「そのコード、いつ書いた？」海外C#エンジニアが本音で語る、レガシーシステムと未来のアーキテクチャ戦略

絶望か、お宝か？海外で直面した「レガシー」の現実

どうも！海外（例えばドイツあたり）で、C#とWPFをメインにエンタープライズ系の設計・開発をやっているエンジニアの「ケン」です。こっちに来て、かれこれ数年。日本でバリバリやっていた皆さんが、これから海外で働きたいって思った時に、「これ、知っとくとマジで得するよ」っていう実体験ベースの話を、カジュアルにお届けしようと思ってます。

さて、記念すべき（？）第一回のテーマは、これ。

「レガシーシステム」です。

うわっ、て思った人、いますよね（笑）。

エンジニア、特に若手でイケイケな人ほど、この言葉に拒否反応を示しがち。

「レガシーとか、触りたくないっす」

「俺は最新のReactとGoで、マイクロサービス作りたいんで」

「WPF？まだ使ってんの？（失笑）」

分かります。その気持ち、めちゃくちゃ分かります。

僕も日本にいた頃は、どっちかというと新しい技術を追いかけるのが好きでした。WPFも、当時は「Windows開発の未来だ！」と思って飛びついたクチですが、今や世間はWeb、クラウド、AI一色。C#は.NET Core (.NET 5以降) のおかげで息を吹き返したけど、WPFって言うと、ちょっと「お、おう…」みたいな空気、ありますよね。

でもね、これ、海外で働き始めて、特にヨーロッパの老舗企業とかと仕事すると、価値観が180度、いや、540度くらい（一周半）ひっくり返るんですよ。

こっちで僕が最初に関わったプロジェクト。

ある製造業の、基幹システムでした。クライアントは、それこそ100年以上の歴史があるような「ザ・老舗」。

で、ソースコード開くじゃないですか。

「……ん？」

ソリューションファイル（.sln）の最終更新日、2008年。

使ってる.NET Framework、3.5。

UIはもちろん、WPF。それも、MVVMパターンなんて導入される前の、コードビハインドに数千行のロジックが書いてある、ゴリゴリの「遺産」。

正直、最初は「マジか…」と思いました。

「これを、俺がメンテすんの？」「作り直した方が早くない？」

日本から意気揚々とやってきて、いきなり10年以上前のコードの海に放り込まれたわけです。

新人エンジニアが「レガシーは嫌だ」って言うのと同じマインドセットに、僕も一瞬、足を突っ込みかけました。

でも、数週間、そのシステムと格闘して、気づいたことがあるんです。

「このコード、バグが、ない。」

いや、ゼロじゃないですよ。もちろん細かいのはある。

でも、10年以上、この会社の「心臓」として動き続けて、日々の膨大なトランザクションを処理し、世界中の工場を動かし、何億ユーロっていう売上を生み出し続けてきた。

そこには、バグが出尽くし、磨き上げられ、最適化された「安定」という、とんでもない価値があったんです。

ここで、海外で働くエンジニアを目指す皆さんに、一つ目の「人生術」というか、「視点の転換」をシェアしたい。

「レガシーシステムは、『負の遺産』ではなく、『検証済みの資産』である」

このマインドセット、めちゃくちゃ大事です。

特に海外。アメリカのスタートアップとかならまだしも、ヨーロッパの多くの国では、「新しいこと」よりも「安定して動くこと」に、日本人が想像する以上に重きを置きます。

彼らにとって、この10年動いてるWPFアプリは「ゴミ」じゃないんです。「宝」なんです。

だから、「こんな古いの、イケてないんで、最新のWeb技術で全部作り直しましょう！」なんて提案したら、どうなるか。

「は？君、何言ってるの？今、完璧に動いてるものを、なんでわざわざリスク取って壊す必要があるんだい？バグ出たら、君が全責任取ってくれるのか？」

って、一蹴されます。ガチで。

これ、日本にいると「技術的負債の返済」とか「モダナイゼーション」って言葉で、リプレイスが正義みたいに語られること、多くないですか？

もちろん、それが必要な場面もある。

でも、「今、価値を生み出しているコード」に対するリスペクトが、こっちは半端ないんです。

じゃあ、古いコードを一生塩漬けにして、メンテだけし続けるのか？

