移行件数が一致しても、請求先は正しいか。データ移行の合否を業務の結果から決める

旧システムも新システムも顧客は一万件。移行結果の表には「差分ゼロ」と並ぶ。ところが初回の請求処理で、会社宛ての請求が支店へ送られた。件数は合っていても、顧客と請求先を結ぶ関係が変わっていた。この数字と出来事は、検証の範囲を考えるための仮想例である。

移行確認で問うべきなのは、すべてを完璧に調べる方法より、稼働を認めるために何を証拠とするかだ。データをコピーできたことと、移行後の仕事が正しく動くことは、重なる部分があっても同じではない。

本稿は、件数だけでなく値・関係・重要な業務結果を照合し、不一致の影響と未検証範囲を分けて受け入れを判断する方法を提案する。すべての列へ同じ検査をするのではなく、請求、出荷、権限など、間違った際の結果から必要な確認を選ぶ。

全部入っていることと、正しいことを分ける

英国政府のData Quality Frameworkは、完全性、正確性、一貫性などの品質の側面を区別する。値が埋まっているデータでも、その値が正しいとは限らない。政府データの管理指針であり、移行の合格率や民間企業の許容誤り率を定めるものではない。GOV.UK「The Government Data Quality Framework」

この区別を冒頭の例へ使うと、一万件という数は、必要な行がそろっているかの確認材料にはなる。しかし、異なる顧客を一件落とし、別の顧客を一件重複させても合計は同じになる。件数一致だけで、同じ対象がそろったことまでは言えない。

次に顧客IDが一致しても、請求先IDが正しいとは限らない。請求先まで一致しても、無効になった契約を有効と扱うなら、業務結果は変わる。何段階確認すればよいかは、列の数より、そのデータが何を決めるかで変わる。

データ品質を一つの点数へまとめると、重要度の差が隠れる場合もある。検索に使わない古い補助項目の欠落と、現在の請求金額の誤りを同じ一件として平均すると、処理を止めるべき問題が小さく見えてしまう。

自動検証の成功は、検証対象の範囲で読む

AWS DMSの公式資料は、移行元と移行先のデータを比較する検証機能を説明し、対応するデータベースやキー、データ型などの条件・制約も示している。例えば、主キーまたは一意インデックスが必要という条件がある。製品の仕様説明であり、すべての移行で検証が完了する証拠ではない。AWS「DMS data validation」

この例が示すのは、自動検証を信用しない方がよいということではない。多くの行や値を照合する作業には、機械の助けが有用である。ただし、画面に失敗がないことを読む前に、どの表、列、状態を検証できたのかを確かめたい。

未対応の列、検証待ち、更新中の行などがあれば、それを「一致」と合算しない。検証対象から外れた理由と、別の方法で確かめる担当を記録する。チェックが動かなかった対象を、問題がなかった対象に変えてはいけない。

さらに、移行元が誤っていれば、それを正確にコピーしても誤りは残る。移行の忠実さと、元データを修正する活動を分ける必要がある。移行中に値を直すなら、変更規則と期待結果を明示し、単純な一致検査とは別に検証する。

AWSの資料には、移行元の行が絶えず更新されるなどの理由で比較できない状態も示されている。その場合は一致でも不一致でもなく、比較が完了していない。更新が落ち着く時点で再検証するか、同じ時点の状態を別に取得して照合するかを決め、未検証のまま受入れ対象へ含めない。

ただし、確認のために更新を止める案も無条件には選べない。止めた間に受注を失うなら、別の受付経路や更新の追随を含めた切替方法が必要になる。反対に短時間の停止を合意できるなら、比較時点をそろえる方が判断しやすいこともある。検証方法と業務を続ける方法を別々に決めず、どの取引がどちらのシステムへ記録されるかまで一つの計画にする。

受入れを支える四つの照合

確認計画は、開発側だけでなく、そのデータで仕事をする側と作りたい。本稿では次の四段階を提案する。順に合格すれば無条件に安全という認証ではなく、見落としやすい違いを分ける整理である。

金額の合計も役立つが、それだけでは足りない。仮にA社へ百円多く、B社へ百円少なく請求するなら合計差はゼロである。合計の照合と、対象ごとの値や関係の照合を組み合わせる理由になる。

文字の違いも、見た目だけで判断しない。名称の空白が変わっても表示上の許容範囲かもしれない一方、識別に使うコードの先頭のゼロが失われれば、別の対象と扱われることがある。何の列を何に使うかが、許容する違いを決める。

不一致を、修正待ちと受入れ可能に分ける

不一致の一覧には、原因だけでなく、業務への影響を付ける。自動変換の仕様どおりの差、既知の元データの誤り、移行処理の欠陥、比較時点のずれでは対処が違う。

意図した変換であっても、説明書に書いてあるだけで受け入れない。例えば旧状態の複数区分を新しい一つの区分へまとめる場合、後から必要な判断ができなくならないかを確認する。情報を減らす変換では、元へ戻せるか、元の値を別途保持するかも判断対象になる。

受入れ可能とした項目には、その理由と責任者を残す。担当者が「影響なし」と書くだけでは、次の担当者が同じ判断を検証できない。どの業務で使わず、どの利用には影響しないのかを具体化したい。

同じ未解決一件でも、稼働判断は逆転する

仮に、現行の請求に使わない、過去の営業メモの改行が一件崩れていたとする。原文を別の保管先から参照でき、修正担当と期限が決まっているなら、その項目を条件付きで受け入れる案が考えられる。

一方、現在の契約に対する請求先の関係が一件でも不明なら、件数の少なさだけで受け入れにくい。誤請求や情報の誤送付へつながる可能性があるためだ。本稿なら、関係を修正して再検証するまで、その請求の実行を保留する案を選ぶ。

さらに、不明な一件を他の処理から切り離せるなら、全社のすべてを止める必要があるとは限らない。ただし隔離した対象が集計や出荷へ再び混ざらないことを確認する。区別できないなら、影響範囲を広く取って保留する必要がある。

ここで合否を分けるのは、不一致が一件か百件かだけではない。誰に何が起き、取り戻せるか、対象を隔離できるかである。この条件を移行日になって初めて議論しないよう、受入れ基準を事前に業務側と合意しておく。

最終コピーの後に、確認の空白を作らない

リハーサルが成功しても、その後の更新を取り込む最終処理は別に確認が必要だ。比較した時点が違えば、正しい更新を不一致と見たり、取り込まれていない更新を見逃したりする。

切替計画には、いつの状態を正として比べるか、更新を止めるか追随するか、確認中に発生した取引をどこで受けるかを載せる。照合結果と、検証したデータの版や時点を結び付けることが、やり直す際の手掛かりになる。

稼働後も初回の請求や締め処理などを点検する。通常の日次処理が動いたことだけで、月末の処理まで確認済みとはしない。件数の一致は入口であり、受入れの答えは重要な業務を正しく続けられるかに置く。 未確認と不一致を分け、影響に応じて受入れ、隔離、保留を選ぶことが、移行完了という表示と実際の業務をつなぐ。