「捨てる選択」に向き合えないエンジニア。その「認知的不協和」を吹き飛ばせ
エンジニアなら一度は見る「あの光景」
開発現場にいると、こんな場面に遭遇すること、ありませんか？
あるベテランエンジニアが、数年前に開発した独自の社内ライブラリ。 当時は画期的だったかもしれませんが、今となってはメンテナンスも属人化しているし、世の中にはもっと便利で高機能なOSS（オープンソース）が溢れています。
チームの誰もが「OSSに移行したほうが、バグも減るし工数も下がる」と思っています。 でも、そのベテランエンジニアはこう言うんです。
「いや、あのOSSはウチの特殊な業務ロジックに対応しきれてないし、セキュリティ的にもブラックボックスで不安だ。自分たちの手元でコードを管理することに意味があるんだ」
周りがどれだけ「工数削減のデータ」や「セキュリティの安全性」を説得しても、「いや、でも……」と頑なに自作コードを擁護する。
これ、単なる「頑固な人」というわけではなく、心の中で「認知的不協和」が大暴れしている状態なんですよね。
今回は、こういったことをどのように解決するかというお話です。なお、本記事は『世界は行動経済学でできている』（著：橋本之克）という本からヒントを得て書いています。
認知的不協和とは何か？
認知的不協和とは、簡単に言うと、「自分の『行動』や『信念』と、新しく入ってきた『事実（情報）』が食い違ったときに感じる、強烈な不快感」のことです。
人間は、この「不快感（モヤモヤ）」を解消しようと必死になります。解消する方法は大きく2つしかありません。
- 行動を変える（例：「OSSの方がいい」と認め、自作コードを捨てる）
- 認識（事実の解釈）を変える（例：「OSSは危険だ」と情報を歪め、自作コードを正当化する）
「行動を変える（過去の否定）」や「間違いを認める」というのは、心理的にものすごくエネルギーがいります。 だから、人間は無意識のうちに手っ取り早く「認識を変える（言い訳を作る）」ほうを選んでしまいがちなんです。これが認知的不協和の正体です。
現場で陥りがちな落とし穴
マネジメントやチーム開発において、この「認識の歪曲」は結構な地雷になります。
1. 「『もったいない』精神」との合わせ技で泥沼化
「このアーキテクチャは失敗だったかもしれない」という事実と、「半年間これを作り続けてきた」という行動。この矛盾がストレスになります。 結果、「あと少しチューニングすればなんとかなるはずだ」「この複雑さが逆に堅牢性を生むんだ」と認識を歪め、損切り（リファクタリングや撤退）ができずに、負債を抱え込みます。
2. 技術選定の固執（Not Invented Here症候群）
冒頭のエピソードのように、自分が苦労して習得した技術や作ったコードが「今は最適ではない」と判明したとき。「勉強した時間は無駄だった」と認めるのは辛いものです。 そのため、「枯れた技術こそが至高」「最近の流行りはチャラチャラしていて信用できない」と、新しい技術を攻撃することで心の平穏を保とうとします。
マネージャーやリーダーがこの状態に陥ると、チーム全体が非合理的な決定に付き合わされることになります。
どのように解決していくのか
では、この認知的不協和をどうマネジメントの文脈で捉えればいいのでしょうか。 ポイントは、不協和が発生したときに「認識」を歪めるのではなく、「行動」を変えるほうが楽だと思える環境を作ることです。
小さく失敗させる（アジャイルなアプローチ）
半年かけたコードを捨てるのは苦痛ですが、3日のプロトタイプなら簡単に捨てられます。重要なのは、「『もったいない』（サンクコスト）」という感情が大きくなる前に現実と向き合うことです。
そのためには、Gitで実験用ブランチを切るように、「前言撤回」や「やり直し」を許容する文化が必要です。「間違えても戻せばいい」という感覚を共有し、心理的コストを下げることで、自分を守るための言い訳（認識の歪曲）を防ぐことができます。
客観的指標（メトリクス）を挟む
「自らの経験則」と「新しい技術」がぶつかると不協和が起きやすいですが、ここに「パフォーマンステストの結果」や「可読性のスコア」といった感情の入らない数字を挟みます。 数字という動かせない事実があれば、認識を歪める余地が減り、渋々でも行動を変える方向へ倒れやすくなります。
まとめ
認知的不協和は、自分の心を守ろうとする防衛本能のようなものです。エンジニアであれマネージャーであれ、誰の心にも発生します。
「事実」と「行動」が矛盾したとき、人は放っておくと事実の方を捻じ曲げて、自分を正当化しようとする生き物です。そのメカニズムが存在するという話でした。
