分析前チェックリスト:SQL の前に確認すること
Stage 4 — 第4章 | データマネジメント入門 推定学習時間:35〜45分 | 難易度:★★☆☆☆
この章で学ぶこと
NULL チェックや重複検出は analytics の品質 SQL で学びます。 本章では クエリを書く前 に、データマネジメント視点で確認すべき 判断チェックリスト を扱います。
さくら商事の山田さんは、SQL スキルは上がりました。 それでも「この表を触っていいか」「この数字を会議で使っていいか」で止まる場面が残ります。
この章を終えると、こんなことができるようになります:
- 分析前チェックリストを その場で使える 形で持てる
- SQL 品質チェックと 判断チェック の役割分担を説明できる
- 公式 / 探索 / 野良の 利用境界 を確認できる
- さくら商事の「分析開始前 5 分」ルーティンを説明できる
1. 上手い SQL でも会議で使えない
山田さんが作った「6 月チャネル別売上」は、SQL としては正しかった。 しかし会議前チェックで次の問題が判明しました。
| # | チェック | 結果 |
|---|---|---|
| 1 | 参照表は SSOT か | × staging_orders(Silver) |
| 2 | 定義は用語集と一致か | × 返品前 |
| 3 | カタログに記載か | × |
| 4 | 品質ルール通過か | 未実行 |
| 5 | 会議利用の承認 | × |
鈴木
「計算は合ってるかも。でも 公式経路じゃない から会議には出せない。」
2. 二種類のチェック
| 種類 | タイミング | 内容 | 担当 |
|---|---|---|---|
| 判断チェック(本章) | SQL 前 | 正本・定義・権限・用途 | アナリスト全員 |
| SQL 品質チェック(analytics) | SQL 後 | NULL、重複、外れ値 | AE / アナリスト |
判断チェック → SQL 作成 → 品質 SQL → 共有 / 会議
3. 分析前チェックリスト(さくら商事版)
A. データの出どころ
- A1. 参照している表・列は カタログ にあるか
- A2. 公式数字なら
mart_*または セマンティックレイヤー か - A3. Bronze / 野良 Sheets ではないか
- A4. OLTP 本番 に直接触っていないか
B. 意味と定義
- B1. 指標名は 用語集 の定義と一致するか
- B2. 返品・キャンセル・テスト注文の 除外 は公式と同じか
- B3. 同名列(
revenue等)を 借りていないか
C. 品質・鮮度
- C1. 対象期間に 既知インシデント はないか(#data-incident)
- C2. マートの 最終更新時刻 は用途に足りるか
- C3. 探索なら 非公式 注記を付ける
D. 権限・コンプライアンス(Stage 5 詳述)
- D1. PII 列を 含めていないか(必要ならマスク済みか)
- D2. 利用目的は 申請済み か
- D3. 外部共有 禁止 データではないか
E. 共有・会議
- E1. 会議資料 → L3 / 公式マートのみ
- E2. 探索結果 → 「非公式・暫定」 ラベル
- E3. オーナー不明データ → 使用停止
4. 用途別:どこまでチェックするか
| 用途 | 必須セクション | さくら商事 |
|---|---|---|
| 経営会議 | A + B + C + E 全部 | 佐藤承認 |
| 部門定例 | A + B + C | マーケオーナー |
| 個人探索 | A3/A4 + D1 | 自己責任、共有禁止 |
| 外部報告 | 全部 + ガバナンス | DPO 確認 |
5. 5 分ルーティン(山田さん版)
- カタログで表を検索(30 秒)
- 用語集で指標定義(1 分)
#data-incidentを検索(30 秒)mart_*か確認(30 秒)- 会議用なら L3 経由に切替(2 分)
Slack 定型
「この分析、公式経路確認済み(
mart_finance/ 用語集 v1.2 / インシデントなし)。探索版は別途。」
6. analytics への橋渡し
判断チェック 通過後、SQL 品質チェックへ。
| 判断チェック OK | 次にやること |
|---|---|
| 公式マート確定 | analytics の NULL/重複 SQL を実行 |
| 探索 Silver 確定 | 軽量チェック + 非公式ラベル |
| 野良と判明 | 止める。公式へ移行 ticket |
詳細: データ品質チェック
7. Stage 4 の振り返り
| 章 | キーワード |
|---|---|
| s4-p1 | 6 軸で症状を言語化 |
| s4-p2 | 止める・伝える・直す |
| s4-p3 | 野良マートと SSOT 崩壊 |
| s4-p4 | SQL 前 の判断 |
Stage 5 では 権限・ガバナンス・AI 時代のハーネス へ。
体系コラム:カリキュラム上の位置づけ
| 項目 | 内容 |
|---|---|
| Stage / 章 | Stage 4 — 第4章「分析前チェックリスト」(Stage 4 完結章) |
| 今回の論点 | 上手い SQL でも、公開前の 5 分 で会議利用可否を判断する |
| DAMA 領域 | データ品質、メタデータ、データガバナンス |
| ライフサイクル | 活用直前の ゲート(加工の成果を世に出す前) |
| 前章との接続 | 野良マートと SSOT — 公式経路かをチェックリスト第 1 項に |
| 次章への伏線 | アクセス制御の基礎 — 見ていいデータの 権限層 |
📚 途中チェックポイント
Stage 4 を終えた時点で、次の 3 点を確認してください。
- 返品欠損のような事例を 6 軸 のどれで説明するか、2 軸以上挙げられるか
- 品質疑義が出たとき 誰に・いつ・何を 報告するか、さくら商事版 runbook で言えるか
- 分析前チェックリストの 5 項目 を、社内探索用と経営会用で使い分けられるか
まとめ
| ポイント | 内容 |
|---|---|
| 判断チェック | 正本・定義・用途・権限 |
| SQL チェック | 値の異常検知(analytics) |
| 5 分ルーティン | カタログ・用語集・インシデント |
| 会議 | 公式経路のみ |
この章のキーメッセージ:
分析力は 「書く力」 だけでなく 「触っていいか決める力」 です。 チェックリストは創意の枷ではなく、説明責任のショートカットです。
次に読む
- 前章: 野良マートと SSOT 崩壊
- Stage 5 第1章: 権限設計の基本
- 関連: データ品質チェック SQL
確認問題
問題 1
山田さんが staging_orders から売上を出し、会議資料に載せようとした。
分析前チェックで引っかかる項目 として最も適切なのはどれですか。
A. A2(公式数字なのに mart / L3 経路ではない)
B. ウィンドウ関数の有無
C. グラフの色
D. Python のバージョン
正解: A
解説: Silver/staging は 公式提供層ではない です。会議には Gold / L3 が必要です。
問題 2
判断チェックと SQL 品質チェックの関係として 最も正確 なのはどれですか。
A. 同じもの。どちらか 1 つで足りる
B. 判断チェックが先。SQL 品質チェックは値の異常検知で後
C. SQL 品質チェックだけすれば SSOT は自動達成
D. 判断チェックは経営のみ
正解: B
解説: 正本・用途 の確認が先、値 の検証が後です。役割は補完関係です。
問題 3
個人探索で silver_orders を使う。最低限クリアすべきはどれですか。
A. 何も確認不要
B. 本番 OLTP 非使用、PII 非含有、結果に非公式ラベル
C. 経営承認必須
D. 野良 Sheets にコピーしてから
正解: B
解説: 探索は 限定的に許可 されますが、本番・PII・無ラベル共有は禁止です。C は過剰、D は SSOT 崩壊です。
用語メモ(この章)
| 用語 | 意味(この章での使い方) |
|---|---|
| 判断チェック | SQL 前の正本・定義・用途・権限確認 |
| 公式経路 | SSOT マート + セマンティックレイヤー |
| 非公式ラベル | 探索・暫定結果である旨の明示 |
| 既知インシデント | 公開中の品質問題(#data-incident 等) |