プロダクトオーナー兼EMとしての資質について考えてみた。
この記事は、Engineering Manager Advent Calendar 2018の1日目のエントリーです。
普段は、DMM.comのプラットフォーム事業本部というところでプロダクトオーナーとエンジニアをマネジメント・採用する立場をしております@i35_267です。
今回は、プロダクトオーナー兼EMとしての資質を自分の経験から自分なりにのべてみたいとおもいます。
■ Overview
ここでは、プロダクトオーナーとして普段行っている中で必要そうになる資質 = 能力について3つほど上げさせていただきます。
まず、プロダクトオーナーの責務とは何でしょうか。Scrum Guideから引用してみます。
プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組 織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ 1 人の人間である。プロダクトバ ックログの管理には、以下のようなものがある。
• プロダクトバックログアイテムを明確に表現する。
• ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
• 開発チームが行う作業の価値を最適化する。
そんな中で、今回は大事な点として今回以下の3つを上げていました。
- 抽象的なものを具現化する能力
- 開発プロセスを作る能力
- プロダクトの状態を数値データで見る能力
- メンバーが開発しやすい環境を作れる能力
ひとつずつ説明していきます。
1. 抽象的なものを具現化する能力
プロダクトオーナーとして一番大事な点は、上で引用した『ScrumGuide』からもわかるとおり『プロダクトバックログアイテム』の最適化です。
そして、そのプロダクトバックログアイテムを作るための能力とは何かを考えると抽象的なもの(=ストーリーベース)を具現化(プロダクトバックログアイテム)だと思います。
例えば、会員登録機能にSNS認証を加えたいといったざっくりといったストーリーがあったとして、それをプロダクトオーナーは徐々に抽象度をさげていきながら、認証用Back-end APIの作成、Front-endの作成、etc…
開発メンバーが作業できる範囲、Readyの定義が整うまで細かくプロダクトバックログアイテムへ落とし込まないといけません。なので、やはりエンジニアリングの能力が少なくとも必要になってくると思います。
意外にここの部分を開発メンバーにまるっと投げているケースが多いように見受けられます。特にエンジニア出身ではないと簡単なストーリーだけ決めてあとは丸投げといった形が多いと思いますが、個人的にはSBI(スプリントバックログアイテム)までは落とし込まなくとも、ストーリーからある程度の粒度までは落とし込み、SBIも何をしているか理解するまでは必要だと思います。
2. 開発プロセスを作る能力
こちらは、プロダクトバックログアイテムをいくら最適化しても、それを開発してリリースするまでのプロセス、リードタイムが長ければリリース回数が減り、Product Market Fitが遅くなります。
いわばプロダクトバックログアイテムは開発をはじめる準備 = アイテムなので良い開発プロセスを設計するのは、とても重要なことです。
スクラム定義をメンバーに浸透させるのはスクラムマスターですが、もうちょっと抽象度高くスクラムでは補えない部分をどうするかもプロダクトオーナーは意識しなければいけません。
始めから、理想の開発プロセスがある人はそのプロセスを適応してもよいですが、現状の開発プロセスを見直す手段も有効です。
見直すツールとして、『VSM(ValueStreamMapping)』があります。
VSMとは、アイディア(要求)から価値(バリュー)が出るまでの開発プロセスを可視化する手法です。以下は実例です。
このような図を開発からリリースに関わった人皆で書きます。
そして、『ここは意味がなさそうだからなくてもよいのではないか』『ここの工程とここの工程は一緒にできるのではないか』などを議論します。ポイントとしては、まずは改善方法を考えるのではなく、ムダを徹底的に見つけることです。
ちなみに一度、VSMを書きチームで議論することでリリースまでのリードタイムがこのくらい削減できます。
詳しい説明は、以下のスライドにありますので興味がある方はぜひご覧ください。
3. プロダクトの状態を数値データで見る能力
プロダクトを成長させるには、さまざまな数値およびデータを見ていかなければなりません。つまりデータ駆動に基づいてプロダクト戦略を立てるべきだと感じています。
まずは、プロダクト戦略を考える上で、なぜ『データ』というものが必要なのでしょうか？
逆に考えると、仮にデータに基づかない状態でプロダクトをGrowthさせる場合、頼るのは直感です。
もちろん、直感で仮説を決めて検証してもよいでしょう。ただし、その仮説を検証した後に効果があったかはデータがないとわからない部分が大きいです。
いずれにしても、データがあるということはプロダクトの状態を見ていく上で大きな根拠になります。
プロダクトオーナーとしては、最低限KPIツリーがあるならばそのツリーの数値(CTRやCVR,CV,etc…)が出せる簡単なSQL程度なら書けること。そして、コホート分析なりでユーザーの行動を常に追えていること。が必要になって来るかなと思います。
■ メンバーが開発しやすい環境を作れる能力
最後にプロダクトオーナーの話をしてきましたが、チーム内の環境について整備できることも重要でしょう。
ここでは、ひとつだけ必ず隔週で1on1をしましょう。そこで個人のキャリアとチームの方向性をきちんとすり合わせしましょう。はじめから目指している姿が固まっているメンバーは少ないです。そのためいかに1on1を通してコミュニケーションのなかで固めていけるかが大事です。
■ まとめ
以上がプロダクトオーナーとして必要になりそうな知識になります。
- 抽象的なものを具現化する能力
- 開発プロセスを作る能力
- プロダクトの状態を数値データで見る能力
- メンバーが開発しやすい環境を作れる能力
1~4の資質はどれも大事ですが、特に『1. 抽象的なものを具現化する能力』は必須かとおもいます。プロダクトオーナーの業務のほとんどはプロダクトバックログアイテムの管理です。
もちろん、プロダクトバックログを作るにあたって、『3. プロダクトの状態を数値データで見る能力』のようなデータを見て仮説を決めてそれをプロダクトバックログに落とし込み優先順位を決め、開発プロセスを設計して最速で仮説検証を繰り返すために複合的に1~3すべての能力が必要になるのかなと思います。
以上です。
