レガシーシステムは、長く使われた結果として技術や運用が古くなり、変更しづらくなった既存システムを指します。 重要なのは、古いこと自体は問題ではないという点です。
何が「レガシー」を作るのか
安定して動いていて、必要なときに安全に直せるなら、20年前のシステムでも問題ありません。困るのは次の状態です。
- 全体を把握している人がいない
- 仕様書が無い、あっても実物と違う
- テストが無く、直した影響を確かめられない
- 業務フローが深く依存していて、止められない
- 動く環境を再現できない（開発機がもう無い）
つまりレガシー化とは技術の古さではなく、変更できなくなった状態のことです。技術的負債を返済しないまま年月が経った結果、と言い換えてもかまいません。
ドキュメントより「動いている事実」が仕様
移行や改修で最初に必要なのは、現在の挙動を正確に把握することです。設計書は更新されていないことが多く、書かれた仕様と実際の動きが違うのは普通です。
そして厄介なのは、その食い違いを前提に業務が回っていることがあるという点です。「バグだから直した」ら現場の運用が壊れる、というのは実際に起きます。挙動を変える前に、必ず利用者へ確認してください。
一括置き換えは失敗しやすい
「全部作り直す」計画は、規模が大きいほど途中で破綻します。要件の洗い出しが終わらない、その間も現行システムは変更され続ける、予算と期間を超える——という流れが典型です。
現実的なのは段階的な置き換えです。外側の機能から新システムへ切り出し、古い部分を少しずつ包み込んで最後に中心を置き換えます（ストラングラーパターンと呼ばれます）。移行期間中は新旧が並走するので、その間の整合をどう取るかを先に決めておきます。
実務で見るポイント
- まず現状を動かせる状態を作る（環境の再現、ログの整備、テストの追加）
- 全面刷新の判断は、コストではなく「事業の変化に追随できているか」で決める
- 属人化の解消は技術課題ではなく体制の課題。人が抜ける前に着手する