機能要望の優先順位づけには、RICE・Kano・MoSCoWといった名前の付いたフレームワークがいくつも存在します。この記事ではそれぞれの考え方と、実務で使うときに見落としがちな共通の限界を整理します。
RICEスコアリングとは
Reach(影響範囲)・Impact(インパクト)・Confidence(確信度)・Effort(工数)の4項目をそれぞれ数値化し、(Reach × Impact × Confidence) ÷ Effort で1つのスコアを出す手法です。要望や施策を横並びで比較しやすくなるのが利点で、特に「候補が多すぎて何から手をつけるか決められない」という段階の粗い絞り込みに向いています。
一方で、4項目の数値化そのものが担当者の主観に依存します。特にConfidence(確信度)は「なんとなく効きそうな気がする」という感覚的な数字になりがちで、スコアの精度は入力の精度を超えません。
Kanoモデルとは
顧客満足度と機能の充足度の関係を、当たり前品質(Must-be)・一元的品質(Performance)・魅力的品質(Attractive)・無関心品質(Indifferent)・逆品質(Reverse)の5分類で整理する手法です。機能の有無を尋ねる質問と、機能がなかった場合の感情を尋ねる質問をペアで聞き、回答パターンから分類します。
「当たり前品質が満たされていないと不満に直結するが、満たしても満足度は大きく上がらない」「魅力的品質は無くても不満は生まれないが、あると満足度が跳ね上がる」という非対称性を捉えられるのが強みです。ただし、この分類を正確に行うには顧客への構造化されたアンケートが前提になり、日々流れ込んでくる要望をその場で分類する用途にはあまり向きません。
MoSCoW法とは
要望をMust have(必須)・Should have(重要)・Could have(あれば良い)・Won't have(今回は対象外)の4区分に仕分ける手法です。スプリントやリリース単位でスコープを決める際に、チーム内の合意形成を速くする目的で使われることが多く、数値化を伴わない分、導入のハードルは低めです。
弱点は、区分の基準がチームの合意次第になりやすいことです。「これは本当にMustなのか、声が大きい人がMustと言っているだけなのか」を分けて判断する仕組みが、フレームワーク自体には組み込まれていません。
共通する限界:数値・分類が「理由」を隠してしまう
RICE・Kano・MoSCoWはいずれも、要望を数値やカテゴリに変換して比較しやすくする道具です。この変換の過程で、個々の要望が持っていた「誰が・何に困っていて・なぜそれが欲しいのか」という文脈は、多くの場合失われます。
例えば同じ「検索機能を改善してほしい」という要望でも、表示速度に不満がある人と、検索対象のデータ範囲に不満がある人ではRICEのImpactもEffortも本来別々に見積もるべきですが、要望が1件として集計されていると、この違いに気づかないまま数値化してしまうことがあります。件数と理由がズレるという同じ問題は「要望の数を数えても、優先順位は決められない」でも詳しく書きました。
フレームワークをどう使うか
フレームワークは判断の「型」を提供してくれますが、型に流し込む前のインプット(要望の背景・理由)が粗いままだと、出てくるスコアや分類の質も粗くなります。実務では、フレームワークを適用する前段階で「なぜその要望が出ているのか」をできるだけ言葉にしておくことが、スコアの精度そのものより効いてくることが多いです。
Feeduryでは、要望投稿に対してAIが背景を要約する仕組みを収集フローに組み込んでいます。似た要望をまとめて合算の共感度を見られるようにしているのも、フレームワークに入力する前のデータの質を上げるための工夫です。実際の画面はデモボードで確認できます。
まとめ
RICE・Kano・MoSCoWはいずれも優先順位づけを助ける有用な型ですが、要望の背景にある理由を保存し損なうと、どのフレームワークを使っても判断の質は上がりません。フレームワークを使う前に、要望の理由をどれだけ言葉にできているかを見直すことが、実務では効果的です。フィードバック管理ツールの選び方全般は「フィードバック管理ツールとは?個人開発〜小規模SaaSのための選び方」でも整理しています。