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

生成AI時代、PMは事業責任者に進化するともっと面白い〜PMだからこそ事業構造を動かせる時代に〜

 生成AI時代、PMは事業責任者に進化するともっと面白い〜PMだからこそ事業構造を動かせる時代に〜

プロダクトマネージャーカンファレンス2026 | pmconf 2026
https://2026.pmconf.jp/event-fukuoka/
での登壇資料です

Avatar for KAKEHASHI

KAKEHASHI PRO

October 23, 2026

More Decks by KAKEHASHI

Other Decks in Technology

Transcript

  1. NTTグループ→リクルート → カケハシ(9年目) MusubiのCS組織 立ち上げ&何でも屋 → Musubi AI在庫管理 立ち上げPM(以降SCM領域の 事業責任者/プロダクト統括)

    → ファルマーケット M&A / PMI(現在同社代表取締役) → SCM領域のPMM・営業/CS組織立ち上げ 山本 惇一 →医薬品安定供給サービス立ち上げ →全社のプラットフォーム領域のプロダクト統括 ※個人開発ではAI Native SDLCやってます 3
  2. そもそもPMと事業責任者は、何が違う? PM(従来) 事業責任者 顧客体験の解像度 「何が課題で、それはなぜ?」を 顧客に向ける 事業の中心 = P/L (売上と利益)の

    因数分解を見る + 違いは「視点」。思考は基本的には一緒。視点を顧客から 「事業全体のバリューストリーム」へ広げるだけ 5
  3. 事業責任者→P/Lを分解して、動かす「レバー」を見つける 売上サイド コストサイド 売上 = 社数 × 単価 LTV/CAC、ユニットエコノミク ス、導入費、保守費

    各Sales StageのCVR(The model型の場合はマーケ/ISも 含めたCVR) 人件費・委託・AWS費用etc そのタイミングで何が最も重要か考え、そこの課題を深掘りする 7
  4. 売上/コストを分解すると・・・・ 売上 コスト 営業 社数 (大手/SMB) 単価 費用項目(固変分解) 営業人員数 人件費

    AWS費用 一人当たり商談数 業務委託費 AI利用料 Sales Stage のCVR プロセス プロダクト+α マーケティング 営業 機能開発 連携機能/ アライアンス Onboarding サポート 商談同行/デモ 将来を語る プロダクト開発 システム保守 レバーの候補は、無数にある
  5. 生成AI時代、PM出身だと「介入ポイント」が広くなる これまで 生成AI時代 ・基本的には機能開発 ・自前ツールでOpsを最適化 ・CSのOps改善をしたいがプ ロダクト優先で手が回らない ・コード→サポート→Chatbot までを一気通貫するなど「デー タ&ナレッジ」を統合

    ・営業やCS領域は各組織で 回っておりデータもバラバラ、 横断した打ち手が打ちづらい ・営業を改善するツールも自作 可能に 開発チームはコアプロダクトに集中。 BizOps領域はビジネス系メンバーと連携しながら高速で廻す 9
  6. 売れる営業の「違い」を因数分解 = PMの課題分解と同じ ① 業界知識 製薬・薬局の ドメイン ③ Sales Stage

    スキル ② プロダクト知見 × 強み・競合差分・ 運用後 × ステージ設計した 商談 × ④ 暗黙知に近いナレッジ群 トップ営業マンの「商談の解説」を教師データに投入 → 精度が跳ねた この4つを掛け合わせた商談設計、特に暗黙知に近い言語化しづら いナレッジ = 売れる営業の正体 12
  7. 暗黙知をAIが形式知化することで、トレーニングツールへと昇華 INPUT 商談を録音 → 全文をテキ スト化 AI-YUSUKE エンジン OUTPUT AI-Yusuke

    → Powered by Claude ルーブリック 15件 共通9 + Stage6 ※商談解説、過去商 談、資料等学習データ → ポイントFB(Goodポイ ント、モットポイント) 「こう言う」提案 (具体的な案を提示) 本人のモチベーションと次へ のアクションの具体化を意識 全体のプロセスを営業メンバーと議論しながら構築。汎用的なナレッジと Sales Stage固有のナレッジをルール化し、アウトプットのベースに 13
  8. PM経験があるから教師データを工夫できる 商談録画 → トップ営業 の解説 → 教師データ → AIが判断ルール化 担当者:鋭い機能質問を連発

    「〇〇の連携は?」「在庫ズレはど う直す?」… 罠:経験が浅い営業は「キーマン だ」と機能説明に熱が入る 大事なポイント:決裁者か? ・鋭いが、役職と不釣り合い ・発言が全部「他人事」 → 借り物の質問=決裁者でない (後にラウンダーと判明) 資料には「キーマンを早期特定せよ」としか書けない。 「どう見抜くか」は本人の解説で初めて言語化=「解説」が教師データ。 14
  9. プロトタイプは数日で完成し、Databricks Appsに 営業・PM 商談テキスト → Databricks Apps → ↓ Claude

    API (LLM) (Foundation Model API) ルーブリック + 教師データ (Unity Catalog) Databricks Workspace ① 安心して試せる:認証・権限・LLMまでDatabricks内で完結。データは 社外に出ない ② 役割分担:PMは0→1を爆速で検証、1→10はエンジニアと 15
  10. AI-Yusukeから派生した様々なツールの発生、自然言語を如何に データ化し、資産として活用するかという視点が生まれ始める 営業マスターへの道 3秒回答のQA特訓 ← AI-Yusuke (最初の型) → AI Yu-san

    オンボーディング 支援 ↕ 問い合わせChatbot ナレッジを追加 1つの機能ではなく型(自然言語のデータ化→ナレッジ化)を設計する ことで、事業全体に広がっていく 16
  11. CVRの改善幅は現在計測中も、レビュー工数が75%減になるなど 少なくとも業務プロセス効率化では数値的な成果もでている 営業マネージャー (Yusuke-san) 営業リーダー /共同開発者 (Kosuke-san) 営業メンバー (Amano-san) 現場の熱量は高い。新規入場者は是非やったほうがよい。結果が〇×だけでなく

    △・◎もあり、改善内容が具体的で明確なため改善のループをまわしやすい。改 善要望も具体的で建設的 営業担当者が任意のタイミングでさっとできるようになり商談ごとにフィード バックを得られるようになった、という観点では商談実施~レビューを受けるサ イクルを4,5倍にできた。非言語的な部分についてもより実戦形式に近い形でト レーニングを積むことができるようになった。 自分自身やメンバー同士で商談を振り返ると、反省中心の厳しい評価になった り、感情が入りやすかったりするんですけど、AIからのフィードバックだと、一定 の距離を置いて自分の商談を捉えることができるので、確かに。と腹落ちする部 分は多い気がします。 17
  12. 肩書きがなくても、明日からできる小さな一歩 1 2 3 営業の商談録音を 1本もらい AIでFBしてみる CSの問い合わせ 上位を ナレッジ化してみる

    営業定例に出て ファネルの数字を 一緒に見て分析 してみる 小さな打席の積み重ねが、事業全体を設計する力になる 視点を意識しながら様々な打席を自ら創る プライベートも含め打席自体も作りやすくなっている 21
  13. なぜ、事業責任者になると「もっと」面白いのか 1 打てるレバーが増える 機能開発だけでなく、営業・CS・Opsまで 2 1つの型が、事業全体に広がる AI-Yusuke → 営業マスター/AI Yu-san/Chatbot

    3 成果が、現場とP/Lで返ってくる レビュー工数75%減・サイクル4〜5倍、売上増にも・・・・ 大事なのは「視点」 PMは、事業に踏み込むと、もっと面白い。 23