本記事は、技術カンファレンス「NDC Sydney 2026」において、ブランダー氏が登壇したセッション「Indiana Jones and the Temple of Legacy Code」の内容を基に構成している。

　ブランダー氏は、「レガシーシステムについての理解度も保守容易性も低い状態から、安全に変更が可能な状態へとシステムを引き上げる必要がある」と主張する。

　保守容易性を高める第一歩は、再現可能なビルドを確立することだ。特定のマシンの設定に依存せず、CI（継続的インテグレーション）ツールで確実にビルドできる体制を整えることが出発点になる。

　レガシーシステムはテストが困難な場合がしばしばある。そこで、ツールを用いてユーザー操作を模倣するテストから着手し、AIツールを利用してテストコードを生成する方法も有効だ。この場合、生成されたテストコードが意味のあるものかどうかを確認するために、ミューテーションテスト（ソースコードに意図的なバグを作ってテストコードの有効性を確かめるテスト）を用いて、ソースコードの分岐ロジックに対するテストの妥当性を検証する手順が不可欠となる。

　ブランダー氏は、システム内部の動作を可視化する観測性（オブザーバビリティ）の導入を推奨する。レガシーシステム全体に観測性を追加するのは難しいため、最初は小規模な処理の流れに導入してパイプラインを確立する。次に自身が修正を担当する機能へと適用範囲を広げる。

Git履歴を用いた「考古学」

　システムの理解度を深める手段として、ブランダー氏はGitのコミット履歴をデータベースとして分析する手法を示す。単一のファイルが過去1年間で何回変更されたかを集計することに加え、「バグ」「修正」「パッチ」といったキーワードを含むコミットでフィルタリングをする。

　ブランダー氏はセッション内でOSS（オープンソースソフトウェア）のメディアプレーヤー「Jellyfin」のリポジトリを分析した。そこで「BaseItemRepository.cs」という約2600行のファイルが1年間で81回変更され、そのうち46回がバグ修正のコミットだったことを実証した。ファイルの約6割が1年間で書き換えられているという定量的な事実を基に、どこにテストを追加し、どこを慎重に扱うべきかのリスク管理が可能になる。

　コンパイラでは検出できない「変更の隠れた結合」を特定する方法にもブランダー氏は言及する。あるファイルを変更した際、別のファイルが同時に変更される割合をGitの履歴から分析することで、隠れた依存関係を事前に把握できる。この分析には標準のGitコマンドの他、専用の分析ツールも活用可能だ。

ライフサイクルに応じた3つの改修手法

　理解度と保守容易性を高めた上で、実際のコード改修に入る。この際、システムのライフサイクルがどの段階にあるかによって、採用すべき手段が異なる。

1．変更よりも追加

　クリティカルなバグのみを修正するフェーズにある場合、既存の機能を変更することには危険を伴う。例えばリストの並び順を変更する際、既存のメソッドを書き換えるのではなく、あえてソースコードを重複させて新しいメソッドを追加する。アクティブな開発では避けるべきソースコードの重複も、このフェーズでは安全性を保証する正当な手段になる。

2．末端の変更

　メンテナンスのフェーズにおいては、既存のコアロジックに手を入れるのではなく、呼び出し元やUI（ユーザーインタフェース）に表示される手前といった、処理の末端で変更を適用する。データベースへのクエリを変更するのではなく、取得したデータをメモリ上で並び替えるといった具合だ。

3．機能ごとの切り出し

　システムがアクティブな開発フェーズにある場合は、機能単位での分離を進める。対象となる機能専用の新しいインタフェースを作成し、関連するソースコードを既存の巨大なクラスから切り離すことで、影響範囲を限定した安全なモダナイゼーションを実現する。

レガシーシステムが優秀な技術者を育てる

　ブランダー氏は「レガシーシステムには長年のビジネス価値が詰まっている。初めから悪いシステムを作ろうとする者はいない」と指摘する。複雑で脆弱（ぜいじゃく）なシステムに変更を加える経験は、開発者に対してリスク管理能力や設計スキルを強制的に学ばせる。困難なレガシーコードに向き合うことは、次世代の優秀なエンジニアを育成する絶好の機会だ。

本稿は、NDC Conferencesが2026年2月11日に公開した動画「Indiana Jones and the Temple of Legacy Code - William Brander - NDC London 2026」を基に作成しました。