システム刷新の進め方｜現行システム調査から移行計画まで

システム刷新の最大の難所は、着手前の「現行システム調査」にある。長年稼働してきたシステムは担当者の異動や引き継ぎを繰り返すうちにブラックボックス化が進み、「何がどこに実装されているかわからない」という状態になっていることが多い。経済産業省のDXレポートでは、約8割の企業がレガシーシステムを抱えており、そのうち約7割がDX推進の障壁になっていると回答している。本記事では、IPAのガイドラインに基づき、現行システム調査から移行計画の策定まで、実務レベルで使える手順を整理する。

なぜ今、システム刷新が急務なのか

経済産業省が2018年に公表したDXレポートは「2025年の崖」という概念を提唱した。21年以上稼働している基幹システムが全体の6割に達し、そのメンテナンスを担えるエンジニアが定年を迎えることで、システムの維持そのものが危うくなるというシナリオだ。刷新に失敗し続けた場合の経済損失は最大12兆円／年と試算されている。

2026年3月時点で「2025年の崖」は通過したが、課題は解消されていない。IPAとレガシーシステムモダン化委員会が2025年5月に公表した総括レポートでは、レガシーシステムの刷新を「一部でも進めている」と回答した企業は全体の約半数にとどまっており、大企業で65.5%、中小企業では43.8%という状況だ。刷新が進まない最大の理由は「他案件で手が埋まっており十分な要員を割けない」（39.9%）であり、人的リソースの制約が依然として最大のボトルネックとなっている。

IPAガイドラインが示す刷新の全体像

IPA（独立行政法人情報処理推進機構）は「システム再構築を成功に導くユーザガイド 第2版」（2018年）において、ユーザ企業が現行システムを再構築する際の体系的な手順を示している。このガイドでは、刷新プロジェクトを大きく以下の4フェーズに分けて整理している。

このガイドが特に強調するのが「現行システム調査を表面的に終わらせるな」という点だ。調査が不十分なまま要件定義に入ることが、後工程での仕様変更爆発や予算超過の主因になる。

現行システム調査の進め方

現行システム調査は、刷新プロジェクト全体の品質を左右する工程だ。しかし実務では、ドキュメントが整備されていない、設計書が実装と乖離している、開発当時の担当者が在籍していないといった状況が重なり、調査だけで数カ月を要することが珍しくない。

調査すべき4つの観点

調査対象は「機能」「データ」「連携」「業務フロー」の4つの観点に整理できる。

機能の調査では、現在のシステムにどの機能が実装されているかをリストアップする。画面一覧・帳票一覧・バッチ処理一覧を棚卸しするのが基本だ。この段階で「使われていない機能」「ほぼ同じ機能の重複実装」が発覚するケースも多い。

データの調査では、テーブル定義・データ量・データ品質を確認する。特にデータ品質の問題（NULL値の混在、形式の不統一、参照整合性の破綻など）は新システムへの移行時に大きな障壁になるため、早期発見が重要だ。

連携の調査では、他システムとのインターフェース（API・ファイル連携・DB直接参照など）を洗い出す。連携の多いシステムほど移行時の影響範囲が広がり、計画が複雑になる。

業務フローの調査では、システムが支えている実際の業務の流れを確認する。システム仕様書と実際の業務フローが乖離していることは珍しくなく、現場へのヒアリングが欠かせない。

調査の落とし穴：暗黙知と属人化

最も見落とされやすいのが「ドキュメントに残っていない業務ルール」だ。長年運用されてきたシステムには、設計書に記載のない条件分岐や、特定のユーザーだけが知っているイレギュラー処理が組み込まれていることがある。これをすくい上げるには、現場へのヒアリングとソースコードの直接確認を組み合わせる必要がある。

コードベースが大規模な場合、人手による調査には限界がある。AI技術を活用した自動解析ツールが注目されているのはこのためだ。1億行を超えるソースコードの解析を数週間で完了するサービスも登場しており、従来数カ月かかっていた調査期間の大幅な短縮が可能になっている。

📱 SysDock — レガシーシステムの構造をAIマルチエージェントが自動解析。機能一覧・データフロー・依存関係を可視化し、現行調査の期間を大幅に短縮する。料金は月額15万円〜。

👉 詳細を見る

移行アプローチの選定

現行システム調査の結果を踏まえ、どのアプローチで刷新するかを決定する。主な選択肢と特性は以下の通りだ。

