火事場のクソ判断。なぜ僕らはプレッシャーで「やらかす」のか？
やぁ、みんな。ヨーロッパの片隅で、C#とWPFを相棒に、クライアントの無茶振りやバグと日々格闘してるITエンジニアです。
突然だけど、エンジニアの仕事って、ぶっちゃけコーディングしてる時間より「何かを決めてる」時間の方が長くない？（笑）どのアーキテクチャを選ぶか、このバグ修正をどうアプローチするか、どのライブラリを採用するか、あるいは採用しないか。僕らの仕事は、大小さまざまな「意思決定」の連続でできてる。
日本で働いていた頃ももちろんそうだったんだけど、海外に出てきてから、この「意思決定」の重みとプレッシャーが、マジでレベル違いになったと痛感してる。
言語の壁？ もちろんある。文化の違い？ 死ぬほどある。時差ボケの中での深夜ミーティング？ 日常茶飯事だ。
でも、それ以上にキツいのが、「説明責任の重さ」と「スピード感」だ。
日本だと「一旦持ち帰って検討します」で許された（かもしれない）場面でも、こっちでは「Why?（なんで？）」「What’s your rationale?（君の論理的根拠は？）」「What’s the alternative?（代替案は？）」と、その場で矢継ぎ早に突っ込まれる。こっちは非ネイティブの英語で、技術的な複雑さを、ロジックが大好きな現地エンジニアやPM（プロジェクトマネージャー）相手に説明しなきゃいけない。
そんな状況で、冷静な判断を下し続けるのって、かなりしんどくない？
今日は、僕が過去にやらかした「火事場のクソ判断」とも言うべき大失敗と、なぜ僕らエンジニアが（特に海外というプレッシャー下で）合理的な判断を見失ってしまうのか、その構造について、ちょっと深く掘り下げてみたいと思う。
これは、これから海外を目指す君たちにとって、技術書（C#の文法やWPFのXAMLの書き方）には絶対に載っていない、でも、生き残るために必須の「サバイバル術」になるはずだ。
僕の「大やらかし」体験談：深夜ミーティングとMVVMの悪夢
あれは数年前、僕がこっちに来てまだ間もない頃。ある大手製造業のクライアント向けに、WPFを使った工場ラインの監視アプリケーションを開発するプロジェクトにアサインされた。
要件は「とにかく高レスポンス。データがリアルタイムでガンガン更新されるけど、UIは絶対にフリーズさせないこと」。まぁ、WPF開発者なら「はいはい、非同期処理（async/await）とデータバインディングの最適化ね」ってなる、よくある話だ。
問題は、プロジェクトがすでに遅延気味で、僕がジョインした時点で火を噴き始めていたこと。
ある木曜の深夜（こっちの時間。クライアント側は昼）。時差ボケで頭が半分寝てる中、クライアントと現地のPM、そして僕（唯一のWPF担当）でのオンラインミーティングが開かれた。
議題は、特定の複雑な画面でのパフォーマンス低下。
PM（早口の英語）：「（俺の名前）、この画面のレスポンスが最悪だ。クライアントが怒ってる。明日までに改善の目処を立ててくれ」
僕：「（うわぁ…）えっと、今調査中ですが、おそらくデータバインディングの量と、非同期処理の管理に問題があるかと…」
PM：「『思う』じゃなくて、原因は？ 解決策は？」
僕：「（焦り）いくつかの方法を考えています。一つはUIの仮想化を導入すること、もう一つは…」
ここで、クライアント側の技術担当（いかにもカタブツそうなドイツ人）が割って入った。
クライアント：「そもそも、君のMVVMの実装は本当に最適なのか？ データフローが複雑すぎないか？ 我々はもっとシンプルなソリューションを求めてるんだが」
カチン、と頭の中で何かが切れる音がした。
いやいや、おたくらの要件が複雑だから、こっちも頑張って設計してるんじゃん！
でも、非ネイティブの僕は、その怒りや技術的な正当性を、流暢な英語で瞬時に説明できない。言葉が喉につかえる。「えっと…（Umm…）」「それは…（Well…）」
PMはイライラしてる。クライアントは疑いの目を向けてる。時計は深夜2時を回ってる。
その瞬間、僕の口から最悪の言葉が飛び出した。
「…わかりました。では、この部分の設計を、以前のプロジェクトで使った、もっとシンプルな（だけど今回の要件には明らかにオーバースペックで、かつレガシーな）自社製フレームワークに置き換えます。それなら実績があります」
シーン、と静まり返るミーティング。
PMが言った。「…OK。それで本当に速くなるんだな？ 信じるぞ」
僕は「はい（Yes）」とだけ答えた。
なぜ、僕はそんな判断をしたのか？
「その場を収めたかったから」
「新しい（けど最適な）アーキテクチャの正当性を、英語で説明しきる自信がなかったから」
「『実績がある』という、誰も反論しにくいカード（＝手抜き）を切りたかったから」
これが、いわゆる**「認知バイアス」**に、僕が完膚なきまでに叩きのめされた瞬間だった。
具体的には、「今ある馴染んだもの」を過大評価し、「新しい挑戦」を避ける**「現状維持バイアス」。そして、プレッシャー下で論理的思考が停止し、「一番早く思いついた（＝手慣れた）安易な策」に飛びつく「利用可能性ヒューリスティック」**のダブルパンチだ。
結果、どうなったか？
言うまでもない。その場は収まったけど、開発は地獄を見た。
レガシーなフレームワークは、今回のプロジェクトの複雑な非同期要件に全く追いつけず、コードはスパゲッティ化。パフォーマンスは一時的に改善したように見えただけで、根本的な解決にはならず、結局、数ヶ月後に僕が泣きながら全てリファクタリングすることになった。チームにも、クライアントにも多大な迷惑をかけた。
もしあの時、僕がプレッシャーに負けず、冷静に「なぜ今の設計が最適なのか」を（たとえ拙い英語でも）論理的に説明できていれば。あるいは、「明日まで」という無茶振りを鵜呑みにせず、「判断にはAとBとCの検証が必要だ」と構造的に反論できていれば。
技術力（C#）だけじゃ、メシは食えない
この手痛い失敗から、僕は心の底から学んだ。
いくらC#の最新機能（.NET 8がどうとか）を知っていても、WPFのDependencyPropertyの仕組みを暗記していても、それだけじゃ「海外のエンジニア」としては二流、いや、三流だということ。
技術力は「弾薬」にすぎない。
その弾薬を、いつ、どこに、どれだけ撃つかを決める「判断力」こそが、エンジニアの価値を決める。
特に、僕らのような設計やアーキテクチャに深く関わるエンジニアにとって、一つの「意思決定」がプロジェクトの生死を分ける。
日本なら、もしかしたらチームや上司が「まぁまぁ」とフォローしてくれたかもしれない。阿吽の呼吸で誰かがサポートしてくれたかもしれない。
でも、海外の現場はもっとドライで、ロジカルだ。
「君の判断（Decision）は、なぜ（Why）ベストなのか？」
これを説明できないエンジニアは、信頼されない。ただのコーダーとして扱われる。
言語の壁、文化の壁、時差。これらは全て、僕らの「冷静な判断力」を奪ってくる強敵だ。頭ではわかっていても、いざプレッシャーがかかると、僕らは簡単に「火事場のクソ判断」に流されてしまう。
このブログで伝えたいこと
だからこそ、僕は決めたんだ。C#やWPFの技術を磨くのと同じくらい、いや、それ以上に「意思決定のスキル」を磨こうと。
これは根性論や精神論じゃない。
**「思考の道具（メンタルモデル）」と「判断の型（フレームワーク）」**を学ぶ、極めてロジカルな「技術」だ。
この記事（シリーズ）では、僕があの地獄のミーティング以来、必死で学び、実践してきた「プレッシャー下で合理的な判断を下すための技術」を、惜しみなくシェアしていきたいと思う。
悪魔のささやき。エンジニアの判断を狂わせる「認知バイアス」トップ3
「起」の記事では、僕が海外の火事場プロジェクトで、プレッシャーと時差ボケと英語の壁に負けて、WPFアプリの設計でとんでもない「クソ判断」をやらかした話をしたよね。
あの深夜ミーティングで、クライアントとPMから（英語で）まくし立てられた瞬間。
僕の頭から「技術的な最適解（MVVMの改善）」は完全に吹き飛んで、「その場を収めるための最悪手（レガシーフレームワークへの逃げ）」に飛びついしまった。
あれから数年、僕は「なぜ、あの時ああなったのか？」を徹底的に研究したんだ。
C#の非同期処理（async/await）のバグなら、デバッガ（Visual Studio）でステップ実行すれば原因がわかる。WPFのXAMLが崩れるなら、Snoop（WPFのデバッグツール）でVisual Treeを覗けばいい。
でも、「判断のバグ」は、目に見えない。
タチが悪いことに、バグってる本人は、その瞬間「それが正しい」と信じ込んでるんだ。
これが「認知バイアス」の本当の怖さだ。
認知バイアスってのは、まぁ平たく言えば「脳みそのクセ」とか「思考のショートカット」のこと。人間が素早く判断するために進化した機能なんだけど、これが現代社会、特に僕らITエンジニアが扱う「複雑な問題」に対しては、とんでもないバグとして機能することがある。
海外の現場は、このバイアスを増幅させる要素（言語の壁、文化の差、スピードの圧力）が満載だ。
今日は、僕が（そして多くのエンジニアが）特に海外の現場でハマりやすい、危険な「認知バイアス」トップ3を、僕の失敗談を交えながら解剖していく。
これを読めば、「あ、これ俺もやったことある…」って、冷や汗をかくかもしれない。でも大丈夫。まずは「敵を知る」ことが、判断力をアップデートする第一歩だからね。
罠その1：「どうせコイツのせいでしょ？」—— 確証バイアス (Confirmation Bias)
これはバイアスの王様だ。
一言でいうと、**「自分が信じたい結論を裏付ける情報ばかりを集め、それに反する情報を無視する」**っていう最悪のクセ。
エンジニアの仕事で言えば、「バグの原因は、絶対に〇〇だ！」と思い込むと、もうそれ以外の可能性が見えなくなるアレだ。
＜海外あるある：WPFパフォーマンスチューニングでの確証バイアス＞
僕が今いるチームでの話。あるWPFアプリ（もちろんC#）で、特定の画面を開くのが異常に遅い、という問題が起きた。
その画面は、僕の同僚（仮にAさんとする。彼はバックエンド出身）が最近追加した機能だった。
Aさんは言った。「うーん、この画面はサードパーティ製のUIコンポーネント（TelerikとかDevExpressみたいなやつね）を多用してるから、きっとこのコンポーネントが遅いんだ」
彼はそう仮説を立てると、そのコンポーネントのドキュメントやフォーラムを漁り始めた。「ほら見ろ、このコンポーネントはパフォーマンスが悪いって書いてあるぞ！」と。
僕はWPFが専門だから、ちょっと気になった。
僕：「ねぇ、Aさん。そのコンポーネント、本当に原因かな？ もしかして、ViewModelからViewへのデータバインディングが、UIスレッドで重い処理をブロックしてない？ または、コンストラクタで同期的にI/O（ファイル読み込みとか）やってない？」
Aさん：「いや、コンポーネントだよ。だって俺のロジックはシンプルだし。まずはこのコンポーネントを標準の（WPFの）ListBoxに置き換えてみよう」
もうね、彼の頭の中では「犯人＝サードパーティ製コンポーネント」で確定してるんだ。
僕の「他の可能性（データバインディングや非同期処理のミス）」という**「反証」は、彼の耳には入らない。**
結果？
彼は貴重な2日間を、UIコンポーネントの入れ替え作業に費やした。そして、パフォーマンスは全く改善しなかった。
結局、僕がデバッガでプロファイルを取ったら、原因はAさんがViewModelのコンストラクタで、同期的に（！）ネットワーク経由で巨大な設定ファイルを読み込んでいただけだった。（おいおい、async/await使ってくれよ…）
なぜこれが海外で怖いのか？
日本では「まぁAさんも思い込んじゃったか。俺が直しとくか」で済むかもしれない。
でも、こっちでは「Aはなぜ反証（僕の指摘）を無視したんだ？」「なぜ2日間も無駄な作業を続けたんだ？」と、彼の**「判断プロセスそのもの」**が厳しく問われる。
言語の壁があると、これがさらに悪化する。
英語で自分の仮説を自信満々に説明されると、非ネイティブの僕らは「うっ…そこまで言うなら、そうなのかも…」と引き下がりがちだ。たとえ技術的に「ん？」と思っても。
確証バイアスは、議論を停滞させ、チームを間違った方向に導く。恐ろしい罠だ。
罠その2：「ここまで来たら、もう引けない…」—— サンクコストの罠 (Sunk Cost Fallacy)
これも強力だ。
**「すでに費やした時間、労力、お金（＝サンクコスト、埋没費用）がもったいなくて、明らかに失敗だとわかっていても、そのプロジェクトや選択をやめられない」**っていう心理。
コンコルドの超音速旅客機が、商業的に大失敗するとわかっていながら開発が続けられたのが、この典型例。「コンコルド効果」とも呼ばれる。
＜海外あるある：自社製フレームワークとWPFの泥沼＞
これは、僕が「起」で話した失敗談の、まさに核心だ。
あの深夜ミーティングで、僕が「レガシーな自社製フレームワークに置き換えます」と言ってしまった時。
実は、あのフレームワークは、僕がジョインする前からプロジェクトの一部で使われていて、すでに多くの問題（パフォーマンス、保守性の低さ）を抱えていることは、チームの誰もが薄々気づいていたんだ。
でも、すでにそのフレームワークを学習するために、何百時間も費やしていた。既存のコードも山ほどあった。
ミーティングで僕が「置き換える」と言った瞬間、PM（プロジェクトマネージャー）の顔が（一瞬だけ）歪んだのを、僕は見逃さなかった。彼も「またあの泥沼に戻るのか…」と本当は思っていたはずだ。
でも、彼はGoサインを出した。
なぜなら、「すでに投資してしまったコスト（時間とコード）」を捨てる決断（＝MVVMの設計をゼロから見直す）よりも、「既存の投資（レガシーフレームワーク）」を使い続ける方が、その場では「合理的に」見えてしまったからだ。
僕も同じだ。プレッシャーの中で、新しいMVVMの設計を英語で論理的に説明し、クライアントを説得する「労力」を払うより、すでに「実績がある（とされている）」古いフレームワークに逃げる方が、精神的にラクだった。
結果は地獄。僕らは「もったいない」という感情のせいで、さらに大きなコスト（リファクタリングの工数、クライアントの信頼失墜）を払うことになった。
なぜこれが海外で怖いのか？
シリコンバレーの有名な標語に「Fail Fast, Fail Often（早く失敗しろ、頻繁に失敗しろ）」というのがある。
これは「失敗を恐れず挑戦しろ」という意味もあるけど、裏を返せば「ダメだとわかったら、サンクコストを無視して、即座に捨てろ（ピボットしろ）」という強烈なメッセージだ。
海外の（特にアジャイルな）現場では、サンクコストに囚われてダラダラと失敗を続けるエンジニアは、めちゃくちゃ評価が低い。「判断が遅い」「ビジネスセンスがない」と見なされる。
「もったいない」は、エンジニアリングの世界では禁句だと思った方がいい。
罠その3：「俺、WPFは詳しいんで（ｷﾘｯ）」—— 専門家の罠（ダニング＝クルーガー効果）
これはちょっと複雑だけど、エンジニアにはめちゃくちゃ多い。
**「自分が得意な分野（例：C#）のことは過信し、逆に知らない分野（例：インフラ、ビジネス要件）のことは過小評価する」**という傾向。
「ダニング＝クルーガー効果」（能力が低い人ほど自分を過大評価する）とも近いんだけど、僕はこれを「専門家の罠」と呼んでる。
＜海外あるある：アーキテクチャ選定での大事故＞
昔の同僚（C#とWPFの神みたいな人）の話。彼は本当に技術力が高かった。
ある時、新しいデスクトップアプリのプロジェクトが立ち上がった。要件は「シンプル。ユーザーがデータを入力して、サーバーに送るだけ」。
普通のエンジニアなら「WPFでサクッと作って、バックエンドはREST APIでいいんじゃね？」ってなる。
でも、彼は神だった。
彼：「いや、このアプリは将来の拡張性を見据えて、**WPFクライアントとバックエンドの間をgRPCで結び、メッセージングはRabbitMQを介して行うべきだ。**データの永続化は（…以下、超絶複雑な技術用語の羅列…）」
チームの若手が（英語で）おそるおそる聞いた。
「あの…そんなに複雑なアーキテクチャ、このシンプルな要件に必要ですか？ 開発コストが爆発しませんか？」
彼は（ちょっとイラっとした顔で）言った。
「君はわかってない。技術的にはこれが最もエレガントな解決策なんだ。（俺は詳しいからわかるんだ）」
これが「専門家の罠」だ。
彼は、自分の得意分野（C#、gRPC、メッセージキュー）の技術を使いたくてたまらない。その技術を使うことが「目的化」してしまっている。
「ビジネス上の要件（＝シンプルに動けばいい）」という、彼の専門外の視点が完全に欠落している。
結局、彼の「技術的にエレガントな」アーキテクチャのせいで、プロジェクトは初期段階で大炎上。シンプルなデータ入力アプリを作るのに、インフラ構築だけで数ヶ月を要した。彼は「こんな簡単な要件も満たせないのか！」とビジネスサイドから詰められ、疲弊して辞めてしまった。
なぜこれが海外で怖いのか？
海外では、エンジニアは「ただコードを書く人」ではなく、「ビジネスの課題を技術で解決するパートナー」として扱われる。
技術的な自己満足（「俺の好きなWPFの最新機能を使いたい！」とか）のために、ビジネスの目的（スピード、コスト）を無視するエンジニアは、ただの「お荷物」だ。
「俺、C#は詳しいんで」という態度は、「俺、ビジネスのことは知りません」と公言しているのと同じ。そんなエンジニアは、海外の多様な専門家が集まるチームでは生き残れない。
「承」のまとめ：まずは「知る」こと。だが…
どうだろう？
「確証バイアス」「サンクコストの罠」「専門家の罠」。
耳が痛い話もあったかもしれない。僕もこれを書きながら、過去の自分の失敗を思い出して胃がキリキリしてる（笑）
僕があの深夜ミーティングでやらかしたのは、まさにこれらのバイアスの合わせ技だった。
「（英語で説明するの面倒くさいし）レガシーフレームワークでいいや」（サンクコストの罠＋現状維持バイアス）
「（俺はこのフレームワークを知ってるから）こっちの方がうまくやれるはずだ」（専門家の罠）
「（クライアントがMVVMにケチつけてきたからムカつく）俺のやり方で押し通そう」（確証バイアス）
これらのバイアスは、無意識（脳のショートカット）だから、厄介なんだ。
でも、こうして「あ、今俺、サンクコストに囚われてるかも」と**気づける（＝メタ認知できる）**ようになったこと自体が、僕にとっての大きな進歩だった。
じゃあ、このどうしようもない「脳のクセ」と、僕らエンジニアはどう戦えばいい？
プレッシャーがかかった修羅場で、「知ってる」だけでバイアスに勝てるほど、現場は甘くない。
大丈夫。そのための「思考の武器」がある。
精神論じゃない、極めてロジカルな「エンジニアリング的思考法」だ。
次の「転」の記事では、僕がバイアスをぶっ壊すために学んだ最強のメンタルモデル、**「第一原理思考（First-Principles Thinking）」**について、ガッツリ語っていこうと思う。
複雑な問題を「それって、要するに何？」と原子レベルまで分解するこの思考法こそ、僕らエンジニアが身につけるべき、最強の判断スキルだ。
お楽しみに。
お前はロケットを作るのか？ 複雑な問題を一瞬で解体する「第一原理思考」
「承」の記事では、僕らエンジニアの合理的な判断をいかに「認知バイアス」が邪魔してくるか、その恐ろしい罠について話した。
- 「犯人はコイツだ！」と思い込む**「確証バイアス」**
- 「ここまでやったら引けない…」と泥沼にハマる**「サンクコストの罠」**
- 「俺、C#は詳しいんで（ｷﾘｯ）」とビジネスを無視する**「専門家の罠」**
僕が深夜ミーティングでやらかした「レガシーフレームワークに逃げる」というクソ判断も、これらのバイアスが見事にフュージョンした結果だった。
「わかった。バイアスの怖さはわかった。でも、どうすりゃいいんだよ！」
「プレッシャーがかかった修羅場で、そんな冷静に『あ、今のは確証バイアスだ』なんて気づけるわけないだろ！」
わかる。マジでわかる。
「バイアスに気をつけよう」なんて精神論は、火事場の前では無力だ。風邪ひいてる人に「気合で治せ」って言うくらい無意味だ。
だから、僕らエンジニアに必要なのは、精神論や根性論じゃない。
必要なのは、バイアスが入り込む隙間さえない、強力な「思考のツール」だ。
それが、今回のテーマである「第一原理思考（First-Principles Thinking）」だ。
類推（アナロジー）は、楽だが危険な「コピペ」だ
突然だけど、イーロン・マスクが有名にしたこの「第一原理思考」って、結局なにか知ってる？
「なんか、物事を根本から考えることでしょ？」
うん、まぁそうなんだけど、それじゃフワッとしすぎてる。
この思考法のスゴさを理解するには、まず、僕ら（人間）が普段いかに「第一原理」で考えていないかを知る必要がある。
僕らは普段、**「類推（アナロジー）」**で考えてる。
- 「前のプロジェクトで、Aというライブラリを使ったらうまくいった。だから、今回のプロジェクトBでもAを使おう」
- 「競合のC社が、Dという機能をリリースした。だから、うちもD機能を作ろう」
- 「あの凄腕エンジニアのEさんが、Fというアーキテクチャを推奨している。だから、Fは正しいんだろう」
これ、全部「類推」だ。
これって、エンジニアの仕事で言えば**「思考のコピペ」**なんだよね。
Stack Overflowからコードをコピペして、なんとなく動けばOK、みたいな。
そのコードがなぜ動くのか、自分のプロジェクトの文脈（コンテキスト）に本当に合っているのか、深く考えない。
類推は、ラクだ。脳のエネルギーを使わないから。
でも、海外の現場で、前例のない複雑な問題にぶち当たった時、この「思考のコピPE」は通用しない。なぜなら、コピペ元の「正解」が存在しないからだ。
僕があの深夜ミーティングで、「（以前のプロジェクトで使った）レガシーフレームワークに置き換えます」と言ったのは、まさにこの「類推」の罠にハマった典型例だ。
- 問題： WPFアプリのパフォーマンスが悪い。
- 類推： 「以前のプロジェクト」で「レガシーフレームワーク」を使ったら「パフォーマンスが出た（と思い込んでいる）」。
- 結論： だから「今回も」レガシーフレームワークを使おう。
ほらね。「なぜパフォーマンスが悪いのか？」という**根本原因（第一原理）**を一切無視して、「前のやり方」というアナロジーに飛びついてる。
「第一原理思考」とは、常識を「原子レベル」まで分解すること
じゃあ、第一原理思考ってのは、なにか。
それは、「類推」の真逆。
物事を、それ以上分解できない「根本的な真実（第一原理）」までドリルダウンして、そこから再構築する思考法だ。
物理学者が「この物質は何でできてる？」と聞かれたら、「鉄です」とは答えない。「鉄原子の集まりです」「いや、それは陽子と中性子と電子が…」と、究極の構成要素まで分解する。それと同じ。
イーロン・マスクが「ロケットは高すぎる」という問題に直面した時、彼はこう考えた。
- 類推（普通の考え）： 「ロケットの相場は数億ドルだ。だから、それより安く作るのは無理だ」
- 第一原理（マスクの考え）：
- 「待てよ。ロケットの『材料』はなんだ？」
- 「アルミニウム、チタン、銅、炭素繊維…」
- 「それらの『市場価格』はいくらだ？」
- 「（計算中…）…あれ？ 材料費だけなら、ロケットの総コストの2%くらいにしかならないぞ」
- 「じゃあ、残りの98%は、材料を『ロケットの形』にするための加工費や人件費、そして過去の常識（類推）で積み上がった『マージン』だ」
- 「結論：材料を安く買ってきて、自社で賢く組み立てれば、コストは1/10以下にできるはずだ」
これが、SpaceXがロケットのコスト破壊を起こした思考の原点だ。
彼は「ロケットとは、こういうものだ」という**常識（バイアス）を疑い、「ロケットとは、金属原子の塊である」という真実（第一原理）**からスタートしたんだ。
あの日の僕が「第一原理思考」を使っていたら（WPFエンジニア編）
じゃあ、この最強の思考ツールを、僕があの地獄の深夜ミーティングで使っていたら、どうなっていたか？
もし、僕がC#とWPFのプロとして、あの場で「第一原理思考」を発動させていたら。
問題： クライアントが「WPFアプリのパフォーマンスが最悪だ」と怒っている。
▼ 僕がやった「類推（バイアスまみれ）思考」
- プレッシャー： PMがイラついてる。クライアントが怒ってる。英語で反論しなきゃ。（焦り）
- バイアス発動： 「早く解決策を出せ」→「俺が知ってる（サンクコスト）一番手っ取り早い策（利用可能性ヒューリスティック）は？」
- 結論（コピペ）： 「（以前使った）レガシーフレームワークに置き換えます！」
- 結果： 死亡。
▼ もし僕が「第一原理思考」を使っていたら
- PM/クライアント： 「パフォーマンスが最悪だ！ どうするんだ！」
- 僕（第一原理ドリルダウン開始）： 「（落ち着け。まず、彼らが言う『パフォーマンスが最悪』とは、具体的になんだ？）」
- 僕： 「『パフォーマンスが最悪』とは、具体的にどの操作をした時ですか？ UIがフリーズする（応答しなくなる）のですか？ それとも、データの表示が遅れるのですか？」
- クライアント： 「このボタンを押した時、アプリが3秒間固まる（フリーズする）んだ！」
- 僕（第一原理レベル1）： OK。問題は「フリーズ」だ。
- 「WPF（というか、ほぼ全てのUIフレームワーク）において、『UIがフリーズする』とは、根本的にどういう現象か？」
- 真実（第一原理）：「UIスレッドが、何か重い処理によってブロック（占有）されている」。これ以外の理由は、絶対にない。
- 僕（第一原理レベル2）：
- 「では、その『重い処理』とはなんだ？」
- 真実（第一原理）： UIスレッドをブロックする重い処理は、**「CPUバウンド（複雑な計算）」か「I/Oバウンド（ネットワーク通信、DBアクセス、ファイル読み書き）」**の2種類しかない。
- 僕（第一原理レベル3）：
- 「（コードを見直す）…あ、このボタンのイベントハンドラ（またはViewModelのCommand）で、同期的に（！）DBからデータを引っ張って、その場で複雑な集計処理をしてるな」
- 真実（第一原理）：「I/Oバウンド（DBアクセス）」と「CPUバウンド（集計処理）」の両方を、UIスレッドで同期的に実行している。 これが犯人だ。
- 僕（第一原理からの再構築＝解決策）：
- 「犯人がわかった。では、『UIスレッドをブロックしない』ための、根本的な解決策はなんだ？」
- 真実（第一原理）：「重い処理（I/OとCPU）を、UIスレッド『以外』のスレッドで実行する」。
- 僕（具体的なC#の解決策へ）：
- 「C#とWPFで、UIスレッド以外で処理を実行し、結果を安全にUIに反映させるための『道具』はなんだ？」
- 道具：
async/awaitだ。（Task.Runを使ってCPUバウンド処理を別スレッドに追い出し、DBアクセスはasync版のAPI（例:ExecuteReaderAsync）を使う）。
導き出される「本当の」結論
見てくれよ。
この「第一原理思考」でドリルダウンした結果、導き出された結論は、なんだ？
「async/await を使って、処理を非同期化する」
だ。
僕がプレッシャーに負けて出した結論、「レガシーフレームワークに置き換える」とは、1ミリも関係ないんだよ。
むしろ、そのレガシーフレームワークが async/await に対応してなかったら、問題はさらに悪化する。
もし、あの場で僕がこの思考法を使えていたら、クライアントとPMにこう言えたはずだ。
「（拙い英語でもいいから）
待ってください。問題の本質を整理します。
第一に、UIがフリーズするのは、UIスレッドがブロックされているからです（← 誰も反論できない真実）。
第二に、調査したところ、原因はDBアクセスと集計処理がUIスレッドを占有していることでした（← 事実）。
したがって、解決策は、フレームワークの変更では『ありません』（← バイアスの否定）。
解決策は、これらの処理を async/await を使って非同期化することです。これなら、UIはフリーズしません（← 第一原理からの合理的結論）。
明日までに、この非同期化を実装したプロトタイプをお見せします」
…どうだ？
これなら、クライアントもPMも納得するしかなかったはずだ。
言語の壁とか、プレッシャーとか、そういう「ノイズ」を全部吹っ飛ばして、「技術的な真実」という土俵で戦える。
「転」のまとめ：分解せよ、さらば道は開かれん
「第一原理思考」は、魔法じゃない。
エンジニアなら誰もが持っているはずの「物事を論理的に分解する力」を、意図的に、極限まで使うための「ツールセット」だ。
常識、前例、権威、思い込み…
僕らの判断を狂わせる「認知バイアス」は、すべてこの「類推（コピペ）思考」から生まれる。
だから、ヤバい問題にぶち当たった時ほど、自問するんだ。
「ちょっと待てよ」
「『そもそも』これは、何でできてる？」
「これ以上分解できない『真実』は、なんだ？」
この「ドリルダウン」こそが、エンジニアをバイアスから解放し、海外のどんな修羅場でも生き残れる、最強の武器になる。
…さて、この強力な武器（第一原理思考）を手に入れたのはいい。
でも、これを「知ってる」だけじゃまだダメだ。
問題は、これを**「どう使うか」**だ。
特に、あの地獄のミーティングのような「高プレッシャー下」で、どうやって思考を整理し、チーム（あるいはクライアント）を「合意」に導くか。
次の「結」の記事では、僕がこの第一原理思考をベースに、実際のプロジェクトで使っている、超具体的な**「意思決定フレームワーク」**について、ついに（やっと）解説しようと思う。
これを知れば、もう「どうしよう…」で思考停止することもなくなるはずだ。
もう「どうしよう」で悩まない。僕が修羅場で使う「爆速・合意形成フレームワーク」
長かったこのシリーズも、ついに最終回だ。
「起」で、僕が海外のプレッシャーに負けてWPFの設計でやらかした「クソ判断」の失敗談を話した。
「承」で、その原因が僕らエンジニアの脳に潜む「認知バイアス」（確証バイアス、サンクコストの罠、専門家の罠）にあることを解き明かした。
そして「転」で、それらバイアスを破壊する最強の思考ツールとして、物事を原子レベルまで分解する「第一原理思考」を紹介した。
あの地獄の深夜ミーティングで、「フリーズする」という現象を「UIスレッドのブロッキング」という第一原理まで分解できていれば、「async/await で非同期化する」というたった一つの正しい答えにたどり着けたはずだ、と。
…でも、ここで一番大事な疑問が残る。
「わかった。理屈はわかった。でも、あの火事場のミーティングで、どうやってそんな冷静に第一原理思考なんて使えるんだよ？」
「クライアントとPMが英語でまくし立ててる中、どうやってその『正しい答え』を説明して、納得させる（合意形成する）んだ？」
そう。
「転」で手に入れた「第一原理思考」は、まだ「弾薬」にすぎない。
それを装填し、狙いを定め、確実に敵（＝問題）を仕留めるための「銃（＝フレームワーク）」が必要なんだ。
今日は、僕があの失敗以来、どんな修羅場でも冷静さを失わず、技術的に最善な判断を下し、かつチーム（PMやクライアント）の合意を得るために実践している、超具体的な「意思決定フレームワーク」を、君だけにこっそり教えよう。
もう「どうしよう…」と頭が真っ白になるのは、これで終わりだ。
C#エンジニアのための「F-O-D-T」意思決定フレームワーク
僕が使っているのは、たった4つのステップで構成される、シンプルなフレームワークだ。
頭文字をとって「F-O-D-T（フォッドティー）フレームワーク」と呼んでる。
- F = Fact（事実）: 「いま、本当に起きていること（＝第一原理）」は何か？
- O = Options（選択肢）: その事実に基づいた「現実的な解決策」は何か？
- D = Decision（決定）: どの選択肢を選ぶか？ 「なぜ」それを選ぶのか？
- T = Tradeoff（トレードオフ）: その決定によって「失うもの（＝代償）」は何か？
これだけだ。
「なんだ、当たり前じゃないか」と思うかもしれない。
でも、人間（特にエンジニア）は、プレッシャーがかかると、このステップのどれかを必ずすっ飛ばす。
僕があの時やらかしたのは、「F（事実確認）」と「O（選択肢の洗い出し）」をすっ飛ばして、いきなり「D（決定）」（＝レガシーフレームワークに逃げる）に飛びついたからだ。
このフレームワークのキモは、必ず F → O → D → T の順番で、自分（とチーム）に問いかけること。
これにより、バイアスが入り込む隙を物理的になくすんだ。
あの地獄のミーティングを「F-O-D-T」でやり直してみる
もし、あの深夜ミーティングで、僕がこのフレームワークを使えていたら、会話はこう変わっていたはずだ。
PM：「おい、パフォーマンスが最悪だ！ クライアントが怒ってるぞ！」
▼ STEP 1: F = Fact（事実の確認）
- 僕（心の声）： （落ち着け。まずは「F」だ。バイアスを排除しろ。「怒ってる」は感情だ。「事実」じゃない。）
- 僕（発言）： 「OK、まず**事実（Fact）**を確認しましょう。『パフォーマンスが最悪』とは、具体的に何が起きていますか？」
- クライアント： 「このボタンを押すと、アプリが3秒フリーズするんだ！」
- 僕（心の声）： （よし、事実ゲット。「UIのフリーズ」だ。「転」でやった第一原理思考を起動する。フリーズ ＝ UIスレッドのブロッキングだ。原因は同期的なI/OとCPU処理だ。）
▼ STEP 2: O = Options（選択肢の洗い出し）
- 僕（発言）： 「ありがとうございます。原因は、UIスレッドでの同期処理にあると特定できました。**選択肢（Options）**は、私が考える限り3つあります」
- Option A: 問題の処理を
async/awaitを使って非同期化する。 - Option B: （僕が逃げそうになった）既存のレガシーフレームワークを使って書き直す。
- Option C:何もしない（現状維持）。（← これも必ず選択肢に入れるのがミソ）
- Option A: 問題の処理を
▼ STEP 3: D = Decision（決定と根拠）
- 僕（発言）： 「私の**決定（Decision）**は、Option A です」
- PM：「Why？（なぜだ？）」
- 僕（発言）： 「なぜなら（根拠）、Option Aだけが、**問題の根本原因（＝第一原理）**である『UIスレッドのブロッキング』を直接解決できるからです。Option Bは根本解決にならず、Option Cは論外です」
▼ STEP 4: T = Tradeoff（トレードオフの明示）
- 僕（発言）： 「ただし、この決定には**トレードオフ（代償）**があります」
- PM：「（身構える）…なんだ？」
- 僕（発言）：
- 「Option A（非同期化）を採用した場合、リファクタリングのために工数が3日ほど必要です。これが短期的な『代償』です」
- 「しかし、もしここでOption B（レガシーFW）を選ぶと、工数は1日（※ウソ）で済むかもしれませんが、根本原因は残ったままなので、将来的に必ずもっと大きなバグと技術的負債を生みます」
- 「我々は、短期的な工数（3日）を取るか、長期的な品質と安定性を取るか、選ぶ必要があります。私は、長期的な安定性を取るべきだと強く推奨します」
「判断力」とは「トレードオフ」を引き受ける覚悟だ
どうだろうか。
ここまで論理的に、事実と選択肢、そして「代償（トレードオフ）」まで明示されて、反論できるPMやクライアントは、まずいない。
もし反論されても、土台は「事実（F）」と「論理（O, D, T）」だから、感情論やバイアスに引きずられることはない。「なぜなら…」と、またこのフレームワークに戻って説明すればいいだけだ。
これが、海外の現場で求められる「説明責任（Accountability）」の正体だ。
僕らエンジニアは、魔法使いじゃない。
どんな選択にも、必ずメリットとデメリット（トレードオフ）がある。
WPFで async/await を使えばコードは複雑になるし、テストも難しくなる。でも、UIのフリーズは防げる。
三流のエンジニアは、バイアスに流されて「なんとなく」決める。
二流のエンジニアは、「メリット」だけを語って自分の好きな技術（専門家の罠）に誘導しようとする。
一流のエンジニアは、「事実」に基づき、「デメリット（トレードオフ）」を隠さずに開示した上で、「それでもこれが最善だ」と論理的に主張できる。
F-O-D-Tフレームワークは、君をその「一流のエンジニア」の土俵に引き上げてくれる。
C#のコーディングスキルやWPFのXAMLテクニックは、そのための「道具」にすぎない。
結び：君の価値は、書いたコードの行数ではなく、下した「判断」の質で決まる
海外で働く、あるいは将来海外を目指すエンジニアの君へ。
君が現場で戦う相手は、バグや技術的課題だけじゃない。最大の敵は、自分自身の「認知バイアス」であり、チームの「曖昧な合意」だ。
もう、プレッシャーに負けて「火事場のクソ判断」をするのは終わりにしよう。
ヤバい問題にぶち当たったら、深呼吸して、F-O-D-Tの4ステップを紙に書き出すんだ。
- Fact: 事実は何か？（第一原理は？）
- Options: 選択肢は？
- Decision: 決定は？ 根拠は？
- Tradeoff: 代償は何か？
この思考の「型」こそが、言語や文化の壁を超えて君を守り、クライアントやチームからの「信頼」を勝ち取るための、最強のサバイバル術だ。
技術力（C#）を磨くのは当たり前。
これからは、その技術を「いつ、なぜ、どう使うか」を決める「判断力」を磨き上げていこうぜ。
君のエンジニア人生が、質の高い「判断」であふれることを願ってる。
ヨーロッパの片隅から、健闘を祈る。
コメント