「それ、僕の仕事じゃないんで」が一番ヤバい。
（サブタイトル：起承転結の「起」）
どうも！海外（現在地はヨーロッパのとある国です）で、かれこれ7年ほどC#とWPFをメインに、デスクトップアプリの設計・開発をやっているITエンジニアです。カジュアルにいきましょう。
さて、突然ですが、皆さんに質問です。
あなたの「武器」って何ですか？
こう聞くと、たぶん9割のエンジニアはこう答えます。
「C#での非同期処理（async/await）が得意です」
「WPFのXAMLなら、複雑なUIでも組めます」
「クリーンアーキテクチャに基づいた設計ができます」
素晴らしい。本当に素晴らしいです。それ、全部「食える」スキルです。
でも、海外で数年間、多国籍チーム（インド、ドイツ、ポーランド、アメリカ…カオスです）にもまれながら働いてきて、ぶっちゃけ思うことがあるんです。
「技術力（ハードスキル）の『差』なんて、すぐ埋まる」
って。
いや、誤解しないでほしいんですが、技術力は「最低限」必要です。C#のTaskもLINQも理解してない人が、いきなり海外で「隠し玉」もクソもない。
でも、ある一定のライン——例えば、「シニアエンジニア」と呼ばれるレベルに達すると、ぶっちゃけ技術力だけで「こいつ、ヤバいな」って差をつけるの、めちゃくちゃ難しくないですか？
みんなGitHub見てるし、みんなStack Overflow読んでるし、みんなカンファレンス動画見てる。キャッチアップの速度がエグいんです、世界は。
じゃあ、何が「差」になるのか。
僕がそれに気づいたのは、ある「大炎上プロジェクト」の真っ只中でした。
あれは3年ほど前。ある重要なクライアント向けの、WPFを使った業務管理ツールの開発でした。僕らのチームはC#のロジック、バックエンドとの連携を担当。UIデザインは別の（イケてる）デザインチームが担当。完璧な布陣でした。
プロジェクトは進み、僕らのC#コードは完璧に動作していました。MVVM（Model-View-ViewModel）パターンに則り、ユニットテストもバッチリ。asyncとawaitを駆使した非同期処理で、データバインディングもサクサク。
「これ、勝ったな」
そう思ってクライアントにデモを見せた瞬間、空気が凍りました。
「…で、これは『何』？ どう使えばいいんだ？」
クライアントの担当役員（技術のことは全く分からない）が、ポツリと言ったんです。
僕らエンジニアチームはパニックです。
「いや、仕様通りです」
「このボタンを押せば、データが非同期でロードされます」
「ここのグリッドは、XAMLでこう定義されていて…」
ダメでした。
技術的な「正しさ」をいくら説明しても、彼らには響かない。彼らが欲しかったのは「俺たちの仕事が“楽になる”ツール」であって、「MVVMで美しく実装されたソフトウェア」ではなかったんです。
デザインチームは「デザインは承認されたものだ」と言い、僕ら開発チームは「ロジックは仕様通りだ」と言い張る。
これぞ、海外あるある。「It’s not my job（それは私の仕事じゃない）」の応酬です。プロジェクトは完全に暗礁に乗り上げました。
その時、です。
もう、会議室の重い空気に耐えられなくなった僕が、ふと、口走ったんです。
「…あの、そもそも、この画面『多すぎ』じゃないですか？」
シーン。
全員が僕を見ます。
「Taku（僕の名前です）、君はC#の担当だろう。UI/UXはデザインチームの仕事だ」と、うちのプロジェクトマネージャー（PM）が目で訴えてきます。
でも、僕は続けました。
「いや、僕、昔（それこそ学生時代）、趣味でバンドのフライヤーとか、同人誌の表紙デザインとかやってたんですよ。全然、プロの領域じゃないんですけど」
僕はホワイトボードの前に立ち、マーカーを握りました。
「ぶっちゃけ、この画面でユーザーが『本当に』やりたいことって、たぶん、この3つだけですよね？ なら、他の機能、全部『隠し』ませんか？ ボタンも、この『デカいの一つ』だけにして」
僕は、WPFの技術的な話（GridがどうとかStyleがどうとか）を一切しませんでした。
代わりに、学生時代に学んだ「視線誘導」の話とか、「色数を減らす」とか、そういう「デザインもどき」の話をしたんです。
それは「C#エンジニア」の仕事ではありませんでした。
それは「WPFデベロッパー」の領域を超えていました。
でも、その瞬間、あの「氷の役員」が、初めて身を乗り出して言ったんです。
「…それだ。なぜ最初からそうしなかった？」
あの会議がターニングポイントでした。
プロジェクトは（紆余曲折ありましたが）大成功。
そして僕は気づいたんです。
あの日、プロジェクトを救ったのは、僕のC#のスキルじゃなかった。僕のWPFの知識でもなかった。
僕の「武器」は、「C#が書けること」と、「（趣味レベルの）デザイン知識があること」の『組み合わせ』だったんだ、と。
これが、僕が今日皆さんに伝えたい「Unlocking Your Own Unexpected Edge（予期せぬエッジ（武器）を解き放つ）」という考え方です。
2025年、そしてそれ以降。
AIがコードを書き、技術がコモディティ化していく世界で、僕らエンジニアが「生き残る」ため、いや、「圧倒的に勝つ」ために必要なのは、純粋な技術力（深さ）だけじゃない。
技術力 × あなただけの「隠し玉（Unexpected Edge）」
この「掛け算」なんです。
あなたの隠し玉は、何ですか？
「学生時代、演劇部でセリフを覚えるのが得意だった」（→異常な記憶力、ドキュメントの暗記力）
「やたらと友達の恋愛相談に乗っていた」（→高度な傾聴力、クライアントの「本当の」要求を引き出す力）
「週末はいつも料理を作っている」（→段取り力、リソース（食材）管理能力）
一見、ITエンジアの仕事と「全く関係ない」こと。
履歴書（レジュメ）には書かないような、自分では「才能」とすら思っていない、その「偏愛」や「趣味」。
それこそが、C#の知識なんかより、よっぽど強力な「差」を生む「最強の隠し玉」かもしれないんです。
このブログシリーズでは、僕がどうやってその「隠し玉」に気づき、どうやってそれを「武器」として磨き、海外の現場で活用してきたのか。
そして、皆さんが自分自身の「隠し玉」を見つけるための、超具体的なステップを、実体験ベースで余すところなくお伝えしていきます。
技術書を読むのは、いったん置いておきましょう。
今日は、あなたの「中」にある、まだ名前もついていない「才能」を探す旅に出かけましょう。
なぜC#エンジニアが「ガチの現場」で無双できたのか。その武器は、技術書には載ってない「共感力」だった。
（サブタイトル：起承転結の「承」）
さて、「起」では僕の「デザインもどき」の知識がたまたま役に立った、という話をしました。
あれは、いわば「ビギナーズラック」みたいなもの。
でも、その経験から僕は「あれ？ もしかして、エンジニアとしての価値って、C#のコードの美しさや、WPFのXAMLテクニックだけじゃないんじゃね？」と、本気で疑い始めたんです。
僕の仕事は、C#とWPFを使ったデスクトップアプリケーションの開発。
その多くは、特定の「業務」で使われる、いわゆる「BtoB」のソフトウェアです。
例えば、工場の生産ラインを管理するシステムだったり、物流倉庫の在庫を管理するツールだったり。
そこには、明確な「ユーザー（使う人）」がいます。
僕らエンジニアは、彼ら「ユーザー」の要望を聞いて、WPFで画面（UI）を作り、C#でロジック（どう動くか）を実装していくわけです。
で、海外（僕のいるヨーロッパの現場）で働いていると、これがまぁ、一筋縄ではいかない。
まず、言語の壁がありますよね。（僕も最初はヒドかった）
それ以上に、「文化の壁」というか、「仕事に対するスタンスの壁」があるんです。
日本だと「阿吽の呼吸」とか「いい感じにしといて」が（良くも悪くも）通じることがありますが、こっちは基本、「仕様書（Spec）に書いてあること」が全て。
「書いてないことは、やらない」
「それは俺の仕事じゃない（Not my job）」
これがスタンダードです。
僕も最初は、その「ドライさ」に憧れていました。
「エンジニアはコードに集中すべき。要件定義はPM（プロジェクトマネージャー）の仕事だろ」と。
で、ある時。
僕は、ある物流倉庫向けの在庫管理アプリ（もちろんC#/WPF製）の改修を担当していました。
ユーザーからの要望は、明確でした。
「在庫一覧（DataGrid）から、特定の条件で絞り込んだデータをCSVでエクスポートする機能が欲しい」
はい、楽勝ですね。
C#エンジニアの皆さんなら、もう頭の中にコードが浮かんでるはず。
WPFのDataGridのItemsSource（データソース）をLINQで絞り込んで、StreamWriterあたりを使ってCSVに書き出すだけ。ちょろいちょろい。
僕はPMが書いた仕様書（「ここにボタンを配置し、押下したらCSVダイアログを開き…」）に基づき、完璧なコードを書きました。async/awaitを使って非同期で処理し、エクスポート中もUIが固まらない（フリーズしない）ように配慮。MVVMのパターンも崩さず、美しく実装しました。
「Taku、完璧な仕事だ！」
PMにも褒められ、意気揚々とリリースしました。
数日後。ユーザー（倉庫の現場マネージャー）から、僕のPM宛に、ブチギレのチャットが飛んできました。
「おい、Taku（僕）が作った機能、クソ遅いぞ！ しかも、このデータ（CSV）じゃ意味ねえよ！ 前より仕事が増えた！ ふざけるな！」
…え？
「クソ遅い」？ そんなはずはない。非同期処理も入れてる。
「データが意味ない」？ 仕様書通りだ。
僕はパニックになりました。
PMは「仕様書通りだって反論しろ！」と言うし、僕も「コードは正しい」としか言えない。
ここでまた、「It’s not my job」合戦が始まるのか…？
もう、あの「炎上会議」はこりごりでした。
僕は、PMに「ごめん、ちょっとだけ時間をくれ」と言い、通訳（英語がまだ怪しかったので）を連れて、その倉庫の「現場」に直接乗り込むことにしました。（当時はまだコロナ前で、オフラインが基本でした）
現場に着くと、倉庫のマネージャー（ブチギレてた張本人）は、僕らを無視して、轟音（フォークリフトの音）の中でデカい声で誰かを怒鳴っています。
…最悪の雰囲気です。
「あの、Takuですけど…」
マネージャーは僕を睨みつけ、こう言いました。
「お前らか。PCの前に座ってるだけの『オフィス組』に、俺たちの何がわかる」
彼は、僕が作ったWPFアプリが動いている、薄汚れたデスクトップPCの前に僕を連れて行きました。
「見ろ。お前の『新機能』とやらを使うところだ」
彼が、僕が実装した「CSVエクスポート」ボタンを、マウスで（思いっきり）クリックします。
すると、僕のローカル環境では3秒で終わっていた処理が、現場のPCでは…
…30秒、経っても終わらない。
「おい、どうなってんだ」
「い、いや、今、非同期で処理してるはずで…」
1分後。
やっとCSVが出力されました。
「で？ このCSVがどう『意味ない』んですか？」
僕は（震えながら）聞きました。
彼はそのCSVファイルを開き、僕に見せつけました。
「このCSV（A）と、こっちの別システム（B）から出すCSVと、さらにこっちの紙（C）のリスト。俺たちは、この3つを『全部』目で見て、突合（とつごう）して、次の発注リスト（D）を作ってんだよ！」
「お前の機能（A）は、確かにデータは出た。だがな、BやCと『データの並び順』が違う！ しかも、Bにしかない『管理番号』が、お前のCSVには入ってない！」
「だから、俺たちは結局、お前のCSVをExcelで開いて、並び替えて、BとCの管理番号を『手入力』で追加して、それからやっと突合（とつごう）してるんだ！」
「わかるか？ お前のせいで、俺たちの仕事は『3ステップ』増えたんだよ！！！」
…頭をハンマーで殴られたようでした。
僕は、C#のコードが正しいか、WPFのUIが固まらないか、MVVMの設計が美しいか…
それ「だけ」を気にしていた。
彼が「なぜ」CSVエクスポートを欲しがったのか。
その「目的」を、僕は一切、理解しようとしていませんでした。
彼が欲しかったのは「CSVファイル」じゃない。
彼が欲しかったのは、「AとBとCを突き合わせて、Dのリストを『楽に』作ること」だったんです。
これが、僕のキャリアにおける「第二の転機」でした。
「起」で学んだ「デザインもどき（＝技術以外の武器）」は、所詮、「どう見せるか」というテクニックでした。
でも、この物流倉庫で学んだのは、もっと根本的なこと。
「相手（ユーザー）が、本当に解決したい『痛み』は何なのか？」
それを、相手の立場に立って、本気で想像する力。
僕は、これを「エンジニア的 共感力」と呼んでいます。
「共感力」なんて言うと、「わかるー」とか「大変だねー」みたいな、フワッとした感情論を想像するかもしれません。
違います。
エンジニアにとっての「共感力」とは、
「ユーザーですら言語化できていない、潜在的な『Why（なぜ）』を、技術的に（ロジカルに）推測し、検証し、解決策を提示する能力」
です。
あの日、僕はブチギレてるマネージャーに、平謝りしました。
「すみませんでした。僕が、あなたの仕事を全く理解していませんでした」と。
そして、僕は「C#エンジニア」としての仕事を、その場で放棄しました。
代わりに、僕は彼の「弟子」になりました。
「マネージャー、すみませんが、今日の午後、あなたの『横』に座らせてください。あなたが、そのAとBとCのCSVと紙を、どうやってDのリストにしているのか、僕に『全部』見せてください」
彼は呆れていましたが、OKしてくれました。
僕は、彼のPC操作、Excelの関数（VLOOKUPを多用してました）、紙に赤ペンでチェックを入れる仕草、ため息の回数…すべてを観察しました。
そして、見えました。
彼が「本当に」欲しかった機能が。
オフィスに戻った僕は、PMに宣言しました。
「あのCSVエクスポート機能、捨てます」
「はぁ！？ Taku、お前、何言ってんだ！」
「代わりに、新しい画面を一つ、WPFで作ります」
僕が作ったのは、こうです。
- 既存のCSVエクスポート（A）のボタンは、押すと「管理番号（Bの情報）」と「並び順（Cのルール）」を自動で付与した「新しいCSV（A’）」を生成するようにC#ロジックを全面改修。
- それだけじゃない。
WPFに新しい画面（Window）を追加。 - その画面には、ボタンが3つだけ。「A’を読み込む」「Bを読み込む」「Cを読み込む」（Cは手入力用の
DataGrid）。 - そして、中央にデカい「突合（とつごう）開始」ボタン。
- これを押すと、C#のロジックが裏で（もちろん
Taskで非同期に）3つのデータを全部マージして、「差分」だけをハイライト表示。 - 最後に、その「差分リスト（＝ほぼ、発注リストD）」をワンクリックで印刷orエクスポートできる。
僕は、ユーザーがやっていた「手作業（VLOOKUPと手入力）」を、C#のコードに「翻訳」しただけです。
これをリリースした時の、あのマネージャーの顔。
最初は「またお前か」と怪訝な顔をしていましたが、新しい画面の動きをデモした瞬間、彼の目が、カッと見開かれました。
「…おい、Taku。これ…」
「はい」
「これ、俺が…俺たちが、毎日3時間かかってやってた作業が…」
「たぶん、5分で終わります」
彼は、僕の手を、油のついたゴツい手で、バチン！！と握りしめてきました。
「…Taku。お前は…お前は、神か」
神、いただきました（笑）
あの日から、僕は「コード書き」であると同時に、「共感者」であると決めました。
技術力（C#, WPF, async/await）は、あくまで「手段」です。
その技術を、「誰の」「どの『痛み』」を解決するために使うのか？
それを見極める「共感力」こそが、僕らを「ただのコード書き」から、「価値を生み出すエンジニア」に変えてくれる「最強の隠し玉」なんです。
じゃあ、その「共感力」、どうやって鍛えるんだよ？
技術書みたいに「教科書」があるわけじゃないだろ、と。
その通り。
だから、僕が実践してきた「超・具体的なトレーニング方法」を、特別に3つ、伝授します。
（これは、僕が海外で、言語や文化の壁を乗り越えるためにも、めちゃくちゃ役立ちました）
エンジニアのための「共感力」ブートキャンプ
1. 「ユーザーの椅子」に座れ（物理）
さっきの僕の失敗談がまさにコレ。
開発者のハイスペックPC（SSD、デュアルモニター、高速回線）の上で動くWPFアプリと、現場のボロボロPC（HDD、低解像度モニター、不安定なWi-Fi）で動くアプリは、もはや「別物」です。
リモートワークなら、「Screen Share（画面共有）」を頼み込み、「あなたの環境で、あなたの操作で、いつもの作業をやってみせて」とお願いする。
ユーザーの「ため息」や「マウスの無駄な動き」にこそ、C#で解決すべき「痛み」が隠されています。
2. 「Why」ではなく「What for（何のため？）」で聞く
「なぜ（Why）この機能が欲しい？」と聞くと、ユーザーは「詰問」されているように感じ、身構えます。
そうじゃなくて、「もし、この機能があったら、何のために（What for） 使いますか？」「それができると、何が 嬉しいですか？」と、「未来のポジティブな体験」を聞き出すんです。
すると、ユーザーは「いやー、これができたらさ、あのムカつく手入力作業がなくなって、早く帰れるんだよね」みたいに、ポロっと「本音（＝目的）」を話してくれます。
3. 「仕様書」の代わりに「業務フロー図」を書く（読む）
僕らエンジニアは「機能」で物事を考えがち。
でも、ユーザーは「業務（流れ）」で生きています。
「このボタンを押したら、このメソッドが呼ばれ…」という「機能仕様」の前に、
「朝、出社したら、まずPC（A）を起動し、次にシステム（B）にログインし…」という、ユーザーの「1日の流れ（業務フロー）」を理解する。
すると、「あれ？ この流れなら、そもそもシステム（B）じゃなくて、僕らのアプリ（C）に最初からこの機能（D）があった方が、絶対早くない？」という、「仕様書の外側」にある「最強の隠し玉（＝改善提案）」が見つかるんです。
C#のTaskを極めるのも、WPFのPrismをマスターするのも、もちろん大事。
でも、その技術を「誰の」「どの『痛み』」に向けるのか。
その「照準」を定めるのが、「共感力」です。
技術（ハードスキル）が「弾丸」なら、
共感力（ソフトスキル）は「照準器」。
弾丸だけ磨いても、当たらなければ意味がない。
海外という戦場で、僕らエンジニアが「最強」であるためには、両方が必要なんです。
…と、ここまで「共感力」サイコー！みたいに語ってきましたが、
実は、僕はこの「共感力」を突き詰めすぎた結果、ある「奇妙な壁」にぶち当たることになります。
「わかる」ことと、「解決できる」ことは、イコールじゃなかったんです。
そして、僕は気づいてしまった。
「技術」と「共感」だけでは、まだ足りない「何か」がある、と。
次回は、僕がこの「壁」を乗り越えるために、なぜかC#の技術書をいったん閉じ、全く別の「ある本」を読み漁るようになった…という、ちょっと「ヤバい」話をしようと思います。
「わかる」と「決める」は、別モノだった。僕がC#の技術書をいったん閉じ、代わりに「哲学書」を読み始めた本当の理由。
（サブタイトル：起承転結の「転」）
「承」で、僕は「共感力」という最強の武器を手に入れました。
ユーザーの「本当の痛み」がわかる。
だから、僕が作るWPFアプリは、いつも「ありがとう！」と感謝される。
C#のコードを書くのが、楽しくて仕方がなかった時期です。
「よし、次のプロジェクトも、共感しまくって、ユーザーを神扱いして、最高のアプリ作っちゃうぞ！」
そう意気込んで乗り込んだのが、全社的な「基幹システム刷新プロジェクト」でした。
僕の担当は、もちろんC#/WPFでのクライアントアプリ開発。
今回は、関わる「ユーザー」が、今までの比じゃありませんでした。
物流倉庫の現場マネージャー（「承」で登場した彼）に加えて、
- 経理部のマネージャー（「データは1円たりとも狂うな。監査に耐えろ」）
- 営業部のエース（「俺は客先（ノートPC）からでも使いたい。動きはサクサクじゃないと死ぬ」）
- 経営企画室の役員（「とにかく全社の売上データ（BI）を、リアルタイムで見たい」）
…はい、地獄の釜が開きました。
僕は、得意の「共感力」を発揮します。
まず、経理部のマネージャーの横に座ります。
「わかります…。監査、大変ですよね。データの『整合性』が命ですよね。WPFのDataGridでの入力チェック、ガチガチに固めましょう。C#側でトランザクションも完璧に組みます！」
マネージャーは満足げです。「Taku、君はわかってるな」
次に、営業部のエースにヒアリングします。
「わかります…。客先で『重い』アプリなんて、使ってられないですよね。OKです。WPFのUIはあえてシンプルに、async/awaitを駆使した非同期処理で、レスポンスを最優先にします。データは『必要な分だけ』裏で読み込みましょう！」
エースはニヤリとします。「話が早いな、Taku」
最後に、役員のところへ。
「わかります…。リアルタイムの『数字』こそが経営のコンパスですよね。承知しました。C#のバックグラウンドTaskで、常に最新データをポーリングして、WPFのダッシュボードに（イケてる）グラフで表示し続けます！」
役員は頷きます。「頼んだぞ」
…さて。
C# / WPFエンジニアの皆さんなら、もうお気づきですね？
彼らの要望、全部「矛盾」してるんです。
- 経理の「整合性（ガチガチのチェック）」と、
- 営業の「速度（サクサクのレスポンス）」は、
- 最悪の「トレードオフ」の関係にあります。
チェックを厳密にすればするほど、サーバーとの通信は増え、アプリは「重く」なります。
- さらに、役員の「リアルタイム性（常時ポーリング）」は、
- 経理の「整合性（ある瞬間の『正しい』数字）」と、
- 営業の「速度（バックグラウンド処理がネットワーク帯域を食う）」の、
- 両方とケンカします。
僕は、どうなったか。
「わかる、わかるよ…」と、全員に共感しすぎた結果、
「何も決められないエンジニア」
になってしまったんです。
会議室で、僕は板挟みになりました。
「Taku、営業の画面はまだか？ 遅いぞ」
「Taku、経理のチェック機能、ロジックが甘いぞ」
「Taku、ダッシュボードの数字が更新されてないじゃないか！」
僕は、全員に「YES」と言ってしまった。
全員の「痛み」に共感してしまった。
その結果、僕が書いたC#のコードは、矛盾した要求を満たそうとした結果、スパゲッティのように複雑怪奇になり、WPFの画面は、あちこちに気を使いすぎた結果、誰にとっても「中途半端」なものになりました。
プロジェクトは、当然、大炎上。
僕は「共感力」という武器を振り回した結果、自分自身を刺し殺してしまったんです。
ここで、僕は（またしても）学びました。
「共感（わかる）」と「決断（決める）」は、まったく別のスキルだ、と。
ユーザーの「痛み」は、所詮「主観」です。
全員の主観的な「痛み」を、すべて同時に取り除くことは不可能です。
じゃあ、どうすればいい？
何が「正しい」判断なんだ？
PM（プロジェクトマネージャー）？ 彼は「全員の要望を入れろ」としか言わない。
僕は、途方に暮れました。
技術書（C#のパフォーマンスチューニングとか、WPFのDI（Dependency Injection）とか）をいくら読んでも、答えは載っていません。
僕に足りなかったのは、「何を優先し、何を捨てるか」を決めるための「羅針盤（コンパス）」でした。
その時です。
僕が（文字通り）技術書を本棚にしまい、なぜか手に取ったのが、いわゆる「哲学書」…というとカッコつけすぎですね。
正確には、「思想」や「原則」に関する本でした。
それは、古代ギリシャのストア派の哲学だったり、
伝説的なデザイナー（ディーター・ラムスとか）の「デザイン10原則」だったり、
あるいは、優れた経営者が書いた「我が社の行動規範（Principles）」みたいな本でした。
僕が知りたかったのは、「どうやってTaskを並列実行するか（How）」じゃない。
僕が知りたかったのは、「『何のため』に、僕らはこのアプリを作るのか（Why）」という、たった一つの「軸」でした。
そして、僕は、自分なりの「エンジニアリング哲学（My Engineering Philosophy、略してMEP）」を、勝手に（！）定義することにしたんです。
僕のMEPは、例えばこんな感じです。
Takuの「エンジニアリング哲学」（MEP）※当時のメモ
- 「個人の快適さ」より、「全体のワークフロー」を優先する。（＝たとえ営業（個人）が「重い」と文句を言っても、経理（全体）の整合性が担保されるなら、そっちを優先する。なぜなら、会社は「ワークフロー」で動いているからだ）
- 「多機能」より、「シンプルさ（学習コストの低さ）」を優先する。（＝WPFで「何でもできる」モンスターアプリを作るな。たとえ役員が「あれもこれも見たい」と言っても、機能は「本当に必要な3つ」に絞れ。使われなければ、存在しないのと同じだ）
- 「その場しのぎ（Quick Fix）」より、「長期的な保守性」を優先する。（＝C#で「汚いコード」を書くな。今、この瞬間、PMに怒鳴られようとも、「この実装は、3年後に必ず『技術的負債』になります。だから、こちらの『正しい設計』でやらせてください」と（データと共に）主張しろ）
…大したこと、書いてないですよね？
当たり前のことです。
でも、この「当たり前」を、自分の中の「憲法」として明文化したことが、僕の「最強の隠し玉」になりました。
次の、あの地獄の会議。
僕は、もう「共感マシーン」ではありませんでした。
「営業部のエース、Aさん。あなたの『速度が命』という気持ち、痛いほどわかります。ですが」
僕は、ホワイトボードに、このプロジェクトの「目的」と、僕の「MEP（のルール1）」を書き出しました。
「このプロジェクトの最大の目的は、『全社のデータ整合性を担保すること』です。したがって、僕は、あなたの『速度』の要求を、意図的に『捨てます』」
シーン。
エースは、カッと目を見開きます。
「ただし」と僕は続けます。
「あなたの『客先で使えない』という痛みは、別の方法で解決します。WPFのフル機能版とは別に、『閲覧専用』の超軽量Webアプリ（当時はBlazorとか使いました）を、僕のチームで『勝手に』プロトタイプ作りました。これじゃダメですか？」
僕は、彼に「共感」した上で、「哲学（ルール）」に基づいて「決断」し、技術（C#）で「代替案」を提示したんです。
エースは、しばらく僕を睨みつけた後、
「…Taku。お前、面白いな。いいだろう、それで進めろ」
役員にも、経理にも、同じように「（僕の哲学に基づいた）決断」と「（技術に基づいた）代替案」をぶつけていきました。
もちろん、全員が100%満足したわけじゃありません。
でも、全員が「Takuは、少なくとも『軸』を持って判断している」と納得してくれました。
プロジェクトは、そこから一気に進み始めました。
「起」で手に入れた「デザイン（見せ方）」
「承」で手に入れた「共感力（痛みの理解）」
それだけでは、まだ足りなかった。
バラバラの「痛み」を、一つの「正解」に導くための「羅針盤」。
それが「哲学（決断する力）」でした。
技術（How） × 共感（What） × 哲学（Why）
この「3つの掛け算」こそが、2025年以降、AIがコードを書きまくる時代に、僕らITエンジニアが提供できる「真の価値」であり、「予期せぬエッジ（Unexpected Edge）」の正体なんです。
あなたの「哲学」は何ですか？
「絶対にユーザーを待たせない（速度こそ命）」ですか？
「絶対にバグを出さない（堅牢性こそ命）」ですか？
「絶対に美しいコードを書く（保守性こそ命）」ですか？
どれでもいい。
でも、その「軸」が、あなたの「決断」を支え、海外のタフな現場で、あなたを「ただのC#エンジニア」から、「信頼できるプロフェッショナル」へと変えてくれるはずです。
さて、これで僕の「武器」は出揃いました。
でも、皆さんはこう思ってるはずです。
「わかった。理屈はわかった」
「でも、Taku、お前だからできたんだろ？」
「私には、デザインの経験も、共感力も、ましてや哲学なんてない」
…そんなことは、絶対にありません。
次回、最終回「結」。
僕が特別だからじゃない。
あなたの中に「必ず」眠っている、あなただけの「隠し玉」を掘り起こすための、
明日から、いや、「今日から」できる、超・具体的なアクションプランを、全部お渡ししようと思います。
あなたの「最強の隠し玉」を見つける、明日からできる3つのアクションプラン
（サブタイトル：起承転結の「結」）
「起承転」で、僕は「技術（How）」に、「共感（What）」や「哲学（Why）」を掛け算することの重要性を話してきました。
これこそが、フック（記事のテーマ）にあった「ホリスティック（全体論的）なアプローチ」です。
C#が書ける。WPFが使える。それは「How（どうやって作るか）」。
でも、AIが台頭するこれからの時代、純粋な「How」の価値は（悲しいかな）相対的に下がっていきます。
じゃあ、僕ら人間の価値はどこにあるのか？
それは、
「**何を（What）**作るべきか？」
「**なぜ（Why）**それを作るべきか？」
を、「決める」ことです。
「承」で話した「共感力」は、「What」を見つける力でした。
「転」で話した「哲学」は、「Why」を決断する力でした。
そして、その「What」と「Why」の源泉こそが、あなたの「隠し玉」…すなわち、
「あなたが、技術（C#）以外で、夢中になれるもの」
に隠されています。
さあ、見つけにいきましょう。
アクションプラン 1：『あなたの「偏愛」マップ』を作る（＝認識する）
まず、PCを閉じてください。
（いや、この記事は読んでほしいんですが）
技術書も、Qiitaも、Stack Overflowも、いったん全部忘れてください。
そして、真っ白な紙（か、テキストエディタ）を用意してください。
そこに、あなたの「スキル」や「職務経歴」を書くのは禁止です。
代わりに、今から僕が言う「質問」に、ひたすら答えて、書き出してみてください。
- Q1. この1年間で、人から「頼まれてもいないのに」、つい語ってしまった「趣味」は？（例：あのキャンプギアの良さ、昨日のサッカーの試合、あのアイドルの凄さ…）
- Q2. 人に「よく相談されること」は？（技術以外で）（例：旅行のプランニング、PCの選び方、人間関係の愚痴、おすすめのレストラン…）
- Q3. 自分の「弱点」や「コンプレックス」だと思っていることは？（例：飽きっぽい、頑固、人見知り、無駄に几帳面（きちょうめん）…）
- Q4. （もし宝くじが当たっても）たぶん、それでも「学び続けてしまう」と思うことは？（例：英語、料理、歴史、筋トレ、コーディング… ※C#でもOK！）
さあ、どうですか？
これを僕は『偏愛マップ』と呼んでいます。
「起」で話した僕の「デザイン知識」は、Q1（学生時代の趣味）でした。
「承」で話した「共感力」は、Q2（昔から、なぜか人の愚痴を聞かされることが多かった）が元です。
「転」で話した「哲学」は、Q3（頑固で、白黒ハッキリさせないと気が済まない）という僕の「弱点」が、裏返ったものです。
大事なことなので、もう一度言います。
あなたの「隠し玉」は、あなたの「職務経歴書」には載っていません。
あなたの「偏愛マップ」の中に眠っています。
「週末は、ひたすらスパイスカレーを作ってる」？
最高じゃないですか。それは「段取り力」と「化学（再現性）」の才能です。
「推しのアイドルの遠征計画を立てるのが生きがい」？
ヤバい。それは「プロジェクト管理」と「予算管理」のプロフェッショナルです。
「MMORPGでギルドマスター（まとめ役）をやってた」？
それ、僕が「転」でぶち当たった「利害関係の調整」そのものです。
まずは、あなたが「何に」異常な熱量（＝偏愛）を持っているのかを、「認識する」こと。
これが、すべて（・・）の始まりです。
アクションプラン 2：『エンジニア語』に”翻訳”する（＝武器化する）
さて、「偏愛マップ」が書けましたね？
でも、そのままじゃ、ただの「趣味人」です。
次のステップは、その「偏愛（隠し玉の原石）」を、僕らITエンジニアの現場で使える「武器」に「翻訳」する作業です。
これは、思考の「筋トレ」です。
「もし、この『偏愛』を、C#エンジニアの仕事に『無理やり』活かすとしたら？」
と、こじつけて考えてみるんです。
いくつか「翻訳」の例を挙げましょう。
- 偏愛：「スパイスカレー作り」
- → 翻訳（エンジニア語）： 「僕は、カレー作りで『プロセス管理』を学んだ。玉ねぎ（A）を炒めるという『重い処理（I/Oバウンド）』の間に、スパG（B）と野菜（C）を切るという『CPUバウンド』な作業を並列で実行する。これは、C#の
async/awaitを使った非同期処理によるリソース最適化と『全く同じ』だ。僕の書くコードは、無駄な『待ち時間』を許さない」
- → 翻訳（エンジニア語）： 「僕は、カレー作りで『プロセス管理』を学んだ。玉ねぎ（A）を炒めるという『重い処理（I/Oバウンド）』の間に、スパG（B）と野菜（C）を切るという『CPUバウンド』な作業を並列で実行する。これは、C#の
- 偏愛：「推しのライブ遠征（プロジェクト管理）」
- → 翻訳（エンジニア語）： 「僕にとって遠征は『プロジェクト』だ。チケット（リソースA）、宿（リソースB）、交通（リソースC）には『依存関係』があり、一つでも欠けると『デプロイ（＝現地到着）』に失敗する。僕は、常に『クリティカルパス（＝絶対にミスれない手順）』を洗い出し、複数の『バッファ（代替案）』を用意する。この『リスク管理能力』は、WPFアプリのリリース計画でも必ず役に立つ」
- 偏愛：「MMORPGのギルドマスター（利害調整）」
- → 翻訳（エンジニア語）： 「ギルド運営は『組織開発』そのものだ。火力（A）が欲しいアタッカーと、安定（B）が欲しいヒーラーの『要求』はトレードオフだ。僕は、その両者に『ギルドの討伐成功（＝プロジェクトの目的）』という『共通のWhy（哲学）』を示し、『決断』を下してきた。これは、『転』でTakuが直面した『営業 vs 経理』の構図と全く同じだ」
- 偏愛：「人見知り（弱点）」
- → 翻訳（エンジニア語）： 「僕は『人見知り』だから、会議で『話す』のが苦手だ。だからこそ、会議の『前に』、誰よりも『書く』。僕が書く『ドキュメント（仕様書、設計書）』は、会議で議論する必要がないほど『完璧』でなければならない。僕の『弱点』が、僕のコードの『保守性』と『可読性』を担保している」
どうです？
バカバカしいと思いましたか？
でも、この「翻訳」作業こそが、「承」の「共感力」と、「転」の「哲学」の「タネ」になるんです。
あなたの「偏愛」は、あなたの「ユニークな視点」そのもの。
その視点こそ、他のエンジニア（技術しか見てない）が気づかない「バグ」や「改善点」を見つける「最強の武器（エッジ）」になります。
アクションプラン 3：『10%の越権行為』を試みる（＝実践する）
さあ、これで「隠し玉」が「認識」され、「翻訳（武器化）」されました。
あとは、どうしますか？
…そう、「使う」んです。
（宝の持ち腐れが、一番もったいない）
でも、いきなり「転」の僕みたいに、会議で「僕の哲学に反する！」なんて叫ぶ必要はありません。（普通に、クビになります）
僕がおすすめするのは、**『10%の越権行為（えっけんこうい）』**です。
「越権行為」とは、つまり「It’s not my job（それは私の仕事じゃない）」の「逆」をやること。
自分の「本来の仕事（C#を書く）」から、「10%だけ」はみ出してみるんです。
- もし、あなたの隠し玉が「デザイン（by 偏愛マップ）」なら…
- 10%の越権： 次の
WPFの画面実装の時、仕様書通りに作る（90%）だけでなく、「（起）の僕みたいに」こっそり、「ここのボタン、色を変えた方が絶対押しやすいです」という「代替案（10%）」を、PMに（ビクビクしながら）提案してみる。
- 10%の越権： 次の
- もし、あなたの隠し玉が「共感力（by 偏愛マップ）」なら…
- 10%の越権： 次の機能開発の時、仕様書を読む（90%）だけでなく、「（承）の僕みたいに」、「すみません、この機能が『本当に』使われる現場の動画（か、画面共有）、見せてもらえませんか？」と、ユーザーの「痛み」を知ろうとする「10%の質問」をしてみる。
- もし、あなたの隠し玉が「段取り力（by 偏愛マップ：料理）」なら…
- 10%の越権： 次のタスク見積もりの時、自分のC#コードのことだけ考える（90%）だけでなく、「このタスク（A）と、あのタスク（B）は、依存関係があるから、先にこっちを潰さないと『手待ち』が発生しますよ」と、チーム全体の「ワークフロー（10%）」について、口を出してみる。
最初は、ウザがられるかもしれません。
「エンジニアはコードだけ書いてろ」と言われるかもしれません。
でも、続けてみてください。
その「10%の越権」が、あなたの「隠し玉」を、現場で「研磨」してくれます。
そして、その「10%」が、一度でも「刺されば」。
（「Taku、お前、神か」みたいな瞬間が来れば）
もう、あなたは「ただのC#エンジニア」じゃない。
「デザイン（あるいは共感、あるいは段取り）の視点を持った、替えの効かないエンジニア」
として、認識されます。
そうなれば、こっちのもの。
あなたの「隠し玉」は、「予期せぬエッジ」から、「誰もが認める最強の武器」に変わるんです。
結論：あなたの「ムダ」こそが、最強の武器だ
僕らは、ITエンジニアとして、常に「効率」や「合理性」を求められます。
C#のコードも、WPFのXAMLも、いかに「ムダ」をなくすかの戦いです。
でも、キャリアにおいて。
特に、海外という「何でもアリ」の戦場で、その他大勢から「突き抜ける」ために必要なのは、
その「効率」や「合理性」の「外側」にある、
あなただけの「一見、ムダなもの（＝偏愛）」
なんです。
このブログシリーズで僕が伝えたかったことは、ただ一つ。
あなたの「技術力」は、あなたの「偏愛」と掛け算された時、初めて「爆発」する。
AIが「How（どう作るか）」の大部分を担う未来は、もうすぐそこです。
僕ら人間のエンジニアの仕事は、「What（何を）」、「Why（なぜ）」を決めること。
その「What」と「Why」の答えは、技術書の中にはありません。
あなたの「偏愛マップ」の中に、あなたの「ムダ」な人生経験の中に、全部眠っています。
さあ、今日、家に帰ったら、
あなたの「偏愛マップ」を書き出してみてください。
それが、あなたの「予期せぬエッジ（Unexpected Edge）」を解き放つ（Unlocking）、最初の「一歩」です。
4回にわたる長い旅路にお付き合いいただき、ありがとうございました！
また次の現場（ブログ）でお会いしましょう！
コメント