レガシーシステム刷新の検討ガイド

基幹システム刷新の進め方｜方式比較・費用・RFPの前に確認すること

基幹システム刷新は、現行資産と業務ルールを整理し、残す・変える・廃止する範囲を合意してから、方式と見積りを比較します。レガシー刷新AIは、その判断に必要な仕様・依存関係・テストの整理を支援します。解析費用と、新システムの開発・移行費用は分けて考えます。

公開・更新：2026年10月7日 / 株式会社GembaShift

最初に、誰が何を決める？

「保守期限に間に合わせたい」「担当者の退職前に引き継ぎたい」「変更のたびに調査が長引く」など、刷新のきっかけと達成したい状態を分けて書きます。新しい言語に変えることだけを完了条件にせず、変更・運用・引き継ぎができる状態を目標にします。

担当	最初に合意すること
経営・DX推進	目的、優先順位、予算や期限の制約、段階的に進める範囲。
情報システム・業務部門	残すルール、変える運用、止められる時間、成果物を確認する担当。
SIer・開発会社・PM	調査対象と除外範囲、必要資料、設計・実装との役割分担、見積りの前提。

方式名の使い方は提供会社によって異なるため、何を残し、何を変える契約なのかを確かめます。システム全体をひとつの方式に揃える必要はなく、業務や資産ごとに組み合わせて検討できます。

選択肢	比較するポイント
リホスト／リプラットフォーム	既存の処理を中心に残し、実行基盤や周辺製品を移す方法。互換性、運用、性能を確認し、仕様の不明点が残るかを見極めます。
リライト	既存の処理を別の言語等に書き換える方法。計算・例外処理・データ表現が引き継がれるかを新旧比較で確認します。
再設計・再構築	業務や構造から見直す方法。維持する要件と変更する要件を分け、移行順序と受入条件を定めます。
パッケージ・SaaSへの置換	標準機能に合わせる範囲と、独自機能・外部連携を比較します。データ移行と運用の変更も対象です。
継続利用・廃止	当面残す理由、保守可能な期間、利用状況、後続処理を確認します。参照が見つからないだけでは廃止を決めません。

コードの行数だけでは見積りの前提は揃いません。同じ量でも、技術の混在、外部との連携、資料の不足、例外処理の多さによって調査と確認の負担は変わります。現行調査・解析と、設計・実装、データ移行、テスト、切替・運用を工程別に分けて比較します。

当社の解析・仕様復元支援は、対象資産と必要な成果物を確認して個別にお見積もりします。一律の削減率や期間を約束するのではなく、最初の対象で確認した作業と残課題を、次の範囲を判断する材料にします。

資料が全部揃うまで待つ必要はありません。手元にあるものと不足しているものを分け、どこまで調べたかを同じ前提で伝えます。ベンダーごとに対象範囲が異なるまま、金額だけを比較することを避けられます。

渡す材料	含めたい内容
対象資産の一覧	対象版、言語、ジョブ、データ、外部連携と除外範囲。
現行仕様・業務ルール	根拠箇所、業務上の意図、残す・変える・未決の区分。
依存関係と未確認事項	他システムへの影響、必要な追加資料、確認担当。
テスト・受入条件	入力条件と期待結果、許容差、例外処理、業務担当者の確認方法。
役割と情報の取り扱い	解析・実装・承認の責任範囲、資料提供権限、保管と外部送信の条件。

ひとつの機能を選ぶときも、読みやすいコードだけに偏らせず、共通部品、外部連携、例外処理を含む代表的な範囲を選びます。解析前に、原文から人が確認した業務ルールと、比較する対象版を定めます。

構造を拾えたことと、業務ルールを正しく説明できたことは別の評価です。当社の公開検証でも両者を分け、取りこぼしを記録しています。下表をたたき台に、お客様の目的に合う判定方法を合意します。

評価すること	確認方法の例
根拠を確認できるか	出力した仕様から元のファイル・該当箇所へ戻り、対象版も一致するかを見る。
どれだけ拾えたか	事前に用意した正解のうち拾えた件数を数える。見落とした条件も残す。
出力が正しいか	出力のうち正しかった件数を数える。誤りや根拠のない候補を分ける。
次の工程に使えるか	別の担当者が仕様とテスト条件を読み、設計・実装の判断に使えるかをレビューする。
追加作業を見積もれるか	不足資料、未解析の経路、人による修正・確認の作業を記録する。