データはあるのに分析できない｜データ品質の落とし穴と回避策

「データは溜まっている、しかし分析できない」が起きる理由

データ活用プロジェクトで最も頻繁に発生する事故が、「データは大量に蓄積されているはずなのに、いざ分析しようとすると使えない」というものです。経営層が「うちにはデータがある」と思っていても、現場で使える形になっていないことが多々あります。

データ品質は、活用しようと思って初めて気づくものです。蓄積している段階では「何かに使うかも」という曖昧な目的で運用されているため、入力ルールの徹底や監視がされておらず、いざ分析しようとすると使い物にならないという結果になります。本記事では、データ品質が劣化する典型パターンと、分析プロジェクト開始前に必ずやるべき品質確認の手順を整理します。

データ品質が劣化する4つの典型パターン

1. 形だけ入力されたデータ

システムの必須項目になっているため値は入力されているが、中身が意味をなしていないパターン。「業種」フィールドにすべて「その他」が入っていたり、「顧客の所属部署」に全件「営業部」が入っていたり、というケースです。

現場担当者にとっては「とりあえず通す」ためのダミー入力ですが、分析する側は「この項目で集計しても意味がない」と後から気づきます。

2. 入力ルールが時期によって変わっている

同じフィールドでも、時期によって入力ルールが変わっているケース。「商品カテゴリ」が3年前は「家電」と入っていたが、2年前から「家電/AV機器」に変わり、1年前から「AV-Home」というコード値になった、といったパターンです。時系列で集計しようとすると、同じカテゴリが分裂して見えてしまいます。

3. 連携元システムの仕様変更で壊れている

外部システムからデータを取り込んでいる場合、連携元の仕様変更でフィールド構造やコード値が変わっていることがあります。連携の継続性は保たれていても、中身の意味が変わっており、分析結果が時系列で歪みます。

4. 重複・名寄せ漏れが大量にある

同じ顧客が複数の顧客IDで登録されているパターン。マイページとECサイトで別IDになっている、メールアドレスの大文字小文字違いで別人扱い、社名表記の揺れ（「株式会社」「(株)」「カブシキガイシャ」）で別法人扱い、などが典型です。

データ品質劣化の発見が遅れる理由

データ品質の問題は、分析プロジェクトに入って初めて気づくケースが大半です。蓄積運用の段階では次のような状況になっており、品質劣化が見えません。

• 「将来何かに使うかも」という曖昧な目的で取得している
• 入力する現場担当者の負担を考慮し、ルールを厳しくしていない
• データを直接見るのは情シス担当者で、業務的な意味の整合性をチェックしない
• 連携元システムの仕様変更が、データの意味の変更として捕捉されない

分析しようとして初めて「このデータは使えない」と判明し、新しくデータを取り直す運用変更を始める。しかし運用が定着するまでに月単位の時間がかかり、プロジェクト全体が大きく遅れる。これがデータ活用プロジェクトの典型的な失敗フローです。

後から取り直すリカバリーが極めて困難な理由

データ品質の問題は、後から気づいてもリカバリーが極めて困難です。理由は次の通りです。

• 過去データは取り直せない：すでに発生してしまった事象のデータは、後から品質を改善できない
• 運用変更には時間がかかる：現場の入力ルールを変えても、定着までに数ヶ月かかる
• 新旧データの接続が難しい：ルールが変わった前後でデータの意味が変わるため、時系列分析が分断される
• プロジェクト全体のスコープが膨らむ：分析プロジェクトが「データ取り直しプロジェクト」に化けると、関係者の合意が取り直しになる

こうなると、当初予定の数倍の期間と費用が必要になります。最悪の場合、プロジェクト自体が中断されることもあります。

分析プロジェクト開始前のデータ品質確認手順

ステップ1：分析対象のデータをサンプリングする

分析する予定のテーブルから、ランダムに数百行を抜き出します。テーブル全体の何百万行を見る必要はなく、サンプルで十分です。サンプリングは時期の偏りを避けるため、過去1年から均等に抽出するのが望ましいです。

ステップ2：欠損率を確認する

各フィールドで、空・NULL・無効値の割合を見ます。30%以上が欠損しているフィールドは、分析の主軸には使えないと考えるべきです。10〜30%欠損のフィールドは「使えるが補完が必要」、10%未満なら「使える」と判断します。

ステップ3：意味的な整合性を確認する

