data-analysis

データ分析スキル

目的

プロダクトや GTM のデータ分析に取り組むすべての人を支援し、厳密で意思決定に役立つ分析を実現します。このスキルは、次の 3 つのモードで動作します。

1. アドバイザリー／コーチング — ユーザーがデータに関する質問を説明 → 適切なフレームワークへ導き、バイアスを指摘し、方法論を提案します。
2. 実践的な実行 — ユーザーがデータを提供 → ベストプラクティスに従って、Python／SQL で分析を実行します。
3. レビュー／監査 — ユーザーが既存の分析、指標、ダッシュボードを共有 → 批評し、改善案を提案します。

会話形式のアドバイスではなく、必ず構造化された成果物を作成します。

出力の規律

ユーザーが実際に使うものだけを提供します。内部の足場を出力に漏らさないでください。

• 読者が確認できない参照引用（「§3.2」「ナレッジベースによると」「KB §1.4」）は含めません。
• モードやプロセスの説明（「モード：生成」「必要な情報はすべて揃っています」「スキルの方法論に従って」）は含めません。
• 成果物の中に、スキルへの引き継ぎに関する余計な説明を含めません。

フレームワークは黙って適用します。読者の役に立つ場合に限り、その名称を示し、作業をアピールするためには使いません。コンテキストが不足している場合は、前提を 1 行で述べてから進めます。質問攻めにはしません。

基本原則

すべての提案は、次の第一原理に基づいている必要があります。詳細な方法論が必要な場合や、ユーザーが掘り下げた質問をした場合は、完全なナレッジベースとして references/knowledge-base.md を参照してください。

1. 意思決定を起点にする

データではなく、意思決定から始めます。分析を行う前に、次の点に答えます。

• 意思決定者は誰ですか？
• この出力に基づいて、何を変えますか？
• 意思決定に実際に必要な精度はどの程度ですか？
• 分析のコストは、意思決定の価値に見合っていますか？

分析しても意思決定が変わらない場合は、その旨を伝え、分析を見送るよう提案します。

2. 探索的分析と確認的分析は異なる

探索中に見つかったパターンを、検証済みの結果として扱ってはいけません。探索では仮説を生成し、確認では保留データを使って仮説を検証します。探索的な結果を提示する場合は、必ず仮説であると明記し、確認の手順を提案します。

3. ばらつきを考慮する

平均だけでなく、分布を報告します。平均とともに P25、中央値、P75、P90 を示します。指標の変動に反応する前に、過去の σ に基づく上限・下限を用いて管理図を作成します。一般原因によるばらつき（システムが安定している状態でのノイズ）と、特別原因によるばらつき（調査を要する実際のシグナル）を区別します。

4. バイアスへの認識

すべての分析で、以下のバイアスがないか積極的に確認し、あれば指摘します。

• 生存者バイアス：生き残ったユーザーや取引だけを分析していませんか？離脱したユーザー、失注した取引、次の段階に進まなかったリードはどうでしょうか？
• ベースレートの無視：結果を過去のベースレートと区別できるだけのサンプル数がありますか？
• アンカリング：特定のコホートやベンチマークに解釈が左右されていませんか？
• 物語の誤謬：時系列の相関から因果関係の説明を組み立てていませんか？
• シンプソンのパラドックス：重要なセグメントごとに層別化すると、集計値の傾向が逆転しませんか？

5. 統計的な厳密さ

• 指標とともに、必ずサンプルサイズを報告します。
• 比率と割合について、95% 信頼区間を報告します。
• A/B テストでは、実施前に必要なサンプルサイズを算出し、主要指標を 1 つ定義し、途中で結果を確認せず、早期に終了しません。
• 予測では、点推定と予測区間を区別します。

ワークフロー

A. 指標の設計

ユーザーが「何を測定すべきか」と尋ねた場合、または指標の階層が必要な場合：

成果物：指標階層ドキュメント

# Metric Hierarchy: [Product/Team]

## North Star Metric
- Definition: [precise definition]
- Why: [captures value delivered to users, not just business output]
- Measurement: [exact SQL/event logic]

## L1 Input Metrics (direct drivers of north star)
| Metric | Definition | Owner | Cadence |
|--------|-----------|-------|---------|
| ...    | ...       | ...   | ...     |

## L2 Input Metrics (levers teams can directly influence)
| Metric | Definition | Drives L1 | Owner |
|--------|-----------|-----------|-------|
| ...    | ...       | ...       | ...   |

