data-investigation

データ調査

このスキルを使うと、迅速かつ正確で再現可能な調査を行い、グラフを並べるだけでなく、明確な結論を伝えられます。

目的

すべての調査では、最初の SQL クエリを書く前に、結論を一文で答えられるようにします。

フェーズ 1：クエリを書く前に調査の枠組みを定める

1. 最初に結論の一文を書く

SQL を書く前に、結論として想定する文を書きます。

例：コホート規模の差は、プロダクトの動作ではなく定義の問題です。

この一文を書けない場合は、まだ問いを理解できていません。

2. 調査の種類を分類する

種類	きっかけ	アプローチ
差異分析	A と B が一致しないのはなぜか？	差異を確認し、発生箇所を特定して説明する
根本原因分析	この指標が変化したのはなぜか？	実際の変化か確認し、セグメントを絞り込み、時期を照合して、仕組みを検証する
仮説検証	X が Y の原因か？	成立に必要な条件を定義し、個々の主張を検証して、確認または棄却する
実現可能性の確認	この数値は信頼できるか？	粒度、結合、NULL、定義の重複を確認する

3. クエリを書く前に、競合する仮説を 2～3 個示す

単一の仮説だけで調査してはいけません。確証バイアスにつながります。

仮説を妥当性の高い順に並べ、現時点で正しいと予想するものと、その理由を記します。

フェーズ 2：段階的に詳細度を上げながらクエリを作成する

1. まず確認し、その後で説明する

ステップ 1 では、異常が実在することを必ず確認し、その規模を測定します。 影響を確認する前に、原因の特定に飛びついてはいけません。

select
    <time_bucket>,
    <source_a_count> as metric_a,
    <source_b_count> as metric_b,
    <source_a_count> - <source_b_count> as gap,
    round(100.0 * (<source_a_count> - <source_b_count>) / nullif(<source_a_count>, 0), 1) as pct_gap
from ...
order by 1

2. 一度に 1 つのディメンションで分解し、発生箇所を絞り込む

差異を確認したら、ステップごとに 1 つのディメンションに沿って分解します。

• 時間別：いつ発生したか？
• セグメント別：誰が影響を受けているか？
• シグナル／ソース別：どの経路が欠けているか？

3. タイミングを上流の変更と照合する

異常の開始日が分かったら、以下を確認します。

• 関連するモデル、ETL ジョブ、アプリケーションコードの git コミット
• スキーマのマイグレーションやソースの変更
• 指標定義の変更
• ローンチ、キャンペーン、価格変更などの外部イベント

根本原因として信頼できる説明には、指標がその時期に変化した理由が必要です。

4. 仕組みを検証する

原因候補を特定したら、具体的な仕組みを検証します。

• 影響を受けた母集団は、予測した母集団と一致するか？
• 反実仮想はどのようなものか？
• 独立した別のシグナルも、その説明を裏付けているか？

相関だけで結論を出してはいけません。

5. 結論を出す前に、各仮説を定量化する

原因候補ごとに、数値を示します。

例：

• H1 は 1,240 人のユーザーを説明します
• H2 は 1,050 人のユーザーを説明します

仮説を定量化できない場合は、まだ検証できていません。

フェーズ 3：SQL の衛生ルール

調査では安定した時間範囲を使う

調査用 SQL は再現可能でなければなりません。分析の目的が運用向けかつ継続的なものでない限り、ローリングウィンドウより固定の範囲を優先します。

-- Prefer fixed investigation scope
where created_at >= '2026-02-16'
  and created_at < '2026-04-04'

重要な CTE には粒度を明示するコメントを加える

-- grain: one row per user
with users as (
    ...
)

生の集計値より、名前付きの比較結果を優先する

悪い例：

select count(*) from ...

良い例：

select
    count(*) as users_in_scope,
    count(distinct org_id) as orgs_in_scope
from ...

診断用クエリは小さく保ち、使い捨てにする

診断用 SQL は、1 つの問いに答えるためのものです。早い段階で巨大な再利用可能クエリを作成してはいけません。

フェーズ 4：伝達のルール

結論から伝える

文章の最初の一文で結論を述べます。

悪い例：

不一致について、考えられる説明をいくつか調べました。

良い例：

ダッシュボードのクエリでは社内ユーザーが除外されている一方、ウェアハウスのベースラインには含まれていることが、不一致の原因です。

根拠と解釈を分ける

次のような構成にします。

1. 結論
2. 根拠
3. 他の仮説を棄却した理由
4. 推奨する次のアクション

結論を左右しうる最大の前提を含める

すべての調査で、結論を変えうる最大の前提を明記します。

例：

この結論は、影響を受けた週のバックエンドイベントのタイムスタンプが完全であることを前提としています。データの取り込みが遅れていた場合、差異を過大に見積もっている可能性があります。

フェーズ 5：出力標準

調査を完了するたびに、以下を残してください。

1. 1文での回答
2. 最終的な裏付けとなる SQL またはノートブック
3. 却下した仮説についてのメモ
4. フォローアップの質問、または未解決の曖昧さ

よくある失敗

• 指標の定義をめぐる意見の相違を、プロダクトの問題として扱う
• 粒度や鮮度の異なるソースを比較する
• 定量化せずに、もっともらしい最初の説明を受け入れる
• 早い段階で巨大なクエリを1つ書く
• 回答ではなく、グラフで締めくくる

関連スキル

• 分析や指標に食い違いが生じた理由のデバッグではなく、ビジネス上の質問への回答が目的の場合は、answering-natural-language-questions-with-dbt を使用してください。