はじめに
先日、認定プロダクトオーナー研修を受講し、無事（？）認定されました。自分の整理と身近な人にその情報を伝えるために学んだことをまとめておきます。
記事に書くこと
- 研修を通じて学んだ基本的な考え方やマインドセット
- 研修中の特徴的な出来事
記事に書かないこと
- Scrumのセレモニーやアーティファクトの解説
- 研修で投げかけられた問に対する解答
どんな研修？
- Scrum Alliance®の認定スクラムトレーナーによる、ProductOwnerについての研修
- 「研修」という名前はついているが、「トレーニング」「修行」という表現が正しい
- よくある座って講義を聞いているような研修ではない
- ProductOwnerとしての考え方、言動を常に考え続ける3日間
- 3日間の間にProductOwnerとしての能力（というより素質？）を評価された場合、CSPOとして認定される
- トレーナーによるが、基本的に座って参加すれば資格を取れるものではない
- 今回私が受講したのは、日本人唯一の認定スクラムトレーナーである江端 一将さん
ProductOwnerの役割
ProductOwnerの役割は、ScrumTeamのROIを最大化すること。
プロダクトの価値を最大化する、という文脈で捉えていることがあるが、あくまでこれが役割。
ScrumTeamとは
この後Areaという考え方をまとめるにあたり、改めてまとめておく。
ScrumTeamとは、以下を含む集団の総称。ProductOwnerの人数で数える。
ProductOwner
- ScrumTeamに1人
- ScrumTeamのROIを最大化させる
- ただし、営利団体に属しているならば、当然求められている最低限のハードルは越える必要がある
- ROIはヒトモノカネだけではなく、もっと細分化して考えなければならない
- いうならば、コトに立ち向かわなければならない（と感じた）
- Why、Whatを考える
- Teamの増減の判断はできる
- 人を選ぶことはできない
ScrumMaster
- Teamに1人
- 実現性を高め、ベロシティを高止まりさせる
- Whyを考える
Team
- 7±2人（複数あればTeams）
- 生産性を最大化させる
- Howを考える
ProductOwnerはTeamが増えても一人。とても大変。
Areaという考え方
とはいえ、ScrumTeamが増えるとProductOwner一人では難しくなってくる。
Scrumの拡張手法として、スクラムアライアンスとしてはLeSSを推奨。
ProductOwnerにAreaという概念が出てくる。
- ProductOwnerは1人だが、それにぶら下がるAreaが登場する
- AreaごとにAreaProductOwnerを配置する
- 一人のAreaProductOwnerあたり最大8Teamまでとされている
- Areaの数に制限はないが、Areaの階層化はコミュニケーションパスが増えるため望ましくない
- ProductOwnerは全体としてのROIを最大化する必要がある
- AreaProductOwnerはAreaのROIを最大化する必要がある
ProductOwnerとして常に考え続けなければならないこと
- 計測できるか
- 戦略はあるか
- リスク
- 不確実性
- エスケーププラン
- 交渉ポイントはどこか
- 相手のwillは何か
- （考えは）一貫しているか
- 適切な組み合わせは何か
- TimeboxではなくTimeslice（ただの時間分割）になっていないか
- ボラティリティゼロ
- 計画に対しての乖離をできるだけゼロにするためには
- 情報精査
- エデュケーション
- 循環
- ProductOwnerの言動はすべて繋がっている
- 矛盾が生じていないか
ProductOwnerとして、上記のポイントを押さえることは最低限のスタートライン。
ただ、これらをセンスでできる人は存在しない。必ずトレーニングをしなければできるようにならない。
ProductOwnerへの"基礎的な"質問
江端さん曰く、これらの質問はとても基礎的なものだと仰っていました。
- ScrumMasterを選定する基準は何か
- ProductOwnerの最初の任務は優秀なScrumMasterを選定すること
- （Scrumにおける）時間軸をどう定めるのか
- Sprintもそうだが、それだけではない
- ScrumMasterがScrumをやるべきではない、と言っている
ProductOwnerとして、やったほうがROIが高いと考えている
この場合、どのようにScrumMasterを説得するか - Sprintの長さはどれくらいが良いか、またその理由は
ProductOwnerが良いと考える長さとTeamが良いと考える長さが異なる場合はどうするか - ステークホルダーからのプレッシャーにどのように立ち向かうか
ex) もっと早く作れないのか - Definition of Doneを作るタイミングや維持の方法は
- ProductOwnerとして、ScrumでROIを高めるべきところとScrum外でROIを高めるところはどこか
- Scrumの各セレモニーにおいて、ProductOwnerとして得たい情報は何か
プロジェクトの時間軸やセレモニー外の時間のことを念頭においた上で、各セレモニーにおけるInvestmentとReturnは何か。また、その優先順位は。
トレーニングの中で、いくつか答え合わせはしましたが、一番大切なことは"ProductOwnerとして常に考え続けなければならないこと"を念頭においた上で、自分でその答えを考え続けることだと感じました。もちろん、答えとして外してはいけないポイントはあるでしょうけれども。
なお、トレーニングでは、補足的な講義を交えつつ、この質問について考えたり、ほかの参加者と交渉（実質はただのディスカッションに成り下がっていましたが）をしているだけで丸1日以上費やしていますが、答えにたどり着けている人はいなかったのではないかと思います。
Scrum先進国と言われるドイツでは、この程度の質問は5分程度で片付けられてしまう、とも仰っていました。
Definition of Done
Scrumにおけるアーティファクトの一つであるDefinition of Doneについて、説明いただきました。
この内容自体は、本来は認定スクラムマスターのクラスで学ぶべき内容なのだと思いますが、ProductOwnerとしてはProductBacklogを通じてundoneをコントロールする必要があるため、初めて聞くとなかなか理解が難しいものであることも踏まえてそれなりな時間を使って説明されたのだと思います。
私は2年前に江端さんの認定スクラムマスター研修を受講しているので復習という感じでしたが、多くの受講者がしっかりと理解に落とし込めていないようで苦戦していました。
ただ、ProductOwnerとしてはDefinition of Doneを理解することは目的ではなくスタートラインであるはずなので、あやふやな場合はきちんと理解に落とし込まなければなりません。
なお、2年前にCSMを受講した際、Definition of Doneはチームが管理するものだという理解をしていましたが、今回のトレーニングを経て組織として考えるべきものと認識を改めました。チームはdoneを遂行する責任がある、というだけ。
例えば、タリーズコーヒーを例に挙げるならば、食中毒にならないこと、というようなものは当たり前に守られなければならないものです。それを、チームの責任で「私たちのチームは食中毒にならないことはDefinition of Doneから外そう」となってはおかしい、というような説明をされていました。
プロダクトごとに組織として考えるのがよくある形かもしれませんね。
Acceptance Criteriaとの関係
どちらを先に取り組むべきか。
- AC -> Done
- Done -> AC
1.の順序で取り組んでいる状態がundone。doneであれば、必ず2.の順序で取り組まれているはずなので、2.の形を目指さなければならない。
もしundoneがあるのならば、次のSprintでしつこいくらいProductBacklogの先頭に積むしかない、とのこと。
優先順位を考えるために
チケット名と見積もりサイズのみが記載された、ProductBacklogItemを模したカードが配られて、ProductOwnerとしてこれまで学んだことを踏まえて優先順位をつける、というお題が与えられました。
ProductBacklogItemの内容は、
- 画像をアップロード
- ログイン
- 画像を注文して郵送
といったように、画像や動画を使ったWebシステムのようなものでした。後に明かされましたが、世界有数のScrumTeamを持つといわれる、とある有名な会社の有名なアプリケーションの最初のProductBacklogだ、とのことでした。（江端さんは世界一じゃないので大したことないですよね？と仰っていましたが。笑）
2人1組で進める中で、なぜその順序なのか、どの単位でリリースするのか、などといったことを議論しながら25分間で並び替えを行いましたが、終わった後にボロクソにダメ出しされました。
決定的なのは、チームのベロシティをなぜ確認しないのか、ということ。
加えて、多くの人たちが最初のリリースまでに色々な機能を詰め込んでしまう、ということでした。
小さくリリース（投資）して細かくリターンの検証をしなければならない、というのが大原則であり、それを踏まえると最初のリリースに必要なものは「画像をアップロードする」だけになる。
それだけでは価値がない、と勝手に思い込んでいるだけであり、
- 画像をアップロードする、ということに価値があるかどうか
- それ以降のProductBacklogItemの並び順の適当性はどうか
といったことを一つずつ検証していく必要がある、とのこと。無意識のうちに、投資（=ヒトモノカネ）に対する効果として利益を出す必要がある、と思い込んでいるのがそもそもの原因。
大切なことは、価値を検証するためにはできる限り細かい単位で物事を考える必要がある、ということ。加えて、価値を測定する指標を持ち計測し情報を精査していくことも必要ですね。
ProductBacklogItemを分割する
優先順位を決めていくにあたり、そもそも大きすぎるProductBacklogItemは分割していく必要があります。ボラティリティを限りなくゼロに近づけるために、当然の営みです。
例えば、今回のワークでは「動画をアップロードする」というProductBacklogItemのサイズが8だったのですが、Teamのベロシティは5とのことでしたので、分割しないとそもそもSprintに収まりません。
私はこれを分割する**"方法"について苦労していたのですが、分割の"観点"**は何かを考えるべきだ、と江端さんからアドバイス頂きました。
最悪なのは、ProductBacklogItemに書かれた文章で分割するということもやり方だそうです。そもそも今回の「動画をアップロードする」なんてものは文章で分割しようもないですし、そりゃそうです。
例えば、ユーザー体験（UX）で分割する、というのが一つの観点だ、と仰っていました。ワーク中ではなかなか良い具体例が思いつかなかったのですが、例えば動画であれば「エンコード」「編集」「アップロード」などが考えられるのかな、と思いました。その他、よくあるのはCRUDで分割する、とかでしょうか。
いずれにせよ、そういった観点を踏まえて分割し、そのサイズはAcceptanceCriteriaで調整する、というのが王道パターンのようですね。
なお、AcceptanceCriteriaは、やってほしいこと：やってほしくないことの比率は1:2が黄金比だ、と仰っていました。そもそも、AcceptanceCriteriaでやってほしいことがたくさんある時点で、そのProductBacklogItemは分割すべきなんでしょうね。
また、ProductBacklogItemを分割するにあたり、INVESTという考え方も忘れてはいけない、とのこと。これはよく聞く話ですかね。
- Independent（独立している）
- Negotiable（交渉できる）
- Valuable（価値がある）
- Estimable（見積もれる）
- Small（適切な大きさ）
- Testable（テストできる）
分割をしていく中で特に難しいのは、Independentです。当然、分割をすればするほど依存関係が生じてしまうことが多いですよね。そうならないよう、AcceptanceCriteriaをマネージすることが大切かつ難しい、と仰っていました。AcceptanceCriteriaは、ProductOwnerがInvestmentをコントロールする最大のポイントだ、とも仰っていました。
個人的に感じたのは、AcceptanceCriteriaの確認方法を、ほかのProductBacklogItemによって実現される機能に依存すると、マネージできなくなってしまうのでアンチパターンのように感じました。
あくまで確認方法は機能を問わないもの。例えば、「登録したXXをYY画面で確認できる」というものではなく、「登録したXXをデータベースで確認できる」というような形が良いのかな、と思いました。
この例は、いわゆる機能間の結合試験をAcceptance Criteriaにしている状態です。しかしながら、機能間の結合試験はDefinition of Doneにあって然るべきですから、「登録したXXをYY画面で確認できる」というのはYY画面に関するProductBacklogItemが実現されたときのDefinition of Doneで担保されるべきテクニカル品質なのだと思います。
マーケットやProductについて考える
ProductOwnerは（リターンをくれる）マーケットの課題を解決することがお仕事。
最初にやるべきこととして、マーケットの特定と課題の設定が必要。この課題（仮説）がProductBacklogItemとなる。
マーケットは、ProductOwner以外はすべてマーケット。例えばScrumTeamは最も身近なマーケットとなる。
勘違いされがちなのは、ProductBacklogItemは1つの製品に対する課題という文脈で用いられていることが多いが、正しくはProductOwnerがROIを最大化するための課題の集合体だと考えるべきである。
Productとは、対象者（社）へ提供しようとする仮説の価値だ、と仰っていました。
Product ＝ 製品、と安直に考えてしまっていたけれども、Scrum、というかそもそも英語圏におけるProductはそのまま製品ではない、ということらしい。
（余談）ProductOwnerやScrumMasterの課題をどう扱うか
ProductOwnerやScrumMasterが取り組む課題は、Teamが見積もることができないのでサイズ0としてProductBacklogに追加する。そもそも、ProductOwnerやScrumMasterが取り組む課題は、複合的に複雑なので見積もることができない、ということも多い。
スパイクは、（Teamから見て）マーケットに価値を提供しない課題。ただ、ProductOwnerの目線としては、スパイクという投資に対してTeamの成長などといったリターンがあるなど、ROIの観点から容認すべき、とされている。
SprintBacklogやProductBacklogは誰が作るべきか
ProductBacklogItemは誰が追加してもよいものであり、最終的にはProductOwnerが伝えた戦略に基づいて、Teaｍが自律的にProductBacklogを作ることができるScrumTeamを目指すべきです。
2年前に認定スクラムマスターの研修を受けていたこともあり、そのこと自体は理解していたつもりですが、もう少し踏み込んでそれらについて学習しました。
大半のScrumTeamは最初はStep1の状態なので、ProductOwnerがマーケット課題を考えて、その上でProductBacklogやAcceptanceCriteriaを作る必要があります。しかし、当然ながらProductBacklogなどを作る作業は時間がかかるので、POの時間という投資が大きくROIを最大化することはできません。
徐々にStep2の状態を目指し、ProductOwnerは本来やるべきマーケット課題を考えることに注力し、それ以外はTeamが自律的にできる状態を目指すのがROIを最大化することにつながります。
Step2の状態になったとしたら、ProductOwnerがやるべきことは
- マーケット課題の検討、および戦略の見直し
- 優先順位を決定する
- とはいえ、戦略がTeamに浸透していれば、そんなに変更はなくなるはず
- AcceptanceCriteriaをマネージする
- TeamがProductBacklogItemと合わせてAcceptanceCriteriaを作成できるのが目指すべき状態
- ProductOwnerは、ROIの観点からAcceptanceCriteriaにフィードバックしてInvestmentをコントロールする
これくらいで、世界中のScrumTeamがどうやってstep2を実現しようかと苦心しているところだと仰っていました。
ProductOwnerが考えるべきマーケットの範囲は？
ProductOwnerはどこまでのInvestmentやReturnを考えるべきか。
| どこに貢献する？ | Investment | Return |
|---|---|---|
| 社会 | ※ | 〇 |
| 業界 | ※ | 〇 |
| 企業 | ※ | 〇 |
| 組織 | （〇）※ | 〇 |
| ScrumTeam | 〇 | 〇 |
Returnという面から考えると、やはりできるだけ大きい範囲でReturnがあることが望ましい。とはいえ、いきなり社会貢献といってもなかなか難しいものはある。
Investmentから考えると、ProductOwnerがコントロールできるのはScrumTeamと、せいぜい組織くらいまで。それ以上のInvestmentは制約が生まれることが多く現実的ではない。
※の部分はScrumMasterがコントロールできる形が理想。さらに言えば、ProductOwnerがInvestしなくてもよい状態を作ることができるのが良いScrumMaster。
理想としては、InvestmentとReturnは1:Nの関係が望ましい。少ない投資で大きいリターンが得られるほうが良いのは言うまでもない。
最後のお題：このクラスのROIを最大化してください
トレーニング最終日の半日ほど、このお題をクラスとして解決する、ということに取り組みました。
これまで学んだ要素を踏まえて、ProductOwnerとしての振る舞いを考え実践する、という内容です。
最後までまとまらないままタイムアップを迎えたわけですが、特に大切だと思ったことをいくつか。
"ProductOwnerとして考えなければならないこと"を踏まえた上で論理的な案であるか
このお題に限らず、Scrumに取り組む人間、特にProductOwnerは常に論理的であるかどうかを考える必要があると感じました。どういう戦略でなぜそうするのか、が一つ一つの言動に対して説明できる必要がありますね。
計測するための指標をきちんと考えなければならない
進め方としては、いくつかの議論を経て、7人*4チームに分かれて課題を付箋に張り出す、という方法をとりました。その上で、付箋の枚数が多いものがクラス全体として大きな課題であるはずなので、できる限り多くの付箋を解決できるよう我々でディスカッションを行いつつ、適宜江端さんに助言を仰ごう、というような腹づもりでいたところでしたが、
- 実現可能な課題しか取り扱わないのか
- 課題は解決ではなく軽減される程度でよいものなのか
というような指摘を受けました。
それぞれがあいまいな基準で付箋に課題を書き出しているので、粒度は大小様々。さらに、「ProductOwnerに認定されたい」というような、そもそも解決しようがない課題はどう取り扱うのか。どういった基準で付箋に課題を書き出していったのかという指摘をいただきました。
結局のところ、計測できるということを実践できていなかった、ということですね。
交渉するにあたり、明確な優位性は何か
その後、指摘された点を踏まえて声が大きい人が中心となり案を出し、交渉によってクラスをまとめていく、という流れになっていきました。このとき江端さんが**案Aに対して案Bを出すならば、明確な優位性を示さないと誰も同意しないのでは？**という指摘をされていました。
いくつかの案から何かを決定するにあたり、割と雰囲気で良し悪しを決めてきたようなところがあったように思いますが、やはり案を評価する指標をもって論理的に決定していく必要があるのだと感じました。
HowではなくWhat/Whyを考えるべき
完全に個人の見解ですが、ProductOwnerとしてはHowよりWhat/Whyを考えて行動すべきだと思います。
例えば、今回のお題に対してAcceptanceCriteriaを書く練習をするという案が出ていたのですが、完全にHowの話をしているように感じました。大切なのは、具体的にどのようにするかではなく、その背景にあるWhat/Whyを考えるべき役割なのだと感じます。
AcceptanceCriteriaがうまく書けないからその練習をする、というようなニュアンスでこの案は出ていたのだと思いますが、この例であれば私たちはAcceptanceCriteriaの要素のうち何ができないのかであったり何故それができないのかといったところを考える必要があったのではないかと思います。
例えば、開発技術がわからないからAcceptanceCriteriaをうまく抽出できないのであれば、クラスでいくら練習したところで効果はありませんよね。
その結果出てきた課題に対して、トップダウン/ボトムアップの両面から改めて情報を精査して、その結果やっぱりAcceptanceCriteriaを書く練習をすることが良いということになればそれでよいですし、別の案に行き着くならばそれでよいのだと思います。
トレーニング中の自分の振る舞いを振り返る
トレーニング中の自分の振る舞いを振り返ると、クラス内で（リターンが少ないと感じる）議論をできるだけ早く終わらせるよう誘導するなど、ROIのうちIを下げることを特に意識して行動していたように思います。
ただ、それだけでは不十分で、そのように誘導するのであれば誰もがYESというであろう論拠を持って案を出すべきだし、そのためには課題に対する深堀や計測する基準をもっともっと考えられるようにならなければならないのだと感じました。
また、他者の議論について様子を見た上で収束させるように動いていましたが、これは後手の戦略だとも感じます。これを先手の戦略として行動できるようになると、より少ないInvestmentで高いReturnを得られるようになるように感じました。とはいえ、他者の議論の様子を伺うというInvestmentなくして収束させるというReturnを上げる能力は今の私にはないので、鍛錬が必要ですね…。
最後に
色々と書きましたが、これらを知識として知っているだけでは何の意味もないと思います。トレーニングで得た知識を自らの血肉として行動していかなければ、この研修を受講するという投資に対する価値は発揮できません。
ScrumやProductOwnerを務める/務めないに限らず、今回学んだ考え方をこれからの活動に活かしていけると、自分にとっても所属する組織にとっても良い影響を及ぼすことができるので、頑張らないといけませんね。