LESSON 30分

ストーリー

田中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つの柱
根本原因分析問題特定→影響範囲→仮説→検証→修正→再発防止

チェックリスト

  • 品質メトリクスの4階層構造を理解した
  • 各品質次元の測定方法を把握した
  • データオブザーバビリティの5つの柱を理解した
  • アラート設計の重大度レベルを把握した
  • 根本原因分析のプロセスを理解した

次のステップへ

次は「データ品質文化の醸成」を学びます。ツールやプロセスだけでなく、組織全体が品質に対するオーナーシップを持つ文化をどう作るかを身につけましょう。


推定読了時間: 30分