RICEスコアの使い方と限界｜PMが推定の根拠を確かめる方法
機能要望に点数を付けたあと、上位の要望を選んだ理由を説明できますか。
RICEスコアは、影響を受ける対象の数・影響の大きさ・推定への確信度を掛け、総工数で割って候補を比べる指標です。プロダクトマネージャー（PM）が数字の根拠までそろえておくと、点数の差が何から生まれたかを説明しやすくなります。
この記事では、計算の条件をそろえ、推定が変わった場合の順位を確かめる手順を扱います。候補を選ぶ全体の流れを知りたい場合は、開発する機能の優先順位を決める方法が参考になります。
- 期間・対象・目標をそろえて、RICEスコアを比較する
- 推定の根拠を残し、値を変えて再計算する
- 点数と判断理由を分け、追加確認の担当を決める
PMはRICEの計算前に期間・対象・目標をそろえる
比較する候補どうしで、期間・対象・目標を変えないようにします。たとえば、対象が「次の四半期に月次集計を使う顧客企業」で、目標が「集計作業の手間を減らす」なら、その条件に対して各機能を評価します。顧客企業の社数と個々の利用者数を混ぜると、点数を同じ意味で読めません。
RICEを考案した顧客対応ソフトウェア企業Intercomは、原典の説明で次の4要素を使っています。
| 要素 | 確かめる内容 |
|---|---|
| Reach（到達範囲） | 一定期間に影響を受ける人数やイベント数 |
| Impact（影響度） | 対象1人にとっての、目標への影響の大きさ |
| Confidence（確信度） | 到達範囲・影響度・工数の推定を支える根拠 |
| Effort（工数） | プロダクト・デザイン・開発を含むチーム全体の人月 |
計算式は「Reach × Impact × Confidence ÷ Effort」です。原典のImpactは3・2・1・0.5・0.25、Confidenceは100%・80%・50%という尺度です。計算時の80%は0.8として掛けます。これらはIntercomの評価尺度であり、成功確率を測った統計値ではありません。
本記事では、BtoBの判断に合わせて到達範囲を社数、影響度を1社の業務への影響として扱います。この変更を評価表に明記しておけば、別の担当者も同じ条件で計算できます。社数を採用した表に、一部の候補だけ利用者数を入れないよう注意してください。
点数の隣に、推定の根拠を残す
PMは各要素の根拠となる記録と確認日を残し、開発担当は見積もりに含む作業と含まない作業を書きます。最終的な点数だけでは、次の会議で誰も見積もりを見直せません。
たとえば到達範囲を見積もるなら、登録社数をそのまま使う前に、対象業務を利用している社数を確かめます。問い合わせが届いた社数は、利用する見込みの社数と同じとは限りません。根拠がない欄は推測で埋めず「未確認」と残すほうが、追加調査の対象を選べます。
Impactは、「便利になる」と書くだけでは尺度がそろいません。「転記作業が不要になる」「転記は残るが確認の手間が減る」のように、顧客の作業がどう変わるかを併記します。背景を聞く方法は、ユーザーインタビューの質問と進め方で確認できます。
工数には、調査・設計・テストなど必要な作業をすべて含めます。ロードマップ作成ツールのProductPlanも、RICEの説明のEffort節で、デザインやテストを含む全体のリソースを挙げています。人月は作業量なので、その数値をそのまま公開までの月数として顧客に伝えることはしません。
確信度は熱意で上げず、どの推定に根拠が足りないかを記録します。以下は本記事の運用案です。利用記録、顧客への確認、開発の見積もりを別々に確かめ、弱い根拠を一文で残しておくと、次に調べる対象が明確になります。
推定値を変え、順位が入れ替わる条件を探す
最初の点数を確定値として扱わず、不確かな値を変えて再計算します。以下は、月次集計ツールの改善を考える架空の例です。社数・工数・点数は説明用の仮定で、実在企業の実績ではありません。
対象期間は次の四半期、目標は集計作業の手間を減らすこととします。PMが1社への影響を評価し、開発が総工数を見積もった場合を考えます。
| 候補 | Reach（社） | Impact | Confidence | Effort（人月） | スコア |
|---|---|---|---|---|---|
| 集計条件の保存 | 40 | 1 | 80% | 1 | 32 |
| 入力漏れの通知 | 20 | 2 | 80% | 1.5 | 約21.3 |
この仮定では、集計条件の保存が上位です。しかし、開発が権限ごとの動作確認を追加し、保存機能の工数を2人月へ見直すと、同機能のスコアは16になります。通知の値が変わらなければ、順位は逆転します。
この逆転を、開発担当の見積もりミスとして扱う必要はありません。「保存機能の範囲を確かめないと順位を決められない」と分かったことが、再計算の成果です。開発担当が権限の仕様を調べ終えるまでは比較結果を確定せず、PMが確認日を決めておきます。
影響度も同じように試せます。通知のImpactを2から1へ下げると、通知のスコアは約10.7です。この場合は、通知だけで手間が減ると見込んだ根拠を、顧客の業務に照らして確かめます。この試算は将来の成果予測ではなく、どの仮定が判断に効くかを探すためのものです。
点数と判断理由は、分けて記録する
スコア順と実際の着手順が違う場合は、その理由を記録に残します。Intercomの原典も、他の機能の前提になる作業や販売上の必須条件があれば、低いスコアの候補を先に進める場合を説明しています。
理由に合わせて点数を書き換えると、比較した記録が残りません。前の例なら、「保存機能は工数の範囲を確認中」「通知は顧客の作業への影響を確認中」と記録します。担当と確認日がなければ、追加確認を誰も引き取れません。調査が終わる前に、上位の機能の実装日を約束する必要はありません。
元の値・変更後の値・変更理由を保存しておけば、次の担当者も同じ条件で再評価できます。顧客の原文と判断の履歴を残す台帳は、顧客要望の管理表テンプレートで扱っています。記録が分かれていても、要望IDをそろえておけば比較の根拠をたどれます。
よくある質問
RICEスコアが何点以上なら採用すべきですか？
全チームに共通する採用点は決められません。対象の数や期間によって点数が変わるため、同じ条件で計算した候補どうしを比べ、使える工数も確認します。
データがない要望にも点数を付けるべきですか？
先に、不足している根拠と確認方法を残します。仮の点数を付ける場合も仮定を明記し、その値だけで実装を確約しません。
まとめ
PMは期間・対象・目標をそろえてRICEスコアを比較します。推定の根拠を残し、値を変えて再計算すると、着手前に確かめるべき点が見つかります。最後に点数と判断理由を分け、追加確認の担当を決めておけば、順位を選んだ理由を説明できます。
