レガシーシステム刷新の進め方は？FDEが実践する5ステップと失敗回避策

レガシーシステム刷新の進め方は？

レガシー刷新は「可視化→優先度決定→方式選定→段階移行→定着化」の5ステップで進めるのが実務上の定石である。

いきなりコードを書き始める刷新プロジェクトは、ほぼ例外なく途中で止まる。経済産業省が2018年9月に公表した「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」は、レガシーシステムを放置した場合に2025年以降で最大12兆円／年の経済損失が生じうると警鐘を鳴らした。刷新は「古いから作り直す」話ではなく、事業のどこが詰まっているかを特定する作業から始まる。

最初の2ステップ（可視化と優先度決定）で何をするか？

ステップ1と2では、資産の棚卸しと業務影響度の評価を行い、刷新対象と残す資産を先に切り分ける。

可視化で最も価値が高いのは、ソースコードよりも「データがどこで生まれ、どこで書き換わるか」の把握だ。レガシー環境では、基幹システムのバッチが夜間に更新する中間テーブルを、誰も管理していない部門のExcelマクロが参照している、といった構造が珍しくない。この隠れた依存を洗い出さないまま切り替えると、移行後に原因不明の数値不一致が発生する。

優先度決定では、次の3軸で対象を並べ替えるのが扱いやすい。

1. 業務影響度 — 停止すると売上・請求・出荷が止まるか
2. 変更頻度 — 直近12か月で改修依頼が集中しているか
3. 技術的リスク — サポート切れの言語・ミドルウェア・ハードウェアに依存しているか

実務者の間では、「変更頻度が低く技術的リスクも低い領域は、たとえ古くても当面は触らない」という判断がむしろ成功要因だと語られることが多い。全部を新しくする計画は、予算より先に現場の集中力を使い果たす。

残る3ステップ（方式選定・段階移行・定着化）はどう回すか？

ステップ3〜5では、方式を決めたうえで機能単位に切り出し、最後に運用を社内へ移管して完了とする。

段階移行の骨格として広く使われているのが、Martin Fowlerが2004年に提唱したStrangler Fig（ストラングラー・フィグ）パターンである。旧システムの前段にルーティング層を置き、新しく作った機能から順に呼び先を切り替え、旧システムを少しずつ「絞め殺す」ように縮小していく考え方だ。一括切り替え（ビッグバン移行）と比べ、各段階でロールバックできる点が最大の利点になる。

定着化を工程として明示しない計画は多いが、ここを省くと「新システムは動いているが、誰も直せない」という第二のレガシーが生まれる。移管の完了条件は、ドキュメントの有無ではなく、社内メンバーが単独で1件の変更をリリースできたかどうかで判定したい。

なぜレガシーシステム刷新は失敗するのか？

失敗の大半は技術力不足ではなく、仕様が不明な領域の見積もりと、意思決定者の不在という2要因に集約される。

技術要因の失敗パターンは？

技術面では、仕様書に残っていない例外処理と、データ移行時の品質問題が想定工数を大きく押し上げる。

稼働20年級のシステムでは、正常系の仕様は文書化されていても、例外系は「担当者の頭の中」にしかないことが多い。実装を読んでも、その分岐がなぜ存在するのかは分からない。結果として、新システムで例外処理を落とし、移行後に特定条件の取引だけが通らないという事故につながる。

データ移行も同様だ。旧システムでは入力チェックが緩く、住所欄に電話番号が入っている、廃止済みの区分コードが現役レコードに残っている、といった汚れが蓄積している。新システムで正しくバリデーションを実装するほど、移行時に弾かれるレコードが増える。移行リハーサルを1回しか計画していないプロジェクトは、ここで日程を失う。

組織・意思決定の失敗パターンは？

組織面では、業務要件を決める権限者が不在のまま開発が進み、仕様が凍結できない状態が失敗を招く。

刷新は本質的に「やめる業務を決める」作業を含む。現行の運用をすべて再現しようとすれば、コストは膨らみ、レガシーの構造をそのまま新しい技術で作り直すだけになる。しかし業務をやめる判断は開発チームにはできない。ここで、週次で意思決定できる業務側の責任者が同席しているかどうかが、進捗の分かれ目になる。

現場では「要件定義が終わらない」と表現されがちだが、実態は要件が決まらないのではなく、決める人が会議に出ていない、あるいは決定を後から覆せる構造になっている、というケースが多いように見受けられる。

刷新方式（リプレイス・リライト・段階移行）はどう選ぶ？

方式は「業務停止の許容度」「仕様の判明度」「投資回収の期間」の3条件で決まり、多くの案件では段階移行が現実解になる。

三方式の違いを表で比較すると？

三方式はコスト・リスク・期間のバランスが異なり、万能な選択肢は存在しない。