選定の際は「何のために刷新するか」という目的に立ち返ることが重要だ。コスト削減が目的であればリホストが有力な候補になるが、業務効率化や新機能追加が目的であればリプレースやパッケージ導入の検討が必要になる。

IPAのモダナイゼーションに関する解説では、「最初から全体を一度に刷新することはリスクが高い」と明確に示している。リスクの低い領域から段階的に進め、実績と知見を積み上げていく方法が推奨されている。

移行計画の策定

移行方式が決まったら、具体的な移行計画を策定する。計画書に盛り込む主要な項目を整理する。

段階移行計画（ウェーブ計画）

システム全体を一括で切り替える「ビッグバン移行」は、リスクが非常に高い。実務では、業務領域やモジュール単位で段階的に移行する「フェーズ移行（ウェーブ移行）」が現実的だ。

フェーズを分ける際の基準は以下の3点が多い。

• 業務の独立性：他の業務との連携が少ない領域から着手する
• データ量：移行データが少ない領域で先行して検証する
• ビジネスインパクト：売上直結の機能は最後に移行する

並行稼働と切り替え判定基準

旧システムと新システムを一定期間並行稼働させることで、移行リスクを低減できる。ただし並行稼働は工数とコストが2倍になるため、期間は最小限に設定する。

切り替えの判定基準（Go/No-Go基準）は事前に明確にしておく必要がある。「テストの合格率が99%以上」「1週間の並行稼働で差異ゼロ」といった定量的な基準を設けることで、担当者の感覚や上位者の判断に依存しない切り替え判定が可能になる。

ロールバック計画

切り替え後に重大な問題が発生した場合の復旧手順を事前に策定しておくことが不可欠だ。ロールバックが現実的に実行可能かどうかは、データの同期方法や旧システムの保持期間にも依存するため、移行設計の段階から織り込んでおく必要がある。

刷新を失敗させる3つのパターン

実際の刷新プロジェクトで失敗が起きやすいパターンとして、次の3つが繰り返し報告されている。

現場の意見を集めすぎて収束しない——ユーザー部門からの要求を広く集めた結果、機能が膨張し、開発期間とコストが当初計画の数倍になるケースだ。「機能はそのままで」という要求を全て飲み込むと、新システムが旧システムの複雑さをそのまま引き継ぐことになる。

ベンダーへの丸投げ——「あとはよろしく」とベンダーに任せきりにすると、ユーザー企業側のシステム理解が深まらないまま納品を迎える。本番稼働後にユーザーから「使いにくい」という声が上がっても、改修の根拠を自社で判断できない状態に陥る。

現行調査の手抜き——時間的プレッシャーから現行調査を圧縮した結果、要件定義フェーズで「こんな機能があったのか」という発見が相次ぎ、設計変更が続発する。中堅製造業の刷新事例では、調査の不足が原因で当初18カ月・約2.5億円の計画が大幅に超過した例も報告されている。

まとめ

システム刷新の成否は、現行システム調査の質と移行計画の精度に直結する。IPAのガイドラインが一貫して強調するのは「上流工程に時間をかけること」だ。着手を急ぐあまり調査を省略すると、下流工程での仕様変更コストが跳ね上がり、結果的にプロジェクト全体が延伸する。

実務上の推奨事項を3点に整理する。

• 現行システム調査は「機能・データ・連携・業務フロー」の4観点で体系的に実施する
• 移行アプローチは刷新の目的に照らして選定し、一括移行よりも段階移行を基本方針にする
• 切り替え判定基準とロールバック計画は移行設計の初期段階で確立する

現行調査の工数が重荷になっている場合は、AIによる自動解析ツールの活用が有効な選択肢だ。コードの自動解析によって、人手だけでは数カ月かかる調査を大幅に短縮できる。

📱 SysDock — AIマルチエージェントがレガシーシステムの構造を自動解析。機能一覧・テーブル定義・画面依存関係を可視化し、現行調査フェーズの工数を削減する。

👉 詳細を見る

姉妹サービスの関連記事

GenbaCompassの姉妹サービスでも、現場改善に役立つ記事を公開している。

• レガシーシステムのリスクと対策
• なぜなぜ分析とフィッシュボーン図の比較

現場改善に役立つ関連アプリ

GenbaCompassでは、SysDock以外にも現場のDXを支援するアプリを提供している。