ICEスコアリング

各施策は3つの次元で評価され、通常は1から10のスケールが使われる。Impactは問う——うまくいけば、重要な指標をどれほど大きく動かすか。Confidenceは問う——データ、調査、過去の実験といったエビデンスに基づいて、どれだけ確信があるか。Easeは問う——実行にかかる手間、複雑さ、リスクはどれほど低いか。この3つの数字を掛け合わせるとICEスコアが得られる。スコアが高いほど、キューの上位に上がる。

この計算式は意図的に粗く作られている。その価値は、最も説得力のある推進者にロードマップの座を勝ち取らせるのではなく、不確実性（Confidence）とコスト（Ease）についての明示的な議論を、アップサイド（Impact）と並べて強制することにある。チームは通常、議論の前に各自で独立して評価を行い、それによって意見の相違を早い段階で表面化させる。

ICEは、詳細な見積もりに投資せずに一貫した評価言語を必要とする、初期段階や速く動くチームで際立った効果を発揮する。実験やグロースのアイデア、あるいは本当に不確実性があって速く動きたいバックログ項目を比較するのに適している。戦略的な整合性や収益への影響を明示的に重み付けする必要がある作業には、あまり向いていない——Reach次元を追加してEase乗数をEffort除数に置き換えたRICE、あるいはCost of Delayを組み込んだWSJFといったフレームワークが、こうした欠落を補う。

Confidence次元は、最も活用されていないレバーだ。サポートチケットの量、調査データ、アナリティクスのイベント、過去のA/Bテストの結果といった実際のエビデンスにConfidenceを紐づけるチームは、それを直感的な乗数として扱うチームよりも、はるかに説得力のあるスコアを生み出す。プロダクトのデータが顧客フィードバックや収益シグナルと並んで共有された基盤の上にあるとき、Confidenceのスコアを実際の記録に紐づけることは、余計な手間ではなく自然な一歩になる。

よくある失敗パターンは、計画時に一度だけスコアを付けて、その後二度と見直さないことだ。実験が進み、データが得られるにつれて、Confidenceのスコアは更新されるべきだ。スコアを付けた各施策を、それを支えたアナリティクス、フィードバック、収益のデータに紐づけることで、追跡可能な記録が生まれ、振り返りが政治的なものではなく有用なものになる。単一のつながったデータソースから運営しているプロダクトチームは、スコアを付けたアイデア、実際に行われた作業、そして測定された結果の間のループを閉じることができ、それによってICEは計画の儀式から学習のシステムへと変わる。