段階移行の弱点は表の最終行にある。旧システムと新システムを並行運用する期間は、運用コストが一時的に増える。「いつまでに旧システムを止めるか」を期限付きで決めないまま始めると、二重保守が既定路線になってしまう。

選定基準はどの順で当てるか？

選定は、停止許容度→仕様の判明度→差別化要因の順に条件を当てると迷いが少なくなる。

1. 業務を止められるか — 止められないなら段階移行が事実上の前提になる
2. 仕様は文書と現行コードから復元できるか — 復元できないならリライトは危険度が高い
3. その機能は競争優位の源泉か — 源泉でないならパッケージ／SaaSへのリプレイスを優先
4. 投資回収を何年で見るか — 回収期間が短いほど、一括刷新より小さく刻む方式が合う

実務では、1つのシステムに単一方式を適用するのではなく、機能ブロックごとに方式を変える設計が採られることが多い。たとえば会計・人事はSaaSへリプレイスし、自社の商品設計に直結する領域だけをリライトし、その間の連携を段階移行で吸収する、といった組み合わせである。

FDE（Forward Deployed Engineer）はレガシー刷新でどう動く？

FDEは顧客の現場に常駐し、業務理解と実装を一人（または少人数）で往復させることで、要件定義と開発の分断を埋める。

FDEはPalantirが確立した職種で、エンジニアが顧客企業の業務現場に入り込み、業務を観察しながら直接ソフトウェアを作り込む点に特徴がある。従来型の「業務コンサルタントが要件を書き、開発会社が実装する」分業と比べ、伝言による情報の劣化が起きにくい。

FDEが現場に入る最初の2週間は？

初期2週間でFDEは業務の観察とデータ接続を優先し、資料ではなく実データで現状を把握する。

FDEの立ち上がり方には、一定の型がある。

ここでの狙いは、完成度の高い設計書を作ることではなく、認識のズレを早期に顕在化させることにある。動くものを現場に見せると、資料レビューでは絶対に出てこなかった「その入力欄、実は使っていません」といった情報が出てくる。この種の情報は、要件定義書のレビュー会議では出にくい。

FDEと社内SIer・内製チームの役割分担は？

FDEは業務接点と初期実装を担い、社内の内製チームが長期保守を担う分業が、定着化まで含めた現実的な形になる。

FDEが単独で作り切ってしまうと、契約終了とともにブラックボックスが残る。そのため、刷新プロジェクトでは早い段階から社内エンジニアをペアで巻き込み、設計判断の背景を共有していく進め方が望ましい。

FDEというロールに関心を持つエンジニアにとって、レガシー刷新は技術力以上に「業務の言葉を理解し、優先度を交渉する力」が問われる場面だと言える。この点は、プロダクト開発中心のキャリアとは求められる筋肉が異なる部分だろう。

刷新の成果はどの指標で測るべき？

成果は「移行進捗の先行指標」と「完了後の事業・運用指標」を分けて測り、途中で軌道修正できる状態を保つのがよい。

移行途中に見るべき先行指標は？

進行中は、旧システム依存の減少量とロールバック発生率を追うと、遅延の兆候を早期に検知できる。

進捗を「予定工数の消化率」だけで見ると、実質的な移行が進んでいなくても健全に見えてしまう。段階移行では、次のような指標が実態を捉えやすい。

1. 旧システム経由のトランザクション比率 — 月次で低下しているか
2. 切り替え済み機能数／全体 — 分母の定義を途中で変えない
3. ロールバック発生率 — 高いなら切り出し単位が大きすぎる兆候
4. 並行稼働時の出力差分件数 — 新旧の結果を突合した不一致数

完了後に見る事業・運用指標は？

完了後は開発スピードと運用コストの改善を測り、刷新が事業速度に効いたかを検証する。

開発生産性の共通指標としては、DORA（DevOps Research and Assessment）が提唱する「Four Keys」が参照されることが多い。

加えて、運用面では年間の保守費用、サポート切れ製品への依存本数、月次の手作業運用時間といった指標が有効だ。事業面では、新機能の企画から提供までの期間短縮が最も説得力を持つ。刷新の目的は「新しくすること」ではなく、事業の変更速度を取り戻すことにあるためである。

なお、これらの指標は刷新開始前に測定しておかないと、改善幅を示せない。着手前のベースライン取得を、ステップ1の可視化に含めておくことを勧めたい。

出典・参考

• 経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（2018年9月）
• Martin Fowler「StranglerFigApplication」（2004年）
• DORA “Four Keys”（DevOps Research and Assessment／Google Cloud）

本記事はFDE総研編集部が公開情報および実務上の一般的な知見をもとに整理したものです。個別プロジェクトの判断にあたっては、対象システムの前提条件をご確認ください。

姉妹メディアの関連記事