tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

「プロダクトオーナーの役割に関する誤解」が組織に与える害について、また避けるために何をすべきか。

www.youtube.com

概要

YouTubeにアップロードされている"How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It"の意訳。

詳細

「プロダクトオーナーの役割」はどう開発に作用するか

小さなチームで1つの製品を作る場合、プロダクトオーナーはすぐ近くにおり、「製品・開発のビジョン・優先順位・目的」は明確である。 顧客もすぐ近くにいることから開発成果に関するフィードバックがすぐにもらえ、チームは複数の作業がこなせるクロスファンクショナルチームであり、プロダクトオーナーは多くの決定権限を開発チームに与え、開発をより加速させていくことができる。

大規模組織になるとプロダクトオーナーの役割がどう誤解されるか

1チームではスクラムが回せなくなるので、チームの分割を検討する。 一番簡単なやり方は1チームの時のスクラムのコピーを複数作り、それぞれにプロダクトオーナーをつけることである。 ※以降この形式を「大人数での単純スクラム」と呼ぶ。

しかし各プロダクトオーナーが対等の立場であるとすると、各プロダクトオーナーには製品全体の決定権がなく、バックログの並び替えすら行うことができない。 この場合組織はプロダクトオーナーに「チームの生産性を最大化する」ことを期待するしかない。 動画ではこのプロダクトオーナーの状態を「チームアウトプットオーナー」と呼んでいる。 チームアウトプットオーナーは、チーム固有のバックログを作成し、チームのアウトプットのみの最大化に注力することになる。

チーム内の生産性は高まるかもしれないが、チーム間の協力は機能せず、開発メンバーを増やしただけの開発加速は期待することができない。

「プロダクトオーナーの役割に関する誤解」が顧客フィードバックを遅くするのはなぜか

通常のスクラムは各スプリントごとに出荷できるプロダクトを開発する。これにより顧客のフィードバックを早期に獲得する。

「大人数での単純スクラム」は各チームがスプリント内で「コンポーネント」を開発することが多い。 コンポーネントだけでは顧客にとって価値のある単位ではなく、これを基にしたフィードバックを獲得することができない。

チームアウトプットオーナーはチームのアウトプットの最大化にのみ注力するため、効果が測りにくい「ビジネス全体での優先順位」や「他のコンポーネントとの整合性」ではなく、ベロシティなどのメトリクス最適化を重視するようになってしまう。

コンポーネントを結合するタイミングが遅れれば、顧客フィードバックを獲得するタイミングが遅れることになり、遅れている間他のチームはさらに別の新コンポーネントの開発に着手したり、コンポーネントの改修を始めたりするかもしれない。これがまたコンポーネント統合のタイミングを遅らせることになり、顧客フィードバックはますます得にくくなっていく。

「プロダクトオーナーの役割に関する誤解」が開発者のモチベーション、顧客への共感を減らしてしまうのはなぜか。

「大人数での単純スクラム」は開発チームと顧客が話す機会がほとんどない。 開発チームは橋渡し役の満足度を高めようと動くようになる。 当然のことながら実際の顧客から得られるフィードバックと橋渡し役から得られるフィードバックは異なる。

本物のプロダクトオーナーは高い顧客価値をどう提供するか

本物のプロダクトオーナーは下記ができなければならない。

  • 大きなビジネス上の決定
  • 製品のビジョン・開発優先順位の見直し
  • 開発項目でなく、顧客視点からみた課題を記述したバックログの用意

上記をインプットとして、スクラムチームが自律的に開発を進める。

  • 顧客の課題を咀嚼し、解決法を見つける
  • クロスファンクショナルチームを構成し、開発に必要なスキルを網羅する。

「プロダクトオーナーの役割に関する誤解」が価値の提供を減らしてしまう訳

「大人数での単純スクラム」は特定コンポーネントに特化してしまうリスクがある。 スキルセットが古くなったり、他のチームがコンポーネントを扱えなくなることがこれに該当する。 チームアウトプットオーナーはチームにできる作業を優先順位をつけ、メンバーも言われた通りに作り続けるが、顧客に価値を提供できる開発項目は他チームのバックログに隠れていたりするため、組織全体として提供できる価値は低くなる。

開発チームがどんなに忙しくしていても実際に価値を生んでいるチームはその中の一部であり、アジリティを持ったビジネスを展開していくことは叶わない。

誤ったプロダクトオーナーの役割を果たし続けることによるうれしくないこと

チームアウトプットオーナーは板ばさみとなる。ビジネス上の決定権がないのに責任を押し付けられたり、開発チームから突き上げを食らったりする。管理職としての業務、進捗報告、複数チーム間の調整をプロジェクトマネージャーとして求められたり、完全なユーザーストーリーの記述などなどなど・・・できないことばかりがスタックしてしまう。

チームの自律性・クロスファンクショナルの改善を促し、スタックしている人を助けるか

1人のスーパーマンが全てを引き受け、全てを調整することはできない。 チームに責任を移譲することで特別な役割を持つ人を減らしていく。

プロダクトオーナーに由来する新たな役割を作るべきか、チーフプロダクトオーナーとか、ビジネスオーナーとか

不要。

プロダクトバックログを1つにし、チーム間の壁を取り払い、顧客から開発チームフィードバックを得ることができるようにすることで、チーム同士が協力しあい、全体としてアジリティのある開発を行うことができる。

上記の開発を実現できる人のことをプロダクトオーナーと呼ぶ。新たな名称を設ける必要はない。

感想

「チームアウトプットオーナー」という呼び名は新鮮で面白い。 動画ではLeSSが一言も紹介されていないが、LeSSの基本思想である「組織全体(複数チーム)で1つのスクラム開発を行う」がなぜ必要なのかが丁寧に説明されていると感じた。