データ移行のためのデータ品質可視化— データ品質問題を解決する実務アプローチ

データ移行は「一発で正解を作る作業」ではありません。移行リハーサルを繰り返しながら、問題を減らし、安心できる範囲を少しずつ広げていく活動です。

しかし実際の現場では、

• 本当に品質は上がっているのか
• どこまで確認できていて、どこがまだ危ないのか
• 次に何を優先すべきなのか

が分からなくなりがちです。

その不安を解消するために欠かせないのが、データ品質の可視化です。

本記事では、こうした不安を整理し、

• なぜ可視化が重要なのか
• 何を、どのように可視化すべきなのか

を、移行リハーサルやデータ整備、後続テストなどの実務視点でまとめます。

なお、データ品質の可視化がどうして難しいのかについては、データ品質問題記事をご覧ください。

また、可視化の本質、失敗パターン、見える化の実現方法の全体構造については、可視化の全体像記事をご参照ください。

---

移行データには2種類ある — 機械的に作れるデータと、人の手が必要なデータ

データと言っても、データの準備のされ方によって、データ品質の確認・向上の仕方は変わってきます。そのため、まずは、その2つを分けて考えることが重要です。

機械的に作れるデータとは

ルールが明確で、正解が一意に決まるデータです。

【例】

• コード変換（A,B,C… → 01,02,03…）
• 日付・金額フォーマット変換（01-Dec-26 → 20261201）
• ルールに基づく固定値設定

【特徴】

• 作成も確認もツール化可能
• 人の判断が不要

一度正しいことが確認できれば、次回以降は差分確認だけで済む。つまり、このタイプのデータは最大限機械化し、安定させることが重要になります。

人の手が必要なデータとは

業務判断が必要で、正解が一意に決まらないデータです。

【例】

• 名寄せ・統廃合
• 新項目の値決定
• 業務妥当性の判断

無理な機械化は、品質劣化の原因になってしまいます。こちらは、人の関与を前提とした管理と可視化が重要になります。

データ品質の確認方法は、データ準備の方法とセットで考える

「どう作ったか」と「どう確認するか」は切り離せません。作り方に応じて、適切な確認方法を選ぶ必要があります。

機械的に作れるものは、機械的に確認する

【代表的な確認方法】

• ルールチェック
• 件数チェック
• 差分比較

もちろん、人間の目によるサンプルチェックは行いますが、機械的に作れるものは、人間を極力介さないことが品質と効率の両立につながります。

人間はミスや勘違いをします。そのため、なるべく人間の関与を小さくすることが品質向上の秘訣です。

人の手が入るものは、人の目で確認する

人間による作業や判断が入ったものは、機械的に一律にチェックすることは困難です。

そのため、人の目で確認することが必要になります。

【確認時に明確にすべきこと】

• 誰が確認したか
• どこまで確認したか
• 何をもってOKとしたか

ここを曖昧にすると、「確認したつもり」のまま問題が残り続けます。

また、先ほどお話したように、人間の作業にはばらつきが生じやすい面があります。そのため、人間の関与を小さくすることが大事です。確認範囲を明確にして、安心できる範囲を広げていくこと＝人間が関与しなければならない残量を減らしていくことが重要です。

つまり、残量を管理していくことが、データ品質管理の重要な要諦になります。

2月03日確認時点	確認済 0%	未確認 100%
2月17日確認時点	確認済 30%	未確認 70%
3月03日確認時点	確認済 60%	未確認 40%

※確認されたデータ範囲が広がっていき、未確認データ数が少なくなってきている

---

データ移行成功の要諦① — 最大限機械化していくこと —

繰り返しですが、人間はミスや勘違いをします。 機械化は効率化のためだけではなく、データ品質を安定させるための重要要素です。

機械化できる範囲が広がることは、データ品質の向上にもなりますし、作業スピードの向上にも貢献します。そして、何より安心できる範囲を広げることにつながります。

データ移行成功の要諦② — 安心できる範囲を積み重ねていくこと —

可視化の目的は「問題探し」に留まりません。より重要なのは、「安心できる範囲」と「まだ安心できない範囲」を見える化することです。安心できる範囲を少しずつ広げていくことで、移行はコントロール可能な活動になります。

問題が無かったレコード・項目が、どれだけ積み上がったか

「今どうか」も重要ですが、より重要なのは「前回から、安心できる範囲は広がったかどうか」です。安心できる範囲が広がっていれば、移行リハーサルで成果が得られている証拠になります。逆に、広がっていなければ、何か問題があるということが分かります。

