第4章: 優先順位付け — 8つのフレームワークと使い分け

第3章のディスカバリーで、多くの「やるべきこと」が見つかりました。しかしリソースは有限です。 ここで避けて通れないのが優先順位付け（prioritization）——「何から手をつけるか」の意思決定です。 本章では、現場で使われる8つの代表的なフレームワークを、計算式と長所短所つきで解剖し、 最後に「どの状況でどれを使うか」という使い分けの地図を描きます。

スコアリング系 — RICE と ICE

RICE — 投下時間あたりの総インパクト

RICEは、Intercom社が自社のロードマップ意思決定を改善するために開発したスコアリング手法です。 4つの要素の頭文字で、計算式は次の通り。

              Reach × Impact × Confidence
   RICE  =  ──────────────────────────────────
                       Effort

   = 「投下した時間あたりの総インパクト」

   Reach（到達）     : 一定期間に何人/何件に影響するか（実数）
   Impact（影響度）   : 1人あたりの影響。Massive=3 / High=2 / Medium=1 / Low=0.5 / Minimal=0.25
   Confidence（確信度）: 見積もりへの確信。High=100% / Medium=80% / Low=50%
   Effort（工数）     : チーム全員の総所要時間（人月）

ReachとImpactとConfidenceが「便益（分子）」、Effortが「コスト（分母）」です。 RICEの巧みな点はConfidence（確信度）が、データの裏付けが弱い項目を割り引く役割を果たし、 楽観バイアスを抑える点にあります。短所は、各入力（特にReach・Impact）の見積もりに主観が混入し、 スコアの精度が見かけほど高くない（疑似定量化のリスク）こと。新規性の高い施策には不向きです。

ICE — グロース実験のための軽量版

ICEは、"growth hacking"の名づけ親Sean Ellisが考案した、RICEの原型ともいえる軽量フレームです。 Impact × Confidence × Easeの各要素を1〜10で採点して掛け合わせます。 RICEのEffort（工数、低いほど良い）の代わりにEase（容易さ、高いほど良い）を使うのが特徴。 極めて高速で、グロース実験の大量バックログを素早くさばけますが、Reach（規模）を明示的に含まないぶんRICEより粗くなります。

Kanoモデル（狩野モデル） — 機能の「性質」を見極める

日本発の世界的フレームワークが、狩野紀昭（かの・のりあき）が1980年代に提唱したKanoモデルです。 これはスコアで順位を付けるのではなく、機能を性質によって5つに分類します。 横軸を「充足度（機能の出来）」、縦軸を「顧客満足度」とした非線形な関係が核心です。

合意形成系 — MoSCoW と 価値×工数マトリクス

MoSCoW — 「やらないこと」を明示する

MoSCoW法は、Dai Cleggが1994年に考案した、4つの区分でスコープを合意する手法です （間の小文字oは発音用）。固定納期（タイムボックス）と組み合わせて使います。

MoSCoWの強みは、「やらないこと（Won't）」を明示できる点にあります。 ステークホルダーとの合意形成が容易で、Must は工数の60%以下に抑える運用がよいとされます。 短所は、各区分内での順位が付かないことと、規律がないと「全部Must」になりがちなことです。

価値×工数マトリクス — 素早いトリアージ

最もシンプルなのが価値×工数マトリクス（2×2）です。縦軸を価値、横軸を工数として4象限に分類します。

quadrantChart
  title 価値 vs 工数
  x-axis 低い工数 --> 高い工数
  y-axis 低い価値 --> 高い価値
  quadrant-1 Big Bets 戦略的大型投資
  quadrant-2 Quick Wins 最優先
  quadrant-3 Fill-Ins 余力で
  quadrant-4 Time Sinks 除外
  施策A: [0.25, 0.85]
  施策B: [0.8, 0.75]
  施策C: [0.3, 0.2]
  施策D: [0.85, 0.25]

Quick Wins（高価値・低工数）は即着手、Big Bets（高価値・高工数）は慎重に計画、 Fill-Ins（低価値・低工数）は余力で、Time Sinks（低価値・高工数）は除外。 視覚的で直感的、議論の出発点として優秀ですが、2軸に単純化しすぎてリスクや依存関係を無視する点が短所です。

専門系 — WSJF と Opportunity Scoring

WSJF（Weighted Shortest Job First）はSAFeの中核で、「If you only quantify one thing, quantify the Cost of Delay（定量化するものが1つだけなら、遅延コストを定量化せよ）」が標語。 Opportunity ScoringはTony Ulwickのもので、第3章のJTBD（ODI流派）と直結し、 「重要だが満たされていない」アウトカムをデータで特定します。 ストーリーマッピング（Jeff Patton）は、フラットなバックログを「地図」に変え、 ユーザー体験の流れを失わずに優先順位とリリース範囲を決められます。

8フレームワーク横断比較

使い分けマップ — どの状況でどれを使うか

フレームワークは「どれが最強か」ではなく「どの段階で使うか」で選びます。意思決定のフェーズで整理しましょう。

graph TD
  A[機会発見フェーズ\n何を作るべきか] -->|未充足ニーズ| OS[Opportunity Scoring]
  A -->|機能の性質| K[Kano]
  B[序列化フェーズ\nどの順で作るか] -->|データあり| R[RICE]
  B -->|グロース実験| I[ICE]
  B -->|SAFe大規模| W[WSJF]
  C[スコープ確定フェーズ\n今回どこまで] -->|固定納期| M[MoSCoW]
  C -->|リリース計画| SM[ストーリーマッピング]
  style A fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style B fill:#3b82f6,stroke:#2563eb,color:#fff
  style C fill:#14b8a6,stroke:#0d9488,color:#fff

実務では併用が定石です。たとえば「Opportunity Scoringで機会領域を特定 → その領域の機能をRICEで序列化 → ストーリーマッピングでリリースに落とす」という流れ。あるいは「Kanoで当たり前品質と魅力的品質を分け、当たり前品質をMoSCoWのMustに置く」。 チームの成熟度やデータ量でも選択が変わります——データが乏しい初期は価値×工数やICE、データが揃えばRICEやOpportunity Scoringへ。

まとめ — フレームワークは地図であって羅針盤ではない

本章では、8つの優先順位付けフレームワークを解剖しました。 RICE/ICEはスコアで序列化し、Kanoは機能の性質を分類し、 MoSCoW/価値×工数は素早く合意し、WSJF/Opportunity Scoring/ストーリーマッピングは専門的な状況に答えます。 重要なのは「どれが正解か」ではなく、意思決定の段階・データ量・組織コンテキストに応じて使い分け、併用すること。 そしてスコアは判断を助ける道具であって、判断そのものではないという節度です。

優先順位が決まったら、それを計画に落とし込み、組織に伝える必要があります。 しかし「いつ何を作るか」を約束するロードマップには、大きな落とし穴があります。 次章では、ロードマップとOKRを「アウトカムへの転換」という視点から扱います。