Topic 12: データ品質 — CDMP学習ガイド

データ品質の6次元（最重要）

📋

Completeness

完全性

必要な値が揃っているか

必須項目のNULL率

🎯

Accuracy

正確性

現実世界と一致しているか

住所が実在するか

🔗

Consistency

一貫性

複数ソース間で矛盾がないか

同一顧客IDが異なる名前を持つ

⏰

Timeliness

適時性

必要なタイミングで利用可能か

レポートが当日中に更新されるか

✅

Validity

妥当性

定義されたルール・形式に適合するか

日付形式がYYYY-MM-DDか

1️⃣

Uniqueness

一意性

重複がないか

同一顧客が複数レコードに存在しないか

⚠ Accuracy vs Validity の区別（紛らわしい！）

Accuracy（正確性）

現実世界の実態と一致しているか
例: 住所「東京都千代田区1-1-1」が実際に存在するか（内容的正しさ）

Validity（妥当性）

定義されたルール・形式に適合するか
例: 日付フィールドが「2024-01-01」形式で入っているか（形式的正しさ）

TDQMサイクル（Total Data Quality Management）

フェーズ	内容	手法
Define	データ品質要件の定義（顧客ニーズから）	CDE特定・SLA設定
Measure	現状の品質を測定（プロファイリング）	NULL率・重複率・ルール違反率の計測
Analyze	問題の根本原因分析	5 Whys・Fishbone Diagram
Improve	改善策の実施（Prevention優先）	バリデーション強化・プロセス改善
Control	改善後の維持・監視（継続モニタリング）	自動チェック・ダッシュボード

コストの法則 1:10:100（最重要）

データ入力時に修正

Prevention（予防）— 最もコスト効率が良い

開発・テスト段階で修正

Detection（検出）— 入力時の10倍のコスト

100

本番稼働後に修正

Correction（修正）— 入力時の100倍のコスト

4つのアプローチと優先順位

Prevention（予防） ← 最もコスト効率が良い。入力段階でのバリデーション
Detection（検出） — 品質問題の発見・測定
Correction（修正） — 問題データの修正
Root Cause Elimination — 問題の根本原因を除去

IBM研究の推計:
悪いデータ品質による損失は米国だけで年間3.1兆ドル。

データプロファイリング（Data Profiling）— 4種類

-- カラムプロファイリングの例
SELECT
  COUNT(*)                               AS total_rows,
  COUNT(customer_id)                     AS non_null_count,
  COUNT(*) - COUNT(customer_id)          AS null_count,
  COUNT(DISTINCT customer_id)            AS distinct_count,
  COUNT(*) - COUNT(DISTINCT customer_id) AS duplicate_count,
  MIN(customer_id)                       AS min_value,
  MAX(customer_id)                       AS max_value
FROM dim_customer;

データ品質ツールのコード例

Great Expectations でのDQルール定義

# Great Expectations でのDQルール定義例
expect_column_values_to_not_be_null("customer_id")
expect_column_values_to_be_between("age", 0, 120)
expect_column_values_to_match_regex(
    "email", r"^[^@]+@[^@]+\.[^@]+$")
expect_column_pair_values_to_be_greater_than(
    "end_date", "start_date")
expect_column_values_to_be_in_set(
    "status", ["ACTIVE", "INACTIVE", "SUSPENDED"])

dbt test でのDQチェック

# schema.yml に記述
models:
  - name: dim_customer
    columns:
      - name: customer_id
        tests:
          - not_null
          - unique
      - name: email
        tests:
          - not_null
          - dbt_expectations.expect_column_values_to_match_regex:
              regex: "^[^@]+@[^@]+$"

6次元（必須暗記）

次元（英語）	日本語	一言説明	例
Completeness	完全性	必要な値が揃っている	必須項目のNULL率がゼロ
Accuracy	正確性	現実・実態と一致している	住所が実在する
Consistency	一貫性	複数ソース間で矛盾ない	同一顧客が異なる名前を持たない
Timeliness	適時性	必要な時に利用可能	レポートが当日中に更新される
Validity	妥当性	ルール・形式に適合	日付がYYYY-MM-DD形式
Uniqueness	一意性	重複がない	同一顧客レコードが1つだけ

コストの法則と4アプローチ

1:10:100 の法則

入力時修正:開発時修正:本番後修正 = 1:10:100
→ 最もコスト効率が良いのは Prevention（予防）

アプローチ	内容
Prevention	入力段階でのバリデーション（最優先）
Detection	品質問題の発見・測定
Correction	問題データの修正
Root Cause Elimination	根本原因を除去

試験直前チェックポイント

⚠ 絶対に覚えること

6次元の英語・日本語・説明を全て覚える
Accuracy（現実との一致）vs Validity（ルールへの適合）の区別
Data Profiling = データの特性・品質を分析するプロセス
最もコスト効率が良い対策 = Prevention（予防）
1:10:100 の法則
Data Cleansing の手法（標準化・Deduplication・Enrichment）
TDQMサイクル = Define → Measure → Analyze → Improve → Control
品質責任: Steward（ルール定義）vs Engineer（実装）

データクレンジングの手法

