本ウェビナー アイキャッチ画面貼付 1 

大手独立系 SIer企業 （担当 WEBサービス） ・バックエンドWEBエンジニア ・システムエンジニア ・プロジェクトマネージャー ISP系サービス企業 （担当 BtoB事業） ・プリセールス ・製品開発責任者(バックエンド開発) 上場系中堅ベンチャー企業 （担当 ブログ、ECサービス） ・バックエンドWEBエンジニア ・WEBディレクター ・エンジニアリングマネージャー ベンチャー企業 （担当 ファッションECサービス) ・エンジニアリングマネージャー ・製品開発責任者（企画・開発デザイン） ・取締役(製品・コーポレート) グローバルパブリッククラウド企業 （担当 API・AI・モバイル関連20サービス) ・技術サポートエンジニアマネージャー SaaS企業[現職] （担当 バックオフィスSaaS) ・プロダクトマネージャー プロジェクト マネージャー バックグラウンド バックエンド エンジニア エンジニアリグ マネージャー プロダクト マネージャー 略歴 稲垣 剛之(いながき たけし) 　　　@ingktks7 2021年8月入社 株式会社 ラクス 開発本部 東京開発統括部 　 プロダクト部 副部長 / 製品管理課 課長 自己紹介 

自己紹介 開発本部 東京開発統括部 　　　　　　　　　　　　　プロダクト部　製品管理課 紀井 美里(きい みさと) ラクス入社 新卒エンジニア職 オフショア開発 ／ブリッジSE 開発・運用 PjM PdM @keeeey_M 担当プロダクト 

【 ラクスの提供サービス一覧 】 ITサービスで企業の成長を継続的に支援します! 会社紹介 

5 Question ラクスでは20年以上SaaS提供をしていますが、 長い年月の中でどのような変化がありましたか？ PdMを取り巻く過去と現在 

6 ベスト・オブ・ブリード型 最適なシステムを各分野ごとに取り入れる 各分野に特化した製品を選定する形 例）勤怠管理はA社、経費精算はB社、会計ソフトはC社 スイート型 各種システムを同一ベンダーで統一 人事も経理もすべて同じシステムで管理するイメージ ラクスはこれ！ ラクス 特徴 １．マルチプロダクトでの製品成長 ２．特定ドメイン領域の課題に特化し、お客様のペインを解消する戦略 特徴 

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

メール系製品の紹介（ラクスシリーズ） サービス名 提供開始 ARR 主な利用部門 提供機能 メール共有・管理システム 「メールディーラー」 2001年 36億円 複数名のスタッフでメール対応をしている カスタマーサポート部門 ・問合せメールの返信状況管理 ・顧客との対応履歴管理 メルマガ配信システム 「配配メール」 2007年 31億円 見込客や顧客にメルマガを配信している営 業やマーケティング部門 ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング メルマガ配信システム 「ブラストメール」 ※(株)ラクスライトクラウド提供 2007年 ・大量高速メルマガ配信 ・メルマガ配信の効果測定 ・エラーアドレスのクリーニング システム連携特化型 メール配信システム 「ブラストエンジン」 ※(株)ラクスライトクラウド提供 2021年 メール配信機能との連携が必要なシステム 開発・IT部門 ・メール配信API ・SMTPリレー 

沿革＆業績推移 ARR30億円超＆10年超の製品が5つ、新規製品も2年一度程度投入 Rule of 40 （年成長率+営業利益率が40%を超えているか） └ 48% (年成長率 27% + 営業利益率 21%) 

ベスト・オブ・ブリード型 最適なシステムを各分野ごとに取り入れる 各分野に特化した製品を選定する形 例）勤怠管理はA社、経費精算はB社、会計ソフトはC社 スイート型 各種システムを同一ベンダーで統一 人事も経理もすべて同じシステムで管理するイメージ ラクスはこれ！ ラクス 特徴 １．マルチプロダクトでの製品成長 ２．特定ドメイン領域の課題に特化し、お客様のペインを解消する戦略 特徴 

