認知バイアスとは何か
認知バイアスとは、人間が情報を処理する際に生じる系統的な思考の偏りのことだ。心理学者ダニエル・カーネマンとエイモス・トヴェルスキーの研究で広く知られるようになった。
脳は膨大な情報を高速に処理するため、「ヒューリスティック（経験則）」と呼ばれるショートカットを多用する。このショートカットは多くの場合うまく機能するが、特定の状況で系統的なエラーを生む。これが認知バイアスだ。
エンジニアが陥りやすい認知バイアス
1. サンクコスト錯誤
「すでに3ヶ月開発したから」という理由で、失敗が明らかなプロジェクトを続けてしまう現象。投資した時間やコストは取り戻せない「埋没費用」であり、意思決定に含めるべきではない。
対処法：「今日からゼロベースで判断するとしたら、このプロジェクトを始めるか？」と問いかける。答えがNoなら、撤退すべきだ。
2. 楽観バイアス（計画錯誤）
プロジェクトの所要時間やコストを過小評価するバイアス。「2週間で終わる」と見積もったタスクが2ヶ月かかる。ソフトウェア開発ではほぼ普遍的に発生する。
対処法：「参照クラス予測」を使う。過去の類似プロジェクトの実績データに基づいて見積もる。自分の直感ではなく、統計データを信頼する。
3. 確証バイアス
自分の仮説を支持する情報ばかりを集め、反証する情報を無視するバイアス。「このアーキテクチャが最適だ」と信じている場合、その弱点を指摘する情報を見落としやすい。
対処法：意図的に「反証」を探す。チーム内で「デビルズアドボケイト（悪魔の代弁者）」の役割を設ける。
4. ダニング・クルーガー効果
能力の低い人ほど自分の能力を過大評価し、能力の高い人ほど過小評価する現象。新しい技術を少し学んだだけで「もう使いこなせる」と感じたり、熟練エンジニアが自分のスキルを過小評価したりする。
対処法：スキルの自己評価と客観的な指標（テスト結果、コードレビューのフィードバック）を定期的に照合する。
PMが陥りやすい認知バイアス
5. アンカリング効果
最初に提示された数値に引きずられるバイアス。「競合のアプリは100万ダウンロード」と聞くと、自社の目標もその付近に設定しがちだ。最初の情報が「アンカー（錨）」となり、その後の判断を歪める。
対処法：複数の独立した情報源からデータを収集し、最初に聞いた数値だけに依存しない。見積もりは個人が独立して行い、後から共有する。
6. 生存者バイアス
成功した事例だけを見て判断するバイアス。「Slackは初期にピボットして成功した」→「うちもピボットすれば成功する」。失敗したピボットの事例は報道されないため、成功確率を過大評価してしまう。
対処法：成功事例だけでなく、失敗事例も意識的に収集する。成功の裏にある「見えない多数の失敗」を想像する習慣を持つ。
7. バンドワゴン効果
「みんなが使っているから」という理由で技術やツールを選択するバイアス。最新のフレームワークやSaaSが話題になるたびに導入を検討するが、自社の課題に本当にフィットするかは別問題だ。
対処法：技術選定では「なぜこれが自分たちの課題を解決するのか」を明文化する。流行ではなく、要件に基づいて判断する。
チーム・組織レベルの認知バイアス
8. 集団浅慮（グループシンク）
チーム内の調和を優先するあまり、異論が出にくくなる現象。「みんな賛成しているから大丈夫だろう」という空気が、重大な見落としを生む。
対処法：プレモーテム（事前の反省会）を実施する。「このプロジェクトが1年後に失敗したとしたら、その原因は何か」を全員で考える。
9. 現状維持バイアス
変化を避けて現状を維持しようとするバイアス。レガシーシステムの刷新が進まない、新しいプロセスの導入に抵抗が生まれる原因のひとつだ。
対処法：「現状を維持するコスト」を定量化する。変更のリスクだけでなく、変更しないリスクも明示する。
認知バイアスと共存する
認知バイアスを完全に排除することはできない。それは人間の脳の仕組みに根ざしているからだ。しかし、バイアスの存在を知り、意識的にチェックする習慣を持つことで、その影響を大幅に軽減できる。
チェックリスト、プレモーテム、デビルズアドボケイト、データに基づく意思決定。これらのツールを日常のプロダクト開発に組み込むことが、より良い判断への第一歩だ。
次にプロダクトの重要な意思決定をするとき、「今、自分はどんなバイアスに影響されているか」と問いかけてみてはいかがだろうか。
