なぜあなたのプロダクトバックログは崩壊するのか？階層構造の落とし穴を徹底解説

プロダクトバックログの管理において、なぜ多くのチームが階層構造の設計で失敗してしまうのでしょうか？エピック、ストーリー、タスクといった階層を単純に積み重ねるだけでは、複雑なプロダクトの成長を支えることはできません。本稿では、なぜ既存の階層構造が破綻してしまうのか、その根本原因を探り、持続可能なバックログ管理のヒントを紐解きます。

サブマリン記事だね。PMだった頃、こういう類のツールのほとんどは時間の無駄だと感じてた。ツールはオーナーシップの問題を解決してくれないから。結局、セールスやエンジニアと直接同じ部屋で話すのが、バックログの問題を解決する一番の近道だったよ。どんなプロジェクトもイニシアチブもタスクも、顧客満足度を上げるか、収益（ARRの1-2%）を具体的に押し上げるものに直結させる必要がある。もしエンジニアが「なぜリファクタリングが顧客満足度やPLの向上に役立つのか」を説明できなければ、優先度を下げる。セールスが「なぜそのチェックボックス機能が大多数の顧客を満足させたりPLに貢献するのか」を説明できなければ、それも優先度を下げてリファクタリングを優先させる。要するに、PM、セールス、エンジニア全員に責任感（オーナーシップ）を持たせろってこと。そうすれば複雑なプロジェクトだって簡単に回るようになる。オーナーシップっていうのは、実行する相手を信頼しつつ、しっかり検証することも意味する。俺はエンジニアやセールス、ステークホルダーを信頼していたし、彼らも俺を信頼してくれていたけど、自分の宿題は常に自分でやるようにしてた。バックログは増え続けるものだし、それは想定内。でも誰かが整理して管理しなきゃいけない。それがPMの役目。どんなツールを使ってるかなんてどうでもいい。JIRAだろうがExcel 95の表だろうが同じこと。とにかく責任を持って、やり切るんだ。

バックログに入れるものには細心の注意を払うようにしてる。現実的にやるつもりのないものは、バックログに入れるべきじゃない。やりたいことは山ほどあるけど、実際にはやる価値がないと分かっているからバックログには入れていない。AIで月々のトークン枠を使い切ってない場合でも、やる価値のないことはたくさんあるんだ。今週もビルドを改善するアイデアを思いついて、リファクタリングしようかなと考えた。でも、実際に必要な作業量を調べてみると、確かにビルドは改善されるけど、そのためのコストが改善によるメリットを上回っていることに気づいて、結局やめることにした。直さないまま放置する不満点がいくつか残るのは残念だけど、それが現実。結局のところ、顧客を維持して、より多くのお金を払ってもらえるような仕事をしなければならないんだ。

やるつもりのないものは全部消しちゃえ。

AIが書いたような匂いがプンプンする。