人間の論理は、私たちがプログラミングして毎日使っているマシンの論理とは違って完璧ではありません。人間は間違えますし、悪い精神的習慣を確立してしまいますし、エンジニアとして成功するための能力に悪影響を及ぼす認知バイアスをたくさん持っています。ソフトウェアエンジニアとして定期的に目にする一般的なバイアスのうち5つを見ていきたいと思います。

1. 根本的な帰属の誤り

根本的な帰属の誤りは、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアスとも。 （参照）

これは私のお気に入りの認知バイアスです。”至る所で”見られるからです。道で誰かに行く手を遮られると、その人を完全に嫌なヤツだと思ってしまいますが、自分が同じことをしてしまう時は、相手が見えていなかったとか、会議があって遅刻できなくて急いでいたといった理由があります。誰かがバグを書いてしまったりサイトをダウンさせてしまうのは、その人が怠慢でダメなエンジニアだからです。しかし、自分がバグを作り出してしまった時は、疲れていたり、自動化されたテストが十分にできなかったり、急がされていたり、要件定義が不十分だったり、満月のせいだったりします。

こういうわけでEtsyは Blameless PostMortems を非常に重視しています。現実には、”失敗のメカニズムの状況的側面”では、将来的に失敗の確率を下げる改善が見られるはずです。人をどなりつけて仕事の質を上げさせようとするのは、うまいやり方とは言えません。ソフトウェアの世界では幸運にも、何かが壊れたら、頻繁にプロセスを自動化したり、テストを追加したりして同じ壊れ方をしないようにできます。この認知バイアスを意識して、関係する人間の個性ではなく、状況に注目するようにすれば、このバイアスが私たちの生活に及ぼす悪影響を減らすことができます。

2. 確証バイアス

確証バイアスとは社会心理学における用語で、個人の先入観に基づいて他者を観察し、自分に都合のいい情報だけを集めて、それにより自己の先入観を補強するという現象である。 （参照）

このバイアスは手動テストで最もよく起こります。新しいコードを書いた時、動作すると分かっているケースばかりをテストしてしまいがちです。そうすれば、テストにあまり時間をかけずに（みんな手動テストが嫌いなので）、堂々と「動作します！」と宣言できます。このバイアスのせいで、コードは十分にテストされずに投げ出されて、別の人間に尻拭いをしてもらうような惨めな結果になる可能性があります。

私見ですが、これは乗り越えるのが難しいバイアスの1つです。自分自身の限界を認め、自分の書いたコードの脆弱な部分を強調することになるからです。誰もが自分のソフトウェアには動作してほしいと思っているので、必然的にその願いに沿うような証拠に引かれてしまいます。この衝動と闘ってテストをし続けて、常に自分の前提を疑ってください。

3. バンドワゴン効果

バンドワゴン効果とは、ある選択が多数に受け入れられている、流行しているという情報が流れることで、その選択への支持が一層強くなることを指す。 （参照）

これを最もよく見かけたのは、サードパーティのソフトウェアを評価する時です。私は実際に、会議に入る時には誰もそのツールを購入する決定はしないだろうと思っていたのに、会議が終わる頃には購入契約をすることが決まっていたという経験があります。とても尊敬されている人が意見をまとめると、他の人々はそれに乗りたくなるものです。この衝動と闘うための様々な戦略があり、例えば、全員が投票し終わるまで他の人の投票内容が分からないような投票方式は、適切な状況で行えばうまくいきます。（サードパーティのツールに大金を投じるような）大きな決断をする場合、まず利害関係者全員に、他の（もっと上の地位の）人々によって彼らの地位が影響を受けない形で、内々に意見を書き出してもらうのは理にかなっていると思います。

4. 双曲割引

2つの似たような報酬の選択肢を与えられると、人は早く受け取れる方を選ぶ傾向がある。報酬が遅れれば遅れるほど、人はその報酬の価値を割り引くと言われている。 （参照）