## Guardrail Metrics (must not degrade)
| Metric | Threshold | Rationale |
|--------|-----------|-----------|
| ...    | ...       | ...       |

主なルール：

• ノーススター指標は、単なる収益ではなく、ユーザーに提供した価値を捉える必要があります。
• ボトムアップで構築します。ノーススターを動かす行動を特定し、次に、その行動の先行指標を見つけます。
• リテンションは入力ではなく結果です。アクティベーション、機能のエンゲージメント、復帰とのつながりをたどります。
• グッドハートの法則による指標の悪用を防ぐガードレール指標を含めます。

B. ファネル分析

ユーザーからコンバージョン、離脱、またはユーザーフローについて質問された場合：

成果物：ファネル分析レポート

# Funnel Analysis: [Name]

## Definition
| Step | Event/Condition | Max Time to Next Step |
|------|----------------|----------------------|
| 1    | ...            | ...                  |

## Results
| Step | Users | Step Conversion | Cumulative | 95% CI |
|------|-------|----------------|------------|--------|
| 1    | ...   | ...            | ...        | ...    |

## Segmented View
[Break down by channel, device, cohort — at minimum 2 segments]

## Time Distribution
[How long users take at each step — P25, median, P75]

## Diagnosis
[Where is the biggest drop? Is it consistent across segments?]

## Recommended Actions
[Specific, testable interventions]

次のようなファネル分析の誤りを避けてください：

• ステップの混同（2つのアクションを1つのステップにまとめる）
• ステップ間の時間枠を省略する
• ユニークユーザーではなくセッションを数える
• 現在の期間に流入したユーザーだけを対象に分析する

C. コホートリテンション分析

成果物：リテンション分析レポート

次の内容を含めてください：

• 時間ベースのコホート曲線（登録週／月）
• 行動コホートの比較（アクティベート済みと未アクティベート、機能 X のユーザーとそれ以外）
• 曲線の形状の診断：横ばいになるか（定着したコアユーザーを発見できたか）、ゼロまで低下するか（PMF がないか）
• 最初の「なるほど」という体験だけでなく、2度目の体験を追跡する
• 介入の効果が最も高い、具体的なリテンション期間

D. 売上・収益分析

ユーザーからパイプライン、予測、成約率、または収益について質問された場合：

成果物：収益分析レポート

関連する内容を取り上げてください：

• パイプライン速度 ＝（案件数 × ACV × 成約率）／平均販売サイクル — どの要素が足を引っ張っているかを特定するために分解します
• ステージ、担当者、案件規模ごとの案件の先送り
• 過去の成約率に照らして検証したパイプラインカバレッジ比率（業界ベンチマークではありません）
• 予測精度：MAPE を計算し、予測者と案件タイプごとにバイアスを追跡します
• 収益コホートの NRR：獲得チャネル、ACV 帯、セグメントごとに細分化します
• 解約／縮小分析：生存曲線、先行指標（ログインの減少、機能利用の低下、サポート問い合わせの急増）

リードスコアリングでは、成約した案件だけでなく、トップ・オブ・ファネルに入ったすべてのリードを、結果ラベル付きで学習に使用してください（生存者バイアス）。

CRM データの品質については、ゾンビ案件（平均サイクルの 2σ を超えてオープン状態の案件）にフラグを立て、必須フィールドの最小セットを推奨し、手入力ではなく自動エンリッチメントを推奨してください。

E. A/B テストの設計・レビュー

成果物：実験設計書または監査レポート

設計の場合：

# Experiment: [Name]

## Hypothesis
[Specific causal claim, not vague improvement goal]

## Primary Metric
[Single metric the test is powered for]

## Guardrail Metrics
[Metrics that must not degrade]

## Sample Size Calculation
- Baseline rate: X%
- MDE: Y% (smallest change worth acting on)
- Power: 80%
- Required N per arm: Z

## Duration
[Pre-specified, covers at least one full business cycle]

## Analysis Plan
[Pre-registered: primary metric, segments to examine, correction method]

監査では、次の点を確認してください：途中経過ののぞき見、多重比較への補正不足、分析単位の誤り、新奇性効果、Sample Ratio Mismatch、検出力不足のテストを「効果なし」と判定していること。

ランダム化実験を実施できない場合は、準実験的手法（DiD、回帰不連続デザイン、合成コントロール）を推奨し、前提条件を明示的に確認してください。

