prioritization-advisor

目的

プロダクトマネージャーが、プロダクトの段階、チームの状況、意思決定のニーズ、ステークホルダー間の力学について適応的な質問に答えることで、適切な優先順位付けフレームワークを選べるよう支援します。これにより、「フレームワークの迷走」（フレームワークを頻繁に切り替えること）や、誤ったフレームワークの適用（例：戦略的な賭けに RICE を使う、データに基づく意思決定に ICE を使う）を防ぎます。状況に合わせた推奨フレームワークと導入手順を提示します。

これはスコア計算ツールではありません。特定の状況に合った優先順位付けフレームワークを選ぶための意思決定ガイドです。

主な概念

優先順位付けフレームワークの概要

一般的なフレームワークとその使用場面：

スコアリングフレームワーク：

• RICE（リーチ、インパクト、確信度、工数）— データに基づき、指標が必要
• ICE（インパクト、確信度、容易さ）— 手軽な直感ベースのスコアリング
• Value vs. Effort（2x2 マトリクス）— すぐに実現できる成果と戦略的な賭け
• Weighted Scoring — ステークホルダーの意見を取り入れた独自の評価基準

戦略的フレームワーク：

• Kano Model — 顧客の満足度に応じて機能を分類（基本、性能、魅力）
• Opportunity Scoring — 重要度と満足度のギャップを評価
• Buy-a-Feature — 顧客が予算を配分する演習
• Moscow（Must、Should、Could、Won't）— 難しい選択を迫る手法

状況に応じたフレームワーク：

• Cost of Delay — 緊急性に基づく（時間的制約のある機能）
• Impact Mapping — 目標主導（機能と成果を結び付ける）
• Story Mapping — ユーザージャーニーに基づく（ストーリーの流れ）

効果がある理由

• 状況を考慮： プロダクトの段階、チームの成熟度、データの利用可能性に合わせてフレームワークを選びます
• 独断を避ける： 唯一の「最良」のフレームワークはありません。状況によって適切なものは異なります
• 実践的： フレームワーク名だけでなく、導入手順を提示します

アンチパターン（該当しないもの）

• 普遍的な順位付けではありません： フレームワークに「優劣」はなく、状況によって適したものが異なります
• 戦略の代わりではありません： フレームワークは戦略を実行するものであり、戦略を生み出すものではありません
• 一度決めたら終わりではありません： プロダクトの成熟に合わせてフレームワークを見直してください

使用する場面

• 初めて優先順位付けフレームワークを選ぶとき
• フレームワークを切り替えるとき（現在のものがうまく機能していない場合）
• 優先順位付けのプロセスについてステークホルダー間の認識をそろえるとき
• 新しい PM にチームの慣行を説明するとき

使用しない場面

• すでに機能しているフレームワークがあるとき（壊れていないものを直す必要はありません）
• 単発の意思決定を行うとき（フレームワークは繰り返し行う優先順位付けに使います）
• 戦略的ビジョンの代用として使うとき（フレームワークでは、何を構築するかは決められません）

---

ファシリテーションプロトコル

次の対話プロトコルに従い、ガイド付きの会話としてこのスキルを実行します：

• まず一行で概要を伝え、次に開始方法を提示します：ガイド付き（一度に質問を1つずつ）、コンテキストをまとめて提示（ユーザーが最初にすべての情報を貼り付ける）、または 最善の推測（トピックだけをもとに進める）。
• 平易な言葉で、1ターンに1つの質問をします。次の質問をする前に回答を待ちます。複数の質問をまとめてはいけません。
• 各質問で進捗を示します（例：Context Qx/8、Scoring Qx/5）。
• 各質問には、番号付きの回答選択肢と推奨される既定の選択肢を提示します。必要に応じて Other (specify) を含めます。
• 会話の中断には柔軟に対応し、ユーザーが一時停止して再開できるようにします。
• 意思決定の場面では、単一の見解ではなく、番号付きの推奨案を提示します。

このファイルでは、分野固有の評価内容を定義します。競合がある場合は、このファイルに記載された分野固有のロジックに従ってください。

適用

この対話型スキルでは、最大4つの適応型質問を行い、各ステップで3～4個の番号付き選択肢を提示します。

---

質問 1：プロダクトの段階

エージェントの質問： 「プロダクトは現在どの段階にありますか？」

次の4つの選択肢を提示してください：

