はじめに
スクラム開発における「プロダクトオーナー」という役割をご存知でしょうか！？
これまでウォーターフォール開発の経験しかなかった私が、今年の4月から一転アジャイル開発：スクラムチームの中で**「プロダクトオーナー」**という役割を担うことになり、世界は一変。
ほどなくチームにJOINし、なんとなく「スクラム風」にやり過ごすという日々。
そんな中、念願かなって、Scrum Inc.認定資格プロダクトオーナー（Licensed Scrum Product Owner、 LSPO）研修に参加できる機会をいただき、改めてスクラムとプロダクトオーナーについて体系的に学ぶことができました。
この研修を機に、私の中の「スクラム」や「プロダクトオーナー」の役割についての印象や考え方が変わったことについて、整理して書いてみようと思います。
一般的なプロダクトオーナーの定義とは？
スクラムガイドでは、以下のように定義されています。
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。プロダクトオーナーは、プロダクトバックログの管理に責任を持つ 1 人の人間である。
研修前に考えたPOの役割とは（Before)
そもそも、「ウォーターフォール畑」で育った私にとって、スクラム（アジャイル開発）に対しての印象は
- 定義されていることは理解できるけど、仕事として本当に成り立つの?
- ルール守ってやるって、なんかゲームみたい。仕事となるとそういうものじゃないでしょ？
という、どちらかというとネガティブなものでした。
さらに、その中の「プロダクトオーナー」の役割についても
「開発チームがより開発に専念できるように、その取り巻きの事をやる何でも屋」
くらいに考えていました。
あまりにもざっくりしすぎてますね。下記にもう少し分解して優先順位付けしてみました。
####■優先順位（高→低）
- 顧客の声を開発チームに届ける。要件としてまとめる。（主にこの役割。80%を占める）
- 開発するものの優先順位をつける
- 受け入れテストをする
- スムーズなリリースの準備
- スケジュール、進捗の管理
※上記すべてにおいてうまくいかない場合は1人で責任とらされる
考えただけでも大変そうですよね。
同じように考えながら仕事をしている現役プロダクトオーナーの方もいるのではないでしょうか？
研修後に考えたPOの役割とは（After)
研修を受けて特に良かった点は、プロダクトオーナーの役割をしっかりと理解できたことです。
受講前と同じように下記に優先順位順に整理してみました。
####1. プロダクトの目指すビジョンを持つ
いつまでに何を目指すのか？それをチームにしっかり説明できること。これはプロダクトオーナーにしかできない重要な役割である。
製品のビジョンは
- 売れるもの（顧客に喜ばれるもの）
- 熱意を傾けられるもの（作っていて楽しいもの）
- 実現できるもの
の３つのバランスがとれた中心点を考える。
そして、ことあるごとにこのビジョンに立ち返って、様々なことを判断していく必要がある。
####2. 方針に従った、本当に使える2割の要件を見つけ出すこと
製品の価値の8割は2割の機能に含まれている。顧客が本当に必要とするのはその2割だとわかっている。その2割をどうやって最初に完成させられるかを見極めることが重要。
要件を見つけ出すポイント
- 市場を見て、次の価値を高める
- 他のチームにも目を配り、企業全体の生産性を高める
- 他プロダクトとの戦略の違いを把握している
これは本当に難しい。今後精進していきます。
####3. 明確な優先順位付け
顧客にとっての最重要項目だけを考慮するとおもっていたが、それは次の要素のうちの１つでしかなかった...
- ビジネス上の効果が大きい
- もっとも利益につながる
- 一番簡単にできる
- リスクが少ない
####4. 常にバランスを意識する
顧客との連携
スクラムマスタとの連携
ビジネスと開発の双方の目線があり、どちらもバランスよく見ることができる人は、そう滅多にいるものじゃない。
だからこそ、プロダクトオーナーはどちらにも傾かないようバランスをとる必要があると思います。
プロダクトオーナーの業務のうち、ビジネスの重みが強い場合には、スクラムマスタと協力して少しPO領域を手伝ってもらい、
開発側が重い場合には、常日頃からビジネスサイドのステークホルダーを上手に巻き込み、協力してもらえる体制を作っておく。
全部自分でできるわけがない！と開きなおることも必要。重要なのは
タイミング良く周りに協力を仰ぎながらバランスを保つことを考えること
####5. 振り返りからのKAIZEN
スプリントごとにしっかり振り返ればいくらでもやり直しがきく。
今スプリントに限ってやってみて、それをすぐに振り返って軌道修正できるという仕組みが当たり前のようにまわり出したとき、面白いほどの発見や、自分が考えていた以上の成果が見えてくるのではないか？と考えられるようになりました。
万が一間違ってた場合には、スプリントの振り返りで誰かメンバーが指摘してくれます。
その時は「ごめんなさい。だよね、では次はどうしていこうか？」と言えればいい。誰も責めないし、怒りません。（すでに実証済）
だってそういうこと前提に作られたフレームワークなのだから、当然のことなのです。
そして、これはシステム開発に限ったことではなく、他の仕事であっても、日頃の生活（家事や育児なども含めて）であったり、どこにでも通用することだと考えています。
▼休日の家族の役割分担（プロダクトオーナー：ママ ※しっかりバランスとってます！）
最後に
私がプロダクトオーナーとして大切にしていることを書いておきます。
###スクラムのルールは絶対ではない！！
スクラムはフレームワークなので、様々なルールが定められているわけですが、油断していると知らず知らずのうちに「ルールを遵守すること」が目的になってしまっていることがあります。（ありませんか？）ルールの通りやっていれば安心するってやつ。
でも、以下をしっかり理解している場合はルールからはずれることがあってもいいと私は考えます。
- そのルールが生まれた意味をしっかり理解している
- ルールを破ってでも解決したい課題がしっかり見えている
- スプリントの振り返りでこの件に関して問題ないかウォッチし続ける
- 上記がチーム全体にしっかり共有されている
常に、想定外の事と出会っても臨機応変に対応できる**「アレンジ力」**こそ、プロダクトオーナーとしての力量を試される部分なのかなと。
楽しむことを忘れない
私のチームではスプリントごとに、注力したいこと、忘れないようにしたいことを、キャッチフレーズ（センスの良い１文）として掲げています。
なるべく前向きになれるような、明るくて面白いフレーズを心がけて作成しています。
▼実際のチームのSprint Burndown Chart（右上にキャッチフレーズ書いてますｗ）
何かつまづくことがあっても、それを見て「ほっこり」できたり、思わずニヤけてしまったりできるようなものにして、楽しみながらやるんだというメッセージを思い出せるよう、これからも続けていこうと思っています。
ぜひ皆さんのチームでもTryしてみてください。