はじめに — バグの本当の原因
障害の振り返りの場で最もよく挙がる表面的な原因は「特定のコードのバグ」です。しかし振り返りを深く掘っていくと、本当の原因はコードではなく人々の間の何かである場合が驚くほど多いのです。
私が経験した一つの事例をお話しします。決済システムで二重請求のバグが起きました。コード自体は二行で直せました。ところが振り返ってみると、一か月前にある開発者がすでにその危険を見つけ、コードレビューで言及していたのです。レビューコメントにはこう書かれていました。「ここで再試行が起きると二重請求になるかもしれませんが?」。そのコメントへの返答はたった一行でした。「今は時間がないので後で見ます」。そして誰も後で見ませんでした。
バグの本当の原因はコードではなく、そのコメントが真剣に扱われなかったという事実でした。意見を出した人は無視されたと感じ、その後レビューでだんだん口を閉ざしました。これは技術問題ではなく、人とコミュニケーションの問題です。
ソフトウェアはコンピューターが実行しますが、人が作ります。人が集まって決定し、議論し、ときに争いながら作ります。だから「人を尊重する」という言葉は温かいスローガンではなく、良いソフトウェアを作る実質的な条件です。この文章では、その尊重を抽象的な説教ではなく具体的な行動として解きほぐしたいと思います。
技術問題に見えるものの本質
ソフトウェアチームで起きる衝突は、表面的には技術論争の衣をまとっています。「RESTかGraphQLか」「モノリスかマイクロサービスか」「この変数名が正しいかあの変数名が正しいか」。しかしその下を覗くと、しばしば次のような非技術的な問題が横たわっています。
| 表面(技術に見える) | 本質(人・コミュニケーションの問題) |
| --- | --- |
| 終わらないアーキテクチャ論争 | 誰の意見がより尊重されるかの力比べ |
| コードレビューが険悪になる | 批判と人格を区別できない |
| 同じミスが繰り返される | ミスを正直に言える安全感の欠如 |
| 情報が共有されない | 信頼と協力の欠如 |
| 会議が長く結論がない | 意思決定権限の曖昧さ |
もちろん純粋に技術的な論争もあります。すべての衝突を人の問題に還元するのもまた危険です。肝心なのは、技術論争が異常に激化したり繰り返されたりするとき、その下に人の問題が横たわっていないか疑ってみることです。技術問題はたいていデータと実験で解けますが、人の問題はそうは解けません。
尊重の具体的な行動
「お互い尊重しましょう」という言葉は誰もが同意し、何も変えません。尊重は名詞ではなく動詞であるべきです。毎日の小さな行動として現れねばなりません。
傾聴 — 話を遮らず最後まで聞く
最も基本ですが最も守られないものです。会議で誰かが話している途中に割り込まない、同意しなくても最後まで聞いて「ちゃんと理解できたか確認させてください」と問い返す。これだけでも雰囲気が変わります。
[傾聴しない会話]
A: 私の考えではキャッシュを導入すれば—
B: いやそれはダメです。キャッシュ無効化がどれだけ大変か。
A: (言葉を失う)
[傾聴する会話]
A: 私の考えではキャッシュを導入すれば応答速度が改善しそうです。
B: 良い方向ですね。一つ心配なのはキャッシュ無効化ですが、
その部分はどう解こうとお考えですか?
A: ああ、それはTTLを短めにしながら—
二つの会話の技術的内容は同じです。違うのは一方が相手を人として扱った点だけです。
クレジット — 功績を正確に帰す
誰かのアイデアで問題が解けたなら、会議で、ドキュメントで、発表でその人の名前を明示的に言うこと。「先週OOさんが提案した方法で解決しました」という一言は、その人にとって大きな承認になります。逆に、他人の功績をこっそり自分のものにすることほど信頼を速く崩すものはありません。
公正 — 一貫した基準で接する
同じミスを誰には寛大に、誰には厳しく接するなら、それは不公正です。好きな人のPRはざっと通し、嫌いな人のPRには難癖をつけるなら、人はすぐ気づきます。公正さは基準の一貫性から生まれます。
時間の尊重 — 相手の集中をむやみに壊さない
「ちょっといいですか」と他人のディープワークをしょっちゅう壊すのも尊重の欠如です。急がない質問は非同期で残し、会議は必要な人だけ、短く。同僚の時間は同僚の最も貴重な資源です。
コードレビューと議論での態度
コードレビューは尊重が最もよく試される場です。コードは人が時間をかけて作った成果物であり、それを批判することは本質的に敏感にならざるを得ません。
コードを批判して人を批判しない
[人を攻撃するレビュー]
「なぜこんな書き方を?基礎が足りない気がしますが。」
「このコードはどうしても理解できません。」
[コードに集中するレビュー]
「この部分でN+1クエリが発生しそうです。一度に取得してはどうでしょう?」
「この流れがうまく追えないので、コメントをもう少し付けていただけますか?」
肝心の原則は「主語をコードにする」ことです。「あなたが間違っている」ではなく「このコードがこういう状況で問題になり得る」と言うことです。
質問の形を借りる
命令より質問のほうが柔らかいです。「こう変えてください」より「ここをこう変えてはどうでしょう?」が相手に考える余地を与えます。ただし、答えの決まった偽の質問(「本当にこれが最善だと思いますか?」)はかえって攻撃的なので避けるべきです。
議論で勝とうとせず、正しい結論に到達しようとする
技術論争の目的は誰が賢いかを証明することではなく、より良い決定を下すことです。「私が間違っていました、その方法のほうが良いです」と言える人が実は最も強い人です。意見の不一致は健全ですが、それが終わったあとは決定に従い(disagree and commit)、人に対するわだかまりを残さないことです。
多様性と包摂 — 異なる視点がより良い結果を生む
多様性を倫理的当為としてのみ語ると空虚になりがちです。より実用的な視点があります。同質的なチームは同じ死角を共有します。全員が同じ背景、同じ経験、同じ思考様式を持つと、全員が同じものを見落とします。
異なる背景の人々は異なる質問を立てます。誰かはアクセシビリティを思い浮かべ、誰かは別の言語圏のユーザーを思い浮かべ、誰かはセキュリティの脅威を思い浮かべます。この多様な質問が集まって、より堅牢なソフトウェアを作ります。
包摂(inclusion)は多様性より一歩先へ進みます。多様な人を集めることを超えて、彼らが実際に声を出せるようにすることです。会議でいつも同じ二、三人だけが話すなら、多様性はあっても包摂はないのです。
包摂を作る小さな実践
- 会議で静かな人に意見を直接尋ねる
「OOさんはこの部分どう思いますか?」
- 非同期チャネル(ドキュメント、チャット)も併せて運用し
口で割り込みにくい人も意見を出せるようにする
- 新人や少数派の意見を先に聞き、シニアの意見を後で出す
(先に権威ある意見が出ると他の意見が埋もれる)
アンチパターン — 天才神話の罠
ソフトウェア業界には「孤独な天才」神話がしぶとく残っています。一人の非凡な開発者がすべてを作り出すという幻想です。この神話は二つの面で有害です。
第一に、事実ではありません。私たちが知るほとんどすべての偉大なソフトウェアはチームが作りました。Linuxでさえ数千人の貢献者が共に作ったものであり、リーナス・トーバルズ本人も誰よりその点を強調します。
第二に、有害です。「天才」と祭り上げられた人は、しばしば無礼を免罪されます。「あの人はもともと気難しいが実力があるから」という言葉がチーム全体の心理的安全を崩します。一人の優れた個人が生む価値より、その人が周りの十人を萎縮させて失わせる価値のほうが大きいことがあります。
Googleが自社のチームを分析したアリストテレス・プロジェクト(Project Aristotle)の結論も同じ方向を指します。最高のチームを作る最も重要な要因は、個々の構成員の天才性ではなく、チームの心理的安全感でした。誰もがバカげた質問をし、ミスを認められる雰囲気のことです。
ほかのアンチパターンも挙げておきます。
- **英雄主義への報酬**: 普段は淡々と働く人より、火を消す(障害を土壇場で収拾する)人だけが称賛される文化。結局みんなが火をつけるようになる。
- **沈黙の外注化**: 「それはあのチームの仕事だ」と責任を押し付ける態度。境界で問題が膿む。
- **シニシズムの伝染**: あらゆる提案に「それ昔やったけどダメだった」で応える人。一人のシニシズムが十人の試みを殺す。
事例 — 無礼な天才 vs 優しい助力者
二人のシニア開発者を比べてみます。どちらも実力は抜群でした。
Sは典型的な「無礼な天才」でした。コードは見事でしたがレビューは厳しく、会議で他人の話をよく遮りました。ジュニアたちはSに質問するのを恐れ、知らないことを知らないと言えませんでした。その結果、同じミスが静かに繰り返されました。
Dは違いました。コードはSほどではありませんでしたが、ジュニアの拙い質問に真剣に答え、自分のミスを先に公開しました。「これ、去年まったく同じく間違えました」と。時間が経つと、Dの周りのジュニアが速く成長し、チーム全体の生産性が上がりました。
一年後にチームの産出物を比べたとき、Dの属するチームのほうが多くを、より安定して作り出しました。個人Sのコード一行はより優れていたかもしれませんが、人Dが作ったチームのほうが強かったのです。これが「結局、人がやる仕事」という言葉の意味です。
実践チェックリスト
- [ ] 今週のコードレビューで「あなた」という主語の代わりに「このコード」という主語でコメントを書く。
- [ ] 会議で一度でも静かな同僚に直接意見を尋ねる。
- [ ] 誰かのアイデアを借りたなら、公の場でその人の名前を言う。
- [ ] 自分が知らないことを「分かりません」と正直に言ってみる。
- [ ] 同僚の集中時間を壊す前に「今ちょっといいですか?」と先に尋ねる。
- [ ] 議論で一度くらい「私が間違っているかもしれません」と先に認めてみる。
- [ ] 非同期チャネルに意見を残し、口で割り込みにくい人にも道を開く。
おわりに
ソフトウェアの品質は、結局それを作った人々の関係の品質を映します。互いを尊重しないチームが作ったコードには、その不信が微妙に刻まれます。共有されなかった情報、扱われなかった警告、口を閉ざした人々の沈黙として。
人を尊重するということは大げさなことではありません。最後まで聞き、功績を正確に帰し、コードを批判して人を批判せず、知らないことを知らないと言えるようにすること。この小さな行動が積み重なって良いチームを作り、良いチームが良いソフトウェアを作ります。
覚えておいてください。私たちが作るのはコードですが、私たちが共に働くのは人です。そして結局、ソフトウェアは人がやる仕事です。
参考資料
- Google re:Work, "Project Aristotle" — https://rework.withgoogle.com/
- Amy Edmondson, *The Fearless Organization* (心理的安全) — https://hbr.org/2023/02/what-is-psychological-safety
- Brian Fitzpatrick & Ben Collins-Sussman, *Team Geek / Debugging Teams* (天才神話の批判) — https://www.oreilly.com/library/view/debugging-teams/9781491932049/
- Google Engineering Practices, "Code Review Developer Guide" — https://google.github.io/eng-practices/review/
- Kim Scott, *Radical Candor* — https://www.radicalcandor.com/
- Harvard Business Review, "The Power of Saying I Was Wrong" — https://hbr.org/
현재 단락 (1/76)
障害の振り返りの場で最もよく挙がる表面的な原因は「特定のコードのバグ」です。しかし振り返りを深く掘っていくと、本当の原因はコードではなく人々の間の何かである場合が驚くほど多いのです。