Scrum Masterの経験をもとにScrum Product Ownerを学んでみる
この記事はREADYFOR Advent Calendar 2020の15日目の記事です。
こんにちは、PdMチームに所属しているohataです。
READYFORにJOINしてからはや3ヶ月ほど経ちました。
今年自分の中で一番大きなインプットになった、Scrum Product Owner研修で学んだ知識と今までのScrum経験を振り返ってみようと思います。今回得た学びをプロダクトを進めていく上での一つのアプローチとして書いていこうと思います。ScrumXXXは以下の略称で表記していきます。
Scrum Master・・・SM
Scrum Product Owner・・・PO
Scrum経験の振り返り
READYFORにJOINする前はエンジニアマネージャー、SMとして新規プロダクト開発や既存サービスのグロースを行ってきました。様々なプロダクトに携わっているとスムーズに進んだプロジェクト、効率的に動けなかったプロジェクトというのも当然ありました。SMとして経験値が上がっても、Scrumでパフォーマンスが出ているのか？やり方がそもそも違うのでは？と自問自答して、夜まで眠れない事も多々ありました。(ちゃんと寝てるじゃん)
いろいろなプロジェクトの振り返りをまとめると、成功したプロジェクトは必ず以下の成果物がわかりやすく、見やすい状態で作られているという共通点がありました。
●インセプションデッキ
●ユーザーストーリー
インセプションデッキ
インセプションデッキについては Agile Samurai の解説、公開されている テンプレート がありますので、そちらを参照してもらえればと思います。ここではどんな時に有効だったかを書いていこうと思います。
議論で迷った時に立ち戻れる
Scrumを行うとプロダクト全体に対するアイデアや議論はチーム内でよく出てくるようになります。非常に良い事ですし、経験上そこから新しい機能が生まれた事もあります。一方で目指す方向は一緒でもアプローチが異なり議論がまとまらなくなる事もよくありました。その際に インセプションデッキ内のトレードオフスライダーや、エレベータピッチなどが非常に有効に機能しました。今はどっちが大事だっけ？ 今出すべき価値は？という問いかけをインセプションデッキを見直すことにより判断していく事ができました。
またポジティブな意見が出た時も今やるべきか？を再確認する際にとても助かりました。 (良い意見が出たらプロダクトバックログに追加しておきましょう)
POの助けになる
Scrum定義ではPOは50%は顧客(自社でいうと戦略や営業部署になる事が多い)と過ごすという定義があります。顧客の話を聞いている内にPOの考えが顧客要望に支配されてしまう事があります。(数字などの話が出てくると支配されやすい。。。) そんな時にインセプションデッキが共有されていれば、要望側に説明したりSH(ステークホルダー)への相談というアクションが取りやすくなります。
影響する範囲を見つけやすい
関係者が明確になるので、以下の事を早期に考慮しやすいです。
- システム的な影響範囲
- 早めに確認しておこなければいけない関係者や調整毎
上記が明確になる事により、見積もりの精度やブロッカーなどが洗い出されるようになり、バックログの優先度をつける際にも役立ってきます。
定義があると楽
経験値からインセプションデッキを作成しなくても、うまく進められるPOもいると思うのですが、全員がいつでも確認できる。確認しておかないといけない項目を見直せる。同じフォーマットでチームの理解が早い。など情報共有できる定義がある事は重要だと思いました。
ユーザーストーリー
実際にユーザーが行う作業をシミュレーションする事によって機能を洗い出したりしていきます。メリットはいくつかありますが特に自分がよかったと思った事をあげます。
- MVPの認識合わせをしやすい
- スコープやフェーズ、Backlog作成のイメージがしやすくなる
Scrum Product Ownerを取得しようと思ったきっかけ
インセプションデッキ -> ユーザーストーリーまでを効率的に行うにはどのようなプロセスを踏むのが良いかと考え、[守・離・破]の [守]を身につけようと思い Scrum Product Ownerを学ぶ事にしました
Scrum Product Owner研修で学んだ事
Whyはどのように決まっていくのか
Scrumには以下の定義があります
Product Owner は顧客50% チーム50%と過ごす
チームとしての過ごし方は、SMをやってきた経験上理解できるのですが、顧客50%の役割の中でどこまでやるのかが全然イメージつきませんでした。今までのPOの方はWhyから定義できる立場の人もいれば、事業戦略によってProduct内のOKRを決めていく人など様々だったからです。チーム内でのタスクやチームでの決め事はPO判断になるのは理解していますが、会社全体の事業戦略として決まっていくような場合に Productチームとしてどう関わるべきか？がイマイチ理解できていませんでした。
研修で学んだ事
結論的には事業レベルの話だともう少し別の役割が必要になってきそうです。以下の図がわかりやすいのですが、Product Managerという役割の人がいると良いとの事でした。
引用 (https://medium.com/@melissaperri/product-manager-vs-product-owner-57ff829aa74d)
ただPOはProductに責任を持っているので、Product Managerの戦略に対して、Product Ownerの見解を共有していくようにするそうです。実際にPOの見解から戦略の見直しがされた経験を持つ方が研修の参加者にいました。研修のグループでそういう経験談を聞けるだけでも研修は最高でした。
なかなか理屈はわかっていても、実務での話を聞けると腹落ち感が全然違います。
Productのフロー
全体フローとしては以下のような流れになります。
プロダクトビジョン
全体のプロダクト情報をまとめるものはインセプションデッキがおすすめです。ビジネスや収益などに影響するような場合は、リーンキャンパスがあるとインパクトがイメージしやすいので良いかなと思います。経験的にもインセプションデッキを作成する前にリーンキャンパスがあるとインセプションデッキがすごい作りやすい！と感じました。また何故やるのか？を決める際にSH（ステークホルダー）との話もスムーズにできる効果もあります。
以下のような視点で成果物を分けると良さそうです。
リーンキャンパス ・・・ ビジネス見解の概要
インセプションデッキ ・・・ プロジェクトを進める上での情報
作成するには検証データ(分析結果や現在の指標)などもあると定性的な視点、定量的な視点の両方をカバーできるので説明する際にも説得感はあると思います。メンバーが事業に関心があるほど数値で示すというのは方向性を合わせやすいので、Product Managerや実際の指標を持っているチームとすり合わせできるとProductの成果も確認しやすく良いと思います。
ペルソナ
カスタマージャーニーなどを元に利用ユーザーを定義して、この後のユーザーストーリーのイメージが沸きやすいようにします。できる限り具体的なイメージがあると良いです。
[ x ] 1日に2回以上ログインするユーザー
[○] 1日に2回以上ログインするユーザーで20代男性、営業職、趣味読書
研修ではもっと細かく定義した方が良いとの事でした。この辺は企画する上で大事な箇所だと思いますが、ユーザーストーリーは想定ができる範囲まででやってみようと思いました。粒度はやっていく中で徐々にブラッシュアップできれば良いのかなと思います。
ユーザーストーリーマッピング
例えば、ECサイトでユーザーストーリーを組んだ場合は以下のように表す事ができます。
作成例を示すためのものなので、機能については画面で見やすい範囲にしています。こちらはメンバーと一緒に作り上げていく事になります。話し合いの前に把握できているFeature、Epic、Storyを置いておくと議論に入りやすいと思います。
結構時間がかかるので、お菓子を用意しながら取り掛かるのがオススメ
・Feature
ユーザーのフローのような大枠を表します。全体フローなどから落とし込む時には連動する事が多いです。
・Epic
Featureを少し具体的にしたイメージです。
・Story
具体的にユーザーが使う機能やアクションを記載します。
リリースプランニング
ユーザーストーリーにあるStory全てに対して見積もりする事はこの段階ではやらないようにします。理由は通常のScrum見積もりと同じ概念です。
- 見積もりはブレるので、詳細に時間を出してもしょうがない
- 詳細が全部決まっている事はないので、見積もりはブレる
概算や見通しを立てる際には以下の手法を使って概算を出します。
見積もりには ストーリーポイント(SP)とビジネス価値 (BV)を利用していきます。
1. Epicに対して見積もりを行う SP / BV
まずはEpicに対して見積もりを行います。図ではフェボナッチ数列を利用していますが、最近ではTシャツサイズ (S/M/L/XL)で行うことも多いようです。見積もりは以下の観点で行います。
- 制作のSP
- ビジネス価値 (BV)
- 数字の出し方はSPと同じ考え方で算出すればOKです
- BV / SP でROIを求める
両方を検討する事によって優先順位の認識合わせをする事ができます。
2. 見積もりしやすいEpicを選ぶ
次にStoryがある程度明確になっているEpicを選びます。(商品の詳細が知りたい)
3. Storyの見積もりをする
Storyに対して見積もりを行います。
4. Ecpicを基準にして、相対的な数字を出す
今回の例で言うと以下のように計算していく事になります。
- [商品詳細の詳細が知りたい] のSP・・・ 17SP
- Epicの1SPあたり = 17 / 5 = 3.4
- 全EpicのSP = 44
- 全SP = 44 * 3.4 = 150SP
算出したSPはタスクレベルの見積もりでない事に注意してください。今までのプロダクトで 1Storyあたりどれくらいのタスクポイントがあったのかわかれば良いですが、わからない場合はもう少し詳細にStoryを立てていく必要がありそうです。
仮にチームのStoryに対するVelocityが[20]だとすると、今回のプロダクトを終えるには 8Sprintくらいかかる事になると思います。
バッファや不確定要素部分は一定のルールを決めて付与しておくと良さそうです。過去のプロダクトでの見積もり時と最終的なVelocityの差分なども考慮すると現実感が出てきそうです。
最後に
自分の経験と学んだ事を検討して記事を書いてみました。Scrumガイドもアップデートされているように、自分の中でも考えをアップデートしながらより良くしていきたいと思います。
Scrumに対するアプローチは様々ですが、Scrumの概念をプロダクト部署以外にも広めていかないと難しい所もあるので、Scrum導入される場合は概念を共有できる小チームから初めていくのが良いと思います。
明日はREADYFORのデザイナー@kyota さんです！ お楽しみに！