データを移しただけでは業務は動かない：データ移行で守る品質と業務上の意味
「全件を取り込めた」「移行プログラムは正常終了した」。どちらも必要な確認ですが、それだけでは新システムで業務を続けられると判断できません。移した顧客コードが別の取引先を指していたり、過去の伝票が現在の単価で再計算されたりすれば、処理として成功していても業務上は誤りです。
レガシーシステムには、長年の運用によって定着したデータの読み方があります。モダナイゼーションのデータ移行は、その読み方を明らかにし、新しい設計でも意味が通じる形へ変換する仕事です。
最初に調べるのは、項目名と実データのずれ
設計書の項目名が「日付」でも、実データには未確定を表すゼロや、特別な処理を指示する値が含まれているかもしれません。「顧客コード」も、全社で一意なのか、会社・部門・年度と組み合わせて初めて一意になるのかで移行方法が変わります。
そこで、項目定義の確認と並行して、値の分布、空欄、重複、桁数、参照先のないデータを調べます。これをデータプロファイリングと呼びます。ただし、異常に見える値を機械的に修正する前に、その値を読み取るプログラムの処理と、業務担当者の判断を確認する必要があります。技術的な不整合と、業務上の例外は同じではありません。
確認対象 | 見落とすと起きること | 決めておく変換ルール |
識別子の範囲 | 同じコードを持つ別の顧客を統合する | 一意性の範囲と新旧キーの対応 |
空欄・ゼロ・特別値 | 未確定と確定済みを同じ状態にする | 値が表す意味と移行先の表現 |
日付・日時 | 日付の境界や締め対象が変わる | 業務日、時刻、タイムゾーンの扱い |
金額・数量 | 丸めや単位の違いで計算結果がずれる | 桁数、単位、丸める時点 |
状態区分 | 完了済みの取引を再処理する | 新旧の状態対応と許される遷移 |
マスターと履歴 | 過去の取引内容が現在の情報に置き換わる | 取引時点の値を保存する範囲 |
仮の例として、二つの事業会社が、それぞれ顧客コード「1001」を使っていたとします。顧客コードだけで新しい顧客マスターを作れば、無関係な二社の履歴が一つにまとめられてしまいます。会社コードとの組み合わせで旧データを識別し、新しい顧客IDとの対応表を作れば、元の取引までさかのぼって確認できます。名称が似ている場合も、それだけで同一顧客と決めず、統合の根拠と承認を残します。
「きれいなデータ」の定義を業務側とそろえる
移行はデータを整理する機会ですが、すべてを同時に修正すると、移行による変化と業務上の変更が混ざります。過去の値を保持する対象、根拠に基づいて修正する対象、判断を保留する対象を分けておくと、責任の所在を明確にできます。
たとえば、現在使っていない顧客でも、未完了の取引から参照されていれば単純に除外できません。古い伝票を移行対象から外す場合も、照会、問い合わせ対応、後続処理に必要な範囲と、代替の参照方法を確認します。保存方針は、移行プログラムの都合ではなく、関係部門の判断に基づいて決めることが大切です。
また、欠けた情報をもっともらしい値で埋めると、後から事実と推測を区別できなくなります。補完できる根拠がある場合は、その根拠と処理方法を記録します。判断できないものは例外一覧へ出し、誰がいつまでに決めるかを管理します。「未判定」と分かる状態にしておくほうが、誤った確定値を作ってしまうよりも扱いやすくなります。
変換は、やり直せて説明できる形にする
移行処理には、抽出時点のデータ、変換ルールの版、実行ID、新旧キーの対応、除外・修正の理由をひも付けます。これにより、「この新しい伝票は、どの旧データから、どのルールで作られたのか」を説明できます。
元データの保存領域、変換途中の作業領域、移行先への投入を分けると、問題が起きたときに原因を切り分けやすくなります。再実行時に重複登録しないこと、途中まで成功した処理をどこから再開するか、手修正が次の実行で消えないことも設計対象です。修正内容を変換ルールや管理された補正データへ反映すれば、リハーサルで確認した結果を再現しやすくなります。
本番直前だけ作業者が直接書き換える運用では、その修正が照合済みか分からなくなります。修正後にどの検証を再実行するかまでを、一つの手順として用意します。
照合は、件数・関係・業務結果の三つで考える
移行後の検証は、次のように層を分けると抜けを見つけやすくなります。
対象の網羅性：移行対象、除外対象、エラー、保留の件数が説明できるか。
データの整合性：キーの重複、親のない明細、不正な状態、桁落ちがないか。
業務結果の妥当性：未処理一覧、残高、在庫、請求対象など、業務が判断に使う結果を再現できるか。
テーブルを分割・統合する設計では、新旧のテーブル件数はそのまま一致しません。その場合は「注文と明細」「顧客と取引履歴」のような業務上の単位にそろえて照合します。合計値についても、互いに打ち消し合う二つの誤りが隠れないよう、全体に加えて部門別、状態別、対象期間別に確認します。
移行ツールによる検証も役立ちます。AWS DMSのデータ検証機能は、対応するソースとターゲットの行を比較し、不一致を報告します。ただし、対応するエンドポイントの範囲や制約があり、検証中・保留・対象外といった状態もあります。「不一致が報告されていない」ことと「必要な検証が完了した」ことを分けて確認する必要があります。
こうした機能を使っても、自社の「未請求」「引当可能」「締め済み」の定義まで自動的に確認できるわけではありません。業務上の受け入れ条件は、移行設計の段階で別途定義します。
比較する時点と、合格の責任者を決める
新旧で異なる時点のデータを比べると、正常な追加・更新が不一致に見えます。照合基準となる抽出時点と、そこからの差分をどこまで反映した状態で比較するかを固定します。差分に更新や削除が含まれる場合は、追加件数だけを数えて完了と判断しないよう設計します。
合格基準は、データの重要度に応じて決めます。業務を誤らせる差異は解消を必須とし、表示上の変更などを許容する場合は、理由、影響、承認者を記録します。割合だけで判定すると、件数は少なくても重要な取引の誤りを見逃します。
株式会社Managetechがデータ移行で重視するのは、移行後の数字を業務担当者が説明できる状態です。まずは主要な取引を一つ選び、識別子、状態、履歴の意味と、移行後に確認する業務結果を整理します。その小さな検証を起点に、変換ルールと受け入れ基準を具体化していくことが、確かな移行計画につながります。
コメント