1. プロダクト・マーケット・フィット前 — 「PMF を模索中。迅速に実験を繰り返している。顧客が何を求めているか不明確」（不確実性が高く、スピードが必要）
2. 初期の PMF 達成後、拡大中 — 「初期の PMF を達成。急成長中。顧客の維持・拡大のために機能を追加している」（不確実性は中程度。スピードと品質のバランスが必要）
3. 成熟したプロダクト、最適化段階 — 「市場での地位を確立。段階的に改善している。品質や機能で競争している」（不確実性が低く、データに基づいて意思決定）
4. 複数のプロダクト／プラットフォーム — 「複数のプロダクトを展開。プロダクト間に依存関係がある。ステークホルダーのニーズが複雑」（調整が複雑）

または、プロダクトの段階（新しいアイデア、成長段階、確立済みなど）を説明してください。

ユーザーの回答： [選択または自由記述]

---

質問 2：チームの状況

エージェントの質問： 「チームやステークホルダーを取り巻く状況はどのようなものですか？」

次の4つの選択肢を提示してください：

1. 小規模チーム、リソースに限りがある — 「エンジニア3～5人、PM 1人。徹底して集中する必要がある」（シンプルで迅速なフレームワークが必要）
2. 部門横断チーム、足並みがそろっている — 「プロダクト、デザイン、エンジニアリングの連携が取れている。目標が明確で、協力体制も整っている」（データ主導のフレームワークを活用可能）
3. 複数のステークホルダー、意見が不一致 — 「経営幹部、営業、顧客がそれぞれ異なる意見を持っている。透明性のあるプロセスが必要」（合意形成のためのフレームワークが必要）
4. 大規模な組織、依存関係が複雑 — 「複数のチーム、共通のロードマップ、チーム間の依存関係がある」（調整のためのフレームワークが必要）

または、チームやステークホルダーを取り巻く状況を説明してください。

ユーザーの回答： [選択または自由記述]

---

質問 3：意思決定のニーズ

エージェントの質問： 「優先順位付けによって解決したい、主な課題は何ですか？」

次の4つの選択肢を提示してください：

1. アイデアが多すぎて、どれに取り組むべきか不明確 — 「バックログに100件以上の項目がある。上位10件に絞る必要がある」（絞り込みのためのフレームワークが必要）
2. ステークホルダー間で優先順位について意見が一致しない — 「営業は機能、経営幹部は戦略的な投資、エンジニアリングは技術的負債の解消を望んでいる」（足並みをそろえるためのフレームワークが必要）
3. データに基づく意思決定ができていない — 「勘で優先順位を決めている。指標に基づくプロセスが必要」（スコアリングのためのフレームワークが必要）
4. 戦略的な投資と短期的な成果の間で、適切な取捨選択が難しい — 「長期的なビジョンと短期的な顧客ニーズのバランスを取っている」（価値と工数を考慮するフレームワークが必要）

または、具体的な課題を説明してください。

ユーザーの回答： [選択または自由記述]

---

質問 4：データの利用可能性

エージェントの質問： 「優先順位付けに役立つデータはどの程度ありますか？」

次の3つの選択肢を提示してください：

1. データがほとんどない — 「新しいプロダクトで、利用状況の指標がなく、調査できる顧客も少ない」（勘に基づくフレームワーク）
2. ある程度のデータがある — 「基本的な分析データと顧客からのフィードバックはあるが、厳密なデータ収集は行っていない」（軽量なスコアリングフレームワーク）
3. 豊富なデータがある — 「利用状況の指標、A/Bテスト、顧客調査、明確な成功指標がある」（データ主導のフレームワーク）

または、データの状況を説明してください。

ユーザーの回答： [選択または自由記述]

---

出力：優先順位付けフレームワークの推奨

回答を収集した後、エージェントがフレームワークを推奨します：

# Prioritization Framework Recommendation

**Based on your context:**
- **Product Stage:** [From Q1]
- **Team Context:** [From Q2]
- **Decision-Making Need:** [From Q3]
- **Data Availability:** [From Q4]

---

## Recommended Framework: [Framework Name]

**Why this framework fits:**
- [Rationale 1 based on Q1-Q4]
- [Rationale 2]
- [Rationale 3]

**When to use it:**
- [Context where this framework excels]

**When NOT to use it:**
- [Limitations or contexts where it fails]

---

## How to Implement

### Step 1: [First implementation step]
- [Detailed guidance]
- [Example: "Define scoring criteria: Reach, Impact, Confidence, Effort"]

### Step 2: [Second step]
- [Detailed guidance]
- [Example: "Score each feature on 1-10 scale"]

### Step 3: [Third step]
- [Detailed guidance]
- [Example: "Calculate RICE score: (Reach × Impact × Confidence) / Effort"]

### Step 4: [Fourth step]
- [Detailed guidance]
- [Example: "Rank by score; review top 10 with stakeholders"]

