基幹システムのデータ移行｜計画・クレンジング・照合・リハーサルの進め方

基幹システムのデータ移行は、「何を移さないか」を最初に決め、照合の合格基準を数字で合意してからリハーサルを2〜3回まわすと失敗しにくくなります。移行作業そのものより、クレンジングと照合に時間がかかるからです。この記事では、システムのデータ移行について、移行対象の判定表、移行計画書の項目、照合シートの数値例、本番切替週末のタイムライン例を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

システムのデータ移行とは：移す作業より「決める作業」が多い

システムのデータ移行は、現行システムにある取引先・品目などのマスタ、売掛金や在庫の残高、受注や請求の履歴を、新しい基幹システムで使える形に変えて載せ替える作業です。プログラムで変換して投入する部分はベンダーが担いますが、どのデータを移すか、汚れたデータをどう直すか、何が一致すれば合格かは発注側にしか決められません。

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」（2018年）は、データ移行の計画が遅れるとプロジェクト全体の計画やコストに大きく影響すると指摘しています。理由として挙げているのは2つです。1つは、移行対象やレイアウトの確認、データクレンジングに手間がかかること。もう1つは、移行したデータをテスト工程で使うため、移行が遅れるとテストの開始が遅れることです。

中小企業の刷新で特に起きやすいのは、後者の連鎖です。受入テストを架空のテストデータで始め、本番データを入れた途端に「掛率が違う」「締め日が登録されていない」と不具合が噴き出します。受入テストの組み立てはユーザー受入テスト（UAT）の進め方で解説していますが、その前提になるのがデータ移行の計画です。

データ移行は大きく3つのデータに分けて考えます。

• マスタデータ：取引先、品目、単価・掛率、倉庫、勘定科目、社員など。新システムの動きを決める設定値
• 残高データ：売掛金・買掛金の残高、在庫数量と金額、受注残・発注残など。切替時点の「いまの状態」
• トランザクション（履歴）データ：過去の受注・出荷・請求・入金・仕入の明細。分析や問い合わせ対応に使う記録

この3つは移し方も、照合の方法も、失敗したときの影響もまったく違います。ひとまとめに「データ移行」と呼んで計画を1行で済ませると、テストや切替の直前に作業が集中して詰まりやすくなります。

データ移行の対象の決め方：4つの方針と判定表

移行対象を決めるときは、データの種類ごとに次の4つのどれにするかを決めます。IPAのガイドも「全部移行すると作業量が増え、時間がかかる。コスト増にもつながる」として移行対象を絞るよう勧め、例として、稼働期間で3年以上前のデータやトランザクションデータは移さないといった範囲の方針を明確にすることを挙げています。

• 全件移行：現行の全レコードを移す
• 有効分のみ移行：使っているもの、残高があるものだけを移す
• 期間限定移行：直近1〜2年分など、期間を区切って移す
• 移さない（参照で残す）：新システムには入れず、旧データを照会用に保管する

次の表は、中小企業の基幹システムでよく使う判定の目安です。

※判定の目安です。業種や取引の性質によって変わります。

「移さない」と決めたデータも、捨ててよいわけではありません。国税庁のタックスアンサー（No.5930、令和8年4月1日現在法令等）によると、法人は帳簿書類を確定申告書の提出期限の翌日から原則7年間（青色繰越欠損金が生じた事業年度は10年間）保存する必要があります。旧システムを読み取り専用で残すのか、CSVやPDFで書き出して保管するのか、検索できる状態を誰がいつまで維持するのかを、移行計画の中で決めておきます。

移す量を減らすほど、クレンジングと照合の手間は減ります。一方で「過去の売上を見られなくなる」という現場の不安はほぼ確実に出てきます。そこで、よく見る履歴は新システムのBI（集計・分析の仕組み）に入れ、まれにしか見ない履歴は旧データで参照すると分けると、合意を取りやすくなります。

データ移行計画書に書く10項目

