ソフトウェア開発における認知バイアス

#認知バイアス #ソフトウェア開発 #設計 #思考法

開発者は日々、設計上の判断や実装の選択を行っている。その判断の質は、技術的な知識だけでなく、自分の思考の癖にどれだけ自覚的かにも左右される。認知バイアスは誰にでもある思考の偏りであり、「知っているだけでは防げないが、知らないと気づくことすらできない」厄介な存在である。

この記事では、設計・開発フェーズで特に影響が大きいと感じる認知バイアスを取り上げる。網羅的なカタログではなく、実務で意識しておくと判断の質が上がりそうなものに絞った。

設計フェーズで効いてくるバイアス

確証バイアス

自分の仮説や設計方針を支持する情報ばかり集め、反証となる情報を無意識に軽視してしまう傾向。

設計レビューで「この設計で問題ないですよね？」という聞き方をすると、確証バイアスを強化してしまう。聞かれた側も「まあ大丈夫そう」と答えやすくなる。代わりに「この設計の弱点はどこだと思いますか？」と聞くと、異なる視点が出やすくなる。

確証バイアスは設計段階だけでなく、デバッグ時にも強く作用する。「この部分は問題ないはず」という前提で調査すると、まさにそこにあるバグを見落とす。

ハンマー釘病（道具の法則）

ハンマー釘病は「ハンマーを持つ者には、すべてが釘に見える」という比喩で知られる。慣れた技術やパターンで何でも解決しようとする傾向のこと。

例えば、Reduxに慣れた開発者がシンプルなローカルステートで十分な場面でもグローバルストアを導入しようとする。マイクロサービスの経験が豊富なアーキテクトが、小規模プロジェクトでも過度に分散したアーキテクチャを提案する。

対策として意識しているのは、「この技術を使わない場合、どう解決するか？」を一度考えてみること。その思考実験で別解が浮かばないなら、その技術選定は妥当かもしれない。別解が浮かぶなら、比較検討の余地がある。

IKEA効果

IKEA効果は自分が労力をかけて作ったものを、客観的な価値以上に高く評価してしまう傾向。IKEAの家具を自分で組み立てると愛着が湧くことから名付けられた。

設計に3日かけたアーキテクチャ、苦労して実装したアルゴリズム、丁寧に書いたユーティリティ関数。これらを「捨てる」「置き換える」という判断は、心理的に難しくなる。

厄介なのは、この効果は自覚していても抗いにくいこと。「自分はIKEA効果に陥っていないか？」と自問しても、「いや、これは本当に良いものだから」と結論づけてしまいがち。第三者の視点（レビュアー、ペアプロの相手）が有効な理由の一つはここにある。

NIH症候群（Not Invented Here）

NIH症候群は外部のライブラリやソリューションより、自前実装を好む傾向。「自分たちで作った方がコントロールできる」「既存のものは要件に完全には合わない」といった理由付けがなされる。

もちろん、自前実装が正解な場面もある。問題は、その判断が技術的な合理性ではなく「自分たちで作りたい」という欲求に駆動されていないかどうか。

判断基準として使えるのは：

そのライブラリのメンテナンス状況（更新頻度、Issue対応）
自前実装した場合の長期的なメンテナンスコスト
チームの学習コストの比較

「作る楽しさ」は否定しないが、それがプロジェクトにとって最善かは別問題である。

実装フェーズで効いてくるバイアス

正常性バイアス

正常性バイアスは「自分の環境では問題が起きないだろう」「本番でこんなエッジケースは発生しない」と考えてしまう傾向。

def process_user_input(data):
    # まあ普通はdataがNoneで来ることはないだろう...
    return data.strip().lower()

このコメント（または心の声）は正常性バイアスの典型例。「普通は」「まさか」「さすがに」といったフレーズが頭に浮かんだら、一度立ち止まる価値がある。

ただし、すべてのエッジケースに対応するのも現実的ではない。重要なのは「起きないだろう」という判断が、確率的な見積もりに基づいているのか、単なる希望的観測なのかを区別すること。

サンクコストの誤謬

すでに投資した時間・労力・コストに引きずられて、合理的でない判断をしてしまうこと。