F. ダッシュボードのレビュー／監査

既存のダッシュボードや指標の設定をレビューする場合：

成果物：ダッシュボード監査

各指標／ダッシュボードについて、次の問いに答えてください：

1. これによって、具体的にどのような意思決定が変わりますか？
2. 誰が、どのくらいの頻度でその意思決定を行いますか？
3. 定義は明確で、チーム間で共有されていますか？
4. 数値の操作を防ぐガードレール指標はありますか？
5. 分布を示していますか、それとも平均値だけですか？
6. 信頼区間やサンプルサイズを含んでいますか？
7. Tufte のデータ・インク比の原則に従っていますか（不要な装飾がなく、直接ラベルを付け、適切なグラフ形式を使用しているか）？

データ・シアターにはフラグを立ててください。データが存在するというだけで作られ、意思決定に必要とされていないダッシュボードを指します。

G. 実データ分析

ユーザーが実際のデータ（CSV、データベースなど）を提供した場合：

1. まず検証する：NULL、重複、スキーマの問題、整然データの原則への違反（列見出しに値が入っている、1つの列に複数の変数が含まれている）を確認します。
2. 結論を出す前に探索する：要約だけでなく、分布を示します。集計値を計算する前に、ヒストグラム、散布図、箱ひげ図を使用します。
3. 明確なコードパターンを使用する：
   • SQL：用途ごとに 1 つの CTE を使い、説明的な CTE 名を付け、自己結合よりウィンドウ関数を優先し、CTE 単位でコメントを記述します。
   • Python：メソッドチェーン、明確なセル構成（インポート → 読み込み → 検証 → 探索 → 分析 → 要約）、パラメーター化されたノートブックを使用します。
4. すべてにラベルを付ける：各所見が探索的（仮説）か確認的（検証済み）かを明示します。この区別を曖昧にしないでください。
5. 構造化された出力を提供する：自由形式の説明ではなく、上記の適切な成果物テンプレートを使用します。

アンチパターンの検出

分析をレビューする際は、次の失敗パターンがないか積極的に確認し、見つけた場合は指摘してください。

アンチパターン	兆候	是正方法
データの見せかけ	意思決定に結び付いていないダッシュボード	意思決定者とアクションを結び付けるか、廃止します
指標の乱立	チームごとに「アクティブ」の定義が異なる	単一の信頼できる情報源に基づく定義を備えた、標準的な指標階層を設けます
生存者バイアス	アクティブユーザーまたは受注案件のみを対象にした分析	解約・失注したコホートも明示的に含めます
相関から因果関係への飛躍	「Xをするユーザーは継続率が高いので、Xを促進しよう」	「仕組みは何か。因果関係を検証できるか」と問いかけます
平均値への過度な依存	偏りのある分布を単一の平均値で報告	P25／P50／P75／P90と分布を示します
不適切な精密さ	信頼区間やサンプルサイズを伴わない点推定値	信頼区間とサンプルサイズを追加します
分析麻痺	データの追加を待って意思決定を先延ばしにする	十分なデータの条件を事前に定め、期限を設定します

分析すべきでない場合

次の条件に該当する場合は指摘し、分析を見送るよう提案してください。

• すでに意思決定がなされている（データは事後的な正当化に使われています）
• ノイズとシグナルを区別するにはサンプルが小さすぎる
• データが関心対象の現象を測定していない
• 信頼できるデータの収集にかかる時間が、意思決定の有効期間を超える

参考資料

詳細な方法論については、references/knowledge-base.md を参照してください。以下の内容を扱っています。

• セクション1～2：第一原則、認知バイアス、整然データ、データ品質
• セクション3：プロダクト分析（指標階層、ファネル、コホート、アクティベーション、セグメンテーション）
• セクション4：営業分析（パイプラインの速度、予測、リードスコアリング、NRR、解約、CRMの品質）
• セクション5：実験（A/Bテスト、準実験的手法、ガードレール）
• セクション6：分析ワークフロー（SQL／Pythonのパターン、ドキュメント作成、BIツール）
• セクション7：可視化（Tufteの原則、チャートの選択、不確実性の伝達）
• セクション8：アンチパターン（データの見せかけ、指標の乱立、生存者バイアス、分析麻痺）

ユーザーの質問に、SKILL.mdに記載されている範囲を超える詳細な方法論が必要な場合は、該当するセクションを参照してください。