データ移行計画書は、移行の範囲・方法・合否基準・スケジュールを1冊にまとめた文書です。要件定義の段階で骨格を作り、設計の進み具合に合わせて詳しくしていきます。要件定義書の中の「移行要件」の章との関係は要件定義書の書き方も参考にしてください。

表の右端に「発注側」が多いことに気づくと思います。ベンダーに「データ移行もお願いします」と頼んだつもりでも、契約上は「移行ツールの作成と実行」だけが範囲で、クレンジングと照合の確認は発注側の作業になっていることがよくあります。見積もりの段階で、どこまでが作る側の作業かを確認してください。見積書の見方はシステム開発の見積もりの見方で解説しています。

発注側の作業が軽く見られがちなことは、裁判例にも表れています。病院情報管理システム（電子カルテ）の開発が頓挫した旭川医科大学とNTT東日本の訴訟で、札幌高裁（2017年8月31日判決）は、契約上ユーザー（大学）の責任とされていたマスタの抽出作業を怠ったことなどを、発注側の協力義務違反と判断し、大学側に約14億1,500万円の支払いを命じました（Westlaw Japan「WLJ判例コラム 第120号」による）。マスタの準備は「ベンダーがやってくれるもの」ではありません。

なお、IPAの「非機能要求グレード」でも、移行性は非機能要件の大項目の一つです。要件定義の段階で、性能やセキュリティと同じ重さで扱ってください。

5の移行方式は、IPAのガイドが挙げる3つが基本です。

• 一括移行：切替日に全データをまとめて移す。中小企業の基幹システムではこれが最も多い
• 段階移行：拠点別・業務別に順番に移す。拠点が多い、業務が独立している場合に向く
• 差分移行：事前に大半を移しておき、切替直前に増えた分だけを移す。データ量が多く、停止できる時間が短い場合に使う

データ移行の手順：7つのステップ

データ移行の手順を、要件定義から本番切替まで時系列に並べると次のようになります。業務アプリケーションの開発と並行して進む、もう1本のプロジェクトだと考えてください。

1. データの棚卸し（要件定義の前半）
   現行システムのテーブルやファイル、Excelで管理している台帳を一覧にし、件数と更新頻度を調べます。「営業が個人で持っている顧客リスト」「工場の段取り表」のように、システムの外にある管理データもここで洗い出します。
2. 移行方針と範囲の決定（要件定義の後半）
   前の章の判定表を使い、データごとに方針を決めます。切替日（月初か期首か）もこの段階で仮決めします。
3. 項目対応表の作成（設計）
   旧項目と新項目を1対1で対応させ、旧にない項目の初期値、コードの変換表を決めます。品目コードや取引先コードの体系を変える場合は、新旧コードの対照表がここで必要です。
4. クレンジング（設計〜テスト前）
   重複・欠落・表記ゆれ・不正値を直します。最も時間がかかる工程で、発注側の担当者の工数を確保しておかないと進みません。
5. 移行ツールの作成と単体確認（開発）
   抽出・変換・投入のプログラムや手順書を作り、少量のデータで動作を確かめます。
6. 移行リハーサル（テスト工程）
   本番と同じ手順で移行し、照合までを通して行います。2〜3回まわし、回を追うごとに本番に近づけます。
7. 本番移行と照合、稼働判定
   旧システムの入力を止め、最終データを移し、照合結果をもとに稼働してよいかを判定します。判定の基準と切り戻しの考え方は稼働判定と本番切替で詳しく扱っています。

手順3でコード体系を見直すと、移行の作業は大きく増えます。それでも、品目や取引先のコードに意味を詰め込みすぎて桁が足りない、同じ会社に複数のコードがある、といった問題は刷新のときにしか直せません。コード体系と名寄せの進め方はマスタデータ整備とコード体系の決め方にまとめています。

データクレンジングの進め方：よくある5種類の汚れ

クレンジングとは、移行するデータの重複・欠落・誤りを直す作業です。IPAのガイドも、想定外の値が含まれるおそれがあるとしてクレンジングの実施と、発注側とベンダー側の役割分担の明確化を求めています。中小企業の基幹システムで見つかる汚れは、だいたい次の5種類です。

