こんにちは！ABEJA でスクラムマスターをしている小川です！

言わずもがなですが、スクラムチームにおけるプロダクトオーナー（以降PO と略します）の役割は重要です。

しかし、「PO 忙しい問題」（ググったらたくさん出てきます💦）が示す通り、世の中のPO はほぼ忙しいです。

そんな忙しいPO に送りたい「チームの一員としてチーム成果を上げるための振る舞い」について焦点を当てた内容をまとめてみました！実際に弊社PO と振り返りをした内容をまとめたものになります！（手前味噌ではございますが経験主義に基づいた内容でございます。）

プロダクトオーナーの方（目指す方も）や、プロダクトオーナーとの連携の仕方について考えている方（悩んでいる方）にもご参考にしていただけるのではと思ってます！

プロダクトオーナー（PO）とは？

まずはプロダクトオーナーについて再確認します。

プロダクトオーナーはスクラムチームの一員です。 POが要件や仕様を決めて開発者に開発を委託する、という関係では決してありません。

自己管理型なスクラムチームの一員として、価値の探索（ユーザーや市場の調査をして新たな価値を検討し、実現した価値を検証する）もしますし、価値の実現（スプリントでの開発活動）にも貢献するはずです。（PO がコーディングをするという意味ではなく、スプリント中に課題や問題があれば一緒に解決を目指すという意味です。「あなた vs 私」ではなく「問題 vs 私たち」の構図をイメージいただきたいです！）

また、私は、チーム立ち上げ初期のPO に意識してほしいこととして、次のようなことをお伝えしています。

「小さく作って、ユーザーや市場から反応を得る機会を高頻度に持って、変化を歓迎する仕組みづくりの早期確立」

これは、ジャストインタイムやフィードバックサイクルのというキーワードでよく紹介されています。

この状態を作るために、プロダクトバックログを活用する（適宜更新して、関係者間で理解共通化を図る）ことがとても重要です！プロダクトバックログについては、以前の記事でもご紹介していました。

ここまでの話を少しまとめますと、PO はこんな役割と言えそうです。

プロダクトオーナー（PO）は

スクラムチームの一員として、日々の価値探索と実現に貢献し、プロダクトの成長の方向性と中長期目標（プロダクトビジョン・ゴール）や短期目標（スプリントゴール）を設定/更新する。

また、それらの目標やその目標を達成するための道筋とアクション（プロダクトバックログとプロダクトバックログアイテム）を、チームで学びを得ながら日々管理/更新できる状態を作り出し、それらの変化についてもチーム内外から理解を得る。

…と、実はここまでは前置きでして、今回は、上記の役割を全うするためにPO としてチームにどのように関わるとよいかについて、具体例も挙げられるよう、スクラムイベントと絡めてご紹介したいと思います！

PO とスクラムイベント

ここから、PO のチームへの関わり方を各種のスクラムイベントなどと絡めてご紹介したいと思います！

少々長い説明になるので、まずはPO のイベント参加要否だけ挙げますとこんな感じです

イベント等	プロダクトオーナー参加要否
スプリントプランニング第一部	必須
スプリントプランニング第二部	任意（できれば参加）
スプリント	積極的に関わる！
デイリースクラム	任意（できれば参加）
スプリントレビュー	必須
スプリントレトロスペクティブ	必須（内容に応じては任意だが、できれば参加）

1. PO とスプリントプランニング（第一部、第二部）

PO は次のスプリントを行う目的（スプリントゴール）を示し、その目的を達成するために実現すべき価値（PBI）の透明性向上に努めます。

スプリントプランニング第一部（WHAT の定義）は、スプリントゴールと対象PBI をチームで合意する場となるため必須参加者です。

スプリントプランニング第二部（HOW の定義）は、開発者主体の場となりますが、PO も同席しておくことで、そこで見つかったPBI に関連する疑問や課題をその場で解消しやすくなるので、できれば参加しておくと良いです。（内職しながら呼ばれたら応えるくらいの感じでもいいと思います！）

2. PO とスプリント

スプリントゴール達成に向けた価値の実現は、開発者だけに委ねられているものではありません！

多くの場合、スプリントゴール達成は「実際に動くものの開発」が主たる要素になるかと思いますが、ゴール達成を阻害しうる課題の解消については、PO やスクラムマスター（以降SM と略します）も協力して対応すべきです。

スクラムガイド2020 で「”開発チーム”という枠（開発者に対する集団名）の撤廃」と「自己管理型チームの実現」についての変更が加えられました。

この変更が何を示唆しているかというと、ゴール達成に必要なことはスクラムチーム全体で取り組むべしというものだと私は理解しています。

これは、PO やSM も開発タスクに取り組むべきだ、という意図ではなく、「PO vs 開発チーム」のようなスクラムチーム内で線引き構造をなくして「問題 vs 私たち」の状態をめざして、チームで団結して目的を成し遂げることを意味しています。

ここまでの話を踏まえると、PO も日々の開発に支障をきたしている問題があれば開発者と共に解決を目指すべきです。

例えば、スプリントで着手しているPBI の内容についての質疑応答や、必要に応じて（スプリント中に新たな発見や学びを得たときなどに、）完成の定義に修正が必要な場面もあるかもしれません。また、チーム内では完結しない作業が発生すれば（SM とも協力して）関係する人や組織に働きかける必要もあるかもしれません。

3. PO とデイリースクラム（朝会）

デイリースクラムは開発者主体で実施されるものなので、任意参加で良いかと思います。

ですが、前述の「PO とスプリント」の項目で述べたようなゴール達成を阻害しうる課題がこの場で明確になることもよくある話なので、可能であれば同席しておくことを推奨します。

一方、「PO忙しい問題」にあるようにPO の時間は貴重です（もちろん開発者の時間も貴重です！）。朝会のタイムボックス（一般的に15分）は守られるよう、開発者は意識と工夫を忘れないようにしましょう！

4. PO とスプリントレビュー

スプリントレビューはステークホルダーと共にプロダクトゴールへの到達具合の確認とプロダクト成長に資するアイデアを出し合う場です。

プロダクトの成長の方向性やゴールを示し、関係者間の認識共通化を図るというPO の役割に照らし合わせると、必須参加であることは自明ですね。

また、関係者間の認識共通化（＝ステークホルダーマネジメント）の観点から見ると、スプリントレビューの場に誰を呼ぶか？どんなふうに見てもらうか？についてもPO は筋の良い選択ができます。

PO と共にチーム外の参加者として誰を招待するか？とか、内容を事前にチームですり合わせる、とかをおこなっておくとより良いです！

5. PO とスプリントレトロスペクティブ

チームの活動を円滑にする、チームの成長に資する場です。

PO はもちろんスクラムチーム全員が参加必須です。

6. PO とリファインメント

プロダクトバックログを構成するPBI の作成や精緻化を行う場ですので、基本的にはPO は必須と考えるべきです。

チームによっては開発者マターな（例えば、技術的負債の解消のような）PBI などPO にとって関心の少ないPBIを作成するケースもありますが、PBI の内容を把握せずしてプロダクトバックログの管理は難しいので、「今日は内容的にPO の出番なし」と割り切り判断で欠席を繰り返すと残念な状態を招きかねませんので、毎回参加することが望ましいかと思います。