機能の優先順位付けとロードマップ

バックログという名のカオス

機能リクエストが50件。エンジニアリングリソースは3人月。何を作る？ 「全部重要」は答えにならない。

🔄 Quick Recall: 前回のレッスンで、PRDと機能仕様書の作成方法を学んだ。「何を作るか」が明確になった。今回は「何を先に作るか」——優先順位付けとロードマップの構築。

RICEフレームワーク

最も広く使われている優先順位フレームワーク：

RICE Score = (Reach × Impact × Confidence) / Effort

以下の機能候補リストをRICEフレームワークで
スコアリングして：

[機能リストをペースト]

プロダクト：[プロダクト名]
月間アクティブユーザー：[数]
エンジニアリングチーム：[人数]

各機能について：
1. Reach（四半期でどれだけのユーザーに影響するか）
2. Impact（0.25〜3のスケールで）
3. Confidence（100%/80%/50%）
4. Effort（人月）
5. RICEスコア
6. スコアの根拠（なぜこの見積もりか）

※Confidenceが50%以下の項目は追加調査が必要な領域として注記。

✅ Quick Check: 自分のバックログから5つの機能を選び、RICEスコアを出してみよう。直感の順位とスコアの順位は一致する？ 一致しない場合、なぜ？

ICEフレームワーク

RICEのシンプル版。スピードが必要なとき：

ICE Score = Impact × Confidence × Ease

RICEよりシンプルだが、Reachが含まれないため大規模プロダクトには不向き。

フレームワークの限界と判断

フレームワークがカバーしないもの：

フレームワークは判断の「出発点」。これらの要素を考慮した「人間の判断」が最終的な優先順位を決める。

ロードマップの構築

以下のRICEスコアと戦略的考慮に基づいて、
四半期ロードマップのドラフトを作成して：

機能リスト（スコア付き）：
[RICEスコアのリスト]

戦略的考慮：
[オーバーライドする理由があれば記載]

チームリソース：[人月]

ロードマップの形式：
- Now（今四半期）：[リソースの60%]
- Next（次四半期）：[リソースの30%]
- Later（将来）：[リソースの10%]

各機能について：
- タイムラインの根拠
- 依存関係（他の機能との順序制約）
- リスクと軽減策

ステークホルダーへの優先順位の説明

「RICEスコアが高いから」では説得力がない。ストーリーで説明する：

以下の優先順位付け結果を、ステークホルダー向けの
説明に変換して：

[優先順位のリストと根拠]

ターゲット：[経営陣 / エンジニアリングリード / 営業]

説明の構成：
1. 我々が解決する課題（ユーザーの痛み）
2. なぜこの順序なのか（データとロジック）
3. 何をやらないか（トレードオフの明示）
4. 成功の測定方法

Key Takeaways

• RICEフレームワークの価値はスコアの精度ではなく、議論の質にある
• スコアを「答え」ではなく「会話の出発点」として使う
• フレームワークがカバーしない要素（戦略、タイミング、技術的負債、モラル）を意識する
• ロードマップはNow/Next/Laterのフレームワークで柔軟性を確保する
• 優先順位はデータとストーリーの両方で説明する

Up Next

レッスン5：競合分析とマーケットリサーチ——競合の動向を体系的に分析し、自社プロダクトの差別化と市場機会を特定する方法を学ぶ。