Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AI時代にPdMとPMMはどう連携すべきか / PdM–PMM-collaboration-i...

Avatar for Rakus_Dev Rakus_Dev
September 01, 2025

AI時代にPdMとPMMはどう連携すべきか / PdM–PMM-collaboration-in-AI-era

◆イベント名
マルチプロダクトで20年以上SaaS提供をするラクスに学ぶ、AI時代にPdMとPMMはどう連携すべき
https://flexy.connpass.com/event/364939/

◆発表タイトル
AI時代にPdMとPMMはどう連携すべきか

◆登壇者
株式会社ラクス プロダクト部 製品管理課
稲垣 剛之 (@ingktks7)  
紀井 美里 (@keeeey_M)

Avatar for Rakus_Dev

Rakus_Dev

September 01, 2025
Tweet

More Decks by Rakus_Dev

Other Decks in Technology

Transcript

  1. 大手独立系 SIer企業 (担当 WEBサービス) ・バックエンドWEBエンジニア ・システムエンジニア ・プロジェクトマネージャー ISP系サービス企業 (担当 BtoB事業)

    ・プリセールス ・製品開発責任者(バックエンド開発) 上場系中堅ベンチャー企業 (担当 ブログ、ECサービス) ・バックエンドWEBエンジニア ・WEBディレクター ・エンジニアリングマネージャー ベンチャー企業 (担当 ファッションECサービス) ・エンジニアリングマネージャー ・製品開発責任者(企画・開発デザイン) ・取締役(製品・コーポレート) グローバルパブリッククラウド企業 (担当 API・AI・モバイル関連20サービス) ・技術サポートエンジニアマネージャー SaaS企業[現職] (担当 バックオフィスSaaS) ・プロダクトマネージャー プロジェクト マネージャー バックグラウンド バックエンド エンジニア エンジニアリグ マネージャー プロダクト マネージャー 略歴 稲垣 剛之(いながき たけし)    @ingktks7 2021年8月入社 株式会社 ラクス 開発本部 東京開発統括部   プロダクト部 副部長 / 製品管理課 課長 自己紹介
  2. バックオフィスDX製品(楽楽シリーズ) サービス名 提供開始 ARR 主な利用部門 提供機能 販売管理業務システム 「楽楽販売」 2008年 55億円

    複数のスタッフでデータや情報共有が必要 なさまざまな部門 ・販売管理 ・請求管理 ・稟議申請管理  etc 経費精算システム 「楽楽精算」 2009年 173億円 交通費精算や経費精算の申請や支払手続 を行う営業や経理部門 ・交通費精算 ・経費・出張精算 WEB帳票発行システム 「楽楽明細」 2013年 99億円 請求書、支払明細(支払通知、支払案内)と いった帳票を扱う営業や経理部門 各帳票 × 発送方法を自動で割り振り、 印刷・封入・発送を作業ゼロにします ・帳票:請求書、納品書、支払明細 ・発送方法:WEB、メール添付、郵送、FAX 勤怠管理システム 「楽楽勤怠」 2021年 14億円 打刻や休暇申請を行う全従業員と勤怠の 締めを行う総務人事部門 ・打刻機能 ・打刻修正、休暇、残業などの申請 ・休暇管理 電子帳簿保存システム 「楽楽電子保存」 2023年 非開示 請求書、支払明細(支払通知、支払案内)と いった帳票を扱う営業や経理部門 ・「楽楽明細」で受け取った請求書の保存/一元管理 ・電子帳簿保存法の法要件を満たす長期保存 請求書受領システム 「楽楽請求」 2024年 非開示 請求書を受領、支払い、会計処理、保存を 行う営業や経理部門 ・請求書受領 ・社内申請承認 ・経理による支払い処理、会計処理 最新は2025年7月~ 「楽楽債権管理」を販売開始
  3. メール系製品の紹介(ラクスシリーズ) サービス名 提供開始 ARR 主な利用部門 提供機能 メール共有・管理システム 「メールディーラー」 2001年 36億円

    複数名のスタッフでメール対応をしている カスタマーサポート部門 ・問合せメールの返信状況管理 ・顧客との対応履歴管理 メルマガ配信システム 「配配メール」 2007年 31億円 見込客や顧客にメルマガを配信している営 業やマーケティング部門 ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング メルマガ配信システム 「ブラストメール」 ※(株)ラクスライトクラウド提供 2007年 ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング システム連携特化型 メール配信システム 「ブラストエンジン」 ※(株)ラクスライトクラウド提供 2021年 メール配信機能との連携が必要なシステム 開発・IT部門 ・メール配信API ・SMTPリレー
  4. 【ラクス】組織全体 管理部門 事業部門 楽楽シリーズ部門 開発部門 ラクスシリーズ部門 各商材組織 各商材組織 各商材組織 横断組織

    【機能別組織】 営業、CS マーケ、製品企画 【機能別組織】 経営管理:総務、人事、経理、法務等 技術本部:情シス 【機能別組織】 営業、CS マーケ、製品企画
  5. 【PdM】開発部門 東京開発部門 プロダクト部 楽楽明細開発部 大阪開発部門 楽楽販売開発部 他各商材開発部 横断開発部門 インフラ開発部 開発管理・

    AI開発等部門 各商材の開発組織は約10名~50名程度 楽楽精算開発部 QA課 各商材 PdM・QA・フロントエンドの 関わり方は商材によって 異なる(部内にいる場合もあり) PdM組織 プロダクトデザイン課 楽楽勤怠開発部
  6. 14 Agenda ❏ Speaker紹介 ❏ セッション - PdMを取り巻く過去と現在 - PdM-PMM連携の現在

    - AI時代にPdMとPMMはどのように連携すべきか ❏ 質疑応答 ❏ アンケート記入
  7. 17 【ラクス】組織全体 管理部門 事業部門 楽楽シリーズ部門 開発部門 ラクスシリーズ部門 各商材組織 各商材組織 各商材組織

    横断組織 【機能別組織】 営業、CS マーケ、製品企画 【機能別組織】 経営管理:総務、人事、経理、法務等 技術本部:情シス 【機能別組織】 営業、CS マーケ、製品企画 PdMの所属 組織 PMM所属 組織
  8. 18 【PdM】開発部門 東京開発部門 プロダクト部 楽楽明細開発部 大阪開発部門 楽楽販売開発部 他各商材開発部 横断開発部門 インフラ開発部

    開発管理・ AI開発等部門 各商材の開発組織は約10名~50名程度 楽楽精算開発部 QA課 各商材 PdM・QA・フロントエンドの 関わり方は商材によって 異なる(部内にいる場合もあり) PdM組織 プロダクトデザイン課 楽楽勤怠開発部 楽楽明細開発部で 楽楽電子保存の 開発も担当 開発組織 デザイナーと 同一組織に所属 12名
  9. 開発部門 事業部門 20 【ラクス】PdM-PMM体制 [楽楽精算編] 20 プロダクト戦略 PMM エンジニア (PJM含む)

    デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA PdMと同組織 結合テスト以降や 技術サポート部隊
  10. 21 【ラクス】役割分担 [楽楽精算編] 21 「プロダクトマネジメントのすべて」より Core Why What How 製品要求仕様

    (PRD) 市場要求仕様 (MRD) 最終OutPut STP/ペルソナ ペインゲイン カスタマー ジャーニー コスト構造 収益モデル プロダクト指標 ロードマップ UI/設計/実装 GTM ミッション ビジョン 事業戦略 市場分析 競合分析 Discovery Delivery PdM PMM PMM PdM PMM PdM
  11. 22 製品管理課(PdM) Mission/Vision ▪Mission ・ビジネス、エンジニアリングの架け橋となりカスタマーサクセスに導く、売れる製品を実現する ▪Vision ・テクノロジー・UIで最高のUXを製品にもたらし続ける •PdM活動領域 PdMの活動すべき領域であり これら全てを健全に機能させる責任追っている

    A:お客様-開発者 └ これによって生み出されるのが「UX」である B:お客様-ビジネス └ これによって「利益」が生み出される C:開発者-ビジネス └ これによって「製品に価値」が届けられる ※バリュー・プロポジション = 製品の提供する価値を伝える A The Product Management Triangle       Posted by Dan Schmidt ,Product Logic   ※ラクスの製品管理課向けにカスタマイズ C B
  12. 23 製品管理課 担当製品 23 製品 どんな製品? 経費精算 請求書・納品書 WEB、メール・郵送自動発行 電子帳票

    受取・保存・管理 入金照合・消込 仕分け作成 誰に? 経理、従業員 (50名~4,999名 企業) 営業事務等 (請求書を発行する全ての企業) バックオフィス関係者 (電子データを管理したい企業、 楽楽明細の請求書受取企業) 経理 いつから? 2009年 (15年以上) 2013年 (10年以上) 2023年 (3年未満) 2025年 (1年未満) 規模・売上? 約1.9万社以上 ARR 173億円 導入数シェア:36% 約1.3万社以上 ARR 99億円 導入数シェア:46% 非開示 これから 非開示 これから 今後は? TAM:2,521億円 年成長率:+20% TAM:1.6兆円 年成長率 +46% 非開示これから 非開示これから 一言 マーケットリーダー 市場を牽引 成長領域 マーケットリーダへ これからの成長及び 各製品のハブとなる製品 新領域へ拡大 楽楽シリーズ主力製品と新規製品の合計4を担当
  13. 24 【ラクス】開発プロセスでの役割分担 [楽楽精算編] 工程 主担当 開発組織 他連携組織 製品ロードマップ PdM PMM

    各開発項目決定 PdM(エンジニア) PMM 要求仕様策定 PdM(エンジニア) PMM(CS、営業) デザイナー 要件定義 エンジニア デザイナー 設計 エンジニア デザイナー 実装・単体テスト エンジニア デザイナー、オフショア 結合・システム テスト QA オフショア 受け入れテスト QA PMM、カスタマー サクセス/サポート リリース準備 エンジニア/QA 開発管理部門 リリース QA インフラ 運用・保守・ サポート QA カスタマー サクセス/サポート ・年4回の3ヶ月サイクル 「ウォーターフォール開発」&「アジャイル(スクラム)開発」のハイブリッド
  14. 26 【一般論】プロダクトマネージャーとは? ユーザーに価値あるプロダクトを継続的につくり、届け続けるための活動全般 ▪一般的に言われているプロダクトマネージャーの仕事 1.戦略フェーズ業務  └A.ビジョン・ミッション策定    B.マーケットリサーチ    C.プロダクト戦略・ロードマップ策定

    2.顧客・課題の理解  └D.ユーザーリサーチ    E.ペルソナ・カスタマージャーニー設計 3.ソリューション検討・開発推進  └ F.要件定義    G.優先順位の設定    H.チーム連携・開発ディレクション 5.チームや社内外との巻き込み  └ L.ビジネス的な意思決定の支援    M.ステークホルダー調整(巻き込む) 4.リリース・効果検証  └ I.リリースマネジメント    J.データ計測・仮説検証    K.ユーザーフィードバックの収集と改善計画
  15. 27 【一般論】プロダクトの進化段階 ・プロダクト進化の段階に応じて「プロダクトマネジメント」担う役割が変わる 市場適合 PMF 成長 Growth 最適化 Optimization /

    Efficiency ミニCEO プロダクト チーム 事業 責任者 ミニCEO プロダクト チーム セールス チーム CS チーム プロダクト マネジメント プロダクト マネジメント マーケ チーム プロダクト チーム セールス チーム CS チーム PdM 事業 責任者 PMM プロダクト チーム セールス チーム CS チーム PdM プロダクト マネジメント マーケ チーム プロダクト マネジメント
  16. 28 【一般論】PdM-PMM歴史年表 時代 PdM PMM 1930〜1970年代 ブランドマネージャー起源 P&Gのブランドマネージャー制度に影響を 受け製品戦略の管理役として芽生え始める 同じくブランドマネージャー制がルーツ

    主に消費財の販促・広告戦略を担う 1980〜1990年代 ソフトウェア時代の幕開け 技術理解を持つ市場担当として進化 開発寄りにシフト ソフトウェア企業に導入されるが 販促・営業支援が中心 2000年代 アジャイル導入期 継続的改善をリードする役割に プロダクトオーナーとの分業議論が始まる SaaS初期Go-to-Market戦略を部分的に担う ローンチ担当色が強い 2010年代 SaaS・データ活用期 プロダクトのライフサイクル全体を管理 データ活用・UX重視 GTM戦略の中核へ 市場選定・ポジショニング・メッセージングを統括 2020年代〜 AI・グロース時代 AIを活用し価値提供と開発スピードを最大化 倫理・リスク管理も役割に AIで市場分析・メッセージ最適化を加速 顧客毎の最適化戦略を設計、収益責任も担うケース増加
  17. 30 【楽楽精算】PdMの歴史 【立ち上がり期】 30 エンジニア デザイナー 事業企画・開発 セールス マーケティング カスタマー

    サクセス  ・プロダクトの立ち上げ責任者がミニCEO的にプロダクトマネジメントを担う ミニCEO PdM 開発 部門 事業 部門
  18. 31 【楽楽精算】PdMの歴史 【PdM組成期】 31 エンジニア デザイナー 事業企画・開発 セールス マーケティング カスタマー

    サクセス  ・事業部部門の事業責任者直下に「製品企画」というPdM組織が組成される PdM 開発 部門 事業 部門 事業責任者 PdM
  19. 開発部門 事業部門 32 【楽楽精算】PdMの歴史 【PdM組成期】 32 製品企画 エンジニア (PJM含む) デザイナー

    営業 マーケ CS MRD PRD 横断組織で別組織 開発 エンジニア 上流担当 PdM  ・事業部門の「製品企画」部隊と開発の上流部隊でPdMを担っていた
  20. 33 【楽楽精算】PdMの歴史 【PdM-PMM分業期】 33 エンジニア デザイナー 事業企画・開発 セールス マーケティング カスタマー

    サクセス  ・開発部門にPdM組織を組成し、事業部門からPdM領域を移管 開発 部門 事業 部門 事業責任者 PdM PMM
  21. 開発部門 事業部門 34 【ラクス】PdM-PMM体制 [楽楽精算編] 34 プロダクト戦略 PMM エンジニア (PJM含む)

    デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA PdMと同組織 開発は要件定義 以降に専念 結合テスト以降や 技術サポート部隊
  22. 35 Agenda ❏ Speaker紹介 ❏ セッション - PdMを取り巻く過去と現在 - PdM-PMM連携の現在

    - AI時代にPdMとPMMはどのように連携すべきか ❏ 質疑応答 ❏ アンケート記入
  23. 37 【ラクス】開発プロセスでの役割分担 工程 主担当 開発組織 他連携組織 製品ロードマップ PdM PMM 各開発項目決定

    PdM(エンジニア) PMM 要求仕様策定 PdM(エンジニア) PMM(CS、営業) デザイナー 要件定義 エンジニア デザイナー 設計 エンジニア デザイナー 実装・単体テスト エンジニア デザイナー、オフショア 結合・システム テスト QA オフショア 受け入れテスト QA PMM、カスタマー サクセス/サポート リリース準備 エンジニア/QA 開発管理部門 リリース QA インフラ 運用・保守・ サポート QA カスタマー サクセス/サポート
  24. 【AI活用】イメージ(PdM・デザイナー) プロダクト戦略 (PMM) 開発上流 (要件定義・設計) 開発下流 (実装・単体テスト) デザイン上流 (UX設計) デザイン下流

    (UI設計) PdM上流 (製品戦略) PdM下流 (製品要求仕様分析) PMM上流 (事業戦略) PMM下流 (市場要求分析・GTM) プロダクト マネージャー (PdM) デザイナー エンジニア AI代替 [50%以上減] AI代替 [80%以上減] PdM×PMM共同 PdM×デザイナー ×エンジニア共同 一部AI代替 インタビューやVOC 分析[20%以上削減]
  25. 40 【ラクス】役割分担 [楽楽精算編] 40 「プロダクトマネジメントのすべて」より Core Why What How 製品要求仕様

    (PRD) 市場要求仕様 (MRD) 最終OutPut STP/ペルソナ ペインゲイン カスタマー ジャーニー コスト構造 収益モデル プロダクト指標 ロードマップ UI/設計/実装 GTM ミッション ビジョン 事業戦略 市場分析 競合分析 Discovery Delivery PdM PMM PMM PdM PMM PdM
  26. 開発部門 事業部門 41 【課題】PdM-PMM体制 [楽楽精算編] 41 プロダクト戦略 PMM エンジニア (PJM含む)

    デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA 出典:ラクス社提供資料 課題① 課題② 課題③ 課題④
  27. 43 【参考】製品解像度 製品解像度 お客様 自組織 システム UI/UX ドメイン 運用中 導入準備中

    導入検討 未検討 未来 市場 他組織 事業戦略 開発プロセス 役割 出典:ラクス社提供資料
  28. 44 AI登場による取り巻く環境変化 ▪ここ1年での環境変化 └製品 側面 ・AIの標準装備化と価値の再定義 ・収益モデルの見直し ・顧客のDXニーズの成熟 ・生成AIによる“競合”の再定義 ・セキュリティ・コンプライアンス要件の複雑化

    └役割 側面 ・開発スピードと検証プロセスの進化 ・職種間の境界が溶けはじめている ・ディスカバリー領域の拡張 ・デリバリースピードの加速 ・カスタマーサクセスの高度化 ⇒プロダクト開発は高速化・複雑化し、提供価値や価格モデルの再定義が迫られている   顧客もツール導入から業務再設計(DX)へ関心が移行 開発側も仮説検証・ディスカバリー・CSの重要性が一段と増している
  29. 開発部門 事業部門 47 【課題】PdM-PMM体制 [楽楽精算編] 47 プロダクト戦略 PMM エンジニア (PJM含む)

    デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA 課題① 課題② 課題③ 課題④
  30. 52 コア 製品戦略、製品ロードマップ、バージョン内容、開発計画 ディスカバリー 案件創出、要求仕様策定 デリバリー 要件定義、設計、実装、単体、テスト、リリース デリバリー GTM、サポート・運用 事業責任者

    PMM PdM リーダー PdM
 リーダー Designer
 ミッション ビジョン 事業戦略 製品戦略 ロードマップ 開発計画 バージョンアップ計画 案件 課題 PBI/案件 商材 PMM
 UX Designer
 STP/ペルソナ ペインゲイン カスタマー ジャーニー 市場分析 競合分析 製品要求仕様 (PRD) ロードマップ 開発案件 PjM
 QA
 ENG
 UI Designer
 PMM
 CS マーケ
 セールス
 製品 PR・発信 営業・ QA
 開発案件 PdM
 PdM
 【理想】役割定義・分担 PdM

  31. 53 ディスカバリー、デリバリー領域・プロセスの再定義 53 市場/製品 要求仕様 要件定義・ UX設計 設計・実装・テスト 結合テスト リリース

    準備 GTM詳細設計 GTM 実装・ リリース フィード バック 収集 課題 深堀 •ウォーターフォール プロセス  └ ユーザー課題が明確ではあるが、各ステークホルダーへの十分な理解が必要なもの •デュアル トラック アジャイル&リーンUXキャンバス プロセス  └ ユーザー課題がまだ不明瞭で、探索が必要で実験的な開発を高速で回す必要があるもの 仮説 ・検証 PdM×PMM ×ENG×DES 実装・ リリース フィード バック 収集 課題 深堀 仮説 ・検証 PdM×PMM ×ENG×DES
  32. 54 ディスカバリー、デリバリー領域・プロセスの再定義 54 市場/製品 要求仕様 要件定義・ UX設計 設計・実装・テスト 結合テスト リリース

    準備 GTM詳細設計 GTM 実装・ リリース フィード バック 収集 課題 深堀 ウォーターフォール プロセス  └ ユーザー課題が明確ではあるが、各ステークホルダーへの十分な理解が必要なもの デュアル トラック アジャイル&リーンUXキャンバス プロセス  └ ユーザー課題がまだ不明瞭で、探索が必要で実験的な開発を高速で回す必要があるもの 仮説 ・検証 PdM×PMM ×ENG×DES 実装・ リリース フィード バック 収集 課題 深堀 仮説 ・検証 PdM×PMM ×ENG×DES 2つのプロセスを共存させつつ、ラクス流に再定義 ▪ポイント  └ 各役割の中をAI駆動で実現 └ プロダクトチーム(PMM×PdM×ENG×DES)の役割のボーダーレス化   
  33. 58 採用人材及び育成の方針の見直し ▪AI時代に求められる力 1)問いを立て動きながら学べる力  ⇒「ラーニングアニマル」 ・AIは「答え」は出してくれるが「問い」は出してくれないのでそれを出すことができる ・アンラーンをし、自ら動いて新たな知識や知恵を獲得できる 2)信頼を築ける力 ⇒「信じて動きたくなる人」 ・凡事徹底によって信用と小さな成果を着実に積み重ねることができる ・「見えない感情的つながり」=「信頼」=「設計資産」を作れる

       ※「設計資産」とは「再利用可能な設計に関する情報や成果物」 ハードスキルよりソフトスキルへ  ハード スキル:「できること」=専門知識や技術スキル             └具体例 プログラミング、データ分析、簿記、会計知識、マーケティング戦略立案 ソフト スキル:「どうやるか・どう関わるか」=対人力・思考力・行動力             └具体例 コミュ力、傾聴・共感力、チームワーク