ハロー、皆さん。元気にコードを書いていますか？
僕は今、海外の技術拠点でC#とWPFを武器に、かなり巨大なデスクトップアプリケーションの設計・開発を担当しています。こっちに来て数年が経ちますが、日本にいた頃よりも痛感していることがあります。それは、**「エンジニアの真の敵は、新規開発ではなく、自分たちが過去に書いたコード（レガシー）である」**という冷酷な事実です。
今回は、僕が海外のガチの現場で血を流しながら学んだ「生き残るための生存戦略」、特にレガシーな巨大システムをどうモダンに作り変え、かつ「二度とレガシーと呼ばせない」ようにするか、という思考法を共有します。
1. 終わらない「蘇生作業」からの脱却：なぜ僕らはレガシーに殺されるのか
海外、特に北米や欧州のテック企業で働いていると、日本以上に「スピード」と「ROI（投資対効果）」に対してシビアです。「動いているから触るな」なんていう文化は、ここにはありません。むしろ「動いているけどメンテナンスコストが高いなら、それは負債（Debt）だ。今すぐなんとかしろ」と突きつけられます。
僕が今のチームに参加した初日のことを今でも覚えています。渡されたのは、10年以上継ぎ足し続けられた「秘伝のタレ」状態で膨れ上がったWPFのプロジェクトでした。MVVMは崩壊し、.NET Framework 4.5という骨董品のような環境。ビルドには15分かかり、一つのバグを直せば三つの新しいバグが生まれる、まさに「エンジニアの墓場」でした。
その時、僕のボスであるシニアアーキテクトが放った言葉が、僕のキャリアを決定づけました。
「このシステムを『蘇生』させるんじゃない。二度と死なない『エコシステム』に作り変えるんだ。Beyond Revival（蘇生を超えろ）だぞ」
「蘇生（Revival）」と「近代化（Modernization）」の決定的な違い
多くのエンジニアは、古いシステムを前にすると「リファクタリングして今風に動かそう」と考えます。これが蘇生です。しかし、テクノロジーの進化のスピードは、僕らがコードを書き直すスピードよりも圧倒的に速い。
僕らエンジニアが本当に戦うべきは、特定の古いコードではなく、**「コードが古くなっていくという現象（ソフトウェア・エントロピー）」**そのものです。海外で求められるのは、単に古いものを新しくするスキルではなく、「常に新しくなり続ける仕組み」を設計に組み込む能力なのです。
2. モダン化を「仕組み」に組み込む：継続的パイプラインの構築
「二度とレガシーと呼ばせない」ためには、リファクタリングを特別なイベントにしないことが重要です。海外の強いチームでは、近代化は呼吸をするのと同じくらい、日々の開発プロセスに溶け込んでいます。
① 依存関係の「鎖」を断ち切る：抽象化の徹底
WPFプロジェクトがレガシー化する最大の原因は、UIとロジック、外部ライブラリの「密結合」です。古いサードパーティ製コントロールに依存しすぎてアップグレードできない……というのは典型的な「負債」です。
僕が最初に行ったのは、すべての外部依存を**「インターフェース」の背後に隠すこと**でした。DI（Dependency Injection）コンテナを用いて実装を差し替え可能にすることで、数年後に優れたライブラリが登場した際、古いパーツを捨てて新しいものに差し替えるだけでアップグレードが完了します。
② ボーイスカウト・ルールをCI/CDへ
「キャンプ場は、来た時よりも美しくして帰る」というルールをCI（継続的インテグレーション）に組み込みます。海外の現場では、プルリクエスト（PR）で「ついでにここをモダンな書き方に変えよう」という指摘が日常的に飛び交います。
- Roslyn Analyzersの導入： 古い構文を見つけたらビルドエラー、あるいは警告を出す。
- SonarQubeによる静的解析： 「コードの臭い（Code Smell）」を自動検知し、技術負債の積み増しを阻止する。
③ プラットフォーム依存を排した「ピュアなコア」
WPFの型（VisibilityやUIElementなど）に依存したViewModelは、将来の移行を阻害します。ロジックをピュアな .NET クラスライブラリとして切り出し、プラットフォームに依存しない「コア」を作る。これが、将来の「蘇生作業」を不要にする究極の防衛策です。
3. エンジニアの価値を数字で証明する：技術負債のKPI管理
どんなに素晴らしい設計も、ビジネスサイドの合意がなければ実行できません。海外のシニアな現場では、感情論ではなく「数字」が求められます。
技術負債を「利息」という言葉に翻訳する
僕は技術負債の話をする際、必ず「利息（Interest）」という概念を使います。
「この古いライブラリを使い続けると、新機能を実装するたびに通常の1.5倍の時間がかかります。この『0.5倍分』が、僕たちが今支払っている負債の利息です」
これを証明するために、以下の**「Innovation vs. Maintenance（イノベーション対保守）」の比率**をKPIとして可視化しました。
| カテゴリ | 内容 | 目標比率 |
| Innovation | ユーザー価値に直結する新機能開発 | 70%以上 |
| Maintenance | 負債対応・バグ修正・インフラ維持 | 30%以下 |
Google スプレッドシートにエクスポート
イノベーション速度（Velocity）の可視化
「サイクルタイム（機能がバックログに載ってからユーザーに届くまでの時間）」を計測します。レガシーなコードが原因でビルドに1時間、テストに3日かかっているなら、そのサイクルタイムの改善こそがビジネス価値です。「このモダン化でサイクルタイムを5日から2日に短縮できる」というプレゼンは、非エンジニアのステークホルダーにも強烈に刺さります。
ROI=モダン化に要したコスト節約された開発工数×エンジニアの単価
この数式を背景に持つだけで、リファクタリングは「エンジニアのわがまま」から「戦略的投資」へと昇格します。
4. 変化を愛する設計思想：過去を糧に進化し続ける極意
最終的に行き着くべき場所は、完璧な設計ではありません。「未来は予測できない」と開き直り、いつでも捨てられる、いつでも変えられる設計をすることです。
「作る」ことよりも「捨てる」ことを設計する
設計を考えるとき、自分に問いかける魔法の質問があります。 「このモジュールが3年後にゴミになったとき、隣のコードを壊さずに30分で捨てられるか？」
海外のシニアエンジニアが愛用する言葉に “Design for Deletion（削除のための設計）” があります。不要になった古いパーツをサクッと「削除」できれば、システムは常に身軽でいられます。これこそが、蘇生を必要としない「新代謝し続けるシステム」の真髄です。
変化はリスクではなく「チャンス」
海外で働いていると、日本では考えられないスピードで方針転換（ピボット）が起こります。そんな時、「ロジックはピュアなC#で切り離してあるから、UIを差し替えるだけだね」と笑って返せる柔軟性。
変化を「避けるべきリスク」と捉えるか、「設計の柔軟性を試すチャンス」と捉えるか。このマインドセットの差こそが、異国の地で生き残るための最強の武器になります。
これから世界を目指すあなたへ
「海外で働く」ということは、多様な文化の中で「技術の価値を自分の言葉で定義し続ける」という冒険です。英語が完璧である必要はありません。しかし、「良いシステムとは何か？」「エンジニアの価値とは何か？」に対する自分なりの哲学は、英語以上に重要です。
レガシーコードを恐れないでください。それを仕組みと数字で攻略していくプロセスは、最高のエンターテインメントです。
The Future-Proofed Present —— 。
僕たちが今この瞬間、キーボードを叩いて生み出しているコードが、未来の誰かを苦しめる「呪い」ではなく、未来を切り拓く「翼」になるように。
Keep Coding, Stay Flexible!
コメント