WPFエンジニアは、そういう「守り」の仕事しかできないのか？

いや、全く違います。

ここからが、今回のブログの核になる「フック」の話。

“Future-Proofing Your Legacy: A Strategic Mindset”

（あなたのレガシーを未来対応させる：戦略的マインドセット）

そう、僕ら「レガシー」と呼ばれる技術（C#やWPFも含む）を知るエンジニアの本当の仕事は、「作り直す」ことじゃない。

今ある「検証済みの資産（レガシー）」を尊重しつつ、それを「未来の要求」にも耐えられるように、賢く「進化」させていくことなんです。

このブログシリーズで僕が皆さんに提供したいのは、まさにこの「戦略的マインドセット」。

具体的には、

「どうやって、その10年モノのレガシーシステムと共存する、長期的なアーキテクチャのロードマップを描くか？」

「”安定第一”のアプローチを適用しながら、どうやって未来の需要に備えるか？」

「（僕らみたいな）アーキテクトやシニアエンジニアが、どうやって”高価な革命（＝全部リプレイス）”じゃなくて、”賢い進化（＝部分的な改善）”を会社に提唱していくか？」

これって、ただの技術論じゃないんです。

ぶっちゃけ、これからのエンジニアにとって、最強の「サバイバル術」であり「人生術」だと、僕は本気で思ってます。

だって、考えてみてください。

新しいフレームワークなんて、毎年出ては消えていくじゃないですか。

でも、「今ある動いているシステムを、どうやって安全に、効率よく、未来に繋げるか」っていうスキルは、10年後も20年後も、絶対に腐らない。

特に、C#とWPFで培われる「ステートフル（状態を持つ）なクライアントアプリ」の設計思想や、「堅牢なエンタープライズ・アーキテクチャ」の知識は、形を変えて、Webでもクラウドでも、絶対に活きてきます。

この「起」のセクションでは、まず皆さんに「レガシー、怖くないよ」「WPF、オワコンじゃないよ」っていう、マインドセットの転換をしてもらいたかったんです。

海外で働くってことは、こういう「キラキラしてないけど、超重要なシステム」と向き合うことの連続でもあります。

そこで「うわ、レガシーだ」って絶望するか、「なるほど、これが会社の心臓か。どうやって進化させてやろうか」ってワクワクするか。

この差が、あなたのエンジニアとしての市場価値を、めちゃくちゃ左右します。

次の「承」のセクションでは、じゃあなんで「全部リプレイス」っていう「高価な革命」が、多くの現場で失敗するのか？

そして、僕らが取るべき「安定第一」のアーキテクチャ思考（Stability-First Approach）って、具体的にどういうことなのかを、僕がやらかした失敗談も交えながら、深く掘り下げていこうと思います。

乞うご期待！

なぜ「全部リプレイス」は失敗するのか？安定第一のアーキテクチャ思考

どうも、ケンです。「起」のパート、読んでくれました？

「10年モノのWPFアプリは、ゴミじゃなくて『宝』だ」

「レガシーは『検証済みの資産』だ」

っていう、マインドセットの話をしました。

とはいえ、ですよ。

そうは言っても、エンジニアの性（さが）として、「うわ、このコードひどいな…全部書き直してぇ…」って思う瞬間、ありますよね。

僕もWPFのコードビハインドに5000行のイベントハンドラが書いてあるのを見た時、一瞬、ディスプレイを閉じようかと思いましたもん（笑）。

「こんなメンテ不能なもの、置いておくだけ無駄！」

「最新の.NET 8とMAUI (もしくはBlazor) で、サクッと作り直した方が、絶対に幸せになれる！」

この「全部リプレイス（作り直し）したい」っていう誘惑。

これを、僕は「高価な革命（Expensive Revolution）」って呼んでるわけですけど、なんでこれが「高価」で、そして「大抵失敗する」のか。

今日は、僕がこっち（海外）に来て、まだイケイケだった頃にやらかした、ガチの失敗談をシェアします。これ、マジで皆さんの「人生術」として役立つはずなんで、心して読んでください（笑）。

---

あれは、僕が今の会社じゃなくて、別のクライアント先に常駐してた時のこと。

そこにもあったんですよ。「秘伝のタレ」みたいになってる、古いWPFアプリが。

