metrics-tree

メトリクスツリー

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Metrics Tree Progress:
- [ ] Step 1: Define North Star metric
- [ ] Step 2: Identify input metrics (L2)
- [ ] Step 3: Map action metrics (L3)
- [ ] Step 4: Select leading indicators
- [ ] Step 5: Prioritize and experiment
- [ ] Step 6: Validate and refine

ステップ 1：ノーススターメトリクスを定義する

情報が提供されていない場合は、ユーザーに背景を確認します。

• プロダクト／ビジネス：何を測定しますか？
• 現在のメトリクス：既存の主要メトリクスはありますか？
• 目標：成功とはどのような状態ですか？

次の基準でノーススターを選びます。

• 顧客に提供した価値を捉えている
• ビジネスモデル（収益の仕組み）を反映している
• 測定・追跡できる
• 実行可能である（チームが影響を与えられる）
• 虚栄のメトリクスではない

ビジネスモデル別のノーススターの例は、一般的なパターンを参照してください。

ステップ 2：入力メトリクス（L2）を特定する

ノーススターを、直接的な要因となる 3～5 個の指標に分解します。

• ノーススターを増加させる直接的な要因は何ですか？
• 加算または乗算による分解を使います
• 可能な限り、構成要素が相互に排他的になるようにします
• 各入力指標をチームが制御できるようにします

分解のフレームワークについては、resources/template.mdを参照してください。

ステップ 3：アクションメトリクス（L3）をマッピングする

各入力メトリクスについて、具体的なユーザー行動を特定します。

• どのような行動がこの入力指標を動かしますか？
• 測定可能で、観察可能な行動に焦点を当てます
• 入力指標ごとに、行動を 3～5 個に絞ります
• 行動はユーザーが制御できるものにします

複雑な場合は、複数レベルの階層についてresources/methodology.mdを参照してください。

ステップ 4：先行指標を選ぶ

ノーススターの変化を予測する早期シグナルを特定します。

• ノーススターが変化する前に、どのメトリクスが変化しますか？
• ファネルの早い段階にある行動（オンボーディング、アクティベーション）を探します
• 継続率の高いコホートに見られるパターンを見つけます
• 将来のノーススター値との相関を検証します

ステップ 5：優先順位を付けて実験する

次の基準で機会をランク付けします。

• 影響度：このメトリクスを動かすことで、ノーススターにどの程度影響しますか？
• 確信度：この関係性について、どの程度確信がありますか？
• 容易さ：このメトリクスを動かすのはどの程度難しいですか？

優先度の高い仮説を検証する実験を 1～3 件選びます。

品質基準については、resources/evaluators/rubric_metrics_tree.jsonを参照してください。

ステップ 6：検証して改善する

メトリクス間の関係を検証します。

• メトリクス間の相関の強さを確認します
• 因果の方向を検証します（A が B を引き起こすのか、その逆なのか）
• 先行指標のタイミングを検証します（どれくらい早く予測できるか）
• データと実験に基づいて改善します

一般的なパターン

ビジネスモデル別のノーススターメトリクス：

サブスクリプション／SaaS：

• 月次経常収益（MRR）
• 週間アクティブユーザー数（WAU）
• 純収益維持率（NRR）
• 有料ユーザーの増加

マーケットプレイス：

• 流通取引総額（GMV）
• 成功した取引数
• 完了した予約数
• プラットフォームのテイクレート × 取引量

Eコマース：

• 訪問者あたりの収益
• 注文頻度 × 平均注文額（AOV）
• 顧客生涯価値（LTV）

ソーシャル／コンテンツ：

• プラットフォームでの滞在時間
• 作成／消費されたコンテンツ
• エンゲージメントしたユーザー数（単なるアクティブユーザー数ではありません）
• ネットワーク密度

分解のパターン：

加算分解：

North Star = Component A + Component B + Component C

Example: WAU = New Users + Retained Users + Resurrected Users