手法	内容	例
標準化（Standardization）	形式を統一	住所・電話番号の表記を統一
重複排除（Deduplication）	重複レコードの統合・削除	同一顧客の複数レコードを1つに統合
拡充（Enrichment）	外部データで欠損値を補完	郵便番号DBで住所を補完
変換（Transformation）	コード変換・単位変換	「M」→「男性」、米ドル→円
削除（Removal）	修正不能なレコードの除去	廃業企業レコードを「Inactive」に

練習問題 — データ品質（11問）

スコア: 0 / 11

Case 1: 製造業のサプライヤーマスター品質改善

背景

自動車部品メーカー（サプライヤー数：約4,200社）。ERP刷新プロジェクト中にデータ移行前の品質調査を実施したところ深刻な問題が発覚。

データプロファイリング結果

品質次元	項目	結果	評価
完全性	supplier_name	99.8%	OK
完全性	tax_id（インボイス必須）	71.3%	問題
完全性	contact_email	43.2%	問題
一意性	重複サプライヤー	312件（7.4%）	問題
妥当性	tax_id 形式不正	8.3%	要改善
正確性	廃業済み企業	推定89社（2.1%）	要改善

根本原因分析（5 Whys）

問題: サプライヤー名の表記揺れが312件ある
Why1: 入力者ごとに表記を決めていた
Why2: 入力時のバリデーション（候補表示・重複チェック）がなかった
Why3: ERP導入時に品質管理機能を省いた（コスト削減）
Why4: データ品質の問題がビジネスコストとして可視化されていなかった
Why5: ガバナンス不在 → データ品質に「誰も責任を持たない」状態

根本原因: Data Steward と入力標準（Naming Standard）が存在しなかった

修正戦略（Prevention vs Cure）

短期（Cure）: 既存データの修正

自動名寄せ：ファジーマッチングで重複候補抽出 → 人手確認
外部データエンリッチメント：国税庁の法人番号APIで補完
廃業企業：ステータスを「Inactive」に更新（削除はしない）

長期（Prevention）: プロセス改善

ERP入力時の重複チェック（新規登録時に類似企業を表示）
tax_id のバリデーション（13桁・数字のみを強制）
サプライヤー情報のData Steward任命
四半期ごとの自動プロファイリングレポート

Case 2: DQ SLAの設計と運用（金融サービス企業）

背景

CRO（最高リスク責任者）が「リスクレポートのデータを信頼できない」と主張。月次リスクレポートで昨年4回、データ問題による修正再送が発生。

各CDEへのSLA設定

データ要素	DQ次元	SLA目標	測定方法	測定頻度
exposure_amount	正確性	99.5%以上	勘定系との突合	日次
counterparty_id	完全性	100%	NULL件数チェック	日次
trade_date	妥当性	100%	営業日カレンダーチェック	日次
product_code	一貫性	99.9%以上	参照データとの整合チェック	日次
月次集計値	適時性	月末翌3営業日	確定日時の記録	月次

エスカレーションルール

SLAレベル	対応
95〜99.5%	Data Steward が48時間以内に対処
90〜95%	DGO へエスカレート + 影響を受けるレポートへの注記
90%未満	CDO へエスカレート + レポートの一時停止を検討

Case 3: データ品質ルールの種類（Specialist試験頻出）

ルールタイプ	説明	例
Completeness Rule	必須項目のNULLチェック	`customer_name IS NOT NULL`
Domain Rule	許可値の範囲チェック	`status IN ('ACTIVE','INACTIVE')`
Format Rule	形式パターンチェック	`email LIKE '%@%.%'`
Range Rule	数値範囲チェック	`age BETWEEN 0 AND 120`
Uniqueness Rule	重複チェック	`COUNT(DISTINCT id) = COUNT(id)`
Referential Integrity Rule	外部参照チェック	`product_id EXISTS IN products`
Cross-field Rule	フィールド間の整合性	`end_date >= start_date`
Temporal Rule	時系列の整合性	`updated_at >= created_at`

品質検証技術の選択

技術	使用場面
Rule-based Validation	形式・範囲・必須チェック（実装が容易）
Statistical Process Control（SPC）	時系列でのデータ品質トレンド監視（製造業由来）
Anomaly Detection	機械学習による外れ値・異常値の自動検出
Reference Data Validation	参照データとの突合（コード値の有効性確認）
Cross-System Reconciliation	複数システム間の値の整合性確認

Case 4: DQプログラムの実施順序（Specialist試験で問われる）

⚠ よくある失敗パターン

多くの組織が「Step4（測定）→ Step7（修正）」とショートカットするが、Step6（根本原因分析）をスキップすると同じ問題が再発する。

DQプログラムの構成要素

People（組織）

CDO / DGO
Data Quality Manager
Data Quality Analyst
Data Steward（ドメイン別）
Data Engineer（実装）

Process（プロセス）

DQ要件定義
データプロファイリング
DQルール設定
継続モニタリング
問題のトリアージ・修正
根本原因分析・予防策
DQスコアカードの報告

Technology（ツール）

プロファイリング

Great Expectations, dbt test

カタログ統合

Collibra DQ, IBM Watson

BI/レポート統合

DQスコアをダッシュボードに

データ品質 (Data Quality)

カラム分析

構造分析

関係分析

ルール分析

練習問題 — データ品質（11問）