11 Question ラクス社のこれまでと現在の プロダクト開発環境の違いを教えてください PdMを取り巻く過去と現在 

【ラクス】組織全体 管理部門 事業部門 楽楽シリーズ部門 開発部門 ラクスシリーズ部門 各商材組織 各商材組織 各商材組織 横断組織 【機能別組織】 営業、CS マーケ、製品企画 【機能別組織】 経営管理：総務、人事、経理、法務等 技術本部：情シス 【機能別組織】 営業、CS マーケ、製品企画 

【PdM】開発部門 東京開発部門 プロダクト部 楽楽明細開発部 大阪開発部門 楽楽販売開発部 他各商材開発部 横断開発部門 インフラ開発部 開発管理・ ＡＩ開発等部門 各商材の開発組織は約10名～50名程度 楽楽精算開発部 QA課 各商材 PdM・QA・フロントエンドの 関わり方は商材によって 異なる(部内にいる場合もあり) PdM組織 プロダクトデザイン課 楽楽勤怠開発部 

14 Agenda ❏ Speaker紹介 ❏ セッション - PdMを取り巻く過去と現在 - PdM-PMM連携の現在 - AI時代にPdMとPMMはどのように連携すべきか ❏ 質疑応答 ❏ アンケート記入 

15 Question ラクスでは、PdMとPMMの役割は どのように定義していますか？ PdMを取り巻く過去と現在 

16 PdM/PMM 役割分担 共通 ・どういう価値が事業戦略や製品戦略上必要なのか ・どの優先度や順序で取り組むべきか PdM（製品管理課） ・その価値を具現化してお客様に提供することを主導する PMM(プロダクト戦略) ・その価値をどのようにお客様に届け、伝えるかことを主導する 

17 【ラクス】組織全体 管理部門 事業部門 楽楽シリーズ部門 開発部門 ラクスシリーズ部門 各商材組織 各商材組織 各商材組織 横断組織 【機能別組織】 営業、CS マーケ、製品企画 【機能別組織】 経営管理：総務、人事、経理、法務等 技術本部：情シス 【機能別組織】 営業、CS マーケ、製品企画 PdMの所属 組織 PMM所属 組織 

18 【PdM】開発部門 東京開発部門 プロダクト部 楽楽明細開発部 大阪開発部門 楽楽販売開発部 他各商材開発部 横断開発部門 インフラ開発部 開発管理・ ＡＩ開発等部門 各商材の開発組織は約10名～50名程度 楽楽精算開発部 QA課 各商材 PdM・QA・フロントエンドの 関わり方は商材によって 異なる(部内にいる場合もあり) PdM組織 プロダクトデザイン課 楽楽勤怠開発部 楽楽明細開発部で 楽楽電子保存の 開発も担当 開発組織 デザイナーと 同一組織に所属 12名 

19 Question 普段、どのようにPdMとPMMの 連携を進めていますか？ PdM-PMM連携の現在 

開発部門 事業部門 20 【ラクス】PdM-PMM体制 [楽楽精算編] 20 プロダクト戦略 PMM エンジニア (PJM含む) デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA PdMと同組織 結合テスト以降や 技術サポート部隊 

21 【ラクス】役割分担 [楽楽精算編] 21 「プロダクトマネジメントのすべて」より Core Why What How 製品要求仕様 （PRD） 市場要求仕様 （MRD） 最終OutPut STP/ペルソナ ペインゲイン カスタマー ジャーニー コスト構造 収益モデル プロダクト指標 ロードマップ UI/設計/実装 GTM ミッション ビジョン 事業戦略 市場分析 競合分析 Discovery Delivery PdM PMM PMM PdM PMM PdM 

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 

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を担当 

