幻の「壊れていないなら直すな」と、給与明細に載らない税金
海外のオフィス、雨の火曜日、そしてWPFの亡霊
窓の外は典型的などんよりとした冬の雨。ここ、海外のオフィスでも、エンジニアの朝はSlackの通知チェックと、温かいコーヒー、そしてVisual Studioの起動から始まります。
僕が現在担当しているプロジェクトは、創業から10年以上続く大規模なデスクトップアプリケーションです。C#、.NET Framework（最近やっと.NET 6へ移行中）、そしてWPF。技術選定としては手堅い。しかし、その中身は歴代のエンジニアたちが積み上げてきた「地層」のようなコードベースです。
ある日、新機能の実装のために、とあるViewModelのファイルを開きました。
MainWindowViewModel.cs。
行数は驚異の8,000行超え。
#region で折り畳まれた “Legacy Logic DO NOT TOUCH” という不穏なコメント。MVVMパターンを採用しているはずなのに、なぜかViewのコントロールを直接操作している形跡。バインディングのパスが複雑怪奇に絡み合い、一つのプロパティを変更すると、画面の反対側にある全く無関係なボタンが無効化されるという、バタフライエフェクトのような仕様。
僕はため息をつきながら、隣の席にいるテックリードのMike（仮名）に話しかけました。
「ねえMike、このクラス、流石に分割しない？ 依存関係がスパゲッティすぎて、単体テストも書けないよ」
Mikeはマグカップを片手に、慈愛に満ちた（あるいは諦めきった）目で僕を見て、あの「魔法の言葉」を放ったのです。
“If it ain’t broke, don’t fix it. (壊れてないなら、直すな)”
この言葉、皆さんも日本で、あるいはどこかの現場で耳にタコができるほど聞いたことがあるでしょう。特にSIerの現場や、納期に追われるスタートアップの修羅場で、この言葉は「正義」として語られます。
「動いているコードは資産だ」
「リスクを冒してリファクタリングして、デグレ（回帰バグ）を起こしたら誰が責任を取るんだ」
一見、理にかなっています。ビジネスサイドから見れば、動いている機能にお金をかけて手を加えるなんて、無駄遣いにしか見えません。しかし、私はここで断言します。
それは、幻想です。
海外の荒波の中でエンジニアとしてやってきて確信したことがあります。「壊れていないなら直すな」というマインドセットこそが、実はチームを崩壊させ、開発速度を殺し、そして何より、私たちエンジニアの市場価値を静かに、しかし確実に削り取っている最大の元凶なのです。
「壊れていない」の定義を疑え
そもそも、「壊れていない（Ain’t broke）」とはどういう状態を指すのでしょうか？
ユーザーがボタンを押して、期待通りの画面が出る。エラー落ちしない。確かに、表面的には「壊れていない」ように見えます。
しかし、その裏側で起きていることを想像してみてください。
- たった一行の修正をするために、その影響範囲を調べるのに3時間かかるとしたら？
- 新しく入った優秀なジュニアエンジニアが、コードの複雑さに圧倒されて自信を喪失し、3ヶ月で辞めてしまうとしたら？
- WPFのXAMLが複雑すぎて、デザイナーがUIを微調整するたびにエンジニアが付きっきりでサポートしなければならないとしたら？
これは、ソフトウェアとしては「動いている」かもしれませんが、**ビジネスツールとしては「壊れている」**のです。
車に例えてみましょう。エンジンはかかる。タイヤも回る。目的地には着く。
でも、燃費がリッター500メートルで、ハンドルを切るたびに異音がして、窓を開けるには特定のコツが必要で、修理できる整備士が世界に3人しかいない車。
これをあなたは「壊れていない車」と呼びますか？
私たちは往々にして、こういう車を「歴史ある基幹システム」と呼び、大切に乗り続けているのです。
「レガシーコード税」という概念
ここで、私が提唱したい（そして海外のカンファレンスやブログでもよく議論される）概念が**「レガシーコード税（Legacy Code Tax）」**です。
私たちは日々、コードを書くことで給料をもらっています。しかし、レガシーコードに触れるたび、私たちは目に見えない税金を支払わされています。
これは消費税のようなものです。何かアクションを起こすたびに、必ず上乗せされます。
- 機能追加税: クリーンなコードなら1時間で終わる機能追加が、依存関係の調査と「既存機能を壊さないための防衛的なコーディング」のために5時間かかる。この差分の4時間は、レガシーコード税です。
- 読解税: コードロジックを理解するために費やす時間。変な変数名、長すぎるメソッド、謎の副作用。これらを解読する時間は、価値を生んでいません。単なる納税です。
- 恐怖税: 「これを触ったら何かが壊れるかもしれない」という心理的ストレス。これは精神的な税金です。デプロイの金曜日に胃が痛くなるあの感覚です。
例えば、あなたの時給が5,000円だとしましょう。
クリーンな環境なら10時間（5万円）で終わるタスクが、レガシーコード税（税率200%）のせいで30時間（15万円）かかったとします。
差額の10万円。これは会社がドブに捨てたお金です。
しかし、恐ろしいのはここからです。
この税金は、会社だけが払っているわけではありません。
あなた自身も、あなたのキャリアという通貨で支払っているのです。
なぜ「あなた」が損をするのか？
「会社がお金を無駄にするのは勝手だ。僕は言われた通りに時間をかけて直すだけで、給料はもらえるんだからいいじゃないか」
そう思うかもしれません。特に日本の雇用慣行の中では、時間をかければかけるほど「頑張っている」と評価されることさえあります。
しかし、海外のテック業界、特に流動性の高い市場では、その考え方は致命的です。
1. スキルの陳腐化
レガシーコード税を払うための作業（スパゲッティコードの解読、手動テストの繰り返し、独自の奇妙なフレームワークの学習）に費やす時間は、市場価値のあるスキルを磨く時間ではありません。
WPFで言えば、最新の .NET の機能や、リアクティブプログラミング（Reactive Extensions）、美しいMVVMアーキテクチャの設計スキルではなく、「このプロジェクト固有のバグを回避する裏技」ばかり詳しくなっていく。
その知識は、一歩会社の外に出たら、1円の価値もありません。
2. 精神的エネルギーの浪費
エンジニアにとって、最も貴重なリソースは「集中力」と「創造性」です。
「どこを触ったら爆発するか分からない」地雷原を歩くような作業は、このリソースを激しく消耗させます。家に帰った後、サイドプロジェクトをやる気力が残っていますか？ 新しい技術書を読む元気がありますか？
レガシーコード税は、あなたのプライベートな学習時間という未来への投資原資さえも徴収していくのです。
3. “Get things done” 能力の低下
海外の評価面談（Performance Review）では、残酷なほど「成果」が問われます。「どれだけ苦労したか」ではなく「何を実現したか」。
レガシーコード税が高い環境に長く浸かっていると、どんなに優秀なエンジニアでも、アウトプットの速度は落ちます。「環境が悪かった」という言い訳は、転職市場では通用しません。あなたのレジュメには「5年かけてこれだけしかリリースできませんでした」という事実だけが残ります。
負債は複利で増える
金融の借金と同じで、技術的負債（Technical Debt）にも金利がつきます。
今日、「If it ain’t broke, don’t fix it」と言って見過ごしたその汚いコードは、明日にはもっと修正が難しくなっています。
なぜなら、その汚いコードの上に、さらに新しいコードが書かれるからです。
歪んだ土台の上に建て増しをすれば、建物全体が歪んでいきます。
私がWPFのプロジェクトで見た実例をお話ししましょう。
当初、画面遷移のロジックをViewModelに直接書いてしまうという小さな「借金」がありました。
「今は忙しいから、とりあえずこれで」
その結果、画面遷移のたびにメモリリークが発生するようになりました。
それを直すために、強制的にガベージコレクションを呼ぶという恐ろしいハックが追加されました。
さらにそのハックのせいで、画面がフリーズするようになり、非同期処理を無理やり同期的に待つコードが追加されました。
3年後、その部分は誰も触れない「聖域」となりました。
最初の段階でリファクタリングしていれば、半日で終わったはずです。
今、それを直すには、アプリケーション全体のアーキテクチャを刷新する、数ヶ月単位のプロジェクトが必要です。
これが、複利の効果です。
私たちは、何もしていないのに、ただ先延ばしにしただけで、支払うべき税金が指数関数的に増えていっているのです。
あなたはもう、支払っている
ここまで読んで、「ああ、うちのプロジェクトのことだ」と思ったあなた。
あなたは既に、多額のレガシーコード税を支払っています。
毎日感じる「開発が遅いな」という感覚。
「なんでこんなに調整ばかりしているんだろう」という徒労感。
それらは全て、過去の誰か（あるいは過去の自分）が借りた借金の利子です。
「じゃあ、どうすればいいの？ 明日から全部書き直すなんて無理だよ」
その通りです。いきなり革命を起こすことはできませんし、ビジネスを止めることもできません。
しかし、まずは**「このままでは損をするのは自分だ」**と自覚することから始まります。
「壊れていないなら直すな」という幻想を捨ててください。
コードは、書かれた瞬間から腐り始めます。
手入れをしなければ、雑草が生え、ツタが絡まり、やがて住めない廃墟になります。
海外の優秀なエンジニアたちは、この「見えないコスト」に対して非常に敏感です。彼らは、自分が税金を払わされることを極端に嫌います。だからこそ、彼らは戦います。コードレビューで、設計会議で、日々のコミットで。
次回の「承」では、この漠然とした「生きづらさ」や「開発の遅れ」を、より具体的な指標として解剖していきます。
チームのモラルがどう崩壊していくのか、オンボーディングコストがどれくらい無駄になっているのか。
数字と実例を交えて、この「サイレント・キラー」の正体をさらに暴いていきましょう。
この税金、いつまで払い続けますか？
それとも、節税対策（リファクタリング）、始めますか？
見えないコストの正体――モラル、オンボーディング、スピードの摩耗を数値化する
1. チームモラルの摩耗：魂を削る「千の切り傷」
海外のテック企業で働いていて、最も恐れられていることの一つが「Burnout（燃え尽き症候群）」です。
しかし、多くの人が誤解しています。エンジニアが燃え尽きるのは、単に長時間労働をしたからではありません。「自分の仕事に意味や進捗を感じられない時」に、心は折れるのです。
レガシーコード税の最も残酷な徴収方法は、この**「エンジニアの魂（Morale）」**からの天引きです。
WPFの現場でよくある光景を想像してみてください。
あなたは、ユーザーインターフェースのちょっとした修正依頼を受けました。「ボタンの色を変えて、クリック時のアニメーションを少し滑らかにする」。クリエイティブで楽しいタスクのはずです。
しかし、コードを開いた瞬間、絶望が襲います。
そのボタンは、標準の <Button> コントロールではなく、10年前に退職した誰かが作った CustomSuperButton という謎のクラスでした。
スタイルは App.xaml ではなく、なぜかデータベースから動的に読み込まれる設定値と、ハードコーディングされた色コードが複雑に絡み合って決定されています。
さらに、そのボタンの Click イベントハンドラの中には、なぜか会計処理のビジネスロジックが 500行にわたって直接記述されています。
「色を変えるだけ」のタスクが、「既存の会計ロジックを壊さないように慎重に解読し、影響範囲を調査する」という、地雷処理のようなタスクに変貌します。
これを私たちは**「Death by a thousand cuts（千の切り傷による死）」**と呼びます。
一つ一つは小さなストレスです。変数名が分かりにくい、単体テストがない、ビルドが遅い。
しかし、これが毎日、毎時間続くとどうなるか。
**「学習性無力感（Learned Helplessness）」**がチームを支配します。
「どうせキレイに書いても、既存のコードが汚いから意味がない」
「提案しても、調査に時間がかかりすぎると却下される」
結果、優秀なエンジニアほど先に辞めていきます。彼らは自分の市場価値を知っているからです。
残るのは、「汚いコードに慣れきってしまった（あるいは諦めた）人」だけ。これを**「Dead Sea Effect（死海現象）」**と呼びます。塩分濃度が高すぎて生物が住めない死海のように、毒性の高いレガシー環境では優秀な人材は蒸発し、塩（変化を拒む人材）だけが沈殿していくのです。
このコストは甚大です。採用コスト、トレーニングコスト、そして失われたイノベーション。これらは決して貸借対照表には載りませんが、確実に組織を殺します。
2. オンボーディングの泥沼：考古学者を雇っているわけではない
次に、**「オンボーディング（新人研修・定着）」**におけるコストを見てみましょう。
通常、シニアエンジニアを採用した場合、期待されるのは「入社1ヶ月目からバリバリ機能開発をしてくれること」です。
しかし、レガシーコード税率の高いプロジェクトでは、これが不可能です。
私が以前いたプロジェクトでの実話です。
新しく入った優秀な同僚、Alex（仮名）がいました。彼は最新の .NET Core や Azure の知識を持っていました。
しかし、彼が最初のプルリクエスト（PR）を出せるようになるまで、なんと3ヶ月かかりました。
なぜか？
開発環境のセットアップ手順書が5年前で更新が止まっていたからです。
ビルドを通すためには、特定の（既にサポート切れの）サードパーティ製ライブラリを、特定のフォルダ構成で配置し、レジストリを手動で書き換える必要がありました。
さらに、WPFの画面プレビュー（XAMLデザイナー）は、複雑すぎる依存関係のせいで表示されず、UIの確認は毎回ビルドして実行（起動に2分）しなければなりませんでした。
Alexの給料が月80万円だとしましょう。3ヶ月で240万円。
さらに、彼につきっきりで教えていた私の工数（メンターコスト）も合わせれば、会社は500万円近くを**「何も生産していない期間」**に支払ったことになります。
クリーンなアーキテクチャ、整備されたCI/CDパイプライン、コンテナ化された開発環境があれば、彼は初日の午後に最初のコミットができたはずです。
レガシーコードは、ソフトウェアエンジニアを**「考古学者」**に変えてしまいます。
私たちは、古代の遺跡（コード）を掘り起こし、当時の人々（退職したエンジニア）が何を考えてこの壁画（コメント）を残したのかを解読することに給料をもらっているわけではありません。
未来を作るために雇われているはずなのに、過去の解読にコストの9割を払っている。これが「オンボーディング税」の正体です。
3. 機能提供スピードの減速：アリスの「赤の女王」現象
3つ目のコストは、ビジネスサイドにも最も説明しやすい**「Velocity（開発速度）」**の低下です。
「昔はもっと早く機能追加できていたのに、最近はどうしてこんなに遅いんだ？」
マネージャーやプロダクトオーナーからこう言われたことはありませんか？
これこそが、技術的負債の複利効果です。
初期のフェーズ（グリーンフィールド）では、何も障害がないので爆速で走れます。
しかし、テストを書かず、リファクタリングをサボり、コピペで継ぎ接ぎしたコードが増えるにつれ、物理的な摩擦係数が増えていきます。
私はこれを、ルイス・キャロルの『鏡の国のアリス』に登場する「赤の女王」になぞらえて考えています。
“Now, here, you see, it takes all the running you can do, to keep in the same place.”
（ここではね、同じ場所にとどまるだけでも、全力で走り続けなきゃいけないのよ）
レガシーコードの泥沼の中では、エンジニアは全力で走っています。サボっているわけではありません。
しかし、一歩進むために、泥をかきわけ、蔦を切り、崩れそうな足場を補強しなければならないため、傍から見ると「全然進んでいない」ように見えるのです。
具体的に数値化してみましょう。
**「変更のリードタイム（Lead Time for Changes）」**という指標があります。コードを書き始めてから、本番環境で稼働するまでの時間です。
- 健全なプロジェクト：
- 機能実装：4時間
- テスト記述：2時間
- 自動テスト＆デプロイ：15分
- 合計：約6時間強
- レガシーなプロジェクト（WPF/デスクトップアプリの例）：
- 影響範囲調査（既存コード読解）：8時間
- 機能実装（スパゲッティコードへの接木）：4時間
- 手動テスト（自動テストがないため）：4時間
- バグ発覚と手戻り：4時間
- リグレッションテスト（全機能の目視確認）：8時間
- 合計：28時間（約4日）
同じ機能を作るのに、4倍以上の時間がかかっています。
差分の22時間は、どこに消えたのか？
これが**「レガシーコード税」**として徴収された時間です。
もしあなたのチームが5人のエンジニアを抱えているなら、そのうちの約4人分は、この「税金」を払うためだけに働いている計算になります。実質的に開発しているのは1人だけです。
これで、競合他社や、身軽なスタートアップに勝てるわけがありません。
4. 認知負荷（Cognitive Load）という限界
最後に、数字にはしにくいけれど、個人のキャリアにとって致命的なコストについて触れます。それは**「認知負荷」**です。
人間の脳が一度に把握できる情報の量（ワーキングメモリ）には限界があります。
良いコード（凝集度が高く、結合度が低いコード）は、そのクラスやメソッド単体を見れば理解できるように作られています。脳のメモリを無駄遣いしません。
一方、レガシーコードは常に「全体」を知っていなければなりません。
「このフラグを true にすると、ViewModel のあのプロパティが変わって、それが Converter を通って View の Visibility を変えるけど、実は裏でシングルトンの Manager クラスの状態も書き換えている…」
このような複雑なコンテキストを常に頭の中にロードしておかないと、一行も書けない。
これは、PCで言えば、Chromeのタブを500個開いたまま Photoshop を起動しようとしているようなものです。
動作が重くなり、フリーズしやすくなるのは当たり前です。
この状態で、新しい技術（例えば .NET 8 の新機能や、クラウドネイティブなアーキテクチャ）を学ぶ余裕なんて生まれるでしょうか？
脳のメモリは常に「社内独自の奇妙な仕様」で埋め尽くされています。
その知識は、一歩その会社を出れば、何の役にも立たないガラクタなのに。
ここまでのまとめ（承）
私たちは、「壊れていないなら直すな」という言葉の裏で、以下のコストを支払い続けています。
- モラルの崩壊： 優秀なエンジニアが去り、変化を拒む文化が定着する。
- オンボーディングの長期化： 新人が戦力になるまで数ヶ月かかり、給料泥棒（システム起因）を生む。
- 開発速度の低下： 全力で走っても、同じ場所に留まるのが精一杯になる。
- 認知負荷の増大： 脳のリソースが「無駄な複雑さ」に奪われ、成長の機会を失う。
状況は絶望的に見えるかもしれません。
海外の現場でも、この沼にハマってもがいているチームはたくさんあります。
しかし、ここで諦めてはいけません。
ここからが、私たちプロフェッショナルの腕の見せ所です。
ただ文句を言って辞めるのか、それともこの状況を逆手に取って、エンジニアとしての価値を爆上げするのか。
次回の「転」では、視点をガラリと変えます。
このレガシーコード税を、ただ支払うだけの立場から脱却し、**「技術的負債を戦略的に返済し、それを自分の実績（資産）に変える」**ための具体的なアクションプランとマインドセットについてお話しします。
ストップ・ザ・納税。
反撃の狼煙を上げましょう。
レガシーコード税を「払う側」から「徴収する側」へ――技術的負債を資産に変える逆転の思考法
被害者でいるのは、もうやめにしよう
ここまで、レガシーコードがいかに悪で、私たちから時間と精神力を奪っていくかを語ってきました。「承」を読んだあなたは、きっと今すぐ辞表を叩きつけたくなっているかもしれません。
しかし、ちょっと待ってください。
海外のテック業界を渡り歩いて気づいた真実があります。
「完全にクリーンなコードベース（Greenfield）」なんて、ユニコーンと同じで実在しないか、一瞬で消える幻です。
どんなにモダンなスタートアップに行っても、半年も経てばそこには必ず「負債」が生まれます。転職は一時的な鎮痛剤にはなりますが、根本治療ではありません。どこへ行っても、あなたは必ず「誰かが書いたコード」と戦うことになります。
ならば、発想を変えましょう。
レガシーコード税をただ黙って支払う「被害者」や「清掃員」になるのではなく、この負債をコントロールし、自分の価値を高めるための「投資材料」に変えるのです。
ここからは、私が実践している**「レガシーコード・ゲリラ戦術」**を共有します。
戦術1：「リファクタリング」という言葉を封印せよ
まず、明日からマネージャーやビジネスサイドの人間に「リファクタリングさせてください」と言うのをやめましょう。これは禁句です。
彼らにとってリファクタリングとは、「機能が増えないのに、金と時間がかかり、バグのリスクだけ増える道楽」に聞こえます。
代わりに、彼らの言語（ビジネス言語）で話すのです。
- ×「コードが汚いのできれいにしたいです」→ ○「新機能の実装スピード（Velocity）を今後20%上げるために、障害となっているボトルネックを除去します」
- ×「テストがないので書きたいです」→ ○「リリース後の手戻りリスクと、品質保証（QA）コストを削減するための自動化ガードレールを設置します」
私がWPFの案件でよく使うのは**「準備的リファクタリング（Preparatory Refactoring）」**という概念です。
「この新機能を実装するには、今の構造だと5日かかります。でも、先に1日かけて土台を整理すれば、実装は2日で終わります。合計3日です。さらに将来の修正も楽になります」
このように、「投資対効果（ROI）」として提案するのです。
海外の優秀なエンジニアは、コードを書く前に、まずこの「交渉」で勝ちます。技術的負債の返済を、エンジニアの趣味ではなく、ビジネス上の合理的判断として承認させるのです。
戦術2：ボーイスカウト・ルール（来た時よりも美しく）
大規模な書き換え（Big Bang Rewrite）は、絶対にやってはいけません。
「全部捨てて作り直しましょう！」という提案は、大抵の場合、数年がかりのデスマーチを招き、完成する頃にはその「新システム」がまたレガシーになっています。（これを「セカンドシステム症候群」と呼びます）
私たちがやるべきは、**「ボーイスカウト・ルール」**の徹底です。
“Always leave the campground cleaner than you found it.”
（キャンプ場は、来た時よりも美しくして帰ろう）
WPFのあの巨大な8,000行のViewModelを修正するタスクが来たとします。
全部を直す必要はありません。あなたが触るその「数行」の周辺だけを少しだけ良くするのです。
- 巨大なメソッドの中にコメントで区切られたブロックがある？ → **「メソッドの抽出（Extract Method）」**でプライベートメソッドに切り出す。
- 謎のマジックナンバー（
if (type == 3)）がある？ → 定数かEnumに置き換える。 - 変な名前（
var x）がある？ → 意味のある名前にリネームする。
たったこれだけです。所要時間は10分もかからないでしょう。
しかし、これをチーム全員が毎日繰り返せば、コードは驚くべき速度で浄化されていきます。
「汚い部屋のゴミを一度に片付ける」のではなく、「通りがかるたびにゴミを一つ拾う」。
この習慣こそが、負債の利息を止め、元本を減らす唯一の現実的な解です。
戦術3：テストがないコードへのアプローチ（Sprout & Wrap）
「リファクタリングしたいけど、テストがないから怖くて触れない。テストを書こうにも、依存関係が酷すぎてテストが書けない」
これがレガシーコードのジレンマです。
ここで役立つのが、マイケル・フェザーズが提唱した**「スプラウト（新芽）メソッド」と「ラップ（包み込み）メソッド」**です。
既存のスパゲッティコードの中に、新しいロジックを追加しなければならない時。
そのスパゲッティの中に直接 if 文を書くのではなく、
- 新しいロジックだけの、独立した新しいメソッド（新芽）を作る。
- その新しいメソッドに対してだけ、単体テスト（Unit Test）を書く。
- 既存のコードから、そのメソッドを呼び出す。
これなら、既存の汚いコードを解きほぐすことなく、**「新しく書くコードだけはテストされたクリーンな状態」**を保てます。
WPFで言えば、ViewModelの複雑なロジックから、純粋な計算処理やデータ変換処理だけを static なヘルパークラスや、独立したサービスクラス（Interface経由）に切り出してテストするイメージです。
泥の中にキレイな水を一滴ずつ垂らしていくのです。最初は濁ったままに見えますが、続けていれば必ず水は澄んできます。
戦術4：ストラングラー・フィグ（絞め殺しの木）パターン
さらに視座を上げて、システム全体の移行を考えるなら**「ストラングラー・フィグ（Strangler Fig Pattern）」**を知っておくべきです。
熱帯雨林の植物のように、宿主（レガシーシステム）の周りに新しいシステムを巻き付かせ、数年かけて徐々に栄養（機能）を奪い取り、最終的に宿主を枯れさせて入れ替わる手法です。
例えば、巨大なモノリシックなWPFアプリがあるとします。
これをいきなりWebアプリやマイクロサービスにするのは不可能です。
そこで、新機能だけは新しいアーキテクチャ（例えば .NET 8 + Blazor、あるいはモダンなWPF構成）で作り、既存アプリからそこへリンクを貼る、あるいは一部の画面だけを差し替える。
古いコードは「塩漬け」にして触らず、新しい要件は全て新しい基盤の上に構築する。
時が経つにつれ、古いコードの重要度は下がり、最終的には切り離せるようになります。
「敵（レガシー）と正面から戦うな。敵の周囲に新しい城を築け」
これがアーキテクトレベルの戦い方です。
キャリアの転換：あなたは「再生請負人」になる
最後に、一番重要なマインドセットの話をします。
レガシーコードと格闘し、それを改善していくスキルは、実は**「新規開発スキル」よりも市場価値が高い**場合があります。
なぜなら、世界中の企業の9割は、既に何らかのコードを持っており、その維持と改善に苦しんでいるからです。
「ゼロからReactでアプリ作れます！」というジュニアエンジニアは山ほどいます。
しかし、「築10年のスパゲッティコードを解析し、ビジネスを止めずに安全にモダナイズし、チームの生産性をV字回復させることができます」というエンジニアは、砂漠の水より貴重です。
これを私は**「再生請負人（Renovation Engineer）」**と呼んでいます。
あなたが日々直面しているその苦しみ――
「なぜ依存関係注入（DI）を使っていないんだ！」
「なぜ関心の分離ができていないんだ！」
という怒りは、裏を返せば**「正しい設計（アーキテクチャ）を知っている」**という証明です。
悪いコードを見ることは、良いコードを書くための最高の反面教師です。
レガシーコードと戦った経験は、あなたの「設計の筋肉」を鋼のように鍛え上げます。
「こう書くと、3年後に死ぬほど苦労する」という痛みを伴う知識は、本からは学べません。
だから、悲観しないでください。
あなたは今、ゴミ掃除をしているのではありません。
高額な研修でも学べない**「アンチパターン」の実地訓練**を、給料をもらいながら受けているのです。
ここまでのまとめ（転）
- 視点を変える： レガシー環境からは逃げられない。ならば「再生請負人」として価値を出せ。
- 言葉を変える： 「リファクタリング」ではなく「リスク低減」「速度向上」としてビジネス側に売れ。
- 行動を変える： ビッグバン書き換えではなく、「ボーイスカウト・ルール」と「スプラウト・メソッド」で、今日触る箇所から浄化せよ。
- 戦略を持つ： 「ストラングラー・パターン」で、レガシーを徐々に無力化せよ。
さあ、武器は揃いました。マインドセットも変わりました。
次回はいよいよ「結」です。
この長い戦いの果てに、エンジニアとしてどう生きるべきか。
技術の話を超えて、あなたの人生の「損益分岐点」を超えるためのラストメッセージを送ります。
エンジニアとしての「損益分岐点」を超えろ――海外で生き残るためのコード哲学
雨上がりのコードベース
数ヶ月に及ぶ「ゲリラ戦」の末、私のチームのWPFプロジェクトは、少しずつですが、確実に変わり始めました。
かつて8,000行あった MainWindowViewModel.cs は、機能ごとに分割された複数のサービスと、小さなViewModelの集合体に生まれ変わりました。
「触ると爆発する」と恐れられていた画面遷移のロジックは、単体テストで保護され、今ではジュニアエンジニアのAlexでも自信を持って修正できるようになりました。
窓の外の雨は上がり、雲の隙間から光が差しています。
レガシーコード税の支払いはまだゼロではありません（ゼロにはなりません）。しかし、私たちはもう、搾取されるだけの存在ではありません。私たちはコントロールを取り戻したのです。
この長い旅路の終わりに、私が海外の荒波の中で掴んだ「エンジニアとして生きるための本質」を3つのポイントで共有します。
1. エンジニアの価値は「書いた行数」ではなく「減らした不確実性」で決まる
日本にいた頃の私は、「どれだけ難しい機能を実装したか」「どれだけ大量のコードを書いたか」が自分の価値だと思っていました。
しかし、こちらに来て、レイオフ（一時解雇）の嵐が吹き荒れるテック業界を目の当たりにして、考えが変わりました。
会社にとって、エンジニアは「投資」です。
そして、レガシーコードは「リスク（不確実性）」です。
毎日バリバリと新規コードを書きまくるけれど、その背後に大量の技術的負債（バグの温床）を撒き散らす「生産性の高い」エンジニアと、
派手な機能は作らないけれど、既存の複雑なシステムを整理し、誰でも安全に開発できる環境を整える「地味な」エンジニア。
どちらが、危機の時に生き残ると思いますか？
海外のマネジメント層は、後者を高く評価します。
なぜなら、前者は将来のコスト（税金）を増やし、後者は将来のコストを削減して「損益分岐点」を引き下げてくれるからです。
「You are not paid to code. You are paid to deliver value.（君はコードを書くために雇われているんじゃない。価値を届けるために雇われているんだ）」
この言葉を胸に刻んでください。
レガシーコードと戦い、それを飼いならす能力は、単なる保守作業ではありません。それは、ビジネスのリスクを直接的に減らす、極めてハイレベルな経済活動なのです。
2. 「過去の自分」と「未来の他人」へのエンパシー（共感）
レガシーコードを見て「なんだこのクソコードは！」と叫ぶのは簡単です。私もよく叫びます（ミュート状態で）。
しかし、そこで止まってはいけません。
そのひどいコードを書いたのは、もしかしたら「納期まであと3日しかない中で、仕様変更を押し付けられ、それでもなんとか動くものを作ろうと必死だった5年前の誰か」かもしれません。あるいは、スキルが未熟だった頃の自分自身かもしれません。
**「Technical Empathy（技術的共感）」**を持ちましょう。
コードは、その時の状況と制約の中で生まれた、精一杯の「解」だったのです。
過去を呪うのではなく、過去を受け入れ、鎮魂（リファクタリング）する。
そして、これからあなたが書くコードは、**「未来の誰かへのラブレター」**であるべきです。
1年後、あなたのコードを読む人が、
「ああ、なんて分かりやすいんだ。意図が明確だ。テストがあるから安心して触れる」
と感謝してくれるか。
それとも、
「ふざけるな！ 誰だこれを書いたのは！」
と呪いの言葉を吐くか。
海外の現場では、コードレビューで「Kindness（優しさ）」という言葉がよく使われます。
「この変数名は、読み手にKindじゃないね」
可読性の高いコード、適切なコメント、整備されたドキュメント。これらは全て、顔の見えない同僚への「優しさ」の表れです。
技術力とは、突き詰めれば**「他者への想像力」**なのです。
3. 常に「脱出ボタン」を用意しておくこと
最後に、少しドライですが現実的なアドバイスを。
どれだけあなたが努力しても、組織が変わらないことはあります。
「リファクタリングなんて金にならないことはやめろ」と頭ごなしに否定する上司、変化を拒絶し続けるチーム。
そんな環境で、あなたの貴重な人生を浪費して「レガシーコード税」を払い続ける義理はありません。
ここで重要なのが、**「いつでも転職できる実力（Fuck You Moneyならぬ、Fuck You Skills）」**を持っておくことです。
レガシーコードとの戦いを通じて、あなたは既に強力な武器を手に入れています。
- 複雑な依存関係を解きほぐす設計力
- テストがない環境にテストを導入する戦略眼
- ビジネスサイドを説得する交渉力
これらは、どの会社に行っても通用するポータブルスキルです。
「今の会社を良くするために全力を尽くす。でも、それが受け入れられないなら、いつでももっと良い場所へ行ける」
この精神的な余裕こそが、あなたを真のプロフェッショナルにします。
会社に依存するのではなく、会社があなたを手放したくないと思わせる存在になるのです。
あなたのコードは、あなたの人生そのものだ
たかがプログラム、されどプログラム。
私たちがモニターに向かっている時間は、人生の起きている時間の半分以上を占めます。
その時間を、終わりのないバグ修正とストレス（納税）に費やすのか。
それとも、美しく、秩序があり、誇れる作品（資産）を作ることに費やすのか。
選択権は、常にキーボードの上のあなたの指先にあります。
WPFのバインディングが上手く動いた時のあの小さな喜び。
スパゲッティコードが解けて、きれいなMVVMパターンに収まった時のあの快感。
それを忘れないでください。
「壊れていないなら直すな」という言葉に負けないでください。
私たちはエンジニアです。
**「壊れていなくても、もっと良くする」**ことが、私たちの仕事であり、誇りなのですから。
さあ、コーヒーを飲み干したら、Visual Studioに戻りましょう。
世界には、まだリファクタリングされるのを待っているコードが山ほどあります。
そして、それを美しくできるのは、あなたしかいないのです。
Good luck, and Happy Coding.
コメント