職場で正しくあろうとすることは、職場以外でもそうですが、実際には進歩を妨げかねないと、このエンジニアリング部門のディレクターは言います。
正しいことだけを目的に議論するのは、エネルギーの無駄になりかねません。
彼女によれば、正しさは手順にあり、成果は結果に表れます。
意見が対立したときは、解決策が何を実現するためのものなのかを理解できるよう、まず問題について合意することが大切です。
最近、パートナーと私はひどい引っ越しを経験しました。大家さんたちは親切で良識的な人たちだったのは幸運でしたが、かなり段取りが悪く、家具を注文したり、前の入居者の退去後に徹底的に掃除したりと、必要なことをすべて済ませていなかったのは不運でした。
そうした状況が進むなか、ホテル暮らしをしながら、私にとっては新しい国で、彼の新しい仕事と私の仕事、そしてあらゆることの大混乱に対処しているうちに、私たちの違いが表面化し始めました。
ソフトウェアエンジニアのパートナーは「彼らはこういうことをするべきだ」と言いました。エンジニアリング部門のディレクターである私は、リスクを軽減する戦略を練り始めました。
残念ながら、戦略レベルで合意に至らなかったため、私のリスク軽減策は不完全なまま実施されました。そしてようやく入居できた後、私は猫の残り香にじわじわと窒息させられるような一週間を過ごしました。
今ではパートナーと私はうまくやっています。国際的な引っ越しはせいぜい数年に一度でしょうから、同じような経験をすぐにまたすることもないでしょう。でも、職場では毎日、似たような力学が働くのを目にします。特に、正しさを好むソフトウェアエンジニアを見て、私はこう尋ねます。「正しくありたいですか？それとも成果を上げたいですか？」
そして時折、自分自身が議論に巻き込まれると、同じ問いを自分に投げかけます。
正しさと成果を上げること
正しくありたいと思うのは理解できます。特にソフトウェアエンジニアリングのような仕事では、正確さによって仕事を進めるからです。問題を取り上げ、分解し、実装して、リリースする。行き過ぎる人もいます。「自分の環境では動く」とか「キーボードと椅子の間の問題」などと言いますが、そこまで鼻につかない人でさえ、仕事が具体的で測定可能であることに安心感を覚えます。テストに合格する。指標を動かす。正しい。
規模が大きくなるにつれて、より多くの人と働くようになります。それでも決定的な正しさを追い求めていると、全体の目的を見失うことがあります。AとBの両方をリリースしなければ機能しないプロジェクトを進めていて、どちらか一方がリリースされなかったとしたら、プロジェクトも失敗です。そして、その問題の責任をリリースできなかったチームに問うことはできるでしょう（正しかったということです）。しかし、時間を巻き戻して問題を予見し、リスクを軽減できるなら、成果を上げることができます。
正しさにこだわるリスクは、誤ったことを最適化してしまう点にあります。正しさは、仕組みやアーキテクチャ、テスト範囲、そして全員が約束したことをそのとおりに行うことに表れます。成果は結果に表れます。
問題について合意する
正しさと成果をめぐる意見の対立に気づいたとき、よく見られるのは、正しくありたい人たちが、その解決策で何を実現するのかについてまず合意せずに、答えを提案していることです。
少し前、私のチームの一つで、ホットフィックス（稼働中のシステムのバグを修正するための、予定外のプログラミング）を行う際に、インシデント対応プレイブック（標準的な緊急対応手順）を使うべきかどうかで議論になりました。一見、専門的で細かな手続き上の論点です。そんなに重要なのでしょうか。しかし、皆かなり強硬になっていました。ところが、最近ホットフィックスを何件行ったかといったデータで測りながら、問題そのものを話し合うようになると、チームはすぐに、意見の相違と問題の両方を解決しました。
話し合いが建設的でないと感じたら、こう尋ねてみましょう。「ここで解決しようとしている問題は何でしょう？どのような形で表れていますか？どんな影響がありますか？」プロセスを変えようとしているなら、まず解決したい問題を明確にし、チームにその問題の解決を支持してもらいましょう。
解決策を提案して問題を片づける人になれるのは気持ちのよいことです。しかし、成果を上げるという考え方に切り替えるには、自分が問題を解決する人でなければならないという思いを手放し、物事を前に進めるファシリテーターの役割を担う必要があります。チームが問題について合意した後、誰かがあなたの考えていた解決策を提案したなら、それは大きな成果です。つまり、問題は解決策ではなく、問題への理解が不足していたことなのです。
議論にエネルギーを注ぐか、注がないか
「インターネット上で誰かが間違っている」せいで机から立ち上がれない、というXKCDのすばらしい漫画があります。インターネットでも職場でも、誰かの間違いをそのままにしておいてよいのです。特に、自分にほとんど影響がないならなおさらです。
リリース日に幸運の靴下を履かなければならないとか、満月の前後の日には1対1の面談をしてはいけないと誰かが信じているとします。かなり奇妙に思えるかもしれませんが、その考えが誰にも実害を及ぼさないなら、気にする必要があるでしょうか。
実際の問題と比べれば、青が好きか緑が好きか、文末のピリオドの後にスペースを二つ入れるか一つにするかといったスタイルの違いは、ただの……スタイルの違いです。意見を伝えたら、あとは忘れましょう。スタイルガイドを示し、自分の好みを伝えたら先へ進みましょう。
ずっと昔、メールのスレッドで100通に及ぶ議論を目にしました。コードの条件式を「var == const」と「const == var」のどちらにすべきかという議論です。そのスレッドに費やされた時間とエネルギーに驚きましたが、発端となった人はその議論を楽しんでいました。終盤までは。最後に誰かが加わり、私がずっと考えていたことを口にしたのです。些細なことにこれほど考えを費やすなら、その結果、ほかの何が検討されずにいるのだろうかと思う、と。
議論を心から楽しむ人もいます。でも、そうでなくても問題ありません。コンパイラーがチェックするようなことで、些細な言い争いに加わる義務はありません。むしろ、議論が好きでないなら、なおさら参加しなくてよいのです。本当に大切なことのために、そのエネルギーを取っておきましょう。
誰か（あるいは自分自身）が何かについて議論すべきか考えるのを手助けするとき、私はこう尋ねます。
なぜそれがあなたにとって重要なのですか？
それはあなたの成果にどう影響しますか？
何が起きたら問題になりますか？
こうした問いによって、本当の問題が何なのか、そもそも問題があるのかを明らかにし、そこから話し合うべきことへと進めます。
何かがあなたの成果に大きく影響するなら、強く主張するのは理にかなっています。最大の課題が採用で、特定の変更によって採用が大幅に難しくなるなら、仕事も大幅に難しくなります。その点を説明し、異議を唱えるべきです。全体として順調に成果を出せていて、その変更に人々が慣れるまで少しペースが落ちるのではと心配しているだけなら、おそらく対処できるでしょう。
「何が起きたら問題になりますか？」と尋ねると、懸念している二次的な影響が明らかになります。意見の対立は、現在の判断そのものではなく、同じ判断が続いた場合に将来の判断へ及ぼす影響をめぐることがよくあるからです。たとえば、注目度の高い人材を採用する際、給与バンドを外れた報酬を提示したとします。問題は、その採用と給与額でしょうか。そこを議論したいのでしょうか。それとも、同じことが繰り返されれば、既存の給与バンド制度が完全に形骸化し、在籍するエンジニアの給与が相対的に低くなることが問題でしょうか。もし再び同じことが必要になった場合には、報酬体系全体を見直すべきだというのが、本当の論点かもしれません。そのほうが、明らかに採用したいと思われ、何らかの点で際立った人材を諦めるよう説得するより、合意を得やすいでしょう。
長期的な視点で議論するときも、目の前のことを議論するときも、意見の対立を短く、より建設的にすることは、望む結果を実現するのと同じくらい大きな効果をもたらし得ることを忘れないでください。
異議を唱えたうえで決定に従う
以前の職場で組織再編があったとき、影響を受けたグループのリーダーが別のチームへ移りました。再編を設計した人はそれを不満に思い、リーダーが「異議を唱えたうえで決定に従う」ことを拒んだのだと表現しました。ある人が、「異議を唱える」ことと「従う」ことは、実際には別々のことだと指摘しました。リーダーが決定に従えないのであれば、別のチームへ移るのは理にかなっていました。
この経験で、私の「異議を唱えたうえで決定に従う」という考え方はまったく新しいものになりました。意見の相違については、話し合いを続けることができます。何について、またなぜ意見が違うのかに応じて、異なる側面を重視できます。強く意見が対立するなら、何に同意し、何には同意できないのかを慎重に考えるべきです。意見の相違を意識的に分解し、どの議論に加わるかを慎重に選べば、その違いを見極めやすくなります。
前の職場である日、同僚たちと、キャリアの進展を定義するためにエンジニアの職位制度を導入するかどうか、長い議論をしていました。導入には正当な理由があります。成長や報酬を実感する助けになり得るので、業界標準になっているのです。私の考えでは、それは万能薬ではなく、特にその組織ではそうでした（職位制度が報酬に反映されることも、報酬と結びつくこともなかったためです）。全体としてプラスになるかも疑問でした。昇進のプロセスを運営するには多くの時間がかかり、人を昇進させるだけでなく、昇進できなかった人にもそう伝えなければならないからです。とにかく議論は続き、私が「まあ、私はそれを実行する人にはなりません」と言うと、終わりました。彼らが私に実行してほしいと思っていたのか、それとも、ほかに誰も実行する気がないことが明確になったのかは分かりません。
「私はこれを実行する人にはなりません」という言葉は、ごく限られた場合にだけ使うでしょう。しかしあの経験で、自分が持つ力の一端が明らかになりました。何かを使うことに同意するのと、自分がそれを実行することに同意するのは同じではありません。
新入社員に「混沌へようこそ」と声をかけるような職場で働いた経験から、自分の平静を保つために、成果を上げるのに十分な正しさとは何かを考えるようになりました。すべてが完璧である必要はありません。皆で一緒に仕事を進められるだけ十分であればよいのです。
