開発する機能の優先順位を決める方法｜フレームワークと実務の勘所
目次
開発リソースの割り当てはシステム開発の中で非常に重要な選択になります。営業からは大口顧客の要望、カスタマーサポートからは解約を防ぐための改善依頼、エンジニアからは技術的負債の解消——どれも「やるべき」に見えるなかで、限られた工数をどこに向けるかを決めるのがプロダクトマネージャー（PdM）の中心的な仕事です。この記事では、機能の優先順位を決めるための代表的なフレームワークを評価軸・長所・限界まで整理し、フレームワークだけでは決めきれない部分をどう補うかという実務の勘所まで解説します。
- 優先順位づけに唯一の正解はなく、フレームワークの価値は「判断の根拠をチームで共有できる共通言語」になること
- 代表的な手法は価値と労力・MoSCoW分析・ICE・RICE・Kanoモデル。それぞれ答える問いが違うので、組み合わせて使う
- スコアの数値を絶対視せず、依存関係・テーブルステークス・技術的負債・声の大きい顧客といった「拾いきれない要素」は対話で補う
優先順位づけに「唯一の正解」はない
最初に前提を共有します。どのフレームワークも万能ではありません。フレームワークの本当の価値は、正解を計算してくれることではなく、判断の根拠をチームで共有できる共通言語になることにあります。
スコアが高いから採用する、のではなく、なぜそのスコアになったのかを説明し、営業・CS・開発・経営の目線を合わせるために使う——この視点を持っておくと、後述する各手法の限界にも冷静に向き合えます。
優先順位づけは、正解を当てるゲームではありません。限られたリソースの向け先について、関係者が納得できる根拠をつくるプロセスです。フレームワークは、その議論の土台をそろえるために使います。
機能の優先順位づけフレームワーク5選
実務でよく使われる5つを、まず一覧で比較します。大きくは「分類・整理するもの（価値と労力・MoSCoW分析・Kanoモデル）」と「スコアで数値化するもの（ICE・RICE）」に分かれます。この記事では、直感的に始められるシンプルな手法から、データや分析が必要な本格的な手法へと、順に紹介します。
| フレームワーク | 評価の軸 | 向いている場面 |
|---|---|---|
| 価値と労力 | 価値×労力の2軸でクイックウィンを可視化 | 全体像をざっと共有したい |
| MoSCoW分析 | Must／Should／Could／Won't でスコープを仕分け | リリース範囲を合意したい |
| ICE | Impact・Confidence・Ease の3軸で手早くスコア化 | Reachが読めない／素早くトリアージしたい |
| RICE | Reach・Impact・Confidence・Effort の4軸でスコア化 | 定量データがそろい、案件を横比較したい |
| Kanoモデル | 顧客満足への寄与で機能を分類（当たり前／性能／魅力） | 満足度の質を見極めたい |
価値と労力（Value vs Effort）：2軸でクイックウィンを見つける
最初に紹介する「価値と労力」は、5つのなかで最も手軽に始められる手法です。価値（縦軸）と労力（横軸）の2×2マトリクスに施策をプロットし、「高価値・低労力＝クイックウィン」を最優先、「低価値・高労力＝原則見送り」とする整理法です。素早く全体像を共有できる反面、価値の見積もりが推測に頼りやすく、声の大きい人の見立てに引っ張られやすい点、依存関係や長期価値が表せない点に注意する必要があります。
MoSCoW分析：スコープを4区分に切り分ける
MoSCoW分析は、要件を Must have（必須）／Should have（推奨）／Could have（あれば良い）／Won't have（今回はやらない）の4区分に振り分ける手法です。リリースのスコープを合意するのに向いていますが、ステークホルダーが強く要求すると「すべてがMustになる罠」に陥りやすいこと、そしてどの項目がどの区分に入るかを決める客観的な方法論をMoSCoW分析自体は持たないことが弱点です。後述するRICEのようなスコアリング手法と組み合わせるのが有効です。
ICE：3つの要素で素早くスコア化する
ここからは、スコアで数値化する手法に入ります。ICEは Impact（インパクト）× Confidence（自信度）× Ease（容易さ）の3要素を、それぞれ1〜10で採点して掛け合わせる手法です。3要素を採点要素として決めることで、素早いトリアージをするときに向きます。そのぶん主観に左右されやすく、共通の採点基準がないと同じアイデアでも人によってスコアがぶれる点には注意が必要です。
RICE：単位工数あたりのインパクトを数値化する
スコアリングの軸を1つ増やし、より精緻に比較するのがRICEです。Intercomのグロースチームが自社の優先順位づけのために考案したフレームワークで、次の式でスコアを出します。
RICEスコア ＝（Reach × Impact × Confidence）÷ Effort
- Reach（リーチ）：一定期間に影響を受ける人数やイベント数。推測ではなく実測値を使うのが原則です。
- Impact（インパクト）：1人あたりへの影響度。原典では 3（massive）／2（high）／1（medium）／0.5（low）／0.25（minimal）の5段階で評価します。
- Confidence（自信度）：推定への確信度をパーセンテージで。100%／80%／50% が目安です。
- Effort（工数）：チーム全体の作業量を人月で。大きいほど不利になるため割り算に使います。
強みは、比較しにくいアイデア同士を「単位工数あたりの総インパクト」という一貫した軸で並べられること。一方で、各要素の決め方が人によって変わるため主観が入りやすく、依存関係や「テーブルステークス（当たり前に必要な機能）」が低スコアになりがちという弱点があります。これはRICEの考案者自身も注意喚起している点で、スコアはあくまでランキングの補助であって絶対的なルールではありません。
Kano（狩野）モデル：顧客満足の"質"で機能を分類する
最後に紹介するKanoモデルは、狩野紀昭らが1984年に提唱した品質分類の考え方です。スコアを計算するのではなく、機能を顧客満足への寄与タイプで分類します。
- 当たり前品質：あって当然。欠けると強い不満を生むが、満たしても満足度は上がらない。
- 一元的品質（性能品質）：充足度に比例して満足が上がる、競争の軸になる要素。
- 魅力的品質：あれば大きな満足、なくても不満にならない差別化要素。
満足の質を可視化できるのが強みですが、魅力的品質は時間とともに当たり前品質へ変化します。競合が追いつけばユーザーの期待が上がり、かつての差別化機能が「あって当然」になるためです。分類のためのアンケート設計・分析にコストがかかる点も、小規模組織には負担になりがちです。
スコアリングの落とし穴：「偽の精度」に注意
ここまでの手法に共通する注意点が、数値の絶対視です。
「8.2点」は「かなり重要そう」よりも科学的に見えますが、その精密さは見かけだけのことがあります。ImpactやConfidenceは主観的な見積もりなので、採点者のバイアスや「お気に入り案件のスコアを盛る」力学が働きます。数字が出たこと自体を、正しさの証拠と取り違えないことが大切です。
だからこそ実務では、フレームワークで初期整理をしてから、対話で補完するという二段構えでの対応が有効です。スコアはゴールではなく、議論の共通言語として扱うのがコツです。
フレームワークを組み合わせて使う
これらの手法は競合するものではなく、それぞれ別の問いに答えるツールです。実務では、次のような複合的な組み合わせがよく使われます。
- 大枠 → 詳細：まずテーマ単位で大まかに方向を決め、そのなかをRICEなどで詰める。
- スコープ → ランキング：MoSCoW分析でリリース範囲を確定してから、RICE／ICEで順位づけする。
- 発見 → 優先順位：Kanoで顧客満足の質を把握し、RICEで実装順を決める。
フレームワークで拾いきれないもの
最後に、スコアだけでは決められない代表的な論点を2つ挙げます。
声の大きい顧客の要望を優先し続けると、目先の懸念に振り回され、機能過多でプロダクトが複雑化します。鍵は「要望（顧客が挙げる解決策）」と「課題（その背後にある痛み）」を切り分けること。解決策は顧客が思いつける範囲の一案にすぎず、真の課題を掘り当てて最適な解を設計するのはプロダクトチームの重要な役目です。
技術的負債は短期の事業インパクトに表れにくく、スコア上はどうしても低くなります。エンジニアが負債解消を提案できる心理的安全性と、「今手を打たないと将来こうなる」と根拠を持って主張できる情報共有の両方を用意し、スコアの外側で意図的に扱う枠組みを持っておくことが重要です。
要望を「集める・整理する」段階の設計は、機能要望管理とは？収集・整理・優先順位付けの基本で詳しく解説しています。あわせて読むことで、要望を集めてから優先順位に落とすまでの流れがつながります。
PMF前は学びを最大化する施策を、成長期は事業インパクト（ARR・解約率など）に効く施策を、というように、優先順位の基準は事業フェーズによって変わります。BtoB SaaSでは、契約金額や解約リスクといった事業指標をスコアの内部に組み込むと、財務指標とロードマップが接続され、経営層への説明もしやすくなります。
ここまで紹介したフレームワークは、いずれも施策を1件ずつ評価するものでした。ここからは少し余談として、アーコレを運営する私たち株式会社Covvyの実例を2つ紹介します。
ひとつは受託開発の現場での話です。あるプロジェクトで、顧客からの要求が大きく、正面から取り組むとリリースがおよそ1ヶ月止まる見通しになりました。要求そのものの優先度は高く、フレームワークで評価しても上位に来る案件です。しかし、その1件にリソースを寄せきると、その間のリリースはゼロになります。そこで私たちは、大きな要求と並行して、事業にインパクトがあり、かつすぐに実装できるものを選び直し、リリースの頻度を落とさないように計画を組み替えました。最初に紹介した「価値と労力」でいうクイックウィンを、大きな案件の合間に意図的に挟み込む形です。優先順位づけの対象は個々の機能でも、顧客やユーザーに届くのは「リリース」という束です。スコアの高い案件から順に消化する計画は、一見合理的に見えて、リリースの空白という見えないコストを含んでいます。
もうひとつは、アーコレ自身の開発です。アーコレは現在α版で、これからβ版を展開していく段階——本記事でいう「PMF前」の探索期にあたります。この段階では、売上や解約率といった事業指標はまだ優先順位の材料にできません。そこで私たちは「学びの速さ」を基準に置き、クイックウィンをα版ユーザーに素早く届けて、フィードバックをすぐに貰える状態を保つことを優先しています。大きな機能をじっくり作り込むより、小さく出して反応を確かめるサイクルを速く回すほうが、探索期には価値が大きいと判断しているためです。
どちらの例にも共通するのは、スコアで順位を決めたら、最後に「この順番で進めたとき、ユーザーに届く頻度はどうなるか」を確かめる、という一手間です。フレームワークの表の外側にあるこの確認を、私たちは優先順位づけの仕上げとして挟むようにしています。
よくある質問
開発する機能の優先順位はどうやって決めればいいですか？
まず判断基準をチームで決めることが出発点です。RICEやICEでスコア化する、Kanoモデルで顧客満足の質を分類する、MoSCoW分析でリリース範囲を仕分けるなど、目的に合ったフレームワークを選びます。ただしスコアだけで機械的に決めず、依存関係やテーブルステークス、技術的負債といった数値で拾えない要素は対話で補完します。
RICEとICEの違いは何ですか？
RICEはReach・Impact・Confidence・Effortの4軸、ICEはImpact・Confidence・Easeの3軸で評価します。ICEはRICEからReachを省いた簡易版で、素早く判断したいときやReachが読めないときに向きます。そのぶん主観に左右されやすいため、共通の採点基準を決めておくとブレを抑えられます。
フレームワークのスコアだけで優先順位を決めてよいですか？
スコアはランキングの補助であり、絶対的なルールではありません。ある機能が別の機能の前提になっている場合や、特定顧客に売るための必須条件である場合は、低スコアでも先に着手する理由があります。スコアで初期整理をしたうえで、最終判断は対話で補うのが実務的です。
まとめ
機能の優先順位づけは、正解を計算する作業ではなく、限られたリソースの向け先についてチームで納得できる根拠をつくるプロセスです。価値と労力・MoSCoW分析・ICE・RICE・Kanoといったフレームワークは、そのための強力な共通言語になります。ただしどれも万能ではなく、依存関係やテーブルステークス、技術的負債、そして「声の大きい顧客」といった数値で拾いきれない要素が必ず残ります。スコアで初期整理をし、対話で補完し、事業フェーズや指標に合わせて基準を調整していく——この地道な往復こそが、優先順位づけの実務そのものなのです。