RICEとWSJFの比較

RICEは候補となるフィーチャーを4つの要素に分解する——Reach（期間ごとに何人のユーザーが影響を受けるか）、Impact（通常0.25〜3の規模スコア）、Confidence（見積もりへの確信度を反映するパーセンテージ）、そしてEffort（人週）である。分子の積をEffortで割ることで、施策同士を比較可能なスコアが得られる。Confidenceが明示的であるため、このモデルは当て推量を隠すのではなく、罰する仕組みになっている。

Scaled Agile Frameworkで導入されたWSJFは、アウトプットの規模ではなく経済的な緊急性に焦点を当てる。Cost of Delayは、ユーザー・ビジネス価値、時間的緊急性、そしてリスク低減または機会創出の合計である。Job Durationで割るということは、遅延コストが高く小さくて速く届けられる項目が、同じ遅延コストを持つ大きくて遅い項目に勝るということを意味する——これは、大きなプロジェクトを高インパクトなクイックウィンより優先してしまうという、よくある習性への直接的な対抗策となる。

RICEは、新機能、実験、バグ修正といった多様なアイデアを共通の言語で比較する必要があるプロダクトディスカバリーの場面に最も適している。PMが評価を担う、小規模で自律的なプロダクトチームでうまく機能する。Confidence乗数によって、実際に知っていることと、単に仮定していることの違いに対して誠実になれる。

WSJFはプログラムレベルの計画によりよく適合する。特に複数のチームが共有のエンジニアリングリソースを競い合い、単なる選定ではなく順序そのものを正当化する必要がある場合に有効だ。遅延の経済的コストを数値化するため、エンジニアリングのリーダーシップや財務部門に対して説明しやすい。すでにSAFeのPIプランニングを実践しているチームは、WSJFが自分たちのリズムに自然に組み込まれることに気づくだろう。AIOProductOSのようなProduct Operating Systemがそうしているように、あなたの基盤が収益、フィードバック、作業項目を一箇所でつなげているなら、実際のサブスクリプションMRRとサポートリクエストの量を確認することで、Cost of Delayの見積もりを純粋な直感ではなく実際の数字に紐づけることができる。それによって判断そのものがなくなるわけではないが、スコアと経済的現実とのギャップを縮めることができる。

入力が当て推量であれば、どちらのフレームワークも偽の精密さを生み出す。楽観的なReachやImpactの見積もりで膨らんだRICEスコアは、見栄えのためだけの機能を一貫して上位に浮かび上がらせる。測定されていない時間的緊急性で膨らんだWSJFスコアは、本当は最初に届ける必要がなかった項目を急がせてしまう。対処法はどちらも同じだ——実際のユーザー数、測定された転換への影響、観測されたチャーンのシグナルといった実データにスコアを紐づけること。委員会の直感に頼らないことだ。

どちらのフレームワークも、戦略的な判断の代わりにはならない。RICEやWSJFだけで並び替えたバックログは、時としてあなたのプロダクトビジョンと矛盾したり、市場のタイミングを無視したりする。スコアは意思決定を排除するアルゴリズムとしてではなく、議論の出発点やバイアスの点検として扱うべきだ。最も持続的なやり方は、1つのフレームワークを十分に一貫して運用し、チームが異常値に気づいて議論できるようにすることであり、四半期ごとにシステムを切り替えることではない。