okr-design

OKR 設計とメトリクスのフレームワーク

目標を構成し、メトリクスを KPI ツリーに分解し、先行指標を特定して、厳密な実験を設計します。

OKR の構成

目標（Objective）は定性的で、人々を鼓舞するものです。主要な結果（Key Result）は定量的で、成果に焦点を当てます。アウトプットのリストにしてはいけません。

Objective: Qualitative, inspiring goal (70% achievable stretch)
+-- Key Result 1: [Verb] [metric] from [baseline] to [target]
+-- Key Result 2: [Verb] [metric] from [baseline] to [target]
+-- Key Result 3: [Verb] [metric] from [baseline] to [target]

## Q1 OKRs

### Objective: Become the go-to platform for enterprise teams

Key Results:
- KR1: Increase enterprise NPS from 32 to 50
- KR2: Reduce time-to-value from 14 days to 3 days
- KR3: Achieve 95% feature adoption in first 30 days of onboarding
- KR4: Win 5 competitive displacements from [Competitor]

OKR の品質チェック

チェック項目	目標（Objective）	主要な結果（Key Result）
数値が含まれている	いいえ	はい
人々を鼓舞し、意欲を高める	はい	必須ではない
成果に焦点を当てている（「機能 X をリリースする」ではない）	はい	はい
70% 達成可能である（意欲的だが、目標を低く設定していない）	はい	はい
上位の目標と整合している	はい	はい

詳細なファシリテーションのアジェンダ（3～4 時間、ドット投票、最終決定用テンプレート）については、references/okr-workshop-guide.md を参照してください。 よくある落とし穴と整合性を段階的に高めるパターンについては、rules/metrics-okr.md を参照してください。

---

KPI ツリーとノーススターメトリクス

最上位のメトリクスを、明確な因果関係を持つ要素に分解します。

Revenue (Lagging — root)
├── New Revenue = Leads × Conv Rate          (Leading)
├── Expansion   = Users × Upsell Rate        (Leading)
└── Retained    = Existing × (1 - Churn)     (Lagging)

ノーススターメトリクスとインプットメトリクスのテンプレート

## Metrics Framework

North Star: [One metric that captures core value — e.g., Weekly Active Teams]

Input Metrics (leading, actionable by teams):
1. New signups — acquisition
2. Onboarding completion rate — activation
3. Features used per user/week — engagement
4. Invite rate — virality
5. Upgrade rate — monetization

Lagging Validation (confirm inputs translate to value):
- Revenue growth
- Net retention rate
- Customer lifetime value

ビジネスタイプ別のノーススターメトリクスの選定

ビジネス	ノーススターメトリクスの例	理由
SaaS	週間アクティブユーザー数	継続的な価値提供を示します
マーケットプレイス	流通取引総額	買い手と売り手の両方を捉えます
メディア	利用時間	エンゲージメントからコンテンツの価値が分かります
E コマース	購入頻度	リピート購入は満足度を示します

収益とプロダクトの健全性に関する KPI ツリーの詳細な例については、rules/metrics-kpi-trees.md を参照してください。

---

先行指標と遅行指標

改善したい遅行指標ごとに、先行予測指標を 2～3 個設定する必要があります。

## Metric Pairs

Lagging: Customer Churn Rate
Leading:
  1. Product usage frequency (weekly)
  2. Support ticket severity (daily)
  3. NPS score trend (monthly)

Lagging: Revenue Growth
Leading:
  1. Pipeline value (weekly)
  2. Demo-to-trial conversion (weekly)
  3. Feature adoption rate (weekly)

指標	レビュー頻度	対応のタイムライン
先行指標	毎日／毎週	直ちに軌道修正
遅行指標	毎月／四半期ごと	戦略的な調整

バランスの取れたダッシュボードのテンプレートについては、rules/metrics-leading-lagging.md を参照してください。

---

メトリクスの計測設定

計測を設定する前に、すべてのメトリクスを正式に定義する必要があります。

## Metric: Feature Adoption Rate

Definition: % of active users who used [feature] at least once in their first 30 days.
Formula: (Users who triggered feature_activated in first 30 days) / (Users who signed up)
Data Source: Analytics — feature_activated event
Segments: By plan tier, by signup cohort
Calculation: Daily
Review: Weekly

Events:
  user_signed_up  { user_id, plan_tier, signup_source }
  feature_activated { user_id, feature_name, activation_method }

イベントの命名規則：スネークケースの object_action。例：user_signed_up、feature_activated、subscription_upgraded。

メトリクス定義の完全なテンプレート、アラートのしきい値、ダッシュボード設計の原則については、rules/metrics-instrumentation.md を参照してください。

---

実験の設計

すべての実験で、開始前にガードレールメトリクスを定義する必要があります。ガードレールにより、隠れた損害を引き起こす「成功」のリリースを防げます。

## Experiment: [Name]

### Hypothesis
If we [change], then [primary metric] will [direction] by [amount]
because [reasoning based on evidence].

### Metrics
- Primary: [The metric you are trying to move]
- Secondary: [Supporting context metrics]
- Guardrails: [Metrics that MUST NOT degrade — define thresholds]

### Design
- Type: A/B test | multivariate | feature flag rollout
- Sample size: [N per variant — calculated for statistical power]
- Duration: [Minimum weeks to reach significance]

### Rollout Plan
1. 10% — 1 week canary, monitor guardrails daily
2. 50% — 2 weeks, confirm statistical significance
3. 100% — full rollout with continued monitoring

### Kill Criteria
Any guardrail degrades > [threshold]% relative to baseline.

開始前のチェックリスト

• 期待する効果量を含む仮説を文書化した
• 主要指標、副次指標、ガードレールメトリクスを定義した
• 検出可能な最小効果量に基づいてサンプルサイズを算出した
• ガードレールメトリクス用のダッシュボードまたはアラートを設定した
• 各段階の停止基準を含む段階的なロールアウト計画を立てた
• ロールバック手順を文書化した

ガードレールのしきい値、パフォーマンスおよびビジネスのガードレール表、アラートの SLA については、rules/metrics-experiment-design.md を参照してください。

---

よくある落とし穴

落とし穴	対策
KR がアウトプットになっている（「機能を 5 つリリースする」）	成果に書き換える（「コンバージョンを 20% 増加させる」）
遅行指標だけを追跡している	すべての遅行指標に先行予測指標を 2～3 個組み合わせる
目標を設定する前にベースラインを確認していない	OKR の設定前に、2 週間にわたって計測・測定する
ガードレールなしで実験を開始している	コードをリリースする前にガードレールを定義する
OKR が多すぎる（チームあたり 5 件超）	目標を 3～5 件、それぞれの KR を 3～5 件に制限する
メトリクスにオーナーがいない	すべてのメトリクスにチームのオーナーを設定する

---

関連スキル

• prioritization — RICE、WSJF、ICE、MoSCoW によるスコアリング。OKR では、RICE のインパクトを左右する KPI を定義します
• product-frameworks — PM 向けの総合ツールキット：価値提案、競合分析、ユーザー調査、ビジネスケース
• product-analytics — OKR ツリーで定義した指標を計測し、クエリを実行します
• write-prd — 成功指標と実験仮説をプロダクト要件に組み込みます
• market-sizing — ノーススターメトリックの目標値の基準となる TAM／SAM／SOM
• competitive-analysis — KR の目標値を決める際に参考となる競合ベンチマーク

---

バージョン： 1.0.0