第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つに分類します。 横軸を「充足度(機能の出来)」、縦軸を「顧客満足度」とした非線形な関係が核心です。

分類充足したとき不充足のとき
当たり前品質(Must-Be)満足は上がらない(あって当然)大きな不満スマホが通話できる、Webが落ちない
一元的品質(Performance)満足が上がる不満が上がる(比例的)バッテリー持ち、表示速度
魅力的品質(Delighter)大きな感動・満足不満にはならない予想外の便利機能、サプライズUX
無関心品質(Indifferent)満足にほぼ影響しない不満にもならない大半が気にしない仕様
逆品質(Reverse)むしろ不満が増えるむしろ満足過剰な機能・押し付け通知

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

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

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

区分意味
Must have必須。これがないとリリースが成立しない
Should have重要だが必須ではない。あると価値が高い
Could haveあれば望ましい。納期が逼迫したら最初に外す候補
Won't have (this time)今回は対象外とステークホルダー合意した最低優先度項目

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を最優先、右下Time Sinksはバックログから除外する

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

専門系 — WSJF と Opportunity Scoring

フレームワーク計算式核心向いている場面
WSJF(SAFe)Cost of Delay ÷ Job Size「遅延コスト」という経済価値で序列化。小さく価値が高い仕事を先に大規模アジャイル(SAFe)
Opportunity Scoring(Ulwick)Importance + max(Importance − Satisfaction, 0)高重要度×低満足度=未充足ニーズを発見イノベーション機会の発見
ストーリーマッピング(Patton)バックボーン×縦の優先度×横のリリーススライスユーザー体験の全体像を保ったまま優先順位を付けるMVP定義・リリース計画

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フレームワーク横断比較

FW出力形式入力データ量最適な場面
RICE定量スコアデータのある成熟プロダクトの序列化
Kano定性分類中(アンケート)機能の性質を見極め投資配分を決める
MoSCoW区分(順序なし)固定納期・スコープ確定・合意形成
価値×工数4象限素早い初期トリアージ・議論の起点
ICE定量スコアグロース実験の高速優先順位付け
WSJF定量スコア(相対)大規模アジャイル(SAFe)の経済的序列化
Opportunity Scoring定量スコア大(顧客調査)未充足ニーズ・イノベーション機会の発見
ストーリーマッピング視覚マップMVP定義・リリース計画・体験の全体最適

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

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

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
意思決定の段階で使い分ける。機会発見→序列化→スコープ確定の各フェーズに適したFWがある

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

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

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

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

理解度チェック

問題 0 / 50%
Q1

RICEスコアの計算式として正しいものはどれですか?

キーボード: 1〜4 で選択、Enter で回答