RICEスコアリング:計算式、具体例と落とし穴
1分で読めます
RICEスコアリングは、リーチ × インパクト × 確信度 ÷ 工数という一つの数値でプロダクトのアイデアに順位をつける。スコアが高いほど、作業の単位あたりの期待価値が大きい。この方法はIntercomのプロダクトチームから生まれ、勘では差がつかない機能リクエストを比べる標準的な手段になった。真剣な候補の短いリストに使うのが最も効果的で、結果の質は入力する見積もりの質を超えない。
| 指標 | 答える問い | 単位または尺度 |
|---|---|---|
| リーチ | 一定期間に何人に影響するか | 四半期あたりの人数またはイベント数 |
| インパクト | その一人ひとりの目標をどれだけ動かすか | 3 非常に大きい、2 大きい、1 中、0.5 小、0.25 ごくわずか |
| 確信度 | 他の三つの数値にどれだけ自信があるか | 100% 高い、80% 中、50% 低い |
| 工数 | チーム全体でどれだけの作業か | 人月 |
RICEスコアの計算式は何か
スコアは リーチ × インパクト × 確信度 ÷ 工数 だ。リーチ、インパクト、確信度は、それぞれが見返りを増減させるので掛け算にする。工数は、同じ見返りでも作業が多いほどコストが高くなるので割り算にする。リーチの期間は四半期のように一つに決め、すべての項目に使う。そうしないとスコアを比べられない。
Intercomの元の解説記事が上の表の尺度を定義しており、ほとんどのチームは人どうしでスコアを比べられるように、そのまま変えずに使っている。
RICEの各指標はどう採点するか
リーチは、すでに持っているデータから出す。機能リクエストなら、まず要望したアカウントの重複を除いた数から始め、要望しなくても使うと思われるアカウントの見積もりを足す。インパクトは最も精度の低い指標なので、五段階の尺度を使い、小数を作り出さないようにする。確信度は推測に対する割引だ。利用データやテスト済みのプロトタイプがあるときだけ100%、強い兆候があるなら80%、ほとんど推測なら50%とする。工数は、設計とテストを含む関係者全員の時間を人月で表す。
同じ項目を二人が採点したら、どの指標でも差は一段階以内に収まるはずだ。収まらないなら、その項目は順位をつけられるほど理解されておらず、食い違いそのものが発見だ。
RICEスコアリングの具体例はどうなるか
追跡中のバックログから四つのリクエストを取り、一四半期で採点する。
| リクエスト | リーチ | インパクト | 確信度 | 工数 | スコア |
|---|---|---|---|---|---|
| CSV一括エクスポート | 400 | 1 | 80% | 1 | 320 |
| ダークモード | 1,200 | 0.5 | 100% | 2 | 300 |
| Slack連携 | 250 | 2 | 50% | 2 | 125 |
| シングルサインオン | 60 | 3 | 80% | 3 | 48 |
最初の行を計算すると、400 × 1 × 0.8 ÷ 1 = 320 になる。ダークモードは3倍の人数に届くが、一人あたりの利益は小さいので、エクスポートのすぐ下に位置する。Slack連携はインパクトの点数が良いものの、確信度で半分になっており、次にやるべきことは作ることではなく調査だとわかる。
シングルサインオンは最下位になるが、ここはもう一度よく見る価値がある。60アカウントというリーチは小さい。しかしそれが大口のアカウントで、更新の契約がいくつかこの機能にかかっているなら、スコアはこの方法では見えない何かを見落としている。
RICEのよくある間違いは何か
一つ目は、見かけの精密さだ。リーチ1,247、インパクト1.3という数値は厳密に見えるが、1,200と1より多くの情報を持っているわけではない。思い切って丸める。
二つ目は、すでに作ると決めた項目を採点することだ。すると本命が勝つまでスコアが調整され、この作業は言い訳を作るだけになる。
三つ目は、誰が要望したかを無視することだ。RICEは人数を数えるので、小さな10アカウントからの要望が、その10社の合計より価値の大きい1アカウントからの要望に勝ってしまう。収益が重要な場合は、収益の列を加えてスコアの横に並べて読む。アカウントによる重みづけは機能リクエストの優先順位づけで扱っている。
四つ目は、異なる期間や、異なるチームの尺度でスコアを比べることだ。シートは一つ、期間は一つ、定義も一組にする。
RICE以外を使うべきなのはどんなときか
リーチのデータがないときは、ICE(インパクト、確信度、容易さ)を使う。リーチを外し、工数を容易さの評価に置き換えたもので、粗くなることは受け入れる。どれだけかではなく、機能がどんな種類の価値を持つかが問いなら、カノモデルがリクエストを当たり前品質、一元的品質、魅力的品質の機能に分類してくれ、二つは組み合わせやすい。決めたいのが順位ではなく順番とタイミングなら、ロードマップの形式のほうが合っており、プロダクトロードマップの作り方で扱っている。
RICEスコアを時間がたっても正直に保つにはどうするか
結果だけでなく、入力値もスコアの隣に保存し、どの前提が順位を決めたのか誰でも見られるようにする。事実が変わったら項目を見直す。たとえば新しい要望が届いてリーチが上がったときや、エンジニアが工数が倍になると気づいたときだ。出荷後は、予測したリーチとインパクトを実際の結果と比べ、次の見積もりのやり方を調整する。リーチの元になるのは、機能リクエストの追跡で説明している、まとめてラベルを付けたリクエスト一覧だ。結果は、要望した人たちに送る返信に盛り込むべきだ。
FAQ
良いRICEスコアとはいくつか? スコアはリーチの期間と工数の単位に左右されるので、普遍的な基準値はない。スコアは同じシートの中だけで比べ、出力として扱うのは絶対値ではなく順位だ。
RICEとICEスコアリングの違いは何か? ICEはインパクト、確信度、容易さを掛け合わせ、リーチを含めない。記入は速いが、機能が影響するユーザー数が大きく異なる場合は精度が下がる。RICEはまさにそのケースのために設計された。
機能リクエストのリーチはどう見積もるか? 要望したアカウント数から始め、要望がなくても使いそうなアクティブアカウントの割合を足し、合計を四半期あたりで表す。推測が粗いなら、精度を作り出すのではなく確信度を下げる。
すべての機能リクエストをRICEで採点すべきか? いいえ。採点の手間に見合うのは、決着をつける材料が要るほど僅差の少数の項目だ。明らかに取り組むべきものと明らかに断るべきものは、採点なしで決められる。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。