「コードさえ書ければ無敵」だと思ってた。海外に来る前の俺へ。
やあ、みんな。海外でITエンジニアやってる（しがないC#とWPF使いの）俺だ。
「海外でエンジニア」って聞くと、どんなイメージを持つ？
ピカピカのオフィスで、MacBook Pro片手に（俺は会社のDellだけど）、窓の外の摩天楼を見ながら、同僚と「Hey, What’s up?」なんて言いながら、フリードリンクのスタバのコーヒーをすする…そんな感じ？
まあ、半分合ってるし、半分は全然違う。現実は、レガシーコードのWPFアプリのXAMLと格闘し、C#の謎のTaskデッドロックに頭を抱え、「なんでこのDataContextがnullになるんだよ！」って叫んでる。日本とあんま変わらないな（笑）
でも、この記事を読んでくれてるってことは、君も少なからず「海外で働く」ことに興味があるか、あるいはもう準備を進めている猛者なんだと思う。
素晴らしい。マジで応援してる。
きっと今、必死でコーディングの勉強をしてるんだろうな。LeetCode解いたり、GitHubでイケてるリポジトリ探したり、C#の最新バージョン（.NET 9とか10とか）の仕様を追ったり。
うん、それ、めちゃくちゃ大事だ。
俺も日本にいる時、死ぬほどやった。業務後、土日、通勤中…とにかくコードを書いた。「技術力さえあれば、どこでも通用する」って信じてたから。だって俺たちエンジニアだぜ？世界共通言語の「コード」が書けるんだ。ロジックが俺たちの武器だ、と。
そう。俺は典型的な「エンジニア」だったんだ。
ここで言う「エンジニア」っていうのは、世間一般が思う、あの**「ステレオタイプ」**なエンジニア像のこと。
- 超ロジカル。
- 合理的。
- 感情よりデータ。
- コミュニケーション？いや、仕様書（英語の）が完璧なら不要でしょ。
- 雑談？その時間あったらリファクタリングしたい。
どう？耳が痛い？（笑）
俺は全部当てはまってた。特にC#とWPFっていう、ガチガチのエンタープライズ向けデスクトップアプリ開発をメインでやってきたから、余計にその傾向が強かった。「ロジックの正しさこそが正義」だと。WPFのMVVMパターンが崩れてるコードなんて、芸術への冒涜（ぼうとく）くらいに思ってた。
日本で働いてた時、俺は技術力でチームを引っ張ってる自負があった。C#の非同期処理（async/await）の最適な使い方、WPFのパフォーマンスチューニング、クリーンアーキテクチャの導入…技術的な議論では誰にも負けなかったし、それがエンジニアの価値だと思ってた。
そして、その「技術力」という最強の剣だけを握りしめて、俺は海外に乗り込んできたわけだ。
結論から言うと、その剣、初日で叩き折られた。
いや、正確に言うと、剣はピカピカのままだったんだけど、その剣を振り回しても、誰も俺の言うことを聞いてくれなかったんだ。
忘れもしない、こっちに来て2週目のアーキテクチャ設計ミーティングでのこと。
新しいWPFアプリケーションの基盤設計。俺は日本で温めていた、パフォーマンスと保守性を極限まで高めるためのアーキテクチャ（C#の最新機能とDIコンテナを駆使した、それはもう美しい設計だった）を、自信満々に提案した。
俺「この設計なら、従来のMVVMが抱えるViewとViewModelの密結合を避けつつ、テスト容易性を格段に上げられます。パフォーマンス計測データもこれです。ロジカルに考えて、これがベストプラクティスです」
完璧なプレゼンだった。データも揃ってる。技術的な反論の余地はないはずだ。
シーン……。
ミーティングルームにいる同僚たち（アメリカ人、インド人、中国人、ヨーロピアン…多国籍軍だ）は、なんか微妙な顔をしてる。
最初に口を開いたのは、この道20年のシニアエンジニア、デイブだった。
コーヒーマグ（デカい）を片手に、彼はゆっくりこう言った。
「OK, I get your logic. But… how does the team feel about this?」
（オーケー、君のロジックは理解した。でも…チームはこれについてどう『感じる』？）
……は？
『感じる』？
FEEL？
俺は耳を疑った。エンジニアリングのミーティングだぜ？設計の優劣を決めるところだ。そこに「感情（Feel）」ってなんだよ。バカにしてんのか？
俺は（もちろん英語で）まくし立てた。
「デイブ、これは感情の問題じゃありません。技術的な優位性の問題です。このアーキテクチャは、C#の特性を最大限に活かし、WPFのレンダリングパイプラインにも最適化されています。こっちの方が『正しい』んです」
その時のデイブの顔、今でも覚えてる。
彼は悲しそうに、ちょっとだけ笑って、こう言ったんだ。
「君の案は、技術的には『正しい（Correct）』んだろう。でも、俺たちは『正しい』コードをデリバリーしてるんじゃない。『価値（Value）』をデリバリーしてるんだ」
続けて彼は言った。
「この新しいアーキテクチャを、今のチーム全員が学習するコストは？そのストレスは？スケジュールはタイトだ。チームが『不安だ（feel anxious）』『自信がない（not feeling confident）』と思いながら書いたコードは、どんなに『正しい』アーキテクチャでも、必ずバグを生む。それより、今みんなが慣れていて『ハッピー（feel happy）』な技術スタックで、自信を持ってリリースできる方が、よっぽどビジネスに『価値』がある」
……俺は、頭をハンマーで殴られたような衝撃を受けた。
俺が必死に磨いてきた「技術力」と「ロジック」。
それがいとも簡単に、「チームがハッピーか」という、俺が一番軽蔑していた「感情論」に負けたんだ。
ロジックは完璧だった。
でも、俺は「人」を見ていなかった。
これは、俺が海外に来て最初にぶち当たった、デカすぎる壁だった。
俺たちエンジニアは、無意識のうちに「自分は技術者だ」というステレオタイプに自分を当てはめてしまう。ロジカルであるべきだ、と。
でも、海外（というか、多分日本でもそうなんだろうけど）で働くってことは、そういう「エンジニア」という役割（ロール）を演じることじゃない。技術スタックがC#だろうがPythonだろうが関係ない。
「技術」を持った「人間」として、どうチームに貢献し、どうビジネスに価値を出すか。
それが全てだったんだ。
もし君が、昔の俺みたいに「コードさえ書ければ無敵」「技術力こそが正義」って思ってるなら、マジでこの記事を最後まで読んでほしい。
それは間違いなく君の武器になる。
でも、その武器、「使い方」を間違えると、最強の「鈍器」にしかならない。
俺がこの数年間、ボコボコにされながら学んだこと。
それは、「英語力」みたいな表面的な話じゃない。
C#のasync/awaitを理解するより、WPFのBindingを極めるより、もっともっと大事な、エンジニアが見落としがちな**「ある非技術的な能力」**の話だ。
この記事は、技術オタクだった俺が、どうやってその「エンジニアのステレオタイプ」っていう呪いを解いて、ロジック以外の武器を手に入れたか、その泥臭い実体験の記録だ。
次の「承」では、俺が「ロジカル病」をこじらせた結果、チームでやらかしたもう一つの大失敗と、そこから見えた「気づき」について話そうと思う。
「正しいコード」が「遅いコード」になった日、あるいは「ロジカル・テロリスト」の誕生
「起」を読んでくれてありがとう。
前回のあらすじはこうだ。
「技術力こそ正義」と信じて海外に乗り込んできたC#エンジニアの俺。しかし、アーキテクチャ会議で「技術的な正しさ」を振りかざした結果、「チームがどう『感じる（Feel）』か？」という、まさかの**「感情論」**に完膚なきまでに叩きのめされた。
ロジックが、感情に負けた。
正直、あのミーティングの後は、悔しさと納得できなさで頭がパンクしそうだった。
「なんだよ『ハッピー』って。仕事だぞ？」
「慣れた技術スタック？そんなんだから技術的負債が溜まるんだろうが」
「WPFのDataContextをobject型で引き回してるあのコードの方がよっぽどアンハッピーだろ…」
ブツブツ文句を言いながらも、俺は（しぶしぶ）チームの意向に従った。
そう、俺は「ロジカル病」の重症患者だったんだ。
デイブのあの一件で、少しは「チーム」を意識するようになったか？
答えは、悲しいかな「ノー」だ。
俺はまだ、自分の「技術的な正しさ」を証明することに固執していた。
そして、俺は「起」の失敗とは比べ物にならない、もっと深刻な大失敗をやらかすことになる。
あれは、俺が海外に来て半年ほど経った頃のプロジェクトだった。
既存のWPFアプリケーションの大規模改修。主なミッションは「パフォーマンス改善」だ。起動速度、画面描画速度、データ処理速度…すべてが遅かった。
これは俺の出番だ。
WPFのパフォーマンスチューニングは、俺が日本でも散々やってきた得意分野。C#の非同期処理、WPFのUI仮想化（VirtualizingStackPanel）、DependencyPropertyの仕組み、XAMLのレンダリングパイプライン…。知識は完璧だった。
俺は水を得た魚のようにコードを書き換えていった。
- 重いI/O処理は、徹底的に
async/awaitで非同期化。UIスレッド（Dispatcher）を絶対にブロックさせない。 - どうせやるならと、C#の最新機能をフル活用。
Taskより軽量なValueTaskを使いこなし、LINQの裏で発生する無駄なメモリアロケーションを避けるため、独自の軽量コレクションを実装。 - WPFの
Bindingも、リフレクションを多用する標準のものから、コンパイル時にコード生成する（Compiled Bindings）アプローチに切り替えた。 - コードレビュー（プルリクエスト）も厳格にやった。俺の基準で。「この
async voidはアンチパターンだ」「このLINQは遅延評価を理解していない」「このXAMLのBindingはメモリリークするぞ」
どうだ。完璧だろ？
技術的に、これ以上ないほど「正しい」コードだ。
俺が書いたモジュールは、ベンチマーク上、既存のコードの数十倍のパフォーマンスを叩き出した。
俺は得意満面だった。
「どうだデイブ。これが『ロジック』の力だよ」と。
だが、プロジェクトが進むにつれ、チームの様子が明らかにおかしくなっていった。
まず、開発速度が劇的に落ちた。
最初は気づかなかった。
俺は自分のタスクを最速でこなし、「正しい」コードを量産していたからだ。
問題が起きていたのは、俺以外のメンバーのタスクだった。
俺が作った「超高速・超正しい」共通モジュール。
それを他のメンバーが使う段になって、なぜかバグが頻発した。
- 「あれ、なんか画面が固まる…」（→俺が作った非同期モジュールの「お作法」を知らず、UIスレッドから同期的に呼び出してデッドロックしてた）
- 「データが更新されない…」（→俺が実装した特殊なキャッシュ機構を理解せず、古いデータを参照し続けていた）
- 「プルリクのレビューが、全然Approve（承認）されない…」（→俺が「ロジックが間違ってる」と、ひたすらコメントで指摘し続けていたから）
チームの雰囲気は最悪になった。
特にジュニアやミドルレベルのエンジニアたちは、明らかに俺を避けるようになった。Slackでの質問も来ない。ランチにも誘われなくなった。（まあ、俺も元々あんまり雑談するタイプじゃなかったけど）
そして、ついに決定的な日が来た。
俺が休暇で1週間休んでいる間に、別のチーム（俺たちのモジュールを使ってる）が、俺の書いたコードが原因で、本番環境で致命的なUIフリーズを引き起こしたんだ。
俺が戻ってきた日の午後、マネージャーのサラ（デイブとは別の人）に会議室に呼ばれた。
彼女は、いつも穏やかなのに、その日だけは凍るような表情をしていた。
サラ：「休暇明けに悪いんだけど、あなたが作った非同期モジュールが原因で、クライアントX社の本番システムが止まったわ」
俺：「え？そんなはずは。あのコードは単体テストも通ってますし、ロジックは完璧です。おそらく彼らの『使い方』が間違ってるんですよ」
ほら、出た。
俺の「ロジカル病」だ。
自分は悪くない。自分のコードは「正しい」。悪いのは、それを「正しく」使えなかった周りだ、と。
サラは深く、深いため息をついた。
サラ：「…あなたの言う通り、彼らの使い方は間違っていた。でもね、問題はそこじゃないの」
サラ：「あなたは、**チームの『心理的安全性（Psychological Safety）』**を破壊したの。わかる？」
…はい？
サイコロジカル…セーフティ…？
なんだそれ。心理学の講義か？俺はエンジニアだぜ？
俺がキョトンとしていると、サラは言葉を続けた。
サラ：「あなたのコードは、技術的に素晴らしい。それは認める。でも、難解すぎるの。チームの誰も、自信を持って触れないのよ」
サラ：「あなたはプルリクで、人のコードの『間違い』を徹底的に指摘する。技術的には全部『正しい』指摘なんでしょうね。でも、指摘された方はどう思う？『自分はダメなエンジニアだ』『あの人に質問したら、またバカにされるんじゃないか』って萎縮するのよ」
サラ：「今回の本番障害も、担当したエンジニアは、あなたのモジュールの使い方が不安だった。でも、休暇中のあなたに聞けなかった。周りの誰も助けられなかった。みんな、あなたのコードを『怖い』と思ってるから。…結果、彼らは推測でコードを書いて、見事に地雷を踏んだ」
俺は、何も言い返せなかった。
サラは最後に、決定的な一言を俺に突きつけた。
「あなたの『正しさ』は、チームにとって『恐怖』なのよ」
「今のあなたは、チームの生産性を下げる『ロジカル・テロリスト』よ」
……ロジカル・テロリスト。
重かった。
「起」でデイブに言われた「チームがハッピーか？」より、何百倍も重い言葉が、俺の胸に突き刺さった。
俺は、良かれと思ってやっていた。
C#の高度なテクニックを駆使して、WPFアプリのパフォーマンスを極限まで高めること。それがプロのエンジニアの仕事だと信じていた。
でも、俺がやっていたことは、「俺スゲー」っていう自己満足のオナニーでしかなかったんだ。
俺の「正しい」コード。
それは、チームの誰もメンテナンスできない「技術的負債」そのものだった。
俺の「正しい」レビュー。
それは、チームメンバーの挑戦する意欲と、質問する勇気を奪う「テロ行為」だった。
俺が書いた「正しいコード」は、結果としてチーム全体の開発速度を著しく低下させた。
つまり、俺の**「正しいコード」は、ビジネス全体で見たら「最も遅いコード」**だったんだ。
ロジックだけではダメだ。
技術力だけではダメだ。
デイブが言ってた「感情」。サラが言った「心理的安全性」。
俺たちエンジニアは、コードという「ロジック」を扱っているようで、その実、常に「感情」を持った「人間」と仕事をしているんだ。
俺に決定的に欠けていたもの。
それは、技術力でも英語力でもなかった。
それは、俺が「エンジニアには不要だ」と切り捨ててきた、ある「非技術的な能力」だったんだ。
じゃあ、その「心理的安全性」とやらを担保しつつ、どうやって技術的な品質も上げていくんだよ？
「ロジカル・テロリスト」の汚名を返上するために、俺はいったい何をすべきだったんだ？
次の「転」では、俺がこの絶望的な状況から抜け出すために見つけ出した、あの「非技術的な能力」の正体と、それを鍛えるために始めた、超具体的なトレーニング方法について、余すところなく話そうと思う。
「ロジカル・テロリスト」の俺が、デイブに弟子入りして知った「魔法の言葉」
マネージャーのサラに「あなたはロジカル・テロリストよ」と宣告された日。
あの会議室から自分のデスクに戻るまでの数メートルが、何キロにも感じられた。
デスクに戻って、モニターに映る自分の「完璧な」C#コードを見た。
パフォーマンスのためにValueTaskを使い、Span<T>でメモリアロケーションを極限まで削り、WPFのBindingエラーが出ないようにXAMLを徹底的に最適化したコード。
全部、無意味だった。
いや、むしろ「害」だった。
俺の「正しさ」がチームを「恐怖」させていた。
俺の「技術力」がチームの「心理的安全性」を破壊していた。
……じゃあ、どうすりゃいいんだよ。
技術力を下げるのか？
わざと「間違った」コードを書くのか？
WPFのひどいBindingエラーを見て見ぬふりするのか？
それは違うだろ。俺はプロのエンジニアだ。品質を捨てるなんて本末転倒だ。
技術的な「正しさ」と、チームの「心理的安全性」。
この二つ、両立できねえのかよ……。
頭を抱えて唸っていた俺の視線の先に、一人の男がいた。
デイブだ。
「起」で俺のアーキテクチャ案を「チームがどう『感じる』か？」の一言で却下した、あのシニアエンジニアだ。
正直、あの時は「技術もわかってねえ感情論ジジイが」くらいに思ってた。（本当にごめんなさい）
でも、今ならわかる。彼はあの時、俺が半年かけて気づいた「チームの感情（心理的安全性）」を、最初から見抜いていたんだ。
……盗むしかない。
俺は、プライドをかなぐり捨てて、デイブの「やり方」を徹底的に観察することにした。
彼がどうやって、あの多国籍でスキルもバラバラなチームをまとめ上げているのか。
なぜ、彼のレビューコメントはいつも「Thanks!」で溢れているのか。
なぜ、ジュニアエンジニアたちが、俺には絶対しないようなC#の初歩的な質問（「Task.Runとawaitって何が違うんスか？」みたいな）を、嬉々として彼にしに行くのか。
観察して、数日ですぐにわかった。
デイブは、俺とはまったく違う「武器」を使っていた。
例えば、コードレビュー。
俺のレビュー：「（コメント）ここはasync voidじゃなくてasync Taskにしろ。async voidはクラッシュの原因になるアンチパターンだ」
デイブのレビュー：「（コメント）asyncを使ってくれてありがとう！ところで、ここをasync Taskに変えると、呼び出し元で『完了』を待てるようになるから、もっと安全になると思うんだけど、どうかな？もしasync voidにした理由があったら教えて！」
……全然違う。
俺のは「命令」と「否定」だ。
デイブのは「提案」と「質問」と「リスペクト」だ。
例えば、ミーティング。
ジュニアエンジニアが、WPFのDataContextの仕組みがわからず、トンチンカンなことを言っている。
俺なら、即座に話を遮って「違う。DataContextはビジュアルツリーを継承するDependencyPropertyだ。まずWPFの基本を勉強してこい」と言っていただろう。（最悪だ）
だが、デイブは違った。
彼は絶対に話を遮らない。最後までウンウンと頷いて聞く。
そして、こう言ったんだ。
「なるほど、つまり君は『このデータ（ViewModel）を、どうやってあのボタン（View）に伝えるか』で悩んでるんだね。OK。WPFのDataContextってさ、**『無線LANのルーター』**みたいなもんなんだよ」
……は？ 無線LAN？
デイブは続けた。
「家（Window）のど真ん中に『ルーター（DataContext）』を一個置いておけば、家中のPCとかスマホ（ボタンとかテキストボックス）が、そのルーターに勝手に接続してデータ（ViewModelのプロパティ）をもらいに来るだろ？個別にLANケーブル（コードビハインドでの参照）を繋がなくてもいい。便利だろ？君がやろうとしてたのは、ルーターがない部屋で、スマホを必死に壁に繋ごうとしてる感じかな」
……なんだ、その説明。
技術的には、まったく「正確」じゃない。
DependencyPropertyの継承の仕組みとか、BindingのRelativeSourceとか、そういう重要な概念が全部すっ飛ばされてる。
なのに。
質問したジュニアエンジニアは、**「めちゃくちゃわかりました！！そういうことか！！」**って、顔を輝かせている。
俺は、またハンマーで殴られた気分だった。
俺が必死に守ってきた「技術的な正確性」。
それは、相手を納得させる上でも、チームを動かす上でも、必須じゃなかったんだ。
デイブがやっていたこと。
それは、俺が「エンジニアには不要だ」と切り捨ててきた、あの能力。
それは、「コミュニケーション能力」なんていうフワッとした言葉じゃない。
もっと実践的で、もっとエンジニアリングに特化したスキル。
そう、あれこそが**「技術的翻訳力（Technical Translation Skill）」**だ。
自分の持っている高度な技術知識を、そのまま（生肉のまま）相手に投げつけるんじゃない。
相手の知識レベル、経験値、そして「今、不安に思っているか」「自信を失っていないか」という**「感情」**を読み取り、相手が消化できるレベルまで、完璧に「翻訳」して（＝調理して）差し出す能力。
- C#の
async/awaitを、「料理の『待ち時間』で他の皿洗いをするマジック」と翻訳する。 Taskを、「未来にもらえる『引換券』」と翻訳する。- WPFの
DataContextを、「無線LANルーター」と翻訳する。
俺は「ロジカル・テロリスト」だった。
なぜなら、自分のロジック（専門用語）を、翻訳せずに押し付けていたからだ。
そりゃ、チームは「怖い」し「触れない」よな。
俺は変わることを決意した。
「ロジカル・テロリスト」の汚名を返上するために、俺は今日から「技術翻訳家」になる、と。
具体的に、俺が始めたトレーニングは3つだ。
トレーニング①：「5歳児に説明する」練習（技術的翻訳力の基礎）
まず、自分の専門分野（C#とWPF）の難解な概念を、「技術用語ゼロ」で説明する練習を始めた。
夜、アパートに帰ってから、壁に向かってブツブツ言うんだ。
「いいかい？WPFのDependencyPropertyっていうのはね…えーっと…『みんなで共有できる黒板』みたいなもんでね…」
「C#のTaskっていうのは…『代わりにやっとくよ』って言って渡される『引換券』で…」
最初は全然できなかった。すぐに専門用語を使いたくなる。
でもこれを繰り返すうちに、「物事の本質（エッセンス）」を掴む訓練になった。
トレーニング②：コードレビューを「否定」から「質問」に変える
これが一番効果があったかもしれない。
俺は、プルリク（PR）のレビューコメントの書き方を180度変えた。
- Before: 「この
FirstOrDefault()はダメだ。SingleOrDefault()を使うべき」 - After: 「ここ、
FirstOrDefault()を使ってるけど、データが複数件ヒットする可能性ってあるかな？もし『絶対に1件か0件』なら、SingleOrDefault()を使うと、その『意図』が明確になって、将来のバグを防げるかも！」 - Before: 「この
async voidはアンチパターン」 - After: 「イベントハンドラだから
async voidになるのはわかる！ただ、もし可能なら、中の重い処理をasync Taskを返す別メソッドに切り出して、イベントハンドラからはそれを呼び出す（try-catchも忘れずにね！）形にすると、例外処理がもっと安全になるよ。どう思う？」
「命令」を「提案」に変える。
「間違いの指摘」を「意図の確認」に変える。
そして、必ず「相手のコードの（小さな）良いところ」を一つ見つけて、まず褒めることから始めた。
「この変数名、すごく分かりやすいね！」とか、そんなレベルでいい。
トレーニング③：「あえて『遅い』コードを書く」勇気を持つ
これは苦渋の決断だった。
俺は、自分の「技術的な正しさ」へのこだわりを、部分的に捨てることにした。
チームのスキルレベルを考え、あえて最新・最速のテクニック（ValueTaskやSpan<T>の多用）を封印した。
代わりに、チーム全員が（そして半年後の俺が）一読して理解できる、少し冗長でも「読みやすい」C#のコード（昔ながらのforeachやTask、分かりやすいLINQ）を選ぶようにした。
パフォーマンスが本当にクリティカルな部分は、俺が責任を持ってカプセル化（＝ブラックボックス化）する。
でも、それ以外の9割のコードは、チームの「読みやすさ（可読性）」と「触りやすさ（保守性）」を最優先する。
つまり、**「技術的な最適解」ではなく、「チームにとっての最適解」**を選ぶ勇気を持ったんだ。
この3つのトレーニングを始めて、数ヶ月が経った。
劇的に何かが変わったわけじゃない。
でも、小さな変化が起き始めた。
まず、SlackのDMで、ジュニアエンジニアから質問が来るようになった。
「あの…このWPFのBindingがうまく動かないんですけど…『無線LANルーター』の設定、どこで見るんでしたっけ？」
（よし！メタファーが伝わってる！）
コードレビューで、俺が「質問」形式でコメントすると、相手も「実はこう考えてました…」「なるほど、そっちの方が安全ですね！」と、ディスカッションが生まれるようになった。
そして何より、俺自身が「コードを書くこと」以外の楽しさを見出し始めていた。
自分の知識を「翻訳」して、相手に「伝わった！」瞬間の喜び。
チームメンバーが、俺のアドバイスで自信を持ってコードを書き、成長していく姿を見ること。
それは、一人で完璧なコードを書いていた時には感じられなかった、まったく新しい種類の「達成感」だった。
俺は「ロジカル・テロリスト」から、少しはマシなエンジニアになれたのかもしれない。
この「技術的翻訳力」は、俺のエンジニアとしての価値観を根本から変えた。
そして、この力が、俺のキャリアを想像もしていなかった方向に導いていくことになる。
それは、単なる「C#を書く人」を遥かに超えた、海外で働くエンジニアとしての「本当の価値」を生み出す道だったんだ。
「正しいエンジニア」を辞めた日。俺が手に入れた本当の「価値」
「転」を読んでくれて、ありがとう。
俺の物語も、これで終わりだ。
「ロジカル・テロリスト」とまで呼ばれた俺が、デイブという師匠（と勝手に思ってる）の技を盗み、「技術的翻訳力」という新しい武器を手に入れるために、泥臭い3つのトレーニング（①5歳児への説明、②「質問」レビュー、③あえて「遅い」コード）を始めた。
あれから、数年が経った。
俺は今、どうしているか？
相変わらず、海外でC#とWPFを書いてる。
レガシーコードの海で泳ぎ、async/awaitのデッドロックと戦う日々だ。
それは変わらない。
でも、決定的に変わったことがある。
まず、チームの開発速度が、俺が「遅い」コードを書くようになってから、皮肉にも爆発的に上がった。
なぜか？
理由は単純だった。「ロジカル・テロリスト」がいなくなったからだ。
俺の書くコードは、チームの誰もが一読して理解できるものになった。
俺のコードレビューは、「否定」から「対話」の場に変わった。
結果、プルリクエスト（PR）が俺の手元で止まることがなくなり、レビューの往復も激減した。
そして、バグが劇的に減った。
「承」で書いたような、本番環境での致命的なUIフリーズ。あんな事故は二度と起きていない。
なぜか？
チームの「心理的安全性」が回復したからだ。
ジュニアエンジニアたちが、「こんなこと聞いたらバカにされるかも…」と怯えなくなった。
彼らは、地雷を踏む前に、俺にSlackでDMをくれるようになった。
「すみません、このWPFのBinding、また『無線LANルーター』が繋がらないんですけど…」
「このC#のTask、『引換券』もらったはいいけど、どこで『交換』すればいいです？」
最高じゃないか。
俺は「ロジカル・テロリスト」から、チーム専属の「技術翻訳家」になっていた。
今、俺は、このチームのテクニカル・リードを任されている。
マネージャーのサラ（俺をテロリスト呼ばわりした、あの上司だ）に推薦されたんだ。
推薦理由は、こうだった。
「彼は、チームで一番C#が書けるエンジニア『ではない』。彼は、チームのC#レベルを一番『引き上げられる』エンジニアだからだ」
嬉しかった。
一人で完璧なコードを書いてドヤ顔してた時より、何万倍も嬉しかった。
これから海外を目指す君へ。
さて、この記事を最後まで読んでくれた君に、俺が実体験ベースで伝えたい、たった一つの「人生術」だ。
もし君が、昔の俺のように「技術力さえあれば無敵だ」と思っているなら、その考えの半分は正しいが、半分は致命的に間違っている。
海外（特に欧米）のエンジニアリングチームは、スーパーマン（一人の天才）を求めていない。
彼らが求めるのは、「フォース・マルチプライヤー（Force Multiplier）」だ。
つまり、「チームの戦闘力を何倍にも高められる人」。
君の持っているC#の知識、WPFのスキル、async/awaitの深い理解…それらは「エンジン」だ。強力なF1エンジンだ。
でも、そのエンジンを自分のためだけにふかして、爆音を立てているだけ（＝ロジカル・テロリスト）じゃ、誰も君と走りたくない。
「技術的翻訳力」は、その強力なエンジンを、チーム全体（バス）に搭載し、全員を目的地に運ぶための「OS」であり「ハンドル」なんだ。
俺たちがぶち当たる「エンジニアのステレオタイプ」ってやつ。
『エンジニアはロジックの生き物で、コミュニケーションは苦手』。
あれは、俺たちが勝手に作り上げた「呪い」だ。
本当の意味で「ステレオタイプを破壊する」エンジニアっていうのは、技術力があるのは当たり前。
その上で、誰よりも「人の感情」に寄り添えるエンジニアのことだ。
- チームメイトが今、技術的に何がわからなくて「不安」なのかを感じ取る。
- その「不安」を、ロジック（正論）で殴りつけるんじゃなく、「翻訳（メタファー）」で優しく解きほぐす。
- チーム全員が「ここなら失敗しても大丈夫だ」と「感じる」場所（心理的安全性）を作る。
これこそ、AIがどれだけ進化しても奪えない、エンジニアの核となるスキルだ。
ロジックはChatGPTだって書ける。でも、チームメイトの「不安」を感じ取り、「無線LANルーター」なんていうフザけた（でも伝わる）翻訳は、人間にしかできない。
だから、君に最後のアドバイスだ。
今、必死でC#の勉強をしているだろう。
英語の勉強もしているだろう。
素晴らしい。そのまま続けてくれ。
でも、それに加えて、今日から「技術翻訳家」になるためのトレーニングを始めてほしい。
君の彼女に、君の親に、あるいは近所の子供に、
「C#のTaskって、要するにどういうこと？」
「WPFのBindingって、何が便利なの？」
と聞かれたと仮定して、技術用語を一切使わずに説明する練習をしてみてくれ。
相手が「なるほど、そういうことか！」と顔を輝かせた瞬間。
それが、君が「ロジカル・テロリスト」から「フォース・マルチプライヤー」へと進化する第一歩だ。
ロジックが君を海外への「面接」には連れて行ってくれる。
でも、君を海外で「ヒーロー」にするのは、そのロジックをどれだけ優しく「翻訳」できるか、だ。
「正しいエンジニア」になるな。
「価値あるエンジニア」になれ。
海外の現場で、君に会えるのを楽しみにしてる。
コメント