データ品質 (Data Quality)
DAMA-DMBOK 2nd Edition — Chapter 13: Data Quality
出題割合: 11%（約11問）— 最重要トピック
1. データ品質とは
定義: データが意図された目的に対して適切である度合い（Fitness for Purpose）。
"Data quality management is the planning, implementation, and control of activities that apply quality management techniques to data, to assure it is fit for consumption."
2. データ品質の6次元（最重要）
DAMA-DMBOK が定義する主要な品質次元：
| 次元 | 英語 | 説明 | 例 |
|---|---|---|---|
| 完全性 | Completeness | 必要な値が揃っているか | 必須項目のNULL率 |
| 正確性 | Accuracy | 現実世界と一致しているか | 住所が実在するか |
| 一貫性 | Consistency | 複数ソース間で矛盾がないか | 同じ顧客IDが異なる名前を持つ |
| 適時性 | Timeliness | データが必要なタイミングで利用可能か | レポートが当日中に更新されるか |
| 妥当性 | Validity | 定義されたルール・形式に適合するか | 日付形式がYYYY-MM-DDか |
| 一意性 | Uniqueness | 重複がないか | 同一顧客のレコードが複数存在しないか |
※他にも Integrity（整合性）、Precision（精度）、Reasonableness（合理性） 等が挙げられることがある
3. データ品質問題の根本原因
| 根本原因 | 例 |
|---|---|
| データ入力時のエラー | タイポ、誤入力 |
| データ定義の不明確さ | 「顧客」の定義が部門ごとに異なる |
| システム間連携の問題 | 形式変換時のデータ損失 |
| 時間経過による陳腐化 | 引越し後も旧住所が残る |
| 重複データ | 同一人物が複数登録 |
| 設計上の問題 | 必須制約なし、バリデーションなし |
4. データ品質管理の活動
4.1 データプロファイリング（Data Profiling）
既存データの特性・品質を分析・評価するプロセス。
分析対象：
- カラム分析: NULL率・ユニーク率・値の分布
- 構造分析: データ型・長さ・形式の適合性
- 関係分析: 外部キー整合性・参照整合性
- ルール分析: ビジネスルールへの適合率
プロファイリング → 問題の発見 → 根本原因分析 → 修正 → 再プロファイリング
4.2 データ品質ルールの定義
- ビジネスルールをデータ検証ルールとして明文化
- 例: 「メールアドレスは@を含む」「年齢は0〜150の範囲」
4.3 データ品質の測定・監視
- KPIダッシュボード
- 品質スコアの定期レポート
- アラート・エスカレーション機能
4.4 データクレンジング（Data Cleansing）
品質問題のあるデータを修正・標準化するプロセス。
| 手法 | 内容 |
|---|---|
| 標準化 | 住所・電話番号・氏名の統一形式変換 |
| 重複排除（Deduplication） | 同一エンティティの統合 |
| 変換（Transformation） | コード変換・単位変換 |
| 拡充（Enrichment） | 外部データで欠損値を補完 |
| 削除 | 修正不能なレコードの除去 |
4.5 マスターデータとの照合
- MDM との連携でデータの一貫性を確保
- ゴールデンレコードへの名寄せ
5. データ品質の組織・ガバナンス
データ品質の責任
- Data Steward: ビジネスルール・品質基準の定義
- Data Quality Analyst: プロファイリング・測定・レポート
- Data Engineer: 品質チェックの自動化・ETLへの組み込み
データ品質の「4つのアプローチ」
| アプローチ | 説明 |
|---|---|
| Prevention | 入力段階でのバリデーション（予防） |
| Detection | 品質問題の発見・測定 |
| Correction | 問題データの修正 |
| Root Cause Elimination | 問題の根本原因を除去 |
最も効果的・コスト効率が良いのは Prevention（予防）
6. データ品質の指標（Metrics）
| 指標 | 計算方法 |
|---|---|
| 完全性率 | 値が存在するレコード数 / 全レコード数 |
| 正確性率 | 正確なレコード数 / 全レコード数 |
| 重複率 | 重複レコード数 / 全レコード数 |
| ルール違反率 | ルール違反レコード数 / 全レコード数 |
| データ品質スコア | 各次元の加重平均（組織ごとに定義） |
7. データ品質ツール
| ツール分類 | 例 |
|---|---|
| プロファイリング | Ataccama, Talend DQ, Informatica DQ |
| マスターデータ管理 | Stibo MDM, SAP MDM, Reltio |
| データカタログ（品質統合） | Collibra, Alation |
| ETLツール（検証機能） | Informatica, DataStage |
8. データ品質のビジネス価値
「1の法則」：
- データ入力時に修正 → コスト1
- 開発・テスト段階で修正 → コスト10
- 本番稼働後に修正 → コスト100
悪いデータ品質のコスト（IBM研究）:
米国だけで年間3.1兆ドルの損失
試験ポイント
- 6次元（Completeness / Accuracy / Consistency / Timeliness / Validity / Uniqueness）
- Data Profiling = データの特性・品質を分析するプロセス
- 最もコスト効率が良い対策 = Prevention（予防）
- Data Cleansing の手法（標準化・重複排除・変換等）
- 品質責任: Steward（ルール定義）vs Engineer（実装）
- 品質問題の根本原因（設計・入力・連携・時間経過）
Specialist試験 深掘り
Total Data Quality Management（TDQM）フレームワーク
MITが提唱したDQ管理フレームワーク。製造業のTQM（全社品質管理）をデータに適用。
Define → データ品質要件の定義（顧客ニーズから）
Measure → 現状の品質を測定（プロファイリング）
Analyze → 問題の根本原因分析
Improve → 改善策の実施（Prevention/Correction）
Control → 改善後の維持・監視（継続モニタリング）
DAMAのDQMとTDQMはほぼ同じアプローチ。Specialist試験では「測定 → 分析 → 改善 → 制御」のサイクルが問われる。
データ品質次元の拡張版（Specialist頻出）
DMBOKの6次元に加えて以下が追加で議論される：
| 次元 | 説明 |
|---|---|
| Integrity（整合性） | エンティティ間の参照整合性が保たれているか |
| Precision（精度） | データの詳細度・粒度が目的に適しているか（例: 売上が円単位か万円単位か） |
| Reasonableness（合理性） | データが常識的な範囲に収まっているか（外れ値検出） |
| Accessibility（アクセス可能性） | 必要な時に必要なユーザーがデータにアクセスできるか |
DQプログラムの実施順序（Specialist試験で問われる）
1. Business Case の確立
→ 品質問題がビジネスに与えるコスト・リスクを定量化
2. スコープ定義
→ クリティカルデータエレメント（CDE）の特定
3. 品質要件の定義
→ 各CDEに対するSLA（Completeness 99%以上等）
4. 現状測定
→ データプロファイリング実施
5. ギャップ分析
→ 現状 vs 目標のギャップ特定
6. 根本原因分析
→ 5 Whys・Fishbone Diagramを使用
7. 改善策の実施
→ Prevention優先（入力バリデーション等）
8. 継続監視
→ 自動チェック・ダッシュボード
重要: 多くの組織が「Step 4（測定）→ Step 7（修正）」とショートカットするが、Step 6（根本原因分析）をスキップすると同じ問題が再発する。
データ品質ルールの検証技術
| 技術 | 使用場面 |
|---|---|
| Rule-based Validation | 形式・範囲・必須チェック（実装が容易） |
| Statistical Process Control（SPC） | 時系列でのデータ品質トレンド監視（製造業由来） |
| Anomaly Detection | 機械学習による外れ値・異常値の自動検出 |
| Reference Data Validation | 参照データとの突合（コード値の有効性確認） |
| Cross-System Reconciliation | 複数システム間の値の整合性確認 |
Great Expectations / dbt test の実務パターン
# 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: "^[^@]+@[^@]+$"