プロダクトバックログの問題：なぜあなたの階層は壊れているのか

あなたのバックログには階層の問題がある

「支払いシステムを置き換えるべきか」というアイデアから「この特定のページにこのボタンを追加できるか」というアイデアまで、あらゆるものが考えられます。両方が同じリストに、同等のアイテムとして同じ優先順位付けのスロットを争って存在する場合、あなたはすでに負けています。「アイデア」という言葉が多くの意味を持ちすぎており、誰もそれに気づいていません。

先月、あるプロダクト責任者と話したのですが、彼は自分のバックログを「検索バー付きの墓場」と表現しました。2年間で蓄積された400以上のアイテムがすべて「アイデア」としてタグ付けされていました。中には数四半期にわたるプラットフォームへの投資もありました。中にはCSSの微調整もありました。Slackのスレッドから貼り付けられた曖昧な文章もありました。毎回のスプリント計画セッションは同じ儀式で始まりました。リストをスクロールし、何が重要かについて議論し、その週に最も強く主張した人に基づいてアイテムを選び、少し敗北感を感じながら進むのです。バックログは、実質を伴わない優先順位付けのパフォーマンスになっていました。

根本的な問題は構造にありました。すべてのアイテムが同じ高度にあったため、優先順位に関するすべての会話はゼロから始めなければなりませんでした。誰かがリンゴとオレンジを比較しているのか、それともオレンジと航空母艦を比較しているのかを伝える階層がありませんでした。

フラットバックログの罠

ほとんどのプロダクトチームはフラットなバックログを引き継ぎます。それは無邪気に始まります。誰かがボードやスプレッドシートを設定し、人々がアイテムを追加し、リストは成長します。20アイテムなら、うまく機能します。200アイテムになると、管理不能になります。500を超えると、それは負債になります。

ここでの構造的な失敗は微妙です。フラットなバックログは、すべてのアイテムが同じ種類の物であり、同じ種類の評価に値することを示唆しています。「新しい認証プロバイダーへの移行」と「オンボーディングボタンの色変更」は、根本的に異なる決定です。それらは異なる高度で機能します。それらは異なる関係者、異なる時間軸、異なるリスク評価、異なる証拠のしきい値を必要とします。それらを同じリストに入れて、チームに互いにランク付けするように求めることは、家を買うのと昼食を買うのとを選ぶように求めるようなものです。どちらも購入です。どちらも費用がかかります。しかし、比較は不条理です。

フラットバックログが優先順位付けに与える影響

すべてが同じレベルにあると、チームは3つの機能不全パターンのうちの1つに陥ります。

ボリュームベースの優先順位付け。 最も多くの投票、最も多くの顧客からのリクエスト、または最も大きな内部支持を得たアイテムが勝ちます。これは、戦略的重要性よりも苦情の頻度に報います。10人の顧客が言及するマイナーなUIの摩擦が、エンジニアリング部門以外誰も理解していない基盤となるアーキテクチャの決定よりも優先されます。チームは問題レベルではなくアイデアレベルで優先順位付けすることになり、その結果、ノイズを最適化するロードマップが作成されます。

新しさへの偏り。 最も最近議論されたものが最も重要だと感じられます。バックログは戦略ツールではなく、キューになります。6ヶ月前に追加されたアイテムは、実際の価値に関係なく、認識される関連性が低下します。チームは、より長い gestation period を必要とする戦略的な賭けを見失い、バックログは迅速な修正と反応的な作業にゆっくりと傾いていきます。

スコアリングにおける偽の等価性。 チームは、プラットフォーム移行の「Reach」スコアがツールチップの改善の「Reach」と同じ意味を持つかのように、すべてのアイテムにRICEまたはImpact vs. Effortスコアリングを等しく適用します。計算は数値を生成します。数値は厳密さの幻想を生み出します。しかし、入力は比較不可能であるため、出力は分析を装ったフィクションです。優先順位付けフレームワークのプロダクトマネージャーガイドは、まさにほとんどのフレームワークが間違った高度に適用された場合に失敗するため存在します。

400のアイデアを並べて比較しようとしていますか？それは優先順位付けの問題が発生するのを待っています。ProdPadが問題レベルで優先順位付けをどのように支援し、適切なアイデアが自然に表面化するかをご覧ください。

Flight Levels：バックログ構造のための思考モデル

Klaus Leopoldによって開発された「Flight Levels」の概念は、組織改善のための思考モデルとして、ここで有用なレンズを提供します。Leopoldは、作業が管理される3つの高度を説明しています。戦略レベル（どこに投資するかに関するポートフォリオの決定）、調整レベル（価値を提供するためにチーム間で作業がどのように流れるか）、および運用レベル（個々のチームがどのように実行するか）。各レベルには独自のペース、独自の意思決定者、独自の「完了」の定義があります。