「このアプローチで3日書いたから、今さら別の方法には変えられない」
「このライブラリに習熟するのに時間をかけたから、もっと適切な代替があっても乗り換えたくない」

過去の投資はサンクコスト（埋没費用）であり、将来の意思決定には本来関係がない。しかし人間の心理として、「ここまでやったのだから」という感覚は強力に作用する。

対策としては、「もし今日からやり直すとしたら、同じ選択をするか？」という問いが有効。答えがNoなら、サンクコストに引きずられている可能性が高い。

アンカリング効果

アンカリング効果は最初に提示された数値や情報に、その後の判断が引きずられる現象。

「この機能、どれくらいかかりそう？」
「うーん、前に似たようなの作った時は2週間かかったから...2週間くらいですかね」

この「2週間」がアンカーになり、実際の複雑さとは無関係に見積もりがその周辺に収束してしまう。最初に聞いた数字、最初に見たコード例、最初に読んだドキュメントが、その後の判断の基準点になりやすい。

対策として、見積もりを出す前に「前提なしで考えるとどうか」を意識的に行う。また、複数人で独立に見積もってから共有する（プランニングポーカーなど）のも、アンカリングの影響を減らす方法の一つ。

レビュー・デバッグ時のバイアス

確証バイアス（再び）

設計時だけでなく、デバッグ時にも確証バイアスは強く作用する。

「このモジュールは昨日テストしたから問題ないはず」という前提でデバッグすると、まさにそのモジュールにあるバグを見落とす。自分が書いたコードほど「ここは大丈夫」と思いやすいが、実際にはバグは至るところに潜んでいる。

犬の道を避けるためにも、「問題がありそうな場所」だけでなく「問題がなさそうだが確認していない場所」も意識的にチェックする姿勢が必要。

バンドワゴン効果

バンドワゴン効果は「みんながそう言っているから正しいだろう」「他のレビュアーがLGTMしているから大丈夫だろう」という心理。

コードレビューで先にApproveが付いていると、後からレビューする人は批判的な視点を持ちにくくなる。逆に、最初のレビュアーが厳しい指摘をしていると、後続も細かい点を指摘しやすくなる。

これを意識したレビュープロセスとして、他のレビュアーのコメントを見る前に自分のレビューを完了させるという方法がある。ただし、チームの文化やツールの制約もあるので、一概には言えない。

バイアスとの付き合い方

認知バイアスは「知っていれば防げる」という単純なものではない。知っていても、その瞬間には自分がバイアスに陥っていることに気づけないことが多い。

いくつかの実践的なアプローチ：

1. チェックリストを使う
レビューや設計判断の際に「確証バイアスに陥っていないか？」「サンクコストに引きずられていないか？」といった問いをチェックリスト化しておく。形式的ではあるが、一度立ち止まるきっかけになる。

2. Devil's Advocate（悪魔の代弁者）を意識的に設ける
設計レビューで「この設計の問題点を3つ挙げてください」と明示的に求める。反論を歓迎する空気を作ることで、確証バイアスやバンドワゴン効果を緩和できる。

3. 時間を置く
判断に迷ったら、一晩置いてから決める。時間が経つとサンクコストの心理的影響が薄れ、より冷静な判断ができることがある。締め切りが許す範囲で。

4. 言語化する
「なぜこの設計にしたのか」「なぜこの技術を選んだのか」を言語化して記録しておく。後から振り返ったときに、バイアスに基づく判断だったかどうかを検証できる。

まとめ

認知バイアスは人間の認知の特性であり、完全に排除することはできない。しかし、その存在を知り、自分の判断を定期的に振り返ることで、影響を軽減することは可能である。

特に中堅以上の開発者は、自分の判断に自信を持てるようになる一方で、その自信がバイアスを強化してしまうリスクもある。経験は武器だが、経験に基づく直感が常に正しいとは限らない。

「自分は今、何かのバイアスに陥っていないか？」

この問いを習慣化することが、より良い設計・実装判断につながると考えている。

抽出された概念

この記事から以下の一般概念をnotes/に抽出した：

悪魔の代弁者 - 意図的に反対意見を提示する役割・手法。確証バイアスやバンドワゴン効果を緩和するための構造的対抗手段

既存ノートでカバーされている概念：