roadmap-prioritization-planning

ロードマップと優先順位付けのスキル

「いいえ」と伝える技術を身につけましょう。組織の方向性をそろえ、戦略的な成果を推進し、限られたリソースでインパクトを最大化する、焦点の定まったロードマップを作成します。

RICE スコアリングシステム（完全版）

計算式

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

Reach: How many users affected? (1-100+)
- 10+ = 10
- 100+ = 100
- 1000+ = 1000

Impact: Per-user impact (3, 2, 1, 0.5)
- 3 = Massive (10x improvement)
- 2 = High (significant improvement)
- 1 = Medium (noticeable improvement)
- 0.5 = Low (minor improvement)

Confidence: How confident? (0.25-1.0)
- 1.0 = High (research backed)
- 0.8 = Medium (some validation)
- 0.5 = Low (minimal validation)
- 0.25 = Very low (assumption)

Effort: Engineer-weeks needed (1-20+)

スコアリング例のマトリックス

Feature          Reach Impact Confidence Effort RICE Score
────────────────────────────────────────────────────────
User Onboarding   50    3      0.8      8      (50×3×0.8)/8 = 15.0
Dark Mode         200   1      0.9      4      (200×1×0.9)/4 = 45.0
API Limits        500   2      0.7      10     (500×2×0.7)/10 = 70.0
Performance Fix   1000  0.5    1.0      5      (1000×0.5×1)/5 = 100.0
Custom Fields     30    3      0.6      12     (30×3×0.6)/12 = 4.5

PRIORITIZE: Performance > API Limits > Dark Mode > Onboarding > Custom Fields

RICE の確信度レベル

高（1.0）— 調査に基づく

• 顧客インタビューを実施済み
• 分析データがある
• 顧客の要望を裏付けるサポートチケットがある
• 顧客の需要が明確

中（0.8）— ある程度の検証済み

• 論理的な仮定
• 1〜2 人の顧客から要望がある
• 業界のトレンドがそれを示している
• 他の場所で類似機能が成功している

低（0.5）— 検証が最小限

• 知識に基づく推測
• 競合からのプレッシャー（競合にはある）
• 新たな機会が生まれた
• さらに深い検証が必要

非常に低い（0.25）— 完全な仮定

• 「良いアイデアに思える」
• 顧客からのフィードバックがない
• 検証がまったくない
• 無駄になるリスクが高い

代替の優先順位付け手法

価値と労力のマトリックス

           Low Effort      High Effort
High Value  QUICK WINS      STRATEGIC
           (Do first)      (Plan carefully)

Low Value   FILL-INS        AVOID
           (If time)       (Skip)

クイックウィン： 価値が高く、労力が少ない

• 勢いをつけるため、最初に実装する
• 自信を築く
• ステークホルダーに進捗を示す
• 例：バグ修正、小規模な機能

戦略的項目： 価値が高く、労力が大きい

• 長期的な競争優位性
• 計画とリソースが必要
• 例：新しいプラットフォーム、アーキテクチャ

補完項目： 価値が低く、労力が少ない

• 機能の磨き込み
• 技術的負債
• 余力があるときに実施する

回避項目： 価値が低く、労力が大きい

• リソースの無駄
• 明確に「いいえ」と伝える

MoSCoW メソッド（よりシンプル）

必須（リリースに不可欠）

• 中核となる機能
• これらがなければリリースできない
• 通常、作業の 40%

あったほうがよい（重要だが延期可能）

• 大きな価値がある
• なくてもリリースできるが、魅力は下がる
• 通常、作業の 30%

あれば望ましい（あると便利）

• 磨き込み、便利な機能
• 予算や時間に余裕があれば実施する
• 通常、作業の 20%

実施しない（明確に対象範囲外）

• 明確に延期される
• ステークホルダーが優先順位を理解しやすくなる
• 通常、作業の 10%

カノモデル（顧客満足度）

機能のカテゴリは 3 つあります。

基本要素（当たり前品質）

• 備わっていることが期待される
• 欠けていると非常に不満を感じる
• 備わっていても満足するだけで、感動はしない
• 例：アプリの中核機能
• 競争優位性にはつながらない

性能要素（比例品質）

• 増えるほど満足度が高まる
• 減るほど満足度が下がる
• 競争優位性につながる
• 例：速度、カスタマイズの選択肢
• 継続的に拡大する

魅力要素（感動品質）

• 予想外の機能
• 備わっていると感動する
• なくても特に不満はない
• 高い競争優位性
• 例：意外性のある UX、隠し機能

戦略： まず必須項目、次に性能要素、差別化のために最後に魅力要素に取り組みます。

ロードマップの計画プロセス

12 か月の戦略ロードマップ

構成：

Q1 2025: Initiative Theme
├─ Goal: Business outcome
├─ Key Features: 2-3 major features
├─ Success Metrics: How you measure
└─ Resource: Team size needed

Q2 2025: Initiative Theme
Q3 2025: Initiative Theme
Q4 2025: Initiative Theme

四半期計画プロセス

タイムライン： 四半期開始の 1 か月前に計画します

第 1 週：データ収集

• 前四半期の顧客フィードバック
• サポートチケットと課題
• 競争環境の変化
• チームの振り返りで得られた学び
• 目標に対する指標のレビュー

第 2 週：優先順位付け

