はじめに
Web開発エンジニアの森山です。
先日、ファインディ株式会社主催の「Product Management Summit 2026」に参加しました。
ファインディ社にとってPM（プロダクトマネージャー）向けのイベント開催は今回が初めてとのこと。来場者646名、オンライン参加者を合わせると2,000名を超える大規模なカンファレンスでした。
エンジニアの自分がなぜPM向けのカンファレンスに参加したのか。
それは、AIの登場によりエンジニアの役割が変わってきていると感じていたからです。
本カンファレンスでも「エンジニアが職能を超えて協働するなど、価値を生み出すための組織の形が変わり始めている」という紹介があり、これからの仕事の形を知るためのヒントが得られると考え、参加しました。
この記事では、参加したセッションの中から特に印象に残った4つのセッションについてレポートします。
セッションレポート
1. AIが"作る"を民主化する時代、PdMは何で価値を出すのか
『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』の著者であるMarty Cagan（マーティ・ケイガン）氏と、ファインディ社の稲葉氏によるトークセッションです。あらかじめ書籍を読んでいたこともあり、話の文脈を理解しながら聴くことができました。
Cagan氏は「ここ2年は激動だった。PMの働き方、責任範囲が大きく変わった。」と語っていました。
ボトルネックは「プロダクトディスカバリー」
印象的だったのは「過去50年間、ボトルネックはエンジニアにあると考えられていた。開発コストを減らすことに価値があると。しかしそれは真実ではなく、他社よりも優れた解決策を考え出すことに価値があったのだ」という指摘です。AIにより開発コストが下がった今でも、この点は変わっていないとのこと。
つまり、AIで「作る」コストが下がったからこそ「何を作るか」「何を作らないか」の判断がより重要になっているということです。
PMのモデル
Cagan氏は成功するプロダクト開発のモデルについて提示しました。
プロダクトモデル: 構築すべき機能ではなく、解決すべき課題が与えられ、チームがそれを顧客に喜ばれる形で解決するモデル。組織の形。
これは、"プロジェクトモデル"と呼ばれる「経営陣やステークホルダーがロードマップや優先度を決め、それをPMが明確にし、エンジニアやデザイナーが設計する」モデルとは異なるものです。
シリコンバレーで成功しているのはこの「チームは機能ではなく、課題から解決策を考える」というモデルであり、「各自が責任を持ち、創造者であること」が求められるとのことでした。
余談ですが、こちらは"ランチ"セッションだったのでお弁当が配布されました。ありがたい！おかげでお昼を探す手間なく、エネルギーを補給した状態で午後のセッションにも集中して臨むことができました。
2. AI時代、誰がプロダクトの成果責任を持つのか
株式会社ログラスの、組織の構造を考える役割を持つ広瀬氏の視点で「責任と組織構造」について深掘りされたセッションでした。
「AIは責任を取れない」
「AIによりプロダクト開発は民主化された。しかし、意思決定・成果責任は分散できない」というメッセージが核となっていました。
エンジニアの立場でも、AIにより「課題発見、調査、情報整理、仮説検証」に関与しやすくなったと実感しています。しかし「責任・判断も各自ができるようになったか？」と問われると、答えはNoです。
これは開発にAIエージェントを使うようにしたときにも感じたことで、コードの生成は可能ですが、動作や取り込みの責任はエンジニア自身が持つ必要があります。この点は共感できる方が多いのではないでしょうか。
責任者が正しく判断できる組織構造を作る
印象的だったのは「責任者に業務を集めるのではなく、責任者が正しく判断できるように組織構造を変えること」という考え方です。
ログラス社では、横断機能（共通技術基盤、データ基盤、デザインシステム等）を整備することでプロダクト責任者の認知負荷を下げたり、業務内容によって組織構造を変える（責任者＋AIエージェント / 責任者＋各領域のエキスパート＋AI）といった取り組みを進めているとのことでした。
業務内容によって組織構造を変えるという発想は考えたことがなかったので、自社でも取り入れたい視点だと感じました。
📎 登壇資料: AI時代、誰がプロダクトの成果責任を持つのか
3. ABEMAにおける再現性のあるPM育成と評価のリアル
AbemaTV 開発チームのチーフプロダクトである田所氏による「AI時代でも成果を出し続けるためのPM育成・評価・素養」についてのセッションです。
「自分で考え、決めて、やる」
サイバーエージェント社の理念である「決断経験が人を育てる」をベースに「考える→決める→やる」の各フェーズをどう育成するかが語られました。
特に「考える→決める」フェーズでは 「分かる」ために「分ける」を徹底するというアプローチが紹介されました。
- 業務フローを整理：誰が、何を、どんな手順で行っているか
- WBS：全体像を漏れなく捉えて構造化する
- ユーザーファネル：ユーザーがどのようなステップを経て達成・離脱をしているのか
「分かる＝自分の言葉で説明できる」であり、OJTで都度分解し、フィードバックで考えを磨く。この繰り返しによって「AIのアウトプットの精査」もできるようになるとのことです。
「やる」は「一人でやる」ではない
次のフェーズである「自分でやる」については「一人でやる」ではなく「チームを巻き込んで進めること」が大切だと語られていました。
巻き込むために必要なのは「一緒に考えること」。そして相手への想像力と思いやりが作る信頼が好循環を生み出すという話は、PMに限らずあらゆる職種で重要なことだと感じました。
「情熱的な姿勢＋利他的であれ」というメッセージも印象的で、利己的な動機は周りに伝わるものだと共感しました。
📎 登壇資料: ABEMAにおける再現性のあるPM育成と評価のリアル
4. 生成AI時代のPdMは何を担う？
「PMを廃止した」という大胆な意思決定をした株式会社リチェルカの幸田氏のセッションです。
PM廃止の背景
従来、PMとエンジニアが連携してプロダクトを作るスタイルだったものの、スピードが遅い・想定と違うといった課題があったとのこと。2026年にPMを廃止し、代わりに「FDE（Forward Deployed Engineer）」という新しい役割を設けました。
FDEとは、誰よりも業務を理解して、As-Is/To-Beを描き、自分で開発をして課題を解決する人材です。顧客との要件定義から、プロダクトの要件仕様、仮説検証、プロトタイプ開発までを一人で担います。
「要件整理・資料作成だけのPMは不要」
「ロードマップの陳腐化」「スライドよりも動くものがほしい」「機能を作ることは価値ではなく、顧客の課題を解くことにしか価値はない」という言葉が刺さりました。
ランチセッションのCagan氏のセッションでも「プロダクトディスカバリーが重要」という話がありましたが、それを組織構造レベルで実践しているのがリチェルカ社の取り組みだと感じました。
求められるスキルとして「顧客理解力」と「技術力」の掛け算が重要であり、営業出身・コンサル出身・エンジニア出身、誰でも活躍できるとのこと。一方で「器用貧乏では深いペインに届かない。強みを軸にして越境できるか」という指摘もあり、エンジニアとしての専門性を持ちながら他領域に越境していく姿勢が求められるのだと理解しました。
📎 登壇資料: 生成AI時代のPdMは何を担う？ - Agentic ERPへの挑戦
企業ブースでの交流
セッション以外の楽しみもありました。
セッション会場の外ではスポンサー企業のブースがあり、実際に企業の方との交流や各社のプロダクトへの取り組みや考え方を直接聞くことができます。ブースを回るスタンプラリーも開催されており、集めると豪華プレゼントが当たるくじ引きに参加できました。
セッションで学びを得られるのはもちろんですが、交流もカンファレンス参加の醍醐味ですね！
カンファレンス全体を通しての感想
全セッションを通じて、共通して語られていたテーマがありました。
「責任」と「判断」はAIに代替できない
どのセッションでも繰り返し出てきたキーワードが「責任」でした。AIによりプロダクト開発は民主化され、誰もがプロトタイプを作れる時代になった。しかし、意思決定と成果責任は分散できない。「何を作るか」「何を作らないか」を判断し、その結果に責任を持つことこそが、AI時代に人間が担うべき役割です。
エンジニアの越境
PM向けのカンファレンスでしたが、エンジニアとして多くの学びがありました。AIの登場により職種の境界が曖昧になる中で、エンジニアもプロダクトの課題発見や仮説検証に関与しやすくなっています。技術力という専門性を軸にしながら、顧客理解やビジネス視点にも越境していくことが、これからのエンジニアには求められるのだと改めて感じました。
組織構造の重要性
優秀な個人に業務を集めるのではなく、正しく判断できるように組織の構造を工夫する。ログラス社やリチェルカ社の事例は、自社の組織を考えるうえでも参考になる視点でした。
おわりに
PM向けのカンファレンスということで最初は場違いかな？とも思いましたが、参加して良かったです。「AI時代にエンジニアの役割はどう変わるのか」という問いに対して、多くのヒントを得ることができました。
各社の内部の取り組みや組織構造の工夫を直接聞くことができるのもカンファレンスの良い点ですね。初めてのPM向けイベントとは思えない充実した内容でした。
オープンワークでは、エンジニアとして挑戦し続けたい方や、職種の枠を越えてプロダクトに向き合いたい方を歓迎しています。興味を持たれた方はぜひ採用サイトをチェックしてみてください！ www.openwork.co.jp
