「 のテストが全部通ってます」は当たり前。「データを信用していいか」は別の問題です。今回は、信頼されるデータ基盤の品質設計を5階層で整理します。
データ品質の5階層
| 層 | 観点 | ツール例 |
|---|---|---|
| 完全性 | NULL率、行数、欠損 | dbt test (not_null), GE |
| 一意性 | 重複、PK制約 | dbt test (unique) |
| 整合性 | JOIN先と一致するか | dbt relationships |
| 時系列性 | 日次取り込みが止まっていないか | dbt source freshness |
| 業務妥当性 | ビジネスルール（例：注文金額>0） | カスタムテスト |
業務妥当性テストの実装
dbt schema.yml カスタムテスト
YAML
models: - name: fct_orders columns: - name: amount tests: - not_null - dbt_utils.expression_is_true: expression: ">= 0" config: severity: error - dbt_utils.accepted_range: min_value: 0 max_value: 10000000 config: severity: warn金額の範囲のように規則で検査できるものは、まず決定的なテストにします。説明文とカテゴリの食い違いのような意味の確認を補助したい場合は、Jevの仕組みとデータ品質検査への実装案で、候補判定を記録して人の確認と比べる進め方を紹介しています。
監視と通知：「いつ気付くか」が品質
テスト失敗を現場担当者が朝のメールで知るようにすると、「気付いた時には半日経ってた」を防げる。Slack / メール / PagerDuty に分岐させる。
- WARN（少し変）：Slack チャンネルに通知のみ
- ERROR（明らかにダメ）：データオーナーをメンション、管理画面でレッド
- CRITICAL（業務停止級）：PagerDuty で当番呼び出し、 ダッシュボードに警告バナー
「使えるデータ」を文書化する
（DataHub / Atlan / dbt docs）に「最終更新」「品質スコア」「」を必ず付ける。「このデータ信頼できる？」にすぐ答えられる状態を作る。
ふくふくの進め方
「データ基盤はあるが、現場が信用してくれない」というご相談には、現状の品質テスト棚卸し（1〜2 週間）→ 5 階層の補強実装 → カタログ整備を 1〜2 ヶ月で。「使われるデータ」になるかどうかは、品質設計が 8 割です。
次回予告
EP.10 は組織設計。データチームの最適規模と、エンジニア・アナリスト・ビジネス担当の役割分担を実例で。