「RICEを使うべきか、MoSCoWを使うべきか」という質問を受けることがあります。この質問自体が、実はつまずきの入り口です。RICEとMoSCoWは、そもそも解決しようとしている問題が違うため、どちらか一方を選ぶという発想では答えが出ません。
プロダクトマネジメントを兼務している経営者であれば、開発チームや投資家に「なぜこの順番なのか」を説明する場面で、こうしたフレームワークの名前を一度は耳にしているはずです。ただし名前だけが先行し、「結局何のために使うのか」が整理されないまま導入すると、かえって判断が遅くなります。
本記事では、RICEとMoSCoWそれぞれの仕組みと限界を整理したうえで、実務でどう組み合わせるかを解説します。
なぜ「比較」で悩むのか
RICEとMoSCoWを比較しようとすると迷いが生じる理由は、両者が答えようとしている質問が異なるためです。
- RICEが答える質問:「数ある候補の中で、どれを先にやるべきか」(順位付け)
- MoSCoWが答える質問:「今回のリリースに、何を含めて何を含めないか」(範囲の確定)
順位付けと範囲確定は、似ているようでまったく別の作業です。順位が1位から10位まで決まっていても、「今回のリリースにどこまで含めるか」は別途決めなければなりません。逆に、リリース範囲だけ決めても、その範囲内での着手順序は決まりません。この違いを理解しないまま「どちらか一方」を選ぼうとすると、片方の問いにしか答えが出ず、もう片方の問いが放置されます。
RICEの仕組みと向いている場面
RICEは、複数の候補を数値化して横並びで比較するためのスコアリング手法です。
RICEスコア =（Reach × Impact × Confidence）÷ Effort
- Reach(到達数):一定期間内に影響を受けるユーザー数
- Impact(影響度):1人あたりの体験にどれだけ強い影響を与えるか(段階評価が一般的)
- Confidence(確信度):見積もりの根拠がどれだけ確かか(%で表現)
- Effort(工数):実装にかかる人月・人日
4つの要素を掛け合わせて工数で割ることで、性質の異なる施策(新機能追加、既存機能の改善、バグ修正など)を1つの軸で比較できるのが最大の利点です。
RICEが向いている場面
- 候補が5〜10件程度あり、優先順位が拮抗していて感覚だけでは決めきれないとき
- 投資家や社外パートナーに「なぜこの順番なのか」を数値で説明する必要があるとき
- 開発チームが複数のプロダクト領域にまたがっており、共通の物差しがないと比較できないとき
RICEの限界
見積もりの主観性が最大の弱点です。特にImpactとConfidenceは、担当者の経験や思い込みに左右されやすく、「数字に見えるが実は感覚」になりがちです。 また、全候補にRICEを適用すると見積もり作業自体に時間がかかるため、上位候補が拮抗した場面に絞って使うのが実務的です。
MoSCoWの仕組みと向いている場面
MoSCoWは、候補を4段階に分類し、特定のリリースに含める範囲を確定するための手法です。
- Must have:これが無いとリリースする意味がない
- Should have:重要だが、無くてもリリースは成立する
- Could have:あれば良いが、優先度は低い
- Won’t have(this time):今回は対象外と明示する
RICEが「順位」を出す手法であるのに対し、MoSCoWは「線引き」をする手法です。順位ではなく、「今回のスコープに入れるか、入れないか」の二択に近い判断を、関係者間で合意するために使います。
MoSCoWが向いている場面
- 特定のリリース・スプリントのスコープを確定させたいとき
- 開発チーム、営業、CSなど複数の関係者が「あれもこれも入れてほしい」と主張し、収拾がつかなくなっているとき
- 期限が固定されており、期限内に収まる範囲を先に決める必要があるとき
MoSCoWの限界
関係者の多くが、自分の要望を「Must have」に入れたがることです。全員が譲らなければ、分類そのものが機能しません。事前に「Must haveは全体の6割以内」といった上限を関係者全員に周知しておくことで、この問題をある程度防げます。また、MoSCoWは「入れるか入れないか」を決める手法であり、Must have同士の着手順序までは決めてくれません。着手順序を決めるには、別途RICEやValue vs Effortのような順位付け手法が必要です。
比較表:何が違うのか
| 観点 | RICE | MoSCoW |
|---|---|---|
| 答える問い | どれを先にやるか(順位) | 何を含めるか(範囲) |
| 出力の形 | 数値スコアによるランキング | 4段階のカテゴリ分類 |
| 適した候補数 | 5〜10件程度(拮抗した上位候補) | リリース対象の全候補 |
| 主な弱点 | 見積もりの主観性 | Must haveへの希望の集中 |
| 使うタイミング | 候補を絞り込む段階 | リリース範囲を確定する段階 |
| 誰向けの説明に強いか | 投資家・社外パートナーへの数値説明 | 社内関係者間のスコープ合意 |
実務での組み合わせ方
多くの現場で機能するのは、どちらか一方を選ぶのではなく、2段階で組み合わせる運用です。
- 候補全体をMoSCoWで大まかに仕分ける。 「Won’t have」を早々に除外し、検討対象を「Must have」「Should have」「Could have」に絞り込みます。この段階では細かい数値化は不要です。
- 「Must have」に分類された候補が拮抗した場合のみ、RICEで着手順序を決める。 Must haveの中でも「今週やるか、来週やるか」の判断が必要な場面で、数値化のコストに見合う効果が出ます。
MoSCoWで絞り込んでからRICEで順位を付ける、という順序が重要です。 逆に全候補にRICEを先に適用しようとすると、Won’t haveに分類されるべき候補まで見積もり工数をかけて計算することになり、非効率です。
MoSCoWでリリース範囲が固まったら、その内容を1人目のPdMやエンジニアに引き継ぐドキュメントに落とし込みます。
具体例:シードステージSaaS、次回リリースのスコープ確定
従業員8名、シードステージのBtoB SaaSスタートアップを例に、組み合わせの流れを確認します。
このスタートアップでは、次のメジャーリリースに向けて候補が32件挙がっていました。経営者がまずMoSCoWで一次仕分けを行い、「Won’t have」に14件、「Could have」に9件を振り分け、残った「Must have」7件と「Should have」2件を今回の対象としました。
このうち「Must have」7件は、いずれも重要度が高く見えて着手順序が決めきれなかったため、RICEでスコアリングを実施しました。Reachは直近3か月の利用ログから実数を使い、Impactは過去の類似施策の解約率改善データを根拠にしました。結果、7件中2件が突出して高スコアとなり、この2件から着手する意思決定を行いました。
全32件にRICEを適用していた場合、見積もり工数だけで数日かかっていたと推定されます。 MoSCoWで先に絞り込んだことで、RICEの計算対象を7件に抑え、意思決定までの時間を1日程度に収めることができました。
よくある失敗
1つ目は、MoSCoWだけで着手順序まで決めようとする失敗です。 「Must have」に分類された候補は、あくまで「今回のリリースに含める」という合意であり、その中での順序は別途決める必要があります。ここを曖昧にすると、結局「声の大きい人の要望から着手する」という状態に逆戻りします。
2つ目は、RICEを全候補に適用して疲弊する失敗です。 前述の通り、RICEは上位候補が拮抗した場面で使う手法であり、候補全体に網羅的に適用するものではありません。まずMoSCoWやValue vs Effortマトリクスで大まかに仕分け、RICEは最後の絞り込みに使うのが実務的です。
よくある質問(FAQ)
Q1. RICEとMoSCoW以外に、比較検討すべきフレームワークはありますか?
Value vs Effortマトリクス(価値と工数の2軸で4象限に仕分ける手法)は、MoSCoWより手軽に全体像を掴みたいときに有効です。また、競合との差別化を狙う場面ではKanoモデルが役立ちます。いずれもバックログ管理全体の中での位置づけを、以下の記事で整理しています。
Q2. 経営者1人で判断している段階でも、これらのフレームワークは必要ですか?
必要ないことがほとんどです。判断材料をすべて持っている段階では、フレームワークを使うとむしろ判断の質が落ちます。フレームワークが必要になるのは、判断を他人と共有・合意する必要が出てきたタイミングです。
Q3. RICEのConfidence(確信度)は、どう見積もればよいですか?
「過去に類似の施策を実施した実績があるか」を基準にすると、主観のブレを抑えられます。実績データがある場合は80〜100%、類似事例はあるが自社での実績がない場合は50〜70%、まったくの新規領域で仮説段階の場合は50%以下、という目安で運用している現場が多く見られます。
Q4. MoSCoWの「Must have」に、経営者自身の要望を入れてもよいですか?
入れても構いませんが、他の関係者と同じ基準で判断してください。自分の要望だからという理由で無条件にMust haveに入れると、事前に決めた上限(全体の6割以内など)が形骸化し、MoSCoW自体が機能しなくなります。
Q5. RICEとMoSCoWを両方導入するのは、チームにとって負担が大きくありませんか?
一度に完璧な運用を目指す必要はありません。まずはMoSCoWによるリリース範囲の確定だけを導入し、「Must have」内での順位付けに困る場面が実際に出てきてから、RICEを追加する形で十分です。段階的に導入するほうが、チームの負担も小さく定着しやすくなります。
まとめ
RICEとMoSCoWは、優先順位付けという同じカテゴリで語られがちですが、答えようとしている問いが異なります。RICEは「どれを先にやるか」という順位の問題、MoSCoWは「何を含めるか」という範囲の問題を解決する手法です。
実務では、どちらか一方を選ぶのではなく、MoSCoWで全体を大まかに仕分けてから、拮抗した上位候補にだけRICEを適用するという2段階の組み合わせが機能します。
まずは今抱えている候補リストを、MoSCoWの4段階(Must / Should / Could / Won’t)に仕分けるところから始めてみてください。その中で「Must have」同士の順序に迷う場面が出てきたら、そこで初めてRICEの出番です。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