大切なのは、「取り組み内容は正しく機能して、想定通り前進/改善しているか」ということなのです。

機械的につぶせる問題は、意図通りにつぶれているか

機械的な問題は、減っていくことが前提です。減っていなければ、設計やロジックの見直しが必要です。

• 前回NGだったものが解消されているか
• 別の形で再発していないか

機械的に対応できるものは、比較的簡単に安心範囲を広げられるところです。データ品質向上は大変難易度の高いタスクですので、簡単に効果ができるところは、取りこぼしなく進めていきたいです。

人の手・目が必要な作業に、再現性のある手順があるか

【チェックリスト】

• 手順書がある
• 判断基準が明文化されている
• 担当者が変わっても対応できる

ここが整って初めて、人手作業も“管理できている”と言えます。

特に、データ整備活動は属人的になりがちです。属人的になると、人によって作業精度もスピードもまちまちになってしまいます。なるべく属人を排すことが肝になります。

そして、移行リハーサルや後続のテストなどで、データ品質に関する問題が報告された場合は、その手順を更新していくことが必要です。そのようにして、人間の作業の精度を上げていくことが重要です。

人間は間違いをすることがありますですので、この地道な手順の改善活動が、非常に大切になってきます。

---

データ移行成功の要諦③ — 幅広い視点でデータを検証すること —

データ品質は、移行リハーサルだけでは確認し切れません。データ移行では、外形的なデータ様式が合っていれば、正常完了できてしまいます。

しかし、実際には、データのビジネス的な内容が間違っていたということも頻繁に起きます。

もちろん、データ整備（データクレンジング）や移行リハーサルの過程で、業務ユーザの目によるチェックは行いますが、見逃してしまう可能性があります。

そのため、後続のテストで更にデータ品質を確認することが有用になります。

システムテスト・UATで移行データを使った検証を行う

後続のテストで検知されるデータ品質問題には色々あります。例えば、要件定義や設計中にデータ定義が二転三転したケース。移行チームが古いバージョンのデータ定義で移行作業をしている場合、移行チームだけでは、問題に気付くことはできません。

こういった場合、後続のシステム処理を行って、その結果を見なければ、問題に気付くことは困難です。

検知した問題を管理し、収束させていく

データ移行は品質改善の取組みそのものです。移行元データと本番移行データとの間にはギャップがありますが、そのギャップを埋めていく活動です。

そして、問題を潰し込むだけでは足りません。同じ問題が再発しないように、手順化・ツール化しておくことが重要です。

同じ問題が再発しないと確信できれば、安心できる範囲が広げることができ、自信をもって本番移行に取り組めます。

---

データ移行成功の要諦④ — データオーナを明確にすること —

データ移行において、データオーナを明確にすることは極めて重要です。

データ品質は、桁数や表示形式など機械的に確認できるものだけでなく、名称や金額、取引区分など、ビジネスを理解した人が確認しなければならないものも多いからです。

データオーナは、項目単位で決めなければならないこともある

データオーナは多くの場合、データの種類ごとに決められますが、ときには項目単位で決めなければいけない場合もあります。

得意先マスタの例

品目マスタの例

重要なマスタほど、部門をまたいだ確認が必要になることが多いです。そのため、誰がオーナになるのか、ボールの投げ合いになり、決まらないプロジェクトも多く見かけます。

オーナが決まらなければ、データ整備やデータ確認の作業は進みません。判断先が明確になることで、問題は滞留しなくなります。

---

データ移行成功の要諦⑤ — 人の手が必要な作業の進捗を丁寧に追うこと —

繰り返しになりますが、データ整備・確認には人の手が欠かせないところがあります。実際の現場ビジネスを理解している人達に担ってもらう必要があるため、現業との専任でデータ整備・確認をしてもらうことが多いです。

そのため、データ整備・確認は時間がかかるのが一般的です。

長い活動だからこそ、可視化が重要

時間がかかる作業では、現業が忙しいとついつい優先順位が落とされ、作業が停滞することがあります。また、データ整備は、数か月に渡って行われることが多いですが、その間の進捗が見えないと大変不安です。

そのため、数か月を細かく区切って、進捗を確認することが有用です。

例えば、以下のようなデータ整備タスクがあったとします。

• データ整備内容は、取引先区分の付与
• 付与対象となる取引先は、2,000件
• データが必要となるのは、4か月後

