設計レビューで誰も反対しないまま決まった方式が、リリースのあとで問題を起こすことがあります。
逆に、指摘の言い方がきつくて、若手が意見を出さなくなったチームの話もよく耳にします。
どちらも、技術的な議論がうまく回っていない状態です。
テックリードは、議論の中身だけでなく、議論が起きる場の空気にも責任を持つ立場にあります。
心理的安全性の定義を押さえると、率直な指摘と攻撃的な言葉の境目がどこにあるのかが見えてきます。
心理的安全性は「仲がよいこと」ではない
Google は社内の 180 チーム（エンジニアリングのプロジェクトチーム 115、営業のチーム 65）を調べ、成果を出すチームに共通する要素を 5 つにまとめました。
その中で、最も重要とされたのが心理的安全性です。
定義は「対人関係のリスクをとってもこのチームは安全だと、メンバーが共有して信じていること」で、ハーバード・ビジネス・スクールのエイミー・エドモンドソン教授が 1999 年の論文で示したものです。
同じ調査は、誰がチームにいるかよりも、チームがどう協力して働くかのほうが効いていたと報告しています。
調査の中身は Understand team effectiveness（Google re:Work） で読めます。
心理的安全性は、衝突がないことや、厳しいことを言わないことと混同されがちです。
エドモンドソンは著書『恐れのない組織』で、心理的安全性と仕事の基準の高さを、別々の軸として並べています。
安全性が高くても基準が低ければ居心地がよいだけのチームになり、基準が高くても安全性が低ければ、メンバーは不安から問題を隠すようになります。
両方が高いときにだけ、チームは率直に言い合いながら学び続けられるという整理で、エドモンドソンはこの状態を学習ゾーンと呼んでいます。
率直さと攻撃性は、言葉の向け先で分かれる
では、率直な指摘と攻撃的な言葉は何が違うのでしょうか。
Kim Scott の Radical Candor は、フィードバックを「相手を人として気にかけているか」と「直接異を唱えているか」の 2 軸で整理しています。
両方を満たすのが Radical Candor で、異を唱えても気にかけていることが伝わらなければ Obnoxious Aggression（直訳すると不快な攻撃）に分類されます。
反対に、気にかけていても指摘を飲み込んだり包み隠したりすると、Ruinous Empathy（破滅的な共感）になるそうです。
4 つの分類は Radical Candor の公式サイト にまとまっています。
コードレビューについては、Google が公開しているレビューのガイドがもっと具体的です。
ガイドは、礼儀正しさと明確さを両立させるために、コメントは常にコードについて書き、開発者について書かないよう勧めています。
悪い例として挙がっているのは、「明らかに並行処理の利点がないのに、なぜあなたはここでスレッドを使ったのですか？」という書き方です。
良い例では、並行処理が性能の利点なしに複雑さを足していることを述べ、だからシングルスレッドにすべきだと理由まで書いています。
例の全文は How to write code review comments（Google Engineering Practices） にあります。
指摘の強さを変えなくても、主語を人からコードへ移すことはできます。
テックリードが先に決めておく議論の型
場の空気は、個人の心がけだけでは安定しません。
議論の型を先に決めておくと、誰が発言しても同じ土俵で話せるようになります。
コメントの重さを明示する
同じガイドは、コメントに「Nit:」「Optional:」「FYI:」のような接頭辞を付けて、必須かどうかを分けることを勧めています。
すべての指摘が同じ重さに見えると、細かい好みの話まで否定に聞こえてしまいます。
重さのラベルがあれば、受け手は直すべきものと参考意見を分けて読めます。
失敗を報告した人を責めない
障害や見落としを報告した人が責められるチームでは、次から報告が遅れます。
Google の SRE 本は、ポストモーテムを、個人やチームを責めずに何が起きたかと原因に集中して書くものとして説明しています。
考え方の元は、SRE 本の Postmortem Culture の章です。
DORA も、組織文化を 3 つに分けた Westrum の分類を使っています。
そのうち、失敗が調査につながり、悪い知らせを持ち込んだ人が育てられる「生成的な文化」は、ソフトウェアデリバリーと組織の成果を予測するとされています。
詳しい説明は、DORA の Generative organizational culture のページにあります。
ポストモーテムの書き方そのものは、別の記事で扱いました。
テックリード自身が間違いを認める
議論の場でいちばん影響が大きいのは、テックリード本人の振る舞いです。
エドモンドソンの著書も、リーダーが自分の知らないことや間違いを認める謙虚さを、発言を促す行動の一つに挙げています。
自分の設計の穴を指摘されたときに受け止めて直す姿を見せれば、ほかのメンバーも反論してよいのだと分かります。
落とし穴は「何を言ってもいい」への読み替え
心理的安全性があるからといって、どんな言い方をしてもよいわけではありません。
安全性は発言のリスクを下げるためのもので、相手を傷つける言葉の免罪符ではないからです。
もう一つの落とし穴は、反論が出るようになったあとで、決め方が決まっていないことです。
意見が出そろっても、いつ・誰が決めるのかが曖昧だと、議論は長引くだけになります。
設計の判断を Design Doc や ADR に残しておけば、反対意見と決めた理由を後から追えます。
コードレビューの指摘をどう運用するかは、別の記事で整理しています。
最後に
心理的安全性は、厳しい指摘をなくすことではなく、厳しい指摘を出しても関係が壊れない状態のことでした。
指摘の矛先を人ではなくコードと判断に向け、コメントの重さと決め方を先に決めておくことが、テックリードにできる具体的な手当てになります。
私もテックリードを目指して学んでいる途中なので、まずは自分のレビューコメントの主語から見直してみます。
以上です。
コメントを残す