プロダクトマネジメントとプロダクトオーナーの関係　『The Professional Product Owner: Leveraging Scrum as a Competitive Advantage』

はじめに

はじめまして。私はドイツでプロダクトオーナー(PO)を担当しつつ、プロダクトマネージャー(PM)を志向して新製品開発を進めており、POについての体系的な知識の確認のためScrum.orgのPSPO資格の勉強をしています。その際の参考文献として挙げられていた『The Professional Product Owner: Leveraging Scrum as a Competitive Advantage』(McGreal Don, Jocham Ralph 著)から学んだことを共有します。

The Professional Product Owner: Leveraging Scrum as a Competitive Advantage

Professional Product Owner

スクラムで定義されているプロダクトオーナーの役割は製品開発に必要な活動の一部分しかカバーしておらず、それがPMに興味を持った理由でもありました。

この本ではその解として、Professional Product Owner(以下PPO)はAgile Product Managerであると定義し、PPOはプロダクトマネジメントの全領域をカバーし、製品ビジョンとスクラムのスプリント活動のギャップを埋める役割を担います。そのためにPPOはビジョナリーであり、決断力があり、製品が対象とするドメインの専門家であることが必要で、製品価値の最大化に責任を負います。

しかしPPOはその責任範囲の広さからボトルネックになりがちです。その解消に有効なのがナラティブ(物語)アプローチです。ユーザー視点から実現したい未来を語ることでエンゲージメントを高め、開発チームが製品/開発機能に対するオーナーシップを発揮できるようにします。これにより、PPOは詳細まで仕様を決める責務から解放され、戦略や製品価値に集中する時間を確保できます。

実際、開発チームの練度が上がるにつれて、この重要性が増してきていることを実感しています。立ち上げ期のチームでは、期待した成果が得られるよう、詳細にAC(受入条件)を記載していました。しかしチームの成長と共に、ACで記載した以上の提案や成果物を得られるようになりつつあり、細かい仕様定義よりも、実現したい価値のイメージを共有することが重要と感じています。

プロダクトビジョン

感情を揺さぶりつつも実践的なプロダクトビジョンと、適切なビジネス指標は、スクラムチームやステークホルダーが顧客価値に集中する事に役立ちます。その際、例えばコード行数のように間違った指標を設定すると、コピー＆ペーストで行数をかさ増しするような望まない結果を生むため注意が必要です。

プロダクトビジョンの例として下記が挙げられています。前半が実践的、後半が感情を揺さぶる点に対応しています。

Our product speeds up the mundane(平凡な) tasks at work so that you can spend more time at home with family

ではどうやって、このプロダクトビジョンをスプリントの活動と繋ぐのでしょうか。本書ではプロダクトビジョンとスプリント毎の成果物が生み出す価値（インクリメント）の関係を真珠のネックレスで喩えています。ビジョンがチェーンの部分にあたり、インクリメントが真珠にあたります。ビジョンの実現に向けて真珠を追加していくイメージです。

スプリント毎に設定するスプリントゴールはそのスプリントのエレベーターピッチの役割を果たし、スプリントゴールの達成はプロダクトビジョンに一歩近づくことを意味します。また開発チームとゴールを共有することで、スプリント期間中の開発スコープについて話し合いが容易になります。

真珠のネックレスの比喩は、スプリント単体で価値のあるインクリメントを作るという意識づけになり良いと思います。またゴールを明確にする代わりに達成手段については柔軟性を持たせ、開発チームにHowとWhatの部分を委ねやすくなることが期待できるため、スプリントゴールも効果的に使っていきたいと思います。スクラムガイド2020の改定では上位目標としてプロダクトゴールも追加され、本書に書かれていることともよく対応すると思います。

リリース

スプリント後に安定化フェイズが必要となる場合、ユーザーのフィードバックを得るまでに余計に時間がかかるため、無駄とみなされます。スプリント後にテストすることは「安定化」のためであり、「品質」のためではありません。製品の品質はスプリント期間中に作り込まれるべきであり、テストは実行可能な要求仕様書として機能します。

安定化フェイズを限りなくゼロに近づけ、市場投入までの期間を短縮しリリース頻度を向上することにより、早期にフィードバックを得ることができ、アジリティを高めることができます。ただし、例えばハードウェアの製品を扱う組織はリリースのコストが高くなるため、価値とコストのバランスを見てリリース頻度を決める必要があります。

技術的負債を最小限にしてスプリント内で品質を作り込む点については、具体的な完了の定義やテストを意識したユーザストーリー記述方法についても記載されていました。開発とテストをフェイズ分けせずQAチームも含めた開発プロセスについては今後深堀りしていきたいです。

プロセス

この本では製品開発の複雑さを説明するためにCynefinフレームワークを紹介しています。製品開発は多くの場合、複雑なドメインに分類され、Unknown Unknowns(知らないことを知らないこと)と向き合う必要があり、アジャイル開発の検査と適応が役立ちます。価値向上に繋がる開発後半での要求変更は良いことであり、フェイズベースの開発から、価値ベースの開発に移行する必要があります。

Cynefinフレームワークを最初に読んだ時はよく理解できなかったですが、読み返してみて、なぜシーケンシャルなアプローチではなくアジャイル開発を採り入れるかについて説明する重要な考え方だとわかりました。また取り組んでいる問題がどのドメインにいるかを認識して次のアクションを決めることでより効果的に開発を進められそうです。

おわりに

本書によって、プロダクトマネジメントとプロダクトオーナーの繋がりをより明確に理解することができました。ただし具体的にビジョン→ゴール→プロダクトバックログへと落とし込む活動にはプロダクトマネジメントの範疇で埋めなければならない空白部分が多くあります。継続学習と実践により、自分なりの型を確立していきたいと思います。

最後に整理用に作ったボードも共有します。