RICEスコアリング

RICEはReach、Impact、Confidence、Effortの略だ。ある施策を評価するには、Reach（これは一定期間にどれだけのユーザーに触れるか？）と、Impact（0.25〜3のような定義済みの尺度で評価される、ユーザー1人あたりの指標をどれだけ動かすか）と、Confidence（0から1までの小数で表される、その推定に対する確信の割合）を掛け合わせ、それを人月で測ったEffortで割る。500人のユーザーに影響し、Impactが高く（2）、Confidenceが80%、2人月の作業量である機能は、500 × 2 × 0.8 ÷ 2 = 400というスコアになる。

この計算式は意図的にシンプルに作られている。その力は、チームに自分たちの前提を明示的で比較可能なものにさせることから来る。Confidenceが低い投機的な大博打は自動的に評価を下げられ、一方でReachが大きく素早く実行できる修正は、誰かがそのために議論しなくても自然と上位に浮かび上がる。

RICEは、その入力が直感ではなく実際のデータに根ざしているときに最も役立つ。影響を受けるワークフローを実際に使っている顧客が何人いるかを照会できるようになると、Reachの推定は改善する。過去の似た変更がリテンションや収益を動かしたかどうかを追跡できると、Impactの推定は精緻になる。声の大きい1人のステークホルダーではなく、フィードバックの量と顧客の信号が仮説の背後にあるとき、Confidenceは高まる。

AIOProductOSのようなプロダクトのオペレーティングシステムは、まさにこの根拠付けのために設計されている。基盤が顧客、収益、フィードバック、プロダクトの作業を一か所に結びつけているため、Reachを推定する際には、実際にどれだけの有料アカウントが該当のフローに触れているかを確認できる。Impactを推定する際には、レポートやOKRの中で似た作業が何を生み出したかを見ることができる——推測するのではなく。

最大の失敗パターンは、証拠ではなく主張の強さにスコアを紐づけてしまうことだ——政治的な議論に勝つために、ReachやImpactを実際より大きく見せる。2つ目の落とし穴は、Confidenceを固定値として扱うことだ（チームはしばしばすべての項目に80%をデフォルトで当てはめてしまい、それによって信号が失われる）。3つ目は、Effortの膨張を無視することだ。1人月から4人月に膨らんだ機能は、スプリントの途中でRICEスコアが半分になってしまう。

新しい顧客データが届いたり、ビルドがリリースされて分析データが生まれたりするたびにRICEスコアを見直すチームは、四半期の初めに一度だけスコアを付けて、その後は数字に一切触れないチームよりも多くの成果を得られる。