欠損率が低くても、入力されている値が意味をなしているかを確認します。サンプル100件程度を目視で見れば、形だけの入力か実質的な入力かは見分けがつきます。「業種」項目で「その他」が80%なら、現場の入力姿勢の問題があります。

ステップ4：時系列の一貫性を確認する

分析期間（過去1〜3年）にわたって、同じフィールドが同じ意味で入力されているかを確認します。年別にカテゴリ別の件数を集計するだけでも、ルール変更の有無が見えてきます。途中で激しく分布が変わるカテゴリは、入力ルールが変わった可能性が高いと判断します。

ステップ5：重複・名寄せ状況を確認する

顧客データなどキー情報がある場合、重複の有無を簡易チェックします。メールアドレスの大文字小文字統一、電話番号のハイフン有無、社名の表記揺れなどを集計するだけでも、名寄せの必要性が見えます。

データ取得時に品質を担保する設計

すでに蓄積されたデータの品質を後から改善するのは困難ですが、これから取得するデータの品質は設計で担保できます。

• 取得目的を明確にする：「将来何かに使う」ではなく「この課題のためにこの形式で」と具体化する
• 必須項目を最小限に絞る：必須項目が多いほど現場の負荷が増え、ダミー入力が増える
• 入力時のバリデーションを設ける：明らかに無効な値が入らないよう、システム側で防御する
• 定期的に品質モニタリングを回す：月次・四半期で欠損率や分布を見て、劣化を早期検知する
• 連携元の仕様変更を捕捉する仕組み：外部システムからの連携は、仕様変更時に検知する仕組みを入れる

始める前のチェックリスト

• 分析対象のデータからサンプリングして欠損率を確認したか
• 主要フィールドの値が、形だけでなく意味のある内容になっているか目視確認したか
• 分析期間中、入力ルールが一貫していることを時系列の分布で確認したか
• 顧客データなどキー情報の重複・名寄れ漏れを簡易集計したか
• 外部システムからの連携データについて、過去の仕様変更履歴を確認したか
• 新たに取得するデータについて、品質モニタリングの仕組みを設計に含めたか

よくある失敗例と回避策

失敗例1：分析開始後に「中身が空」と判明し、プロジェクト中断

外部パートナーに分析を依頼し、データを渡したところ、「このデータは形だけで中身がない」と後から判明したケース。分析プロジェクトが事実上停止し、新規データ取得のための運用設計から始め直しになる。

回避策は、分析プロジェクトを始める前に、必ず品質確認のステップを契約に含めること。「データを渡したら分析開始」ではなく「データ品質を確認してから本分析を開始」のフェーズ分けが重要です。

失敗例2：データクレンジングに想定の3倍の工数がかかった

分析準備として始めたデータクレンジングが、表記揺れ・欠損・重複の対処で想定の3倍の工数になり、本来の分析に入る前に予算を使い切ってしまうケース。

回避策は、見積もり段階でデータ品質確認を必ず実施し、クレンジングの工数を現実的に見積もること。「とりあえず受けて、進めながら考える」のではなく、初動でリスクを定量化します。

FAQ

Q. データ品質確認はどれくらいの工数で済みますか

A. 主要なテーブル数本を対象とした初期確認なら、数人日〜数週間で済みます。「サンプル数百行」「欠損率」「分布」「重複」の確認はSQLが書ける担当者なら短時間で実施できます。

Q. データ品質が悪すぎる場合、プロジェクトを中止すべきですか

A. 中止ではなく、スコープを絞る判断が現実的です。「全社統合分析」を諦めて「特定部門の絞った分析」に変更する、「全顧客分析」を「主要顧客に絞った分析」に変更するなど、品質が確保できる範囲に絞れば成果は出せます。

Q. データ品質を継続的に維持するにはどんな仕組みが必要ですか

A. 月次でデータ品質ダッシュボードを見る運用、入力時のバリデーション、外部連携の仕様変更検知、現場担当者への定期的な入力ルール周知、これらを組み合わせます。専任者を置く必要はないですが、品質劣化を捕捉する仕組みは継続的に必要です。

関連記事

• CDP導入で失敗する5パターンと回避策｜「箱は作ったが使われない」を防ぐ
• 中小企業こそデータドリブン経営に切り替えるべき理由｜クラウド時代の現実解
• 生成AI時代の経営判断｜技術的障壁が下がった先で重要になる「問いを立てる力」