Product Owner

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

– アジャイル宣言

プロダクトオーナーの概要

プロダクトオーナー(PO)はチームの一員である。チームは担当するフィーチャーやコンポーネントの概念的および技術的な完全性を維持するが、プロダクトオーナーはストーリーの定義とチームバックログの優先順位付けに責任を持つことによって、プログラム優先順位の実行を合理化する。さらに、プロダクトオーナーは品質において重要な役割を持ち、ストーリーを「完了」に受け入れられる権限を与えられた唯一のチームメンバーである。アジャイルへ移行するほとんどの企業にとって、これは新しく、重要な役割であり、一般的にフルタイムの仕事となる。通常1人のPOは1アジャイルチームをサポートする。(最大2チーム)

この役割は、PI計画策定を準備するためのプロダクト管理チームとの協力を含む、担当するチーム以外のさらなる関係と責務を持つ。

詳細

プロダクトオーナーはアジャイルチームのメンバーであり、顧客の代理として務める。プロダクト管理(あるいは主プロダクトオーナー、参考文献[3])や他のプロダクトオーナーやチームを含む利害関係者と一緒に作業し、チームバックログにあるストーリーの定義と優先順位付けに責務を持つ。このように、技術的な整合性を取りながら、ソリューションを用いてプログラムの優先順位(フィーチャー/イネイブラー) へ効果的に対応する。理想的に、プロダクトオーナーはチームと同じ場所にいて、管理、動機づけ及び文化を共有する。もっとも関連性のあるプロダクト管理会議や計画策定はもちろん、バックログ/ビジョンの手入れセッションに、プロダクトオーナーも参加する。

責務

SAFeにおけるプロダクトオーナーは主に以下の責務を持つ。

PI計画策定の準備と参加

  • 拡張されたプロダクト管理チームのメンバーとして、プロダクトオーナーはプログラムバックログの手入れ、PI計画策定の準備に大いに関与し、計画イベント自身にも重要な役割を担う。イベントの前に、プロダクトオーナーはチームバックログを更新したり、ビジョンロードマップ及び内容発表のレビューに参加したりする
  • イベント中に、プロダクトオーナーはストーリーの定義に関与し、必要な説明を提供する。これによって、チームにストーリーの見積もり、ストーリーの順位付けを支援する。また、今後のプログラムインクリメント(PI)向けのチームの特定の目標の作成に関与する

反復の実行

  • バックログの手入れシステムアーキテクト/エンジニアリングや他の利害関係者からのインプットを受けて、プロダクトオーナーはバックログの作成、剪定、維持に関する主な責任を持つ。バックログの大部分はユーザーストーリーによって構成されるが、欠陥やイネイブラーも含む。バックログ項目の優先順位付けはPI計画策定時に決められたユーザーの価値、時間、他のチームへの依存性に基づく。PI中で、優先順位の再調整を行う。
  • 反復計画。他のプロダクトオーナーと一緒に内容の依存性を調整することを含め、反復計画準備の一環として、プロダクトオーナーはバックログをレビューしたり、優先順位の再調整を行ったりする(ScrumXPをご参照)。反復計画ミーティング中、プロダクトオーナーはストーリーの詳細と優先順位に関する主要な情報源となり、最終的な反復計画の受け入れに関して責任を持つ。
  • ジャストインタイムのストーリーの詳細化。ほとんどのバックログ項目は実装向けにユーザーストーリーレベルまで詳細化される。この詳細化作業は反復の前、反復計画中、反復進行中に行われるかもしれない。チームメンバーの誰もユーザーストーリーや受け入れ基準を記入できるが、プロダクトオーナーがプロセスの進行に責任を持つ。バックログには、常に大よそ2反復の準備できたストーリーを用意したほうがよいだろう。それより多い場合、待ち行列ができてしまう。それより少ない場合、フローの流れを阻害する可能性がある。
  • ATDDのサポート。プロダクトオーナーはストーリーの受け入れ基準の開発に参加し、実施可能な場合、たたき台を作成する。また、実例を準備し、ATDD(受け入れテスト駆動開発)の実例による仕様をサポートするようにする。テストファーストを参照する。
  • ストーリーを受け入れる。プロダクトオーナーはストーリーを「完了」に受け入れることが可能な唯一なチームメンバーである。受け入れはストーリーが受け入れ基準に合致していることや適切で持続的な受け入れテストを持っていることの検証、及び完了の定義に満たすことを含む。このように、プロダクトオーナーは主に利用に即しているかに注目し、品質保証の機能も果たす。
  • イネイブラー作業を理解する。プロダクトオーナーは技術的な意思決定を促進することが期待されていないが、今後のイネイブラー作業範囲を理解し、システムとソリューションアークテクと/エンジニアリングと協力し、新しいビジネス機能性を実現するための重要な技術インフラに関する意思決定及び順序付けの支援に期待されている。これに関して、多くの場合キャパシティの割り当てを確立することで最も効果的である。チームデモ、及びチーム一緒にプロセスの改善を図る反復振り返りに参加し、重要な役割の果たす。POはプログラムレベル検査と適応のワークショップにも積極的に参加する。

プログラムの実行

  • 頻繁に、信頼性があり、継続的に付加価値の高いソリューションをリリースすることに関して、反復とチームは大いに貢献する。各PI過程では、プロダクトオーナーは他のプロダクトオーナーと内容の依存性を調整する。通常、これの一部は週次PO同期ミーティングへの参加によって実現する。詳細はプログラムインクリメントをご参照。
  • プログラム及び価値のストリームの利害関係者向けのシステムデモのやり方に関して、プロダクトオーナーは支援する役割を果たす。

検査と適応

  • チームはPI検査と適応ワークショップで大きな障害を対処する。そこで、プロダクトオーナーは、プログラムのベロシティーと品質を向上させるための改善ストーリーの定義と実装のため、チーム横断的に勤める。
  • PIシステムデモは検査と適応ワークショップで実施する。プロダクトオーナーはプログラムの利害関係者向けのPIシステムデモのやり方に関して、重要な役割を担う。
  • POはPIシステムデモの準備にも参加し、ソリューションの最も重要な側面を利害関係者に確実に示せるようにする。

内容に関する権限

規模が大きくにつれ、1人のPOはアジャイルチームに専任しながら、プロダクトや市場戦略を取り扱うことが難しくなる。プロダクト管理者とプロダクトオーナーはプログラム向けの「内容に関する権限」を共有するため、役割と責務の明確的な線引きは重要である。以下図1で示す。

Figure 1. Release content governance
図1. リリース内容の制御

プロダクト管理者、プロダクトオーナーとアジャイルチームの多重度

開発の成功には、企業における数のゲームという部分がある。適切な役割を担った適切な人数がいなければ、ボトルネックはベロシティーをひどく制限するでしょう。従って、アジャイルリリース列車 (ART)を運行するため、プロダクト管理者、プロダクトオーナー及びアジャイルチームは大体なバランスを取らなければならない。そうしないと、システム全体はその定義、明確化、受け入れに関する待ち時間をたくさん費やすでしょう。SAFeが推奨する多重度を図2に示す。

Figure 2. Fan-out Model for PM/PO
図2. PM/POの多重度モデル

1人のプロダクト管理者は通常4人までのプロダクトオーナーをサポート可能である。1人のプロダクトオーナーは1から2のアジャイルチーム向けのバックログを担当することが可能である。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. 第11章 (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Larman, Craig, and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010. 第3章。

Last update: 7 October 2015