システム移行のリスクと対策｜レガシーから新システムへの安全な移行

システム移行が失敗したとき、その損失はどれほどになるか。2024年4月、江崎グリコはSAP S/4HANAへの基幹システム移行で大規模なトラブルに見舞われ、売上高ベースで150億円、純利益は53%減という打撃を受けた。出荷停止が解消されるまでに要した期間は約7カ月にのぼる（出典：piyolog「江崎グリコの基幹システム移行トラブル」）。

これは決して他人事ではない。現行システムの把握が不十分なまま移行を進めると、どの企業でも同様のリスクを抱えることになる。本記事では、システム移行でよく発生するトラブルの原因を整理し、現行システムの可視化がなぜリスク低減の鍵になるのかを解説する。

システム移行の失敗が招く損失規模

まず損失の現実を直視しておく必要がある。

経済産業省が2018年に発表したDXレポートでは、レガシーシステムが残存した場合に毎年最大12兆円の経済損失が発生すると試算されている。一方でIPAの調査によると、システム障害による損失額は1社あたり平均約2億1,900万円に達するとされる（出典：IPA「システム障害に関する調査」）。

移行コストにも深刻な非対称性がある。要件定義フェーズを「1」とした場合、本番稼働後に問題が発覚した際のコストダメージは400倍以上にのぼるとも言われる（出典：SBビジネスメディア「基幹システム移行リスク管理」）。移行前に徹底的に問題を潰す理由がここにある。

また、2025年時点でいまだレガシーシステムが残存している企業は**日本全体の61%**にのぼる（出典：経済産業省「レガシーシステムモダン化委員会総括レポート」2025年5月）。移行を「いつかやること」として先送りしてきた企業にとって、残り時間は少ない。

システム移行でよくある5つのリスク

1. 現行システムのブラックボックス化

移行プロジェクトで最も深刻なリスクがこれだ。長年運用されてきたシステムは、担当者の退職や仕様書の紛失によって「誰も全体像を把握していない」状態になりやすい。

依存関係が不明なまま移行を進めると、新システムへの切り替え後に想定外の業務影響が次々と発生する。グリコの事例でも、冷蔵品の出荷に関わる複数業務が連鎖的に停止したことからも、隠れた依存関係の怖さがわかる。

IT資産の可視化ができている企業とできていない企業では、ブラックボックス対策の取り組み状況に大きな開きがある。情報共有が適切にされている企業では71%がIT資産の棚卸しや可視化に取り組めているが、情報共有が不十分な企業では66%で可視化が未達となっている（出典：デジタル庁「レガシーシステムモダン化委員会総括レポート」）。

2. データ移行時の不整合・欠損

現行システムのデータを新システムへ移す際、データの品質問題が表面化することが多い。長年の運用で生じた重複データ、フォーマットの不統一、未整備のマスタデータが、移行後の業務に直接影響する。

グリコの事例でも、物流センターでのデータ不整合が出荷停止の原因のひとつとして報告されている。データ移行は「コピー作業」ではなく、データ品質の検証と移行ルール策定を伴う工程として計画する必要がある。

3. テスト不足による本番稼働後のトラブル

移行プロジェクトの失敗原因を分析すると、「テスト期間の不足」「テスト環境の不備」が根本にあるケースが多い。スケジュール圧力からテストを短縮した結果、本番稼働後に致命的な問題が発覚するパターンだ。

要件定義フェーズで見つけた問題と、本番稼働後に見つけた問題では対処コストが比較にならない。十分なテスト期間とテスト環境の整備は、コスト削減ではなくリスク低減への投資として考える必要がある。

4. 段階移行における新旧システムの連携不備

一括移行ではなく段階的に移行する場合、移行期間中は現行システムと新システムが並行稼働する。この期間中、両システム間でデータを同期させる仕組みが必要になり、インタフェース開発の複雑さがリスクとなる。

連携が不十分だと、新旧システム間でデータのずれが生じ、業務担当者が二重に確認作業を強いられる状況になる。段階移行は慎重に進められるメリットがある反面、移行期間中の管理コストが高くなる点を計画に織り込む必要がある。

5. 人員・体制の不足

2025年時点での調査では、レガシーシステム刷新における課題として最も多かった回答が「他の案件に手いっぱいで十分な要員を割けない」だった（出典：経済産業省「レガシーシステムモダン化委員会総括レポート」）。

