「レガシー」はコードの話だけじゃない。海外で痛感した「進化」の本当の意味。
（※ここから本文「起」）
みんな、お疲れ様です！海外で何とかサバイブしてるC#エンジニア、（ハンドル名）です。
突然だけど、みんな「レガシーシステム」って言葉、好き？
まあ、好きってやつはいないか（笑）。「技術的負債」とか「触るなキケン」とか、ロクなイメージないよね。僕も日本にいた頃は、WPFでゴリゴリの業務アプリ作ってたけど、数年前に自分が書いたコードが、早くも「レガシー」扱いされてるのを見て、ちょっとへこんだりしてた（笑）。
で、こっち（海外）に来て、まずぶち当たったのも、やっぱり「レガシー」の壁だった。
僕が最初に参加したプロジェクト、金融系のシステムだったんだけど、使われてる技術がもう、博物館レベル。いや、マジで。20年前のアーキテクチャが、幾重にも重なるパッチ（継ぎ当て）で、かろうじて動いてる。ドキュメント？もちろん、ない（笑）。
「マジかよ…これをどうしろと？」って、初日は頭抱えたよね。
でも、数ヶ月そこで格闘してるうちに、あることに気づいたんだ。
ここの連中（同僚たち）は、その「博物館」を、なぜか楽しそうにいじってる。
日本では「レガシー＝悪」「触りたくない」「早くリプレイスしろ」っていう空気が強かった気がする。でも、こっちのシニアエンジニアたちは、その複雑怪奇なシステムを、まるで「解きごたえのあるパズル」みたいに扱ってた。
彼らは、システム全体を一気に捨てて、流行りの技術でピカピカに作り直すなんて、端から考えてない。そんなことしたら、ビジネスが止まる。彼らがやってたのは、**「どうやってこの『動いている』という価値を止めずに、中身を少しずつ良くしていくか」**っていう、超地道な作業。
その時、ハッとしたんだよね。
僕らが向き合ってる「レガシー」って、コードやシステムのことだけを指してるんじゃないんだなって。
本当の「レガシー」とは、**「固定された設計思想」や「変化を拒むマインドセット」**そのものなんだ。
最近、「The Legacy Unlocked: Building a Sustainable Digital Future（レガシーの解放：持続可能なデジタル未来の構築）」っていう、ちょっとカッコいいテーマのカンファレンス動画を見たんだ。
そこで語られてたキーメッセージが、まさにこれ。
「アーキテクトの仕事は、完璧な『固定設計（Fixed Design）』を作ることじゃない。**『継続的な進化（Continuous Evolution）』**を前提とした、しなやかなインフラを設計することだ」
これ、聞いた時、マジで膝を打った。
僕らエンジニア、特にC#やWPFで大規模なエンタープライズシステムを設計開発してきた人間って、「いかに堅牢で、変更の必要がない（と信じたい）完璧な設計をするか」に命をかけてきた部分があると思う。
それは素晴らしい職人技だし、WPFのMVVMパターンなんて、その思想の結晶だとも思う。
でも、海外に来て、ビジネスのスピードが日本の比じゃない環境に放り込まれると、その「完璧な固定設計」が、次の瞬間には「変化を妨げる足かせ」になるのを、嫌というほど見てきた。
「海外でエンジニアとして働きたい」
そう思ってるキミに、まず伝えたいのはこれだ。
キミが日本で学んだ技術や常識は、こっちでは「レガシー」かもしれない。
ちょっとショックかもしれないけど、これは事実。
僕の愛するC#やWPFだって、会社によっては「Windowsでしか動かないレガシー技術」って言われることもある。（そんなことない、.NET Core（今は.NET）でマルチプラットフォームだし、MAUIもWASMもあるぞ！って反論したくなるけど、世間のイメージは往々にしてそんなもんだったりする）
でも、大事なのはそこじゃない。
技術が「レガシー」かどうかは、時代や環境で変わる。
ヤバいのは、キミ自身の「マインドセット」が「レガシー」になることだ。
「俺はC#とWPFの専門家だ。それ以外の仕事はしない」
「俺の知ってる設計パターンが一番正しい。こっちのやり方は非効率だ」
この「固定設計」な考え方を持ったまま海外に来たら、多分、秒で詰む。
こっちで求められるのは、「WPFエンジニア」じゃない。「WPFもできる、問題解決のプロ」だ。
Webも、クラウドも、なんならPythonやGoだって、必要ならキャッチアップする。
昨日作った設計が、今日のビジネス要件で「間違い」だと分かれば、プライドを捨てて、喜んで修正する。
自分の「固定された」やり方に固執せず、チームの「継続的な進化」のために動けるか。
「レガシー」を「アンロック（解放）」するってのは、古いコードを捨てることじゃない。
僕らエンジニア自身の「固定観念」をアンロックするってことなんだ。
海外で働くってのは、まさにその「マインドセットの進化」を、毎日、強制的にやらされるようなもん（笑）。
技術スキルはもちろん必要だ。でも、それ以上に「変化し続けること」を受け入れるメンタリティ。それこそが、キミが海外でサバイブし、価値あるエンジニアとして「持続可能（サステナブル）」であり続けるための、最強の武器になる。
このブログでは、僕がC#とWPFという（ともすればレガシーと見られがちな）技術を背負いながら、どうやって海外の現場で「継続的な進化」とやらを実践してるのか。
特に、技術アーキテクチャの話だけじゃなく、キミ自身の「キャリア」をどうサステナブルにしていくか、リアルな「人生術」として、この後、じっくり語っていこうと思う。
みんな、お疲れ様です！海外で何とかサバイブしてるC#エンジニア、（ハンドル名）です。太平洋の向こう側から、今日もキーボードを叩いております。
突然だけど、みんな「レガシーシステム」って言葉、好き？
まあ、好きってやつはいないか（笑）。「技術的負債」「スパゲッティコード」「触るなキケン」……僕らエンジニアにとっては、できれば関わり合いたくない、悪夢の代名詞みたいなもんだよね。
僕も日本にいた頃は、C#とWPFでゴリゴリの業務アプリを設計・開発してました。クライアントの複雑な要求を、いかに美しいMVVMパターンで捌くか、いかにリッチでサクサク動くUIを作るかに、命を燃やしてた。
でも、皮肉なもんで、自分が「完璧だ」と思って作り上げたシステムも、3年、5年と経つうちに、いつの間にか「レガシー」って呼ばれるようになる。機能追加のたびにコードは複雑になり、新しいメンバーは「全体像が分からない」と嘆き始める。数年前に自分が書いたコードが、未来の誰か（時には未来の自分自身）の「負債」になってるのを見た時、ちょっとへこんだりもしたよね（笑）。
で、だ。
一念発起して海外に飛び出してきたわけだけど、こっち（海外）に来て、まずぶち当たったのも、やっぱり、特大の「レガシー」の壁だった。
僕が最初に参加したプロジェクト、とある大手金融系の基幹システムだったんだけど、使われてる技術がもう、博物館レベル。いや、マジで。20年前のアーキテクチャが、幾重にも重なるパッチ（継ぎ当て）の上で、かろうじて動いてる。ドキュメント？もちろん、ない（笑）。メインのロジックが、どっかの誰かがExcel VBAで書いたマクロに依存してたりして、「マジかよ…これをどうしろと？」って、初日は本気で頭を抱えた。
でもね、数ヶ月そこで格闘してるうちに、あることに気づいたんだ。
ここの連中（同僚たち）は、その「博物館」を、なぜか、ちょっと楽しそうにいじってる。
日本ではどうだったろう？
「レガシー＝悪」「触りたくない」「早くフルリプレイスしろ」っていう空気が、結構強かった気がする。新しい技術、イケてるアーキテクチャで、ゼロから作り直すのが正義、みたいな。
でも、こっちのベテランのシニアエンジニアたちは、その複雑怪奇なシステムを、まるで「解きごたえのある難解なパズル」みたいに扱ってた。
彼らは、システム全体を一気に捨てて、流行りの技術（例えばMicroservicesとか？）でピカピカに作り直すなんて、端から考えてない。そんなことしたら、何千億って金が動いてるビジネスが、確実に止まる。
彼らが血眼になってやってたのは、**「どうやってこの『動いている』という絶大な価値を止めずに、中身を少しずつ、でも確実に良くしていくか」**っていう、超地道な作業だった。
まさにその時、ハッとしたんだよね。
僕らが向き合ってる「レガシー」って、コードやシステムのことだけを指してるんじゃないんだな、って。
本当の「レガシー」とは、「固定された設計思想」や「変化を拒むマインドセット」、あるいは**「過去の成功体験に縛られたやり方」**そのものなんだ。
最近、すごく面白いカンファレンスの動画を見たんだ。
「The Legacy Unlocked: Building a Sustainable Digital Future（レガシーの解放：持続可能なデジタル未来の構築）」っていう、ちょっとカッコいいタイトルのやつ。
そこで語られてたキーメッセージが、まさに僕が現場で感じてたモヤモヤを、一言でブチ抜いてくれた。
「現代のアーキテクトの仕事は、完璧な『固定設計（Fixed Design）』を作ることじゃない。**『継続的な進化（Continuous Evolution）』**を大前提とした、しなやかで、回復力のある（レジリエントな）インフラを設計することだ」
これ、聞いた時、マジで膝を打った。というか、電撃が走った感じ。
僕らエンジニア、特にC#やWPFで、大規模なエンタープライズシステムや、一度納品したら長く使われる業務アプリケーションを設計開発してきた人間って、「いかに堅牢で、変更の必要がない（と信じたい）完璧な設計をするか」に、命をかけてきた部分があると思う。
それは素晴らしい職人技だし、WPFのMVVMパターンなんて、その「関心の分離」思想の結晶だとも思う。
でも、海外に来て、ビジネスのスピードが日本の比じゃない環境に放り込まれると、その「完璧な固定設計」が、次の瞬間には「変化を妨げる最大の足かせ」になるのを、嫌というほど見てきた。
「仕様変更？ダメダメ、その設計思想に反するから、できない」なんて言ったら、次の日にはプロジェクトから外されてるかもしれない。
「海外でエンジニアとして働きたい」
そう思ってるキミに、だからこそ、まず伝えたいのはこれだ。
キミが日本で学んだ最高の技術や常識は、こっちでは「レガシー」と呼ばれるかもしれない。
ちょっとショックかもしれないけど、これはマジであり得る事実。
僕の愛するC#やWPFだって、シリコンバレーのイケイケなスタートアップに行けば、「え、まだWindowsでしか動かないデスクトップアプリ作ってんの？（笑）」って、「レガシー技術」のレッテルを貼られることもある。（そんなことない、.NETはとっくにマルチプラットフォームだし、WPFだって進化してるし、MAUIもWASMもあるぞ！って反論したくなるけど、世間のイメージは往々にしてそんなもんだったりする）
でも、大事なのはそこじゃない。
技術が「レガシー」かどうかは、時代や環境、プロジェクトのコンテキストで、一瞬で変わる。
本当にヤバいのは、キミ自身の「マインドセット」が「レガシー」になることだ。
「俺はC#とWPFの専門家だ。それ以外の仕事はしない」
「俺が日本で学んだ設計パターンが一番正しい。こっちの連中のやり方は非効率で雑だ」
この「固定設計」な考え方を持ったまま海外に来たら、多分、秒で詰む。間違いなく、キミは「扱いにくい、レガシーなエンジニア」の烙印を押される。
こっちで求められるのは、「WPFエンジニア」じゃない。
**「WPF『も』できる、目の前の問題を解決してくれるプロフェッショナル」**だ。
Webも、クラウド（Azure, AWS）も、なんならPythonやGo、Reactだって、ビジネス課題を解決するために必要なら、喜んでキャッチアップする。
昨日自分が「完璧だ」と思って作った設計が、今日のビジネス要件の変更で「間違い」だと分かれば、ちっぽけなプライドは速攻で捨てて、喜んで修正し、チームに謝罪する。
自分の「固定された」やり方や、過去の栄光に固執せず、チームの「継続的な進化」のために、自分自身が変わり続けられるか。
「レガシー」を「アンロック（解放）」するってのは、古いコードを全て捨て去ることじゃない。
僕らエンジニア自身の「固定観念」や「変化への恐れ」をアンロックするってことなんだ。
海外で働くってのは、まさにその「マインドセットの進化」を、毎日、強制的にやらされるようなもんだ（笑）。
技術スキルはもちろん、前提として必要だ。でも、それ以上に「変化し続けること」そのものを受け入れ、楽しむメンタリティ。それこそが、キミが海外でサバイブし、価値あるエンジニアとして「持続可能（サステナブル）」であり続けるための、最強の武器になる。
このブログでは、僕がC#とWPFという（ともすればレガシーと見られがちな）技術を背負いながら、どうやって海外の現場で「継続的な進化」とやらを実践してるのか。
特に、単なる技術アーキテクチャの話だけじゃなく、キミ自身の「キャリア」をどうサステナブルにしていくか、僕がこっちで学んだリアルな「人生術」として、この後、じっくり語っていこうと思う。
C#とWPF、僕らが愛した「固定設計」の罠。アーキテクトが今、学ぶべきこと。
（※ここから本文「承」）
どうも！海外でC#とWPFのコードにまみれながら、なんとか生き延びてる（ハンドル名）です。
前回の「起」では、「本当のレガシーはコードじゃなくて、キミのマインドセットだ！」なんて、ちょっと偉そうなことを語らせてもらった（笑）。
「継続的な進化」が大事だってね。
でも、「言うは易し、行うは難し」ってやつで。
特に、僕らC#とWPFでガチガチのエンタープライズ・アプリケーションを作ってきたエンジニアにとって、この**「継続的な進化」っていうフワッとした概念を、どうやって日々の「設計」に落とし込むか**って、めちゃくちゃ難しくない？
今日は、僕らの愛するC#とWPFという技術スタックが、いかにして僕らを「固定設計」の罠にハメてきたか（いや、半分は僕らのせいなんだけどｗ）、そして、海外の現場で僕が学んだ「進化し続けるアーキテクチャ」のために、今すぐ意識すべきことについて、超具体的に語っていこうと思う。
WPFの「完璧な設計」が、なぜ「足かせ」になるのか？
まず、断っておくけど、僕はWPFが大好きだ。
XAMLでUIの構造を定義し、C#でロジックを書き、MVVMパターン（Model-View-ViewModel）でそれらを美しく分離する。あのアーキテクチャは、本当に素晴らしい。
特に「関心の分離（Separation of Concerns）」っていう思想。Viewは見た目だけ、ViewModelはUIのロジックと状態管理、Modelはビジネスロジックとデータ。これを徹底することで、テストはしやすくなるし、UIデザイナーとエンジニアの分業も可能になる。
日本で大規模な業務アプリを作ってた頃、僕はこの「完璧なMVVM」を実装することに、ある種の快感を覚えてた。
インターフェースを定義し、DI（Dependency Injection）コンテナで疎結合にし、ViewModelからModelへの依存は一方向、ViewはViewModelの存在しか知らない……。美しい。あまりにも美しい設計だ。
……そう、ビジネス要件が変わらない限りはね。
この「完璧な固定設計」、海外のスピード感についていこうとすると、途端に牙をむく。
僕がこっちで経験した、あるプロジェクトの話をしよう。
それは、とある物流の在庫管理システム。もちろん、僕の得意なWPF（とC#）で作られてた。
初期の設計は、そりゃもう美しかった。まさに「MVVMの教科書」だ。
そこへ、ある日、ビジネスサイドから無茶な要求が飛んできた。
「緊急なんだけど、今ある在庫管理画面、明日からタブレット（iPad）でも使えるようにしたい。あと、現場のハンディスキャナ（Androidベース）とも連携させて、スキャンしたら即座に在庫数に反映させてほしい」
……は？
ってなるよね（笑）。
WPF（.NET Frameworkベースの）で作られたデスクトップアプリを、iPadでどう動かせと？
ハンディスキャナ（Android）とのリアルタイム連携？おいおい、こっちはWindowsデスクトップの世界だぜ？
日本だったら、「無理です。アーキテクチャの前提が違います。まずはMAUIかWebへの移行プロジェクトを立ち上げて、見積もりと工数を……」って、半年がかりのプロジェクトを提案してたかもしれない。
でも、こっちのマネージャーは「（ハンドル名）、君はC#のプロだろ？ .NETはマルチプラットフォームだって聞いたぞ。なんとかしてくれ」の一点張り。
この時、僕が日本で培った「完璧なMVVM設計」は、完全に「レガシー」な足かせになった。
なぜか？
- プラットフォームへの密結合:そのアプリ、WPFのUIコンポーネントライブラリ（TelerikとかDevExpressみたいなやつ）にガッツリ依存してた。当然、iPadでは動かない。
- 「デスクトップアプリ」という大前提:設計の根底が、「Windows PC上で、一人のユーザーが操作する」ことを前提にしてた。リアルタイムな他デバイス連携なんて、まったく考慮されてない。
- ViewModelの肥大化:「関心の分離」はどこへやら。度重なる仕様変更で、ViewModelがビジネスロジックを山ほど抱え込み、もはや「ViewのためのModel」ではなく、「何でも屋のゴッドクラス」と化してた。
結局、その場はWeb APIを急ごしらえで立てて、iPad側は最低限のWeb UIを作るっていう、超絶泥臭い対応で乗り切った。
でも、僕はその時、痛感したんだ。
僕らが「固定設計」の罠にハマる理由は、技術そのものにあるんじゃない。
「このシステムは、このプラットフォーム（WPF）で、この設計（MVVM）で、未来永劫使われ続けるのだ」という、エンジニアの「思い込み」にあるんだ。
アーキテクトが学ぶべきは「技術」より「境界」
先のカンファレンス「The Legacy Unlocked」では、アーキテクトの役割のシフトについて、こうも言ってた。
「固定された青写真（ブループリント）を描くのをやめろ。代わりに、**『進化する境界』**を設計しろ」と。
これ、まさに僕がWPFのプロジェクトで失敗したことそのものだ。
僕が作るべきだったのは、「完璧なMVVM」じゃなかった。
作るべきだったのは、**「WPF（View）が、将来別のもの（WebやMobile）に置き換えられること」を前提とした、「境界」**だったんだ。
具体的にどういうことか？
僕が最近、C#で新しいシステムを設計する時に、WPFを使うかどうかにかかわらず、徹底的に意識してるのは、「WPFである必要がないコード」を、WPFのプロジェクトから物理的に引き剥がすことだ。
当たり前だろって思う？
でも、WPF（やWindows Forms）のプロジェクトって、「UIのイベントハンドラに、ファイルI/OやDBアクセスのロジックを直接書いちゃう」っていう誘惑が、すごく強いんだ。だって、その方が早いから。
でも、それをやっちゃうと、さっきの「iPad対応しろ」みたいな無茶振りが来た瞬間に、詰む。
ファイルI/OやDBアクセスのロジックは、WPFとは何の関係もない。それは「ビジネスロジック」であり、「インフラ（I/O）層」だ。
だから、僕はこうする。
- Coreプロジェクト（.NET Standard / .NET 8）:ここには、ビジネスロジック（いわゆるドメインモデル）と、インターフェース（DBアクセスやAPIコールの「定義」）だけを入れる。このプロジェクトは、WPFやWindowsへの依存を一切持たない。ピュアなC#コードだ。
- Infrastructureプロジェクト:Coreで定義したインターフェースの「実装」を入れる。EntityFrameworkCoreでのDBアクセスとか、HttpClientでのAPIコールとか。
- Applicationプロジェクト（WPF）:ここで初めてWPFが登場する。このプロジェクトの責務は、ただ一つ。Coreのロジックを呼び出し、その結果を「画面に表示する」ことだけ。ViewModelは、Coreのビジネスロジックを（DI経由で）呼び出す「通訳」に徹する。
こうやって、「WPFじゃないと動かないコード」と、「別にWPFじゃなくても（なんならLinuxサーバー上でも）動くはずのコード」を、物理的に（プロジェクトレベルで）分離する。
これが、僕が学んだ**「進化する境界」を設計する**ってことの、第一歩だ。
こうしておけば、明日「iPadで」って言われたら？
CoreとInfrastructureはそのまま再利用して、新しく「Web APIプロジェクト」や「MAUIプロジェクト」を作って、そこからCoreを呼び出せばいい。
僕の書いたビジネスロジックは、「WPF」というレガシー（になるかもしれないもの）から守られる。
「固定設計」から「継続的進化」へ。
これは、技術を捨てて、流行りを追いかけろって話じゃない。
むしろ逆だ。
自分が愛する技術（C#）が、プラットフォーム（WPF）という「固定された」環境と一緒に「レガシー」として捨てられないように、きっちり「境界」を設けて、守ってやることなんだ。
海外で働くってのは、こういう「技術のサステナビリティ」を、設計レベルで真剣に考えるってこと。
それは、キミのコードを守るためであり、もっと言えば、キミ自身の「エンジニアとしての価値」を守るための、最強のサバイバル術なんだ。
「モダン化の失敗」から学んだ。技術選定より大切な、海外チームでの「合意形成」術。
（※ここから本文「転」）
よお！海外の片隅で、今日も元気にデバッグしてる（ハンドル名）だ。
「起」で「レガシーはマインドセットだ！」と叫び、「承」で「WPFエンジニアよ、技術の『境界』を設計しろ！」と、具体的なCore分離の話をした。
我ながら、いいこと言ったと思う（笑）。
「よし、これで俺も『継続的進化』ができるアーキテクトだ！」
そう意気込んで、僕が次に参加したプロジェクトで、例の「美しいCore分離アーキテクチャ」をチームに提案したんだ。
「みんな、WPFプロジェクトにビジネスロジック書くの、もうやめないか？これからは、CoreプロジェクトにピュアなC#でロジックを書いて、WPFはそれを使う『だけ』にするんだ。こうすれば、将来Web APIが必要になっても、MAUIでスマホ対応する時も、このCoreを再利用できる。完璧だろ？」
自信満々だった。技術的には、これが「正解」だと信じて疑ってなかったから。
……だが、現実は甘くなかった。
僕の提案を聞いた、チームのシニアエンジニア（仮に”ボブ”としよう。こういう時、だいたい”ボブ”って名前のベテランが出てくるんだ、海外は）が、コーヒーを一口飲んで、こう言った。
「……で、なんで俺たちが、そんな面倒なことをしなきゃいけないんだ？」
「え？」ってなったよね。
ボブは続けた。
「（ハンドル名）、君が言ってることは、理論としては分かる。でもな、俺たちは『WPFアプリケーション』を作ってるんだ。WPFプロジェクトにコードを書くのが、一番早いし、自然だろ？ なんでわざわざプロジェクトを分けて、インターフェースを定義して、DIコンテナで注入して……そんな『過剰設計（Over-engineering）』をする必要がある？」
別のメンバーも続く。
「そもそも『将来MAUIでスマホ対応』って、誰が言ったんだ？そんな話、ビジネスサイドから一言も出てないぞ」
「君の『美しい設計』の自己満足のために、俺たちの開発スピードを落とすつもりか？」
……詰んだ。
僕の「技術的な正しさ」は、彼らにとっては「余計な仕事」であり、「現場を分かってない理想論」でしかなかった。
僕は焦った。「いや、これは『継続的進化』のために必要な投資なんだ！」「サステナブルなインフラを構築するには……」と、カンファレンスで聞いたような言葉で反論しようとした。
でも、ダメだった。
僕が技術論を語れば語るほど、チームの空気は冷めていく。
「あいつ（日本人）は、また面倒なことを言ってる」
「口ばっかりで、手を動かさないアーキテクト気取りだ」
そんなレッテルが、背中にビシビシ貼られていくのが分かった。
結局、僕の「モダン化」の提案は、マネージャーから「うーん、ボブたちが乗り気じゃないなら、一旦ペンディング（保留）にしようか」と、事実上の「却下」を食らった。
これが、僕が海外で経験した、**手痛い「モダン化の失敗」**だ。
あの夜、ホテルの部屋で一人、安いビールを飲みながらマジで考えた。
僕の設計は、間違ってたのか？ C#のロジックをWPFから分離するのは、本当に「過剰設計」だったのか？
いや、技術的には、やっぱり「正しい」はずだ。
じゃあ、何がダメだったんだ？
……答えは、シンプルだった。
僕は「技術」の話しかしてなかった。
チームを「動かす」ための、一番大事なプロセスを、全部すっ飛ばしてたんだ。
僕が学んだのは、技術選定（WPF vs MAUIとか）や、アーキテクチャの優劣（MVVM vs X）なんかより、**100倍大切な「合意形成」**のスキルだった。
「これから海外で働きたい」
そう思ってるキミに、僕のこのクソダサい失敗談から学んだ、「マジで得する」海外チームでの「合意形成」術をシェアしよう。
これは、技術書には載ってない、超実践的なサバイバル術だ。
人生術①：「Why」を技術で語るな、「ビジネスの未来」で語れ。
僕の失敗は、「Coreを分離すべき」という「How（どうやって）」から話しちまったことだ。
ボブたちにとって、それは「（ハンドル名）のやり方」でしかなく、自分たちには関係ない。
そうじゃない。
彼らに響くのは、技術の美しさじゃない。**「彼らの仕事が、どう楽になるか」「会社のビジネスが、どう成功するか」**だ。
だから、こう言うべきだった。
「なあ、ボブ。最近、X社のシステム、バグ多くないか？あれ、ロジックがViewModelにベッタリだから、単体テストが書けないのが原因だ。もし、ロジックが別プロジェクト（Core）にあったら、テストコード書きまくれるぜ？ キミがいつもイライラしてる、あの面倒なデバッグ作業、半分になるかもよ？」
「マネージャー、もし明日、社長が『ウチもWebで同じ機能を提供しろ』って言い出したら、どうします？今からゼロで作りますか？ もし、このCoreがあれば、半年かかるプロジェクトが、2ヶ月で終わる『保険』になりますよ」
「技術的な正しさ」を振りかざすな。
彼らの「痛み（Pain）」を解消するメリットや、ビジネスの「未来（Gain）」にどう貢献するか。
「Why（なぜやるのか）」を、技術の言葉じゃなく、彼らの言葉（ビジネス、コスト、工数）に翻訳して語ること。これが、第一歩だ。
人生術②：「完璧な図」より「雑な対話」で巻き込め。
僕は、自信満々に「これが完璧なアーキテクチャだ」と設計図を見せた。
これが、ボブのプライドを傷つけたのかもしれない。「俺に意見するなってことか？」と。
海外（特に欧米）のエンジニアは、トップダウンで「決められた」ものを、そのまま受け入れるのを嫌う傾向が強い。彼らは「対話」し、「議論」し、自分も「意思決定に参加した」という感覚を、めちゃくちゃ大事にする。
だから、いきなり完璧なUML図とかを見せちゃダメだ。
やるべきは、ホワイトボードの前にボブを連れてきて、**超雑な「箱」と「線」**を引くこと。
「なあ、ボブ。今、ウチのシステムって、全部がこのデカい『WPF』って箱の中にあるよな。もし、ここ（ビジネスロジック）を、別の『Core』って箱に切り出したら、どう思う？」
大事なのは「どう思う？」と、**相手の意見を聞く「問いかけ」**から入ることだ。
ボブは、きっと言うだろう。「面倒だ」と。
そしたら、こう返す。
「なるほど、ボブは『面倒（開発スピードの低下）』を懸念してるんだな。確かに。じゃあ、その『面倒さ』を上回るメリットが、例えば『テストのしやすさ』だとしたら、キミはどっちを取る？」
こうやって、彼を「批評家」から「問題解決の当事者」に引きずり込むんだ。
僕がやったのは「プレゼン」。やるべきだったのは「ファシリテーション（対話の促進）」だった。
人生術③：「技術選定」の前に「原則」を合意しろ。
一番やっちゃいけないのが、「WPFは古い！これからはMAUIだ！」「いや、WebAssemblyだ！」みたいな、「技術選定」の宗教戦争を始めること。
その前に、チームで「価値観」をすり合わせるんだ。
「なあ、みんな。僕らのチームとして、将来の技術選定で、一つ『原則（Principle）』を決めないか？」
「例えば……『我々のビジネスロジックは、特定のUI技術（WPFとか）に、依存してはならない』……この原則、どう思う？」
もし、チームがこの「原則」に「Yes」と言ってくれたら、こっちのもんだ。
だって、この原則を守るためには、必然的に「ビジネスロジックを、UI（WPF）プロジェクトから分離する」っていう「How（やり方）」が必要になるからだ。
ボブが後から「やっぱりWPFに全部書きたい」と言っても、「いや、ボブ。それは、俺たちが合意した『原則』に反するぜ？」と、チーム全体の「合意」を盾に、反論できる。
「どうやるか（How）」で戦うな。「なぜやるか（Why）」、そして「何を大事にするか（Principle）」で、先に合意を取れ。
キミの「モダン化の失敗談」も聞かせてくれ
長くなったけど、僕が言いたいのはこれだけだ。
技術的な「レガシー」との戦いは、実は、半分以上が「人間（チーム）」との戦いだ。
「継続的な進化」が必要なのは、コードベースだけじゃない。僕らエンジニアの「コミュニケーション」や「合意形成」のやり方そのものなんだ。
これ、マジで海外に来て一番学んだ「人生術」かもしれない。
どうだろう？
キミたちも、こういう「モダン化の失敗」や、「技術的には正しいはずなのに、チームが動いてくれねー！」って壁にぶち当たった経験、ないか？
もし、キミが乗り越えた経験（成功談）や、今まさに格闘してる挑戦（チャレンジ）があったら、ぜひコメントでシェアしてほしい。
みんなの「レガシー挑戦記」、マジで聞きたい。
このブログでは、こういう小手先のC#テクニックだけじゃなくて、海外でエンジニアが「しなやかに（resilient）」生き残り、「適応し続ける（adaptable）」ための、リアルなサバイバル術を、これからも発信していくつもりだ。
次の「結」では、これら全部を踏まえて、じゃあ「キミ自身のキャリア」をどうサステナブルにしていくか、最終的な話をしようと思う。
興味があったら、ぜひサブスクライブ（購読）して、また読みに来てくれよな！
あなたのキャリアを「レガシー」にしないために。今日から始めるサステナブルなエンジニアライフ。
（※ここから本文「結」）
最後まで読んでくれて、マジでありがとう！海外の（ハンドル名）です。
いやー、長かったな（笑）。
「起」から始まって、「承」「転」と、僕がこの海外の現場で「レガシー」っていう化け物と、どう格闘してきたかを、かなり赤裸々に語ってきた。
ここで、一度、旅を振り返ってみようか。
- 「起」：本当のレガシーは、コードじゃなくて「固定化されたマインドセット」だ！「俺はWPFエンジニアだ」と固執するな。「継続的な進化」を受け入れるメンタリティこそが、海外サバイバルの第一歩だと気づいた。
- 「承」：俺たちの愛したWPF（MVVM）が「固定設計」の罠になる！技術的な正しさ（完璧な設計）に酔っちゃダメだ。将来の変化を前提とした「境界」を設計し、自分のコードを「レガシー化」から守ってやれ。
- 「転」：技術的に正しくても、チームが動かなきゃ失敗だ！「モダン化」の失敗から学んだ、技術選定より100倍大事な「合意形成」術。Whyを語り、対話し、原則で合意しろ。
「マインド」「技術」「チーム」……この3つの話をしてきた。
でも、勘のいいキミならもう気づいてるよな。
これ、全部、キミ自身の「キャリア」をどう「持続可能（サステナブル）」にしていくかっていう、超重要な「人生術」の話だったんだ。
「レガシー」を解放し、「持続可能な未来」を築くということ
このブログのインスピレーションになった、あのイケてるフックを覚えてるか？
「The Legacy Unlocked: Building a Sustainable Digital Future（レガシーの解放：持続可能なデジタル未来の構築）」
僕がこの4つの記事を通して、本当に伝えたかったのは、この「レガシーの解放」と「持続可能な未来」っていう言葉の、僕なりの「再定義」だ。
**「レガシーの解放（The Legacy Unlocked）」**ってのは、古いコードベースを捨てて、ReactとかGoみたいなイケてる技術に乗り換えることじゃない。
それは、過去の成功体験に縛られた「古い自分」をアンロック（解放）するってことだ。
「俺は日本でこれで成功した」
「俺の知ってるMVVMが最強だ」
そういう「固定設計」なプライドを、気持ちよくアンロックできるかどうかに、キミの未来がかかってる。
じゃあ、**「持続可能な未来の構築（Building a Sustainable Digital Future）」**ってのは？
ピカピカのマイクロサービスや、無限にスケールするクラウドネイティブなインフラを作ること？
それも大事だ。でも、もっと大事なことがある。
それは、キミ自身が、5年後、10年後も、変化の激しいこの業界で「価値あるエンジニア」としてメシを食い続けられるか、そのための「しなやかで、回復力のある（レジリエントな）キャリア」を構築することだ。
WPFがなくなっても、C#が下火になっても（まあ、Microsoftがいる限り、それはないと信じたいが）、キミが「エンジニア」として生き残れるか。
それこそが、僕らが本当に目指すべき「サステナブルな未来」じゃないか？
「じゃあ、具体的にどうすりゃいいんだよ！」
って声が聞こえてきそうだ（笑）。
分かった。
僕がこの海外の荒波で、マジで「これは得した」と実感してる、キミのキャリアを「レガシー」にしないための、**今日から始める3つの「人生術」**を、最後にプレゼントしよう。
人生術①：「WPFエンジニア」という肩書きを、今すぐ捨てろ。
いきなり「専門性を捨てろ」って、極端に聞こえるかもしれない。
でも、これが一番大事な「マインドセット」のアンロックだ。
海外に来て痛感したのは、「肩書き」なんて、何の役にも立たないってこと。
日本だと「WPFのスペシャリスト」ってのは、一種の「勲章」だったかもしれない。
でも、こっちで「I’m a WPF specialist.」なんて言ったら、「へえ、それで？（So what?）」で終わりだ。最悪、「デスクトップアプリしかできない、レガシーなやつ」と見られるリスクすらある。
キミの本当の価値は、「WPFが書けること」じゃない。
キミの価値は、**「C#（と.NETエコシステム）を使いこなして、ビジネス上のクソ面倒な課題を、ロジカルに解決できること」**だ。
もっと言えば、「C#すらも」道具の一つに過ぎない。
「承」で話した「Core」の分離を思い出せ。
あの「Core」に詰まってる、プラットフォームに依存しないピュアな「問題解決能力」こそが、キミの本当の価値だ。
だから、明日から自分のことを「WPFエンジニア」と呼ぶのをやめよう。
「C#で問題解決するプロ（C# Problem Solver）」と呼べ。いや、「ソフトウェアエンジニア」でいい。
肩書き（プラットフォーム）に依存するキャリアは、そのプラットフォームが沈む時に、一緒に沈む。「固定設計」のキャリアだ。
「問題解決」という、普遍的なスキルに軸足を置け。それこそが「継続的進化」が可能なキャリアだ。
人生術②：「学習」を「仕事」として再定義しろ。
日本にいた頃、僕は「学習」を、業務時間外の「自己研鑽」だと思ってたフシがある。
でも、海外じゃ、そのマインドセットは「レガシー」だ。
こっちでは、「教えてもらう」なんて文化は、ない。
「（ハンドル名）はプロだろ？ プロなら、必要なことは自分で勝手に学んで、解決してくれ」
これが基本スタンスだ。
じゃあ、いつ学ぶんだ？
「仕事中」だ。
キミが今、WPFの仕事しかしてないなら、その状態は「ヤバい」と自覚しろ。
そのWPFのコードを、どうやったら「Core」に分離できるか、業務時間中に調べろ。
「今は必要ない」と言われても、空いた時間（なんてものはないから、「作る」んだ）に、Core分離のプロトタイプを作れ。
隣のチームが使ってるAzure Functionsや、フロントエンドが使ってるReactが、どうやって自分たちのC# APIと繋がってるのか、勝手にコードを読んで、勝手に学べ。
「サボってる」って罪悪感を感じるか？
逆だ。
それは、未来のプロジェクトで発生するかもしれない「技術的負債（レガシー化）」を、先回りして「返済」してる、めちゃくちゃ価値のある「仕事」なんだ。
「転」でボブに「過剰設計だ」と言われたあの日から、僕はマネージャーにこう言うようにしてる。
「この『調査（学習）』の時間は、今すぐには金にならないかもしれない。でも、半年後にウチのチームが『レガシー』チームと呼ばれるのを防ぐための、**一番安い『保険』**ですよ」
「学習」を「自己研鑽」という名の「趣味」から、「未来への投資」という名の「仕事」に再定義しろ。
それが、キミのキャリアの「サステナビリティ」を、劇的に高める。
人生術③：「書く」か「話す」かで、自分の「進化」をアウトプットしろ。
これが最後にして、最強の「人生術」だ。
「転」で「合意形成」の話をしたよな。
あれ、結局は「自分の考えを、相手に伝わる言葉でアウトプットできるか」ってことに尽きる。
海外では、黙って「いい仕事」をしてるだけじゃ、マジで評価されない。
「あいつ、何考えてるか分からん」
「静かだけど、仕事はしてる……のか？」
最悪、レイオフ（解雇）のリストに、真っ先に名前が載る。
だから、キミが「進化」しようと、水面下で何を学んでいようと、それを「アウトプット」しなきゃ、「存在しない」のと同じなんだ。
このブログだって、僕のアウトプットだ。
チーム内のSlackで「なあ、C# 12のこの新機能、ウチのレガシーコードのリファクタリングに使えそうじゃないか？」って、短い記事をシェアするのでもいい。
ボブを捕まえて「Core分離のプロトタイプ、作ってみたんだけど、5分だけ壁打ち（意見交換）付き合ってくれ」と話しかけるのでもいい。
大事なのは、**「俺は、ここにいて、ちゃんと『進化』しようと、もがいてるぞ！」**と、チームや世界に対して、発信し続けることだ。
そのアウトプットが、キミの「評価」を定義する。
そのアウトプットが、キミの「価値」を定義する。
そして、そのアウトプットが、キミ自身の「学習（進化）」を、最強にブーストしてくれるんだ。
キミの「アンロック」を応援してる
長くなった。
「マインドをアンロックしろ」
「技術の『境界』を守れ」
「チームと『合意』しろ」
そして、
「肩書きを捨てろ」
「学習を仕事にしろ」
「アウトプットしろ」
僕が伝えたかったのは、これだけだ。
どれも、簡単なことじゃない。僕だって、毎日失敗して、へこんで、ボブと喧嘩しそうになりながら、なんとかやってる。
でも、これが、僕らC#エンジニアが、WPFという素晴らしい（だが、ともすればレガシーと呼ばれる）技術を愛しながらも、海外という変化の激しい場所で「サステナブル」に生き残っていくための、唯一の道だと信じてる。
さあ、次はキミの番だ。
この記事を読んで、**キミが、自分のキャリアを「レガシー」にしないために、「明日から具体的に何を始めるか？」**を、ぜひコメントで教えてほしい。
「WPFプロジェクトの、まずはこのクラスからCoreに分離してみます」
「ボブ（みたいな人）に、まず雑な対話を持ちかけてみます」
「C#以外の言語（Pythonとか）を、週に2時間『仕事として』学んでみます」
どんな小さな一歩でもいい。
キミの「レガシー」を「アンロック」する、その最初の一歩の宣言を、マジで聞きたい。
このブログでは、これからも、こういう海外でガチでサバイブするための「技術」と「人生術」を、包み隠さず発信していく。
もし、僕と一緒に「継続的に進化」する、サステナブルなエンジニアライフを築いていきたいと思ってくれたなら、ぜひ、このブログをサブスクライブ（購読）して、次の記事も読みに来てくれよな！
読んでくれて、本当にありがとう。
キミの「レガシー」が解放され、持続可能な未来が築かれるのを、太平洋の向こう側から、心から応援してる。
コメント