プロダクト開発の役割分担

プロダクト開発は関係者が多く、プロダクトマネージャー (PdM) の仕事の複雑性が高い。

役割といえば、プロダクトマネジメントトライアングル¹が引き合いに出されるが、非常に複雑で実戦には不向きだと思ってます。PdMの採用要件を社内ですり合わせるためには役に立つかも知れませんが、プロダクト開発の役割分担やPdMの責務を定義するには使いづらいと感じてます。

流動的でチーム状況により変化もあるため、もっと雑に、もっと単純化した方が良いと思い、「顧客とシステム」「具体と抽象」で分類してみました。

受託型のソフトウェア開発の役割分担

まずは、複雑性の少ない受託開発のプロジェクトを想定して整理してみるとこの分担が良いと思います。

アカウントマネージャー（営業）の役割

• 顧客と契約で揉めたら怒られる人
• 契約交渉、契約管理、請求や入金管理
  • 請求や入金については経理・財務が支援してくれるケースが普通ですが、責任はアカウントマネージャー（営業）にあります
• 要望をすくい上げ、顧客の要求を明確にする

CSディレクターの役割

四象限上の名前を合わせるために、一般的な呼称ではない「CSディレクター」としています（適切な名称が思い付きませんでした）。コールセンター等で一般的に使われる役割のスーパーバイザー (SV) と概ね同義です。

• 顧客がシステム使い方で困っていたら怒られる人
• マニュアルやFAQの作成・更新
• 受入テストやシステム導入支援

プロジェクトマネージャー (PM) の役割

• 全体の仕事進行がグダグダになったら怒られる人
• 社内外のすべてのタスク管理や進行支援
• 顧客の要求をもとに製品仕様を決める
• 製品の品質と納品スケジュールコントロール

システムディレクターの役割

• システム関連の文書が陳腐化したら怒られる人
• PMのシステム関連タスクの支援
• 要件定義や仕様書などの品質管理
• 単体テスト、結合テスト

プロダクト開発の役割分担

一般化して拡張するとプロダクト開発に登場する人物の役割分担は下記のイメージになります。

プロジェクトマネージャー (PM) とプロダクトマネージャー (PdM) は、どちらも「抽象 x システム」に分類されており違いが分かりづらいのが難点ではある。

プロジェクトマネージャー (PM) は、「いつまでに作るか (When)」「どうやって作るか (How)」に関心があり、プロダクトマネージャー (PdM) は、「なぜ作るのか (Why)」「何を作るか (What)」に関心がある人という違いがある。これは、不確実性の高いプロジェクト（事業系）と不確実性の低いプロジェクト（受託系）により、さじ加減が変わる。

事業系であればユーザーが欲しいものを言ってくれないので作るべきプロダクトを間違える可能性がある。一方で、受託系であれば顧客が要望してくれるので作るべきプロダクトを間違える確率が下がる。と言う訳で、PMとPdMをかき分けて記載しています。

プロダクトマーケティングマネージャー (PMM) は利用者（ユーザー、顧客）の接点を担う人になります。製品を使ってもらう前に、顧客に製品価値を伝える必要があるため、具体ではなく抽象としています。広告媒体・ツールの運用やマーケティングメッセージを考えるから『具体』ではなく、顧客の立場に立ち具体的に見て触って実感できるか否かを基準に分類しています。この定義では、セールスやカスタマーサクセス (CS) に近い役割と捉えています。

toBサービスの場合、規模（契約顧客数や製品の機能数）が多くなったら手が回らなくなるので、プロダクトマーケティングマネージャー (PMM) やカスタマーサクセスマネージャー (CSM) を配置すると良い。あまり初期から配置するとコミュニケーションコスト（情報伝達や合意）がかかる。

役割毎のアウトプット

「責任」という言葉は案外一人歩きされやすく、実はチーム内で認識が一致していないことがあります。責任は、アウトプット（目に見えて、触ってわかるもの）として明記すると良いです。一番のアウトプットは実際に動いているプロダクトになるので、ここを曖昧にするとエンジニアにあらゆる責任が雪崩れ込みます。

「何を作るのか？」「なぜ作るのか？」が明記されている製品要求仕様書 (PRD) はプロダクトマネージャー (PdM) の仕事になります。いわゆる仮説検証（ユーザーストーリー）もPdM の仕事です。市場やユーザーに関する分析が含まれる市場要求仕様書 (MRD) はプロダクトマーケティングマネージャー (PMM) の仕事です。

小さなチームだと、システムディレクターの役割をエンジニアが担っていることもあるかと思います。手が回らなくて必要なシステムの設計資料が整備できていないこともしばしば。PRDとMRDはまとめてプロダクトマネージャー (PdM) が担っているかも知れません。

まとめ

プロダクト開発を進める際にチームメンバーの役割分担を「顧客とシステム」「具体と抽象」の四象限で分類すると概ねすっきりするのではないかと思います。プロダクトマネジメントトライアングルは良く整理されたフレームですが、残念ながらそらで言える人はあまりいないと思います。ホワイトボードにサッと書いてチームでお互いの役割分担を確認すり合わせするのは向いていないと思います。

いろいろ足りない箇所もありますが、実用的なフレームとして使うなら「顧客とシステム」「具体と抽象」で分類してみると良いと思います。