エリートエンジニア、炎上プロジェクトで「詰んだ」日
やあ、みんな。海外の片隅で、今日も元気にWPFの画面とC#のロジックとにらめっこしてる、しがないITエンジニアです。
「海外で働くエンジニア」っていうと、どんなイメージ？
バリバリ英語で議論して、最新技術をビシバシ使いこなし、週末はヨットハーバーで乾杯…みたいな？
うん、まあ、半分くらいは合ってるかもしれない（ヨットは持ってない）。
でもね、今日はそういうキラキラした話じゃないんだ。
むしろ、俺が「エリートエンジニア（笑）」の鼻っ柱をへし折られ、マジで「詰んだ」と思った日。そして、C#のTask.Runでもawaitでも、WPFの{Binding}でも解決できなかった問題を、まったく別のスキルが解決した「あの日」の話をしようと思う。
これから海外を目指す君、あるいは今まさに海外で壁にぶつかってる君に、ちょっとした「得する情報」というか、「人生術」をシェアしたくてね。
あれは、俺がこっちに来て2年目くらい。
あるクライアント向けの、結構デカい業務アプリケーション（もちろんWPF製）のプロジェクトリーダー的なポジションを任されてた。正直、技術には自信があった。C#の非同期処理？MVVM？任せとけ。WPFの描画パフォーマンス？最適化の鬼だぜ。
俺はロジックで世界を構築するエンジニアだ。
合理性。効率。それがすべて。そう信じてた。
プロジェクトは中盤を過ぎ、デモを繰り返すごとに、なんだか空気がおかしくなってきた。
「なんか違う」「思ってたのと違う」
クライアントから、そんな曖昧なフィードバックが増え始めた。
いやいや、仕様書（Spec）通り作ってますよ？
こっちは、あんたらの要望（しかも無茶振り）を、見事にWPFのXAMLで具現化してるんだぞ？
俺のイライラは、そのままチームの空気になった。
ギスギスしたレビュー。増えるバグ。積み上がる技術的負債。
そして、運命の日。
「最終デモ」と銘打たれた、重役も勢揃いのテレビ会議。
時差のせいで、こっちは早朝。冷めたコーヒーをすすりながら画面を見ると、クライアント側のトップ、仮に「マーク」と呼ぼう、彼の顔が石のように硬い。
デモが始まった。
担当が新機能（俺が設計した、我ながらトリッキーな非同期データロード部分だ）を操作する。
…シーン。
…あれ？
画面が、固まってる。いや、正確には「ローディング中」のグルグルが、永遠に回ってる。
まさかのデッドロック？いや、ローカルでは動いた！なんでだ！
「…またか」
マークの低い声が、スピーカーから響いた。
その瞬間、俺たちのPM（プロジェクトマネージャー）が、早口でまくし立てた。
「あ、いえ、これは稀なケースでして！特定のネットワーク環境下では…」「仕様では、ここのデータ同期はベストエフォートと…」
ああ、もうダメだ。
技術的な言い訳が飛び交う。PMは仕様書（Spec）を盾にし、エンジニアは環境差異を主張する。
「技術的には正しい」
「契約上は問題ない」
でも、クライアイントのマークが、どんどん怒りのオーラをまとっていくのが、画面越しにビンビン伝わってくる。
「もういい！」
マークが叫んだ。
「君たちにいくら払ってると思ってるんだ！こんな動かないガラクタのために！仕様書？それがどうした！俺たちが必要なのは『動く』システムなんだ！」
PMは青ざめ、俺は（やべえ、あのawaitがマズかったか…？）と、必死にコードを脳内デバッグしてた。
完全に「詰み」だ。
会議室（というか、それぞれの自宅のPC前）は、凍りついた。
数秒が、永遠のように感じられる。
誰もが、次の「技術的な言い訳」か「謝罪」の言葉を探していた、その時。
俺は、気づいたら口を開いてた。
自分でも何を言うかなんて、0.1秒前まで考えてなかった。
「マーク。ひとつ、聞いてもいいですか？」
ざわつくチャット欄。俺を見るPMの（お前、何を！？）という目。
「俺たち、根本的に何か勘違いしてるかもしれません」
「もし、この機能が『完璧に』動いたとして…マーク、あなたは『本当に』ハッピーになりますか？」
シーン。
今度は、さっきとは質の違う静寂が訪れた。
え、俺、何言ってんだ？エンジニアが、機能の話じゃなくて「ハッピー」とか言っちゃったよ。
マークは、怒りで吊り上がっていた目を、一瞬だけ見開いた。
「…どういう意味だ？」
「俺は、マークが今、ものすごくガッカリしてるように見えます」
「それは、単にこのグルグル（ローディング）が回ってるからじゃなくて…もっと別の、『期待してた未来』が手に入らないことに対してなんじゃないか？って思ったんです」
「俺たちエンジニアは、仕様書に書かれた『機能』を作ろうとしてた。でも、もしかしてマークが欲しかったのは、『機能』じゃなくて…例えば、この機能で『部下の残業が月5時間減る』とか、そういう『結果』だったんじゃないですか？」
PMが息を呑むのがわかった。
技術的な炎上ミーティングが、一瞬にして哲学問答みたいになってる。
マークは、石のような顔のまま、こっちをじっと見ていた。
そして、数秒後、重いため息とともに、こう言ったんだ。
「…そうだよ、スミス（仮名）。俺が欲しかったのは、それだ」
「俺は、このシステムで、ウチのチームがバカみたいな手作業から解放されることを『期待』してたんだ。でも、出てくるのはいつもバグと、言い訳だけだ」
この瞬間、俺は「勝った」と思ったんじゃない。
「ああ、これだったのか」と、全身の力が抜けるような、それでいて、目の前がカッと開けるような、不思議な感覚に襲われた。
俺が、この絶望的な「詰み」の状況で、無意識に使ったスキル。
それは、C#の知識でも、WPFのテクニックでもなかった。
それは、「相手の感情（Empathy）を読み取り、自分の言葉で『翻訳』する」スキル。
いわゆる「エモーショナル・インテリジェンス（Emotional Intelligence：EQ）」とか、「共感力」と呼ばれるものだった。
俺たちエンジニアは、ロジック（Logic）とファクト（Fact）で戦うように訓練されてる。
でも、人間が、特に海外の多様なバックグラウンドを持つチームやクライアントと仕事をする時、ロジックだけじゃ絶対に越えられない壁がある。
その壁を、俺はこの日、期せずして「感情」というトンカチでぶっ壊したんだ。
「グルグルが回る」というファクト（事実）を議論しても、炎上は悪化するだけ。
「ガッカリしている」というエモーション（感情）を共有した瞬間、俺とマークは、敵対する関係から「共通の問題（＝チームの手作業を減らす）に立ち向かう仲間」に変わった。
この「起」では、俺がエンジニアとして最大のピンチに陥り、技術ではなく「感情を読む」という意外なスキルによって、その突破口を見出した瞬間を語った。
でも、これは始まりにすぎない。
じゃあ、そのスキルって具体的に何なのか？
どうやってエンジニアがそんな「文系的」なスキルを身につけるんだ？
そして、その後の炎上プロジェクトはどうなったのか？
次の「承」では、そのあたりをガッツリ掘り下げていくぜ。
なぜC#より「感情」が重要なのか？ロジカルなエンジニアがEQを学ぶ本当の理由
（「起」のあらすじ：海外クライアントとの炎上プロジェクト。技術的な正論も仕様書も通用しない「詰み」の状況で、俺を救ったのはC#の知識ではなく、相手の怒りの奥にある「感情」を読み解くスキル＝エモーショナル・インテリジェンス（EQ）だった…）
さて、前回の「起」を読んだ、特にエンジニアの君。
たぶん、こう思ったんじゃないか？
「は？ 感情？ EQ？」
「俺の仕事はコードを書くことだ。WPFのXAMLで美しいUIを組み、C#で堅牢なバックエンドを動かすことだ」
「そんなフワッとした精神論で、バグが治るか？納期が守れるか？」
わかる。
わかりすぎる。
俺も、数年前までまったく同じことを思ってたから。
俺たちエンジニアは、いわば「ロジックの獣」だ。
0か1か。trueかfalseか。コンパイルが通るか、通らないか。
曖昧さを徹底的に排除し、合理性で世界を組み上げるのが俺たちの仕事であり、誇りだ。
だから、「C#より『感情』が重要だ」なんて言われたら、「うるせえ、nullでも食ってろ」って思うよな。
でも、ちょっと待ってほしい。
俺は、「C#の勉強なんかやめて、自己啓発セミナーに行け」と言いたいんじゃない。
断じて違う。
俺が言いたいのは、**「君が必死に磨いたC#やWPFのスキルを『本当の意味で』活かしきるために、その土台としてEQが死ぬほど重要になってくる」**ってことだ。
特に、ここ「海外」では。
今日は、なんで俺たちロジカルなエンジニアが、「感情」なんていう一見不合理なものを学ばないといけないのか。
その理由を、俺の実体験（主に失敗談）ベースで、3つのポイントに分けて解き明かしていこうと思う。
理由１：「仕様書（Spec）」は、相手の「期待（Expectation）」の”不完全な翻訳”でしかない
まず、これだ。
俺たちエンジニアは「仕様書」を神だと思うように訓練されてる。
「仕様書にこう書いてある（だから正しい）」
「仕様書に書いてない（だから俺のせいじゃない）」
これが、プロジェクト炎上の第一歩だ。
「起」で話したクライアント、マークを思い出してほしい。
俺たちは、マークと合意した（はずの）仕様書通りに、完璧な（はずの）WPFアプリを作っていた。
でも、マークはブチギレた。
なぜか？
マークが欲しかったのは、仕様書のチェックボックスが埋まることじゃなかった。
彼が本当に欲しかったのは、「部下の残業が月5時間減る」という**『未来』であり『期待（Expectation）』**だったんだ。
でも、その「期待」は、PMやコンサルタントを経由して「仕様書」というドキュメントに翻訳される過程で、必ず劣化する。情報が欠落する。
「期待（曖昧で、感情的）」 → （翻訳） → 「仕様（ロジカルで、具体的）」
俺たちエンジニアは、翻訳後の「仕様」だけを見て仕事をする。
C#のコードは、仕様書に書かれたstringやintしか受け取れない。クライアントの「不安」や「期待」なんていうobjectは、そのままじゃコンパイルエラーだ。
でも、考えてみてくれ。
特に俺たちが作ってるようなWPFの業務アプリ。
ユーザー（クライアント）は、その画面を見るまで、自分が本当に何が欲しかったのか、わかってないことのほうが多い。
「うーん、なんか、ここ、もっとこう…シュッと動いてほしいんだよね」
（シュッ、とは！？ async/awaitで非同期にしろってことか？それともAnimationを使えと！？）
ここでロジックだけで戦うエンジニアは言う。
「『シュッと』の定義を明確にしてください。仕様に落とし込んでください」
これが、日本国内ならまだいい。
「まあまあ、阿吽の呼吸で」とか「ちょっと飲みにいきましょう」で解決（先送り）できるかもしれない。
でも、海外ではこれが致命傷になる。
文化も言語も違う相手とのコミュニケーションで、「行間」なんて読めるわけがない。
だからこそ、俺たちは余計に「書かれたロジIC（＝仕様書）」に依存してしまう。
結果、どうなるか？
**「仕様書通りだけど、誰もハッピーにならないクソシステム」**の爆誕だ。
EQ（共感力）が高いエンジニアは、ここで一歩踏み込める。
「シュッと、ですか。もしかして、今このボタンを押した後の『待ち時間』がストレスになってます？ 例えば、〇〇さんがこの機能を使う時って、一番焦ってる時なんじゃ…？」
仕様（What）の裏にある、相手の感情や背景（Why）を探る。
これができると、クライアントは「こいつ、わかってる！」と信頼してくれる。
たとえ、その「シュッと」が技術的にクソ面倒なWPFの描画スレッドの問題だったとしても、「わかってくれてる」相手からの依頼なら、エンジニアだって「いっちょやったるか」って気になるだろ？
仕様書は「最低限の要求」。
相手の「期待」は「真のゴール」。
そのギャップを埋めるのが、ロジックじゃなくて「感情」を読むスキルなんだ。
理由２：チーム開発は「コード」ではなく「人間」が動かしている
次にこれ。当たり前すぎる話だけど、見失いがちな真実だ。
君は、自分のC#スキルに自信がある。
WPFで、クリーンアーキテクチャに基づいた、完璧なMVVMパターンを設計した。
Dependency Injectionもバッチリ。単体テストもカバレッジ100%。
「さあ、お前ら（チームメンバー）、この完璧な設計通りにコードを書け！」
…で、チームは動くか？
動かない。
特に、海外の多様なバックグラウンドを持つチームは、絶対に「正しいロジック」だけじゃ動かない。
- ジュニア（新人）のA君は、君の「完璧な設計」を見て、プレッシャーで萎縮してるかもしれない。「こんな難しいことできない…」
- インド出身のBさんは、君の指示が自分の経験（前の会社でやってた別のやり方）と違うから、内心「非効率だ」と不満に思ってるかもしれない。
- ベテランのCさんは、「また若造が新しいことやりたがって」と、静観してるかもしれない。
全員、口では「OK, Boss」って言う。
でも、内心はバラバラ。不安、不満、疑念。ぜんぶ「感情」だ。
この「感情」を無視して、「ロジック（設計書）」だけを振りかざすとどうなる？
コードレビューは、揚げ足取りの「間違い探し」になる。
「ここの命名規則、規約と違いますね（ﾆﾁｬｱ）」
「なんでTask.DelayじゃなくてThread.Sleep使ってるんですか？（怒）」
ロジックで殴り合うと、チームは疲弊する。
バグは減るかもしれないが、誰も新しいことに挑戦しなくなり、チームの生産性は地に落ちる。
じゃあ、EQが高いリーダー（エンジニア）はどうするか？
まず「相手の感情」をケアする。
- A君には「この設計、難しく見えるかもだけど、一番大事なのは〇〇の部分だけだから。そこ、一緒にやってみようか」と不安を取り除く。
- Bさんには「君の国のやり方もぜひ聞きたい。俺の設計とどっちがこのプロジェクトに合うか、ディスカッションしない？」とリスペクトを示す。
- Cさんには「ベテランのCさんの目で見て、この設計の『リスク』ってどこにあると思いますか？」と知見を借りる。
やってることは、ただの「コミュニケーション」に見えるかもしれない。
でも、本質は「相手の感情（不安、プライド、経験）を認識し、尊重する」というEQの技術だ。
海外で働くってことは、自分とまったく違う「当たり前」を持つ人たちと、共通のゴール（＝WPFアプリの完成）を目指すってことだ。
その時に必要なのは、C#の文法よりも、「こいつ（俺）のために一肌脱ごう」と思わせる「信頼残高」だ。
その信頼残高を貯める唯一の方法が、EQなんだよ。
理由３：エンジニアの市場価値は「技術」x「人間理解」で決まる
最後の理由。これが一番、君の「得する情報」＝「人生術」になるかもしれない。
はっきり言おう。
「C#でWPFの画面が作れます」
「async/awaitが理解できます」
こんなエンジニア、世界中に（それこそ、日本より人件費が安い国に）ゴマンといる。
悲しいけど、技術（What）だけで差別化できる時代は、もう終わりつつある。
最近じゃ、AI（ChatGPTとかGitHub Copilot）が、そこらの凡百なエンジニアよりよっぽど綺麗なコードを書く。
俺たちがWPFの面倒なデータバインディングで悩んでる間に、AIは爆速でコードを生成してる。
じゃあ、俺たち人間のエンジニアの価値って、どこにある？
それが、**「AIにはできないこと」**だ。
AIは、C#のコードは書ける。
でも、AIは、ブチギレてるクライアント（マーク）の「怒りの奥にある本当の願い」を察することはできない。
AIは、不安で手が止まってるジュニア君の背中を押す、温かいコードレビューはできない。
AIは、「仕様書に書いてないけど、こっちのほうが絶対にユーザーは喜ぶ」という「おせっかい（＝共感）」はできない。
これからの時代、エンジニアの価値は、掛け算で決まる。
市場価値 ＝ 技術力（C#/WPF） × 人間理解力（EQ）
技術力が100点でも、EQが0.1点（＝相手の感情を無視してロジックで殴る）なら、価値は10点だ。
技術力が70点でも、EQが10点（＝相手の期待を読み、チームを動かせる）なら、価値は700点になる。
俺たちが海外で、高い給料をもらって、C#やWPFなんていう（ある意味、ちょっとレガシーな）技術で戦い続けるためには、この「人間理解力（EQ）」っていう、もう一つの武器を磨くしかないんだ。
C#のTaskは、非同期処理を「待機（await）」できる。
エンジニアのEQは、相手の「言葉にならない言葉」を「待機」し、受け止める技術だ。
どっちも、これからのエンジニアにとって、必須の「技術（スキル）」だと思わないか？
「わかった、わかった。EQが大事なのはもういい」
「で、具体的にどうやるんだよ、と」
「炎上プロジェクトで、お前は具体的に『何をした』んだ？」
そう焦るなよ。
次の「転」では、俺がまさにあの「詰んだ」プロジェクトで実践した、超具体的で、君が明日から使える「エンジニアのためのEQ実践ステップ」を、余すところなく解説する。
これは、ただの精神論じゃない。「技術」の話だ。
炎上PJTで実践した「共感」の技術。明日から使える3つのステップ
（「承」のあらすじ：海外でエンジニアが生き残るには、C#の技術力と「EQ（人間理解力）」の掛け算が必須だ。技術だけではクライアントの「期待」に応えられず、チームも動かせない。じゃあ、具体的にどうすりゃいいんだ？…）
お待たせ。
ここからが、このブログで一番「得する情報」だ。
「EQが大事とか、共感がどうとか、わかったよ」
「でもな、俺たちはエンジニアなんだ。もっと具体的に、public static void Main()から教えてくれ」
その気持ち、痛いほどわかる。
俺も「感情」なんていうフワッとしたものを、どう「実装」すりゃいいんだよ、って長年思ってた。
だから、俺があの炎上プロジェクト――クライアントのマークがブチギレた「あの日」の直後に、**ガチで実践した『技術』**を、3つのステップに分けて、そのままコード（手順）化する。
これは精神論じゃない。
WPFの画面遷移を設計するのと同じくらいロジカルな、**「対人関係デバッグ」**の技術だ。
ステップ１：【停止】ロジックで殴り合うな。「感情」を先にawaitしろ
あの凍りついたデモ会議（起を参照）の後、俺はすぐにPMに頼んで、クライアントのマークと、俺（エンジニア代表）だけの、1対1のミーティングをセットしてもらった。PMは「技術的な説明を…」とか言ってたけど、「いや、これは俺にやらせてくれ」と押し切った。
会議が始まる。画面越しのマークは、まだ怒ってる。
さあ、ここで普通の（＝昔の俺）エンジニアがやる「最悪手」は何か？
「マーク、先ほどのバグ（デッドロック）の原因がわかりました！あれは非同期処理のコンテキストが…」
ダメだ、絶対。
相手が「怒り」や「失望」という感情に包まれてるときに、こっちから「ロジック（技術的正論）」を投げても、それはただの「火に油」だ。
相手からすれば、「俺はこんなに困ってるのに、こいつはまだ技術の言い訳か！」としか思われない。
だから、俺が最初にやったこと。それは、**「相手の感情を、そのまま受け止めて、言葉にする」**ことだ。
俺：「マーク、時間ありがとう。…正直に言うと、昨日の俺たちのデモは、クソだった」
マーク：「…（眉をひそめる）」
俺：「もし俺がマークの立場だったら、あんなもの見せられたら、激怒してる。期待してた分、失望もデカい。昨日は、本当に申し訳なかった」
ポイントは、「バグがあってすみません」じゃない。
「（あなたが）ガッカリしたであろうその気持ち、わかります」と、感情（Empathy）にフォーカスすることだ。
相手が感情的になっている時は、まずその感情の嵐が過ぎ去るのを「待機（await）」しなきゃいけない。
こっちがロジックで反論（throw new Exception()）した瞬間、すべてがクラッシュする。
まず、相手の感情を「true」だと認める。そこからしか、デバッグは始まらない。
ステップ２：【深掘り】「人間の5 Why」で、真のExceptionを探れ
相手の感情（怒り）のトゲを、ステップ1で少し抜いた。
マークは、ふう、とため息をついた。「…そうだよ。本当にガッカリした」
さあ、ここからが本番だ。
多くのエンジニアはここで「では、どう修正しましょうか？」と、すぐ**「How（どうやって）」**の話に行きたがる。
これも「罠」だ。
俺たちはまだ、**「本当の問題（Why）」**を特定できていない。
トヨタの「なぜなぜ5回」を、コードじゃなくて「人間」に対してやるんだ。
俺：「マークが昨日、一番ガッカリしたのは、どの瞬間だった？」
マーク：「そりゃ、あのグルグル（ローディング）が止まらなかった時だ」
俺：「（なぜ1）あのグルグルが止まると、マークにとって『何が』一番マズい？」
マーク：「…ウチの部下が、それ（新機能）を使えないからだ」
俺：「（なぜ2）それ（新機能）が使えないと、『何が』困る？」
マーク：「…結局、古いExcelで手作業するしかないからだ」
俺：「（なぜ3）その手作業が続くと、『何が』起きる？」
マーク：「…来月の繁忙期、あいつらがまた徹夜することになる。もうウンザリなんだよ！」
見えたか？
俺たちが対処すべきだったException（例外）は、「async処理のデッドロック」じゃなかった。
真のExceptionは、**「部下に徹夜させたくない」というマークの切実な『想い（感情）』**だったんだ。
デッドロックは、その「想い」を阻む、数ある障害（バグ）の1つに過ぎなかった。
もし俺がデッドロックだけを光の速さで直しても、他の部分が使いにくくて結局Excel作業が残ったら、マークは絶対に満足しなかった。
「どう直すか（How）」の前に、「なぜ彼は怒ってるのか（Why）」を、しつこく掘る。
C#のコードでNullReferenceException（ヌルぽ）を見つけるのと同じくらい、執拗にだ。
ステップ３：【再構築】「仕様書」を捨て、「共通のゴール」で再Commitしろ
本当の問題が「部下の徹夜をなくすこと」だとわかった。
ここまでくれば、もう俺とマークは「敵」じゃない。「共通の敵（＝徹夜作業）」と戦う「仲間」だ。
ここで俺が取った、最後の、そして最強の行動。
それは、**「仕様書を（一時的に）捨てる」**ことだ。
俺：「マーク、わかった。俺たちのゴールは『仕様書を終わらせること』じゃない。『マークの部下からExcelを奪い取ること』だ」
マーク：「…（ニヤリ）いい表現だ」
俺：「（仕様書を見せながら）正直に言う。この仕様書通りに全部作っても、たぶんExcelはなくならない。ここの機能、複雑すぎる」
マーク：「…だろうな」
俺：「だから、取引しよう。この仕様書の機能『10個』、俺の独断で『凍結（実装しない）』する。その代わり、部下の人たちが一番Excelで時間食ってる作業『トップ3』を今から教えてくれ。**それだけを、来週までにWPFで動く『何か』**にして持ってくる」
PMが聞いたら卒倒しそうな提案だ。
エンジニアが勝手に仕様を削り、勝手なマイルストーンを置いている。
でも、これが「効く」。
なぜなら、ステップ2で掘り当てた**「相手の本当の痛み（Why）」に対して、「最速で価値を届ける（How）」**というコミットメント（約束）だからだ。
ロジック（仕様書）で戦うのをやめ、相手の感情（痛み）に寄り添い、共通のゴール（徹夜撲滅）を設定し、そのための具体的な「次のアクション（Next Action）」を提示する。
これが、俺がやった「対人デバッグ」の全貌だ。
技術的な炎上は、技術で解決しようとすると悪化する。
人間が起こした問題は、人間の「感情」をデバッグすることでしか、根本解決できないんだ。
この後、どうなったか？
もちろん、俺はチームのメンバー（彼らにもEQを発動して事情を説明し、協力を仰いだ）とクソみたいに働いて、翌週、約束通り「Excel撲滅プロトタイプ（WPF製）」をマークの部下に見せた。
彼らが「おお…！」と声を上げた瞬間、このプロジェクトは「炎上」から「再生」に変わった。
「技術（C#）」は、その最後の「再生」のフェーズで、初めて本当の輝きを放つんだ。
さあ、残すは「結」。
この経験を経て、「コードは世界を変えない」という、ちょっと生意気な結論に至った俺の「人生術」の集大成を、最後に語らせてほしい。
コードは世界を変えない。でも、「感情」を理解したエンジニアは世界を変えられる
（「転」のあらすじ：炎上PJTの根本原因は「デッドロック」ではなく、クライアントの「部下を徹夜させたくない」という『想い』だった。俺はロジックで戦うのをやめ、①感情でawaitし、②人間の5Whyで深掘りし、③共通のゴールで再Commitする、という「対人デバッグ」技術で、プロジェクトを再生させた…）
さて、長い話に付き合ってくれてありがとう。
海外の片隅で、今日もWPFのXAMLをいじってる、しがないエンジニアの「炎上鎮火物語」は、これでおしまいだ。
「起」で詰んだあの日から、「承」でEQの重要性に気づき、「転」で具体的なテクニックを実践するまで。
俺は、この一連の経験から、エンジニアとして、いや、ひとりの人間として、クソでかい「気付き」を得た。
それが、今日のタイトルだ。
「コードは世界を変えない」
…おいおい、待てよと。
「俺たちエンジニアは、コードで世界をより良くするために（以下略）」
「お前だって、C#とWPFでクライアントの問題を解決したんだろうが」
そう言いたいよな。
もちろん、最終的にマークの部下たちのExcel作業をなくしたのは、俺とチームが書いたC#のコードであり、WPFの画面だ。それは間違いない。
でも、考えてみてほしい。
もし俺が、あの「詰んだ」会議の後、あのデッドロック（Taskのawaitの問題だった）だけを必死に直して、「ほら、仕様書通り動きましたよ！」とドヤ顔で報告していたら？
プロジェクトは、たぶん「成功（仕様書通り）」という判子だけ押されて、納品されていただろう。
そして、そのWPFアプリは、**「なんか使いにくいし、遅いし、俺たちの本当に欲しい機能じゃない」**と現場でソッポを向かれ、結局みんなExcelを使い続け…誰もハッピーにならない「動くゴミ」として、サーバーの片隅でホコリをかぶっていたはずだ。
コードは、書かれただけじゃ、何も変えられない。
それはただのテキストだ。
それは、public static void Main()から始まる「命令」の羅列でしかない。
じゃあ、何が世界を変えるんだ？
それは、「感情」を理解したエンジニアだ。
「部下を徹夜させたくない」というマークの**『痛み』。
「この面倒な作業から解放されたい」という現場の『切望』**。
その「感情」に、俺が「共感（Empathy）」し、それを「技術（C#）」で解決しようとCommitした、その『意志』。
それこそが、プロジェクトを動かし、クライアントを動かし、最終的に「徹夜」というクソみたいな現実を変えたんだ。
俺たちエンジニアは、ともすれば「技術」に恋しすぎる。
新しいフレームワーク、美しい設計（MVVM！）、効率的なアルゴリズム。
それ自体は素晴らしいことだ。俺も大好きだ。
でも、俺たちが作ってるのは、自己満足の芸術品じゃない。
（少なくとも、俺たちが作ってるC#/WPFの業務アプリは）
「人間」が使う、「人間」の「面倒くさい」とか「辛い」とか「もっと楽したい」っていう、ドロドロした「感情」を解決するための道具だ。
AIがどれだけ進化しても、ChatGPTがどれだけ流暢なコードを書けても、ここの領域は、まだ人間のエンジニアに残されてる。
ブチギレてるクライアントの、言葉にならない「本音」を読み解くこと。
不安で手が止まってるジュニアの「恐れ」に寄り添うこと。
これらは、AIにはデバッグできない、最高にクリエイティブで、最高に「人間臭い」仕事だ。
■ 俺たちエンジニアが、本当に「得する」人生術
ここまで読んだ君に、俺からの最後の「得する情報」を渡したい。
これから海外で働こうと思ってる君。
今まさに、海外の訳わからん仕様と、文化の壁にぶち当たってる君。
C#の勉強も、WPFのBindingの理解も、英語の学習も、もちろん死ぬほど大事だ。
でも、もし君が「その他大勢の、ただコードが書けるエンジニア」で終わりたくないなら。
AIに仕事を奪われたくないなら。
そして、どうせなら、クライアントからもチームからも「君がいてくれて、本当に良かった」と本気で感謝されるエンジニアになりたいなら。
今日から、ロジック（技術）で人を殴るのをやめてみないか？
コードレビューで、相手の「間違い」を指摘する前に、相手が「なぜ」このコードを書いたのか、その「意図（感情）」を想像してみる。
クライアントの「無茶振り（仕様変更）」にキレる前に、相手が「なぜ」今になってそんなことを言い出したのか、その「背景（不安）」を聞き出してみる。
俺たちの武器である「C#」や「WPF」は、研ぎ澄まされた刃だ。
でも、その刃を、誰の「どの問題」に向けるのか。
その「照準」を合わせるスキルこそが、「EQ（エモーショナル・インテリジェンス）」なんだ。
照準（EQ）がズレてたら、どんなに強力な武器（C#）を振り回しても、敵（真の問題）には当たらない。
C#のコードは、世界を変えるための「手段」だ。
でも、「世界を変えたい」と願う人間の「感情」こそが、すべての始まりなんだ。
俺は今日も、WPFの画面の向こう側にいる「人間」の顔を思い浮かべながら、awaitを打つ。
コメント