「 のテストが全部通ってます」は当たり前。「データを信用していいか」は別の問題です。今回は、信頼されるデータ基盤の品質設計を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監視と通知：「いつ気付くか」が品質
テスト失敗を現場担当者が朝のメールで知るようにすると、「気付いた時には半日経ってた」を防げる。Slack / メール / PagerDuty に分岐させる。
- WARN（少し変）：Slack チャンネルに通知のみ
- ERROR（明らかにダメ）：データオーナーをメンション、管理画面でレッド
- CRITICAL（業務停止級）：PagerDuty で当番呼び出し、 ダッシュボードに警告バナー
「使えるデータ」を文書化する
（DataHub / Atlan / dbt docs）に「最終更新」「品質スコア」「」を必ず付ける。「このデータ信頼できる？」にすぐ答えられる状態を作る。
ふくふくの進め方
「データ基盤はあるが、現場が信用してくれない」というご相談には、現状の品質テスト棚卸し（1〜2 週間）→ 5 階層の補強実装 → カタログ整備を 1〜2 ヶ月で。「使われるデータ」になるかどうかは、品質設計が 8 割です。
次回予告
EP.10 は組織設計。データチームの最適規模と、エンジニア・アナリスト・ビジネス担当の役割分担を実例で。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。