24 【ラクス】開発プロセスでの役割分担 [楽楽精算編] 工程 主担当 開発組織 他連携組織 製品ロードマップ ＰｄＭ ＰＭＭ 各開発項目決定 ＰｄＭ(エンジニア) ＰＭＭ 要求仕様策定 ＰｄＭ(エンジニア) ＰＭＭ(ＣＳ、営業) デザイナー 要件定義 エンジニア デザイナー 設計 エンジニア デザイナー 実装・単体テスト エンジニア デザイナー、オフショア 結合・システム テスト ＱＡ オフショア 受け入れテスト ＱＡ ＰＭＭ、カスタマー サクセス/サポート リリース準備 エンジニア/ＱＡ 開発管理部門 リリース ＱＡ インフラ 運用・保守・ サポート ＱＡ カスタマー サクセス/サポート ・年4回の3ヶ月サイクル 「ウォーターフォール開発」＆「アジャイル(スクラム)開発」のハイブリッド 

25 Question これまで「楽楽シリーズ」展開において、 PdM-PMM連携はどのように進化しましたか？ 大規模化で直面した具体的な課題や「壁」には どのようなものがありますか？ PdM-PMM連携の現在 

26 【一般論】プロダクトマネージャーとは？ ユーザーに価値あるプロダクトを継続的につくり、届け続けるための活動全般 ■一般的に言われているプロダクトマネージャーの仕事 １．戦略フェーズ業務 　└A.ビジョン・ミッション策定 　　 B.マーケットリサーチ 　　 C.プロダクト戦略・ロードマップ策定 ２．顧客・課題の理解 　└D.ユーザーリサーチ 　　 E.ペルソナ・カスタマージャーニー設計 ３．ソリューション検討・開発推進 　└ F.要件定義 　　　G.優先順位の設定 　　　H.チーム連携・開発ディレクション ５．チームや社内外との巻き込み 　└ L.ビジネス的な意思決定の支援 　　　M.ステークホルダー調整(巻き込む) ４．リリース・効果検証 　└ I.リリースマネジメント 　　　J.データ計測・仮説検証 　　　K.ユーザーフィードバックの収集と改善計画 

27 【一般論】プロダクトの進化段階 ・プロダクト進化の段階に応じて「プロダクトマネジメント」担う役割が変わる 市場適合 PMF 成長 Growth 最適化 Optimization / Efficiency ミニCEO プロダクト チーム 事業 責任者 ミニCEO プロダクト チーム セールス チーム CS チーム プロダクト マネジメント プロダクト マネジメント マーケ チーム プロダクト チーム セールス チーム CS チーム PdM 事業 責任者 PMM プロダクト チーム セールス チーム CS チーム PdM プロダクト マネジメント マーケ チーム プロダクト マネジメント 

28 【一般論】PdM-PMM歴史年表 時代 PdM PMM 1930〜1970年代 ブランドマネージャー起源 P&Gのブランドマネージャー制度に影響を 受け製品戦略の管理役として芽生え始める 同じくブランドマネージャー制がルーツ 主に消費財の販促・広告戦略を担う 1980〜1990年代 ソフトウェア時代の幕開け 技術理解を持つ市場担当として進化 開発寄りにシフト ソフトウェア企業に導入されるが 販促・営業支援が中心 2000年代 アジャイル導入期 継続的改善をリードする役割に プロダクトオーナーとの分業議論が始まる SaaS初期Go-to-Market戦略を部分的に担う ローンチ担当色が強い 2010年代 SaaS・データ活用期 プロダクトのライフサイクル全体を管理 データ活用・UX重視 GTM戦略の中核へ 市場選定・ポジショニング・メッセージングを統括 2020年代〜 AI・グロース時代 AIを活用し価値提供と開発スピードを最大化 倫理・リスク管理も役割に AIで市場分析・メッセージ最適化を加速 顧客毎の最適化戦略を設計、収益責任も担うケース増加 

29 ラクス 楽楽精算 PdM進化の歴史 

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

31 【楽楽精算】PdMの歴史 【PdM組成期】 31 エンジニア デザイナー 事業企画・開発 セールス マーケティング カスタマー サクセス 　・事業部部門の事業責任者直下に「製品企画」というPdM組織が組成される PdM 開発 部門 事業 部門 事業責任者 PdM 