---

## Example Scoring Template

[Provide a concrete example of how to use the framework]

**Example (if RICE):**

| Feature | Reach (users/month) | Impact (1-3) | Confidence (%) | Effort (person-months) | RICE Score |
|---------|---------------------|--------------|----------------|------------------------|------------|
| Feature A | 10,000 | 3 (massive) | 80% | 2 | 12,000 |
| Feature B | 5,000 | 2 (high) | 70% | 1 | 7,000 |
| Feature C | 2,000 | 1 (medium) | 50% | 0.5 | 2,000 |

**Priority:** Feature A > Feature B > Feature C

---

## Alternative Framework (Second Choice)

**If the recommended framework doesn't fit, consider:** [Alternative framework name]

**Why this might work:**
- [Rationale]

**Tradeoffs:**
- [What you gain vs. what you lose]

---

## Common Pitfalls with This Framework

1. **[Pitfall 1]** — [Description and how to avoid]
2. **[Pitfall 2]** — [Description and how to avoid]
3. **[Pitfall 3]** — [Description and how to avoid]

---

## Reassess When

- Product stage changes (e.g., PMF → scaling)
- Team grows or reorganizes
- Stakeholder dynamics shift
- Current framework feels broken (e.g., too slow, ignoring important factors)

---

**Would you like implementation templates or examples for this framework?**

---

例

例1：適切なフレームワークの選択（PMF 初期、RICE）

Q1 の回答：「PMF 初期、拡大期 — 初期の PMF を達成し、急成長中です。ユーザーの維持・拡大に向けて機能を追加しています」

Q2 の回答：「部門横断チームで連携 — プロダクト、デザイン、エンジニアリングが連携し、目標が明確です」

Q3 の回答：「データに基づく意思決定の不足 — 直感で優先順位を決めているため、指標に基づくプロセスを求めています」

Q4 の回答：「データは一部あります — 基本的な分析データや顧客からのフィードバックはありますが、厳密なデータ収集は行っていません」

---

推奨フレームワーク：RICE（リーチ、インパクト、確信度、工数）

適している理由：

• 分析データや顧客からのフィードバックがあるため、リーチとインパクトを見積もれます
• 部門横断チームの連携が取れているため、評価基準について合意できます
• 直感頼みからデータに基づく方法へ移行するにあたり、RICE は複雑になりすぎずに枠組みを提供します
• PMF 初期段階ではスピードが必要ですが、維持・拡大に向けてインパクトの大きい機能の優先順位付けも必要です

使用する場面：

• 四半期または月次のロードマップ計画
• バックログが 20～30 項目を超える場合
• 関係者間で優先順位について意見が分かれる場合

使用しない場面：

• 複数四半期にわたる戦略的な施策（RICE は漸進的な成果を優先します）
• 基本的な指標がない場合（リーチの算出には利用データが必要です）
• 単一機能の判断（過剰です）

---

導入方法：

ステップ1：評価基準を定義する

• リーチ： この機能は、月または四半期あたり何人のユーザーに影響しますか？
• インパクト： ユーザー体験をどの程度改善しますか？（1 = 最小、2 = 大きい、3 = 非常に大きい）
• 確信度： リーチとインパクトの見積もりに、どの程度の確信がありますか？（50% = データが少ない、80% = 十分なデータ、100% = 確実）
• 工数： 開発には何人月かかりますか？（デザイン、エンジニアリング、QA を含めます）

ステップ2：各機能を評価する

• スプレッドシートまたは Airtable を使用します
• 評価には PM、デザイン、エンジニアリングが参加します（PM だけで行わないでください）
• 確信度は正直に評価します（スコアを水増ししないでください）

ステップ3：RICE スコアを計算する

• 数式：(Reach × Impact × Confidence) / Effort
• スコアが高いほど、優先度が高くなります

ステップ4：確認して調整する

• RICE スコア順に並べ替えます
• 上位 10～20 項目を関係者と確認します
• 戦略上の優先事項に合わせて調整します（RICE ですべてを捉えられるわけではありません）

---

評価例：

機能	リーチ	インパクト	確信度	工数	RICE スコア
メールリマインダー	5,000	2	70%	1	7,000
モバイルアプリ	10,000	3	60%	6	3,000
ダークモード	8,000	1	90%	0.5	14,400

優先順位： ダークモード > メールリマインダー > モバイルアプリ（モバイルアプリはリーチとインパクトが大きいものの、工数がかかりすぎます）

---

代替フレームワーク：ICE（インパクト、確信度、容易さ）

適している可能性がある理由：