• 重複：同じ取引先が「（株）山田商店」「山田商店株式会社」で2コードある。電話番号・法人番号・住所で突き合わせて見つけ、残すコードを決めて、もう一方は統合先として記録します。
• 欠落：締め日や支払条件が空欄、品目の単位が未登録。新システムで必須になる項目が空のレコードを抽出し、担当部署に一覧を渡して期限つきで埋めてもらいます。
• 表記ゆれ：「ｶﾌﾞｼｷｶﾞｲｼｬ」「㈱」「(株)」や全角・半角が混在。文字の種類ごとに件数を数え、変換ルールを決めて一括で直します。
• 不正値・矛盾：マイナスの在庫、存在しない倉庫コード、終了日が開始日より前の単価。値の範囲と他マスタとの整合を機械的に確認し、原因を確かめてから直します。在庫は棚卸しで確定させます。
• 使われていないデータ：10年以上取引がない取引先、廃番から数年たった品目。最終取引日・最終出荷日で抽出して移行対象から外し、外したリストは保管します。

クレンジングは、旧システムの上で直すのか、移行用に抜き出したファイルの上で直すのかを最初に決めます。旧システムで直せば切替まで正しいデータで業務が回りますが、旧システムの入力チェックが弱いと再び汚れます。移行用ファイルで直すと、リハーサルのたびに同じ修正をやり直すことになります。おすすめは、重複・欠落・不正値は旧システムで直し、表記ゆれやコード変換は移行ツールのルールで直すという分け方です。

照合の方法：件数・金額・サンプルの3段で突き合わせる

照合とは、移行したデータが正しく載ったかを、旧システムと新システムの数字を突き合わせて確かめる作業です。IPAのガイドは、移行結果の確認方法について発注側とベンダー側の双方で合意することを求めています。合意がないまま本番を迎えると、「この差は許容範囲か」をその場で議論することになります。

照合は、次の3段で行うと漏れにくくなります。

• 件数照合：移行対象のレコード数と、新システムに入ったレコード数が一致するか。除外した件数も含めて説明がつくか
• 金額・数量照合：売掛残高、在庫金額、受注残金額などの合計が、取引先別・品目別・倉庫別に一致するか
• サンプル照合：代表的な取引先・品目を選び、画面や帳票で項目の中身まで確かめる

次の表は、照合シートの記入例です。

※説明用の例です。数値は架空です。

この例で見てほしいのは2点です。1つは、品目マスタの2件の差を「たった2件」で済ませないことです。2件の原因が変換ルールの誤りなら、ほかのデータにも同じ誤りが潜んでいます。もう1つは、在庫金額の端数のように差が出ることが分かっている項目は、事前に合格基準の中で許容の条件と理由を書いておくことです。単価の小数点以下の扱いが新旧で違うと、合計金額に数百円の差が出ることがあります。

照合の確認者は、移行作業をした人とは別の人にします。売掛金は経理、在庫は倉庫や購買、受注残は営業事務と、日常その数字を見ている人が確認すると、差異の原因にすぐ気づけます。

移行リハーサルは何回やるか：3回の目的の違い

移行リハーサルは、本番と同じ手順でデータを移し、照合までを通して行う予行演習です。IPAのガイドも、テスト開始前のリハーサル、移行できなかった不整合データの修正、リハーサルの再実施が発生しうるとして、早めの計画を求めています。中小企業の基幹システムなら、目的を変えた3回が目安です。

1. 第1回（受入テストの前）：手順が最後まで通るか、変換ルールに誤りがないか
   終わったときに分かること：エラーで投入できないデータの件数と原因。クレンジングの残作業
2. 第2回（受入テストの途中〜後半）：所要時間の計測と、照合の手順の確認
   終わったときに分かること：本番の時間割が組めるか。照合シートが使えるか
3. 第3回（本番の2〜4週間前）：本番と同じ日時・体制・データ時点での通し
   終わったときに分かること：本番の時間内に終わるか。稼働判定に使える照合結果が出るか

