RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

戦略の舞台裏: プロダクトにおけるPdMとPMMの連携

皆さん、こんにちは!もしくはこんばんは! 楽楽精算プロダクトマネージャーのwekkyyyyです。

前回は「PBIの優先度設定方法のポイントと設定することの狙い」というタイトルで記事をかかせていただきました。

tech-blog.rakus.co.jp

今回は、PdMとPMMの役割分担・連携というテーマでブログを記載します。

目次は以下となります。

対象読者

以下のような方に読んでもらえると有益になると考えております。

  • PdMっぽい人とPMMっぽい人がいるけど、実際何をしたらいいかまったくわからない
  • PdMとPMMって役割は分かれてるけど業務にカニばりがある
  • PdMとPMMの協業は、うまくいってるけど型化、横展開はできてない

前提

  1. 基本的に筆者はPdMを以下の役割と捉えています。
    1. プロダクトの成長のために穴を埋める人
  2. 今のラクス(楽楽精算)での分担です。
    1. 各会社、プロダクトによって分担内容は変わります。

背景

PdM組織が立ちあがるまでは、以下の図のように事業サイドのPMMがPdMの役割を兼務していた状態でした。

しかし、事業サイドのカバー範囲が広くなっており、 必要時間・得意領域の不一致により質の確保が難しいリスクを抱えている状態でした。

そのため、以下のように開発サイドにPdM組織が立ち上がり、役割分担をすることで質・量ともに(優先度としては質)あげていくことを組織として決断しております。

基本方針

PdM/PMMメンバーのリソース・スキルセットを鑑みて決定する。

ということを基本方針として決めております。

決定方法

「DACI」というフレームワークを使用して決定しました。

DACIとは、「Driver(推進者), Accountable(責任者), Consulted (相談先), Informed (報告先)」の頭文字をとったものです。

このDACIの役割を「Output」「工程」と紐づけて割り当てていきました。   ※割り当て内容は、PdM/PMM協議の上決定しております。

D: Driver (推進者)
 特定のタスクを推進し、実行に責任を持ちます。

A: Accountable (責任者)
 最終的な意思決定者または承認者となり、タスクの成功に責任を負います。

C: Consulted (相談先)
 Driver (推進者)から、必要な追加情報や詳細についての相談・実行を受ける人またはチームを指します。

I: Informed (報告先)
 進捗や、決定内容について、報告・共有を受ける人を指します。

決定内容(一部分)

以下画像にて、決定内容の一部分を公開いたします。

より詳細な内容は、言える範囲でカジュアル面談・選考で会話させていただけるとありがたいです。

基本的には、 PRDを作成するための必要要素については、マーケット情報の収集をPMM、その他をPdMが「D」としています。

その他、GoToMarketに関わる部分は、PMMを「D」にしています。

(やってみて)メリデメ

  • メリット
    • PdM/PMMそれぞれの得意領域に専念できるようになった
      • 得意な人のOutputから、それ以外の人も学習の機会を持てるようになった
      • 業務効率もアップした
      • 後続作業の担当者からの質問事項が、より深い領域のものになった(組織としてのクオリティアップ)
    • ジョブディスクリプションが明確になった
      • 採用において、社内やエージェントの方など共通言語ができ相互理解に寄与した
  • デメリット
    • (世の中に稀にいる)事業の成長に対して、なんでも穴を埋められるPdMキャリアを歩むことは難しい
      • 筆者は、なんでも自分ひとりで行う必要はないと考えているが、一定目指したい方はいると想定

ラクスのPdMとして活躍してみませんか?

楽楽精算PdMは、引き続き人材を募集しております。 是非カジュアル面談からお申し込みいただけると幸いです。

career-recruit.rakus.co.jp

Copyright © RAKUS Co., Ltd. All rights reserved.