開発部門 事業部門 32 【楽楽精算】PdMの歴史 【PdM組成期】 32 製品企画 エンジニア (PJM含む) デザイナー 営業 マーケ CS MRD PRD 横断組織で別組織 開発 エンジニア 上流担当 PdM 　・事業部門の「製品企画」部隊と開発の上流部隊でPdMを担っていた 

33 【楽楽精算】PdMの歴史 【PdM-PMM分業期】 33 エンジニア デザイナー 事業企画・開発 セールス マーケティング カスタマー サクセス 　・開発部門にＰｄＭ組織を組成し、事業部門からPdM領域を移管 開発 部門 事業 部門 事業責任者 PdM PMM 

開発部門 事業部門 34 【ラクス】PdM-PMM体制 [楽楽精算編] 34 プロダクト戦略 PMM エンジニア (PJM含む) デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA PdMと同組織 開発は要件定義 以降に専念 結合テスト以降や 技術サポート部隊 

35 Agenda ❏ Speaker紹介 ❏ セッション - PdMを取り巻く過去と現在 - PdM-PMM連携の現在 - AI時代にPdMとPMMはどのように連携すべきか ❏ 質疑応答 ❏ アンケート記入 

36 Question 製品開発プロセスの中でAIを どのように活用していますか？ AI時代にPdMとPMMはどのように連携すべきか 

37 【ラクス】開発プロセスでの役割分担 工程 主担当 開発組織 他連携組織 製品ロードマップ ＰｄＭ ＰＭＭ 各開発項目決定 ＰｄＭ(エンジニア) ＰＭＭ 要求仕様策定 ＰｄＭ(エンジニア) ＰＭＭ(ＣＳ、営業) デザイナー 要件定義 エンジニア デザイナー 設計 エンジニア デザイナー 実装・単体テスト エンジニア デザイナー、オフショア 結合・システム テスト ＱＡ オフショア 受け入れテスト ＱＡ ＰＭＭ、カスタマー サクセス/サポート リリース準備 エンジニア/ＱＡ 開発管理部門 リリース ＱＡ インフラ 運用・保守・ サポート ＱＡ カスタマー サクセス/サポート 

【AI活用】イメージ(PdM・デザイナー) プロダクト戦略 (PMM) 開発上流 （要件定義・設計） 開発下流 （実装・単体テスト） デザイン上流 （UX設計） デザイン下流 （UI設計） PdM上流 （製品戦略） PdM下流 （製品要求仕様分析） PMM上流 （事業戦略） PMM下流 （市場要求分析・GTM） プロダクト マネージャー (PdM) デザイナー エンジニア AI代替 [50％以上減] AI代替 [80％以上減] PdM×PMM共同 PdM×デザイナー ×エンジニア共同 一部AI代替 インタビューやVOC 分析[20%以上削減] 

39 Question AIの発展により、PdM-PMMの連携は どのように変化していくと考えていますか？ AI時代にPdMとPMMはどのように連携すべきか 

40 【ラクス】役割分担 [楽楽精算編] 40 「プロダクトマネジメントのすべて」より Core Why What How 製品要求仕様 （PRD） 市場要求仕様 （MRD） 最終OutPut STP/ペルソナ ペインゲイン カスタマー ジャーニー コスト構造 収益モデル プロダクト指標 ロードマップ UI/設計/実装 GTM ミッション ビジョン 事業戦略 市場分析 競合分析 Discovery Delivery PdM PMM PMM PdM PMM PdM 

開発部門 事業部門 41 【課題】PdM-PMM体制 [楽楽精算編] 41 プロダクト戦略 PMM エンジニア (PJM含む) デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA 出典：ラクス社提供資料 課題① 課題② 課題③ 課題④ 

