Product Management Summit に参加しました。
本当は一日参加の予定が都合により合間を縫っての参加となりました。
それでも多くの学びがありました。
イベントに参加した学びをまとめます。
イベントの概要
技術の進化により、プロダクトを取り巻く環境は大きく変化しています。データ活用や自然言語インターフェース、サービス連携が進む中で、顧客価値の届け方やマネタイズの設計も再定義が求められています。
同時に、PdM・デザイナー・エンジニアが職能を越えて協働するなど、価値創出のための組織やチームの形も変わり始めています。
AI時代に、顧客価値を継続的に生み続けるプロダクトマネジメントとは何か。
各社の実践と試行錯誤を共有し、次の一歩を考える場として本イベントを開催します。
引用：
product-management-summit.findy-tools.io
イベント参加の背景
- 今年からコミュニティ運営をはじめておりもっと学びたい。
- 魅力的なコミュニティ運営者ばかりなので是が非でも学びたい。
- 参加者としても好きなコミュニティが多いので参加！！
セッション
ボトムアップの限界を越える - 20チームを束ねる"Drive Map
メモ
カオナビに転職して1年。
フリーアドレス、テレワーク中心に最初は戸惑った。
開発チームが20チームある。
・入社して見えた健全に見える病
表面上はうまく見えても、中はうまくいかなかった問題。
ビジョン・戦略は明確、ボトムアップで自律的、エンジニア組織も優秀。
理想的な状態だが、問題が見えづらい状態だった。
・20チームそれぞれの認識正義で走っている。全体で見た時に企業の戦略に対してはブレがある。
・プロダクト戦略のオーナーが事実上不在。全体判断できる人間がいない。
・機能を作ることがゴール化。目先の機能にフォーカスしていた。
初期フェーズは四角。正確なピラミッドができる。
現在は20角歪なピラミッドになり、正確な価値が顧客に伝わらない。
やったこと。翻訳レイヤーの構築をした。
・プロダクト戦略の明確化・言語化：事業戦略を開発目線で翻訳
・Drive Mapの設計と導入：全チームが自分の位置を確認できる共通地図
・「報告」から「相談」への転換：日常のコミュニケーションの型を変える
プロダクト戦略の言語化
・事業戦略の開発観点への翻訳
・優位性の明示：当社では無いとできないことの言語化
・やること／やらないことの基準：迷った時の優先度を明確化、属人的な判断を排除
・顧客セグメント別の共通言語化：顧客の課題・攻め方をセグメント別に整理しチームが扱えるように
Drive Map。指示書ではなく、ナビゲーション。
なぜやるかをチームに紐づけ全チーム同一フォーマットで共有。
情報の非対称性を無くす。
プロダクト戦略→開発部門OKR→チームゴール（半年後/1.5年後）→追いかける指標→事業KPIとの接続
目先じゃなく中期目標を意識させ、何をもとに成功と考えるかを整理した。
導入プロセスと工夫
・分化を重視。過去の経緯を大事にした。
・トライアルなどせず、一気に導入。
・敢えてのトップダウン方式で「変わる」というメッセージを伝えた
・走りながら改善。
報告から相談への転換
・やめたこと：ロードマップに対する進捗報告
・はじめたこと：進捗報告は非同期で実施。当日は課題報告・相談を中心に。
全員で集まる時間を少なくし、接続するチームで集まる時間を増やした。
営業・CSの声もDrive Mapに反映した。
壁。
・権限のない中での影響力。DriveMapを実行するメンバーは部下ではない。
・開発文化の融合。What/Whyに責任を持ち、Howは開発に委ねた。
・組織構造の限界。PdMがチームに入ると自チーム最適になる。4月からPdM組織が組成。
トップダウンによりボトムアップが加速した。
・ミドルPMの自律性向上。
・若手PMの視野が拡大
・チーム間の対話が自然発生
1年の軌跡：聞く→体現する→描く・変える→組み替える→つなげる
学び
カオナビのエンジニア組織を本当に魅力的だと思っているため、PdM目線での話を楽しみにしていました。
その中で、改めていかにエンジニアリングを事業に近づけるかの重要性を学びました。
サイロを無くし、各チームが共通の目的を持って取り組むためのDrive Map。実際の姿を見てみたい。
トップダウンだからこそ、緊張感が生まれるといった話も学びになりました。
「SaaSの次の時代」に重要性を増すステークホルダーマネジメントの要諦 ～「解像度」を圧倒的に高めPdMの価値を最大化させる方法～
メモ
AIによって職種の境界が溶けて役割の再定義が必要になっている。
プロダクトマネージャーの役割
・プロダクト価値を創る。BizDev/PMMとの融合。
・プロダクトを創る。デザイナー・エンジニアとの融合。
SaaSバブルの崩壊。
生成AIで、より大きく、深く、複雑な構造的な課題を時に行く必然性が高まった。
「自社でSaaSプロダクトを開発する」以上のプロダクト戦略が必要になっている。
今のカケハシ：B2Bマルチサイドプラットフォーム、M&Aを組み合わせたプロダクト戦略
プロダクトの環境変化。
・シングルプロダクトの提供より、課題解決型に。
。顧客以外の関係者と文脈背景を理解することが重要。
何が変わるか？
2面の顧客＋多面的なステークホルダー調整
PdMの提供価値
構造を理解し、推進力の源泉（プロダクト含）を創る。
B2Bマルチサイドプラットフォーム。
・基盤となるプロダクトを創る。価値の源泉を裏に持つ。
・ステークホルダーマネジメント
・単体プロダクトではなく、課題解決するためにはどうするか？を起点に考える
重要なこと。
社内外のステークホルダーとの関係づくり：
協業が重要。BizDevとPdMび視点を統合したプロダクト戦略
プロダクト＋αの価値づくり：
複数プロダクトを連携した課題解決
ポイント。
背景・文化を大切にする。前提の違いからくるズレを把握する。
不確実性に対する考え方のずれが大きい。
プロジェクト推進：企業によっては「とりあえずやってみる」ことが文化面でネガティブに映る。
プロダクトゴール：理想からのバックキャストの精度、見せ方を大切にする。
ナレッジ差を考慮した役割分担：相手の体制に合わせた体制を組む。
生成AIを文脈理解に役立てる。ナレッジの言語化、企業同士の勝ち創出のための理解。
泥臭く解像度を高めていく。課題の核心をとらえる。
ステークホルダマネジメントの対象を、顧客だけではなく、関係するステークホルダーに拡大する。
学び
カオナビさんと同様に、カケハシさんのPdMのお話を楽しみにしていました。
AIが作ることを代替したからこそ、開発組織の役割が人段ずつあがったことを改めて理解しました。
そのうえで、プロダクトではなく、事業を見る重要性が増したイメージが持てました。
AIをものづくりの速度を上げるためではなく、深度を深めるために利用する。
そのうえで、人と人とのやり取りの泥臭さの上を根気強くやっていくことが重要と学びました。
AIが“作る”を民主化する時代、PdMは何で価値を出すのか（※オンライン対談）
メモ
最近の取り組み。
過去2年生成AIに取り組んできた。働き方や責任範囲が大きく変わった。
プロダクトを作る際の三つの大きな問題
・どの問題を解決したいのか、何に取り組むべきかを決めること（プロダクト戦略）
・他のすべての選択肢よりも自分の解決策を人々が選ぶほど優れたソリューションを考え出す必要がある（プロダクトディスカバリー）
・解決策を構築する（デリバリー）
生成AIはすべてに貢献しているが、特に構築に貢献している。
プロダクトチームにとって、プロダクトディスカバリーがボトルネックになる。
今までは開発者がボトルネックになっていた。ただ、問題ではなかった。
問題は常に、競合他社よりも優れた解決策を考えだすことにあった。
今まさにプロダクトディスカバリーが注目されている。
プロダクトには決定論的な従来型のプロダクトと、確率論的なAIプロダクトがある。
生成AIは特定のリスクに対して他の技術よりも効果的に対応することができる。
ただ、AIプロダクトはコストに対して利益をあげることは難しい。財務リスクがある。
確率的なプロダクトでも、確実に安全である必要もある。
確率的で、予測不可能なプロダクトと付き合っていく必要もある。
何よりAIプロダクトはAIプロダクトであるだけでは価値はない。
AIには価値リスクがつきまとう。
デリバリーのしやすさによってどんどんプロダクトは開発されている。
価値があると思っても、実際に価値が発揮される訳では無い。
依然としてプロダクトディスカバリーは重要となる。
プロダクトマネジメントには複数のモデルがある。
・アジャイルプロダクトオーナー型
アジャイルプロダクトオーナーは、主にデリバリーに関わる役割である。
ただし、生成AIはデリバリー支援をかなりの程度代替・加速できるようになっている。
そのため、単にスプリントやバックログ、デリバリーを管理するだけの役割は、今後価値が下がる可能性がある。
・プロジェクトモデル／機能チーム型
経営陣やステークホルダーが作る機能やロードマップの優先順位を決める。
PdMはそれをPRDや仕様書に落とし込み、デザイナーが体験を設計し、エンジニアが実装・テスト・デプロイを行う。
ただし、本当の意思決定はPdMではなく、経営陣やステークホルダーが行っている。
そのため、実態としてはプロダクトマネジメントではなく、プロジェクトマネジメントに近い。
このモデルではロードマップ上の多くの項目が成果につながらず、時間やお金を無駄にしやすい。
・プロダクトオペレーティングモデル
チームに「作る機能の一覧」が渡されるのではなく、解決すべき問題や達成すべき成果が与えられる。
チームは、その問題に対して顧客価値・技術的実現性・事業性を満たす解決策を探索する。
重要なのは、単に出荷することではなく、成果を出すこと。
必要に応じて何度もプロトタイプや機能を試しながら、顧客とビジネスにとって有効な解決策を見つけていく。
ボトルネックがエンジニアからディスカバリーに移行した以上、ディスカバリーに注力しないといけない。
だからこそ3つ目のモデルが重要となる。
・AIによって変わったこと
AIにより、誰でもプロトタイプや簡単なコード、モックアップを作成できるようになった。
PdM自身もAIや各種ツールを使ってプロトタイプを作れる。
これにより、プロダクトディスカバリーにおいて、チーム全員が「学ぶために作る」ことへ参加しやすくなった。
一方で、AIでプロトタイプを作れることと、本番運用に耐えるプロダクトを作れることは別。
プロトタイプは学習のために作るものであり、プロダクトは収益化や事業成果のために作るもの。
AIによって誰でもプロトタイプを作れるようになっても、デザイナー、エンジニア、PdMの専門性が不要になるわけではない。これらの専門性は、良い意思決定をするために必要。
・プロダクトセンスの重要性
AI時代におけるPdMの重要な責任として「プロダクトセンス」がある。
顧客、自社のデータ、ビジネスに対する深い理解のこと。
従来、新しく会社やチームに加わったPdMがこれらを理解し、一人前になるには3か月ほどかかっていた。
AIをプロダクトコーチとして活用すれば、この学習期間を短縮できる可能性がある。
AIは意思決定を代行するものではなく、意思決定を支援するものとして使うべき。
AIを「パーソナルプロダクトコーチ」として活用する。
AIプロダクトコーチを適切に設定すれば、PdMが顧客理解、事業理解、データ理解を深める支援ができる。
従来3か月かかっていた学習を、将来的には1か月程度まで短縮できる可能性がある。
ただし、AIプロダクトコーチを使う際には、前提となるモデルを明確にする必要がある。
言語モデルと、プロジェクトモデルやプロダクトモデルのようなプロダクト開発モデル。
この2つを混同すると、AIから的外れな助言が返ってくる可能性がある。
そのため、AIに対して「どのプロダクト開発モデルを前提にして考えてほしいのか」を明確に伝えることが重要。
AIによってUIや機能は簡単にコピーできるようになった。
そのため、真の競争優位は「速く作ること」や「機能を持っていること」だけではなくなる。
重要になるのは、顧客や事業を深く理解し、何を作るべきかを正しく判断する力。
プロダクトセンスと高品質な意思決定こそが競争優位になる。
AIはPdMを置き換えるものではなく、PdMのプロダクトセンスを育て、より良い意思決定を支援するためのコーチとして活用すべき。
また、プロダクトチームは「作る機能」ではなく、「解決すべき問題」や「達成すべき成果」に向き合う必要がある。
学び
私にとってマーティン・ケーガンさんとの出会いは現職に入社した頃でした。
『INSPIRED』の翻訳者のひとりである関満徳さんと一緒に働いたのがきっかけでした。
それ以来、時々マーティン・ケーガンさんの講演を聞いては刺激を頂いています。
今回、特に自分にとっての学びになったのは、プロダクトマネジメントのモデルの整理でした。
長くプロジェクトマネージャーとして稼働している自分にとって、プロダクトマネージャーと自分の違いの言語化が難しく感じていました。
個人評価としては、『デリバリー』はできるけど、『ディスカバリー』は素人、と考えていましたが、それはHOWの話であり、意思決定が自分ではなく経営陣やステークホルダーが近いと思いました。
また、AIがやってきても、本来果たすべき役割は果たし、いかにそのための精度や成長にAIを活用するかが重要ともイメージできました。
特にAIプロダクトコーチに対して、プロダクトの話なのか、プロジェクトの話なのか伝えることは、意識できていなかったため学びになりました。
「解決すべき問題」や「達成すべき成果」に向き合いたいです。
ブース
短い時間でしたが、いくつかのブースを回ることができました。
ニーリーさんのブースでてぃんおじさんとお話しできたことも嬉しかったです。
ニーリーさん！！#pdm_summit_findy pic.twitter.com/x48cAsro6u
— 幡ヶ谷亭直吉@文フリけ-44／多摩.dev／子育てMeetup／秦野アジャイル (@asagayanaoki) 2026年4月28日
PdEConferenceも今から楽しみです。
はじめての企業様のブースで、今まで知らなかったプロダクトのお話もお伺いすることができ、知見が広がりました。
くじ引きのためのスタンプは集められず退散しました。
感想
午前の途中のみの参加でしたが、とても刺激の大きい1日でした。
特に普段開発のお話を聞く企業様のプロダクトマネジメントの話は、別の角度からエンジニアリング組織を見ることができ楽しかったです。
改めてAIが作る部分を代替していく世界で、いかに意図を持って、その意図を組織全体で持ってプロダクト開発に取り組むことが重要かを学びました。
次回あれば1日通して参加したいです。