そいつは、ある特定の（でも超重要な）顧客向けの、見積もり作成ツールでした。

UIはまぁ…うん、って感じ。XAMLもぐちゃぐちゃ。でも、動いてはいた。

当時の僕は、まだ「レガシー＝悪」っていう思想が抜けきってなかったんですね。

「ケン、これ見てくれよ。このアプリ、新しいOS（Windows 11とか）で動かすと、たまに挙動がおかしいんだ。ついでに、新しい見積もりロジックも追加したいんだけど、もう誰も触れなくて…」

とマネージャーに相談されたんです。

チャンス！と思いましたね。

「これ、コードベースが古すぎます。メンテナンスするより、Web APIとReact（当時はそれが流行ってた）で作り直しましょう！6ヶ月もあれば、ピカピカのWebアプリができますよ！そしたらスマホからでも見積もり作れますし！」

僕は自信満々に提案しました。

マネージャーは最初渋ってたんです。「今動いてるものを、わざわざ…？」って。

でも、僕は「技術的負債」とか「スケーラビリティ」とか、それっぽい横文字を並べて、なんとか説得したんです。「革命」を起こそうとしたわけです。

そして、プロジェクトは始まった。

最初の1ヶ月は、最高でした。

クリーンなアーキテクチャ、新しいCI/CDパイプライン、イケてるUI。

「やっぱ、作り直して正解っすよ！」なんて、チームで盛り上がってました。

地獄が始まったのは、3ヶ月目からです。

僕らが「ピカピカのWebアプリ」を作っている間も、当然ながら、ビジネスは止まらない。

例の「古いWPFアプリ」には、相変わらず「今すぐ対応しろ」っていう緊急の修正依頼が来るんです。

「あ、ケン。悪いけど、A社向けの特別割引ロジック、今月から料率変わったから、古いアプリの方、直しといてくれる？」

え？そっちも直すの？

僕らは新しいの作ってるのに？

でも、ビジネスは待ってくれない。

結局、古いWPFアプリのコード（あの5000行のコードビハインド）を、泣きながら解読して修正するハメになりました。

一方で、新しいWebアプリの開発も進めなきゃいけない。

もう、この時点でカオスです。

そして、最悪の事態が発覚します。

古いWPFアプリのロジックを、新しいWebアプリに移植しようとした時。

誰も、そのロジックの「すべて」を理解していなかったんです。

「この計算式、なんでここで『1.05』を掛けてるんですか？」

「さあ…？10年前に辞めたハンスさん（仮名）が書いたコードだから…でも、これがないと、なぜかB社の請求額が合わなくなるんだよ」

これです。

「全部リプレイス」が失敗する最大の理由。

それは、**「10年分の暗黙知（ドキュメント化されてない、担当者の頭の中にだけあったノウハウや、バグ修正の歴史）を、完全になめていた」**からです。

僕らが「ひどいコード」だと思ってた5000行のロジックは、「ひどい」んじゃなくて、「10年分のビジネスの例外処理とエッジケースの塊」だったんです。

月末にだけ動く謎の処理。

特定の顧客コードの時だけ適応される謎のフラグ。

それこそが、会社が10年間かけて培ってきた「検証済みの資産」の正体だった。

仕様書？そんなもの、とっくに更新されてません。

「ソースコードが、仕様書」だったんです。

結局、どうなったか。

6ヶ月で終わるはずだったプロジェクトは、古いWPFアプリのロジックを解読する「リバース・エンジニアリング」作業に大半の時間を費やし、1年半かかりました。

予算は3倍に膨れ上がりました。

そして、リリースされたWebアプリは…バグだらけでした。

「古いアプリだと、この見積もり1000ユーロだったのに、新しいアプリだと998ユーロになるぞ！何が起きてるんだ！」

…ええ、あの「1.05」の掛け算とか、そういう「暗黙知」の移植漏れが、無限に出てくるんです。

もう、お分かりですよね。

これが「高価な革命」の末路です。

---

じゃあ、どうすればよかったのか？

ここで、僕が血反吐を吐きながら学んだ「人生術」が出てきます。

それが、「安定第一 (Stability-First)」のアプローチです。

これは、「何もしない」って意味じゃないですよ。

医者の「ヒポクラテスの誓い」と一緒です。

「まず、害をなすなかれ (First, do no harm)」

