やりたいことは30個あって、次の四半期に入るのは3つ。その3つをどうやって選びましたかと聞かれて、言葉に詰まったことはありませんか。
優先順位づけのフレームワークは、その説明を助けるための道具です。RICEやICEという名前を聞いたことがある方も多いと思います。
ただ、実際に使ってみると数字がひとり歩きします。スコアの高い順に並べたはずなのに、なぜか納得感がない。
この記事では、RICEとICEの中身を噛み砕いたうえで、スコアを主観の言い換えで終わらせないための運用方法を書きます。定義を覚えるためではなく、来週の会議で使うための道具として読んでください。
スコアが主観の言い換えになる瞬間
RICEもICEも、複数の観点を掛け算と割り算で1つの数字にまとめる道具です。まず定義を短く押さえます。
ICEは Impact（影響の大きさ）、Confidence（確信度）、Ease（やりやすさ）の3つを1〜10で見積もり、掛け合わせるやり方です。3つの数字だけなので、慣れれば15分で30項目を並べられます。
RICEは Reach（何人に届くか）、Impact（1人あたりの影響）、Confidence（確信度）、Effort（かかる工数）の4つを使い、R×I×C÷E で計算します。ReachとEffortに実数が入るぶん、ICEより説明力があります。
ここまでは教科書どおりです。問題はこの先。
よくあるのは、担当者が自分の推したい施策のImpactを3にして、気の進まない施策を1にするという現象です。悪気はありません。
数字を入れる根拠がないから、結論から逆算してしまうだけです。そうして出たスコアは、やりたい順を数字に翻訳しただけの表になります。
心当たり、ありませんか。スコア表を出すと、なぜか毎回それぞれの担当領域が上位に来る、あの感じです。
これを防ぐ方法はひとつしかありません。変数のうち少なくとも1つを、人の感覚ではなく実データで埋めることです。
1つでも動かせない数字が入ると、残りの見積もりも急に慎重になります。全部が可変だと結論から逆算できてしまいますが、片方が固定されていると逆算の余地が減るからです。
そして実データで埋めやすいのは、圧倒的にReachです。
RICEとICE、どちらをいつ使うか
2つを比べるとき、どちらが優れているかという議論はあまり実りません。使う場面が違うだけです。
| 観点 | ICE | RICE |
|---|---|---|
| 変数 | Impact / Confidence / Ease | Reach / Impact / Confidence / Effort |
| 向く場面 | 数十件をざっと粗選り | 残った候補の順位を確定 |
| 必要なもの | 経験と感覚 | 到達人数と工数の見積もり |
| 弱点 | 主観が入りやすい | 準備に時間がかかる |
実務では、二段構えにするのがいちばん楽です。まずICEで30件を10件に削り、残った10件だけRICEで丁寧に計算する。
全部にRICEをかけると、見積もりだけで2日が消えます。落選が確実な候補に、そこまでの精度は要りません。
ひとつだけ注意点があります。EaseとEffortは向きが逆で、Easeは大きいほど良く、Effortは小さいほど良い数字です。
同じ表に混ぜると、誰かが必ず取り違えます。列名に単位を書いておくだけで事故が減りますよ。
もう1つ、両方に共通する性質も押さえておくと迷いが減ります。
Confidenceはほかの変数と掛け合わされるため、確信の薄い施策はどれだけ規模が大きく見えても自動的に順位が下がります。
これは弱気になるための係数ではなく、調べれば上げられる係数だと考えてください。
Reachは、推測ではなく実数で入れる
RICEでいちばん化ける変数がReachです。ここに実測値が入るだけで、表全体の空気が変わります。
Reachは、決めた期間内にその施策が影響する人数のことです。四半期で回すなら3か月、月次なら1か月と、チームで単位を固定してください。
たとえば料金ページの見せ方を変える施策なら、Reachは直近3か月に料金ページを見た人数です。これは推測する必要がありません。
ページ別の閲覧数を見れば済む話です。Strideのようなウェブ解析ツールならページ別・流入元別・デバイス別の内訳がそのまま出るので、対象人数を数える作業は数分で終わります。
ここで1つだけ、単位の取り違えに注意してください。
Reachは人数であって、閲覧回数ではありません。同じ人が10回開いたページはReachとしては1人で、ページビューをそのまま入れると回遊の多いページだけが不当に大きく見えます。
実際に数えてみると、順位が入れ替わることがよくあります。数字で見てみましょう。
候補A: 料金ページによくある質問を追加する
Reach 料金ページの3か月UU 4,200
Impact 申込率への影響（中） 1.0
Conf 離脱データ + 操作記録の裏づけあり 0.8
Effort デザイン0.5人月 + 実装0.5人月 1.0
RICE = 4,200 × 1.0 × 0.8 ÷ 1.0 = 3,360
候補B: 管理画面のダークモード対応
Reach 要望を出した既存ユーザー 120
Impact 継続率への影響（小） 0.5
Conf 要望ベースのみ 0.5
Effort 実装2人月 + 検証0.5人月 2.5
RICE = 120 × 0.5 × 0.5 ÷ 2.5 = 12
280倍の差です。会議の熱量では候補Bのほうが盛り上がっていたとしても、この開きは感覚では埋まりません。
もちろん、候補Bを永久に捨てるという話ではありません。
狙いは、やらない理由ではなく、いま先にやらない理由を全員が同じ数字で共有できる状態をつくることです。
ここで気をつけたいことがあります。Reachに使う人数は、施策が実際に触れる場所の人数でなければ意味がありません。
サイト全体の月間UUを全施策のReachに入れてしまうと、全部同じ数字になって差がつかなくなります。Reachは施策ごとに違う分母を持つ、と覚えておいてください。
どこで人が減っているかを先に押さえておくと、この分母選びが速くなります。手順はファネル分析の基本｜離脱ポイントの見つけ方と改善の進め方にまとめています。
測れる範囲を、正直に線引きする
ひとつ正直に書いておきます。ウェブ解析ツールで取れるのは、サイト側の行動までです。
訪問、ページの回遊、フォームへの到達、コンバージョン、再訪。前の節で挙げたページ別の人数もその範囲の話で、ログイン後のプロダクト内で機能がどれだけ使われたかまでは追えません。
ですからReachの出どころは、施策の置き場所で使い分けます。サイト上の施策は解析ツール、プロダクト内の施策はアプリケーション側のログや利用状況データ、という分担です。
この線引きを曖昧にしたまま数字を並べると、あとで根拠を聞かれたときに答えられなくなります。表に出典の列を1つ足しておくだけで、ずいぶん楽になります。
Impact・Confidence・Effortを見積もるコツ
残りの3つは、どうしても見積もりが混ざります。だからこそ、決め方を先に固定してしまいます。
その前にひとつだけ、候補の粒度をそろえておいてください。
検索機能をまるごと作り直すという候補と、ボタンの文言を変えるという候補が同じ表に並んでいると、スコアの比較そのものが成り立ちません。
大きすぎる候補は、最初に価値が届く単位まで割ってから並べます。1つの候補が1〜2スプリントで終わる大きさが、ちょうどよい目安です。
Impactは刻みすぎない
Impactは1人あたりの効果の大きさで、0.25 / 0.5 / 1 / 2 / 3 の5段階が広く使われています。0.7と0.8を議論しはじめたら、時間の無駄だと思ってください。
刻みを細かくしても精度は上がらず、議論だけが伸びます。5段階で十分です。
コツは、基準になる施策を1つ決めてしまうことです。去年のあの改修をImpact 1とすると宣言すれば、以降の会話がすべてそれとの比較で進みます。
Confidenceは、根拠の種類で決める
Confidenceは0〜1の確信度ですが、感覚で0.7と言われても検証のしようがありません。そこで、根拠の種類ごとに数字を先に決めておきます。
| 根拠の種類 | Confidence | 具体例 |
|---|---|---|
| テストで実証済み | 1.0 | 同型の変更で改善を確認した |
| 実データと定性の両方 | 0.8 | 離脱の数字と操作の記録が一致 |
| 実データのみ | 0.5 | 数字は動くが理由は未確認 |
| 要望や思いつき | 0.2 | 会議で出た意見だけ |
この表があると、議論の性質が変わります。0.8にしたいなら定性の裏づけを取ってこよう、という具体的な宿題に化けるからです。
裏づけは、数字と声の両方から作ります。離脱している画面での操作を再現できると、なぜ止まったのかが見えることが多いです。
Strideのセッションリプレイは記録の時点で全テキストを伏せ字にし、入力値や画像は一切保存しません。個人情報を抱え込まずに、詰まっている箇所だけを確認できます。
根拠の作り方そのものを整えたい場合は、仮説検証型のプロダクト開発｜思いつきで作らないための型で扱っている仮説の型が土台になります。
Effortは人月より、チームの実測で
Effortは工数です。人月で書くチームが多いですが、見積もりの甘い組織では実態と2倍ずれます。
おすすめは、直近で完了した施策の実績を1件、基準として置くことです。あの改修が1.0と決めてから相対で見積もると、ずれが小さくなります。
そして、実装だけを数えないでください。仕様の詰め、デザイン、QA、リリース後の様子見まで含めて1つの数字にします。
実装1週間の施策が、前後の調整で3週間かかることは珍しくありません。ここを実装だけで数えると、細かい施策ばかりが上位に来る表になります。
このやり方が機能しない場面
フレームワークを紹介した以上、限界も書きます。スコアが向かない領域は確実にあります。
まず、新規事業や大きな賭け。Reachが実測できずConfidenceも低いので、スコアは必ず小さくなります。
既存改善だけが上位に並ぶ表になり、伸びしろのある挑戦が構造的に落ちる。これはフレームワークの欠陥というより、性質です。
次に来るのが、障害対応やセキュリティ、法令対応、限界が近いインフラといったやらないと壊れるものです。
これらはスコアの外側に置いて、先に枠を取ってください。
そして、依存関係のある施策。単体ではスコアが低くても、それがないと後続の3件が動かない土台なら、単独の点数で判断すると全体が詰まります。
だから運用としては、四半期の開発枠を先に分けてしまうのが現実的です。目安として、こんな配分から始めてみてください。
- 改善枠（およそ7割）：RICEの上位から順に入れる
- 探索枠（およそ2割）：スコアでは勝てないが、確かめる価値がある候補
- 保守枠（およそ1割）：不具合、技術的負債、セキュリティ
枠を先に決めておくと、探索的な施策を毎回スコアで殺さずに済みます。比率は組織の状況で変えて構いません。
もう1つ、スコアは意思決定を自動化する装置ではありません。最後に決めるのは人で、スコアはその判断を説明可能にするための材料です。
スコアを覆す決定をしても構いません。ただし、覆した理由は必ず記録しておきましょう。
記録といっても、表の右端に一言を足すだけで十分です。半年後に同じ議論が持ち上がったとき、その1行が驚くほど効きます。
もうひとつ、運用を続けると起きるのがスコアのインフレです。自分の案を通したい気持ちから、四半期を重ねるごとに全員の見積もりが少しずつ高くなっていきます。
対策は簡単で、前回の表を横に置いて見積もることです。新しい候補を、前回1.0を付けた施策と直接比べるだけで、水位は元に戻ります。
1時間で終わらせる、優先順位づけの進め方
最後に、実際の回し方です。長い会議にしないことがいちばん大事なので、時間を区切ります。
事前準備として、候補を1行ずつ書き出し、ReachだけをPMが埋めておきます。ここを会議中にやると、それだけで1時間が溶けます。
参加者は5人までに絞ると進みます。関係者を全員呼んでも、発言の総量が増えるだけで結論はあまり変わりません。
当日は、次の順番で進めると迷いません。
- ImpactとConfidenceを、参加者が同時に出す
- 数字がずれた項目だけ、理由を1人1分で話す
- Effortは開発メンバーが決める（PMは希望値を入れない）
- 計算して上から枠に入れ、入らなかった候補も表に残す
1つ目の同時に出すという点は、地味ですが効きます。順番に言うと、最初の発言に全員が引っ張られてしまうからです。
2つ目も大事です。全項目を議論する必要はなく、経験上ずれるのは全体の2〜3割にとどまります。
4つ目の残すという行為も忘れないでください。消してしまうと、来期また同じ議論をゼロからやり直すことになります。
開催の頻度も決めておくと楽です。ゼロから並べ直すのは四半期に1回で十分で、月次では順位の入れ替えと新しい候補の追加だけを10分で済ませます。
毎月フル稼働させると、そのうち誰も準備してこなくなります。軽く回せる形にしておくほうが長続きしますよ。
この表は、そのまま社内向けの説明資料になります。外に見せる形へ整える方法はデータで語るロードマップ｜優先順位を説明できるようにするで扱っています。
決めたあとに、答え合わせをする
優先順位づけは、決めた瞬間に終わりではありません。むしろ、決めたあとの答え合わせが見積もりの精度を育てます。
リリースした施策について、見積もったImpactと実際の変化を並べて記録してください。数か月続けると、自分たちが何を過大評価しがちなのかが見えてきます。
多くのチームは、新機能のImpactを高く、地味な導線改善のImpactを低く見積もる癖を持っています。実測を並べると、その癖が数字で表に出ます。
答え合わせの手段として素直なのが、A/Bテストです。元のページと変更後を同時に出し分けて比べれば、Impactの見積もりが当たっていたかが分かります。
StrideのA/Bテストはノーコードで、サイトを開いたままビジュアルに編集して作れます。ボタンの文言程度の検証なら、開発の順番待ちをせずに試せます。
進め方はA/Bテストの始め方｜ノーコードで検証する手順と注意点にまとめました。
そして、検証で得た確信は次の四半期のConfidenceに戻ってきます。この往復が回りはじめると、優先順位の議論は驚くほど短くなります。
まとめ
RICEもICEも、それ自体が答えを出す魔法ではありません。ただ、判断の材料を全員で共有するための共通言語としては、とても優秀です。
やることは3つでした。Reachを実データで埋める、Confidenceを根拠の種類で決める、枠を先に分けてスコアの外側を守る。
そして忘れがちなのが、測れる範囲を正直に線引きすることです。サイト側の数字とプロダクト内の数字を混ぜないだけで、根拠の強さが変わります。
次の優先順位づけの前に、上位5件のReachだけでも実数に置き換えてみてください。それだけで、会議の質は確実に変わります。