Flight Levelsモデルがバックログ構造に関連する理由は、異なる高度は異なる種類の決定と異なるフィードバックループを必要とするという中心的な洞察です。組織が単一の高度ですべてを管理しようとすると、戦略的な決定が運用上の会話に引きずり込まれ、戦術的な改善がプラットフォームへの投資と同じ儀式で扱われます。その結果、何も適切な速度で進みません。

［画像: プロダクト意思決定の3つの高度を示し、バックログ階層図における戦略、調整、運用レベルを示す、ProdPadプロダクトマネジメントソフトウェア］

戦略、調整、運用の各決定には、独自のバックログ構造が必要です。それらを単一のリストに圧縮すると、偽のトレードオフが発生します。

バックログへのマッピング方法

ほとんどのプロダクトチームはすでに複数の高度で決定を下しています。ただ、それを正式化する構造がありません。プロダクト責任者は、来四半期にどの市場セグメントを追求するかを考えています。プロダクトマネージャーは、特定のイニシアチブ内でどの顧客の問題に取り組むかを考えています。エンジニアリングリードは、特定の機能にどの技術的アプローチを取るかを考えています。これら3つの決定はすべて有効で必要です。問題は、それらがすべて同じバックログ列に収まることです。

単一の高度で動作するバックログは、すべての人に絶えずコンテキストスイッチを強制します。ある瞬間には、新しい価格モデルへの投資について議論しているかもしれません。次の瞬間には、ボタンの配置変更の相対的な優先順位について誰かが尋ねています。戦略的な会話は運用上の詳細によって中断されます。運用上の詳細は、部屋にいる誰かがボタンについて強い意見を持っているため、戦略的な議論に膨れ上がります。そして、チーム間の依存関係やイニシアチブレベルのトレードオフが実際に存在する調整レイヤーは、完全にスキップされます。

ほとんどのチームが欠いているイニシアチブレイヤー

概念的には、修正は簡単です。すべてのバックログアイテムを同等として扱うのをやめ、目標とアイデアの間に階層を導入します。イニシアチブは、解決すべき問題または追求すべき成果を表します。それは調整高度に位置します。それは会社全体の目標または戦略的なテーマに上向きに接続し、それらを達成するための可能な方法を表すアイデア、実験、およびユーザーストーリーのコレクションに下向きに接続します。

イニシアチブが存在すると何が変わるか

チームが明示的なイニシアチブレイヤーを持つと、3つのことが変化します。

優先順位付けが適切な高度で行われる

「支払いシステムを置き換える」と「このページにボタンを追加する」を比較する代わりに、チームはまずイニシアチブレベルで優先順位を付けます。「支払い摩擦の軽減」が「初回オンボーディングの改善」や「エンタープライズSSO要件のサポート」と競合します。これらは比較可能な決定です。それらは同様の高度で機能し、同様の投資期間を含み、同じ戦略的目標に対して評価できます。個々のアイデアは、親イニシアチブのコンテキスト内で優先順位が付けられます。「このページにボタンを追加する」は、支払いインフラストラクチャのオーバーホールと競合するのではなく、同じオンボーディング問題を解決する可能性のある他のアイデアと競合します。アイテムが共通の参照フレームを共有しているため、比較は有意義です。これは、まず高レベルのイニシアチブで作業し、その後アイデアをレイヤー化することに重点を置くプロダクトロードマップのベストプラクティスで概説されているアプローチです。

フラットなバックログに溺れていますか？実際のチームが戦略的なイニシアチブの下でアイデアをどのように整理しているかを、ProdPadのライブインタラクティブ環境でご覧ください。

コンテキストがアイデアと共に移動する

アイデアがイニシアチブにリンクされている場合、それを評価する人は誰でも、なぜそれが存在するのかをすぐに確認できます。イニシアチブは、問題ステートメント、戦略的接続、ターゲット成果をもたらします。新しいチームメンバーが「レポートページにCSVエクスポートを追加する」を見ると、「エンタープライズ顧客向けのデータアクセシビリティの向上」までたどり着き、30分のオンボーディング会話なしでコンテキストを理解できます。階層がフレームワークを提供するため、アイデアは自己文書化されます。

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

プロダクトマネジメントの最も難しい部分の1つは、合理的なアイデアに「ノー」と言うことです。すべてのアイデアが孤立して存在する場合、1つを却下することは個人的または恣意的に感じられます。アイデアがイニシアチブ内にあり、イニシアチブが目標に接続されている場合、「ノー」には構造的なサポートがあります。「これは良いアイデアですが、現在のイニシアチブのいずれにも役立ちません」は、「これは重要ではないと思います」とは根本的に異なる会話です。階層は、プロダクトマネージャーの判断だけに降りかかる可能性のある対立を吸収します。

