はじめに
この記事は NTTコムウェア Advent Calendar 2023 19日目の記事です。
NTTコムウェアの三浦です。
私のこれまでのキャリアは、レガシー系のシステム開発が中心でした。そんな私が今の部署への異動をきっかけにスクラム開発に触れ、その中でプロダクトオーナー業務を１年ほど経験しました。
サービスの企画をはじめて経験する中で、自分が苦労したこと・学んだことをこの記事を通して読者の皆様にお伝えできればと思います。
読んでほしい人
- スクラム開発をはじめたばかりの人・興味がある人
- プロダクトオーナー初心者（歴１年以内）
- プロダクトバックログアイテム（以下PBI）の優先順位付けがうまくいかない人
プロダクトオーナーとして実践していること
基本的にスクラムガイドで定義されている役割に沿った業務をこなしていますが、具体的に文字に起こしてみました。
定量分析
ここで離脱が多い・ここの数値が予想より伸びていないなど、定量データをもとにユーザの課題とその解決手段の仮説を立てる
定性分析
立てた仮説の検証をユーザインタビューを通じて実施。
（インタビュースクリプトの作り方などの話も含めると長くなるので割愛）
PBIの作成・並び替え（プロダクトの改善）
上述した定量分析・定性分析の結果を受けて、プロダクト価値向上のためPBIの追加・変更・優先順位の見直しを実施
ステークホルダー調整
現状の課題共有とプロダクトの方向性について共有
（平たく言うと、次に何をやるかの宣言）
開発調整
開発チームとのやりとり、デザイナーさんとのやりとりなど
悩み
私がうまくいかないと感じていたのは、ステークホルダー調整でした。
分析を通じてこんな声が挙がってる・だから次はこれをやるべきだ…と説明しても承認されず、挙句の果てに別のPBIを着手せざるを得ないという経験が少なくありませんでした。
プロジェクトの中でユーザの生の声を最も聞いてる自負もあったため、自分たちが分析を通して得られた結果がなぜ受け入れてもらえないのか非常に頭を悩ませました。
偏っていた視野
なぜステークホルダーを納得させられないのか考えたときに、自分の視野がユーザ側に偏ってることに気づきました。事業会社で働く身である以上、必ずKPIや事業目標という数字があり、その数字にどれだけリーチできるのか？という観点の説明が足りていなかったのです。ユーザの声を一番よく聞いている自分がこのプロダクトを成長させることができる！という自負が、逆に自分の視野を狭めていました。
数字で語ってみた
そこでステークホルダー調整をする際に、数字の話もインプットすることにしました。
具体的には以下のような感じです。
- この課題を解決すると、
- KPI（重要な業績評価の指標）のこの指標値が〇%伸びる見込みです
- MAU（月１回以上の利用があったユーザの数）が〇%改善する見込みです
- CVR（購入や申し込みなどに至った割合を示す数値）が〇%改善する見込みです
すると自分たちのPBIの価値を認識してもらい、すべて自分たちの思い通りにプロダクトを成長させることができました！
…という、いかにもありそうなサクセスストーリーにはなりませんでした。。
もちろんKPI達成も大事ですが、ROI（投資対効果）など気にすべき数字は他にもあり、自分たちが思い描いた通りになることは稀でした。
しかしながら、ステークホルダーとの対話内容が以前よりも府に落ちることが多くなりました。これはおそらく、自分がステークホルダーにより近い視野（KPIなどの数字）を持つことができたからだと思います。
逆に言えば、どのようにアプローチすればステークホルダーの承認を得ながらプロダクトを自分の思う方向に成長させることができるのかというヒントをこの経験から学ぶことができたと感じています。
学び
まとめると、自分がプロダクトオーナー業務を通じて得た学びは以下です。
- プロダクトオーナーは数字から課題を読み取り、解決策を言語化することが大事
- さらに、解決策を講じることでどうなるのか？を数字に落とし込む力が必要
- 常に広い視野を持って判断することが大切。偏った視野で判断すると、どこかで歪みが生まれる
終わりに
いかがでしたでしょうか。
慣れてる方にとっては当たり前のことかもしれませんが、実際に業務に取り組むと見失ってしまいがちだなと思ったことを改めて言語化してみました。
プロダクトオーナーは今後も継続予定なので、また機会があれば記事を執筆できればと思います。