第1回で移したデータは、そのまま受入テストに使います。架空のデータではなく本物の取引先と品目でテストすると、締め日や掛率の設定漏れがテストで見つかります。IPAのガイドも、試験工程で現行の動きを確かめるにはサンプルデータではなく実際の業務データでテストすべきだとしています。

第3回で時間内に終わらなかった場合は、本番の日程を見直すか、差分移行に切り替えるかを判断します。この判断を本番の週になってから行うと、選択肢がほとんど残りません。

本番移行の週末の時間割（データ移行の作業に絞った例）

月末締めの会社が、月初の土日でデータを移す場合の、抽出・投入・照合の時間割の例です。切替当日の業務全体の段取りや判定会議の進め方は、稼働判定の記事で扱っています。

※説明用の例です。データ量や業務によって時間配分は変わります。

この時間割で一番大事なのは、日曜10時の判定会議までに照合を終え、差異とその理由を一覧にしておくことです。判定で「No-Go」になった場合に月曜から旧システムで業務を続けられるよう、旧システムは停止せず、入力だけを止めておきます。

データ移行でつまずく典型と、事前に確認するチェックリスト

データ移行のトラブルは、終盤になって表に出るのが特徴です。IPAのガイドも、データ移行の問題は開発の終盤で表面化するため、問題を解消する期間も計画に入れるべきだとしています。よくあるつまずきを、原因と予防策で整理します。

• 文字が化ける・欠ける：旧システムの外字（社名や人名の特殊な漢字）が新システムにない。IPAのガイドも文字コードの対応づけを確認観点に挙げています。外字を使っている件数を棚卸しの段階で数えておきます。
• レイアウトが途中で変わっていた：旧システムの改修で、ある時期からファイルの項目の並びが変わっていた。抽出したデータの項目定義を、発注側とベンダー側の双方で確認します。
• 在庫が合わない：切替直前の棚卸しをしないまま、帳簿在庫を移した。移行前に実地棚卸しで在庫を確定させ、差異を処理してから移します。
• 残高の内訳が作れない：旧システムでは取引先ごとの残高しか持っておらず、新システムは請求書ごとの消込を前提にしている。移行前に内訳を作るか、「移行残高」という1件にまとめるかを決めます。
• Excel台帳が移行対象から漏れた：特別単価や得意先別の納品条件が、システムではなく担当者のExcelにあった。棚卸しでシステム外の台帳を必ず聞き取ります。

着手前と本番前に、次の項目を確認してください。

• データの種類ごとに「全件／有効分／期間限定／移さない」が決まっている
• 移さないデータの保管方法・保管期間・参照方法が決まっている
• Excelや紙で管理している台帳も棚卸しの対象に入っている
• 項目対応表とコード変換表を、発注側の業務担当者が確認した
• クレンジングの担当者・件数・期限が一覧になっている
• 照合の方法と合格基準（許容する差異とその理由）を文書で合意している
• 照合の確認者が、移行作業をした人と別になっている
• 移行リハーサルを2回以上予定し、本番と同じ手順で通す回がある
• 本番の所要時間をリハーサルで計測し、時間割に余裕がある
• 切替前の実地棚卸しと月次締めの日程が決まっている
• No-Goの場合に旧システムで業務を続ける手順がある

この記事で挙げたようなつまずきは、刷新プロジェクト全体の失敗要因の一部でもあります。ほかの典型的な失敗はERP導入の失敗パターンで整理しています。

よくある質問

まとめ

システムのデータ移行は、移す作業よりも移す範囲・直し方・合格基準を決める作業が中心です。マスタ・残高・履歴を分けて方針を決め、移さないデータの保管方法まで決める。クレンジングの担当と期限を一覧にする。照合の基準を数字で合意し、目的の違う3回のリハーサルで本番に近づける。この順番を守れば、稼働直前に数字が合わずに延期する事態はかなり防げます。

自社のデータがどの程度整っているか、どこから手を付けるべきか分からない場合は、無料診断で現状と移行の論点を整理できます。