［画像: フラットバックログと構造化された階層の比較。イニシアチブが戦略的目標の下でアイデアをどのように整理するかを示す、ProdPadプロダクトマネジメントソフトウェア］

フラットバックログは、異なる高度のアイテム間で偽のトレードオフを強制します。構造化された階層により、チームは適切なレベルで優先順位を付けることができます。

なぜデリバリーツールが問題を悪化させるのか

フラットバックログ問題の重要な貢献者は、ツール自体です。ほとんどのチームは、Jira、Trello、Azure DevOpsのようなデリバリーツール内でプロダクト思考を管理しています。これらのツールは、チケット、スプリント、ストーリーポイント、ベロシティの実行を追跡するのに優れています。それらは、そもそも何を構築すべきかを決定する上流の決定を管理する上では構造的に劣っています。

Jiraのバックログは、設計上、ワークアイテムのフラットなリストです。ラベルを追加できます。エピックも利用可能です。ストーリーはそれらのエピックの下にネストされます。

しかし、ツールの基本的なモデルはデリバリーを中心に据えており、その階層もそれを反映しています。Jiraのエピックはストーリーのコンテナであり、作業範囲でグループ化されています。それらは戦略的な構成要素ではありません。それらは目標、成果、または証拠をもたらしません。それらはバケツです。

チームが戦略的なプロダクトの決定のためにデリバリーツールを使用しようとすると、ツールの構造が会話を下に引き下げます。すべてがチケットになります。すべてにストーリーポイントの見積もりが必要です。戦略的思考は、誰も読まないチケットの説明に圧縮されます。なぜなら、ツールはカードを列を越えて移動させることを奨励するのであって、それらのカードが存在すべきかどうかを深く考えることを奨励するわけではないからです。Rich Mironovは、チームが使用するツールが彼らの意思決定をどのように形成するかについて広範囲に書いており、デリバリーツールは一貫してチームを出力思考ではなく成果思考へと押しやります。

ProdPadはデリバリーツールのさらに上流に位置します。戦略、発見、証拠が存在する場所であり、何かがチケットになる前です。無料トライアルを開始する →

2つのバックログの原則

解決策は、明確な引き継ぎを持つ2つの別個のバックログを維持することです。プロダクトバックログ（またはMarty Caganが呼ぶところのオポチュニティバックログ）は、アイデア、実験、仮説、および戦略的な可能性のためのスペースです。それはデリバリーの上流に位置し、解決すべき問題を中心に構成されています。デリバリーバックログ（スプリントバックログ、開発バックログ）は、コミットされた作業のためのスペースであり、エンジニアリングが取り組む準備ができているストーリーとタスクを中心に構成されています。

ProdPadはこの正確な分離を中心に設計されています。アイデアはアイデア管理システムに存在し、ロードマップの目標に接続するイニシアチブの下に整理されています。アイデアが検証され、スコープが決定され、開発の準備が整うと、それは完全に仕様化されたチケットとしてJiraまたはAzure DevOpsにプッシュされます。プロダクトバックログはクリーンで戦略的なままです。デリバリーバックログは焦点を絞り、実行可能であり続けます。誰も400の混合高度のアイテムをスクロールして、何が重要かを理解しようとしていません。

スコアリングの罠

スコアリングフレームワークがフラットバックログで失敗する理由について、もう少し詳しく説明する価値があります。その失敗モードは教育的です。

ほとんどの優先順位付けフレームワークは、スコアリングされるアイテムが比較可能であることを前提としています。RICEスコアリングでは、各アイテムのReach、Impact、Confidence、Effortを推定するように求められます。それらは妥当な次元です。しかし、プラットフォーム移行の「Reach」とボタン変更の「Reach」は、根本的に異なるものを測定しています。プラットフォーム移行は、今後3年間で支払いフローを操作するすべてのユーザーに影響します。ボタン変更は、単一のページの一部のユーザーに、次の四半期まで影響します。どちらも数値を生成します。数値は比較できません。

階層なしでスコアリングに依存するチームは、2つの失敗モードのいずれかに陥ります。誤った精度ですべてをスコアリングして誤解を招くランキングを生成するか、結果が決して直感に合わないためスコアリングを完全に放棄します。どちらの結果も同じ根本原因を示しています。スコアリングされるアイテムは異なる高度で機能しており、単一のスコアリングルーブリックがその範囲を意味のある方法でカバーすることはできません。

より良いアプローチは、レベル内でスコアリングすることです。戦略的基準（目標への整合性、期待されるビジネスインパクト、顧客証拠）を使用して、イニシアチブを他のイニシアチブと比較します。戦術的基準（実現可能性、学習速度、変更の範囲）を使用して、同じイニシアチブ内のアイデアを他のアイデアと比較します。比較が同等であるため、スコアリングは有意義になります。