42 課題①：PdM ・「製品解像度」がまだまだ不十分 課題②：PdM-PMM連携 ★ ・PdM-PMMの部門が違うことで連携課題があり、製販一体の動きが不十分 課題③：デザイナー ・UX領域（UXリサーチや顧客ヒアリング）から十分に参画できていない 課題④：エンジニア ・PdMが顧客視点が担うことになり、顧客ニーズに即応しづらい 各役割連携課題 補足 

43 【参考】製品解像度 製品解像度 お客様 自組織 システム UI/UX ドメイン 運用中 導入準備中 導入検討 未検討 未来 市場 他組織 事業戦略 開発プロセス 役割 出典：ラクス社提供資料 

44 AI登場による取り巻く環境変化 ■ここ1年での環境変化 └製品 側面 ・AIの標準装備化と価値の再定義 ・収益モデルの見直し ・顧客のDXニーズの成熟 ・生成AIによる“競合”の再定義 ・セキュリティ・コンプライアンス要件の複雑化 └役割 側面 ・開発スピードと検証プロセスの進化 ・職種間の境界が溶けはじめている ・ディスカバリー領域の拡張 ・デリバリースピードの加速 ・カスタマーサクセスの高度化 ⇒プロダクト開発は高速化・複雑化し、提供価値や価格モデルの再定義が迫られている 　 顧客もツール導入から業務再設計（DX）へ関心が移行 開発側も仮説検証・ディスカバリー・CSの重要性が一段と増している 

45 ラクス AI製品活用 ●楽楽精算、メールディーラーはロードマップを公開 └いずれもAIエージェント搭載予定 ●他製品でもAIの製品利用が多数進行中 　　└ 楽楽明細、楽楽債権管理、楽楽販売、配配メール 

46 ラクス AIの業務利用 ラクス、生成AI活用に関する社内調査を実施 日々の業務における生成AI活用率は97.9% ・利用深度のグラデーションはあるが 　　　　 　全従業員、職種問わずほぼ全員が活用 ・開発組織 　└ Claude Code Max / Devin / Copilot / Junie ・PdM＆デザイナーは「Cursor ＋ α」で活用 ・新ツールも出てから1-2週間で利用ができる環境 

開発部門 事業部門 47 【課題】PdM-PMM体制 [楽楽精算編] 47 プロダクト戦略 PMM エンジニア (PJM含む) デザイナー 営業 マーケ CS MRD PRD 製品管理課 PdM QA 課題① 課題② 課題③ 課題④ 

48 課題①：PdM ・「製品解像度」がまだまだ不十分 課題②：PdM-PMM連携 ★ ・PdM-PMMの部門が違うことで連携課題があり、製販一体の動きが不十分 課題③：デザイナー ・UX領域（UXリサーチや顧客ヒアリング）から十分に参画できていない 課題④：エンジニア ・PdMが顧客視点が担うことになり、顧客ニーズに即応しづらい 各役割連携課題 補足 AIの台頭により些末な課題へ 

49 Question AI時代に、PdM-PMM連携を加速させる上で、 どのようなことに取り組むべきですか？ AI時代にPdMとPMMはどのように連携すべきか 

50 AI時代に変化し取り組むべきこと 1 理想の役割は定義は実施 2 ディスカバリー、デリバリー領域・プロセスの再定義 3 採用人材及び育成の方針の見直し 

51 【今後】PdM-PMM連携イメージ エンジニア デザイナー 事業企画・開発 セールス マーケティング カスタマー サクセス ・PdM-PMMが互いの強みを活かし背中を預けられる体制 開発 部門 事業 部門 事業責任者 PdM PMM 