移行プロジェクトは、通常業務と並行して進めることが多い。担当者が日常業務に忙殺され、移行プロジェクトが形骸化するリスクは現実的だ。さらに、2030年にはIT人材需要に対して79万人の不足が見込まれており（出典：経済産業省試算）、社内での人材確保は今後さらに困難になる。

リスク低減の鍵は「現行システムの完全な可視化」

5つのリスクを整理すると、その多くは現行システムの把握不足に起因していることがわかる。

• ブラックボックス化 → システム全体像の未把握
• データ不整合 → データ構造・品質の未把握
• テスト不足 → 影響範囲の未把握による計画の甘さ
• 連携不備 → 依存関係の未把握

移行を始める前に「現在のシステムが何をどのように動かしているか」を完全に把握することが、すべてのリスク対策の起点になる。

具体的には以下の4点を可視化する必要がある。

この可視化作業を省いたまま移行を進めることが、大規模障害の直接的な原因になる。

📱 SysDock → 👉 詳細を見る

現行システムの構造解析を効率化するサービスがSysDockだ。COBOL・VB6・Javaなど複数言語に対応し、ソースコードの自動解析によってシステム全体の依存関係や業務ロジックを可視化する。手作業で数カ月かかる調査工程を大幅に短縮でき、移行前の現状把握フェーズで有効に活用できる。料金は¥15万〜。

システム移行を成功させるための対策

移行前：現状把握と計画策定

移行プロジェクト開始前に実施すべき対策を整理する。

• IT資産の全棚卸し：稼働中のすべてのシステム・サーバー・ソフトウェアをリストアップする
• 業務ロジックの文書化：担当者ヒアリングと並行して、ソースコード解析でロジックを把握する
• データ品質の点検：移行対象データの重複・欠損・フォーマット不整合を事前に特定する
• 移行スコープの確定：一括移行か段階移行かを決定し、スコープを明確に定義する
• ロールバック計画の策定：移行に問題が発生した場合の切り戻し手順を事前に用意する

移行中：テストと検証の徹底

• 移行リハーサルの実施：本番移行前に複数回の移行リハーサルを実施し、手順と所要時間を検証する
• データ検証の自動化：移行後のデータが正しく移行されているかを自動チェックする仕組みを整備する
• 並行稼働期間の設定：新旧システムを並行稼働させ、処理結果の差異がないかを確認する期間を設ける
• 切り替えタイミングの選定：業務繁忙期を避け、問題発生時に対処できる余裕がある時期を選ぶ

移行後：安定稼働の確認

• モニタリング体制の強化：本番稼働直後の数週間は特に集中的にシステムを監視する
• ユーザーへのサポート体制：操作方法の変更点を周知し、問い合わせに対応できる体制を維持する
• インシデント対応手順の整備：問題発生時の報告・対応フローを明確にしておく

移行方式の選択がリスクに与える影響

移行方式によってリスクの性質が異なる。自社の状況に合わせた選択が重要だ。

業務の重要度とシステム停止許容時間（RTO）を踏まえて、自社にとって適切な方式を選択する必要がある。重要な基幹システムほど、段階移行や並行稼働を組み合わせてリスクを分散する判断が妥当だ。

まとめ

システム移行の失敗は、数カ月分の業務停止と数十億円規模の損失を招きうる。そのリスクの多くは、移行前の現状把握が不十分であることに起因している。

重要なポイントを整理する。

• 日本企業の61%にはレガシーシステムが残存しており、移行の先送りにはリスクが伴う
• 本番稼働後の問題修正コストは要件定義フェーズの400倍以上にのぼる
• 現行システムの可視化（構成・ロジック・データ・依存関係）が移行成功の起点になる
• 移行方式の選択はリスク許容度と業務重要度を踏まえて決定する
• ロールバック計画と移行リハーサルの実施は必須の対策だ

移行前に十分な時間をかけて現行システムを把握することが、結果的にプロジェクト全体を短期間で終わらせる近道になる。

姉妹サービスの関連記事

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

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

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

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

参考文献

• piyolog「江崎グリコの基幹システム移行トラブルについてまとめてみた」
• 経済産業省「レガシーシステムモダン化委員会総括レポート」（2025年5月）
• デジタル庁「企業のDXを阻む『レガシーシステム』とは？」
• SBビジネスメディア「基幹システム移行のリスク管理ポイント」
• IPA「DX動向2025」