🎄 本記事はbitA Tech Blog Advent Calendar 14日目の記事です。
はじめに
「この挙動ってどこで制御してるんですか？」と聞くと、
先輩がしばらくコードを追いかけて黙り込む。
数分後、ようやく口を開いたと思ったら
「このコードだけど、昔の担当が書いたままで、
なぜか修正すると全体が動かなくなるんだよね…。」
「1行触っただけなのに、なぜか別の画面が壊れた」
そんな理不尽バグに振り回された経験はありませんか。
日本企業でも6割以上がレガシーシステムを抱えています。
レガシーなプロジェクトが良くないと言われることは多いですが、
なぜ良くないのかを考え問題点を洗い出し、
レガシー環境をどう扱うべきなのかを改めて整理してみます。
レガシーとは何か？
まず考えるべきは、そもそも レガシーとは何か？ という点です。
-
フレームワークやライブラリのバージョンが古ければレガシー？
-
最新のものを使っていなければレガシー？
-
「レガシー技術」と呼ばれるものを使っていたらレガシー？
考え方によってはこれらも間違いではないかもしれませんが、
断言しきれないと思います。
結論として、自分は以下のように定義したいと考えます。
- システムに対して保守性・拡張性が低い
- システムがビジネス要求に素早く適応できないほど肥大化・複雑化している
これらはどちらか一方だけが当てはまる場合もあれば、両方を併せ持つ場合も存在します。
定義のポイントとしては、「“古いかどうか”」 ではなく 「“システムの進化を阻害しているか”」 という点です。
たとえば、
- 設計が破綻している
- ブラックボックス化している
といった状態であれば、影響が読めないという理由から進化が阻害されていると言えます。
つまり、比較的新しいフレームワークを使っていても、
進化の阻害が起きていれば、それはレガシーだと自分は考えます。
レガシーフロントエンドが引き起こす問題
レガシーなフロントエンド環境を例に、どのような問題を引き起こすか、
具体的に見ていきます。
技術的な問題
-
影響範囲が不明瞭
修正がどこに影響するかの特定が難しいパターンです。
一行修正を加えただけでも、システム全体の検証を要するような場合もあります。
以下のような要因によって、システムの進化が阻害されます。
- 数千行規模の巨大ファイル
- 関数や処理が密結合となり、変更時の影響範囲が把握できず安全に修正できなくなるため
- グローバル変数汚染
- どこから値が書き換わるか追えず、意図しない副作用が発生しやすくなるため
- モジュール化されていない
- 読み手が制御フローを理解しにくく、一箇所の修正が別機能に影響しやすくなるため
-
バグ再発率の上昇
主に「隠れた依存関係」によって引き起こされます。
- 複数箇所で書き換わる変数が存在する
- 値の変化元が追えず、思わぬ動作を招くため
- 発火元が不明なイベントが混在している
- 実行タイミングを把握できず、影響箇所を特定しにくいため
- 副作用を伴う関数が散在している
- 一部の変更が他の処理へ波及しやすいため
その結果、「Aを直す → Bが壊れる → Aが再度壊れる」といった悪循環が発生します。
- 新機能が追加できなくなる
- システム構造の破綻によって要求に必要な改修や拡張に対応できなくなる
- その結果、プロダクトの競争力が低下してしまう
レガシープロジェクト問題がある環境のイメージ
組織・チーム面の問題
- 属人化が進行する
- 「Aさんしか触れない」「Bさんが抜けたらビルド不可」「新人が参入できない」など、属人化による持続不可能な状態が発生してしまう
- その結果、チーム全体の開発スピードが低下し、最終的には品質が落ちる
- スキル移転が困難。
- レガシー技術・独自仕様・ブラックボックス化により、学習コストが高く新人が戦力化し辛い
- 結果として、チームが増員・分担しにくくなる
問題点まとめ
| 種別 | 問題 | 主な原因 | 結果 |
|---|---|---|---|
| 技術 | 影響範囲が不明瞭 | ・巨大ファイル（数千行） ・グローバル変数汚染 ・モジュール化されていない |
・1 行修正でも全体検証が必要 ・安全に変更できない |
| 技術 | バグが再発しやすい | ・隠れた依存関係 ・複数箇所で値が書き換わる変数 ・発火元不明のイベント ・副作用の多い関数 |
・A を直すと B が壊れる悪循環 |
| 技術 | 新機能が追加しにくい | ・システム構造の破綻 ・拡張性の欠如 |
・開発コスト増大 ・競争力の低下 |
| 組織 | 属人化が進行する | ・一部の人しか触れない ・ブラックボックス化 |
・新人参入不可 ・開発速度・品質の低下 |
| 組織 | スキル移転が困難 | ・学習コストが高い ・独自仕様／レガシー技術 |
・増員・分担が行えずチーム拡大が難しい |
実際に起きた危機：Rosetta2 廃止が示したレガシー環境の限界
ここまでは一般論でしたが、現場ではより突発的で深刻な事態が起こり得ます。
2025年6月のWWDC 2025で、Appleが今後 Rosetta2 の提供を終了すると発表し、“レガシーな開発環境が動かなくなる” という危機に直面しました。
Rosetta依存のIntelバイナリが使えなくなることで、
フロントエンドの開発環境でも下記のようなツールがそのままでは動作しなくなります。
- Node v16未満
- Apple Silicon上でx86ビルドが実行できず、Rosetta廃止後は起動自体が困難。
- webpack 5.x（Node v16要求の旧構成）
- 旧設定のままではビルドエラーが発生しやすい。
- Vite（古いプラグイン/設定）
- arm64環境でプラグインが動作せず、再ビルド・設定更新が必須。
- npm / yarn v1系
- パッケージインストール時にエンジンチェックで落ち、環境構築不可。
普段は無視したまま運用できている構成でも、
Rosetta依存が切られたタイミングで macOSでは開発環境そのものが再起不能になる可能性 が高まっています。
実際、廃止が本格化する 再来年の秋以降には、Mac OS上で次のような事態が十分起こり得ます。
- ビルドできない（そもそもビルドツールが動作しない）
- Intel系のプログラムがmacOS上で動かない
- 予想できていない箇所からバグが発生するが理由を把握し辛い
上記のようにいきなりレガシーな環境がビジネスを止めてしまうことが起きる可能性があります。
今までの内容でわかるようにレガシー環境改善は “そのうちやるもの” ではなく “環境変化によって突然できなくなる前に調査し管理していくべきもの” となります。
このようなレガシーをどう扱うべきか？
1.「全面リプレイス」より「段階的モダナイゼーション」
理想は全面刷新ですが、それが難しい場合は次のような段階的モダナイゼーション をとるのが良いかと思います。
- 機能単位で分割
- 既存機能の外側からモジュール化
→ 例：jQuery依存を徐々に純JSに置き換える - 新規開発からモダン構成へ移行
- テスト導入で安全な移行ルートを確保
→ 例：Jest / Playwrightで最低限壊せない箇所を守る
2. 現状のレガシーポイントを“可視化”する
“どこがレガシーな環境なのか” を可視化することが重要です。
例）
- 循環参照の多いファイル
- 正体不明の共通モジュール
- イベントリスナーが乱立している箇所
可視化 → 評価 → 優先度付け
チームのプロジェクトの中どの部分をレガシー環境として特定するべきなのか、
また、どのように評価し、どのくらいの優先度で対応すべきなのかを検討することが必要かと思います。
3. 技術的負債を「集合知」として扱う
レガシー改善は個人で抱える問題ではありません。
- チームで負債リストを管理
- 改善の成果をドキュメント化
- 開発フローそのものも改善対象にする
こうした取り組みを積み重ねて、レガシー環境改善を仕事としてチームが認識することが大事です。
終わりに
レガシーを放置することは、
単に “古い技術を使っている” という問題ではありません。
- バグ発生率が上がる
- 開発速度が落ちる
- ビジネス要求に追随できなくなる
- チームが疲弊し、人材が離れる
これらはプロジェクトにもエンジニア個人にも致命的です。
レガシー改善は手間も時間もかかりますが、
その投資は プロダクトと組織の未来を確実に良くする力 を持っています。
だからこそ、隠れた改善ポイントに目を向け、
興味を持って対策を立て、1つずつ解決していきましょう。
Discussion