システム刷新時のデータ移行｜失敗しないための注意点

システム刷新では、新しい画面や機能に目が向きがちです。しかし本番切替の当日に問題が起きやすいのは、既存データの移行です。この記事では、システム刷新時のデータ移行で失敗しないための注意点を、発注者の立場から整理します。移行方式の選び方、データクレンジングと移行後の検証、RFPでの情報開示、切り戻し条件の決め方の4点が分かります。

データ移行の注意点：なぜ失敗しやすいのか

データ移行が失敗しやすい理由は、主に次の3つです。

• 移行が「最後にやる作業」として扱われ、計画と予算が後回しになる
• 現行データの件数・形式・重複の実態が分からないまま見積が出る
• 一度きりの作業なので、手順のリハーサルが足りないまま本番を迎える

データの中身を一番よく知っているのは、現場で使ってきた発注者です。ベンダー（開発会社）は移行の手順と道具は用意できます。ただ、「どのデータが正しいか」は決められません。データ移行は、発注者が主体的に関わる作業だと考えてください。

IPA（情報処理推進機構）のシステム再構築を成功に導くユーザガイドも、再構築のリスクを発注者とベンダーで共有することを前提にしています。刷新全体の進め方はレガシーシステム刷新の進め方もあわせてご覧ください。

移行方式の選び方：一括・段階・並行運用

移行方式は大きく3つあります。それぞれに向き不向きがあります。

選ぶときは、次の4点を確認します。

1. 業務を止められる時間はどれくらいあるか
2. データの量と品質（重複や欠損の多さ）
3. 現場が二重入力に耐えられる期間
4. 外部システムとの連携の数

「一括は危ないから並行運用」と決めつける必要はありません。並行運用は安全に見えますが、現場が疲弊して入力漏れが起き、かえって差異が増えることがあります。

データクレンジングと移行後の検証

クレンジングで直すもの

データクレンジングとは、移行前にデータの誤りや不揃いを直す作業です。よくある対象は次のとおりです。

• 重複：同じ顧客が別IDで複数登録されている（名寄せが必要）
• 表記ゆれ：「株式会社」と「(株)」、全角と半角の混在
• 欠損：必須項目が空欄のレコード
• 形式の違い：日付の書き方、コード体系が新システムと違う
• 不要データ：何年も使われていないマスタや試験データ

ここで発注者が決めるのは「どちらを正とするか」というルールです。重複した2件のうち住所が違えば、どちらを残すかは業務の判断になります。古いデータを全件移すのか、一定期間より前は参照用に保管するだけにするのかも決めておきます。

移行後の検証

移行が終わったら、次の順で検証します。

• 件数照合：移行前後でレコード数が一致するか
• 合計値照合：売上合計や残高など、金額や数量の合計が一致するか
• サンプル突合：代表的なデータを抜き出し、画面で目視確認する
• 業務シナリオ確認：実際の業務の流れで、移行データを使って操作する

本番の前に、本番と同じ手順でリハーサルを行い、所要時間も測っておきます。所要時間が分かれば、切替日の作業計画と、後で述べる切り戻しの判断期限を現実的に決められます。受入テストの進め方は受入テストの進め方で詳しく解説しています。

RFPで現行システムの情報をどこまで開示するか

RFP（提案依頼書）に現行システムの情報が少ないと、各社の見積の前提がばらばらになります。後から「想定より件数が多かった」となれば、追加費用の原因になります。最低限、次の情報は開示しましょう。

• 主なデータの種類と件数の概数（顧客、商品、取引履歴など）
• データの持ち方（データベースの種類、ファイル、紙）
• データを取り出す方法（CSV出力、APIの有無、現行ベンダーの協力の可否）
• 外部システムとの連携の一覧
• データ項目の定義書があるかどうか
• 法令や社内規程で決まっている保存期間

一方、実データそのものをRFPの段階で渡す必要はありません。個人情報を含む場合は特にそうです。サンプルが必要なら、氏名や連絡先を加工した匿名データを用意します。詳細な資料はNDA（秘密保持契約）を結んでから開示します。RFP全体の書き方はRFPの書き方、NDAは発注前のNDAを参照してください。

切り戻し条件の決め方

切り戻しとは、新システムへの切替を中止し、旧システムに戻すことです。切替当日に慌てて判断しないよう、条件は事前に文書で決めておきます。

• 判断基準：件数や合計値の不一致、重要な業務が一定時間動かない、など
• 判断期限：何時までに問題が解消しなければ戻すか
• 判断者：誰が最終判断するか（発注者側の責任者を明記する）
• 戻す手順：旧システムをすぐに止めず、いつまで動く状態で残すか
• 切替後に新システムで発生したデータの扱い：戻すときに旧システムへどう反映するか

切り戻しの手順もリハーサルしておきます。「戻せる」と書いてあるだけで、試したことのない手順は当日に動かないことがあります。

受託開発の現場から

ある受託開発会社が、データ移行を含む案件で実際に行っている進め方を紹介します。

• 顧客情報を持つシステムが社内に複数あり、さらに新しいアプリを足そうとしている企業には、先に「どのシステムを顧客情報のマスターにするか」という青写真を描くよう提案しています。新しいアプリがその基盤とつながれば、顧客情報がこれ以上分散しません。
• 移行の前に、顧客情報を持つ全システムを棚卸しします。保有している項目、ID体系、データを出力できるか、APIが公開されているかを一覧にします。APIのないツールは、CSV連携か手作業を前提に費用を試算します。
• 見積には「既存記事は約○件と仮定」のように件数の前提を明記し、件数と形式で費用が変わることを伝えています。見積の工程でも「データ投入・結合テスト」を独立させ、移行作業が他の工程に埋もれないようにしています。
• 本番の移行の前に、データベースの復元手順書とアプリケーションを元に戻す手順書を作ります。そのうえで、本番に近い検証環境で実際に手順を試します。

まとめ

• データ移行は発注者が「どのデータを正とするか」を決める作業で、ベンダー任せにできない
• 移行方式は、業務の停止許容時間、データ品質、現場の負担で選ぶ
• クレンジングのルールを決め、件数・合計値・業務シナリオで検証する
• RFPには件数の概数と取り出し方法を書き、実データは匿名化してNDA締結後に渡す
• 切り戻しの基準・期限・判断者・手順を事前に決め、リハーサルしておく

移行の範囲や件数がはっきりしない段階でも、相談は始められます。FastProposal の無料AI相談では、現行システムの状況を入力すると、案件の論点と費用の目安を数分で整理できます。開発会社に相談する前の準備としてご活用ください。