待機リストの構造的転換：平坦化からの脱却と階層化による優先度付けの改善

アイデアとは、システム刷新という大規模な問いから、ボタン追加という小規模な要望までを指します。これらを**同じレベル（ピア）**に置き並べると、優先度の議論がゼロになり、勝てる見込みは皆無です。「アイデア」という言葉が過度な重みを背負いつつ、誰もその問題に気づいていないのが現状です。

平坦な待機リストの罠

多くのプロダクトチームには、当初は無害でしたが次第に管理不能になった平坦な（単一層）待機リストが存在します。

• 20 アイテム: 機能する範囲
• 200 アイテム以上: 管理不能になる境界線
• 500 アイテム以上: それはすでに「負債（コスト）」そのもの

なぜ失敗するか？

すべてのアイテムを同様の評価基準で扱うという前提には、本質的な矛盾があります。

• 「認証プロバイダへの移行」と「ボタンの色変更」は、全く異なる決定プロセスです。
• これらを比較することは、「家を買うか、昼食を買うか」を比較することと同じく非合理です。

3 つの機能不全パターン

すべての要素が同じレベルにあると、以下の弊害が発生します。

1. ボリュームベースの優先付け（不満の頻度）

   • 投票数や顧客の声の大きさだけで決定されます。
   • 結果: 「問題のレベル」ではなく「アイデアのレベル」で判断し、ノイズを最適化するだけのロードマップになります。例：基盤アーキテクチャより UI の不具合が優先される。

2. 近接バイアス（最新性の偏り）

   • 最近議論されたものが最重要と見なされ、待機リストは単なる待ち行列（キュー）化します。
   • 結果: 6 ヶ月前の戦略的投資案件が見失われ、パッチ適用やリアクティブな作業へ傾斜します。

3. スコアリングにおける虚構の同等性

   • RICE モデルなどをすべてに等しく適用しますが、入力が互換性がないため出力はフィクションになります。
   • 例: 「プラットフォーム移行」のリーチと「ツールチップ改善」のリーチを比較することは不可能です。

フライトレベル：思考モデルの導入

組織改善の思考モデルである**「フライトレベル」**（戦略、調整、運用の 3 つの高さ）を待機リスト構造に応用します。

• 戦略レベル: ポートフォリオ決定（どこへ行くか）
• 調整レベル: チーム間の作業フロー（どう連携するか）
• 運用レベル: 個別タスクの実行（どうやるか）

マッピングの重要性

これらを単一のリストに統合すると、虚偽のトレードオフが生じます。

• 問題: コンテキストスイッチが強制され、戦略的会話と運用の詳細が混在します。
• 欠落: 「イニシアチブレイヤー」が存在しません。

イニシアチブレイヤーの導入効果

目標とアイデアの間に**「イニシアチブ」**というレイヤーを挿入することで、3 つの変化が起きます。

• 適切な高さでの優先付け

  • 異なる高さを比較するのではなく、類似の高さで競合させるようにします。
  • 「決済システムの刷新」対「オンボーディングの改善」といった、同レベルのイニシアチブ同士で議論し、その下に具体的なアイデアを配置します。

• 文脈はアイデアと共に移動する

  • アイデアは親イニシアチブにリンクされているため、評価者が「なぜこのアイデアが必要か」を理解できます。
  • 階層により、アイデア自体が自己ドキュメンテーション化されます。

• 「ノー」と言うのが容易になる

  • アイデアが孤立して存在すると断ることは恣意的に見えますが、イニシアチブへの貢献がないと論理的に拒否できます。
  • 階層はプロダクトマネージャーの判断負担を軽減し、対立を吸収します。

デリバリートルが悪化させる理由

Jira や Trello などのデリバリツールは、戦略的な決定を下す上流のプロセスには構造的に不適切です。

• 構造的問題: ツールは「実行の追跡」に最適化されており、階層もそれを反映しています。
• エピックの限界: Jira のエピックは単なるコンテナであり、戦略的な意思決定そのものではありません。
• 出力思考への誘導: ストーリーポイント推定やチケット移動が報酬となり、深い思考を阻害します（Rich Mironov 氏の指摘）。

2 つの待機リスト原則

解決策は、明確なハンドオフを持つ2 つの独立したリストを維持することです。

1. 製品バックログ（機会バックログ）

   • 位置: デリバリーの上流。
   • 内容: アイデア、実験、仮説、戦略的可能性。課題解決を中心に組織化。
   • 役割: 戦略的思考の場。

2. デリバリバックログ（スプリントバックログ）

   • 位置: エンジニアリングが引き継ぐ準備完了した先頭。
   • 内容: ストーリーとタスク。コミットメントされた作業。
   • 役割: 実行の追跡。

ProdPad のアプローチ:

• アイデアはイニシアチブの下で管理され、検証・スコープが完了した時点で、仕様化されたチケットとして Jira へプッシュされます。
• これにより、400 つのアイテムをスクロールする必要はなくなります。

スコアリングの罠と解決策

スコアリングは異なる高さの比較を前提にしているため、平坦なリストでは失敗します。

• 失敗例: プラットフォーム移行とボタン変更で「リーチ」を計算しても意味がありません。
• 正しいアプローチ: レベル内でスコアリングを行います。
  • イニシアチブ間: 戦略的基準（目標整合性、ビジネスインパクト）。
  • アイデア内: 戦術的基準（実現可能性、学習までの時間）。

健全なプロダクト待機リスト階層の外観

構造された待機リストには、3 つの明確に分離されたレベルがあります。

1. 目標レベル (Goals)

• 目的: 製品の戦略的.direction を定義。「どこへ行くか、なぜ行くか」。
• サイクル: 四半期以上。
• 所有権: プロダクトリーダーシップ（企業全体のビジネス目標と接続）。

2. イニシアチブレベル (Initiatives)

• 目的: 解決すべき課題や成果を定義。「何を仕事としているか、成功とは何か」。
• サイクル: Now-Next-Later ロードマップ上。
• 構造: 上位の目標と、下位のアイデア系列に接続。

3. アイデアレベル (Ideas)

• 目的: 課題に対する解決策や機能。「どうするか」。
• 粒度: 最も細かい層（多くの時間が費やされる）。
• 原則: 孤立して評価せず、常に親イニシアチブの文脈の中で評価する。

この構造は「フライトレベル」と整合し、各レベルに独自の優先付け基準とレビューサイクルを持たせます。

待機リストとしての決定システム

待機リストはタスクリストではなく、決定システムです。

• 階層なしの場合: 希望リスト（Wishlist）化し、政治的な演習となり、戦略的漂流を招きます。
• 階層ありの場合:
  • 戦略的議論はイニシアチブレベルで発生。
  • 戦術的議論はアイデアレベルで発生。
  • プロダクトマネージャーは「高さの翻訳者」から解放され、システムとして意思決定が可能になります。

結論：階層が良質な優先付けの前提条件

すべてのスコアリングフレームワークやロードマッププロセスは、評価アイテムが相互比較可能であることを前提としています。平坦な待機リストはこの仮定を根底から否定します。

• 解決策: 新しいスコアリングモデルではなく、構造そのものの変更です。
  • 目標 → イニシアチブ → アイデアへ分離。
  • 各高さで適切な基準を使用して優先付けを行う。
• 効果:
  • 優先付けは「交渉」から「決定」へと変化します。
  • スプリント計画会議は「優先順位決め」から「合意済み課題の解決策議論」に変わります。

待機リストは恐れるべきものではなく、チームが信頼する戦略的なコンパスとなるべきです。