そのコード、誰でも書けますよね？— 海外でぶち当たった「Tier 1」の限界
どうも！ 海外の片隅で、今日も今日とてVisual Studioと格闘しております、C#とWPFを愛するITエンジニアです。
いやー、海外でエンジニアとして働くって、響きはカッコいいっすよね。満員電車ゼロ、フレックスタイム当たり前、スタバ片手に（いや、こっちのコーヒーはデカいだけだけど）颯爽とコーディング…みたいな。
実際、そういう面もあります。日本で消耗してた頃に比べたら、働きやすさはガチで上がった。
でもね、この記事を読んでるってことは、あなたも「いつかは海外で」って思ってるか、すでに来てみて「あれ、こんなはずじゃ…？」ってなってるかのどっちかだと思うんすよ。
今日は、そういう「これから海外目指す人」や「海外来たけど伸び悩んでる人」に向けて、特に俺みたいな「Web系じゃない」スキルセット（そう、WPFとかね！）のエンジニアが、どうやって「その他大勢のコーダー」から一歩抜け出すか、っていう超重要な話をします。
これ、多分あんまり誰も言ってくれないけど、知ってると知らないとじゃ、5年後のキャリアがマジで変わる。「知ってよかった」って絶対思うはず。
夢が叶った「後」の、リアルな現実
俺も最初はそうでした。日本でWPF使ってゴリゴリのデスクトップアプリ開発。でも、「このままでいいのか？」って漠然とした不安があって、一念発起して英語勉強して、なんとかこっちの会社のポジションをゲットした。
最初の1年？ そりゃもう地獄でしたよ（笑）。
まず、英語が聞き取れない。会議で何言ってるか半分もわかんないのに、とりあえず頷いて持ち帰る。WPFのXAML（ザムル）の書き方一つとっても、日本で「当たり前」だった書き方（Bindingの書き方とか、MVVMの解釈とか）が、こっちのチームの「常識」とビミョーに違ったりする。
「ああ、ここはINotifyPropertyChangedの実装、Fody（ライブラリ）使って簡略化しないんだ…」とか、「ICommandの実装、RelayCommandじゃなくてDelegateCommand（Prism）で統一してんだな」とか。
そういう細かい「郷に入っては郷に従え」をキャッチアップしつつ、とにかく必死にTaskとawaitを駆使して非同期処理を書きまくり、パフォーマンスチューニングに追われる日々。
毎日が「学習」と「適応」。これが、いわゆるキャリアの**「Tier 1（ティア・ワン）：Learner（学習者）」**フェーズ。
この時期は、ぶっちゃけ「コードが書ければ」よかった。バグを直し、言われた機能を実装する。それだけで精一杯だし、周りも「新しいヤツだから」って多めに見てくれる。
で、2年も経てば、仕事にも慣れるわけです。
英語も（完璧じゃないけど）会議で意見を言えるようにはなる。WPFの設計思想もチームの流儀を理解して、コードレビューでも的確な指摘ができるようになってくる。
「ああ、俺、海外でもやっていけてるわ」
そう思った矢先でした。デカい「見えない壁」にぶち当たったのは。
その日、俺は「便利なコーディング要員」だと悟った
それは、新しいプロジェクトで使うUIコンポーネントライブラリを選定する会議でのこと。
俺は、技術的な観点からA社のライブラリを推してました。パフォーマンスもいいし、WPFの標準コントロールとの親和性も高い。技術的には絶対A。
でも、リードエンジニアが選んだのは、B社のライブラリだったんすよ。B社のは、ちょっとクセがあって、パフォーマンスもAに劣る。
俺は「なんで？ 技術的にはAでしょ？」って食い下がった。
そしたらリードにこう言われたんです。
「キミの言うことは技術的に正しい。でも、B社は、ウチの会社が使ってる他のクラウドサービス（Azureとか）との連携で、すでに戦略的パートナーシップを結んでるんだ。将来的に、このWPFアプリをWebやモバイルに展開するってなった時、B社のロードマップとウチの戦略が一致してる。サポート体制も手厚い。技術的なわずかな優位性より、5年後のビジョンと組織全体の繋がりが重要なんだよ」
……ガツーン、と殴られた気分でした。
俺が見てたのは「今、この瞬間のコードの美しさ」だけ。
リードが見てたのは「会社全体の未来と、その中でのこのアプリの立ち位置」。
俺は、WPFのコードは書ける。でも、**「なぜ、この技術（WPF）を今、ここで使うのか」「このプロダクトをどう成長させていくのか」**という、一段上の視点が完全に欠けてた。
その瞬間、悟ったんです。
ああ、俺は「Tier 1」、つまり**「言われたことを（うまく）実行する人」**のままだ、と。
このままだと、俺は一生「コードを書くのがちょっと速い、便利な外国人エンジニア」で終わる。給料もそこそこで頭打ち。もっとコスパのいいヤツ（それこそAIかもしれないし、もっと給料の安い国からのエンジニアかもしれない）が出てきたら、真っ先に切られる存在。
特にWPFみたいに、Web系と違って「流行りの最先端！」ってわけじゃない技術分野だと、なおさら。
技術力だけで食っていくには限界がある。
Tier 1の「沼」から抜け出すために
海外で働くって、そういう「実力主義の残酷さ」がダイレクトに来るんです。
日本みたいに「〇〇さん、ベテランだから」みたいな「空気」は存在しない。
あなたに「ユニークな価値」がないと判断されたら、そこまで。
じゃあ、どうする？
コードを書くスキル（Tier 1）を極めるのは大前提。じゃあ、その「次」は？
そこで俺が意識し始めたのが、**「Tier 2 & 3」っていうキャリアの考え方。
これは単なる「シニアエンジニア」とか「マネージャー」みたいな役職の話じゃない。「影響力のレイヤー（階層）」**の話です。
- Tier 1: Learner (学習者)
- スキルを学び、タスクを実行する人。
- Tier 2: Catalyst (触媒者)
- 学んだことを「共有」する人。
- 自分の知識や経験をチームに還元し、周りを「加速（Accelerate）」させる「触媒」みたいな存在。
- （例：ジュニアのメンタリング、ドキュメント整備、勉強会の開催）
- Tier 3: Visionary (先見者)
- 未来を「開拓（Pioneer）」する人。
- 技術選定やプロジェクトの方向性を決め、戦略的なパートナーシップを築いて、組織の未来を形作る存在。
あの会議でリードエンジニアが持ってたのは、明らかに「Tier 3」の視点でした。
俺は、「Tier 1」の沼にハマってた。
海外で「不可欠な存在」になるためには、このレイヤーを意図的に上がっていくしかない。
「でも、いきなりTier 3なんて無理ゲーじゃね？」
「知識を共有（Tier 2）するって、具体的に何すりゃいいの？」
わかります。俺もそうでした。
でも、大丈夫。
このブログでは、俺がこの「Tier 1の壁」にぶち当たってから、どうやって泥臭く**「Tier 2: 知識をシェアする側」に移行し、さらには「Tier 3: 未来を語る側」**の議論に食い込んでいったか。
その実体験ベースの「超・具体的なステップ」を、これから余すところなくブチまけていこうと思います。
特に「ギブ（与えること）が、いかに自分の成長を増幅させるか」っていう、**「相互ネットワーク（Reciprocal network）」**の構築術。これはマジで効きます。
まずは「承」で、どうやって俺が「ただのWPFコーダー」から「WPFの設計思想を語る触媒（Catalyst）」へと動き出したか、その第一歩から話していきますね。
ギブは最強の学習戦略 — 「Tier 2（触媒者）」になるための、超具体的な3つのアクション
「起」で話した、あの忌まわしき技術選定会議（笑）。
俺が「技術的に絶対Aでしょ！」って息巻いてたのに、リードエンジニアに「会社戦略と5年後のビジョン（Tier 3の視点）でB社なんだわ、スマンな」って一蹴された、あの日。
あの瞬間、俺は「Tier 1（学習者）」の限界、つまり「コードが書けるだけの人」の天井をハッキリと見たわけです。
このままじゃ、マジでヤバい。
給料も上がらんし、いつか「キミ、WPFしか書けないんだ？ じゃあ、もういいや」って言われる日が来る。
でも、いきなりリードエンジニアみたいに「会社の5年後の戦略的パートナーシップが〜」とか語れます？ 無理ゲーですよね（笑）。俺だって無理だった。
じゃあ、どうする？
答えはシンプルでした。
いきなり「Tier 3（先見者）」を目指すんじゃなくて、まずは「Tier 2（触媒者）」になること。
「触媒（Catalyst）」ってのは、つまり「化学反応を促進させるヤツ」のこと。
チームで言えば、**「自分の知識や経験をシェアすることで、チーム全体の生産性やレベルを『加速』させる人」**です。
海外の現場って、日本みたいに「背中を見て盗め」とか「暗黙の了解」みたいな文化は（比較的）薄い。その代わり、「知識はオープンにしてナンボ」「知ってるヤツは知らんヤツに教えるのが当たり前」っていうカルチャーが強いんです。
だから、「ギブ（Give）するヤツ」は、めちゃくちゃ尊重される。
でもね、これ、勘違いしちゃいけない。
「ギブ」っていうのは、自己犠牲じゃない。むしろ逆。
海外エンジニアにとって、「ギブ」は最強の「学習戦略」であり、「生存戦略」なんです。
「え、人に教えてたら自分の時間がなくなるじゃん」って思うでしょ？
違うんです。
- 教えるためには、自分の中で情報が「超」整理されてないといけない。
- 質問されることで、自分が「わかったつもり」になってた穴に気づける。
- 「あの人は〇〇（俺ならWPF）に詳しい」というポジション（＝ブランド）が確立される。
結果、自分のスキルも上がり、社内での影響力も上がり、重要な情報（Tier 3につながる話）が自然と集まってくるようになる。
今日は、俺が「Tier 1の便利なコーダー」から抜け出すために、泥臭く実践した「Tier 2（触媒者）になるための超具体的な3つのアクション」をシェアします。
これ、特別なスキルは要りません。「ちょっとの勇気」だけ。
アクション1：「完璧主義」を捨てて、50点のドキュメントを「まず」書く
「知識をシェアしろ」って言われて、最初に思いつくのって「ドキュメント書く」ことですよね。
でも、これが一番の難関。
特にエンジニアって完璧主義多いから（俺もそう）、「こんな中途半端な情報、公開してもな…」とか「もっと完璧に検証してから…」とか思って、結局やらない。
わかる。超わかる。
でも、海外でそれやってたら、一生「知識を溜め込む（けど活用できない）ヤツ」で終わります。
俺がやったのは、「完璧な100点のドキュメント」を目指すのをやめたこと。
その代わり、**「今、チームが困ってることの50点の答え」**を、誰よりも早くWiki（こっちだとConfluenceとかが多いかな）に書く、ということ。
例えば、俺のチームでは当時、WPFアプリの「起動時間の遅さ」が地味に問題になってました。
みんな「遅いよねー」とは言うものの、誰も根本対策に手をつけてなかった。
俺も最初は「うーん、Dispatcherの処理が詰まってんのかな」とか「XAMLのBindingが複雑すぎるのかな」とか色々考えてたけど、完璧な答えは出ない。
だから、まずこう書いた。
タイトル：「WPF起動時間：現状分かってることと、やってみたけどダメだったことリスト」
- 現状：
- 起動に平均5秒かかってる（最悪）。
- 調査したこと（効果薄）：
App.xaml.csのコンストラクタで重い処理はしてないか？ → してなかった。- 画像の遅延読み込みは？ → 一部やったけど、効果は0.5秒短縮のみ。
- たぶん、ここが怪しい（未検証）：
- A社のサードパーティ製コンポーネントの初期化が重い疑惑。
- 膨大な数の
Style（デザイン定義）をMergedDictionaryで読み込んでるのがボトルネックかも？
- 誰か、この辺の知見ある人いますか？（Help!）
……どうです？
これ、技術的には何も解決してないんですよ（笑）。
ただ、「俺はここまで調べた。でもわからん。誰か助けて」って言ってるだけ。
でもね、これが「触媒」になるんです。
これを書いたことで、
- 別のシニアエンジニアが「あ、その
MergedDictionary問題、昔ハマったわ。StaticResourceじゃなくてDynamicResource使うと遅くなるケースあるよ」ってコメントくれた。 - 「A社のコンポーネント、確かに怪しいと思ってた。俺、ベンダーに問い合わせてみるわ」って別プロジェクトのヤツが反応してくれた。
- 結果、俺が一人でうんうん唸ってた時には出なかった解決策が、チーム（というか組織）として見つかった。
俺がやったのは「完璧な答え」を書くことじゃない。
「議論の叩き台（50点）」を提供しただけ。
でも、これにより、俺は「起動時間問題に最初に取り組んだヤツ」として認識された。
これが「ギブ」の第一歩。
「完璧なコード」を書くことより、**「不完全な情報をオープンにする勇気」**の方が、Tier 2への近道だったりするんです。
アクション2：「指摘」するな、「質問」しろ — ジュニア育成という名の自己学習
次にやったのが、ジュニアエンジニアのメンタリングとコードレビュー。
「え、ただでさえ忙しいのに、人のコード見てる暇ないよ」って？
甘い（笑）。
コードレビューこそ、最強のインプットの場なんです。
特に海外のジュニアは（いい意味で）生意気というか、ガンガン「Why?（なんで？）」って聞いてくる。
こっちが「ここはasync/await使って非同期にした方がいいよ」ってレビューで指摘するとするじゃないですか。
日本の感覚だと「あ、はい、直しときます」で終わるかもしれない。
でも、こっちのジュニアは平気でこう返してくる。
「なんでです？ この処理、数ミリ秒で終わるんで、asyncにするオーバーヘッド（処理負荷）の方がデカくないです？ Task.Runで別スレッドにするのと、awaitでUIスレッドに戻すの、どっちがパフォーマンスいいかデータあります？」
……ぐうの音も出ない（笑）。
「なんとなく、こっちの方がイケてるから」っていうフワッとした理解じゃ、レビューなんてできないんです。
だから俺、レビューの仕方を変えました。
「指摘（Assert）」するんじゃなくて、**「質問（Inquire）」**するスタイルに。
（悪い例）
「ここ、INotifyPropertyChangedの実装、BaseViewModel継承してないからダメ。直して」
（俺が実践した良い例）
「プルリクありがとう！ 1点質問。ここのViewModel、BaseViewModelを継承してないけど、何か意図がある？ 例えば、このViewModelはプロパティ変更通知が不要っていう認識で合ってる？」
こう聞くと、2パターンの答えが返ってきます。
- パターンA（ジュニアが単に忘れてた）：「あ、ヤバい！ 完全に忘れてました！ すぐ直します！」（→ この場合、彼は「指摘された」んじゃなく「自分で気づいた」形になるから、関係性が悪くならない）
- パターンB（ジュニアに意図があった）：「ああ、ここは画面表示後に一切変更がない読み取り専用のデータだから、INotifyPropertyChangedは不要（＝オーバーヘッドを減らすため）と判断して、あえて継承してないんです」（→ 俺のインプットになる！ 「なるほど、そういう割り切り方もあるのか！」と）
WPFのMVVMパターンなんて、100人いれば100通りの「正解」がある世界。
自分の常識（例えば「ViewModelは必ずBaseViewModelを継承すべし」みたいな）が、常に正しいとは限らない。
コードレビューを「間違い探し」の場じゃなくて、**「お互いの設計思想をすり合わせるディスカッションの場」**に変える。
これを徹底してから、ジュニアからの信頼も得られたし、何より俺自身が「なぜ、この書き方を選ぶのか？」を言語化するトレーニング（まさにTier 2のスキル！）になりました。
アクション3：「専門家」のレッテルを貼りにいく — 社内勉強会という名の「営業活動」
ドキュメント（アクション1）とコードレビュー（アクション2）で、ちょっとずつ「WPFのことで困ったら、アイツに聞けばなんか知ってるかも」っていう空気が醸成されてきました。
ここで、ダメ押しの一手。
社内勉強会（Tech Talk）の開催です。
これはもう、はっきり言って「営業活動」。
俺は「WPFのパフォーマンスチューニングの専門家」です、っていう「レッテル」を、自分から貼りにいく行為です。
いや、待って。
「専門家って言えるほど詳しくないし…」
「人前で英語でプレゼンとか無理…」
わかります。俺もそうでした。
プレゼン資料作ったはいいけど、「こんな内容でウケるか…？」って不安で、開催ボタンを押すのを3日くらい悩んだ（笑）。
でもね、これもアクション1のドキュメントと同じ発想。
「100点の完璧なプレゼン」じゃなくていい。
**「みんながちょっとだけ得する、明日使える3つのTips」**くらいでいいんです。
俺がやった最初のテーマは、
「お前らのWPFアプリが遅い理由 Top 3 — 今すぐListViewのVirtualization（仮想化）を確認しろ！」
みたいな、ちょっと刺激的なタイトル（笑）。
内容は、
- WPFの仮想化（
Virtualization）がデフォルトで効かないケース（StackPanelにItemsControl入れるな、とか）。 BindingのエラーがOutputウィンドウ（デバッグログ）に出てると、めちゃくちゃ遅くなる実演。async/awaitの「罠」（ConfigureAwait(false)の使い所）。
…みたいな、WPFエンジニアなら「ああ、あるある」って言うけど、ちゃんと説明しろって言われると自信がない、そんな内容。
結果？
そりゃもう、大成功でした。
終わった後、いろんな部署のエンジニアから「ウチのアプリもソレだわ！」とか「あのBindingエラー、放置してた…」って声かけられて。
一番デカかったのは、
あの俺をコテンパンにしたリードエンジニアが来てて、「いいまとめだった。今度、俺が考えてる新しいアーキテクチャ（Tier 3の話！）について、WPFの観点から意見くれない？」って言われたこと。
……キタコレ！！！
「ギブ（勉強会の開催）」が、見事に「リターン（Tier 3への招待状）」になって返ってきた瞬間でした。
「承」で見てきたように、「Tier 2（触媒者）」になるっていうのは、特別な才能が必要なわけじゃない。
- 不完全でもいいから情報を「先に」出す勇気。（ドキュメント）
- 「教える」フリして、自分も「学ぶ」姿勢。（コードレビュー）
- 「専門家」のレッテルを自分で貼りにいく「営業努力」。（勉強会）
全部に共通してるのは、**「自分の知識を抱え込まない」**ってこと。
ギブすればするほど、自分も成長できるし、周りからの信頼（＝影響力）もデカくなる。
この「信頼」っていう土壌ができて、初めて「Tier 3（先見者）」の出番がやってくるんです。
次の「結」では、このTier 2活動で得た「影響力」を武器に、どうやって俺が「コードの先を見る目」、つまり技術選定や会社の戦略っていう「Tier 3」の議論に食い込んでいったのか、その具体的なステップについて話します。
技術の話はするな！？ — Tier 3の会議で、俺が「C#」を封印した日
「承」で話した、あの社内勉強会。
「WPFの仮想化（Virtualization）を確認しろ！」ってやつね。
あれがウケて、俺はついに、あのリードエンジニアから「次の新アーキテクチャ会議、キミも意見くれない？」っていう「Tier 3への招待状」をゲットしたわけですよ。
いや、もうね、ガッツポーズですよ。心の中で。
「よっしゃー！ 見てろよ！ 俺のWPF愛と技術力で、完璧なアーキテクチャ提案してやる！」
「これで俺も『便利なコーダー（Tier 1）』卒業だ！」
って。
Tier 2（触媒者）としてのギブ活動（ドキュメント整備、レビュー、勉強会）が、ついに実を結んだ瞬間でした。
そして迎えた、運命の会議当日。
参加者は、俺をコテンパンにしたリードエンジニア、各部門のシニアエンジニア数名、そして…プロダクトマネージャー（PdM）と、なんか役職がよく分からん「ビジネス戦略担当」みたいなオッチャン。
……あれ？ なんかエンジニア以外の人、多くない？
まあいい。俺は俺の仕事（WPFの知見をブチまけること）をするまでだ。
会議が始まると、リードエンジニアが口火を切った。
「さて、来期から開発する新プロダクトだが、技術スタックの候補は3つある。A案：既存のWPF資産を流用する。B案：Blazor（C#でWeb作るやつ）でWebに全振りする。C案：MAUI（モバイル・デスクトップ両対応）でマルチプラットフォームを狙う」
お、おう。いきなりWPFの存続危機かよ。
でも、待ってました。俺の出番だ。
「ちょっといいですか」
俺は満を持して切り出した。
「A案のWPF流用だとしても、今の古いMVVMフレームワークは刷新すべきです。パフォーマンスとメンテナンス性を考えると、Dependency Injection（依存性の注入）を前提とした設計にして、WinUI 3（Microsoftの新しいUI技術）への移行パスも視野に入れたViewModelの分離を…」
俺が技術的な「正しさ」を熱弁してると、その「ビジネス戦略担当のオッチャン」が、俺の言葉を遮ってこう言ったんです。
「ごめん、ちょっと待って。君の話は、技術的には正しいんだろう。でも、俺が知りたいのは『なぜ』それをするのか、だ」
……へ？
オッチャンは続けます。
「君の言う『WinUI 3への移行パス』ってのは、具体的に『いつ』『いくら（工数）』かかって、それによって『何人の新規顧客』が獲れるんだ？ 『メンテナンス性が上がる』ってのは、具体的に『開発者の工数』を『何％』削減できて、それは『いくら（人件費）』のコストカットになるんだ？」
「……え」
「俺たちは『美しいコード』を作りたいんじゃない。『売れるプロダクト』を作りたいんだ。君の提案は、その『売上』にどう貢献する？『技術的負債』っていう言葉で、エンジニアの『やりたいこと』を正当化してないか？」
……シーン。
会議室が静まり返った。
俺、顔から火が出るかと思った。
あの「起」で書いた技術選定会議のデジャヴ？ いや、あれよりヒドい。
あの時は「会社の戦略を知らない」だけだった。
今回は**「技術（C#やWPF）」と「ビジネス（カネ）」を『翻訳』する言語を、俺が一切持っていない**ことを、白日の下に晒された。
俺が熱弁してたのは、
「このasync/awaitの書き方は美しい」
「このICommandの実装はイケてる」
っていう、完全に「Tier 1（学習者）」の視点、良くて「Tier 2（触媒者）」の視点（＝エンジニア仲間にはウケる話）でしかなかった。
Tier 3の会議で求められていたのは、「技術的な正しさ」じゃなかった。
「その技術選定が、会社の『カネ』にどういうインパクトを与えるか」
その一点だけだったんです。
Tier 3の「本当の姿」
俺は、根本的に勘違いしてました。
Tier 3（Visionary / 先見者）ってのは、
「Blazorだ！ これからはWebAssemblyだ！」
みたいに、技術の未来を予言する「技術の王様」みたいな存在だと思ってた。
違う。
Tier 3とは、「通訳者」であり「交渉人」だったんです。
- 「通訳者」として：
- エンジニアの言葉（「技術的負債」「リファクタリング」「パフォーマンス向上」）を、
- ビジネスサイドの言葉（「コスト削減」「開発スピード向上による市場投入（Time to Market）の短縮」「解約率（Churn Rate）の低下」）に翻訳する。
- 「交渉人」として：
- ビジネスサイドの要望（「今すぐこの機能を追加しろ」「開発費は半分だ」）に対して、
- エンジニアリングの現実（「その機能はアーキテクチャ変更が必要で6ヶ月かかる」「コスト半分なら品質は保証できない」）を突きつけ、落とし所を探る。
あのリードエンジニアが「起」の会議でB社を選んだのは、「戦略的パートナーシップ」っていう「ビジネス言語」で、その技術選定の「費用対効果（ROI）」を説明できたから。
あの「ビジネス戦略のオッチャン」は、俺に「WPFの技術的な詳細」なんか求めてなかった。
彼が知りたかったのは、
「WPF（A案）を選ぶと、Blazor（B案）より、いくら『得』なの？」
「開発スピードは『何倍』になるの？」
っていう、**「数字」**でした。
「C#」を封印する、という決意
その会議、俺はその後、一言も発せられませんでした。
「WPFの知見を…」とか息巻いてた自分が、恥ずかしくてたまらなかった。
会議が終わって、リードエンジニアに呼び止められた。
「キツいこと言われたけど、落ち込むなよ」
「アイツ（オッチャン）の言う通り、俺たちエンジニアはすぐ『技術』の話から入る。でも、Tier 3のテーブルでは、それは『悪手』だ」
「じゃあ、どうすれば…」
「簡単だよ。次にあのテーブルに着く時は、『技術用語』を封印してみろ」
……技術用語を、封印？
C#エンジニアが、asyncもWPFもMVVMも使わずに、何を話せと？
「例えば、『技術的負債の解消』って言う代わりに、『今、バグ修正に月間40時間（＝エンジニア0.25人月）かかってます。この改修で、それを月5時間に減らせます。浮いた35時間で、新機能Aが開発できます』って言うんだ」
「『パフォーマンス改善』って言う代わりに、『起動時間が3秒短縮されることで、ユーザーの離脱率が推定2%改善し、年間〇〇ドルの売上増に繋がります』って言うんだ」
「そのためには、まず『ビジネス』を理解しろ。 ウチの会社が今、どこで儲けてて、何に困ってるのか。プロダクトマネージャーが毎朝見てる『数字（KGI/KPI）』は何か。それを知ることからだ」
俺は、自分が「エンジニア」という狭い枠の中でしか生きてこなかったことを痛感しました。
Tier 1で「コード」を学び、
Tier 2で「チーム」に共有することを学んだ。
でも、Tier 3で必要なのは、「会社（ビジネス）」を学ぶことだった。
この日を境に、俺はC#の技術書を読む時間を半分にして、代わりに「プロダクトのKPIダッシュボード」と「マーケティング部の資料」を読み漁るようになりました。
「コードの先を見る目」っていうのは、新しいフレームワークの動向を追うことじゃなかった。
自分の書いたコードが、どうやって「会社のカネ」に変わってるのか、その「流れ」を見る目のことだったんです。
この「ビジネス言語」の習得こそが、俺にとって一番キツく、そして一番リターンがデカい「学習」になりました。
次の「結」では、この「Tier 3の壁」を乗り越えるために、俺が具体的にどうやって「ビジネス言語」を学び、ただのWPFエンジニアから「ビジネスを語れるエンジニア」へと変わっていったのか。その泥臭いプロセスと、そこから得た「本当の価値」について、話を締めくくろうと思います。
もう「WPFエンジニア」とは呼ばせない — あなたの本当の「価値」を定義する方法
「転」で話した、あの悪夢の会議。
「君の言う『メンテナンス性』って、いくらのコストカットになるんだ？」
「ビジネス戦略担当」のオッチャンにそう詰められて、俺が技術用語を連発した挙句に撃沈した、あの日。
あれはマジで、俺のエンジニア人生の「第二の挫折」でした。
（第一の挫折は、海外来てすぐの英語が聞き取れなかった頃ね（笑））
あの日から、俺はC#の技術書を読む時間を減らし、代わりにプロダクトマネージャー（PdM）のケビン（仮名）に「ちょっとコーヒーでもどう？」ってウザ絡みするようになりました。
「ケビン、今どの機能が一番『売上』にインパクトある？」
「今追いかけてる最重要KPI（主要業績評価指標）って何？」
「ぶっちゃけ、ウチのプロダクトの一番の『強み』と『弱み』って、営業資料になんて書いてあんの？」
最初は「なんでエンジニアがそんなこと知りたいんだ？」って怪訝な顔をされましたよ。
でも、ここで「承」で築いた**「Tier 2（触媒者）」としての信頼**が、めちゃくちゃ効いてきたんです。
ケビンは俺のことを「WPFのことなら何でも知ってる、あのTech Talk（勉強会）のヤツ」って認識してくれてた。
だから、俺が「いや、技術的にどうアプローチすればそのKPI達成に貢献できるか、マジで考えたいんだ」って本気度を見せたら、アイツ、全部教えてくれたんです。
「ウチの顧客の4割は、セキュリティが厳格な製造業だ」
「そいつらはオフライン環境のWindows端末でしか、ウCHIのソフトを使えない」
「だから、もしウCHIが『Web版（Blazor案）だけにします』なんて言ったら、売上の4割が一瞬で吹き飛ぶ。それがウCHIがWPFを捨てられない、最大の『ビジネス上の理由』だ」
……これだ！！！
俺が「起」の会議でリードエンジニアに負けた理由。
俺が「転」の会議でビジネスのオッチャンに一蹴された理由。
彼らはずっと「Tier 3（先見者）」の視点、つまり**「技術」と「カネ（売上）」が直結した視点**でモノを見ていた。
俺は「Tier 1（学習者）」の視点、「コードの美しさ」しか見ていなかった。
この「ビジネスの現実」を知ってから、俺は生まれ変わりました。
そして、次の会議で起きたこと
数週間後。
再び、あの新プロダクトの技術スタックを決める会議が開かれました。
メンバーは、前回とほぼ同じ。あのビジネスのオッチャンもいます。
リードエンジニアが「さて、前回（WPF vs Blazor vs MAUI）の続きだが…」と切り出した瞬間、俺は手を挙げた。
「その件ですが、まず『どの技術を選ぶか』の前に、『どの顧客を獲り、どの顧客を捨てるか』の議論をさせてください」
会議室が、ちょっとザワついた。
俺は、あのオッチャンの目をまっすぐ見て続けました。
「俺、PdMのケビンと話しました。ウチの現時点での売上の4割は、オフラインのWindows環境を必須とする製造業のクライアントです」
「ここでB案（Blazor / Web）を採択した場合、この4割の既存顧客を『捨てる』覚悟が必要になります。その売上減（年間XXX万ドル）を、新規のWeb顧客で回収するのに、何年かかると試算してますか？」
「逆にA案（WPF）かC案（MAUI）なら、既存の4割の顧客は維持できます。その上で、C案（MAUI）を採用した場合、新規にiOS/Android市場へアクセスできますが、そのためにはウチのWPFエンジニア（俺含む）全員の再トレーニングが必要です。そのコスト（＝開発がストップする期間と研修費）は、XXX万ドルと試算しました」
「A案（既存WPFの流用）が、最も低コスト（XXX万ドル）かつ短期間（Xヶ月）でリリースでき、既存顧客も維持できます。ただし、これだと新規市場は獲れません」
「……さて、皆さん。我々が今、会社として取るべき戦略（＝カネの使い方）は、どれでしょう？」
あなたの「価値」は、コードが書けること「だけ」じゃない
……会議の結果？
もちろん、俺の出した数字をベースに、議論はめちゃくちゃ前に進みました。
（結局、短期的にはA案（WPF）で足場を固めつつ、C案（MAUI）への移行をスモールチームで検証する、っていうハイブリッド案に落ち着いた）
あの「ビジネスのオッチャン」が、会議の後に俺の肩を叩いてこう言いました。
「よくやった。君はもう『WPFエンジニア』じゃないな。『ビジネス・エンジニア』だ」
泣きそうになりましたよ、マジで。
これが、俺がこのブログで一番伝えたかったこと。
海外で働く、特に俺らみたいなC# / WPFっていう、Web系ほど「流行り」じゃない技術スタ…ックで戦うエンジニアが「不可欠な存在」になるための道筋です。
- Tier 1 (Learner):
- まずは技術を学べ。C#だろうがWPFだろうが、コードが書けなきゃ始まらない。これは「入場券」。
- Tier 2 (Catalyst):
- 学んだことを、独り占めするな。ドキュメントを書き、レビューをし、勉強会を開け。
- ギブ（Give）しまくれ。これが「信頼」と「影響力（あなたのブランド）」を作る。「あいつは〇〇の専門家だ」と認識させろ。
- Tier 3 (Visionary):
- その「信頼」を使って、ビジネスサイドの「数字」と「戦略」を盗め。
- なぜ、あなたの技術が必要なのか？ それが会社の「売上」や「コスト削減」にどう繋がるのか？
- 「技術」を「ビジネス（カネ）」の言葉に『翻訳』しろ。
Tier 2（触媒者）が「横」への影響力（同僚へのギブ）だとしたら、
Tier 3（先見者）は「縦」への影響力（経営層へのギブ）です。
この**「ギブの循環（Reciprocal Network）」**を作れた人間が、海外では勝ち残る。
明日から、あなたに始めてほしいこと
「いやー、壮大な話だった。でも俺には無理そうだ…」
って思った？
大丈夫。
俺だって、最初はasync/awaitの書き方すらおぼつかなかった、ただのWPFコーダーです。
明日から、大それたことをする必要はありません。
まずは、あなたの隣にいるPdMや営業担当に、こう聞いてみてください。
「今、お客さんから一番クレーム来てる機能って、何です？」
そして、そのクレームを、あなたのWPF/C#のスキルでどう潰せるか、考える。
「そのバグ直したら、サポートチームの対応工数、月に何時間減らせます？」って見積もる。
それが、あなたが「Tier 1」のコーダーから、「Tier 3」のビジネス・エンジニアへと踏み出す、最高にクールな第一歩です。
あなたの価値は、あなたが書けるコードの行数じゃない。
あなたのコードが、どれだけ「ビジネスの数字」を動かしたかで決まる。
さあ、Visual Studio開く前に、ちょっとだけ「カネ」のこと、考えてみませんか？
コメント