ストーリー
田
田中VPoE
品質フレームワークを理解した。次は「測定」と「監視」だ。品質基準を定義しても、測定できなければ管理できない
あなた
「測定できないものは管理できない」ですね。ドラッカーの言葉でしたっけ
あ
田
田中VPoE
よく知っているな。データ品質も同じだ。ただし、闇雲にメトリクスを増やすのは逆効果だ。「何を」「どの粒度で」「どのタイミングで」測定するかの設計が重要だ。さらに、問題を検知したら即座にアラートを飛ばし、影響範囲を特定し、修正する仕組みが必要だ
あなた
品質問題が起きたときの「消火活動」だけでなく、「火災報知器」を設置するイメージですか
あ
田
田中VPoE
まさにその通りだ。事後対応ではなく、予防と早期発見の仕組みを設計しよう
品質メトリクスの設計
メトリクス体系
品質メトリクスの階層構造:
Level 1: 組織レベル(経営報告)
├── 全社データ品質スコア(総合指標)
├── SLA遵守率
└── 品質改善トレンド
Level 2: ドメインレベル(ドメインオーナー向け)
├── ドメイン別品質スコア
├── 6次元別スコア
└── 品質問題件数とトレンド
Level 3: データセットレベル(データスチュワード向け)
├── テーブル別品質スコア
├── カラム別品質詳細
└── テストケース通過率
Level 4: パイプラインレベル(データエンジニア向け)
├── テスト実行結果
├── エラーログ
└── リトライ回数
各品質次元の測定方法
| 次元 | メトリクス | 計算式 | 良好基準(例) |
|---|
| 完全性 | NULL率 | NULL行数 / 総行数 × 100 | < 0.5% |
| 完全性 | レコード数偏差 | |今回 - 前回| / 前回 × 100 | < 10% |
| 正確性 | ルール準拠率 | 準拠行数 / 総行数 × 100 | > 99% |
| 一貫性 | クロスチェック合致率 | 合致件数 / 総件数 × 100 | > 99.5% |
| 適時性 | データ遅延 | 実際更新時刻 - 期待更新時刻 | < SLA |
| 一意性 | 重複率 | 重複行数 / 総行数 × 100 | < 0.1% |
| 妥当性 | フォーマット準拠率 | 準拠行数 / 総行数 × 100 | > 99.5% |
品質スコアの算出
| 次元 | 重み | スコア計算 |
|---|
| 完全性 | 25% | (1 - NULL率) × 100 |
| 正確性 | 25% | ルール準拠率 |
| 一貫性 | 15% | クロスチェック合致率 |
| 適時性 | 15% | SLA内更新率 |
| 一意性 | 10% | (1 - 重複率) × 100 |
| 妥当性 | 10% | フォーマット準拠率 |
総合品質スコア = 各次元スコア × 重み の加重平均
データオブザーバビリティ
データオブザーバビリティとは
| 項目 | 説明 |
|---|
| 定義 | データの健全性を継続的に監視し、問題を自動検知・診断する能力 |
| 従来の品質管理との違い | 事前定義のルールだけでなく、パターン学習による異常検知も含む |
| 5つの柱 | 鮮度(Freshness)、量(Volume)、分布(Distribution)、スキーマ(Schema)、リネージ(Lineage) |
データオブザーバビリティの5つの柱
| 柱 | 監視内容 | 異常の例 |
|---|
| 鮮度 | データの最終更新時刻 | 朝9時に更新されるはずのデータが11時になっても未更新 |
| 量 | レコード数の変動 | 通常10万行/日のテーブルが1,000行しかない |
| 分布 | カラムの値の統計的分布 | 平均注文金額が突然2倍になった |
| スキーマ | テーブル構造の変更 | カラムが削除された、型が変わった |
| リネージ | データの流れと依存関係 | 上流テーブルの変更が下流に影響 |
アラート設計
| 重大度 | 条件 | 通知先 | 通知方法 | SLA |
|---|
| P0(緊急) | Tier 1データのSLA違反、経営ダッシュボードに影響 | データチーム全員 + オーナー | Slack緊急チャンネル + 電話 | 30分以内に対応開始 |
| P1(重要) | Tier 2データのSLA違反、複数テーブルに影響 | 担当データエンジニア + スチュワード | Slack + メール | 2時間以内に対応開始 |
| P2(注意) | Tier 3のSLA違反、単一テーブルの品質劣化 | 担当データエンジニア | Slack | 翌営業日中に対応 |
| P3(情報) | 軽微な品質低下トレンド、予防的アラート | 週次品質レポートに含める | メール(週次) | 次回スプリントで対応 |
品質ダッシュボードの設計
エグゼクティブダッシュボード(経営層向け)
| セクション | 表示内容 | 更新頻度 |
|---|
| 全社品質スコア | 100点満点のスコアとトレンド(過去12ヶ月) | 日次 |
| SLA遵守率 | Tier別の遵守率とトレンド | 日次 |
| 品質インシデント | 月間のP0/P1インシデント数と解決状況 | 日次 |
| 改善進捗 | 品質改善イニシアティブの進捗率 | 週次 |
| コストインパクト | 品質問題による推定損失額とトレンド | 月次 |
オペレーションダッシュボード(データチーム向け)
| セクション | 表示内容 | 更新頻度 |
|---|
| テスト通過率 | 全テストケースの通過/失敗/スキップ状況 | パイプライン実行後 |
| 品質アラート一覧 | 未解決アラートのリスト(重大度別) | リアルタイム |
| データセット別スコア | 各テーブルの6次元スコア | 日次 |
| トレンドアラート | 品質が徐々に劣化しているテーブル | 週次 |
| パイプラインヘルス | 各パイプラインの成功/失敗/遅延状況 | リアルタイム |
根本原因分析(RCA)
品質問題の典型的な根本原因
| カテゴリ | 原因 | 発生率目安 | 対策 |
|---|
| ソースデータ | アプリケーションのバグでNULLが混入 | 30% | 入力バリデーション強化 |
| パイプライン | ETL処理の不具合でデータが欠落 | 25% | パイプラインテスト、冪等性確保 |
| スキーマ変更 | 上流テーブルの変更が通知なく行われた | 20% | スキーマ変更の管理プロセス |
| 外部データ | 3rdパーティデータの品質劣化 | 10% | 外部データの品質チェック |
| 手動操作 | 手動データ投入のミス | 10% | 自動化、承認フロー |
| インフラ | ストレージ障害、ネットワーク断 | 5% | 冗長構成、バックアップ |
RCAプロセス
品質問題の根本原因分析プロセス:
Step 1: 問題の特定
└── 何が(どのデータ)、いつ(いつから)、どの程度(影響範囲)
Step 2: 影響範囲の特定
└── リネージを辿り、下流への影響を調査
Step 3: 仮説の列挙
└── 5 Whysで根本原因の候補を列挙
Step 4: 仮説の検証
└── ログ分析、データプロファイリングで検証
Step 5: 修正
└── データの修正 + パイプラインの修正
Step 6: 再発防止
└── テストケースの追加、監視の強化、プロセスの改善
「品質問題は”見つけて直す”だけでは不十分だ。根本原因を特定し、同じ問題が二度と起きないように予防策を講じる。そしてその予防策をテストケースとして自動化する。これを繰り返すことで品質は着実に向上する」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| メトリクス階層 | 組織→ドメイン→データセット→パイプラインの4階層 |
| 品質スコア | 6次元の加重平均で算出 |
| オブザーバビリティ | 鮮度、量、分布、スキーマ、リネージの5つの柱 |
| 根本原因分析 | 問題特定→影響範囲→仮説→検証→修正→再発防止 |
チェックリスト
次のステップへ
次は「データ品質文化の醸成」を学びます。ツールやプロセスだけでなく、組織全体が品質に対するオーナーシップを持つ文化をどう作るかを身につけましょう。
推定読了時間: 30分