締切は4か月後ですが、4か月後まで何もフォローしないといったことはしません。マイルストンを細かく切って、進捗を追って行きます。

細かく刻むことで、4か月後まで進捗が見えないということを防げます。また、何か問題があった場合の検知も早く出来ますので、対策も早く打つことができます。

---

データ移行成功のための可視化ポイント

ここからは、これまでお話してきた考え方を、「可視化」という観点で整理しなおします。

可視化とは、単に一覧表やグラフを作ることではありません。「状態を正しく理解し、適切な対策を打てるようにする」ことが目的です。

可視化ポイント① 安心できる箇所・課題がある箇所・未検証な箇所を分けて見る

移行状況を一枚で示す際、最も避けたいのは「全部が同じ色・同じ扱い」になってしまうことです。

• すでに十分確認できているもの
• 問題はあるが、原因と対応方針が見えているもの
• まだ手が付けられていない、または確認が浅いもの

これらを明確に区別することで、関係者の認識が一気に揃います。

可視化ポイント② 安心できる箇所が積み上がっていることを確認する

可視化は“断面”だけではなく“時系列”で見ることが重要です。

• 前回は課題がある箇所だったが、今回は安心できる箇所に移った
• 未検証な箇所だった範囲が、課題がある箇所として認識できた

こうした変化が見えると、プロジェクトが前進していることを実感できます。現在値だけでなく、「前回、前々回、前々々回...との差分」を必ず示すことが大事です。

可視化ポイント③ 機械的につぶせる問題が確実に解消されていくようにする

件数不一致や変換ミスなど、機械的に検知・修正できる問題は、回を重ねるごとに減っていくのが前提です。

• 同じ原因の問題が残り続けていないか
• 別の形で再発していないか

を確認できるようにします。

機械的な問題が減らない場合、可視化以前に設計やロジックの見直しが必要です。

可視化ポイント④ 人の手が必要な作業のステータスを根気強く管理する

人が判断する作業は、放っておくとブラックボックス化しやすい領域です。

例えば、データ整備については、以下の点が重要になります。

作業量	何パーセント完了したのか把握するためには、まず母数を管理することが最重要
進捗状況	データ整備は長期間になりがち。最終締め切りまで待つのではなく、細かく期間を刻んで管理
管理粒度	取引先マスタといっても、整備すべき項目は様々。細かすぎるのは良くないが、ある程度の細かさで管理することが、問題を特定することに役立つ

上記のようなことが一目で分かる形で可視化することが大切で、多くの場合スプレッドシード形式で管理していきます。

可視化ポイント⑤ すべての作業や問題にデータオーナを紐づける

特に、人間の手・目が必要な作業や問題は、データオーナの関与が欠かせません。

問題が発生した際、

• 「誰に聞けばいいのか分からない」
• 「判断待ちで止まっている」

という状態は、移行全体の停滞を招きます。

そもそも、データオーナが明確でなければ、「データ整備やデータ確認の作業自体が進まない」と言ったことも置きます。特にデータ整備は人間が行う作業ですから、データオーナが決まっていない＝責任者が決まっていないと、滞留しがちです。

可視化ポイント⑥ 後続テストで検証の網羅性を高める

移行データの問題は、データ単体のチェックだけでは見つからないことがあります。

実際に、業務プロセスのなかで使って行くことで、様々なシステム処理に必要なデータが正しく揃っていることが確認できます。

• システムテスト
• UAT

しかし、システムテストもUATも、決められたデータセットをシナリオベース確認することが多いですので、普通にテストをするだけでは、データ品質を網羅的に確認することができません。

プロジェクトによっては、システム品質の確認を重視して、移行リハーサルのデータを利用せずに、テスト用のデータセットを作る場合もあります。そのため、データ品質を確認することの重要性を認識して、テストを企画する姿勢が欠かせません。

可視化ポイント⑦ 問題防止の仕組みを積み上げていく

可視化の最終ゴールは、「問題が減っている」ことだけではありません。

• なぜ起きたのか
• 次はどう防ぐのか

が仕組みとして蓄積されている状態です。それは、データ品質に関しても同じです。

---

可視化とは、進捗報告のためではありません。判断を早め、安心できる範囲を広げるために行うものです。この視点を持つことで、データ移行は属人的な作業ではなく、再現性を持って進められるようになり、積み上げ可能なプロジェクトになります。

なお、可視化の本質、失敗パターン、見える化の実現方法の全体構造については、可視化の全体像記事で整理しています。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

Related Insights

---