この記事は2022年12月16日に開催されたQiita Night〜プロダクトマネジメント〜のLT資料をベースに書いています
はじめに
私が所属している株式会社ROUTE06（ルートシックス）では、プロダクトマネージャー（PdM）とは別に プロダクトオペレーションマネージャー（POM） という職種が存在します。
本来であれば、PdMが担うケースが多いであろう業務の一部をプロダクトオペレーション業務として位置づけ、POMが遂行するような体制をとっている形です。
本記事では、プロダクトオペレーション業務が具体的にどういった業務で、なぜPOMという個別の役割が担当しているのか、その背景も含め、紹介します。
プロダクト開発における体制を構築するうえで、参考になれば幸いです。
ROUTE06のエンタープライズ領域事業について
ROUTE06のプロダクトオペレーションについて語る前に、まずそもそも、ROUTE06がどういった事業を行なっているかに触れさせてください。
ROUTE06は主にエンタープライズ領域のクライアントに向けてソリューション提供を行なっています。
というと、「なるほど、受託開発か？？」と想像される方も多いかと思うのですが、ROUTE06はもっと大上段からクライアントの支援をさせていただいてます。
クライアントが抱えている事業課題を丁寧にヒアリングし、その課題に対する解決策はどうあるべきか、というところから一緒に考え、事業企画として練り上げてプロダクトに落とし込むところから携わります。
クライアントの要望を、何も考えずそのままプロダクト開発に反映することはまずありえませんし、むしろ、我々から理想の形を提案させていただくことがクライアントへの大きな提供価値の1つになっています。
また当然ながら、プロダクト開発すること自体が目的ではなく、プロダクトを通して顧客価値を提供すること、またその提供価値を最大化していくことが求められるため、グロースフェーズの品質を高めることはとても重要であると捉えています（ここについては詳しく後述します）。
プロジェクト推進の各フェーズとPOMが関わるフェーズ
私たちがクライアントとプロジェクトを推進していく際のフェーズを大まかに分けると、
①提案・要求整理フェーズ
②要件定義・デザインフェーズ
③設計・開発フェーズ
④グロースフェーズ
といった具合に分けられるかな、と思っています。
クライアントの要求を整理して、コンセプト設計や事業計画策定の支援などを行うフェーズから始まり、プロダクト開発に必要な要件定義・デザイン・詳細設計を進めて開発に着手。
初期開発が完了したらローンチし、その後、グロースフェーズでプロダクト改善を行なっていく、といった流れになります。
PdMはプロジェクト初期から参画し、プロダクトローンチにあたる③の完了まで関わります。
一方、POMは③から薄く関わり始め、④のグロースフェーズでPdMと入れ替わり、デザイナー・エンジニアと連携しながらプロジェクトを推進します。
つまり、PdMはプロダクトローンチまで、POMはプロダクトローンチしてから、という形でそれぞれプロジェクトに関わっていくわけですが、もちろんいきなりスパッと切り替えられるわけではないため、③から④のフェーズにかけてグラデーションをつけながら緩やかに移行していきます。
例えばPOMの場合、③の設計・開発フェーズ中に、PdMからドメイン知識やプロダクトについてインプットしてもらい、操作・運用マニュアルの作成や、プロダクトのテストを通して理解を深めていきます。
さらにその過程で、「ローンチにあたって必要なことが抜けていないか」「ローンチ後、クライアントがプロダクトを運営できるか、考慮不足はないか」といった視点を持ちレビューする、といったことも行います。
また、④のグロースフェーズの仕込みとして、ローンチ前に分析ダッシュボードの作成も行います。
ダッシュボード上で可視化する指標は、プロジェクトのドメイン領域によって変わるので一概には言えませんが、顧客の事業運営および現場を意識した指標を可視化する必要があります。
例えば、事業担当者が上長への事業報告のために使う指標、マーケティング担当者が日次で追うべき指標、プロダクト担当者が改善ポイントを把握するために顧客行動を把握するファネル、現場の担当者が日々の運用改善のために参考になりうる指標など、多角的な視点でダッシュボードを設計・作成します。
この業務は、ローンチ後に可能な限り早くデータに基づいた改善を回すためにとても重要な業務ではありますが、クライアントワークにおいて実践できているところは、まだまだ少ないのではないでしょうか。
プロダクトオペレーション業務を明確に定義する意図
さて。
というように、ROUTE06ではPdMとは別にPOMという役割を設け、プロダクトオペレーション業務を明確に定義して担当しています。
エンタープライズ領域のクライアントワークを推進していくうえで、スムーズなグロースフェーズの移行と、それを高い品質で継続していくことを実現するために、最適な解は何か？を考えた結果、この形となりました。
上のスライドにも書いてあるとおり、「ローンチさせること」と「グロースさせること」は求められる能力が異なります。
もちろん、双方の能力は関連し、補完し合うものもあるため、PdMがどちらも担うことが効率が良い部分もあるかと思います。
しかしながら、ことエンプラ領域のクライアントワークともなると、多様な関係者を巻き込んだ期待値調整、契約まわりのハンドリング、セキュリティやコンプラインスまわりの整備や認識合わせといった業務もPdMは担うことになり、ローンチさせるまでの労力は尋常ではありません。
そういった背景もあり、「ローンチさせること」と「グロースさせること」を明確に分けて役割を分担することで、それぞれを高い品質で実現させることを目指しています。
現状の体制が抱える課題感
POMが「グロースさせること」に注力したとしても、なおその領域は広いなと感じています。
ローンチしたとはいえ、プロダクトの改善は続きます。
追加したい機能は尽きませんし、運用してみて気づいた改善したい点も次々に出てきますので、それらに優先順位をつけ、限られたリソースの中で改善をまわしていかなければいけません。
また、プロダクト改善だけに注力できるわけではなく、サービス運用をしていくうえで困ったことがでてきたらクライアントのサポートが必要になってきますし、クライアントからだけではなく、プロダクトを利用しているエンドユーザーからの問い合わせも当然来ますので、その支援・対応も必要です。
さらに、ダッシュボードから拾える指標をもとに、分析・改善提案をしていくことも我々がクライアントに提供する価値の1つですので、それも疎かにはできません。
すべてをこなすには、ひとつの案件に対してPOMひとりのリソースをほぼすべて割く必要があります。
ですが、そのような体制では、ROUTE06を必要としていただけるクライアントが増えれば増えるほど、POMを増やさなければなりません。
また、ひとりで案件を担当することはリスクも高いですし、心理的な負担も大きいですよね。いつでも休みたいときに休めるようにしたいものです。
こういった課題を解決するために、1案件を1POMで担当するのではなくチームとして支援できるよう、Issue管理や定例の設計、ドキュメンテーションの工夫など進めており、ゆくゆくはさらに役割を細分化していきたいと考えています。
エンジニアだった私がPOMで活かせた経験とストレッチが必要だった経験
さてさて。
ここまでROUTE06におけるプロダクトオペレーションマネジメントについてお話させていただいたわけですが、最後にPOMとして私がどういった経験をさせてもらったか、について触れたいと思います。
先にも述べたとおり、POMとして携わった領域は広く、いろいろな経験をさせてもらっていますが、ざっくり分けると 「プロダクトマネジメント」「プロジェクト推進」「カスタマーサクセス対応」「データ分析」 といったところが大部分を占めているかな、と感じています。
私自身、元々はソフトウェアエンジニアとして8年ほどキャリアを積んでPdM→POMと転向しているのですが、ソフトウェアエンジニアだったときは何か特定の領域で特化していたわけではなく、広く浅くという感じで、ある種、器用貧乏的なところを感じていました。
しかしながら幸いにも、その器用貧乏的に積んできたソフトウェアエンジニアとしてのスキルが、ROUTE06におけるPOMという役割においてカッチリとハマっていた ように思います。
機能改善を伴うプロジェクト推進において、技術的な難易度やリスクが経験上わかるということは意思決定に大きく寄与しますし、データ分析をおこなう際の、プロダクトのデータ構造を把握してSQLを書き、必要なデータを抽出するという作業も、エンジニアとしてのスキルを十分に活かせた部分でした。
また、カスタマーサクセス対応においても、問い合わせいただいたときに「あれが原因じゃないか？」というアタリを、エンジニア目線でつけることができたり、必要に応じて自身でログを追うなどして早急な対処ができたりしたことは、そのままクライアントへの信頼獲得に繋がるという点でも、大きな武器だったように感じます。
逆に、例えばデータ分析まわりに関しては、どういった指標が見れるとプロダクト改善に役立てられるか、クライアントのポジティブな行動に繋がるか、次の事業計画立案の参考になるか、といった様々な視点を持ち、レポート設計に落とし込む、といったことはほぼ経験がなかったため、やりながら学んでいく必要が大きい部分でしたし、いまなお学んでいる最中といった感じです。
あと、エンジニアのときは、目の前にある課題をどうやって解くか、を考えていたことが多かった気がするのですが、POM（PdM）に転向したあとは、目の前にある課題に優先度をつけて今はやらない判断をする、ということにリソースを割くことが多く、全部やることはできない、というマインドを持つことが、とても難しかったように思います。
おわりに
プロダクトのローンチはゴールではありません。
ローンチしたあとも、運用を継続しながら改善のサイクルをまわし、クライアント/エンドユーザーへ価値を提供し続ける必要があります。
達成すべき目標こそあれど、それを達成すればまた新たな目標が生まれるので、そういった意味ではゴール自体がないのかもしれません。
だからこそ、いかに長期的に継続でき、かつスケールするような体制をつくれるか、 ということにかかってきます。
プロダクトオペレーションという役割を据え、その役割がチームとして機能し、ゆくゆくはさらに専門性を高めて細分化していくような体制を目指していけたらと思っています。
まだまだ道半ばですし、より良い方法もあると考えていて、日々模索している状況です。
ぜひ、社外の方々とも情報交換できたらと思うので、気軽にお声がけいただけるととても嬉しいですし、もっとPOMについて知りたい、ROUTE06について知りたい、というお声がけもお待ちしております