僕らが向き合ってるシステムは、会社の「心臓」なんです。

心臓が動いてる（＝ビジネスが回ってる）のに、「ちょっと動きが古いんで、最新の人工心臓に交換しましょう！」とか言って、いきなり心臓を止めちゃダメなんです。

僕らがやるべきだったのは、「バイパス手術」です。

心臓（＝古いWPFアプリ）は、動かし続ける。絶対に止めない。

その代わり、新しい機能（＝新しい見積もりロジック）が必要になったら、それは「別」の場所に、新しいサービス（例えば、C#で書いたWeb API）として作る。

そして、古いWPFアプリから、その「新しいAPI」を「呼び出す」ように、そーっと繋ぎ変える。

これなら、リスクは最小限です。

最悪、新しいAPIがバグってても、古いロジックに戻せばいいだけ。心臓は止まらない。

この「安定第一」のマインドセット。

これこそ、海外のマネージャーやクライアントが、エンジニアに一番求めている価値なんです。

彼らは、ピカピカの技術より、「ビジネスが止まらないこと」を、100倍重視します。

「ケン、君の提案は、ビジネスのリスクをちゃんと考えてくれてるね」

こう言われるエンジニアになれるかどうか。

「全部リプレイス」っていう「革命」を夢見るエンジニアは、ある意味「無責任」です。

「検証済みの資産」をリスペクトし、どうやって「安定」を保ったまま「進化」させるかを考える。

それこそが、僕らC# / WPFっていう「堅牢なシステム」を知ってるエンジニアが、海外で発揮できる最大のバリューなんです。

次の「転」のセクションでは、じゃあ具体的に、この「安定第一」のバイパス手術をどうやるのか。

「心臓」であるWPFアプリを活かしつつ、「賢く進化」させるための、僕らアーキテクトの具体的なテクニック（あの「絞め殺しのイチジク」とか「腐敗防止層」とかの話）を、C#のコードも交えながら、ガッツリ解説していきます。

C#とWPFは「枯れて」いない。「進化」させるアーキテクトの役割

どうも、ケンです。「承」のパートで、僕がやらかした「全部リプレイス（高価な革命）」の地獄、読んでいただけたでしょうか（笑）。

あの見積もりツールの一件で、僕は骨身にしみて学びました。

「10年分の暗黙知をなめるな」

「ビジネス（心臓）を止めるな」

「エンジニアのエゴ（ピカピカの技術使いたい）より、まずは安定第一 (Stability-First) だ」

と。

じゃあ、どうすればよかったのか？

「承」の最後で、「バイパス手術」って話をしましたよね。

心臓（＝レガシーなWPFアプリ）は動かし続けたまま、新しい血管（＝新しい機能やWeb API）をそーっと繋ぎ込んで、血流（＝ビジネス価値）を改善していくアプローチです。

今日は、この「バイパス手術」を、僕らC# / WPFエンジニアがどうやって「安全」かつ「賢く」実行していくのか、その具体的な戦術（アーキテクチャ・パターン）を2つ、紹介します。

これ、マジで海外の現場で「お、こいつ分かってるな」と思われるための必須スキルなんで、コーヒーでも飲みながら、じっくり読んでください。

---

戦術その1：すべては「通訳」から始まる。「腐敗防止層 (Anti-Corruption Layer)」

「バイパス手術」って言っても、いきなり古いWPFアプリ（.NET Framework 3.5とか）から、最新の.NET 8で動くWeb APIを叩こうとすると、十中八九、問題が起きます。

なぜか？

**「文化（データ構造）が違いすぎる」**からです。

古いWPFアプリ（僕が「心臓」と呼んでるやつ）の中って、だいたいこんな感じじゃないですか？

• Customerっていうクラスがあるんだけど、なぜかプロパティが150個ある（God Object）。
• 顧客住所も、Address1, Address2, Address3…みたいに、全部ベタ書き。
• 状態（ステート）の管理がカオス。GlobalStaticVariables.IsSpecialMode = true; みたいなのが、コードビハインドのあちこちに散らばってる。

一方で、僕らが新しく作るWeb APIは、クリーンでいたいですよね。

• CustomerDtoは、必要なIDと名前だけ。
• 住所はAddressDtoっていう別のクラスに分けたい（正規化）。
• APIはステートレス（状態を持たない）に設計したい。

