多くのプロダクトチームでは、バックログは緊急感が死ぬ場所です。追加されたときにはすべてが緊急でした。顧客のクレーム、セールスのリクエスト、競合の機能、社内のアイデア。6ヶ月後、すべてがまだそこにあり、すべてがまだ緊急に感じられ、次に何をすべきかを正確に誰も知らない状態です。
問題はツールの不足ではありません。優先順位付けのフレームワークは数十種類あります。RICE、MoSCoW、カノモデル、ICE、重み付けスコアリング。問題は、ほとんどのフレームワークが虚偽の精度を必要とすることです。未知のことに数字を割り当てることで厳密に見せますが、実際にはスプレッドシートを通して直感を洗浄しているだけです。
実際に機能するのはもっとシンプルです。二つの次元を誠実に評価し、その結果に基づいて行動する規律です。
優先順位付けは二つの質問に集約されます。第一に：これは私たちが気にしている成果をどれだけ改善するか？（インパクト）。第二に：これを届けるためにどれだけのコストがかかるか？（エフォート）。それ以外はすべてこの二つの洗練版か、注意散漫の原因です。
確信度が三つ目の次元として加えられることがあります。「インパクトについてどれだけ確かか？」これは念頭に置く価値があります。しかし実際には、ほとんどのチームは推測しているときに分かっています。規律は推測を正直にラベル付けすることであり、1〜5のスケールでスコア付けして数式に加えることではありません。
難しいのはグリッドを理解することではありません — 記入するときに正直であることです。どのチームにも「時間の無駄」に属しながら「大きな賭け」と再分類され続ける機能があります。フレームワークはチームがインパクトについて正直でいられるときにのみ機能します。
インパクトはチームが最も評価しにくい次元です。しばしば未来を予測する必要があるからです。数値でスコア付けして科学的に見せたくなりますが、より良いアプローチは定性的だが構造化されたものです。
検討中の各機能について三つの質問をしてください：
チームはエフォートを系統的に過小評価します。これはよく文書化されています。計画錯誤と楽観バイアスに関連しており、複数のシステムに触れる機能、チーム間の調整が必要な機能、またはチームが以前に構築したことのない能力を含む機能では特に顕著です。
二つの実践が役立ちます。第一に、エフォートをスコア付けする前に、後ではなく、常にエンジニアリングに確認してください。PMが単独でエフォートをスコア付けすると、ほぼ必ず過小評価します。第二に、「未知の未知」の概念を明示的なエフォート乗数として使用してください。新しいコードベースエリア、サードパーティAPI、または最近テストされていないユーザーフローに触れる機能は、明らかな作業が示す値の1.5倍のエフォートスコアに値します。
プロダクトバックログのほとんどの緊急性は本物の緊急性ではありません。それは最近性です。先週顧客がクレームしたので、そのリクエストは切迫しているように感じられます。先月競合が何かをリリースしたので、それに追いつくことは重要に感じられます。しかし最近性は重要性と同じではなく、最近性に反応することは本当に重要な仕事を滑り落とす最も信頼できる方法の一つです。
実践的なテスト：先週ではなく6ヶ月前に聞いていたら、まだこれを緊急と考えるかどうかを自問してください。答えが「いいえ」なら、戦略的な優先事項ではなく最近性バイアスが働いています。記録し、グリッドに対して冷静に評価し、新しいからというだけでファストトラックしたい誘惑に抵抗してください。
グリッドは常に明確な答えを出すわけではありません。二つのアイテムが同じ象限に似たスコアで並び、それでもどちらかを選ばなければなりません。そのような場合、二つのタイブレーカーが役立ちます。戦略的整合性（18ヶ月後に望む位置に近づくのはどちらか？）と可逆性（間違いだった場合に取り消しにくいのはどちらか？）。より戦略的に整合していてより可逆的なアイテムを優先してください。