• RICE よりシンプルです（リーチの算出が不要です）
• 評価が速く済みます（迅速な判断が必要な場合に適しています）

トレードオフ：

• データに基づく度合いが低くなります（リーチ指標がないため、異なるユーザー層に影響する機能を比較できません）
• より主観的になります（インパクトと容易さは指標ではなく、直感に基づきます）

---

よくある落とし穴：

1. 工数を重視しすぎる — スコアが低いという理由だけで、難しい課題を避けないでください。戦略的な施策には大きな工数が必要な場合があります。
2. 確信度を水増しする — 正直に評価してください。データが少ない場合、確信度が 50% でも問題ありません。
3. 戦略を無視する — RICE では戦略上の重要性を捉えられません。ビジョンや目標に合わせて調整してください。

---

例2：フレームワークの選択ミス（PMF 達成前に RICE を使う＝不適切な選択）

Q1 の回答：「プロダクト／マーケットフィット達成前 — PMF を模索中で、迅速に実験しています」

Q2 の回答：「小規模チームで、リソースが限られています — エンジニア3名、PM1名」

Q3 の回答：「アイデアが多すぎて、どれに取り組むべきか不明確です」

Q4 の回答：「データがほとんどありません — 新しいプロダクトで、利用状況の指標がありません」

---

おすすめのフレームワーク：ICE（インパクト、確信度、容易さ）または価値／労力マトリクス

RICE が不適切な理由：

• リーチを見積もるための利用データがありません
• PMF 達成前は、厳密なスコアリングよりスピードが必要です
• 小規模チームにとって、RICE スコアリングのオーバーヘッドは大きすぎます

代わりに ICE を使う理由：

• 軽量で、直感的に判断できるフレームワークです
• 30分で20個のアイデアをスコアリングできます
• 迅速な実験を行う段階に適しています

または価値／労力マトリクス：

• 視覚的な2×2マトリクスです（価値が高く、労力が少ないもの＝すぐに成果を出せるもの）
• ICE よりもさらに速く進められます
• ステークホルダー間の合意形成に適しています（視覚的で、直感的です）

---

よくある落とし穴

落とし穴1：段階に合わないフレームワークを使う

症状： PMF 達成前のスタートアップが、10個の基準を使った加重スコアリングを行う

結果： オーバーヘッドによってスピードが失われます。必要なのは厳密なスコアリングではなく、実験です。

対策： 段階に合ったフレームワークを選びます。PMF 達成前＝ICE または価値／労力。規模拡大期＝RICE。成熟期＝オポチュニティスコアリングまたはカノモデル。

---

落とし穴2：フレームワークを頻繁に切り替える

症状： 四半期ごとにフレームワークを切り替える

結果： チームが混乱し、時間が無駄になり、一貫性が失われます。

対策： 1つのフレームワークを6〜12か月使い続けます。段階や状況が変わったときにのみ、見直します。

---

落とし穴3：スコアを絶対視する

症状：「機能Aのスコアは8,000で、機能Bは7,999だから、Aを採用します」

結果： 戦略的な背景、判断、ビジョンが無視されます。

対策： フレームワークは判断材料として使い、自動化の手段にはしません。必要に応じて、PM の判断をスコアより優先します。

---

落とし穴4：PM が一人でスコアリングする

症状： PM が機能を一人でスコアリングし、その結果をチームに提示する

結果： チームの賛同が得られず、エンジニアリングやデザインの担当者がスコアを信頼しません。

対策： PM、デザイン、エンジニアリングが一緒にスコアリングする、協働型のセッションを行います。

---

落とし穴5：フレームワークをまったく使わない

症状：「一番大きな声を上げた人の意見で優先順位を決めています」

結果： データや戦略ではなく、HiPPO（最も報酬の高い人の意見）が優先されます。

対策： どのフレームワークでもよいので選びます。不完全な仕組みでも、混乱よりは効果的です。

---

参考資料

関連スキル

• user-story.md — 優先順位付けされた機能をユーザーストーリーにします
• epic-hypothesis.md — 優先順位付けされたエピックを実験で検証します
• recommendation-canvas.md — ビジネス成果を優先順位付けに活用します

外部フレームワーク

• Intercom、RICE Prioritization（2016）— RICE フレームワークの起源
• Sean McBride、ICE Scoring（2012）— 軽量な優先順位付け
• Luke Hohmann、Innovation Games（2006）— Buy-a-Feature などの協働型手法
• Noriaki Kano、Kano Model（1984）— 顧客満足度のフレームワーク 依存関係： なし（単独で使用できますが、ロードマップとバックログの判断に役立ちます）