［画像: 右の高度でのスコアリング。構造化された比較テーブルにおけるイニシアチブレベルとアイデアレベルの優先順位付け基準を示す、ProdPadプロダクトマネジメントソフトウェア］

スコアリングは、アイテムが階層の同じレベル内で比較される場合に機能します。クロス高度スコアリングは誤解を招く結果を生み出します。

優先順位付けフレームワークは、適切なレベルに適用された場合にのみ機能します。私たちの無料ガイドでは、17のフレームワークと、それぞれが実際に役立つ時期について詳しく説明しています。

健康的なプロダクトバックログ階層の外観

適切に構造化されたプロダクトバックログには、それぞれ独自の目的とペースを持つ3つの明確に分離されたレベルがあります。

目標レベル

目標は、プロダクトの戦略的方向を表します。「どこへ向かっており、なぜ」に答えます。ペースは四半期ごと、またはそれ以下です。所有権はプロダクトリーダーシップにあり、会社全体のビジネス目標に接続します。ProdPadでは、目標は階層の最上位にあり、ロードマップにカスケードします。

イニシアチブレベル

イニシアチブは、解決すべき問題または達成すべき成果を表します。「何に取り組んでおり、成功とは何か」に答えます。それらはNow-Next-Laterロードマップ上にカードとして配置され、偽のデリバリーコミットメントなしに戦略的意図を伝えます。各イニシアチブは、上向きに目標に、下向きに一連のアイデアに接続します。

アイデアレベル

アイデアは、イニシアチブによって説明された問題に対処できる可能性のあるソリューション、実験、または機能を表します。「どのように解決できるか」に答えます。それらは最も細かいレイヤーであり、ほとんどのチームがほとんどの時間を費やすレイヤーです。重要な構造原則は、アイデアが決して孤立して評価されないということです。それらは常に親イニシアチブのコンテキストで評価されます。

この3レベル構造は、Flight Levelsの概念を反映しています。上部に戦略、中央に調整、下部に運用があります。各レベルには独自の優先順位付け基準、独自の意思決定者、独自のレビューペースがあります。関係者が「なぜこれに取り組んでいるのですか？」と尋ねた場合、階層は、誰も記憶から推論を再構築する必要なしに、答えを提供します。

バックログを意思決定システムとして

ここでのより深いポイントは、バックログはToDoリストではないということです。ToDoリストはフラットなアクションシーケンスです。バックログは意思決定システムです。トレードオフが表面化し、証拠が検討され、適切な高度でコミットメントが行われる構造化された環境です。

バックログに階層がない場合、それはウィッシュリストに劣化します。アイテムは構造なしで蓄積されます。優先順位付けは政治的な演習になります。チームは忙しいと感じますが、戦略的には漂流しています。一般的な症状は、スプリント計画会議で、誰もが優先順位について議論しますが、どのアイテムも会社の戦略的方向性にどのように接続しているかを説明できないことです。アイテムはすべて同じ高度にあるため、利用可能な唯一の議論は個人的な確信です。

バックログに階層があると、会話が変わります。戦略的な議論は、それが属するイニシアチブレベルで行われます。戦術的な議論は、特定の問題にスコープされたアイデアレベルで行われます。プロダクトマネージャーは、リアルタイムで高度間で翻訳する人間のルーターであることから、構造化されたトレードオフをサポートするシステム内で作業する意思決定者になります。実際に機能するプロダクトバックログの例はすべて、この構造的特徴を共有しています。それらは、「どのような問題を解決しているのか」という会話と「どのように解決しているのか」という会話を分離し、それぞれの会話に適切な高度、適切な証拠、および適切な意思決定者を与えます。

階層は良好な優先順位付けの前提条件

すべての優先順位付け方法、すべてのスコアリングフレームワーク、すべてのロードマッププロセスは、評価されるアイテムが比較可能であることを前提としています。フラットバックログは、構造レベルでその前提に違反します。チームは、どの優先順位付けフレームワークを使用するかを議論するために数ヶ月を費やすことができますが、実際の Сは、バックログに任意のフレームワークを効果的にするための階層がないことです。

解決策は新しいスコアリングモデルではありません。解決策は構造です。目標をイニシアチブからアイデアから分離します。各レベルで、その高度に適した基準を使用して優先順位を付けます。階層に、プロダクトマネージャーがリアルタイムで混合高度のアイテムを精神的にソートすることを強制するのではなく、意味のある比較を作成する作業を行わせます。

このシフトを行ったプロダクトチームは、同じ経験を説明しています。優先順位付けは交渉のように感じられるのをやめ、決定のように感じられるようになります。バックログは、チームが恐れるものではなく、信頼するものになります。そして、スプリント計画会議は、最終的に、そもそもどの問題が重要かの再検討ではなく、チームがすでに重要だと合意した問題をどのように解決するかについての会話になります。