• 使用する場面：構成要素が独立したセグメントである場合
• メリット：チームが個々の構成要素を担当できます

乗算分解：

North Star = Factor A × Factor B × Factor C

Example: Revenue = Users × Conversion Rate × Average Order Value

• 使用する場面：構成要素を掛け合わせる場合
• メリット：レバレッジポイントが明確になります

ファネル分解：

North Star = Step 1 → Step 2 → Step 3 → Final Conversion

Example: Paid Users = Signups × Activation × Trial Start × Trial Convert

• 使用する場面：順次進行するコンバージョンプロセスの場合
• メリット：ボトルネックを特定できます

コホート分解：

North Star = Σ (Cohort Size × Retention Rate) across all cohorts

Example: MAU = Sum of retained users from each signup cohort

• 使用する場面：継続率が主要な推進要因である場合
• メリット：獲得と継続を分けて把握できます

ガードレール

虚栄の指標を避ける：

• ❌ 登録ユーザーの総数（価値を反映しません）
• ❌ ページビュー数（エンゲージメントを示しません）
• ❌ アプリのダウンロード数（アクティブな利用を意味しません）
• ✓ アクティブユーザー数、エンゲージメント時間、完了した取引

因果関係を明確にする：

• 相関関係と因果関係を混同しないでください
• AがBを引き起こすのか、BがAを引き起こすのかを検証してください
• 交絡変数を考慮してください
• 実験で関係性を検証してください

ツリーの深さを制限する：

• 最大3〜4階層にとどめてください（North Star → L2 → L3 → L4）
• 深すぎると、分析が行き詰まります
• 浅すぎると、実行に移せません
• 最も効果の高い階層に注力してください

先行指標と遅行指標のバランスを取る：

• 全体像を把握するには両方が必要です
• 先行指標は早期の対応に役立ちます
• 遅行指標は検証に役立ちます
• 遅行指標を損なう先行指標を最適化しないでください

指標の操作を避ける：

• 意図しない結果を考慮してください
• チームがどのような行動で指標を操作する可能性があるでしょうか？
• ガードレール指標（品質、信頼、安全性）を追加してください
• 成長と継続率／満足度のバランスを取ってください

クイックリファレンス

リソース：

• resources/template.md - 分解フレームワークを含む指標ツリーの構造
• resources/methodology.md - 複雑な指標システムのための高度な手法
• resources/evaluators/rubric_metrics_tree.json - 指標ツリーの品質基準

出力：

• ファイル：現在のディレクトリにある metrics-tree.md
• 内容：North Starの定義、入力指標（L2）、アクション指標（L3）、先行指標、優先順位を付けた実験、指標関係図

成功基準：

• North Starが根拠とともに明確に定義されている
• North Starを完全に分解する入力指標が3〜5個ある
• アクション指標が具体的で、測定可能な行動を示している
• 先行指標が特定され、タイミングの見積もりが示されている
• 優先順位を付けた上位1〜3件の実験にICEスコアが付いている
• ルーブリックに照らして検証されている（スコア ≥ 3.5）

クイック判断フレームワーク：

• シンプルなプロダクトですか？ → template.mdを使い、2〜3階層にします
• 複雑なマルチサイド型ですか？ → methodology.mdを使い、各サイドに個別のツリーを作成します
• North Starが定まりませんか？ → 上記の一般的なパターンを確認し、「価値を捉え、収益を予測する」という基準で検証します
• 指標が多すぎますか？ → 各階層で3〜5個に制限し、最もインパクトの大きいものに注力します

よくある間違い：

1. 誤ったNorth Starを選ぶ：虚栄の指標や、チームが左右できない指標を選ぶ
2. 階層が多すぎる：分析が行き詰まり、実行可能性が失われる
3. 因果関係が弱い：指標同士は相関しているが、因果関係はない
4. トレードオフを無視する：ある指標の最適化が別の指標を損なう
5. 実験を行わない：ツリーを作っても、仮説を検証しない