見出し画像

マネーフォワードの事業開発PdMってどんな仕事?にお答えします!

こんにちは! マネーフォワードホームカンパニーの採用担当、萩原です。

今回は「マネーフォワードホームカンパニーの事業開発プロダクトマネージャー(以下PdM)ってどんな仕事なの?」と気になっている方にお伝えしたい……! そんな一心でこちらをしたためています。

マネーフォワードのPdMポジションに興味を持っていただいている皆さんの、解像度が高くなれば幸いです。

マネーフォワードホームカンパニーの事業開発部は、『マネーフォワード ME』といったtoC向けのプロダクトの新規事業立ち上げからグロースまでを担っています。

先日、事業開発部 部長の志賀が、日本中・世界中のカメラの映像をクラウド化した映像プラットフォームを提供しているセーフィー株式会社様の「社内向けPdM座談会」にお誘いいただき、マネーフォワードのPdM業務について赤裸々にお話ししました。これは、その内容をまとめた記事です。ぜひ最後までお読みください!

<新規事業開発に関して>

ーセーフィー吉田さん(以下:吉田さん、写真右)
早速ではありますが、まずは「新規事業開発」について教えてください。
志賀さんが、ゼロイチでサービスを立ち上げるときに大事にしていることはなんですか?

ーマネーフォワード志賀(以下:志賀、写真左)
はい、今までの経験からtoCプロダクトについての話になりますが、

  • プロダクト観点では「絶対あったほうが良い」と強く思えるプロダクトであること

  • ビジネス観点では、マネタイズエンジンをしっかり搭載していること

だと思います。

事業を立ち上げるときに、まず自分自身が「ファーストユーザーになりたい!」と思えることがとても重要なんです。
例えば、いい企画を思いついた場合でも、自分自身がそれを使うイメージを持てない場合は、早めにその企画はお蔵入りにして、別の案を考える方が絶対にいいですね。

また、売上もプロダクトの成功を示す重要なインジケーターの一つです。プロダクトの初期設計の時点で、マネタイズをどう組み込んでいくかを念頭に置くことも重要です。
マネタイズの仕組みを考慮していないサービスに対して、後からマネタイズエンジンを追加すると、プロダクトがどうしても歪むので、「このサービス単独での収益化は絶対にしない!」という強い意志がない場合には、初期設計から組み込んでおく必要があります。

ー吉田さん
会社の上層部からお題を与えられる、ということはよくあるケースですが、与えられたお題に対して、自分なりに企画に落とし込むときにはどんな行動をしてきましたか?

ー志賀
そうですね、お題があるときには、やりたいと言い出した人が「なぜそれをやりたいと思ったのか」をしっかりヒアリングしています。
お題は会社の上層部から下りてくることが多いので、自分では検討していなかったことや、知らない観点が見えてくることもあり、方向性を定めることができるんです。
一方で、ヒアリングした結果、どの観点から見ても納得できない場合にはやらないという選択肢も、もちろんあるべきです。

ー吉田さん
なるほど。ちなみに、グロースのタイミングで気をつけているポイントはなんでしょうか。

 ー志賀

  • ユーザーの反応を見て素早く執着を捨てること

  • ユーザーの反応に引きずられすぎずに戦略案件を進めていくこと

の二つです。

まず「ユーザーの反応を見て素早く執着を捨てること」に関してお話しします。
サービスをグロースさせていくときには、仮説を持って機能開発をしますが、100%その仮説が正しい、ということはありません。
ガチガチにロジックを立てても、一定のユーザーにはいい反応を得られるものの、大半には受け入れられない、ということもありますよね。
手塩にかけてリリースするので、こだわりは大切なのですが、なるべく早い段階で自分で覚悟を決めて、時にはストップしたり、方向転換していく、ということが必要だなと思います。

次に「ユーザーの反応に引きずられすぎずに戦略案件を進めていくこと」に関してです。あらゆる機能開発は達成したいプロダクトビジョンを叶えるためのパーツであり、現時点での開発はそのロードマップの一番手前のものだと考えています。
したがって、多少反応が悪かったとしてもそれ自体がプロダクトビジョンに必要なのであれば軸をブラさず推進することが必要だと考えています。
当然、ユーザーの反応が悪すぎたり、数値に悪影響が出すぎたりしてしまった場合には、立てた戦略、仮説自体が間違っている可能性も大いにあるのでそこは慎重に判断する必要はあります。
そうならないようにリリース後の反応はしっかりチェックしていきながらロードマップを進めていくことが大事ですね。

