prioritization-advisor

目的

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

これはスコア計算ツールではありません。お客様固有の状況に合った優先順位付けフレームワークを選ぶための判断ガイドです。

入力

特に役立つ情報： 優先順位を付けたいものと、今それを行う理由（スプリント計画、ロードマップ、ステークホルダー間の対立など）。 あると役立つ情報： プロダクトの段階、チームの規模、データの有無、試したもののうまくいかなかったフレームワーク。

このスキルの呼び出し時に渡された内容（スキル名の後に続くテキスト、貼り付けられたコンテキスト、または追加された ARGUMENTS: 行）は、すでに回答済みの情報として扱います。その情報を使用し、該当する質問は繰り返しません。

何も用意していなくても大丈夫です。 アドバイザーが、プロダクトの段階と、フレームワークを使ってどのような意思決定を行いたいのかを尋ねるところから始めます。

呼び出し例： フレームワーク選びを手伝ってください。シード段階の B2B スタートアップで、バックログは 40 項目、利用データはゼロ、声の大きいエンタープライズ見込み顧客がいます。

主な概念

優先順位付けフレームワークの全体像

一般的なフレームワークとその用途：

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

• RICE（リーチ、インパクト、確信度、工数）— データに基づく評価。指標が必要です
• ICE（インパクト、確信度、容易さ）— 手軽な直感チェック型のスコアリング
• 価値対工数（2x2 マトリクス）— すぐに得られる成果と戦略的な賭けを区分します
• 加重スコアリング — ステークホルダーの意見を取り入れた独自の評価基準

戦略的フレームワーク：

• Kano モデル — 顧客満足への貢献によって機能を分類します（基本、性能、魅力）
• オポチュニティスコアリング — 重要度と満足度のギャップを評価します
• Buy-a-Feature — 顧客が予算を配分する演習です
• MoSCoW（Must、Should、Could、Won't）— 難しい選択を迫る手法です

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

• 遅延コスト — 緊急性に基づきます（時間制約のある機能）
• インパクトマッピング — 目標主導型です（機能と成果を結び付けます）
• ストーリーマッピング — ユーザージャーニーに基づきます（ストーリーの流れ）

この方法が有効な理由

• 状況を考慮： プロダクトの段階、チームの成熟度、データの有無に応じてフレームワークを選びます
• 独善的な判断を避ける： 唯一の「最良」のフレームワークはありません。状況によって適切なものは異なります
• 実行に移しやすい： フレームワーク名だけでなく、実践手順も提示します

アンチパターン（このツールが行わないこと）

• 万能のランキングではありません： フレームワークに「優劣」はありません。状況に応じて適合するものが異なります
• 戦略の代わりにはなりません： フレームワークは戦略を実行するためのものであり、戦略を生み出すものではありません
• 一度設定したら終わりではありません： プロダクトの成熟に応じてフレームワークを見直します

このツールを使う場面

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

このツールを使わない場面

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

---

ファシリテーションの準拠ルール

このスキルでは、デフォルトの対話プロトコルとして workshop-facilitation を使用してください。

このプロトコルでは、以下を定義します。

• セッション開始時の案内と進行モード（Guided、Context dump、Best guess）
• 平易な言葉で尋ねる、一度に一つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 割り込みへの対応と一時停止・再開の動作
• 意思決定の要所で番号付きの推奨事項を提示すること
• 通常の質問では番号付きのクイック選択肢を提示すること（役立つ場合は Other (specify) を含めます）

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

アプリケーション

この対話形式のスキルでは、各ステップで3～4個の番号付き選択肢を提示しながら、状況に応じた質問を最大4つ行います。

---

質問1：製品の段階

エージェントの質問： 「製品はどの段階にありますか？」

番号付きの選択肢を4つ提示します：

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

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

ユーザーの回答：［選択肢または自由記述］

---

質問2：チームの状況

エージェントの質問： 「チームやステークホルダーの環境について教えてください。」

番号付きの選択肢を4つ提示します：

1. 小規模チーム、限られたリソース — 「エンジニア3～5人、プロダクトマネージャー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 名、PM 1 名」

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

Q4 の回答：「データは最小限です — 新しいプロダクトで、利用状況の指標はありません」

---

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

RICE が不適切な理由：

• リーチを推定するための利用データがありません
• PMF 前に必要なのは厳密なスコアリングではなく、スピードです
• 小規模チームにとって、RICE のスコアリングに伴う負担は大きすぎます

代わりに ICE を使う理由：

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

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

• 視覚的な 2×2 マトリックスです（高価値／低労力＝すぐに成果を得られる施策）
• ICE よりさらに迅速です
• ステークホルダー間の認識合わせに適しています（視覚的で直感的です）

---

よくある落とし穴

落とし穴 1：自分たちのステージに合わないフレームワークを使う

症状： PMF 前のスタートアップが 10 項目の基準で重み付けスコアリングを行っている

結果： 負担によってスピードが損なわれます。必要なのは実験であり、厳密なスコアリングではありません。

対策： ステージに合ったフレームワークを選びます。PMF 前は ICE または価値／労力、拡大期は RICE、成熟期は機会スコアリングまたは Kano モデルを使います。

---

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

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

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

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

---

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

症状：「機能 A のスコアは 8,000、機能 B のスコアは 7,999 なので、A が勝ちです」

結果： 戦略的な状況や判断、ビジョンが考慮されません。

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

---

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

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

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

対策： 共同でスコアリングする場を設けます。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）— 顧客満足度フレームワーク

Dean の著作

• [Dean に優先順位付けに関する資料があれば、ここにリンクします]

---

スキルの種類： インタラクティブ 推奨ファイル名： prioritization-advisor.md 推奨配置場所： /skills/interactive/ 依存関係： なし（単独で使用できますが、ロードマップやバックログの判断に役立ちます）