PMとGLを両方担う僕の葛藤を誰か一緒に解決してくださいw

こんにちは！ 『マネーフォワード クラウド勤怠（以下『クラウド勤怠』）』のプロダクトマネージャー（以下PM）とグループリーダー（以下GL）を務めている上田です。2018年に新卒でマネーフォワードに入社して、もうすぐ社会人歴4年目に突入します。社内では「ぴょんす」と呼ばれていますので「ぴょんす」と覚えてください！

今回はPMとGLの両方を担う僕が意思決定をするときの葛藤について執筆します。同じような境遇で迷われている方がもしいましたら、一緒にこの問題の解決策や自分ならどうするかといったアイデアをいただけると嬉しいです。

PMとGLという両極端の立ち位置をまずは知ってほしい

まずは言葉の定義を簡単に整えようと思います。

PM：プロダクトマネージャー
エンジニアと共に自分が担当しているプロダクト（僕の場合は『クラウド勤怠』）の開発を中心となって進める役割。ユーザーのニーズ調査や要求/要件の定義づけ、エンジニアや他部署と密に連携を取る。
担当プロダクトの機能をスケジュール通りリリースすることや、プロダクトの品質を担保することが求められる。

GL：グループリーダー
担当しているプロダクト開発グループ（僕の場合は『クラウド勤怠グループ』）のメンバー評価やモチベーション管理及び、チーム開発がより良くなるようにマネジメントを行う。また、マネーフォワードのHR領域では複数のHR領域プロダクトを展開しているため、他グループとの開発リソースの調整や将来のHR開発の組織体制なども考える。HR開発として将来的なメリットも含めて全体最適な判断をすることが求められる。

言葉の定義は色々ありますが、今回の話をわかりやすくするために、簡易的に整えています。もちろんPMが評価やチームマネジメントをする開発チームもあると思いますし、将来的な開発組織体制をPMが考えるようなチームもあると思います。

つまり、PMとGLは実は似ているのでは…？と最初僕も思っていました。
しかし、この似ているはずの役割で真逆の決断を迫られることがありました。

矛盾した選択を迫られる瞬間

マネーフォワードのHR領域では、複数のプロダクトを開発しています。以前、別の開発グループから「少し大きめの開発をやりたいので、クラウド勤怠グループから開発リソースを借りたい」と依頼を受けました。

PMの僕：『クラウド勤怠』としても開発スピードを上げたいから、他グループに開発リソースを渡しても大丈夫なのか。他グループに開発リソースを渡すと、既にスケジューリングされている開発計画を練り直さないといけないし、1エンジニアが担当する保守メンテのコスト（ユーザーからのお問い合わせ調査等）も増えるので、クラウド勤怠グループの開発リソースは渡したくない。

GLの僕：他グループに開発リソースを一時的に寄せて、機能開発をすることによってMRR（Monthly Recurring Revenueの略。毎月繰り返し得られる収益）やARR（Annual Recurring Revenueの略。毎年決まって得られる収益）に今後どれだけ影響してくるのか。リソースを寄せないことによって他プロダクトのリリースが遅れた場合、どれくらい影響があるのか（極端な例だと事業が1つ潰れるということであればリソース調整するしか無い。）など将来的観点を含めると、クラウド勤怠グループからリソースを他グループに渡す方が、将来的にユーザーにとってもメリットが大きいのでは？という判断に至りました。

どうやって意思決定している？

身も蓋もない回答になってしまいますが、僕が経験したような状況ではこれが正解！という答えは無いと思います。
しかし、どうするか、という意思決定は必要になります。その際には「どちらの意思決定のほうがより多くのユーザーに価値を届けることができるか」ということを軸に意思決定をしています。

マネーフォワードのValueの中に「User Forcus」という行動指針があります。
User Forcus：私たちは、いかなる制約があったとしても、常にユーザーを見つめ続け、本質的な課題を理解し、ユーザーの想像を超えたソリューションを提供します。

この指針は決して「既にサービスを利用中のユーザー」だけに絞っているわけではありません。既にマネーフォワードのサービスを導入していただいているユーザーにフォーカスするのは当たり前で、将来導入していただくユーザーにどういった価値を届けることができるのかというところまで考えた上で意思決定をするようにしています。
なので既にご利用いただいているユーザーからすると、一時的に『クラウド勤怠』の開発スピードは遅くなっているように見えるかも知れませんが、最終的にマネーフォワード クラウドのHR領域全体で、ユーザへの提供価値を最大化するために必要な判断をしています。

サービスを提供するということは、ビジネスなので、売上が上がる選択、新規MRRのstockが積める選択をする、という考え方も正解だと思います。
その売上があるからこそ更に開発を進めることができ、長期的にユーザーに価値を届けることができるという考え方もあります。

さいごに

サービスの開発状況、開発エンジニアの人数、他プロダクトとの関係性、プロダクトのフェーズ、利用ユーザー数、売上等考えれば考えるほど意思決定に必要な要素はたくさんあります。
その中で、PMの方だけに限らずこの記事を読んでくださっている読者の方は、何か意思決定をする際にどういった要素を優先して意思決定をしていますか？