データ品質フレームワーク

ストーリー

田

田中VPoE

Step 3でデータ民主化の仕組みを設計した。だが、民主化した先に待っている最大の敵がある。何だと思う？

あなた

セキュリティ…いや、データ品質ですか？

あ

田

田中VPoE

その通りだ。全社員がデータにアクセスできても、そのデータが間違っていたら最悪だ。誤ったデータで意思決定すれば、正しい判断をした場合より悪い結果を招く。「データがないから勘で判断」よりも「間違ったデータで自信を持って判断」の方が危険だ

あなた

民主化で利用者が増えるほど、品質問題の影響も大きくなりますね

あ

田

田中VPoE

だからStep 4では「データ品質」を徹底的に学ぶ。品質を管理する仕組みだけでなく、品質を「文化」として組織に根付かせる方法を身につけよう

データ品質の6次元

DAMA-DMBOKの品質フレームワーク

次元	定義	測定例	ビジネスへの影響
完全性（Completeness）	必要なデータが欠けていないか	NULL率、必須フィールドの充填率	分析対象が欠落し、偏った結論に至る
正確性（Accuracy）	データが現実を正しく反映しているか	ビジネスルールへの準拠率	誤った数値で意思決定してしまう
一貫性（Consistency）	異なるシステム間でデータが矛盾しないか	クロスチェックの不整合率	部門間で数字が合わず信頼を失う
適時性（Timeliness）	データが十分に新鮮か	最終更新からの経過時間	古いデータで判断し、機会を逃す
一意性（Uniqueness）	同じ実体が重複して記録されていないか	重複レコードの割合	重複による過大計上、二重連絡
妥当性（Validity）	データが定義された形式・範囲に合っているか	フォーマットチェックのエラー率	システム間の連携エラー

品質問題の年間コスト

データ品質問題のコスト（FreshCart社 試算）:

直接コスト:
  ├── 手動データ修正工数:      年間 1,200時間 × @5,000円 = 600万円
  ├── 重複顧客への二重配送:    年間 200件 × @3,000円 = 60万円
  ├── 住所不備による配送失敗:   年間 6,400件 × @2,000円 = 1,280万円
  └── データ不整合の調査工数:   年間 800時間 × @5,000円 = 400万円

間接コスト:
  ├── 誤った在庫予測による機会損失:  推定 3,000万円
  ├── 不正確なCVRによる広告無駄遣い: 推定 1,500万円
  └── データ不信による非データ意思決定: 定量化困難

推定年間コスト: 6,840万円以上
  → 売上60億円の約1.1%がデータ品質問題で失われている

データ品質フレームワークの設計

3層構造

データ品質フレームワークの3層構造:

┌──────────────────────────────────────────────────────┐
│  Layer 3: 品質ガバナンス                               │
│  品質ポリシー | 品質基準 | SLA定義 | 責任体制           │
├──────────────────────────────────────────────────────┤
│  Layer 2: 品質管理プロセス                              │
│  品質測定 | 問題検知 | 根本原因分析 | 修正 | 予防        │
├──────────────────────────────────────────────────────┤
│  Layer 1: 品質チェックエンジン                           │
│  自動テスト | プロファイリング | アノマリ検知 | アラート  │
└──────────────────────────────────────────────────────┘

Layer 1: 品質チェックの種類

チェック種別	内容	ツール例	実行タイミング
スキーマチェック	カラムの型、NULL許可、外部キー	dbt tests, Great Expectations	パイプライン実行時
ビジネスルールチェック	値の範囲、整合性、ロジック	dbt tests, Soda	パイプライン実行時
統計プロファイリング	分布、外れ値、トレンド変化	Great Expectations, Monte Carlo	日次バッチ
クロスデータセットチェック	テーブル間の整合性	dbt tests	日次バッチ
アノマリ検知	過去のパターンからの逸脱	Monte Carlo, Anomalo	リアルタイム/日次

Layer 2: 品質管理プロセス（PDCA）

フェーズ	活動	成果物
Plan（計画）	品質基準の定義、SLA設定、テストケース設計	品質基準書、SLA定義書
Do（実行）	品質チェックの実装・実行、結果記録	テスト結果、品質スコア
Check（確認）	品質レポートの確認、トレンド分析、問題の優先順位付け	品質レポート、優先順位リスト
Act（改善）	根本原因分析、修正、予防策の実装	改善レポート、予防策

データ品質SLAの設計

SLAの構成要素

要素	説明	例
対象データ	SLAが適用されるデータセット	daily_sales_summary
品質次元	測定する品質の側面	完全性、正確性、適時性
目標値	達成すべき品質レベル	完全性99.5%以上
測定方法	品質の計算方法	NULL行数 / 総行数
測定頻度	品質チェックの間隔	日次
違反時の対応	SLA違反時のエスカレーション	P1: 即時通知、P2: 日次レポート

データティア別SLA

ティア	対象データ	完全性	正確性	適時性	監視レベル
Tier 1（Critical）	売上、顧客PII	99.9%	99.5%	1時間以内	リアルタイム
Tier 2（Important）	在庫、マーケ指標	99.0%	98.0%	6時間以内	日次
Tier 3（Standard）	行動ログ、内部指標	95.0%	95.0%	24時間以内	週次

品質チェックツールの比較

主要ツール

ツール	カテゴリ	強み	弱み	コスト
Great Expectations	OSS	柔軟なテスト定義、Python連携	UIが弱い、運用負荷	無料（OSS）
dbt tests	OSS	dbtとの統合、SQL定義	統計テストが弱い	dbt Coreは無料
Soda	OSS/SaaS	YAML定義、使いやすさ	大規模運用の実績	OSS版無料/SaaS有料
Monte Carlo	SaaS	自動アノマリ検知、リネージ	コスト高	要問い合わせ
Anomalo	SaaS	ML自動検知、少ない設定	カスタマイズ制限	要問い合わせ

ツール選定のフレームワーク

評価軸	重み	評価項目
テスト網羅性	25%	6次元のカバー範囲
自動化	25%	自動検知、パイプライン統合
運用負荷	20%	設定・メンテナンスの手間
可視化	15%	ダッシュボード、アラート
コスト	15%	ライセンス、運用コスト

「品質チェックはパイプラインの”一部”として組み込む。後付けで品質テストを入れるのではなく、データが生成される時点から品質を保証する設計にすることが重要だ」 — 田中VPoE

まとめ

ポイント	内容
データ品質の6次元	完全性、正確性、一貫性、適時性、一意性、妥当性
3層構造	品質チェックエンジン→品質管理プロセス→品質ガバナンス
SLA設計	データの重要度に応じたティア別SLAを設定
ツール選定	テスト網羅性、自動化、運用負荷、可視化、コストで評価

チェックリスト

データ品質の6次元を理解した
品質問題のコストインパクトを認識した
3層構造の品質フレームワークを把握した
SLAの設計方法を理解した
品質チェックツールの選択肢を把握した

次のステップへ

次は「品質メトリクスと監視」を学びます。品質を定量的に測定し、継続的に監視する仕組みを構築する方法を身につけましょう。

推定読了時間: 30分