エンジニアは自らを「論理的な人間」と認識しがちだ。しかし、認知科学の研究は容赦なく事実を突きつける。人間の脳は合理的な判断装置ではなく、数百万年の進化で獲得した「素早くそれなりの判断を下す」ための器官だ。この「素早さ」を実現するショートカットが、現代の複雑な意思決定では「認知バイアス」として裏目に出る。エンジニアの日常を蝕む20のバイアスを、カテゴリ別に解剖する。
情報の取得と解釈に関わるバイアス
最初のカテゴリは、情報をどう集め、どう解釈するかに影響するバイアスだ。
| # | バイアス名 | 定義 | エンジニアリングでの発現 |
|---|---|---|---|
| 1 | 確証バイアス | 自分の仮説を支持する情報ばかり集める | 選んだ技術の良い記事だけ読む |
| 2 | アンカリング効果 | 最初に接した数値に判断が引きずられる | 最初の見積もりに後の調整が不十分 |
| 3 | 利用可能性ヒューリスティック | 思い出しやすい情報を過大評価する | 直近のインシデントを過剰に対策 |
| 4 | フレーミング効果 | 提示の仕方で判断が変わる | 「99.9%の稼働率」と「年8.7時間の停止」 |
| 5 | 選択的知覚 | 関心のある情報だけ認識する | 自分の専門領域の問題ばかり目につく |
確証バイアスは特に厄介だ。ある技術を「採用したい」と思った瞬間から、その技術を褒める記事が目に入りやすくなり、批判的な記事はスルーしてしまう。技術選定の会議で「調査の結果、やはりXが最適です」と報告するとき、その調査自体がバイアスに汚染されていないかを疑う必要がある。
対策としては、「悪魔の代弁者(Devil's Advocate)」を制度化する方法がある。技術選定の際に、必ず1人が反対意見を担当する。これにより、確証バイアスの暴走を構造的に防げる。
自己評価と能力判断に関わるバイアス
2番目のカテゴリは、自分の能力や知識をどう評価するかに関わるバイアスだ。
| # | バイアス名 | 定義 | エンジニアリングでの発現 |
|---|---|---|---|
| 6 | ダニング=クルーガー効果 | 能力の低い人が自己を過大評価する | 初学者が「フレームワークは簡単」と判断 |
| 7 | インポスター症候群 | 能力の高い人が自己を過小評価する | シニアが「自分はまだ未熟」と感じる |
| 8 | 知識の呪い | 知っている人が知らない人の視点を想像できない | ドキュメントが[初心者](/tag/beginner)に不親切 |
| 9 | 過信バイアス | 自分の判断の正確さを過大評価する | 「テストなしでも大丈夫」 |
| 10 | 自己奉仕バイアス | 成功は自分の力、失敗は外部要因のせい | 障害の原因を他チームに帰属 |
ダニング=クルーガー効果は、技術の学習曲線と深い関係がある。新しい言語やフレームワークを学んで最初のアプリを作れた段階で「マスターした」と感じてしまう。しかし実際には、エラーハンドリング、パフォーマンス最適化、セキュリティ対策など、プロダクション品質に必要な知識の90%がまだ残っている。
逆に、インポスター症候群はシニアエンジニアに多い。知識が増えるほど「知らないこと」の広大さに気づき、自分の能力を過小評価する。これは知的に誠実な態度ではあるが、意思決定の場で不必要な躊躇をもたらすこともある。
判断と意思決定に関わるバイアス
3番目は、具体的な判断を下すときに影響するバイアスだ。
| # | バイアス名 | 定義 | エンジニアリングでの発現 |
|---|---|---|---|
| 11 | サンクコストの誤謬 | 過去の[投資](/tag/investment)を理由に不合理な継続をする | 失敗プロジェクトを「もう半年費やしたから」と継続 |
| 12 | 現状維持バイアス | 変化よりも現状を好む | レガシーシステムの刷新を先送り |
| 13 | 計画錯誤 | タスクの所要時間を楽観的に見積もる | 「2週間でできます」が3ヶ月に |
| 14 | 正常性バイアス | 危機的状況を過小評価する | 「セキュリティ侵害はうちには起きない」 |
| 15 | ゼロリスクバイアス | 小さなリスクを完全に消すことを好む | 低確率の障害に過剰な対策を講じる |
サンクコストの誤謬は、大規模プロジェクトで壊滅的な影響をもたらす。すでに1年と5000万円を投じたプロジェクトが方向性を誤っていると判明しても、「ここまで来たのだから」という感情が合理的な撤退判断を妨げる。経済学的に正しい判断は「過去の投資は無視して、今後の投資対効果だけで判断する」だ。
計画錯誤も深刻だ。心理学者のダニエル・カーネマンは、人間は自分のタスクの所要時間を体系的に過小評価することを実証した。対策として「参照クラス予測」がある。類似のプロジェクトが実際にかかった時間を統計的に調べ、それを基準にする方法だ。
集団の意思決定に関わるバイアス
最後のカテゴリは、チームや組織レベルの判断に影響するバイアスだ。
| # | バイアス名 | 定義 | エンジニアリングでの発現 |
|---|---|---|---|
| 16 | 集団思考 | 集団の調和を優先し批判的意見を抑制 | リーダーの意見に全員が同調 |
| 17 | バンドワゴン効果 | 多数派に合わせる傾向 | 「みんな[Kubernetes](/tag/kubernetes)だから」で導入 |
| 18 | 権威バイアス | 権威者の意見を無批判に受け入れる | 著名エンジニアの推奨を検証せず採用 |
| 19 | IKEA効果 | 自分で作ったものを過大評価する | 自作ツールに固執し[OSS](/tag/oss)を使わない |
| 20 | NIH症候群 | 外部で開発されたものを拒絶する | 「自社で作った方がいい」 |
集団思考は、心理的安全性が「低い」チームで発生しやすい。反対意見を述べると評価が下がると感じる環境では、メンバーはリーダーに同調し、問題の兆候を見逃す。NASAのスペースシャトル・チャレンジャー号事故は、集団思考の悲劇的な結末として広く知られている。
IKEA効果とNIH症候群は、エンジニアの「作りたい欲求」と結びついて特に強力に作用する。自分たちで一から構築したシステムには愛着が湧くが、その愛着が客観的な品質評価を歪めてしまう。
バイアスと付き合う——「メタ認知」の力
認知バイアスを完全に消し去ることはできない。それは脳の構造に根ざしたものだからだ。できるのは、バイアスの存在を知り、自分の判断が歪められている可能性を常に考慮すること——つまり「メタ認知(自分の思考について考えること)」を鍛えることだ。
実践的には、重要な判断を下す前に「このバイアスリストの中で、今の自分の判断に影響しているものはないか」と一瞥するだけでも効果がある。チームであれば、定期的な振り返りでバイアスの実例を共有し合うことで、集団的なメタ認知力が高まる。
あなたの直近のプロジェクトで、今振り返ると「バイアスに影響されていた」と気づく判断はなかっただろうか?