スクラムチーム（Scrum Team）のプロダクトオーナー（Product Owner）は、これから作るプロダクトがどうなっていればユーザーにとって価値があるか？ということを考え、開発者に示す役割です。プロダクトオーナーは開発者（Developers）にプロダクトゴール（Product Goal）を示すことで、プロダクトの価値を高めていきます。
Scrum.org のスクラムガイドによると、プロダクトオーナー（PO）について次のように書かれています。
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。
プロダクトゴールを策定し、明⽰的に伝える。
https://www.scrum.org/resources/scrum-guide
またスプリントゴールについては次のように書かれています。
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。
https://www.scrum.org/resources/scrum-guide
つまり PO は、プロダクトが将来どうなっている状態が良いのか？を考えて、スクラムチームに伝える役割ということになります。
目次
プロダクトオーナーはプロダクトの価値を最大化する（プロダクトゴール＝将来 価値を出せるようになっているプロダクトの状態を考えて決める）
プロダクトオーナー（PO）は、これから作る（あるいはまさに今作っている）プロダクトが、将来どうなっていれば価値があるのか？ということを理解していなければなりません。もちろんこれは、長期目標としてイメージすることなので、必ずこうすれば成功するという答えを知っている必要があるというわけではないはずです。しかし、必ず成功するとは限らないとしても、これから作るプロダクトがユーザーにどう使われることで、ユーザーにとって嬉しいのか？とか、そもそも誰が使うのか？など、これから作るプロダクトとその周りのことには詳しくなければなりません。
もし PO が、他のステークホルダー（役員や上司など）から、ただ単にこのプロダクトを作るように言われて、PO を始めただけだと、PO としての役割を果たすことはできないでしょう。その背景にある、なぜこのプロダクトが必要なのか？やどういう価値をもたらすべきなのか？ということを、知って、理解する必要があります。またさらに、「価値を最大化する」のが PO の役割なので、PO が自分自身でこのプロダクトを本気で作りたいと思ったり、価値があると信じていたりしなければ、難しいでしょう。
もし、うまく行っていないスクラムチームがあるなら、PO が自分自身の役割を理解しているか？を確認するとともに、どのようにプロダクトをとらえているか？を確認してみると良いと思います。「私は上司からやれと言われたから PO をやっているだけで、本当はこんなプロダクトは欲しいとは思っていない」的な考えが垣間見えたなら、きっとそのスクラムチームは最後までうまくいきません。なかなかそういう本音を明確に口にすることはないと思いますが、話を聞いているとどう考えてもそう言っているように聞こえることを繰り返している、というよなことはあると思います。
そういう極端なケースではなくても、PO が、単にステークホルダーから与えられたプロダクトバックログの一覧（作りたいもの・作ってほしいものの一覧）を上から順に作る（作らせる）役割だと考えているケースは、割と多く見られます。受け身的な意味でなくても、役員などのステークホルダーが考えた一覧を自分で変えることなんてできないと思っているパターンもあります。そういう場合にも、なかなか PO としての役割を果たすことはできないでしょう。PO は単にプロダクトバックログの一覧を上から作ることを考えるのではなく、プロダクトがどうなっていれば価値があるか？を考えるのが仕事です。そのうえで、それを実現するための手段として、プロダクトバックログの一覧を自分で作る・書き換えるなど、コントロールできることが重要です。もし価値を最大化できるなら、ステークホルダーが考えたプロダクトバックログアイテムであっても変更したり破棄したりできる権限や能力、あるいは意思が必要とされます。もちろん、それを社内のコミュニケーションや必要なプロセスなどを通じて、ステークホルダーに適切に説明することが出来なければなりません。PO はステークホルダーの意見を取りまとめて代表できるように、ステークホルダーと丁寧にコミュニケーションできる人でなければなりません。
プロダクトオーナーは結果に責任を持つ（プロセスや管理に責任を持つのではない）
もうひとつ、プロダクトオーナー（PO）が誤解しているパターンとして、「PO は開発者の進捗を管理する人」だととらえている場合にも、スクラムチームはうまくいきません。スクラムチームの PO は開発者の進捗を管理しません。PO は「価値を最大化することの結果に責任を持つ」と書かれている通り、結果に責任を持つのであって、プロセスに責任を持つわけではありません。PO が開発者の作業の状況ややり方に細かく口を出してはいけません。
スクラムチームの開発者は自己管理型です。開発者は、自分たちで自分たちの進捗を管理します。例えば、POがデイリースクラムで毎日開発者から進捗報告を受ける、というのは間違いです。デイリースクラムは開発者のためのイベントであり、PO が参加したり報告を受けたりしません。もっと言うと、開発者は自分たちの進捗を、Azure DevOps Boards のようなシステムに入力していて常に見える化して共有しているので、開発者同士や開発者の上司に進捗を報告したりもしません。進捗は全員がリアルタイムで把握している状態で、デイリースクラムでは毎日再計画を行っています。もし、PO が開発者から毎日進捗報告を聞かないと安心できないのであれば、スクラムははおろか従来のウォーターフォールの開発でもうまくいかないでしょう（当然、ウォーターフォールの進捗報告では、報告のために綺麗にまとめられた資料が作られていて、そこには「お客様にはとても言えない真実」は含まれていないので、毎日進捗報告を聞いていても、失敗するときは失敗しますよ）。それよりも、Azure DevOps などのシステムの見方を教えてもらって、開発者に聞かなくてもおおよその進捗を把握できるようにしておく方が、より安心できるはずです。また、スプリントの期間中に想定外のことが起きたときに、スプリント計画通りに進まなくなりそうな場合には、開発者から事情を詳しく聞いて、例えば何を優先するか？何を諦めるか？などの話をするのは PO の重要な役割です。それはプロダクトゴールやスプリントゴールについて話し合うという意味で、開発者の進捗を管理したり、行動をコントロールすることではないのです。
また、PO が開発者の進捗を管理することはありませんが、開発者が作成したインクリメントが、PO が期待した通りの価値がある状態になっているか？ということには言及するべきです。もし期待したものと違うものが出来上がってきた場合には、プロダクトゴールの伝え方がうまくいっていないのかもしれません。もう作ってしまったものは、そのスプリントの中では改善が難しいかもしれませんが、次のスプリント以降では軌道修正をして、少しずつ価値があるものにできるかもしれません。そして、今後はそういった認識のズレができるだけ小さくてすむように、PO と開発者のコミュニケーションを改善するように、レトロスペクティブでアイディアを出し合う必要があります。あるいはコミュニケーションやプロダクトゴールには問題がなくても、実はやろうとしていたこと自体が「やってみたら思ったほどうまく行かないもの」だったのかもしれません。もしそうならより良い新しいアイディアを考えて、プロダクトバックログとして示すしかありません。開発者と一緒に地道にプロダクトの価値を上げていくようにします。
もし、スクラムチームでレトロスペクティブで改善を求めても、改善する気がなさそうな場合。例えばいくら言っても開発者が PO に質問をしてこないので、開発者と PO の理解のギャップが埋まらない・誤解が大きいまま開発が進んでしまう、というようなことがあるのであれば、スクラムマスタに相談するのがよいでしょう。あるいは、開発者がインクリメントを作成することをコミットしないで、何スプリント経過してもいつまでもずるずる何も完成してこない、などもスクラムのプロセスがうまく行っていません。
スクラムのプロセスがうまく行っているか？の責任を持つのは、スクラムマスタの役割です。もちろんスクラムマスタが動くまでもなく、スクラムチームの誰でも改善を試みることが出来ますが、それでもうまく行かない場合には、スクラムマスタにうまく行っていない点を明確に伝えて、そのポイントについての改善を重点的に考えてもらうのが良いと思います。PO とスクラムマスタを別の人が担うということを活かしていきましょう。PO からスクラムマスタに改善してほしいと伝えるのは正しい行動です。また逆に、開発者やスクラムマスタから見て、PO が役割を果たせていない場合には、明確にそのことを PO に伝えて改善してもらう必要があります。
プロダクトオーナーはプロダクトゴールを明確に伝える
スクラムチームのプロダクトオーナー（PO）は、プロダクトゴールを開発者やステークホルダーに明確に伝える必要があります。開発者は PO から聞いて理解したプロダクトゴールに合うように（外れないように）開発を行います。ステークホルダーは、各スプリントで完成したインクリメントをレビューするときに、全体の長期的計画から考えたときに今のスプリントがどういう位置なのか？というのも意識したうえでレビューをしなければなりません。そのためにステークホルダーも PO からプロダクトゴールを聞いている必要があります。あるいは、ステークホルダーの中にはこのプロダクトを作るためのお金を出している人もいるはずです。彼らはこのスクラムチームがいったいどういう計画に対してお金を使うのか？という説明なしにお金を出すことはできません。そういったステークホルダーはスプリントレビュー以外の場面での、PO とプロダクトゴールについて詳しく話し合うかもしれません。
PO がスクラムチームの開発者にプロダクトゴールを伝えるタイミングは、（スプリントプランニングやスプリントレビューなどの）スクラムのイベントだけでなく、開発者が必要な時にはいつでもコミュニケーションをとって説明できる必要があります。そのうえで、少なくとも最初のスプリントプランニングまでには、ある程度明確にスプリントゴールを開発者に伝えておかなければなりません。
最初のスプリントのスプリントプランニングで初めて話していたのでは遅すぎるはずです。おそらくスプリントプランニングの時間が足りなくなくて、開発する時間が足りなくなるか、スプリントプランニングで十分に理解が出来ずにイメージのギャップが大きいまま開発を進めて、完成したインクリメントが思っていたのと違う状態になります。スプリントが開始するより前に、十分に時間を取って、用意したドキュメントや動画で説明したり、もし可能なら開発者をユーザー（になる人たち）の現場に連れていってどういう状況で使うプロダクトを作るのか？を説明したりします。書籍 More Effective Agile では、こういった取り組みがいかに重要か？が説明されているので参考にします。
プロダクトゴールを数行のテキストで表現し、Azure DevOps のダッシュボードに見えるようにしておく
プロダクトゴールはおそらく、プロダクトバックログの一覧の中に表現されていて、それぞれがプロダクトゴールを実現するように書かれていると思います。そうであっても、プロダクトゴールをより適切に簡潔に表現した、シンプルな数行のテキストがあった方がいいと思います。誰でも「これってプロダクトゴールにあっているんだっけ？」と疑問に思ったときに、このシンプルなプロダクトゴールがあると、「そうだそうだ」とか「いや、ちがうな」といつでも立ち戻ることが出来ます。
Azure DevOps では、数行のテキストで表現したプロダクトゴールを、ウィジェットで見えるようにしておくことができます。
Azure DevOps Boards の編集画面で、Markdown ウィジェットを追加します。サイズを 2 x 2 など読みやすいサイズにすることが出来ます。スプリントゴールをテキストで記載できるほか、Markdown 形式で参照先のドキュメントのリンク（URL）などを記載しておくことが出来ます。
Markdown 以外にも、プロダクトビジョン（Product Vision）を表現する専用のウィジェットがあります。
The Product Goal is a reflection of the product vision, the bridge between Sprints and the vision.
https://www.scrum.org/resources/blog/product-goal-explained
「プロダクトゴールはプロダクトビジョンの反映であり、スプリントとビジョンの架け橋である」ということをイメージして、プロダクトゴールとプロダクトビジョンを並べてダッシュボードに置いておくのが良いかもしれません。
これらうまく活用して、スクラムチームの誰でもすぐに確認できるように、ダッシュボードを工夫しておくと良いでしょう。
コメント
