データ品質の 6 軸：何が「悪い」のかを言語化する

Stage 4 — 第1章 | データマネジメント入門 推定学習時間：40〜50分 | 難易度：★★★☆☆

この章で学ぶこと

Stage 3 までで 置き場所と層 を整えました。 次は、その中身が 信頼できるか です。

現場で「データがおかしい」と言われても、曖昧なままだと手が付けられません。 データ品質（Data Quality）は、6 つの評価軸 で症状を言語化する枠組みです。

この章を終えると、こんなことができるようになります：

• 品質 6 軸（Accuracy / Completeness / Uniqueness / Consistency / Timeliness / Validity）を説明できる
• さくら商事の困りごとを どの軸の問題か に分類できる
• 「SQL が合わない」と「品質が悪い」の違いを説明できる
• analytics の SQL 品質チェックと 役割分担 を説明できる

1. 「おかしい」の正体が分からない

返品 CSV の取込停止後、さくら商事の Slack は次のように流れました。

経理・佐藤: 「6 月売上、先週より 800 万円少ない。データおかしくない？」

基盤・鈴木: 「パイプラインは成功してます。」

マーケ・田中: 「うちの数字は変わってない。」

山田: 「SQL 見直しました。合ってると思います…」

「おかしい」だけでは 何を直すか が決まりません。 品質 6 軸は、症状の ラベル です。

2. 品質 6 軸一覧

現場メモ

1 つの事故が 複数軸 にまたがることは普通です。 返品欠損は Completeness だが、気づくのが遅れれば Timeliness も問題になります。

3. 軸ごとの深掘り

3.1 Accuracy（正確性）

現実世界の事実 とデータが一致しているか。

Accuracy は ビジネスルールの実装ミス でも、ソース入力ミス でも起きます。

3.2 Completeness（完全性）

あるべきデータが存在するか。

-- 完全性チェックの例：日次件数の欠損日を探す
          SELECT dt
          FROM UNNEST(GENERATE_DATE_ARRAY('2026-06-01', '2026-06-30')) AS dt
          LEFT JOIN (
            SELECT DATE(refund_at) AS dt, COUNT(*) AS cnt
            FROM bronze_refunds
            GROUP BY 1
          ) r USING (dt)
          WHERE r.cnt IS NULL;
          

返品 CSV 2 日欠損は Completeness の典型です。

3.3 Uniqueness（一意性）

同じエンティティが 重複していないか。

3.4 Consistency（一貫性）

システム間・表間 で矛盾がないか。

Consistency 問題の一部は 定義未合意 です。品質だけでなくガバナンスの話も混ざります。

3.5 Timeliness（鮮度）

データは 必要な時点で最新か。

Stage 3 で学んだ MV refresh 間隔も Timeliness 設計です。

3.6 Validity（妥当性）

定義・形式・許容値 に沿っているか。

Stage 2 のオントロジー・用語集は Validity を守るための仕様書 です。

4. 6 軸で見る返品欠損事件

5. analytics トラックとの棲み分け

データ品質チェック（analytics） では、NULL・重複・外れ値を SQL で検出 します。

SQL は検知ツール。6 軸は共通言語。

6. 品質ルールの書き方（最小）

さくら商事で mart_finance に付けたルール例:

ルールは 測定可能 に。曖昧な「正しそう」は運用できません。

体系コラム：カリキュラム上の位置づけ

コラム：よくある誤解 —「品質＝NULL がないこと」

さくら商事で返品 CSV が 2 日欠損したとき、テーブルには NULL はほとんどありませんでした。Completeness だけ見れば「問題なし」に見える——これが最初の誤解です。件数が平日比 0 件という Completeness のシグナル を見逃していました。

もう一つは「品質は DE の仕事」と捉えること。Timeliness で古い MV が会議に出た事例、Validity でテスト注文が混ざった事例は、オーナーとスチュワード の判断領域でもあります。6 軸は技術チェックリストであり、同時に 公開してよい状態か の共通言語です。

佐藤さんは経理オーナーとして Q-001（返品行数）の閾値承認を担い、鈴木さんは実装します。品質はパイプラインの向こう側、意思決定の安全装置 です。

まとめ

この章のキーメッセージ：

「データがおかしい」を 6 軸のどれか に変換すると、次のアクション（取込修正、定義見直し、公開停止）が決まります。

次に読む

• 前章（Stage 3）: テーブル・ビュー・MV
• 次章: 品質疑義とインシデント対応
• 関連: データ品質チェック SQL

確認問題

問題 1

同じ order_id が fct_orders に 2 行存在し、売上が 2 倍になった。 主な品質軸 はどれですか。

A. Uniqueness
B. Timeliness
C. Consistency のみ
D. 品質問題ではない

正解: A

解説: 同一キーの重複は Uniqueness です。Timeliness は鮮度、Consistency はソース間矛盾が中心です。

問題 2

返品 CSV が 2 日欠損し、売上が実態より高く見えた。 最も中心となる軸 はどれですか。

A. Completeness
B. Accuracy のみ（Completeness は無関係）
C. Validity のみ
D. 6 軸は使わない

正解: A

解説: 行そのものが 存在しない のが Completeness です。結果として Accuracy も狂いますが、根本原因の分類は Completeness が先です。

問題 3

「テスト注文が mart_finance に含まれていた」問題の 主軸 として最も適切なのはどれですか。

A. Validity（定義・除外ルール違反）
B. Timeliness
C. Uniqueness
D. 統計検定 2 級の計算ミス

正解: A

解説: テスト除外は 公式定義（Validity） の問題です。SQL 技法や分布の話ではありません。

用語メモ（この章）