目次
システム刷新のプロジェクトで、最も事故が多い工程はどこか。要件定義でも開発でもなく、データ移行だ。設計や実装がどれほど丁寧に進んでも、データ移行に失敗すれば本番稼働は即座に止まる。それが基幹系システムであれば、受発注・出荷・会計といった業務全体が連鎖的に停止する。
2024年4月、江崎グリコがSAP S/4HANAへの切り替えを実施した直後、出荷業務が停止した。チルド品の出荷は数か月にわたって続き、売上高ベースで約150億円の損失を被った（出典：ビジネスジャーナル「グリコ障害、開発担当デロイトに原因か」）。同年、ユニ・チャームもS/4HANAと物流システムの連係不具合で出荷遅延が発生している（出典：日経クロステック「グリコもユニ・チャームも苦渋、トラブル相次ぐERP導入」）。いずれも、データ移行工程での検証不足が遠因として指摘されている。
これらは大企業の話ではあるが、構造的な問題は中堅・中小企業でも同一だ。旧システムに蓄積されたデータの品質問題、移行手順の検証不足、整合性確認の甘さ。本記事では、データ移行で繰り返される失敗の構造を分解し、移行前に押さえるべき3つのリスクと具体的な対策を整理する。
なぜデータ移行はこれほど失敗するのか
データ移行が難しい理由は、「開発とは異なる固有のリスクを抱えているから」に尽きる。
開発工程では、不具合が発生しても修正して再テストするサイクルが回せる。しかしデータ移行の本番実施は原則として一発勝負だ。旧システムを停止してデータを移し、新システムを起動する。その瞬間に不整合が発覚しても、即座の修正は困難で、切り戻しの判断を迫られる。切り戻しにかかる時間分だけ業務は止まる。
もう一つの構造的な問題がある。データ移行は「技術の問題」だと思われやすいが、実態は「業務とデータと技術の三つが交差する問題」だ。旧システムのデータ構造を理解するためには技術知識が必要だが、どのデータをどのルールで変換するかを決めるには業務知識が不可欠だ。さらに、変換後のデータが新システムの業務ロジックと整合するかを検証するには、新旧両システムの仕様を横断的に理解する必要がある。この横断的な理解を持つ人材は、多くの企業で圧倒的に少ない。
IPA「ソフトウェア開発分析データ集2022」では、5,546件のプロジェクトを分析し、開発遅延の要因として「要件・仕様の変化・追加」とともに「移行・テスト工程での問題発覚」が上位に挙げられている（出典：IPA ソフトウェア開発分析データ集2022）。プロジェクト終盤で発覚するほど、修正コストは指数関数的に増大する。
データ移行の失敗リスク1：旧データの品質問題
旧システムのデータは「使えない」ことが多い
長年運用されたシステムには、不整合データが蓄積している。これは特殊なケースではなく、ほぼすべての現場で発生する構造的な問題だ。
具体的には次のような状態が観察される。
- 重複レコード。 同一顧客が異なるコードで複数登録されている。合併・組織変更・担当者ミスが重なって生じる。
- 欠損データ。 必須項目が空白のまま長年稼働している。旧システムが当該項目を必須チェックしていなかった場合に起きる。
- 不整合データ。 受注テーブルと在庫テーブルで数量が一致しない。バッチ処理の失敗履歴がそのまま残っている。
- 廃止コードの参照。 マスターから削除されたコードが、トランザクションデータから参照され続けている。
新システムはこれらのデータをそのまま受け入れない。制約条件やバリデーションが厳格化された新システムに不整合データを投入すると、インポート時に大量エラーが発生し、本番稼働が不可能になる。
データクレンジングは「移行前の作業」ではなく「独立したフェーズ」
データクレンジングを「移行直前にちょっとやる作業」と捉えているプロジェクトは失敗する。規模によっては数か月を要する独立したフェーズとして計画すべきだ。
クレンジング作業の進め方は以下の通りだ。
| ステップ | 内容 |
|---|---|
| データプロファイリング | 移行対象データの件数・欠損率・重複率・外れ値を定量的に把握する |
| クレンジングルール策定 | 業務担当者と協議して、不整合データの扱い方（補完・削除・統合）を決定する |
| クレンジング実行 | ルールに基づいてデータを修正する。自動化できる部分はスクリプトで処理する |
| クレンジング後検証 | 修正後のデータが新システムの制約を満たしているかを確認する |
このステップで重要なのは、「ルール策定」だ。技術者だけで進めようとすると、業務上の意味を誤解したまま修正が走る。業務担当者を必ず参加させる必要がある。
着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）
データ移行前に旧システムのDB構造とデータフローを可視化しておくことで、クレンジング対象の特定と移行ルール策定が格段に効率化する。SysDockはAIマルチエージェントがソースコード・DB構造を解析し、テーブル間の依存関係とデータフロー図を自動生成する。ライト30万円から、完全後払いで依頼できる。
データ移行の失敗リスク2：移行手順の検証不足
「本番は一発勝負」を覚悟するな
「本番移行は一発勝負だから、失敗するリスクを覚悟しなければならない」という考え方がある。これは誤りだ。正確には「本番移行が一発勝負になるような準備しかしていないから、失敗リスクが高い」のであって、十分なリハーサルを積めばリスクは大幅に低減できる。
問題は、移行リハーサルに十分な工数が確保されないことだ。開発が遅延すると、そのしわ寄せが移行リハーサルの回数削減に向かう。「1回やれば十分だろう」という判断が、本番でのトラブルを引き起こす。
移行リハーサルで確認すべきことは何か
移行リハーサルの目的は「手順書の確認」だけではない。以下の3点を検証することが本来の目的だ。
1. 移行所要時間の計測。
本番移行は業務停止時間が最小になるよう設計しなければならない。リハーサルで実際の所要時間を計測し、業務停止ウィンドウ内に収まるかを確認する。旧システムのデータ量によっては、想定の2〜3倍の時間がかかることがある。
2. エラー発生パターンの洗い出し。
1回目のリハーサルでは必ずエラーが出る。エラーの種類と件数を記録し、対処方法を確立する。2回目以降で対処後の状態を確認する。
3. 切り戻し手順の検証。
移行が失敗した場合に旧システムへ戻す手順を、実際に実行して確認する。切り戻しも含めてリハーサルしておかないと、本番で切り戻しを判断した瞬間に手順が不明確になる。
最低2回、できれば3回のリハーサルを計画すべきだ。1回目で問題を洗い出し、2回目で修正を確認し、3回目で本番相当の環境と手順で最終検証する。このサイクルを踏まないプロジェクトは、本番で初めて問題に直面することになる。
並行稼働期間の設計も移行計画の一部
移行後の並行稼働期間についても計画が必要だ。並行稼働とは、新旧システムを同時に稼働させ、両者の処理結果を突き合わせる期間を指す。
並行稼働期間が短すぎると、通常業務ではなく月次処理・四半期処理・年次処理でしか発生しない不具合を見逃す。逆に長すぎると、現場の負荷が限界に達する。業務サイクルに応じた期間設定が必要だ。
| 業務の種類 | 最低限必要な並行稼働期間 |
|---|---|
| 日次処理が中心 | 1〜2週間 |
| 月次処理を含む | 1〜2か月 |
| 四半期・年次処理を含む | 3〜4か月 |
データ移行の失敗リスク3：整合性検証の不徹底
「データが入った」と「業務が動く」は別の話
移行後のデータ検証において、最も見落とされやすい視点がある。「データが正しく入った」ことと「業務ロジックが正しく動く」ことは、別の確認事項だ。
データが件数どおりに移行され、フォーマットも正しい。しかし、業務処理を実行すると結果が旧システムと一致しない。この不整合は、テーブル単体の検証では発見できない。複数テーブルにまたがるデータの連携関係、計算ロジック、マスターとトランザクションの結合パターンを実際の業務シナリオで動かして初めて発覚する。
グリコの事例でも、切り替え直後に「物流センターでのデータ不整合が発生し、受注処理が想定した速度で処理されなかった」と報告されている（出典：日経クロステック「グリコもユニ・チャームも苦渋」）。移行したデータ自体の問題というより、移行後のデータと業務ロジックの整合が取れていなかったことが問題の本質に近い。
整合性検証の3つのレイヤー
データ移行後の整合性検証は、3つのレイヤーで設計する必要がある。
レイヤー1：データ件数・フォーマット検証。
移行前後の件数が一致しているか。移行先の型定義に適合しているか。これが最低限の検証だが、ここだけで終わるプロジェクトが多い。
レイヤー2：参照整合性検証。
外部キー制約が守られているか。マスターに存在しないコードがトランザクションから参照されていないか。旧システムで許容されていた不整合が、新システムでエラーになっていないかを確認する。
レイヤー3：業務シナリオ検証。
代表的な業務処理（受注登録・在庫引き当て・請求処理・締め処理など）を新システムで実行し、旧システムの処理結果と突き合わせる。金額・数量・集計値が一致することを確認する。
この3つのレイヤーをすべてパスして初めて「移行が完了した」と言える。レイヤー1だけで本番稼働に踏み切ることは、移行検証の放棄に等しい。
着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）
整合性検証の設計には、旧システムの業務ロジックとデータ構造の正確な理解が前提となる。SysDockの解析レポートでは、テーブル定義・関連テーブル間の依存関係・主要な処理フローを可視化する。検証シナリオの策定に直接活用できる情報を、1週間で納品する。
移行計画を成功に導く4つのステップ
失敗事例に共通する問題を踏まえ、移行計画を成功させるための4ステップを整理する。
ステップ1：要件定義フェーズからのデータアセスメント
データ移行の計画は、開発着手前に立てなければならない。要件定義フェーズでは、以下のアセスメントを並行して進める。
- 移行対象データの洗い出しと件数確認
- データ品質の初期評価（サンプルを取得して欠損率・重複率を概算）
- 新旧システム間のデータ構造ギャップの特定
- クレンジングに要する工数の見積もり
このアセスメントを省略すると、開発が終盤に差し掛かった段階でデータ品質問題が発覚し、プロジェクト全体の計画を見直す羽目になる。
ステップ2：クレンジングと変換ルールの業務部門との合意
クレンジングルールと変換ルールは、技術者と業務担当者の共同作業で策定する。「このデータはどう扱うか」という判断は業務知識なしには下せない。
変換ルールはドキュメント化し、業務部門の承認を取る。後から「そんなルールで変換したのか」という紛争を防ぐためだ。
ステップ3：段階的リハーサルによる手順の精度向上
移行リハーサルは段階を追って実施する。
- 開発環境での手順確認（内部テスト用）：手順書の動作確認と所要時間の初期計測
- ステージング環境での本番相当リハーサル：本番に近いデータ量とシステム構成で実施。切り戻し手順も含めて検証
- 最終リハーサル：本番同様の手順・タイムラインで最終確認
各回のリハーサル後に発見事項を整理し、手順書を改訂してから次のリハーサルに進む。
ステップ4：本番移行後の集中監視と段階的な並行稼働終了
本番切り替え後の最初の1〜2週間は集中監視体制を敷く。通常の業務ではなく、処理ログ・エラーログ・業務担当者からのフィードバックを毎日確認する。
並行稼働の終了は段階的に行う。日次処理を旧システムなしで問題なく回せるようになってから月次処理に進む。月次処理まで確認できた段階で、正式に旧システムを停止する。
SysDockでデータフローを事前に可視化する
データ移行の準備で最も時間がかかる作業は、現行システムのデータ構造と業務ロジックの把握だ。設計書が存在しないか、実態と乖離している場合は、ソースコードとDBから直接解析するしかない。これを人手で行うと、数十万行規模のシステムでは数か月を要することもある。
SysDockはAIマルチエージェントがソースコードを解析し、以下の情報を1週間で可視化する。
| 出力内容 | データ移行での活用方法 |
|---|---|
| テーブル定義一覧 | 移行対象データの全量把握と品質評価の起点となる |
| テーブル間依存関係マップ | 移行順序の決定と参照整合性検証の設計に使う |
| データフロー図（React Flow） | どの業務プロセスがどのデータを読み書きするかを可視化する |
| 処理フロー図 | 変換ルール策定と業務シナリオ検証のシナリオ設計に使う |
内部リンク先のシステム刷新プロジェクトの失敗パターン5選と回避策でも指摘したとおり、現行システムの正確な理解なしにデータ移行計画は立てられない。SysDockのレポートは、移行計画の土台となる「現状把握」を確実に行うために設計されている。
移行前チェックリスト
データ移行に着手する前に、以下を確認してほしい。
| チェック項目 | 確認内容 |
|---|---|
| データアセスメント | 移行対象データの品質（欠損率・重複率）を定量的に把握済みか |
| クレンジング計画 | クレンジングルールを業務部門と合意済みか。工数を計画に組み込んでいるか |
| リハーサル回数 | 最低2回のリハーサルを計画しているか |
| 切り戻し手順 | 本番移行が失敗した場合の復旧手順とタイムラインが文書化されているか |
| 整合性検証設計 | 業務シナリオベースの検証（レイヤー3）が計画されているか |
| 並行稼働期間 | 業務サイクルを考慮した期間が設定されているか |
| 体制 | 技術担当と業務担当が連携できる移行チームが組まれているか |
これらの項目に全てチェックが入らない状態で本番移行に踏み切ることは、失敗リスクを自ら引き上げることになる。
まとめ：データ移行の失敗は「準備の失敗」
データ移行の失敗事例を分析すると、原因は技術的な問題よりも準備の不足に起因するものが圧倒的に多い。旧データの品質問題を事前に把握していなかった。移行手順のリハーサルが不十分だった。整合性検証が件数チェックで終わっていた。いずれも、計画段階で対処できた問題だ。
データ移行を成功させるための原則は一つだ。「移行計画は要件定義フェーズから立て、リハーサルに十分な工数を確保し、業務シナリオ検証まで含めた整合性確認を実施する」。この原則を守れば、本番稼働後に致命的なトラブルに見舞われる確率は大幅に下がる。
起点となるのは、現行システムのデータ構造とデータフローの正確な把握だ。ここが不明確なまま進めたプロジェクトが、終盤に多大なコストをかけて手戻りを余儀なくされる事例を、業界は繰り返し目撃してきた。
着手金0円・完全後払い。まずはお見積り → SysDock（シスドック）
データ移行前の現状把握なら、SysDockにお任せください。AIマルチエージェントがソースコードとDB構造を解析し、テーブル定義・依存関係・データフロー図を1週間で納品します。Wordレポート+PowerPointスライド+React Flowフロー図の3点セット。ソースコード非送信・完全後払いで、ライト30万円から。移行計画の精度を上げたい方はまずお見積りから。
無料お見積りはこちら → sysdock.genbacompass.com
よくある質問（FAQ）
Q. データ移行のクレンジングにはどれくらいの期間が必要ですか？
A. システムの規模とデータ品質によって大きく異なる。数万件規模の比較的クリーンなデータであれば2〜4週間で対応できる場合もあるが、数百万件規模で長年の不整合が積み重なったデータでは3〜6か月を要することがある。まず移行対象データのサンプリングを行い、不整合率を定量的に把握してから工数を見積もるべきだ。
Q. 並行稼働はどのくらいの期間が必要ですか？
A. 業務サイクルに依存する。日次処理だけを持つシステムなら1〜2週間で十分な場合もあるが、月次締め・四半期処理・年次処理を持つ基幹系では3〜4か月が目安だ。業務上の全サイクルを新システムで一巡させてから旧システムを停止することが原則となる。
Q. 旧システムの設計書がない場合、データ構造はどう把握すればよいですか？
A. ソースコードとDB定義ファイルが残っていれば、そこから解析できる。SysDockのようなAI解析ツールを使えば、ソースコードからテーブル定義・依存関係・データフローを自動生成できる。設計書がなくても、ソースコードとDBさえあれば移行計画に必要な情報は取り出せる。
現場改善に役立つ関連ツール
GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。
| ツール名 | 概要 | こんな課題に |
|---|---|---|
| 技術伝承AI | ベテランの暗黙知をAIで形式知化し、ナレッジとして蓄積・共有する | 退職・異動による技術ノウハウの喪失を防ぎたい |
| WhyTrace | 5Why分析をAIが支援し、問題の根本原因を体系的に究明する | トラブルの再発防止策を確実に導きたい |
| AnzenAI | 安全書類の作成をAIで効率化し、現場の安全管理を支援する | 安全書類の作成工数を削減したい |
| PlantEar | 設備の異音をAIが検知し、故障の予兆を早期に発見する | 設備の突発故障を未然に防ぎたい |
| IdeaLoop | 現場からの改善提案を収集・管理し、実行までを一元化する | 改善提案制度を活性化させたい |
参考文献
- IPA「ソフトウェア開発分析データ集2022」https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html
- 日経クロステック「グリコもユニ・チャームも苦渋、トラブル相次ぐERP導入に潜む大きな理解不足」https://xtech.nikkei.com/atcl/nxt/column/18/00138/061001541/
- ビジネスジャーナル「グリコ障害、開発担当デロイトに原因か…なぜERP刷新失敗で1カ月も出荷停止」https://biz-journal.jp/company/post_380413.html
- NTTコミュニケーションズ「データ統合や移行でよくあるトラブルとその解決方法」https://www.ntt.com/business/sdpf/knowledge/archive_43.html
- Granpaz「データ移行はなぜ失敗するのか」https://www.granpaz.co.jp/sap/1861/