DXの計画書を開くと、BIダッシュボードの構築、AIによる需要予測、業務の自動化といった施策が時期とともに並んでいます。ところが、その手前にあるはずの「使えるデータをそろえる」工程が入っていないことがあります。施策として見えにくく、書かなくても計画表は成立してしまうためです。そして実際にBIを作り始めてから、部門ごとに違うコードや空欄の多さに気づき、スケジュールを引き直すことになります。本記事では、データ整備をロードマップのどこに置き、どれだけの期間を見込み、整備が終わったあとに何を続けるのかを扱います。なぜデータ品質がDXの前提になるのかという話はDX推進でデータ品質が重要な理由：フェーズ別リスクと推進前チェックリストで扱っているため、本記事は「計画のどこに置くか」から始めます。
データ品質はDXの「基盤フェーズ」として定義する
DXの進め方に決まった型があるわけではありませんが、計画を整理する方法の一つとして、本記事では「基盤整備→活用・分析→高度化・自動化」の3フェーズに分けて考えます。データ整備は基盤整備フェーズの中心に置くのが基本ですが、対象業務やデータの状態によっては活用・分析と並行して進めることもあります。整備が不十分なまま活用・分析に進むと、集計値が部門間で合わない、分析対象が偏る、予測結果を判断材料として使えないといった形で効果が限られます。「動かない」のではなく「動くけれども信頼して使えない」という現れ方をすることのほうが多く、こちらのほうが気づくのが遅れます。
- フェーズ1（基盤整備：3〜12ヶ月）：データの現状診断→主要マスタの整備→データガバナンス体制の構築→BIデータ基盤の整備
- フェーズ2（活用・分析：6〜18ヶ月）：BIダッシュボードの構築→KPI分析→初期的なAI・機械学習の試用
- フェーズ3（高度化：12〜36ヶ月）：AI需要予測・最適化→自動化・プロセス変革
ここに挙げた期間は計画を立てるときの例であり、標準的な所要期間として公表されているものではありません。実際には、対象データの範囲、システムの数、関係する部門の数、整備に充てられる人員によって大きく変わります。自社の条件で見積もり直してください。
これを時間軸に並べると、計画のどこに空白があるかが見えます。フェーズは順番に進むものの、実際には重なりながら動きます。
図で伝えたい点は2つあります。1つは、データ整備の工程に期間を見積もって計画に書くこと。「BI構築」の前に線を1本引くだけでは、いつ誰が何をするのかが決まりません。もう1つは、整備が終わってもデータ品質の仕事は終わらないことです。フェーズ2以降も入力は続き、組織も変わるため、維持の工程を薄くでも計画に残しておかないと、フェーズ3に入るころに同じ問題が戻ってきます。
DXロードマップへの組み込み方
DX戦略の策定時にデータ品質改善を「当然組み込むべき前提」として提案するための説明ポイントを整理します。
- 後回しにした場合に何が起きるかを示す：「データ品質がなければDXはできない」と言い切るより、BI導入後に集計値の不一致が出た、AIに使うには必要な項目が埋まっていなかった、といった具体的な躓き方を示すほうが伝わります。他社事例を使う場合は、引用できる出典を自分で用意してください
- DXの成果指標にデータ品質KPIを含める：BIの利用率・分析の意思決定への活用率などのDX成果指標とともに、「マスタの重複率○%以下」「必須項目充足率○%以上」というデータ品質KPIをロードマップの成果指標に含めます
- 「基盤整備は投資、活用は回収」として予算を設計する：基盤整備フェーズの費用を「投資」、活用フェーズで生まれる効果（工数削減など）を「回収」として時系列で示すと、費用の性格が説明しやすくなります。ただしこれは説明の枠組みであって、回収を約束するものではありません。回収として挙げる効果は、測り方と前提条件まで添えてください
DX予算へのデータ品質コストの組み込み方
DX予算の申請時に「データ品質整備にかかるコスト」をどう位置づけるかは実務上の課題です。「データを整備するための費用」は成果が見えにくいため、承認されにくい傾向があります。ここではDX予算の中での区分の切り方に絞ります。稟議そのものの書き方や投資対効果の数字の作り方はデータ品質改善の稟議書の書き方：経営層が承認する費用対効果の数字の出し方とデータ品質改善のROI計算：コスト削減・AI精度向上・意思決定ミス回避を数値化する方法で扱っています。
| 予算区分 | 内容 | 提示方法 |
|---|---|---|
| 診断・現状把握 | データ品質スキャン・棚卸し費用 | 後続整備コストの精度向上と無駄な投資の防止効果として説明 |
| 整備・クレンジング | マスタ整備・クレンジング・ルール設計 | BI/AI導入後の手戻りコスト回避として定量化 |
| ツール・自動化 | 品質モニタリングツール・自動検知 | 手動確認工数の削減効果として年間ROIを試算 |
| 体制・教育 | スチュワード育成・研修・ルール定着 | 品質問題の再発防止コストとして説明 |
DX予算におけるデータ品質コストの区分と提示方法（整備は当面のユースケースに必要な範囲から始め、段階的に広げる前提）
データ品質整備の進捗をDX成果として可視化する
DXプロジェクトの中間報告でデータ品質整備の成果をどう見せるか、経営層が「基盤への投資が実っている」と実感できる可視化が重要です。
- 品質スコアの改善グラフ：整備前後の必須項目充足率・重複率・エラー件数を時系列で可視化します。数値が改善していることが視覚的に伝わると、経営層の理解が深まります
- BIの信頼性向上を測定する：BI導入後に「数値の不一致問題の発生件数」「現場からのデータ問題の問い合わせ件数」を追跡し、品質整備によってこれらが減少していることを示します
- 業務効率化の定量化：データ不整合の修正・確認作業に費やしていた工数が品質整備後に削減された量を試算します。「月○時間の確認作業が不要になった」という実績は経営層に伝わりやすい指標です
- AI・分析精度との関係：データ整備の前後で予測モデルの精度やBIの利用状況を比べます。ただし精度が上がる保証はなく、同じ時期にモデルや学習データの構成を変えていれば、どちらの効果か切り分けられません。比較するときは評価指標と評価条件をそろえ、他に何を変えたかを記録しておいてください
ここで混ぜないほうがよいのは、データの状態を測る指標と、業務が楽になったかを測る指標です。前者が改善しても、後者が自動的に良くなるわけではありません。3つの層に分けて並べると、どこまで効いているかが見えます。
| 指標の種類 | 指標の例 | 確認できること |
|---|---|---|
| データの状態 | 必須項目充足率、重複率、コード体系違反の件数 | データが利用の条件を満たしているか |
| 業務への影響 | 数値の不一致に関する問い合わせ件数、照合作業の時間 | 現場の手間が減ったか |
| DXの成果 | レポート作成までの時間、意思決定までの時間 | 業務上の効果が出たか |
混ぜずに分けて見る3つの層
「BIの利用率」「分析が意思決定に使われた割合」も候補になりますが、ログで測れるか、何をもって利用とみなすかを先に決めておかないと、数字が後から動きます。
部門横断でのデータ品質推進体制
DX戦略の中にデータ品質を組み込む際、推進体制の設計が成否を大きく左右します。データ品質は複数部門にまたがる課題であり、IT部門だけでは推進しきれません。データの業務上の意味や、業務ルールに照らしてどの値を正とするかは、原則として業務部門が主体となって判断します。IT部門はその判断をデータ定義・システム上のルール・検査処理に反映する役割です。もっとも、システム間の整合や外部の基準に合わせる必要がある場面では、両者で調整することになります。
- DX推進委員会へのデータ品質アジェンダの組み込み：DXの進捗を管理する会議体に、定期的にデータ品質KPIのレビューを組み込みます。「データ品質が議題になる場」があることで、関係部門が品質に意識を向け続けられます
- 業務部門のDXチームへのデータ品質担当の設置：DXプロジェクトに業務部門から参加するメンバーの中に、データ品質を担当する「データスチュワード」の役割を割り当てます。IT部門に任せきりにしない体制が品質維持の鍵です
- データ品質の「不具合レポート」制度の設置：現場からデータ品質の問題を報告できる仕組みを設け、報告されたデータ問題を「DXの改善活動」として追跡・対応します。問題が「見えない」状態から「見える化」することが最初のステップです
業務部門側の担当者をどう決め、何を任せるかはデータオーナー制度の作り方：業務部門にデータ品質責任を根付かせる実践ガイドで具体的に扱っています。
よくある質問
DX推進の途中でデータ品質の問題が判明した場合、どう対処すべきですか？
既にDX推進が始まった後に品質問題が顕在化した場合、まず現状の品質スキャンで問題の全体像を把握することが先決です。全ての問題を解決してからDXを再開するのではなく、DXのユースケースに影響する範囲から優先的に整備し、並行して残りを進めるアプローチが現実的です。「止めて解決する」より「動かしながら修正する」を基本戦略にします。
データ品質整備にどのくらいの期間が必要ですか？
整備の範囲と深度によって大きく異なり、一律の標準期間はありません。本文のフェーズ1に挙げた3〜12か月は基盤整備全体の幅で、その内訳として、主要マスタ3〜5種のクレンジングと基本的なガバナンス体制の設計だけなら3〜6か月程度を計画上の目安にできます。複数システムとの連携、DWH構築、全社展開まで含めるとさらに長くなります。いずれも実績値ではなく計画を立てるための例なので、自社の要件で見積もってください。最初から完璧を目指さず、DXの当面のユースケースに必要な品質を最初に確保し、段階的に範囲を広げるアプローチをお勧めします。
経営層に「データ整備の工程」を計画に入れる必要性を、どう説明すればよいですか？
整備そのものの必要性を説くより、整備を飛ばした場合に何が起きるかを時間で示すほうが伝わります。「BI構築に6か月を見込んでいても、必要なデータが使える状態になければ構築の途中で止まり、そこから整備を始めることになる」という形です。どれだけ遅れるかは状況によりますが、先にやるか後でやるかの違いであって、やらずに済む工程ではないことを計画表の上で見せてください。あわせて、整備の範囲をDXの当面のユースケースに必要な分だけに絞ると、期間と費用の見積もりが具体的になり議論しやすくなります。
データ品質整備の成果を継続的に追う仕組み
DXロードマップにデータ品質を組み込んだ後も、品質の状態が計画どおりに改善されているかを追う仕組みが必要です。月次を基本としつつ、データの更新頻度や業務上のリスクに応じて頻度を決め、主要な指標（必須項目充足率・重複率・コード体系違反件数）の推移をDXの進捗レポートに含めます。目標値を下回った場合は原因を分析し、整備計画を見直します。「一度整備すれば終わり」ではなく、続けて見ることが前提です。
まとめ
データ整備を計画に入れるときは、3つを決めてください。フェーズ1のどこに置くか、どれだけの期間を見込むか、整備が終わったあとに何を続けるか。このうち3つ目が抜けやすく、フェーズ3に入るころに同じ問題が戻ってくる原因になります。
計画に書く効果は、工程が1つ増えること自体ではありません。工程になって初めて、担当者と期間と完了の条件が決まります。「データを整備してからBIを作る」と口頭で合意していても、計画表に行がなければ誰も着手しません。
なお整備の範囲は、当面のユースケースに必要な分に絞ってください。全社のデータを完璧にしてから進めようとすると、フェーズ1が終わらずDX自体が止まります。DX計画へのデータ整備の組み込みについてはBFT Insightにご相談ください。