概要
RICEの各項目に算出根拠を持たせる
「なんとなく効きそう」ではスコアの妥当性を説明できない。過去の類似施策の実測データ・対象母集団の実数を根拠にし、期間・粒度を施策間で統一する。
Confidenceはデータの有無で機械的に決める
全施策を100%固定にすると、実績豊富な施策と未検証の施策が同列になり、不確実性を織り込むというRICEの本来の目的が失われる。
スコアの高さと実行可能な順序は別物
最高スコアの施策が別の施策の技術基盤に依存している場合、スコア順に着手するとブロックされる。依存関係グラフを描いてから実行順を組む。
スコアは固定値ではなく定期更新する運用にする
実測データが出るたびにConfidence/Impactを見直すレビュー日を明示的に置かないと、古い前提のままスコアが独り歩きする。
問題
ECサイト MOps 販促システムチームは、来四半期に着手できるエンジニア工数に上限があるため、バックログにある5つの施策案を RICEスコアリング（Reach × Impact × Confidence ÷ Effort）で優先順位付けし、役員会にスプリント割当ロードマップとして提出することになった。
あなたはMOpsチームのシニアエンジニアとして、後輩PdM見習いが作成した以下の Bad RICEスコアシートをレビューし、実際にスプリント計画へ落とし込める精度まで再設計することになった。以下のドラフトには 7つの問題点が潜んでいる。問題点を全て洗い出し、Good RICEスコアシート + ロードマップへ再設計してください。
制約・前提条件（正）
- MAU（月間アクティブユーザー）: 500万人
- トップページ訪問者数（月間）: 300万人 — 施策Aのパーソナライズドバナーが実際に表示される対象
- 商品詳細ページ到達ユーザー数（月間）: 350万人 — 施策Dの価格表示が実際に見られる対象
- カート放棄ユーザー数（四半期実績）: 15万人
- 誕生日該当ユーザー数（月間）: 8万人
- 購入済み未レビューユーザー数（四半期対象）: 60万人
- 過去の類似施策の実測データ: パーソナライズドバナー系（昨年実施の「おすすめ表示A/Bテスト」）はCVR +0.3pt（相対+8%）の実績あり。カート放棄リマインドメール（過去に同種施策実施済み）はCVR回復率12%の実績あり。レビュー投稿促進（過去にポイント付与で実施）はレビュー投稿率+5ptの実績あり（売上への直接影響は間接的）。誕生日クーポンは自社実績データなし、他社事例のみ。在庫連動リアルタイム価格表示は自社未実施で検証データなし
- Effort内訳（人日、QA・リリース作業込み）: A=実装15人日+QA5人日+リリース2人日=22人日、B=8人日、C=12人日、D=40人日（在庫APIとの連携基盤構築を含む）、E=10人日
- 技術的依存関係: 施策Aのパーソナライズドバナー配信は在庫状況をレコメンドロジックへ組み込む設計になっており、施策Dで構築する在庫API連携基盤が無いと本実装に着手できない
- 後輩ドラフトは、RICE各項目の算出根拠・期間の統一・Effortの人日換算・施策間の技術依存関係・スコア見直しのタイミング、のいずれも検討されていない
期待する回答形式: 問題点の列挙（番号付き） + RICEスコア再計算表（Before/After比較、算出根拠列を含む） + 施策間の依存関係図 + スプリント割当ロードマップ + スコア再評価タイミングの定義
悪いRICEスコアシート (Before)
このドラフトには 7つの問題 が隠れています。見つけてみてください。
Bad ドラフト — 根拠なし・単位不統一・依存関係無視
四半期 優先施策 RICEスコアリング（後輩ドラフト）
| 施策 | Reach | Impact | Confidence | Effort | RICEスコア |
|--------------------------------|------------------|----------------------|-----------|--------|-----------|
| A パーソナライズドバナー配信 | 500万人(全MAU) | 3(なんとなく効きそう) | 100% | 1ヶ月 | 1,500万 |
| B 誕生日クーポン自動配布 | 8万人(月間該当者) | 2 | 100% | 2週間 | 32万 |
| C カート放棄リマインドメール | 15万人(四半期実績)| 5(過去の成功体験) | 100% | 3週間 | 100万 |
| D 在庫連動リアルタイム価格表示 | 500万人(全MAU) | 4 | 100% | 2ヶ月 | 1,000万 |
| E レビュー投稿促進キャンペーン | 500万人(全MAU) | 1 | 100% | 1ヶ月 | 500万 |
優先順位(スコア高い順): A → D → E → C → B
← 問題⑥: AはDの在庫API基盤に依存するのにA→Dの順でスプリントを組んでいる
この順番でスプリント1〜5に1施策ずつ割り当てて着手する。
← 問題⑦: スコアは四半期を通して固定、再評価のタイミングが無い問題点サマリー（7点）
1Reachの期間・粒度が施策ごとにバラバラ — A/D/Eは実際の接触対象ではなく全MAU500万人を機械的に当てはめている
2Impactが主観点のみ — 「なんとなく」「過去の成功体験」という曖昧な記憶ベースで根拠データがない
3Confidenceが全施策100%固定 — 実績データの有無によるリスク差を無視
4Effortがアバウトな見積もり — 「◯ヶ月」のみで人日換算・QA/依存タスクが未計上
5各項目の単位・粒度が施策間で不統一 — スコアの大小比較自体に意味がない状態
6技術的依存関係を無視 — AはDの在庫API基盤が無いと着手できないのにA→Dの順で計画
7再評価タイミングが未定義 — スコアを四半期中固定値として扱っている
ヒント（段階的開示）
ヒント1 — 方向性
Bad版の罠は3系統。(1) RICE各項目の算出根拠の欠如 — Reachの対象期間・粒度が施策ごとにバラバラで比較不能、Impactが「なんとなく」「過去の成功体験」という曖昧な記憶ベース、Confidenceが全施策100%固定でリスク差を無視、Effortが「◯ヶ月」というアバウトな見積もりで人日換算されていない。(2) スコアだけで機械的に順序を決め、技術的依存関係を見ていない — 施策Aは施策Dの在庫API基盤が無いと着手できないにもかかわらず、スコア順にA→Dとスプリントを組んでしまっている。(3) スコアの鮮度管理がない — 一度算出したRICEスコアを四半期を通して固定値として扱い、新情報（実際のA/Bテスト結果・季節性等）が入った際に再計算するタイミングが定義されていない。
ヒント2 — アプローチ
- 問題①: Reachの対象期間・粒度が施策ごとにバラバラ → 四半期（90日）を評価期間の基準に統一し、各施策が実際にトリガーされる対象（トップページ来訪者・商品詳細到達者等）に絞る
- 問題②: Impactが実測データなしの主観点 → 過去の類似施策の実測データ（CVR変化・投稿率変化）から算出根拠を明記する。データが無い施策は保守的に見積もる
- 問題③: Confidenceが全施策100%固定 → データの有無で機械的に3段階（High 80% / Medium 50% / Low 20%）に分ける
- 問題④: Effortが「◯ヶ月」というアバウトな見積もり → 実装・QA・リリース作業・依存タスクを含めて人日で見積もる
- 問題⑤: RICE各項目の単位・粒度が施策間で揃っていない → Reach（四半期人数）・Impact（1-5、根拠付き）・Confidence（3段階%）・Effort（人日）に統一してから計算する
- 問題⑥: 施策AがDの在庫API基盤に依存しているのにスコア順（A→D）でスプリントを組んでいる → 依存関係グラフを作り、依存元（Dの基盤部分）を先行着手するロードマップに変更する
- 問題⑦: RICEスコアが一度算出されたら四半期中固定 → 四半期中間地点で新情報を反映して再計算するレビュー日を設定する
ヒント3 — 誘導
【RICEスコア再計算の骨格】
RICEスコア = Reach（四半期人数） × Impact（1-5、根拠付き） × Confidence（0.2/0.5/0.8） ÷ Effort（人日）
【依存関係グラフの骨格】
D（在庫API連携基盤構築）─┬─→ A（パーソナライズドバナー配信、Dの基盤が前提）
└─→ D自体の価格表示機能
【ロードマップの骨格】
Sprint1: Dの基盤部分（在庫API連携）を先行着手
Sprint2: A本実装 + Dの残り機能（価格表示）を並行
Sprint3: E（レビュー投稿促進）
Sprint4: C（カート放棄リマインド）
今四半期は見送り: B（誕生日クーポン、自社データなし・スコア最低）
【再評価タイミング】
四半期6週目（中間地点）に、実施済み施策の実測データ・季節性（年末商戦前）を反映してConfidence/Impactを再計算問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | Reachの期間・粒度が施策ごとにバラバラ | 根拠の欠如 | 四半期基準に統一、実際の接触対象に絞る |
| 2 | Impactが主観点のみで根拠データなし | 根拠の欠如 | 過去の類似施策の実測データから算出 |
| 3 | Confidenceが全施策100%固定 | リスク未反映 | データ有無で3段階（80/50/20%）に分ける |
| 4 | Effortがアバウトな月単位見積もり | 見積り精度 | 人日換算、QA/依存タスクを含める |
| 5 | 各項目の単位・粒度が施策間で不統一 | 比較不能 | Reach/Impact/Confidence/Effortを統一形式に |
| 6 | 技術的依存関係を無視したスコア順スプリント計画 | 依存関係 | 依存関係グラフ作成、実行可能な順序に組替 |
| 7 | スコアの再評価タイミングが未定義 | 鮮度管理 | 四半期6週目に再評価レビューを設定 |
優先順位付けプロセス比較 — Bad vs Good
模範解答
修正①②③④⑤: RICEスコア再計算表（Before/After）
Before（後輩ドラフト、算出根拠なし）
| 施策 | Reach | Impact | Confidence | Effort | RICEスコア |
|---|---|---|---|---|---|
| A パーソナライズドバナー配信 | 500万人(全MAU) | 3(なんとなく) | 100% | 1ヶ月 | 1,500万 |
| B 誕生日クーポン自動配布 | 8万人(月間) | 2 | 100% | 2週間 | 32万 |
| C カート放棄リマインドメール | 15万人(四半期実績) | 5(成功体験) | 100% | 3週間 | 100万 |
| D 在庫連動リアルタイム価格表示 | 500万人(全MAU) | 4 | 100% | 2ヶ月 | 1,000万 |
| E レビュー投稿促進キャンペーン | 500万人(全MAU) | 1 | 100% | 1ヶ月 | 500万 |
After（Good、算出根拠付き・単位統一）
| 施策 | Reach(四半期人数) | Impact(根拠) | Confidence | Effort(人日) | RICEスコア |
|---|---|---|---|---|---|
| A パーソナライズドバナー配信 | 300万人(月間トップページ来訪者) | 3 — 類似施策でCVR+8%実績あり | Medium 50% | 22人日 | 204,545 |
| B 誕生日クーポン自動配布 | 24万人(8万人×3ヶ月) | 1 — 他社事例のみ、自社実績なし | Low 20% | 8人日 | 6,000 |
| C カート放棄リマインドメール | 15万人(四半期実績) | 4 — CVR回復率12%実績あり | High 80% | 12人日 | 40,000 |
| D 在庫連動リアルタイム価格表示 | 350万人(月間商品詳細到達) | 4 — 理論的インパクト大だが未検証 | Low 20% | 40人日(在庫API基盤含む) | 70,000 |
| E レビュー投稿促進キャンペーン | 60万人(四半期対象) | 2 — 投稿率+5pt実績、売上影響は間接的 | Medium 50% | 10人日 | 60,000 |
Bad版は全項目の算出根拠が存在しないため「なぜその点数か」を役員会で問われた瞬間に説明できない。Good版はReach・Impact・Confidence・Effortそれぞれに根拠列を持たせることで、スコアの妥当性そのものをレビュー可能にしている。
修正⑥: 施策間の依存関係図
D: 在庫API連携基盤構築（Effort 40人日の中核部分）
│
├──→ A: パーソナライズドバナー配信（在庫状況をレコメンドロジックに使う設計のため、
│ Dの基盤が無いと本実装に着手不能）
│
└──→ D自体の価格表示機能（基盤構築後にリリース）
C: カート放棄リマインドメール（独立、依存なし）
E: レビュー投稿促進キャンペーン（独立、依存なし）
B: 誕生日クーポン自動配布（独立、依存なし）
RICEスコア単体ではA（204,545点）が最高スコアだが、Aの実装は技術的にDの在庫API連携基盤に依存している。スコア順に単純にA→D→E→C→Bとスプリントを割り当てると、Aに着手した瞬間に在庫APIが存在せずブロックされる。優先順位付けは「スコアの高さ」と「実行可能な順序」を分けて考える必要がある。
修正⑥: スプリント割当ロードマップ
| スプリント | 施策 | 内容 | 根拠 |
|---|---|---|---|
| Sprint 1 | D（基盤部分） | 在庫API連携基盤の構築を先行着手 | Aの前提条件を満たすため、スコア2位のDの基盤部分を最初に着手 |
| Sprint 2 | A本実装 ＋ D残り機能(価格表示) | 基盤ができた時点でAの本実装に着手、Dの価格表示機能も並行リリース | Dの基盤完成でAのブロッカーが解消。スコア最高のAを早期投入 |
| Sprint 3 | E レビュー投稿促進 | 独立施策、依存なし | RICEスコア3位(60,000)、実績データありで確度が高い |
| Sprint 4 | C カート放棄リマインド | 独立施策、依存なし | スコア4位(40,000)だがConfidence Highで実行確度は最高。工数が小さく前倒しの余地あり |
| 今四半期は見送り | B 誕生日クーポン | 着手しない | スコア最低(6,000)かつConfidence Low。来四半期に小規模検証してから再評価 |
Bad版の「スコア順に1施策ずつ機械的に割り当てる」計画を、依存関係を踏まえた実行可能な順序に組み替えている。Cは工数が小さくConfidenceが高いため、余剰工数が出た場合はSprint2と並行させる余地も残す。
修正⑦: スコア再評価タイミングの定義
- 四半期6週目（中間地点）にRICEスコアの再計算レビューを実施する
- 見直しトリガー: (1) Sprint1〜2で実施した施策の実測データ（Aの実際のCVR変化等）が出そろうタイミング、(2) 年末商戦前（11月末）という季節性を踏まえ、見送りにしたBやその他未着手施策の優先度を再評価するタイミング
- 再評価では、実測データが出た施策のConfidenceをLow/Mediumから引き上げ、逆に想定より効果が出なかった施策はImpactを下方修正する
RICEスコアリングは「その時点で分かっている情報での見積もり」に過ぎない。実測データが出るたびに更新することで、後続の優先順位付けの精度を継続的に上げていく運用にする。
ポイント解説
1RICEの各項目には必ず「なぜその数値か」という算出根拠を持たせる — 主観の点数だけでは、役員会でスコアの妥当性を問われた瞬間に説明が崩れる。過去の類似施策の実測データ、対象母集団の実数を根拠にすることで、スコアそのものがレビュー可能になる。
2Reach・Impact・Confidence・Effortは施策間で単位・粒度を統一してから比較する — 期間がバラバラ、粒度がバラバラのまま計算したスコアは、大小を比較すること自体に意味がない。
3Confidenceは「データの有無」で機械的に決める指標として運用する — 全施策を100%にすると、実績豊富な施策と未検証施策が同列に扱われ、不確実性を織り込むというRICEの本来の目的が失われる。
4スコアの高さと実行可能な順序は別物であり、技術的依存関係を必ず確認する — 最高スコアの施策が別施策の成果物に依存している場合、スコア順に着手すると開発が途中でブロックされる。
5RICEスコアは一度算出して終わりではなく、新しい実測データや季節性を反映して定期的に更新する運用として設計する — 明示的な再評価タイミングを置かないと、古い前提のままスコアが独り歩きし、優先順位が実態と乖離していく。
実務への応用
MOpsチームでは今後も、限られたエンジニア工数を複数の販促施策候補に配分する優先順位付けの局面が繰り返し発生する。本問題の型（算出根拠付きRICEスコア表 → 施策間の技術依存関係グラフ → 依存関係を踏まえたスプリント割当ロードマップ → 中間地点での再評価タイミング定義）は、四半期ごとのバックログ優先順位付けの標準プロセスとして再利用できる。
証券会社経験との接続: 限られた投資枠を複数の商品開発案に配分する社内審査でも「期待リターンの根拠」「実現確度（信頼度）」「必要投資額」を分けて評価し、かつ商品間の依存関係（先行してシステム基盤を整備しないと後続商品が出せない、等）を軽視すると計画が崩れる場面を見てきた。RICEスコアリングのような定量フレームワークも、根拠データと依存関係の可視化が伴って初めて、経営層に対して説得力を持つ優先順位付けになる。
今日のまとめ
RICEスコアリングは「Reach × Impact × Confidence ÷ Effort」という計算式さえ埋めれば成立するものではない。各項目に算出根拠を持たせ、期間・粒度を施策間で統一し、Confidenceをデータの有無で機械的に決め、Effortを人日で正確に見積もり、スコアの高さと技術的依存関係を分けて実行可能なロードマップに組み替え、新しい実測データが出るたびに再評価する、という一連の運用設計が揃って初めて、役員会に提出できる説得力のある優先順位付けになる。
次のステップ
- 発展問題: 四半期6週目の再評価タイミングで、実際にはAのパーソナライズドバナー配信のCVR実測値が期待（+8%相当）を大きく下回り、+1%程度にとどまったことが判明したとする。このとき、(1) 既にSprint2で投入済みの工数をどう扱うか、(2) 残りのC・E・Bの優先順位をどう見直すか、(3) 今後同様の「期待を下回った施策」が出た場合のRICE運用ルールをどう改善するか、の3点を踏まえた再評価レポートを作成せよ。
- 参考: RICEスコアリング（Reach/Impact/Confidence/Effort）、ICEスコアリングとの違い、優先順位付けフレームワークの依存関係管理、スコアリングの定期レビュー運用