ここで、「承」の僕みたいに、古いWPFアプリから、この新しいAPIを「直接」呼び出そうとすると、どうなるか。

古いWPF側で、あの150個のプロパティを持つCustomerオブジェクトから、必死こいて新しいCustomerDtoとAddressDtoを組み立てるロジックを書くハメになります。その「変換ロジック」が、あの5000行のコードビハインドに、さらに追加されるんです。

地獄ですよね。

逆に、新しいAPI側が「忖度」して、「古いアプリが使いやすいように」と、150個のプロパティを持つLegacyCustomerDtoみたいなのを受け入れ始めたら…

おめでとうございます。新しいAPIが、古いシステムに「腐敗」させられました。

これを防ぐのが、**「腐敗防止層（Anti-Corruption Layer = ACL）」**です。

難しく考えなくていいです。要は「通訳」です。

古いWPFアプリと、新しいWeb APIの「間」に、専用の「通訳クラス（あるいは、専用のクラスライブラリ・プロジェクト）」を一個だけ作るんです。

<-> [Anti-Corruption Layer (Translator)] <-> [New Web API]]

この「通訳 (ACL)」の仕事は、たった2つ。

1. 古いWPFアプリから、「古くてカオスなデータ（あのGod Objectとか）」を受け取る。
2. それを、新しいAPIが喜ぶ「クリーンなデータ（DTO）」に翻訳して、APIを呼び出す。
3. （逆も然り）APIから返ってきたクリーンなデータを、古いアプリが理解できる形式に翻訳して返す。

例えば、C#で書くと、こんなイメージです。

WPFのコードビハインド側は、もう「通訳」を呼ぶだけ。

C#

// --- 古いWPFのコードビハインド (例: MainWindow.xaml.cs) ---
// ※こいつは .NET Framework 3.5 かもしれない

// ACL (通訳) をインスタンス化
private readonly QuotationACL _translator = new QuotationACL();

private void CalculateButton_Click(object sender, RoutedEventArgs e)
{
    try
    {
        // 1. 古いUIから、古いデータオブジェクトを作る
        var legacyRequest = new LegacyQuotationRequest
        {
            CustomerCode = txtCustomer.Text, // "A-001" みたいな古いコード
            PriceA = decimal.Parse(txtPriceA.Text),
            // ... 他にもカオスなデータが50個 ...
        };

        // 2. 「通訳」に丸投げする (ここが最重要！)
        //    コードビハインド側は「どうやってAPIを呼ぶか」
        //    「どうやってデータを翻訳するか」を一切知らない。
        NewPriceResponse response = _translator.GetNewPrice(legacyRequest);

        // 3. 結果をUIに反映
        lblNewPrice.Content = response.TotalPrice.ToString();
    }
    catch (Exception ex)
    {
        // 通訳がエラーを処理してくれる
        MessageBox.Show("エラーが発生しました: " + ex.Message);
    }
}

で、「通訳」であるACL（これは別プロジェクト。こっちは.NET Standard 2.0とか、.NET Framework 4.8とか、少し新しくてもいい）の中身はこうなります。

C#

// --- ACL (腐敗防止層) のクラス (例: QuotationACL.cs) ---
// ※こいつが「翻訳」と「API呼び出し」の汚れ仕事を引き受ける

public class QuotationACL
{
    // 最新の.NET 8で動いてるAPIを叩くクライアント
    private readonly HttpClient _newApiClient;

    public QuotationACL()
    {
        _newApiClient = new HttpClient { BaseAddress = new Uri("https://new-api.mycompany.com/") };
        // (本当はHttpClientはstaticかDIすべきだけど、イメージとして)
    }

