PMとしてスクラムプロダクトオーナー（PO）の役割を半年くらい担ったところで、考えたりやってみたことのメモ
下記Devdayで開発マネージャー達が語ったり、daiksyさんがCreator's noteで記事投稿してくれているのですが、Chatworkでは今後に向けて Scrum@Scaleをベースにしながらスクラム開発のかたちを探っているところです。その中でPMも徐々にPOの役割を担いつつあり、プロダクトマネジメント部内のPMメンバーも色々と試行錯誤しているので相談を受けます。
先日自分のメモを漁っていると、前職で半年くらいスクラムPOをやった時点で、考えたりやったことをまとめたメモが出てきました。
前職のスクラムチームでは、外部のアジャイルコーチに2人も入ってもらい、毎週ラーニングセッションと言う学びを共有する会なども設けてもらっていたので、試行錯誤や相談ができる恵まれた環境でした。その中で考えたことを改めて読み返して、POという役割に悩んでいる人達の参考になることもありそうかなと思ったので、少し整理して公開することにしました。
これは何か
プロダクトマネージャー（PM）がPOとして、どういう役割を担うのかの個人的整理で、下記のスクラム開発における疑問や課題を一定明確にしようとしたメモを外向けに少し整理してみたものです。
1. 基本的にスクラム開発とはどういうものか
2. POが担うべき責務は何か
3. POはどこまでHOWに踏み込んでバックログ管理を行うべきか
4. 開発チームが運用責務で他スクラムの依頼対応もしなければならない場合、チームが事業にインパクトをもたらせる開発のための工数をどうやって確保していくべきか
基本的にスクラム開発とはどういうものか
Mitch Laceyの「スクラム現場ガイド」（p367-368）で「スクラムは、スクラムマスター、プロダクトオーナー、開発チームの3つの役割から成り立つ」と述べられていて、その説明がしっくり来たので下記に引用します。
レーシングカーの構成要素に例えると、開発チームがエンジンであり、プロダクトオーナーはドライバー、スクラムマスターは潤滑油やセンサーといえる。
良いスクラムマスターは開発を進化させる。メーターやセンサーを仕込んで、チームが性能を発揮できているかをわかるようにする。スキル（潤滑油）を持って問題対応を手伝う。対立を冷静に扱ったり、コミニュケーションに優れていたり、人同士の信頼と尊敬を養い、チームのダイナミズムを理解する。
プロダクトオーナーは顧客とステークホルダーの利益を代表する。ドライバーとして、車を正しい方向に向けコースから外れないように調整し、結果を出す。製品のビジョンを作り、育て、チームとステークホルダーに伝える。プロジェクトの投資対効果と財務上の責任を持ち、何をいつ作るか、期待通りかを判断し、最終的なリリースの決断を下す。
開発チームは、プロダクトオーナーのビジョンをスクラムマスターの助けを借りて実行する。
スクラムのスプリントサイクルイメージはこんな感じ。
POの担うべき責務は何か
少し古い本ですが「スクラムを活用したアジャイルなプロダクト管理」（Roman Pichler著, 2012）には、こう書かれていました。
Ken Schwaberが "Scrum Guide" で、プロダクトオーナーのことを以下のように説明しています (Schwaber 2009, 5)。
プロダクトオーナーは、プロダクトバックログを管理し、チームが実施する作業の価値を保証する「唯一の責任者」です。プロダクトバックログを誰でも確認できるように保証します。(p2)
GEの元会長兼CEOであるJack Welchは、「優れたビジネスリーダーはビジョンを思い描き、それを明確化し、情熱を注ぎ自分のものにし、何が何でも完成させる」と言います。プロダクトオーナーは、まさにこのようなリーダーです。(p2)
プロダクト開発でのOutputとして責任を持ってバックログを運用しながら、ビジネスとしてOutcome（顧客に提供する価値と収益価値）を追い求めて完成まで持っていく姿勢が重要という理解にしています。
PMやPOが、本質的にミニCEO的なビジネス意識を持つことは重要だと考えていて、自身としてもその観点は重視しています。
今回はPMやPOとしての階層的な役割については触れないですが、プロダクト全体ではなく一部のコンポーネントを担当するPOであれ、このマインドを持つことは大事だと考えています。少なくとも自身が受けたCSPOやA-CSPO研修ではPOのもっとも重要な役割はビジネス価値を証明し判断することだと言われていました。少なくとも、この部分だけはPOがMUSTで、他は開発チームで分散することも可能だと。
自身の経験からも言えますが、概してPOは求められるスキルや責務も多く、一定組織が大きい（1POでプロダクト全体の意思決定ができない、ステークホルダーや折衝が多い）と、1人ではボトルネックになるケースがほとんどです。ボトルネックになっていない場合はPOがスーパーマンか、チームとしてのOutcomeがあまり意識できていないかのどちらかだと思います。（対応策として、POにレイヤーを設けたりPOチームを組成するやり方がありますが、これはまた別の機会に）
スクラムチームのPOとして意識したこと
下記は、当時の開発チームにぶつけてみたPOとしての考えです。
1. 製品開発チームがすべてという考えを主軸にする
もっとも重要な概念は、製品開発チームがすべてであるということ。他の人が行うことは、製品開発チームの生産性を最大限に高めること (INSPIRED, p45)
POというのは、開発チームのエンジン性能を最大限活用して、レースに勝つことが仕事だと捉えることにする。「開発チーム以外を軽視してもよい」と言いたいわけではなく「必要なものをより良いかたちでより早く世の中に届ける。価値あるデリバリーが全て」なので、POは開発チームとポリシーを共有し、この効率的な生産性に意識を集中するべきという考え。
2. プロダクトビジョン（世界観）に理解共感してもらい、向くべき方向を共同化する
基本的には四半期では必ず、もし途中大きめの順列の変更や方針の追加など意思決定の変更がある場合にはメンテナンスを行い、開発チームにも説明する機会を設ける。
3. チーム外との優先順位の認識をそろえるベースを準備する
KRで設定したプロジェクトやその他企画から必要なレベルかつ工数を食いそうな案件はプライオリティプランニングシートを作成の上、POとして管理する。部署外のステークホルダー等とのコミュニケーションはこのシートで認識をあわせる議論と運用を行う。
4. HOWは基本的に開発チームにゆだねる
状況によって、POとの兼務で開発チーム内の役割を担うこともでてくる。例えば、このチームではデザイナーがおらず、PO兼UIデザイン（UX観点）で、デザインフレームやモックアップ作成も担っていて、UI/UX観点では開発チームの一員としてHOWの議論に入っていた。
ただし、意思決定は俯瞰して、POとしての判断を下すように意識する。
5. POとして、チームがインパクトをもたらせる開発のための工数確保を支援する
このチームは、サービス管理系のコードオーナーを持つというチームの特性上、他チームが起点となるタスクに3-4割とられる現状がある。より有効に企画しサービス改善を進めるためには、「生み出すインパクトの大きさ」を考えると同時に「一粒で、２度どころか３度美味しい解決策」を見つけ出す思考の意識が重要。即時対応して欲しいというチーム外のリクエストに対して、ロードマップ対応の枠の中でまとめて潰せるアイデアを考えて、必要があればステークホルダーと折衝することを意識する。
一定一緒に働いた上で、こういった考えをあらためて整理してみると、自分の考えの整理にもなって共有できるし、チームへのスタンス表明にもなるので、けっこう良かったかなと思っています。
その後の開発のためにチームと認識をあわせたこと
スプリントプランニングレベルのチケットサイズ分割
アジャイルコーチから「スプリントで扱うバックログアイテムは1〜3ストーリーポイントくらいの粒度に落とし込んだほうがよい」という話もあったので、チームとして意識していました。ただ、その中でプロダクトバックログの管理はPOがやるべきという基本があるとしても、実際にPO単独では分割の判断もつかず、この粒度までブレイクダウンができませんでした。
結局、初期は主にテックリードと密に連携して「このくらいのストーリー規模なら1スプリントでやれるかな…？」などと相談しながら、チケットを作成していくやり方を行っていました。結局HOWに踏み込んでいる感じになるし、なにより毎度時間を食うし、テックリードの時間もおさえる事になってしまうので、煩わしいだけにならないか？と感じていました。
その後、開発チームとも話をして、PO粒度の開発要大枠をFeatureやEpicとしての受入要件（Acceptance criteria）で握り、リファインメントの中で開発チーム主体で細かい粒度に分解する。スプリントで扱うStoryやTaskに対して、POは主にビジネス観点から確認や要望を出し、必要な時に最終意思決定をするかたちに落ち着きました。
最初はリファインメントにあまり時間を割いてなかったのですが、一定スプリントがスムーズに廻るようになるまでは、できる限りリファインメントに時間を割くことが超重要！ということも伝えておきたいところです。
開発メンバーからは「POとしてリファインメント前にチケットをチェックして、ストーリーを分割する方法が正しいかどうかを確認しておくのが良いと思う」といった助言ももらいました。
ロードマップで想定していたスケジュール感や見積もりが明らかに無理になった場合対応どうするか
ビジネスゴールに向けた意思決定は、プロダクト要求の優先度（Priority）ランク（P1/P2/P3...）で決める必要があるので、開発状況等で沿えない可能性が出てきたら、リファインメントやプランニングなどで開発チーム側からアラートを上げてもらう。その上でスコープや優先度の見直し調整をかけるという握りにしました。
合わせて、リファインメント前に30分ほどテックリード/スクラムマスターと認識合わせをする時間も作りました。
メモには他にもPMとして意識した責務とPOとして意識した責務みたいなことも書いてあったのですが、それはまた後日書こうと思います。
だいぶ長くなってしまいましたが、本日はここまで。