【イベントレポート】POの役割徹底解剖！フェーズ・領域の違いにおけるプロダクトオーナーの役割とは
こんにちは！グロービス技術広報です。
プロダクトマネジメントにおいて、ユーザーに価値を提供することはもちろん、社内オペレーションの設計、技術的負債の解消、基幹システムの構築に至るまで、様々な領域をカバーすることが求められます。これらすべてを一人のPMが担うのは現実的ではなく、分業体制が一般的です。しかし、分業によって連携不足が生じると、価値創出をしたくても技術的負債で進められなくなったり、オペレーション設計が甘く事業拡大に耐えられないなどの落とし穴にはまるリスクも生まれます。
そこで、リクルート、マネーフォワード、グロービスの3社より、toCプロダクト、マスタメンテナンス基盤、社内プロダクトと、担当されている領域が異なるプロダクトオーナー/プロダクトマネージャーの方々を登壇者としてお招きし、日々のプロダクトマネジメントの中で複数領域をどのように分担し、どのように進めているのか、リアルな取り組みをお話しいただくイベントを実施しました。
今回はそのイベントのパネルディスカッションの内容の一部をお届けします！
登壇者紹介
登壇者の担当領域について
久津：今日はいろんな領域を扱うPO・PMの方にお集まりいただいています。
領域というと以下の図にまとめているんですけれども、こちらは私が考えたものでどこか出典があるわけではないのですが、プロダクト開発に関わる領域として定義しています。
1番目はユーザーにバリューを届ける領域として、ここはPMとかPOとか想像しやすい領域かと思っています。例えばプロダクトをグロースさせるとか、あるいは新しい価値を探すディスカバリーですね。
2番目はそれを裏で支えるオペレーションの領域ですね。ここは業種だったりどういったプロダクトなのか、toBなのかtoCなのかで変わってくるところかなと思いますが、わかりやすいところでいうとカスタマーサポートだったり、あるいはプロダクトに何かしらコンテンツがある場合は入稿をする必要がありますので、その業務ですね。そういったオペレーションがあるものが2になります。
続いて3番目は少し広いんですけれども、例えばマルチプロダクトだったり他業界に跨っている場合です。マスタ基盤だったり決済基盤だったり、あと認証基盤もですね。そういった共通化するところだったりとか、あと技術的負債もここに入れています。
4番目はさらにその奥で、提供側の事業の根幹を担うものですね。例えば契約管理だったり請求・会計管理、要は我々のプロダクトで出来上がった売上を会計に繋げていく、裏の流れですね。
今日のメンバーがどのレイヤで仕事をしているかは図で示しています。
担当する領域での工夫について
久津：松岡さんは3の領域で、約30プロダクトが展開されている中で、マスタ共通化チームがあるとおっしゃっていましたね。立ち上がった経緯とか、どうやって作られたのか聞いてもいいですか？
松岡：私はマネーフォワードに入ってちょうど3年くらいなんですが、入社したときには担当しているチームとかは特になかったんですね。ここ数年で毎年プロダクトがリリースされてきていて、幸いお客様も1つのプロダクトだけでなく複数のプロダクトを併用いただく事例も増えてきています。
その中でお客様から、例えば僕が担当しているマスタの一つに「部門マスタ」という、会社の部門のマスタがあるんですけれども、同じ情報なのに複数のプロダクトに毎回メンテナンスしているというペインがあってですね、
これはもうかなり大きな課題だといったところで、2年半前に「ダブルメンテ撲滅プロジェクト」と社内で呼んでいるプロジェクトチームが立ち上がって、基盤サービスを作り上げていくといったところに初期から入り込んでいきました。それが2年半前ですかね。そういった経緯になってます。
久津：ありがとうございます。2年半前にやるぞ！ってなったきっかけとかありますか？
松岡：お客様からご意見いただくことが増えていたのと、これからリリースを控えるプロダクトも多くあったタイミングで、また負債を増やす選択肢はなかったのでチームが立ち上がった、というのは背景としてありますね。
久津：なるほど。ありがとうございます。
続いて1の立場にいる西村さんの話になるのですが、今の立場だとどんどんグロースするディスカバリーする、ガンガン進めるところだと思うんですけど、もともと3にもいらっしゃったので視野が広いとは思うんですが、3のレイヤの人とどうコミュニケーションしていますか？
西村：そうですね、「これからビジネスの企画やっていこうと思ってるんだよね」とか、「グロースしていこうと思ってるんだよね」という話が見えたときに、機能開発していこうと思ったら、「ちょっと待ってください、めっちゃ大変なんです、技術的負債めっちゃ多いんです」ってことはよくあります。
そこを事前に防がないとどうしてもビジネスの速度遅くなっちゃうので、エンジニアだったり、3の領域のロールのメンバーとコミュニケーションを密にとるようにしていて、これから半期先や1年先にどのユースケースにアプローチしていこうといしているのかという話を随時コミュニケーションの中で共有をし続けるとかは意識をしているところではありますね。
そこがないと、「急に来た！」みたいに思っちゃうことがどうしても起きちゃうので、事前に開発側から「そこちょっと厳しいんだよね」と負債解消のための工数を確保することの合意を取っていくことは工夫しています。
久津：ありがとうございます。
その流れで、西口さんも同じようにいろんなところからいろんな要望をもらう立場だと思うんですけど、受ける側として、来た要望をどういう順でやっていくかってどう決めているんですか？
西口：まず現場からは痛みとか困っていることっていう事象レベルで上がってくるんですね。例えば「お客様からよく問い合わせが来ています」とか。
別々の部署の方の要望だったりとか、データプロダクトからの要望もあるので、同じ軸で優先度比較して開発の順番を決めてあげないといけないので、そこをシステム課題にどう落とし込んでいくかにどう持っていこうか、例えば問い合わせの件数、時間をコストという軸に変えてそれで順番を決められるんで、どう落とし込んでいくか、実際何に困っているのか、の掘り下げをいろんな部署の人の観点に合わせながら落としていくって感じですかね。
久津：めっちゃいい話ですね、比較可能にしないといけない。
この4つのレイヤって同じ単位がないので、変換結構むずいんじゃないかなって思ってるんですけど、例えば問い合わせをコストに変換するときって愚直に計算するんですか？それとも肌感でやってるんですか？
西口：アバウトなところではあるんですけど、1件あたりの時間×n件、といった形ですね。厳密にやろうとするとそんなに効果はないので、スピード感持って順番を決めてあげるためにある程度アバウトにってところですね。
久津：ありがとうございます。
4つの領域それぞれで活躍されているPM/POがいる中で、いろんな役割だったり動き方があると思うんですけど、共通しているのはそこだけやっていればいいわけじゃなくて、全体を俯瞰して見るというところが大事だなということ。それとしっかりコミュニケーションを怠らないようにしないといけないこと。
すべての活動がプロダクトの価値・グロースに繋がっていくので、どこも無駄なことはない。それぞれの領域の担当者がどれだけ重なり合えるかというところが重要だなと、みなさんのお話を聞いて思いましたね。
以上の内容はディスカッションのごく一部で、まだまだおもしろい話がたくさんありました！
各社の事例で気になるところがあればぜひ各社のカジュアル面談などで質問してみてくださいね。
グロービスで一緒に働く仲間を募集しています！
日本発、世界をリードするEdTechカンパニーを目指すGLOBISでは、一緒に働けるエンジニアを探しています！ まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？
https://hrmos.co/pages/globis/jobs/gdd_pm_tko_t
いいなと思ったら応援しよう！