    // 「通訳」メソッド
    public NewPriceResponse GetNewPrice(LegacyQuotationRequest oldRequest)
    {
        // 1. 「翻訳」開始 (ここがACLの心臓部)
        //    古いカオスなデータを、新しいクリーンなDTOに変換する
        var newApiRequest = new NewApiRequestDto
        {
            // 「暗黙知」だったコード変換ロジックを、ここに集約！
            ClientId = ConvertLegacyCodeToNewId(oldRequest.CustomerCode),
            Items = new List<ItemDto>
            {
                new ItemDto { Sku = "SKU-A", Price = oldRequest.PriceA },
                // ... 複雑なマッピング ...
            }
        };

        // 2. 新しいAPIを呼び出す (WPF側はこれを知らない)
        // (※ 本当は非同期 (async/await) でやるべきだけど、
        //    古いWPFに組み込む都合上、あえて同期で書くことも現場では多い)
        var httpResponse = _newApiClient.PostAsJsonAsync("api/v1/calculate", newApiRequest).Result;

        if (!httpResponse.IsSuccessStatusCode)
        {
            // エラー処理も「翻訳」する
            throw new Exception("新しい見積もりAPIでエラーが発生しました。");
        }

        // 3. 結果を翻訳して返す
        var apiResult = httpResponse.Content.ReadAsAsync<NewApiResponseDto>().Result;
        return new NewPriceResponse { TotalPrice = apiResult.CalculatedPrice };
    }

    // 「暗黙知」だったロジックは、この通訳の中に封じ込める
    private string ConvertLegacyCodeToNewId(string oldCode)
    {
        if (oldCode == "A-001") return "CUST_10001";
        // ... (10年分の秘伝のタレ) ...
        return "UNKNOWN";
    }
}

// --- 古いアプリとACLが使う、共通の戻り値 (イメージ) ---
public class NewPriceResponse
{
    public decimal TotalPrice { get; set; }
}

// --- (参考) 新しいAPIが使うDTO (ACLだけが知ってる) ---
internal class NewApiRequestDto
{
    public string ClientId { get; set; }
    public List<ItemDto> Items { get; set; }
}
// ... (以下略) ...

どうです？

これだけで、古いWPFアプリ（コードビハインド）は、汚い翻訳ロジックやAPI呼び出しの詳細から解放されました。

そして、新しいAPIも、古いカオスなデータ構造に「腐敗」させられることなく、クリーンな設計を保てます。

これが「賢い進化」の第一歩です。

---

戦術その2：「絞め殺しのイチジク (Strangler Fig)」で、乗っ取れ

ACL（腐敗防止層）で「連携」ができるようになったら、次はいよいよ「置き換え」です。

でも、「全部リプレイス」はダメ、って言いましたよね。

そこで使うのが、**「絞め殺しのイチジク (Strangler Fig)」**パターンです。

マーティン・ファウラーが提唱した、超有名なパターン。

熱帯雨林にあるイチジクの木は、まず大きな木（ホスト）に「ツタ」として巻きつくんですよ。

で、ツタはどんどん太く、強くなって、栄養を吸い取りながら、ホストの木を「覆い尽くして」いく。

そして何十年も経つと、中のホストの木は枯れてなくなり、ツタだったイチジクの木が、新しい大木としてそこに立っている。

これを、システムに例えるんです。

• ホストの木: レガシーなWPFアプリ（心臓）
• ツタ: 新しい機能（Web APIや、新しいWeb UI (Blazorとか)）

「全部リプレイス」は、ホストの木をいきなり切り倒そうとして、生態系（ビジネス）を破壊する行為です。

「絞め殺しのイチジク」は、違います。

ホストの木（WPF）は、活かし続けます。

1. ステップ1 (連携): まず、「見積もり計算」機能だけ、新しいWeb APIとして作ります。そして、ACL（さっきの通訳）経由で、WPFからそれを呼び出すようにします。（＝最初のツタを巻き付ける）
2. ステップ2 (置き換え): 次に、「顧客管理」機能。これはUIごと新しくしたい。じゃあ、Blazor Serverあたりで、ピカピカの「顧客管理Web画面」を作ります。
3. ステップ3 (乗っ取り): 古いWPFアプリのメインメニューにある「顧客管理」ボタン。これを押した時の動作を、変えちゃうんです。
   • （旧）古いWPFの顧客管理画面（Windows.Forms.Formとか）を開く
   • （新）新しく作ったBlazorのWeb画面を、ブラウザで開く。 ( Process.Start("https://new-crm.mycompany.com/...") )
4. ステップ4 (繰り返す): これを、「商品管理」「在庫管理」「請求書発行」…と、機能単位で、一つ、また一つと、新しいWebサービスやWeb画面に置き換えていきます。

これを繰り返していくと、どうなるか。

1年後、古いWPFアプリの機能は、半分くらいが新しいWebサービスへの「リンク集」みたいになってます。

