ストーリー
田
田中VPoE
データ品質、リネージ、カタログ、オブザーバビリティ。データガバナンスの4つの柱を学んだ。これらを統合したガバナンス基盤をDataFlow社に設計してもらう
あなた
個別のツールではなく、全体が連携するように設計するということですね
あ
田
田中VPoE
その通り。品質チェックの結果がカタログに反映され、リネージで影響分析ができ、オブザーバビリティが異常を検知してアラートを発報する。この一連のフローが自動で動く基盤だ
あなた
データチームへの「この数字合ってる？」という質問がゼロになる世界ですね
あ
田
田中VPoE
それが理想だ。データの信頼性がカタログのスコアとして可視化され、誰でもセルフサービスでデータを信頼して使える基盤を設計してくれ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | データガバナンス基盤の設計 |
| 想定時間 | 90分 |
| 成果物 | ガバナンス基盤設計書（品質 + カタログ + オブザーバビリティ統合） |
Mission 1: データ品質フレームワークの設計
要件
DataFlow社の主要テーブルに対するデータ品質フレームワークを設計してください。
- 主要5テーブルの品質チェック項目を定義する（各テーブル最低5件）
- 品質スコアの算出ロジックを設計する
- 品質SLAを定義する
解答例
品質チェック項目
| テーブル | チェック項目 | 種類 | 閾値 |
|---|---|---|---|
| slv_orders | order_id NOT NULL & UNIQUE | 基本 | 100% |
| slv_orders | total_amount >= 0 | 妥当性 | 100% |
| slv_orders | order_date <= CURRENT_DATE | 妥当性 | 100% |
| slv_orders | レコード数が前日比50%以上 | ボリューム | 異常検知 |
| slv_orders | status IN (定義値) | 妥当性 | 100% |
| slv_customers | customer_id NOT NULL & UNIQUE | 基本 | 100% |
| slv_customers | email NOT NULL | 完全性 | 99% |
| slv_customers | segment IN (定義値) | 妥当性 | 100% |
| slv_customers | created_at <= CURRENT_DATE | 妥当性 | 100% |
| slv_customers | email形式バリデーション | 正確性 | 95% |
品質SLA
| テーブルカテゴリ | 品質スコア | チェック頻度 | 違反時のアクション |
|---|---|---|---|
| Gold（経営ダッシュボード） | 95点以上 | 毎時 | Critical アラート |
| Silver（分析用） | 90点以上 | 日次 | High アラート |
| Bronze（生データ） | 85点以上 | 日次 | Medium アラート |
Mission 2: データカタログとビジネス用語集
要件
DataFlow社のデータカタログとビジネス用語集を設計してください。
- 主要KPI（5つ以上）のビジネス用語定義を作成する
- データカタログのツール選定と導入計画を策定する
- PIIデータの分類とアクセスポリシーを定義する
解答例
ビジネス用語集
| 用語 | 定義 | 計算式 | ソーステーブル | オーナー |
|---|---|---|---|---|
| アクティブユーザー | 過去30日間に1回以上ログインしたユーザー | COUNT(DISTINCT user_id) WHERE last_login >= today - 30 | gold.fact_user_activity | プロダクト |
| MRR | 当月のアクティブサブスクリプション × 月額料金の合計 | SUM(monthly_price) WHERE status=‘ACTIVE’ | gold.fact_subscription | ファイナンス |
| チャーン率 | 月初アクティブのうち月末非アクティブの割合 | (月初Active - 月末Active) / 月初Active | gold.mart_monthly_metrics | CS |
| NRR | 純収益維持率 | (期首MRR + 拡大 - 縮小 - 解約) / 期首MRR | gold.mart_monthly_metrics | ファイナンス |
| LTV | 顧客生涯価値 | ARPU / チャーン率 | gold.customer_ltv | マーケティング |
PII分類
| PIIレベル | データ例 | アクセス制御 | Gold層での扱い |
|---|---|---|---|
| 高 | メールアドレス、氏名 | データチーム + CS | SHA256ハッシュ化 |
| 中 | 会社名、所在地 | データチーム + 営業 | マスキング（一部表示） |
| 低 | 業種、従業員規模 | 全社 | そのまま利用可 |
ツール選定
| コンポーネント | ツール | 理由 |
|---|---|---|
| データカタログ | DataHub (OSS) | コスト効率、メタデータAPI、BigQuery連携 |
| スキーマレジストリ | dbt docs + DataHub | dbtのdescriptionを自動同期 |
| PII検出 | Google Cloud DLP | BigQueryネイティブ統合 |
Mission 3: データオブザーバビリティの設計
要件
DataFlow社のデータオブザーバビリティ基盤を設計してください。
- 監視対象テーブルと監視項目を定義する
- アラート設計（重要度、通知先、対応フロー）を策定する
- データインシデント対応プロセスを設計する
- データSLAを定義する
解答例
監視設計
| テーブル | 鮮度SLA | ボリューム監視 | 分布監視 |
|---|---|---|---|
| gold.revenue_daily | 2時間 | 日次レコード数 ±50% | net_revenue の3σ異常 |
| gold.fact_user_activity | 1時間 | 時間次レコード数 ±70% | login_count の NULL率 |
| gold.mart_monthly_metrics | 6時間 | 月次1レコード | churn_rate の値域 |
| silver.slv_orders | 30分 | 時間次レコード数 ±50% | total_amount の分布 |
データSLA
| SLA | 目標値 | 計測方法 |
|---|---|---|
| データ鮮度 | Gold層: 2時間以内 | 最終更新タイムスタンプ監視 |
| MTTD | 30分以内 | アラート発報までの時間 |
| MTTR | 4時間以内 | インシデントクローズまでの時間 |
| 品質スコア | 95点以上 | 加重平均スコア |
| パイプライン稼働率 | 99.5% | ジョブ成功率 |
インシデント対応プロセス
- 検知: Elementaryがdbt test失敗を検知 → Slack #data-incidents に通知
- 影響分析: DataHubのリネージで影響範囲を特定 → ステークホルダーに通知
- 修復: データエンジニアが原因調査 → dbtモデル修正 → 再実行
- 検証: 品質チェック再実行 → スコア回復を確認
- 振り返り: 週次のデータレビューでポストモーテム実施
達成度チェック
| 観点 | 達成基準 |
|---|---|
| 品質フレームワーク | 主要テーブルの品質チェック項目とSLAが定義されている |
| カタログ | ビジネス用語集とPII分類が作成されている |
| オブザーバビリティ | 監視設計、アラート設計、インシデント対応が設計されている |
| 統合性 | 品質・カタログ・オブザーバビリティが連携する設計になっている |
推定所要時間: 90分