データ移行とは

データ移行とは

旧システムが保有するデータを、新システムで使用できる形式に変換したうえで移行する工程です。
売上、顧客、在庫、取引履歴など、業務が依存するデータを引き継がないと、新システムでは過去の照会と集計ができません。

移行は一般に、抽出、変換、投入、突合の4つの作業に分けて整理されます。
移行する範囲を確定して旧システムから抽出する作業、項目の対応関係を確定して形式を変換する作業、新システムに投入する作業、投入した結果を元のデータと比較する作業（突合）です。

データ移行で確認すべき観点には、移行対象の整理、レイアウトの確認、データクレンジング、文字コードのマッピング、移行方法の選定、移行実施結果の確認の6つがあります。
移行対象の整理、レイアウトの確認、データクレンジング、文字コードのマッピング、移行方法の選定、移行実施結果の確認です。

移行しないと止まる業務がある

システムの更改や製品の切り替えでは、新システムの画面と項目に適合させてデータを移行する必要があります。
移行しなければ過去の取引、契約、在庫の履歴を新システムで参照できず、請求、返品、問合せの対応が停止します。

会計や法令の保存期間を満たすために旧システムを維持する選択もありますが、保守期限が満了すると、参照のためだけに費用が発生し続けます。

移行の検討は要件定義から開始します。
要件定義の段階で、業務移行、システム移行、データ移行について、移行時期、移行方式、移行対象、移行環境を非機能要件として定義する必要があります。

すべてのデータを移行する必要はありません。
移行対象を絞ると作業量とコストを抑えられます。稼働期間の古いデータは移行しないという選択が有効です。

過去のデータを引き継げる

• 過去の取引と残高を新システムで参照でき、業務を停止せずに切替できる
• 重複した顧客と表記の揺れを解消でき、集計と検索の精度が向上する
• 移行を機に不要な項目と書類を廃止でき、移行後の運用と保守の負担が減少する
• 例外の扱いを業務部門と合意する過程で、業務の暗黙の前提が明文化される

開発の終盤に作業と手戻りが集中する

データ移行の問題は開発の終盤に判明しやすいです。
計画の検討が遅れると、プロジェクト全体の計画とコストに影響する可能性があります。問題が発生した場合の解消期間も計画に反映する必要があります。

• 項目のレイアウトの未確認や想定外の値が原因で、移行のやり直しが発生する
• データクレンジングと、移行できなかった不整合データの修正に、業務部門と開発側の双方の工数を要する
• 突合の完了条件を確定しないまま開始すると、差異の調査が終了せず、本番切替の日を決定できない
• 並行稼働を選択すると同じ業務を二重に実施する期間が生じ、利用部門の負担が増加する
• 旧システムのサポートが終了する前に移行を完了する必要があり、延期できる幅が限られる
• 移行直後は問合せと手作業の補正が増加するため、運用の受け入れ体制を別に用意する必要がある
• 移行後のデータ品質を維持するには、入力規則と重複の点検を運用に導入する必要がある
• 個人情報や機密のデータは移行作業の委託範囲、利用目的、保存先の国や地域を確認し、テストで使用するデータは個人を特定できない形にする
• 切戻しの判断基準と手順が未確定だと、切替後の不具合で戻せない
• 旧システムは切替後も一定期間、参照できる状態で維持する

計画を立てる前提として、移行の作業量は開発全体の1〜2割程度になることが多いです。

移行をどう計画するか

移行を独立した工程にするかは、データの件数では規定されません。
項目の対応関係と例外の数で規定されます。
件数と年数は突合とリハーサルを何回行うかを決定する材料になります。

独立した工程として確保するか

項目が数十で新旧が1対1に対応するなら、数百万件でも開発の作業に含められます。
項目の意味が変化する場合、複数の旧項目を1つに統合する場合、例外が多数になる場合は、数千件でも独立した工程を確保します。
件数と年数は、突合とリハーサルを何回行うかを決めます。数百万件規模で10年分を超えるなら、設計、リハーサル、突合、例外の修正で3〜6か月かかることが多いです。

