2026年10月8日にIntercomのRICE説明とGOV.UK Service ManualのDiscovery・ユーザー調査手順を再確認した。RICEは期間を置いた到達数、影響、確信度、工数を比較する補助線で、スコアの低い案を必ず後回しにする規則ではなく、依存関係・法令・期限・検証価値の例外を理由付きで残す。Discoveryでは解決策を作り始めず、利用者、制約、代替、成功指標を調べ、進む・止める・調べ直す条件を決める。
30秒で要点
問題の優先順位付けは、声の大きさや思いついた機能の魅力を競う作業ではありません。誰のどの困りごとを、いつまでに、どの根拠で扱うかをそろえ、今すぐ止める対応と、後で検証する投資を分けます。
- 問題: 観察できた行動・損失・制約を一文にする
- 優先度: 影響、緊急度、確信度、コスト、依存関係を別の列にする
- 検証価値: 作る前に不確実性を減らせる問いを置く
- 記録: 仮説、測定値、決定者、見直し日、停止条件を残す
1. 先に「問題」を書き、解決策を隠す
「検索をAI化する」「ダッシュボードを作る」は解決策です。問題票には、誰が、どの状況で、何をしようとして、どの障害に遭い、何が起きているかを書きます。
表が収まらない場合は、横にスクロールできます
| 問題票の欄 | 記入例 | 確認すること |
|---|---|---|
| 利用者・業務 | 新規顧客の初回設定 | 対象を推測せず、利用ログや観察を照合する |
| 状況 | 初回ログイン後に設定画面へ進む | 前後の行動と離脱を定義する |
| 障害 | 必須項目の意味が分からない | 画面の問題か、制度・データの制約か |
| 影響 | 設定未完了、問い合わせ増 | 件数、割合、金額、時間を期間付きで記録する |
| 根拠の強さ | 定量ログと5件の観察 | 未確認の仮説を別ラベルにする |
GOV.UK Service ManualのDiscoveryは、作る前に利用者、目的、制約、改善機会を調べ、前へ進む価値があるかを判断する段階です。問題の文章が書けないなら、優先順位より先に調査の問いを作ります。
2. 影響と緊急度を分ける
影響が大きくても期限が遠い問題と、影響が限定的でも今日止めるべき問題があります。次の二軸を別々に採点し、理由を短く残します。
表が収まらない場合は、横にスクロールできます
| 軸 | 質問 | 例 |
|---|---|---|
| 影響 | 解決すると、誰のどの結果がどれだけ変わるか | 完了率、時間、損失、アクセシビリティ |
| 緊急度 | いつまでに対応しないと被害・機会損失が増えるか | 法定期限、障害、契約、季節性 |
| 可逆性 | 間違えたときに戻せるか | 設定変更、停止、データ移行 |
| 到達範囲 | 対象がどの程度広いか | 1チーム、全顧客、特定の利用者群 |
緊急度が高いときは、機能開発の前に公開停止、設定変更、案内、手作業など被害を抑える選択肢を並べます。暫定対応をしたことで問題が消えたのか、根本原因が残っているのかも別に記録します。
3. RICEを比較の補助線として使う
IntercomのRICEは、Reach（到達数）、Impact（個人への影響）、Confidence（見積もりの確信度）、Effort（必要な作業量）を組み合わせる枠組みです。式は概ね Reach × Impact × Confidence ÷ Effort ですが、入力値が推定なら結果も推定です。
表が収まらない場合は、横にスクロールできます
| 列 | 書き方 | 留保 |
|---|---|---|
| Reach | 定義した期間の利用者・取引・業務数 | 同じ対象と分母で比較する |
| Impact | 目標への影響を段階評価 | 「大」だけで成果を保証しない |
| Confidence | データ、観察、専門判断の確度 | 未検証は低く置き、調査課題にする |
| Effort | プロダクト、設計、運用、移行の総量 | 開発者の工数だけにしない |
RICEが低くても、依存関係を解除する作業、法令や安全の最低条件、学習価値の高い小実験は先に行うことがあります。点数を並べ替えたあと、例外と理由を別列に残すことで、点数への盲従を避けます。
4. 確信度を「調べる価値」へ変換する
確信度が低い問題は、いきなり大きく作るより、最小の調査・プロトタイプ・ログ追加で不確実性を減らせます。
- 何が不明かを一文で書く（利用者、原因、効果、制約）。
- 1〜2週間以内に答えられる調査方法を選ぶ。
- 観測する行動、対象、成功・失敗の判定を決める。
- 調査をやめる条件と、結果ごとの次の分岐を決める。
- 結果を優先順位表へ戻し、スコアと根拠を更新する。
ユーザー調査では、対象者の同意、代表性、プライバシー、観察と解釈の分離を記録します。GOV.UKはDiscoveryで幅広い利用者を調べ、後の段階でより具体的な問いへ絞る手順を示しています。
5. 依存関係と最低条件を別枠にする
スコア表だけでは、先に認証基盤を直さないと他の機能を試せない、という順序が見えません。依存関係、法令・安全・アクセシビリティの最低条件、期限のある作業を別の列またはゲートにします。
表が収まらない場合は、横にスクロールできます
| 種類 | 先に確認すること | 決定の記録 |
|---|---|---|
| 依存 | 他の作業が完了しないと試せないか | 解除する作業と責任者 |
| 最低条件 | リスク、法令、アクセシビリティを満たすか | 未達時の停止・相談 |
| 学習 | 何を学べば次の投資を判断できるか | 実験、期間、成功条件 |
| 機会 | 期限・市場・契約の窓があるか | 期限と逃した場合の影響 |
6. 優先順位表を決定へつなぐ
表が収まらない場合は、横にスクロールできます
| 問題 | 影響 | 緊急度 | 確信度 | 次の一手 | 停止条件 |
|---|---|---|---|---|---|
| 初回設定で離脱 | 中 | 中 | 低 | 5人の観察とログ確認 | 原因が別ならUI案を作らない |
| 誤表示の可能性 | 大 | 高 | 中 | 表示停止と専門家確認 | 根拠が揃うまで再公開しない |
| 内部検索の遅さ | 中 | 低 | 中 | 代表クエリの計測 | 改善幅が閾値未満なら投資を止める |
| 連携先APIの変更 | 大 | 中 | 高 | 互換層と移行計画 | 期限前に検証できなければ縮小する |
会議では表の順位だけでなく、「今は何をしないか」「次の証拠は何か」「誰が再判断するか」を読み上げます。決定ログに日時、参加者、根拠リンク、反対意見、見直し日を残すと、後から点数だけを見て結論を作り直すリスクを下げられます。
7. よくある失敗
- 機能名や担当者の声を問題の定義として扱う
- 影響、緊急度、確信度、工数を一つの主観スコアへ潰す
- 推定した到達数を実績として報告する
- 法令・安全・アクセシビリティの最低条件を点数の平均で相殺する
- 調査の目的と停止条件を決めず、プロトタイプを作り続ける
- 決定理由と見直し日を残さず、順位だけを更新する
8. 数式が代替しないもの（根拠・依存・停止条件）
優先順位は、限られた時間で「何を先に学び、何を止め、何を作らないか」を決める仕組みです。RICEなどの数式は比較を助けますが、問題の根拠、依存関係、最低条件、停止条件を代替しません。
問題から開発へ進む流れは プロダクト開発の基礎、意思決定の記録は 意思決定フレームワーク と データドリブン意思決定 も参照してください。