• RICE スコアリングを適用する
• 戦略目標を考慮する
• リソースの確保状況を評価する
• エンジニアリングの見積もりを取得する
• 依存関係を整理する

第 3 週：計画

• ストーリーをスプリントに分割する
• リソースを割り当てる
• リスクを特定する
• コミュニケーションを計画する

第 4 週：調整と開始

• ステークホルダーにロードマップを提示する
• エンジニアリングチームのコミットメントを得る
• 経営陣の承認を得る
• 全体ミーティングで発表する

スプリント計画（週次）

月曜日：計画

• スプリントで取り組む機能を選ぶ
• ユーザーストーリーに分割する
• 労力を見積もる
• 担当者を割り当てる
• ブロッカーを特定する

毎日：スタンドアップ

• 何をしましたか？
• 何が障害になっていますか？
• 次に何をしますか？
• 最大 15 分

金曜日：振り返り

• うまくいったことは何ですか？
• 改善が必要なことは何ですか？
• ベロシティを追跡する
• 次のスプリントに向けて計画を調整する

リソースの割り当て

チームのキャパシティ計画

Team Size: 5 engineers
Sprint Length: 2 weeks
Typical Capacity: 40-50 story points

Planning Reality:
- 50% unplanned work (bugs, interrupts)
- 20% operational tasks
- 30% feature development

Result: 50 points × 30% = 15 points for features
→ Add MUST have items first
→ Fill remaining capacity with SHOULD/COULD

リソース配分

エンジニアリングチーム：

• 60～70％：新機能（ロードマップ）
• 20～30％：バグ修正と最適化
• 10～15％：技術的負債
• 5～10％：運用／サポート

プロダクトマネージャー：

• 60％：計画とディスカバリー
• 20％：コミュニケーションと認識合わせ
• 10％：分析と指標
• 10％：チームのリーダーシップ

デザインチーム：

• 70％：機能設計
• 15％：デザインシステムの保守
• 15％：調査とテスト

依存関係と順序

依存関係の種類

ハード依存関係

• 機能 A が完了するまで、機能 B は着手できません
• 例：サブスクリプションプランの前に決済システムを構築する
• スケジュールに大きな影響を与えます

ソフト依存関係

• 機能 A を先に完了しておくと、機能 B がよりスムーズに進みます
• 例：ウェブ版のテスト完了後にモバイルアプリを開発する
• タイミングには柔軟性があります

チーム横断の依存関係

• 他チームの完了が必要です
• リードタイムが最も長くなります
• 早い段階で明らかにする必要があります

リスク管理

よくあるリスク：

1. スコープクリープ

   • 軽減策：「ノー」と伝え、後回しにします
   • 担当者：プロダクトマネージャー
   • 計画：毎週スコープをレビューします

2. 重要なメンバーの離職

   • 軽減策：クロストレーニング、ドキュメントの整備
   • 担当者：エンジニアリングマネージャー
   • 計画：オンボーディングプロセスを整備します

3. スケジュールの圧迫

   • 軽減策：バッファを設けて計画し、期待値を管理します
   • 担当者：プロダクトマネージャー
   • 計画：透明性のあるコミュニケーションを行います

4. 技術的な課題の発生

   • 軽減策：スパイク期間、概念実証
   • 担当者：エンジニアリングリード
   • 計画：見積もりに20％の予備を設けます

ロードマップのコミュニケーション

経営陣向け

• ビジネス成果を重視します
• 各四半期がビジョンの実現にどうつながるかを示します
• 競合との差別化要因を強調します
• 収益／成長への影響を示します

エンジニアリング向け

• 詳細な仕様と要件
• 技術的な複雑さと依存関係
• 工数の見積もりとリスク
• 必要なリソース

顧客向け

• ユーザーにとってのメリットを重視します
• スケジュール（具体的な日付ではなく四半期）
• 要望の多い機能を強調します
• 控えめに約束し、期待を上回る成果を届けます

営業向け

• 「近日公開」のメッセージ
• 営業活動に活用できる内容
• 顧客からのフィードバックを反映します
• 競合との差別化要因

ロードマップのレビューと調整

毎週： スプリントの進捗
毎月： 四半期の計画に対する進捗
四半期ごと： ロードマップ全体の見直し
毎年： 戦略的な方向性のレビュー

優先順位を見直すきっかけ：

• 大口顧客の解約
• 競争上の脅威
• 市場の変化
• 予期せぬ技術的な障害
• リソースの利用可能状況の変化

トラブルシューティング

よくあるエラーと解決策

エラー	考えられる原因	解決策
ロードマップが常に遅れている	非現実的な見積もり	30％のバッファを追加
優先順位をめぐる議論	基準が不明確	RICE ワークショップ
リソースの競合	過剰なコミットメント	キャパシティプランニング
依存関係によるブロック	特定が遅い	スプリント 0 でマッピング

デバッグチェックリスト

[ ] RICE scoring consistent mi?
[ ] Capacity realistic mi? (20% buffer)
[ ] Dependencies mapped mi?
[ ] Stakeholder alignment var mı?
[ ] Risk mitigation planı var mı?

復旧手順

1. ロードマップの遅延 → 優先順位を見直し、スコープを削減
2. リソースの競合 → トレードオフマトリクス
3. 優先順位の不一致 → データに基づく RICE

---

優先順位付けを習得し、確かな成果につながるロードマップを作成しましょう！