新しいシステムのデータ構造の定義と、保有するデータの標準的及び例外的な変換方法の作成が必要です。

独立した工程にする場合は移行の設計、リハーサル、突合、例外の修正に分割して工数を見積もります。
リハーサルは本番と同じ手順で実施します。
独立した工程にしない場合も、初期データの投入と、投入後の件数の確認は必要です。

一括で切り替えるか、並行して稼働するか

移行の方式には、一括移行、段階移行、差分移行などがあります。
一般に、一括移行は切替日に新旧を一斉に切り替える方式、段階移行は業務や拠点を分けて順に切り替える方式、差分移行はあらかじめ大部分を移行しておき、切替の直前に変更した分だけを移行する方式です。
移行方法の選定も、確認観点の1つです。

方式とは別に、切替のリスクを低減する手段として並行稼働があります。
一定期間、旧システムと新システムの両方で同じ業務を実施し、不具合を特定します。
並行稼働では、利用部門の負担が増えるため許容できる範囲を確認することと、旧システムのサポートが終了するまでの期限内で実施できるかを確認します。

業務の停止が売上や法令の対応に直結する場合や、金額と在庫の一致を重視する場合は、段階移行を選択するか、一括移行に並行稼働を併用します。
並行稼働は移行の方式ではなく、切替のリスクを低減する対策です。
参照系のシステムや、利用者が少なく影響の限られる場合は、一括移行で十分です。

切替日は旧システムの契約の終了日から間隔を確保して設定します。
切替日は、1〜2か月の延期を想定することと、契約の終了日に近い日を避けることが勧められます。

突合をどこまで行うか

突合は全件の比較と例外の確認を併用します。
金額、在庫、契約者数など、請求や法令の届出に影響する項目は全件を比較します。
参照用の項目と履歴は件数と合計が一致することを確認し、差異が発生した箇所を個別に調査する方法で十分です。

移行後のデータだけでなく例外データ等についても確認し、データの品質を確保します。

突合の完了条件は開始前に決定します。
新旧の比較テストでは全ルートの網羅性を保証できないため、業務継続性を担保できる要件を定量的な基準として定め、基準を満たせば完了とします。

完了条件の例は金額の合計の差異を0円とすること、件数の差異を0.01%以内とすること、例外の一覧を業務部門が承認することです。
許容する桁は業務ごとに決定します。
突合の結果は業務部門が確認します。
開発側だけで一致を判定すると、業務上の意味が変化した差異を検出できません。
参照用のデータだけなら件数と合計の確認に限定できます。

よくある誤解

移行ツールを導入すれば自動化できる

ツールは変換と投入の反復を省力化しますが、項目の対応関係の決定と例外の処理は人が行います。
例外の扱いが移行の品質を左右するため、標準的及び例外的な変換方法の作成が求められます。

データ移行は本番切替の直前に実施する

試験工程で実際の業務データを使用する場合、データ移行の完了がテストの開始に影響します。
試験工程までにデータ移行を完了させる必要があります。

すべてのデータをそのまま移行するのが安全

全件を移行すると使用されていない項目の変換と例外の処理に工数がかかります。
法令の保存期間と照会の頻度で保持する範囲を確定し、保持する分は旧システムの参照手段を確保します。

データ移行はシステム部門だけで進められる

項目の意味と例外の扱いは業務部門が決定します。
レイアウトの確認とデータクレンジングの役割分担は、利用部門と開発側の双方で明確にする必要があります。

データ移行の工数はデータ件数に比例する

件数が増加すれば投入と突合の時間は増加しますが、工数を規定するのは項目の対応関係と例外の数です。
新旧が1対1で例外が少なければ、件数が増加しても作業は比例して増加しません。