でも、ビジネスは止まってない。ユーザーは、機能ごとに新しいUIに少しずつ慣れていけます。リスクも分散されてる。

そして3年後。

ついに、古いWPFアプリのすべての機能が、新しいサービス（ツタ）に置き換えられました。

古いWPFアプリ（ホストの木）に残ってるのは、メインメニュー（ランチャー）だけ。

その時こそ、レガシーシステムが「引退」する時です。

ホストの木は、静かに枯れていく（アンインストールされる）。

誰も困らない。なぜなら、すべての機能は、すでに新しいツタ（Webサービス群）によって、完全に置き換えられているから。

---

これが、「高価な革命」じゃなくて、**「賢い進化」**です。

そして、気づきましたか？

この「ACL」や「Strangler Fig」戦略において、僕らC# / WPFエンジニアのスキルが、どれだけ重要か。

WPFは、オワコンじゃないんです。

「賢い進化」を支える、最強の「ハブ（拠点）」であり、「ホストの木」なんです。

• 安定性: 10年動いてるWPFは、これ以上ないくらい「安定」してます。
• 連携力: C# (.NET Framework) は、最新の.NET 8のAPIだろうが、gRPCだろうが、何でもござれで呼び出せます。ACL（通訳）を書くのに、C#ほど適した言語はありません。
• 資産: ローカルPCのプリンタや、工場に繋がってる特殊なシリアルポート機器を制御するロジック。こういうのはWebじゃ（まだ）難しい。WPF/C#が「資産」として持ってる部分です。

僕らアーキテクトやシニアエンジニアの本当の役割は、

「WPFは古いから、捨てましょう！」と「革命」を叫ぶことじゃない。

「今動いているこのWPFという『資産』を『ハブ』にして、ACLとイチジクの木パターンを使い、ビジネスを止めずに、3年計画でシステムを『進化』させましょう」

と、具体的なロードマップを描き、経営陣やマネージャーに**「提唱」**することなんです。

「転」はここまで。

最後の「結」では、この「賢い進化」を提唱できるエンジニアになることが、僕ら自身のキャリア、つまり「人生術」として、どれだけ最強の「Future-Proofing（未来対応）」になるのか、という話をします。

高価な「革命」より賢い「進化」を。未来の自分を助けるキャリア術

どうも、ケンです。

いやー、長かったですね（笑）。でも、ここまで読んでくれたってことは、あなたも「レガシーシステム」っていう、この深くて面白い沼に、片足くらいは突っ込む覚悟ができたんじゃないでしょうか。

軽く振り返ってみましょう。

• 「起」： 10年モノのWPFアプリは「ゴミ」じゃない。「検証済みの資産（お宝）」なんだ、っていうマインドセットの転換をしました。
• 「承」： 「全部リプレイス（高価な革命）」がいかに危険か、僕の失敗談で学びましたね（笑）。心臓（ビジネス）を止めるな、「安定第一 (Stability-First)」が鉄則だと。
• 「転」： じゃあどうする？の答えとして、「腐敗防止層 (ACL)」っていう”通訳”と、「絞め殺しのイチジク (Strangler Fig)」っていう”乗っ取り”戦術、この2つの「賢い進化」のテクニックをC#のコード交じりで解説しました。

そして今日、この「結」で、僕がこのブログシリーズを通して、これから海外で働きたいC# / WPFエンジニアの皆さんに、一番伝えたかった「人生術」について話します。

フックの最後の一文を、もう一度見てみましょう。

“The architect’s role in advocating for smart evolution over expensive revolution.”

（高価な革命よりも、賢い進化を「提唱」する、アーキテクトの役割）

これ、単なるプロジェクト管理論じゃないんです。

これこそが、僕らエンジニアの「キャリアを未来対応させる (Future-Proofing)」最強の戦略なんです。

---

考えてみてください。

世の中には、大きく分けて2種類のエンジニアがいると、僕は思ってます。

1. 「革命家（Revolutionist）」タイプのエンジニア

彼らは、常に新しい技術を追いかけています。

「レガシーは悪だ」「全部ReactとGoで書き直すべきだ」

「WPF？まだ使ってんの？（失笑）」

こういう人たちです（昔の僕だ…耳が痛い…）。

