フレームワーク活用ガイドひとことで言うと#
Reach（リーチ）× Impact（インパクト）× Confidence（確信度）÷ Effort（工数） でスコアを算出し、限られたリソースでどの施策を優先すべきかを定量的に判断するフレームワーク。「声の大きい人の意見」や「直感」ではなく、データに基づいた優先順位づけを実現する。
押さえておきたい用語#
- Reach（リーチ）
- 一定期間内にその施策が影響を与えるユーザー数のこと。「1四半期あたりの対象ユーザー数」で統一するのが一般的。
- Impact（インパクト）
- 個々のユーザーに対する影響度を5段階（3/2/1/0.5/0.25）で評価した値のこと。ユーザーデータを根拠に判断する。
- Confidence（コンフィデンス）
- ReachとImpactの見積もりに対する自信の度合いをパーセンテージで表した値のこと。データ裏付けが弱い施策ほど低くなる。
- Effort（エフォート）
- 施策の実現に必要な開発・デザイン・QA等を含む総工数のこと。「人月」や「人週」で見積もる。
- RICEスコア（RICE Score）
- R×I×C÷Eで算出される施策の優先度を表す数値のこと。絶対値ではなく施策間の相対比較に使う。
RICEスコアリングの全体像#
こんな悩みに効く#
- やりたい施策が多すぎて、どれから手をつければいいかわからない
- 機能要望の優先順位が「声の大きい人」の意見で決まってしまう
- 開発リソースが限られているのに、すべてを同時にやろうとしてしまう
基本の使い方#
一定期間内に、その施策が影響を与えるユーザー数を見積もる。
- 単位を統一する: 「1四半期あたりのユーザー数」が一般的
- 実データに基づく: アクセスログ、利用状況データから算出
- 例: 「検索機能改善」→ 月間で検索機能を使うユーザーが5,000人 → Reach = 5,000/月
ポイント: 「全ユーザーに影響する」と雑に見積もらない。実際にその機能に触れるユーザー数を正確に把握する。
個々のユーザーに対する影響度を5段階で評価する。
- 3 = Massive: ユーザー体験を根本的に変える
- 2 = High: 大きな改善
- 1 = Medium: そこそこの改善
- 0.5 = Low: 小さな改善
- 0.25 = Minimal: ほぼ気づかないレベル
この評価は主観が入りやすいので、ユーザーインタビューやアンケートの結果を根拠にする。「自分たちが大事だと思うか」ではなく「ユーザーにとってどれだけ重要か」で判断する。
リーチとインパクトの見積もりに対する自信の度合いをパーセンテージで表す。
- 100%: データに裏付けられている
- 80%: おおむね確信がある（一部仮説）
- 50%: 半々。やってみないとわからない
- 20%以下: ほぼ勘
確信度が低い施策は、まず小規模な検証（A/Bテスト、ユーザーインタビュー）を行って確信度を上げるという選択肢もある。
施策に必要な工数を「人月」や「人週」で見積もる。デザイン、開発、QAなどすべて含める。
RICEスコア = (Reach × Impact × Confidence) ÷ Effort
例:
- 施策A: (5,000 × 2 × 80%) ÷ 3人月 = 2,667
- 施策B: (10,000 × 1 × 50%) ÷ 1人月 = 5,000
- 施策C: (2,000 × 3 × 100%) ÷ 6人月 = 1,000
→ 施策B > 施策A > 施策C の順に優先度が高い。
スコアは絶対的な答えではなく、議論のための材料。スコアの大小だけで機械的に決めず、戦略的な判断も加味する。
具体例#
チームが検討中の4つの施策をRICEスコアで比較する。
| 施策 | Reach（月） | Impact | Confidence | Effort（人月） | RICEスコア |
|---|---|---|---|---|---|
| モバイルアプリ対応 | 8,000 | 2 | 80% | 4 | 3,200 |
| Slack連携 | 3,000 | 3 | 100% | 2 | 4,500 |
| ダッシュボード刷新 | 10,000 | 1 | 50% | 3 | 1,667 |
| CSV一括インポート | 500 | 2 | 100% | 0.5 | 2,000 |
結果: Slack連携（4,500）が最優先。モバイルアプリ対応（3,200）が次点。
議論のポイント:
- ダッシュボード刷新はReachは最大だがConfidenceが低い → まずユーザーインタビューで確信度を上げてから再評価
- CSV一括インポートは少数だが確実なニーズ。工数が少ないので「ついでにやる」候補
- モバイルアプリは戦略的に重要（競合が対応済み）なので、スコア以外の要素も考慮して優先度を上げる判断もあり
RICEスコアだけで自動的に決まるわけではないが、「なぜこの順番なのか」を数字で説明できることが最大の価値。
月商8,000万円のファッションECサイト。グロースチーム3名で次月の施策を5つの候補から2つに絞る。
| 施策 | Reach（月） | Impact | Confidence | Effort（人週） | RICEスコア |
|---|---|---|---|---|---|
| 商品レコメンド改善 | 120,000 | 2 | 80% | 6 | 32,000 |
| チェックアウトUI改善 | 45,000 | 3 | 90% | 3 | 40,500 |
| お気に入りリスト共有 | 15,000 | 1 | 50% | 2 | 3,750 |
| 配送日時指定機能 | 80,000 | 0.5 | 100% | 1 | 40,000 |
| サイズレコメンドAI | 30,000 | 2 | 30% | 8 | 2,250 |
結果: チェックアウトUI改善（40,500）と配送日時指定（40,000）が僅差でトップ2に。
サイズレコメンドAIの判断: スコアは最低だが、Confidenceが30%と低いことが原因。技術検証（PoC）を2週間で実施し、Confidenceが80%以上に上がれば来四半期に再評価する方針とした。
**整理すると、スコアだけでなく「Confidenceを上げるアクション」を次ステップとして定義できるのがRICEの強み。数字が低い＝やらない、ではなく「まず検証する」という選択肢が生まれる。
従業員12名のヘルスケアスタートアップ。クリニック向け予約システムの改善要望が30件以上溜まり、開発チーム4名のリソースを最適配分する必要があった。
上位5施策のRICEスコア:
| 施策 | Reach（月） | Impact | Confidence | Effort（人月） | RICEスコア |
|---|---|---|---|---|---|
| LINE予約連携 | 2,000 | 3 | 80% | 2 | 2,400 |
| 予約リマインド自動化 | 3,500 | 2 | 100% | 1 | 7,000 |
| 電子カルテ連携 | 800 | 3 | 50% | 5 | 240 |
| 患者ポータル | 1,500 | 2 | 60% | 4 | 450 |
| 待ち時間表示 | 4,000 | 1 | 90% | 0.5 | 7,200 |
結果: 待ち時間表示（7,200）と予約リマインド自動化（7,000）を優先実施。
ステークホルダーとの合意: 院長から強い要望があった電子カルテ連携は、スコア表を見せて「Confidenceが50%なので、まずPoC（2週間）で技術的実現性を確認しましょう」と提案。「声の大きいステークホルダー」に対して数字で対話できた。
3ヶ月後: 待ち時間表示導入後、患者のクリニック滞在時間の体感不満が42%減少。予約リマインドで無断キャンセル率が15%→4%に低下。小さな工数で大きな効果を出す施策から手をつけた結果、顧客満足度が急速に向上した。
やりがちな失敗パターン#
- Impactを全部「High」にする — 自分が推したい施策のインパクトを高く見積もりがち。ユーザーデータやフィードバックを根拠にし、チームで合意して評価する
- Effortを過小評価する — 開発だけでなく、デザイン・QA・ドキュメント・サポート対応の工数も含める。「思ったより大変だった」を防ぐ
- スコアを神聖視する — RICEはあくまで意思決定の補助ツール。戦略的な重要性、技術的負債の解消、法規制対応など、スコアに反映されない要素も考慮する
- 一度評価したら更新しない — 市場環境やユーザーデータは変わる。四半期ごとにRICE値を再評価し、Confidenceが上がった施策は優先度を引き上げる運用ルールを設ける
まとめ#
RICEスコアリングは「Reach × Impact × Confidence ÷ Effort」というシンプルな式で、施策の優先順位を定量的に比較するフレームワーク。完璧な数字を出すことが目的ではなく、「なぜこれを先にやるのか」をチームで議論し、合意するための共通言語を提供する。直感に頼らない意思決定の第一歩として、バックログ整理の場で試してみよう。