Scrumにおけるプロダクトオーナーの役割を言語化した話
※本記事はAgile Tech EXPO Advent Calendar 2020の23日目の記事になります。
過去業務委託ながらプロダクトオーナーを務めていた際に、プロダクトオーナーの役割を言語化したことがあります。
本記事ではそのときの思考過程と、どのように言語化していったのかを記載しました。
何故言語化するのか?
Scrumを上手く導入し開発を進めていくためにはスクラムマスターだけでなく、プロダクトオーナーの役割がとても重要だと考えます。 しかしスクラムマスターについてはScrumの推進者として、チームとどう接するべきか、何を行っていくかなど割と具体的な内容が書かれている一方で、 プロダクトオーナーについての記載はとてもシンプルです。
例えばスクラムガイドでは以下のように記述されています。
プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。
・プロダクトゴールを策定し、明示的に伝える。
・プロダクトバックログアイテムを作成し、明確に伝える。
・プロダクトバックログアイテムを並び替える。
・プロダクトバックログに透明性があり、見える化され、理解されるようにする。
スクラムマスターをScrumの推進者とするならば、プロダクトオーナーはScrumの一番の理解者であって欲しいと思います。
しかしプロダクトの価値を最大化することに結果に責任を持つ
という意味とそれに伴う役割を誤解していると、プロダクトオーナーはScrumの破壊者になってしまうと考え言語化する必要を感じました。
スクラムマスターが正しく機能していなくてもScrumで定義されているプラクティスによってある程度こなすことはできると思います。
一方でプロダクトオーナーが機能していないとScrumチームが機能せず、Productの発展も死んでしまうことになります。
大きいからこそ影響は大きいのでやるべきこと
・やってはいけないこと
を定義することが大事だと思い、言語化=定義を行うことにしました。
※プロダクトオーナーがScrumの破壊者になり得る理由
どういう環境でどういう立場の人がプロダクトオーナーになるかによって様々な理由が生じ得ますが、 プロダクトオーナーが持つ責任が大きいからこそマイナスの影響が大きく出てしまうためだと思います。
例えばプロダクトオーナーが機能しない(あるいは誤った行動をする)ことで - プロダクトバックログの優先順位が整理できず価値の最大化ができない - プロダクトバックログのアイテムが不明瞭で開発着手できない - 安易に差し込みタスクを発生させてしまう - スプリントレビューでフィードバックを正しく受け入れられない - チームは何を目的に開発しているのか分からなくなってしまう
といったところが起き、本来Scrumによって得られるであろう恩恵が失われてしまうと思います。
言語化した当時の環境
- 自社プロダクトの開発を行っている会社の一部署
- 開発全体での人数は50〜60人程度
- 事業責任者、組織責任者の下に各Scrumチームを組んで開発していた
- 各チームでプロダクトオーナーに求められることは微妙に異なる
- 基幹システムにおいては多数の部署との調整が発生する
- システムリプレイスを行っているチームではプロジェクトマネジメント能力が求められる
- 新規プロダクト開発ではプロダクトビジョンの策定やチームビルディングが必要になる
- チーム横断する作業が発生した際に何を基準に調整するかが不明瞭だった
作成プロセス
作成はおおよそ以下の順序で進めていきました。 1. 草案となる定義を作成 1. ユーザーストーリーテンプレートの作成 1. 各スクラムイベントにおけるプロダクトオーナーがやるべきことをリストアップ 1. プロダクトオーナーがやるべきことを実行するために必要な権限の定義
1. 草案となる定義を作成
起案するとともに議論の叩き台となるものを作成しました。
ここではプロダクトオーナーの役割を定義する理由や課題感、その時点で自分が心がけていることを書き出したものを用意していました。 草案の内容自体は議論の呼び水程度の目的とし、ここで重視したのは課題感の共有でした。
色々なチームが存在していたので、プロダクトオーナーが機能しないことによる課題感が擦り合っていないとその先の議論は上手く噛み合わなくなります。
課題を共有し論点を明確にするというのがこのステップでの目的でした。
2. ユーザーストーリーテンプレートの作成
ユーザーストーリー形式にし書式を統一した理由はプロダクトオーナーも開発チームもそのアイテムの価値を意識するようになること、価値を言語化することでコトに向かうことを目的としていました。
※ユーザーストーリー形式については株式会社トラーナさんのテックブログに投稿した下記の記事をご覧ください。
開発要望をユーザーストーリー形式にした話
今回の記事内容とトラーナさんとは一切関係はありません
3. 各スクラムイベントにおけるプロダクトオーナーがやるべきことをリストアップ
スクラムイベント毎にプロダクトオーナーは何をやらなくてはいけないのかを書き出しました。 特にスプリントプランニングとスプリントレビューを中心にプロダクトオーナーに求められることは何なのか、どんな準備をしなくてはいけないのかなどを洗い出し、 それに必要な知識や能力は何なのかを考える、という流れで進めました。
各チームが担当している領域、各プロダクトオーナーのこれまでの経歴や経験によって認識は異なっているので、洗い出しと共通項の擦り合せとを行いました。 ここのプロセスが一番大変で一番時間が掛かったと記憶していますし、その過程の中で新たな課題もいろいろ出てきてスムーズには行きませんでした。
一方で、各チーム特有の課題が見えてくることで今まで知らなかった他チームの事情への理解も進むという副次効果もありました。 この副次効果はチーム横断の作業を進めるにあたってチーム同士の協働に少なからず効果があったと思います。
4. プロダクトオーナーがこれらを実行するために必要な権限の定義
最後にリストアップした内容を整理し、必要な権限を与えられるようにするための調整を行いました。 企業文化によってはとても難しいと思いますが、権限のない名ばかりのプロダクトオーナーはただの伝書鳩と化し存在意義が無くなってしまうので、必ずやらなくてはいけない作業だと思います。
スクラムガイドにも > プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。
というように組織全体でプロダクトオーナーを立てる必要があると書かれています。
策定したプロダクトオーナーの定義
最後に当時作成したものを一部抜粋して紹介します。
● プロダクト理解
○ 担当するプロダクトが関わる業務範囲や業務フロー・運用体制を把握する
● プロダクトビジョン定義
○ 事業戦略に沿った形で担当するプロダクトのビジョンをチームとして定め、開発チーム・ステークホルダーに共有し説明責任を果たす
● スプリントプランニング
○ ユーザーストーリーテンプレートを元にストーリーを書く
○ ステークホルダーからの意見・要望の吸い上げ(要望リストの精査を行う)
■ ステークホルダーが意見を言いやすいようにファシリテートする(外部ファシリテーターを 立てることを検討しても良い)
○ ステークホルダーと受け入れ条件のすり合わせ(受け入れ条件を受け入れてもらう)
● スプリントレビュー
○ スプリントレビューに適切なステークホルダーを呼ぶ ○ ステークホルダーが差し戻すことを受け入れる
■ フィードバックを元にステークホルダーと相談しリリース判断を行う
■ ステークホルダーが意見を言いやすいようにファシリテートする(
● プロダクトオーナーの権利
○ プロダクトの意思決定権限を有しプロダクトバックログに何を載せるかはプロダクトオーナーが決定する
以上です。
もしScrumを導入しても上手く機能しない場合、実はプロダクトオーナーが機能していない可能性があるのでプロダクトオーナーの役割を言語化するという試みをしてみてはいかがでしょうか。