52 コア 製品戦略、製品ロードマップ、バージョン内容、開発計画 ディスカバリー 案件創出、要求仕様策定 デリバリー 要件定義、設計、実装、単体、テスト、リリース デリバリー GTM、サポート・運用 事業責任者 PMM PdM リーダー PdM
 リーダー Designer
 ミッション ビジョン 事業戦略 製品戦略 ロードマップ 開発計画 バージョンアップ計画 案件 課題 PBI/案件 商材 PMM
 UX Designer
 STP/ペルソナ ペインゲイン カスタマー ジャーニー 市場分析 競合分析 製品要求仕様 （PRD） ロードマップ 開発案件 PｊM
 QA
 ENG
 UI Designer
 PMM
 CS マーケ
 セールス
 製品 PR・発信 営業・ QA
 開発案件 PdM
 PdM
 【理想】役割定義・分担 PdM
 

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

54 ディスカバリー、デリバリー領域・プロセスの再定義 54 市場/製品 要求仕様 要件定義・ UX設計 設計・実装・テスト 結合テスト リリース 準備 GTM詳細設計 GTM 実装・ リリース フィード バック 収集 課題 深堀 ウォーターフォール プロセス 　└ ユーザー課題が明確ではあるが、各ステークホルダーへの十分な理解が必要なもの デュアル トラック アジャイル＆リーンUXキャンバス プロセス 　└ ユーザー課題がまだ不明瞭で、探索が必要で実験的な開発を高速で回す必要があるもの 仮説 ・検証 PdM×PMM ×ENG×DES 実装・ リリース フィード バック 収集 課題 深堀 仮説 ・検証 PdM×PMM ×ENG×DES ２つのプロセスを共存させつつ、ラクス流に再定義 ■ポイント 　└ 各役割の中をAI駆動で実現 └ プロダクトチーム（PMM×PdM×ENG×DES）の役割のボーダーレス化 　　 

55 Question AIの登場により、PdM・PMMそれぞれに 求められるスキルはどのように変化しますか？ AI時代にPdMとPMMはどのように連携すべきか 

56 AI時代に変化し取り組むべきこと 1 理想の役割は定義は実施 2 ディスカバリー、デリバリー領域・プロセスの再定義 3 採用人材及び育成の方針の見直し 

57 採用人材及び育成の方針の見直し ■AI時代に求められる力 １）問いを立て動きながら学べる力 　⇒「ラーニングアニマル」 ・AIは「答え」は出してくれるが「問い」は出してくれないのでそれを出すことができる ・アンラーンをし、自ら動いて新たな知識や知恵を獲得できる ２）信頼を築ける力　⇒「信じて動きたくなる人」 ・凡事徹底によって信用と小さな成果を着実に積み重ねることができる ・「見えない感情的つながり」＝「信頼」＝「設計資産」を作れる 　　 ※「設計資産」とは「再利用可能な設計に関する情報や成果物」 

58 採用人材及び育成の方針の見直し ■AI時代に求められる力 １）問いを立て動きながら学べる力 　⇒「ラーニングアニマル」 ・AIは「答え」は出してくれるが「問い」は出してくれないのでそれを出すことができる ・アンラーンをし、自ら動いて新たな知識や知恵を獲得できる ２）信頼を築ける力　⇒「信じて動きたくなる人」 ・凡事徹底によって信用と小さな成果を着実に積み重ねることができる ・「見えない感情的つながり」＝「信頼」＝「設計資産」を作れる 　　 ※「設計資産」とは「再利用可能な設計に関する情報や成果物」 ハードスキルよりソフトスキルへ 　ハード スキル：「できること」＝専門知識や技術スキル 　　　　　　　　　　　　└具体例 プログラミング、データ分析、簿記、会計知識、マーケティング戦略立案 ソフト スキル：「どうやるか・どう関わるか」＝対人力・思考力・行動力 　　　　　　　　　　　　└具体例 コミュ力、傾聴・共感力、チームワーク 

59 最後に ラクスではそんな「プロダクトマネージャー」を募集しています プロダクト部紹介 PdM カジュアル面談応募 ラクスは大きな変革期に入っています。 今期末の現中期計画の達成は見え、次の中長期に向けて動き出しています ⇒特にこの２点が今後取り組むべきことです 　　１．製品へのAI活用 　　２．統合型ベスト・オブ・ブリード型に向けたUIやUXへの取り組み