あの「深夜の障害対応」だけが評価される不思議。「利用可能性ヒューリスティック」でバグる人事評価の話
「俺はこんなに頑張った」vs「あいつ最近たるんでない？」
想像してみてください。あなたはバックエンドエンジニアです。
この半年、あなたの活動はまさに、神掛かっていました。複雑なスパゲッティコードをリファクタリングし、技術的負債を返済し、システムをかつてないほど堅牢にしました。誰にも文句は言わせない、完璧な仕事ぶりだったはずです。
しかし、評価面談の3日前、ごく些細なバグを1つ出してしまいます。即座に修正しましたが、タイミングが悪すぎました。
迎えた面談当日、マネージャーは開口一番こう言います。 「最近、気が緩んでるんじゃない？」
あなたは耳を疑います。「は？ 半年間の完璧な仕事が、たった1回のミスで全部帳消し？ 正気か？」
これが、評価の現場で頻発する「絶望的な認識のズレ」です。 実はこれ、単なる「記憶違い」や上司の性格の問題ではありません。「エンジニアが見ている『頑張り』」と「マネージャーが見ている『成果』」が根本的に違う上に、脳のバグである「利用可能性ヒューリスティック」がそのズレを決定的にしてしまっているのです。
今回は、この「評価のバグ」の構造と、どう向き合うかという話をします。本記事は『世界は行動経済学でできている』（著：橋本之克）という本からヒントを得て書いています。
そもそも「見ているゴール」が違う
心理学の話に入る前に、前提として押さえておくべき残酷な事実があります。それは、エンジニアとマネージャーでは「使用している言語」が違うということです。
エンジニアの言語：「技術的な正しさ」
エンジニアにとっての「成果」や「頑張り」は、しばしば以下のようなものです。
- コードの品質：可読性が高い、拡張性がある。
- 技術的負債の解消：将来のバグを防ぐ、開発体験を良くする。
- 難易度の克服：難しいアルゴリズムを実装した。
マネージャーの言語：「ビジネス上の利益」
一方、マネージャー（特に非エンジニア出身）にとっての「成果」は、ビジネスインパクトです。
- 売上・利益：いくら儲かったか。
- 納期：スケジュール通りに出せたか。
- コスト削減：サーバー代が減ったか。
ここに悲劇の種があります。エンジニアが「リファクタリング頑張りました！」と言っても、マネージャーの脳内では「で、それはいくら儲かったの？」と変換できず、処理落ちしてしまうのです。
この「ただでさえ伝わりにくい」状況に、トドメを刺すのが次に説明する心理効果です。
脳のバグ「利用可能性ヒューリスティック」
「利用可能性ヒューリスティック（Availability Heuristic）」とは、人間が物事の頻度や確率を判断する際、「思い出しやすい事例」を優先して判断材料にしてしまう心理的な傾向のことです。
脳は省エネ設計なので、過去のデータを全件検索したりはしません。手っ取り早くメモリから引っ張り出せる（利用可能な）情報を元に、「これが真実だ」と判断します。
このバイアスがかかると、マネージャーの視界はどう歪むのでしょうか。
「平穏」は記憶に残らない
マネージャーの脳内メモリは、「トラブル対応」や「急ぎの案件」といった異常値（イベント）で埋め尽くされています。具体的に、マネージャーの脳に「保存されやすい行動」と「保存されにくい行動」を見てみましょう。
【保存されやすい（プラス評価になりがち）】
- 深夜の障害対応：「大変だったね！」という強い感情と共に記憶される（ドラマ性がある）。
- 新機能のリリース：目に見える変化があり、社内報にも載りやすい（視覚的にわかりやすい）。
- 会議での鋭い発言：その場の空気を変えるイベントとして記録される（目立つ）。
【保存されにくい（評価につながらない、または忘れ去られる）】
- トラブルの未然防止：「何も起きなかった」ため、イベントとして認識されない。
- リファクタリング：外側の挙動が変わらないため、変化として認識されない。
- ドキュメント整備：誰かが読むまで価値が顕在化せず、地味な作業としてスルーされる。
ここで問題になるのが、「優秀なエンジニアによる、完璧な予防保守」です。 システムを落とさず、アラートも鳴らさず、静かにコードをきれいにする作業。これはマネージャーの視界にはどう映るでしょうか？
答えは「無（Null）」です。
何も起きていないからです。トラブルという名の「イベント」が発生しない限り、マネージャーの脳内タイムラインには何も書き込まれません。 その結果、半年間のタイムラインはこうなります。
- 1〜5ヶ月目：（平穏無事なので）記憶なし
- 6ヶ月目：【バグ発生！】（＝強烈なイベント！）
こうして、「あいつはずっと成果を出していないのに、最後にバグを出した」という、エンジニアからすれば冤罪のような評価が完成してしまうのです。
解決策としての「翻訳」と「想像」
この構造的なバグを回避するには、お互いに歩み寄るしかありません。キーワードは「翻訳」と「想像」です。
1. エンジニアは「頑張り」を「成果」に翻訳する
マネージャーの記憶に残すためには、彼らの言語（ビジネス価値）でインデックスを作ってあげる必要があります。「技術的にすごいこと」を、そのまま伝えてはいけません。
- ×「リファクタリングでコードが綺麗になりました」
- これでは「自己満足」と捉えられかねません。
- ○「リファクタリングにより、次の機能追加にかかる工数を20%削減できる状態にしました」
- 「工数（コスト）」という言葉なら、マネージャーも理解し、記憶できます。
- ×「特に何も起きず、安定していました」
- これでは「何もしていない」と同じです。
- ○「潜在的なダウンタイムリスクを排除し、想定される数百万円の機会損失を防ぎました」
- 「防いだ損失」を成果として提示します。
「わかってくれるはずだ」という期待は捨てて、相手のコンパイラが通る言語に変換してあげる意識が必要です。
2. マネージャーは「数字に出ない未来」を想像する
一方で、マネージャーに求められるのは、目先のKPIに出てこない部分への想像力と、それを言語化して伝える力です。
「今、数字が出ていない」のは、「サボっている」からではなく、「未来の数字を作っている（種まきをしている）」からかもしれません。ここでも、脳内の自動翻訳を意識的に切り替える必要があります。
- ×「今期は新しい機能リリースがなかったから、評価しづらいね」
- これは「目に見える果実」しか見ていない発言です。エンジニアのモチベーションを粉砕します。
- ○「新機能はないけど、障害ゼロだったね。裏でかなり良い設計をしてくれたおかげだと思ってるけど、具体的にどう工夫した？」
- 「無事」を成果として認識し、そのプロセス（工夫）を掘り下げる質問をします。
- ×「このリファクタリング、いつ終わるの？ 利益生まないよね？」
- 短期的な利益だけで判断すると、技術的負債の返済という「投資」を止めてしまいます。
- ○「今は将来の開発速度を上げるための『投資期間』だと理解してるよ。いつ頃から回収（開発スピード向上）できそう？」
- 「利益」ではなく「投資と回収」というフレームで捉え直し、エンジニアとタイムラインを共有します。
直近の派手なイベント（バグや障害対応）に引っ張られそうになったとき、「ちょっと待てよ、それ以外の期間の静けさは誰のおかげだ？」と、意識的にヒューリスティックのバイアスを補正する思考を持つことが重要です。
まとめ
利用可能性ヒューリスティックは、私たちが日々膨大な情報を処理して生きていくために必要な、脳の生存戦略の一つです。これ自体をなくすことはできません。
しかし、システム開発の現場において、この脳の癖は「エンジニアの地道な貢献」を透明化させ、「派手な火消し」や「直近のミス」だけを過大評価させる厄介なノイズになります。
エンジニアは自分の仕事を「ビジネス価値」に翻訳して伝える。 マネージャーは見えにくい「平穏の裏側」に想像力を働かせる。
お互いに「見ている景色が違う」という前提に立ち、この脳のバグを織り込んでコミュニケーションすること。それだけで、無用な不公平感やストレスは、多少なりとも減らせるものであるという話でした。