彼らは、ピカピカのスタートアップで、ゼロからモノを作るのは得意です。

でも、3年経って、自分たちが作ったそのシステムが「レガシー」になり始めた頃、彼らは飽きて、また次のピカピカの現場（革命）を求めて去っていきます。

彼らは、「育てる」とか「進化させる」っていう視点が、根本的に欠けていることが多い。

2. 「進化論者（Evolutionist）」タイプのエンジニア

彼らは、まず「今、動いているもの」にリスペクトを持ちます。

「この10年モノのWPFアプリが、どうやって会社の心臓として動いてきたのか」を理解しようとします。

そして、「承」で学んだ「暗黙知」や「安定性」という価値を、絶対に捨てません。

その上で、「転」で学んだ武器（ACLやStrangler Fig）を使って、

「この『お宝』を活かしつつ、どうやって未来の要求（Web対応とか、クラウド化とか）に応えていくか」

という、「賢い進化」のロードマップを描くことができます。

---

さて、これからあなたが海外で働こうとするとき。

特に、ヨーロッパの歴史ある製造業や、アメリカでも大手のエンタープライズ企業に入ろうとするとき。

彼らが喉から手が出るほど欲しがっているのは、どっちのエンジニアだと思いますか？

圧倒的に、「進化論者」です。

なぜなら、世の中の99%の会社は、「ゼロから作る」ことよりも、「今ある資産を、どうやって安全に、安く、未来に繋げるか」という問題で、毎日頭を抱えているからです。

「革命家」は、会社のマネージャーにこう言います。

「全部捨てて、作り直しましょう。5億円と3年ください。バグは出るかもだけど、イケてるシステムができますよ」

…こんなの、ギャンブルですよね。

「進化論者」は、こう言います。

「あなたの『心臓』は動かし続けます。まず、”通訳”（ACL）を2週間で作って、一番要望の多い『見積もり計算』だけ、新しいAPIに繋ぎます。リスクは最小限です」

「そして、3年計画の『イチジクの木』プランを立てました。これなら、毎年1億円ずつ、3年間で、ビジネスを一度も止めずに、システムを丸ごとWebに移行できます。途中で止めることも可能です」

あなたがマネージャーなら、どっちのエンジニアに、自分の会社の「心臓」を任せたいですか？

どっちのエンジニアに、高い給料を払ってでも、チームに残ってほしいですか？

---

僕が言いたいのは、これです。

「C#とWPFを知っている」ということは、決して「古いエンジニア」だということじゃない。

それは、**「エンタープライズの『心臓』を触れる、数少ないエンジニア」**だっていう、最強の「証明書」なんです。

多くのWeb系エンジニア（革命家タイプ）は、WPFや.NET Frameworkの「お宝」に触りたがりません。怖いですから。

でも、僕らは触れる。僕らはC#を知っている。僕らは「心臓」の構造を理解できる。

だからこそ、僕らは「革命家」にはなれない、「進化論者」という、超ハイバリューなポジションを取れるんです。

古い世界の言葉（WPF, .NET Framework, 10年分の暗黙知）と、新しい世界の言葉（.NET 8, Web API, Blazor, クラウド）の両方を話せる、「通訳」であり「アーキテクト」になれる。

これこそが、僕がこのブログで伝えたかった、一番「得する情報」であり「人生術」です。

Future-Proofing Your Legacy

（あなたのレガシーを、未来対応させる）

この「レガシー」っていうのは、古いWPFアプリのことだけじゃありません。

僕らエンジニア自身の「キャリア（Legacy）」のことでもあるんです。

新しいフレームワークを追いかけるだけの「革命家」のキャリアは、そのフレームワークが廃れたら終わってしまいます。

でも、「今ある価値を、未来に繋げる」という「進化論者」のスキルは、10年後も20年後も、絶対に廃れません。

なぜなら、**「システムは、必ず古くなる」**からです。これは、技術界における唯一の「真実」です。

だから、胸を張ってください。

僕らのC#とWPFのスキルは、「賢い進化」を提唱できる、最強の武器です。

その武器を持って、「高価な革命」で悩んでいる海外の企業を、助けに行ってやりましょう。

それが、僕ら自身のキャリアを「未来対応」させる、一番確実な道だと、僕は信じています。

最後まで読んでくれて、ありがとうございました！