ー吉田さん
深いですね……勉強になります。ちなみに、戦略的撤退の場合、早いときでどのくらいで意思決定するのでしょうか?

ー志賀
早いときで3か月くらいだと思います。クローズするか、機能を大きく改変するかの2択になりますね。

<プロダクトロードマップに関して>

ー吉田さん
次は、プロダクトロードマップに関しての質問ですが、志賀さんが管轄するプロダクトの場合は、どのくらい先まで、また誰がプロダクトロードマップをつくっているのでしょうか。

ー志賀
マネージャーとして、リソースの配分や部員の育成という観点で考えると、1年だけではなく、期をまたいで次の半年ぐらいまでを見据えてロードマップを描くとより良いと考えています。
一方で各PdMには、1年のスパンでユーザーにどうなっていてほしいという絵を描いてほしいとオーダーしています。

誰が作る、という観点ですが、プロダクト単位のロードマップはプロダクトのPdMにお願いしています。個別のプロダクトを超えるような戦略であったり、目標とすべきKPIの大まかな形、設計する上でのフレームワークは渡すものの、どう形にしていくかはPdMを信頼して任せていますね。

チームを横断した開発の優先順位は、僕の方で論理的に検討して進めています。
開発リソースを共有しあい、健全な競争関係をPdM間でつくりつつ、互いに切磋琢磨できるチームができていると思います。

<PdM組織に関して>

ー吉田さん
新規事業開発に関して、とても勉強になりました! ありがとうございます。
続いて組織運営に関しての質問させてください。
PdM育成のために具体的にやっている取り組みがあれば、教えていただけますでしょうか?

ー志賀
PdMの育成って本当に難しくて、これを勉強しておけばすぐに役立つ、みたいなことはなかったと思います。
なので、現場での経験値を最大化することが最も効果的なのではないかと考えました。
そこで意識しているのが、ひとつのプロダクトに一人のPdMではなく、コンビでのチームアップです。

ひとりPdMは、すごく孤独な仕事です。
そこにもう一名担当をつけることで孤独感は減らせるし、それ以上に2人でひとつのことを見ることはとてもいいと思っています。
経験や得意分野が違うメンバー同士で仕事をしながら、自分になかった点を補填しあえるので、日々学びにもなるはずです。
そうなるように、コンビの相性はお互い補完しあえるスキルセットで組むように意識しています。

ー吉田さん
横のつながりで学びあえるのは重要です。コンビだと壁打ち相手がいることで思考の迷路からも抜けられるので、職種を問わずコンビで動くのはいいですね。心配していることを相談できるだけでも嬉しいですし。

少し話がそれるのですが、メンバーに次の機会を渡すタイミングやきっかけはどのように決断していますか?

ー志賀
事業開発部は新規事業の部署なので、常に新しいプロダクトの立案を奨励しています。いつでもかかってこい、という状況なんです。なので提案タイミングはメンバーにゆだねています。
しかし、それをGOするかは、そのメンバーの今のスキルによるところもあるので、常に各メンバーにどんな仕事が任せられるか? は検討をしています。

ー吉田さん
部門をまたいで、PdM同士の連携のために何かやっていることはありますか?

ー志賀
やってよかったのは、ロードマップ共有会ですね。
自分のプロダクトでやろうとしていることを、お互いに発表しあう会です。
良い点だけではなく、失敗事例を共有することで、勉強になるなと思っています。

ー吉田さん
弊社も社内でのリクエストが多いので、事例の共有はやっています。
PdM組織を横断してよもやま会なんていうのもやっていますよ。

ー志賀
いいですね! そういうの大事ですよね。

ー吉田さん
とても大事です!
今日は事業開発やPdM組織に関して、細かくお話しいただき、ありがとうございました。とても勉強になりました!

<さいごに>

さて皆さんいかがでしたでしょうか。
事業開発部がいつもどんな事を大事に仕事をしているのか、組織づくりをどうやっているのか、少しでもイメージしていただけていると嬉しいです。

マネーフォワードホームカンパニーでは、一緒に働く仲間を募集しています!
このnoteを通して、少しでもご興味をもってくださった方はぜひご応募ください。

【事業開発PdMへのご応募はこちら】

【カジュアル面談エントリーはこちら】

セーフィーさんのPdM座談会に関するnoteはこちら


この記事が気に入ったらサポートをしてみませんか?