簡単に言うと、今日もらえる価値の低い報酬の方が、将来もらえる価値の高い報酬よりも魅力的に見えるということです。これは技術的負債が頻繁に生じる原因でもあります。不十分な設計をしたり、手っ取り早い方法を取ったりすれば、今すぐに価値（正しく厳密に構築しなくて済むというメリット）が得られるので魅力的に見えます。最初から厳密にやる方が将来的には大きな価値が得られるのに、その価値を大幅に割り引いて捉えてしまうのです。粗悪なコードを書けば、のちのちデバッグしたりリファクタリングしたり、コードを解釈して実行したりするのに時間というコストがかかりますが、そのコストを見積もることは人間にとって非常に難しいのです。皆さんも以下のような経験があるでしょう。例えばプロジェクトに参加した時、より良い方法が見えているのに、今リファクタリングに数時間か余計にかけるのが嫌で、長期的に見ればそのひと手間で多くの時間を節約できると分かっていたとしても、やりたくなくなってしまうのです。

私が思うに、こうなるのを回避するには、意識的に立ち止まって判断する練習をすることです。まずリファクタリングにどのくらい時間がかかるかを、ものすごく多めに見積もります（例えば最初のイメージの2倍くらい）。次に、どれだけの人がどのくらいの頻度で、自分の書いたコードと向き合うことになるかを考えます。自分が生もうとしているインクリメンタルな技術的負債と混乱をごく控えめに見積もってもいいですから、リファクタリングの手間がどんなに長い時間で”清算”されるのかを算出してみてください。通常はこの練習によって物事が浮き彫りになり、どちらの道を選択すべきかがはっきりします。もしそれでもまだ決めかねるようであれば、自分の携わっているプロジェクトのタイプによって判断しましょう。大手企業のプロジェクトなら、リファクタリングをするべきです。 MVP つまり最低限の機能を持った製品をとりあえずリリースしようというスタートアップ企業のプロジェクトなら、好きなようにやってしまいましょう（たぶんどちらにしろ、あなたのコードは書き換えられます）。とはいえ、常に自分の作ったコードに向かう人のことを考えましょう…

5. ネガティビティ・バイアス

ネガティビティ・バイアスとは、人間がポジティブな経験よりもネガティブな経験や情報の方により重きをおくという心理現象である。 （参照）

常にどんな意見でも否定するのに、多くの人から尊敬を集めていて、ものすごく知的に見える人と一緒に仕事をしたことがありますか？　もしかしてあなたがそうですか？　私はそういう人と組んだ経験があります。ネガティビティ・バイアスは強力で、否定的な態度を取る人の意見に、みんなが耳を傾けていました。これは、誰もが認めるような根拠を持つような議題（地球温暖化など）でさえも、それを強く否定する人が存在する理由の1つです。ソフトウェアエンジニアリングの世界では、実装がかなり難しい機能について製品開発責任者や設計者が説明する時、これがよく起こります。エンジニアたちが、その実装が達成不可能である理由を説いて、しばしばこれを突き返すのです。私たちの誰もが持つネガティビティ・バイアスのせいで、こういった否定的な人々は知的で熟達した印象を与え、会社の時間と経費の削減に貢献しているように見えるのです。何かに対してノーと言う判断は正しいことも多いですが、いつでもノーばかり言っている人を見つけた場合は、一歩退いて、その人の主張に価値があるのか、または自分が認知の罠にかかってしまっているだけなのかを自問してください。

結論

ここまでに述べた全てのバイアスへの対応として最も重要なステップは、こういったバイアスの存在を認識し、日々の生活の中で実際にそれが現れた時にどんなものかを特定することです。一度特定できてしまえば、あとは一歩引いてその場の状況を考えればいいのです。他の人が巻き込まれている時などは特に、声を大にしてバイアスのことをその人たちに話してもよいでしょう。よくある認知の罠にかかっている可能性があるという意識を持つことで、改めて会話に集中し、自分の意思を明確にすることができるのです。

もし合理性や認知バイアスについて学び、私たちの脳の持つ弱みに打ち勝つ方法を知りたければ、 LessWrong というブログをチェックして、 Harry Potter and the Methods of Rationality という記事を読んでみてください（まじめに、ぜひやってみてください）。