バックログの優先順位を考えるときに意識したいこと

こんにちは。こにしです。

PMの仕事には色々ありますが、成果に最も直接的につながるのはどんなアイデアにどの順序で取り掛かるか(バックログの作成と並び替え)を決めることだと思っているので、今日はその辺りで考えていることをまとめてみようと思います。

実情としてはこれを完璧にこなせているわけではないですが、「本来的にはこうあるべきじゃないか」「このようにやっていきたい」と思ってる内容になります。

相対評価と絶対評価を意識する

これは言葉尻みたいなものですが、優先という言葉の意味を考えるに優先順位というものは相対的な概念です。
開発あるあるで「これは優先的に対応したい(してほしい)」みたいな言葉が飛び交うことがあると思うのですが、比較対象が明示されない限りこれはあんまり正しくないコミュニケーションだなと思っています。

もしこういう会話をしたいならば、「その代わりに今実施予定のA、B、Cのうちそれかを落とすことになるけどいいですか？」みたいな返しがセットであるべきだと考えます。

これがないと優先的にやってほしいこと祭りになってどこかで「優先的にしてほしいって言ったのに進んでないじゃん」みたいになってしまうので期待値コントロールも兼ねて優先順位を語るときはトレードオフを明示するようにしたいところです。

一方で、絶対評価で語るときは比較対象なしで語っても問題がないです。
具体的には「この案件にはこれぐらいのビジネスインパクト/損失回避/意義がある」みたいなのです。
絶対評価での価値についての認識があっていれば並び替えの根拠として活用しやすいので、その場で優先度の話まで踏み込めないなら絶対評価のすり合わせに留めるとかもよくやります。

実施しない方向への意思決定を意識的に増やす

これは結構心理的ハードルがあるんですが、PMやる以上は向き合わないといけない壁かなと思っています。

基本的にはプロダクトの運営していると、色んなアイデアや要望が溜まってきて「こういうのやりたい」「これはやったほうがいい」みたいな話がどんどんくるようになります。

PMの仕事は開発のROIを最適化してプロダクトを成長させることなので、(表現はさておき)そうでもないアイデアにあまり時間を使わないようにするのも役割の1つだと認識しています。

コミュニケーションや過去ログの保管の仕方など各論の問題はありますが、基本的には開発チームが今本当に大事なことを理解し集中できる環境を作るのも仕事だと考えています。

バックログの量ではなく質を見て立ち回りを変える

これ、具体的には
・超重要案件が詰まっていて新規案件を差し込みようがない場合
・案件自体がない、数はあるけど期待値の高いアイデアは実はない状態
なんかを指してます。

開発チームの立ち回りは製品の発見(Discovery)と提供(Delivery)のバランスが大事だと思っていまして前者の場合はDelivery、後者の場合はDiscoveryにフォーカスすべきだなという理解です。

具体的には、前者の場合はスケ管理やステークホルダーとの期待値調整、スコープ整理、QAあたりに力を入れるイメージです。
後者の場合は、シンプルにアイデアの発掘や考案をすることが肝要なのですが、バックログの量があると「やることが十分にある」と誤認してしまうことがあるのでアウトカムやサクセスベースでバックログの評価をすることが重要だなと考えています。

可視化と説明のための土壌を整備する

色々と言ってきましたが、これらを空中戦の丁寧なコミュニケーションで解決するのは無理だなと思ってまして結局は見やすくて意図がわかりやすいバックログの状態を保つというのが全ての根源だなと思っています。

そのためにも、
・レーンを適切な単位で区切る
・レーン内には適切なissueしか置かない
・同一レーンの数が多くなりすぎないようにする(WIP制限、スウォーミング的な話)
・レーン内の並び順=優先順位にする
のような基本は徹底せねばなというところです。

簡単ですが、バックログ整備関連で考えていることを書き出してみました。
まだまだできていない部分もありますが、引き続き頑張っていこうと思います。