Newbee株式会社 代表取締役／プロダクトマネージャー
蜂須賀 大貴
株式会社IMAGICAでエンジニアとしてキャリアを開始。フリーランスPMを経て株式会社サイカにて新規プロダクト戦略を牽引。PIVOT株式会社ではPM兼プロダクト組織の立ち上げを担う。2025年3月にNewbee株式会社を創業し、現在はテクノロジーメディア『Newbee』の運営や映像受託制作、外部CPOとして支援する。2026年7月22日に『勝てるプロダクト開発の教科書』（翔泳社）を発売。
2026年7月に翔泳社から刊行された『勝てるプロダクト開発の教科書』は、不思議な本です。
『プロダクト開発の教科書』と銘打ちながら、書いてあるのはマーケティング戦略や利用規約、社内外のステークホルダーとの協業といったプロダクトマネジメント。いわば、開発の“外側”にある工程のお話です。そして、プロダクトマネジメントがテーマの本なのに、想定読者は必ずしもプロダクトマネージャー（以下、PdM）ではない、といいます。
なぜこのような、ねじれを持った本が生まれたのでしょうか。
著者・蜂須賀大貴さんにお話を伺ってみると、AIの発展に伴って進むプロダクト開発のあり方の変化や、「プロダクトマネジメントの民主化」を踏まえて書かれた本とのこと。実装をAIが引き受ければ、人に残る仕事は開発の外側に寄っていく。プロダクトマネジメントも、PdMだけのものではなくなっていく。
つまりこの本が持つねじれは、プロダクト開発におけるAI以前／以後のねじれに応えるためのもの、というわけです。では、AI以後のプロダクト開発はどう変わり、これからの開発現場では何が求められるのか。蜂須賀さんが思い描くビジョンを伺いました。
『勝てるプロダクト開発』という書名で伝えたかった「プロダクトマネジメントの本質」
――まずは、『勝てるプロダクト開発の教科書』がどういう本なのかを教えてください。
蜂須賀：今までPdM向けの教科書的な本は、私の知っている限り2冊あるかなと思っています。プロダクト開発にフォーカスした『プロダクトマネジメントのすべて』と、SaaSビジネスにフォーカスした『ALL for SaaS』（ともに翔泳社）です。
そして、自分が本書の執筆のお話をいただいたとき、「3冊目の教科書として、今の世の中に足りないものは何だろう」と考えました。私自身、この2冊の教科書を読んできましたが、さらにPdMとして働くうえで必要だと思ったことは他の本を読んで補ってきました。そうして「さらにこういう情報があると良かったな」と思っていた部分を凝縮して、他の人が知識をショートカットできるようにしたいと思ったんです。
それが本書の内容です。実際のプロダクト開発やSaaSビジネスに限定されず、「PdMが実際にはやらなきゃいけない泥臭いこと」「周りのステークホルダーや別の部署の方々とどう協業して、どうビジネスを前に進めるか」を書きました。
市場選びや予算管理から始まって、人事戦略、エンジニアリング、体験設計、売り方、広報PR、最後は法務と知財まで。網羅性を重視して、プロダクト開発のさまざまなフェーズを全面的にカバーしています。
――本のタイトルは『PdMの教科書』ではなく、『勝てるプロダクト開発の教科書』。この「勝てる」は、どこから来たんでしょうか。
蜂須賀：その「勝てる」には、深い意味を込めています。とても強い表現なので、かなり悩んだんですけどね。読者からしたら、極端な話、「この本を読んで勝てなかったら返品保証してくれるんですか」というタイトルじゃないですか。
それでも「勝てる」をタイトルに入れたのは、「PdMに対するイメージの誤解を解きたい」という理由からです。
――どうつながるんですか？
蜂須賀：PdMは「エンジニアたちとコミュニケーションしてモノをつくる役割の人」「エンジニア組織の責任者」と見られることがよくあり、それが「PdMには、エンジニアリングのことしか分からない」という誤解につながっていると思います。
でも実際には、PdMには、プロダクトをつくる前とつくった後に「どう売れるものをつくるか」を考える役割がありますし、ステークホルダーと協力しながらマーケティング戦略や利用規約も考えます。
私が考えるPdMの本質的な仕事は、プロダクトをつくること自体ではなくて、プロダクトというHOWを使って、事業を勝たせる、会社を成長させることです。このニュアンスをいかに短い言葉で表現するかを考えた結果が、タイトルの「勝てる」という3文字なんです。
もはやプロダクトマネジメントはPdMの専売特許ではない
――「プロダクト開発」というよりは「開発の外側」にある仕事をして、プロダクトを成功に導くのがPdMの役割、というイメージでしょうか。
蜂須賀：そうですね。
本書の執筆にあたってもうひとつ悩んだのは、プロダクトマネジメントを担う役割を「PdM」と表現するかどうか。本書では、より広い定義にするために「プロダクト責任者」という言い方にしています。
世の中には「PdMと呼ばれてはいないけれども、実質的にはプロダクトマネジメントをやっている人」がたくさんいるんですよね。会社の立ち上げ初期は社長がプロダクトマネジメントしていることが多いですし、P&Gの「ブランドマネージャー」や、トヨタの「主査」もやっていることはPdMに近いと思います。
――「プロダクトマネジメントをする人＝PdM」ではない、と。
蜂須賀：もっと言うと、これからの時代、AIを使えばより多くの人がプロダクト開発をできるようになるでしょうし、また、AIによって職種の越境も進むと思います。その中で、プロダクトマネジメントに関わる人自体も増えていくのではないか、と。
それで、本書のテーマはプロダクトマネジメントなのですが、想定読者はPdMに限定せず「プロダクトマネジメントの知見を必要としている人全般」と置いています。
話がやや脱線するのですが、「AIが進化すると、ソロプレナーが現れる」という話がありますよね。
――AIと協働すれば1人でビジネスを進められるようになるだろう、というような話ですよね。
蜂須賀：ちょうどいま自分が一人企業のような状態なので、「あの話は本当なのかな。試してみようか」と思って、小さなプロダクトや社内ツールをつくってみました。
そうしたら確かに、AIを使ったら1人でできちゃったんですよ。話には聞いていましたが、実感として衝撃がありました。
「なぜ自分にはそんなことができたのか」と考えてみると、私にはPdMの経験があったからだと思います。顧客をリサーチして、プロダクトの仕様を考えて、プロダクトを開発して、デリバリーして、そこからマーケティングして……というようなビジネスの流れに一通り関わってきたので、どの工程の勘どころもある程度分かります。
しかし、プロダクトマネジメントの知見を持たないまま、同じことをしようとしたらどうなるか。「AIがあれば開発できる」と豪語しながら、いわゆる「高速でゴミを生み出す」のような状態になってしまうのではないか、と。そういう失敗を防ぐためにも、本書のようなプロダクトマネジメントについて網羅的に分かる本が必要だと思うんです。
「プロダクトマネジメントの民主化」以後、組織はどう変わる？
――AIが実装してくれる時代、人間に求められるスキルは何だと思いますか？
蜂須賀：これからの時代、実装よりも意思決定が人間の仕事になる、と言われています。そのために「ロジカルシンキング」「具体と抽象の行き来」「意思決定リテラシー」といったスキルが重要になるのではないでしょうか。
知識面でいうと、これまではエンジニアであれば言語やアーキテクチャ、EMであれば組織設計、というふうに役割ごとに限定されてきました。これからは役割の越境が進むことで、求められる知識の領域がプロダクトマネジメント全体、つまり「ビジネスで勝つための知識」にまで広がっていくのではないかと思います。
ただ私の考えでは、それでもプロダクトマネジメントという営み自体はなくなりません。
この本には、プロダクトマネジメントをするなかで関わるステークホルダーが10種類以上出てくるのですが、彼らとコラボレーションしながら仕事を進めていくということは今後も変わらないと思います。時代が進むなかで、コラボレーション相手が「人間9割、AI1割」から「AI9割、人間1割」のように比重が変わっていく可能性はありますが。
――それは「開発組織内の人は、ほぼPdMだけになるだろう」というような見方でしょうか？
蜂須賀：というよりは、「プロダクトマネジメントのスキルや仕事が民主化する」という感じでしょうか。「エンジニアが得るべきスキルが横に広がっていき、PdMに求められるスキルまで求められる」というようなイメージです。
そして、これは「PdMという職種がいらなくなる」という話でもあります。だって、プロダクトマネジメントのスキルを持つエンジニアがいるのであれば、それとは別にPdMを置く必要はないですよね。
私は「プロダクトマネジメントは残り続けるけれども、そのスキルは民主化され、PdMの専売特許ではなくなる」と考えていますし、すでにそうなっているような気もします。今年（2026年）あたりから、私の周りのシニアPdMやPdMのコーチ・アドバイザーが、PdMという職種に対しての興味を失ってきているように見えるんです。
――職種やそれに求められるスキルの考え方が大きく変わると、組織の考え方にも影響しそうです。この点はどう考えていますか？
蜂須賀：今後は「プロダクトサイドとビジネスサイドの境界がなく、よりコミュニケーションパスの少ない小さな組織にする」という方向性が強まっていくと思います。「PdM1人、エンジニア1人、CS1人、営業1人」で1チーム。それが社内にたくさんある、というイメージですね。
このようなチームにしたほうが、ビジネスを前に進めやすいと思うんです。組織の壁、役割の壁は溶けていったほうがいいでしょう。
たとえば、開発の中で「このページの表示は何秒以内にするか」を考えるときには、技術的に「何秒以内に表示できるか」だけでなく、ビジネス的に「ユーザーはこのページで何秒まで待てるか」も考える必要があります。
技術観点だけでは決められない問題なので、従来のプロダクト開発では、エンジニアは「ちょっとPdMに聞いてみます」や「PRDに書いてあるかどうかを確認します」という動き方をすることが多かったと思います。しかし、AIによって開発スピードが上がった今、こんなことをしていると人間がボトルネックになってしまいます。
――従来の組織のあり方では、意思決定に時間がかかりすぎる、と。
蜂須賀：はい。ですが、チームがプロダクトサイドとビジネスサイドに分かれておらず、CSなどの担当者が隣の席にいれば、エンジニアはすぐに確認・意思決定して、動けますよね。
また、営業のようなビジネスサイドの担当者も、バイブコーディングによってプロトタイプをつくることもできるようになりました。ただ、チーム間に垣根があると、エンジニアからのレビューを得るにも手間がかかってしまうと思います。
役割を溶かすための相互理解、溶かしてはいけないプロダクトの責任
――プロダクトマネジメントは民主化され、役割や組織の壁が溶けていく。こうなったとき、プロダクト責任者という役割はどうなると思いますか。
蜂須賀：もしも「全員が本当に同じ役割で、営業もやるし、PdM的な動きもやるし、エンジニアリング的な動きもやります」というチームがあったとしても、チームをリードする責任者は必要ですし、それは1人であるべきです。
プロダクト責任者を置かないとしたら、チーム内での合議制で開発を進めることになるでしょう。しかし正直なところ、そういうやり方で成長しているプロダクトは見たことがない気がします。合議制からは、イノベーションは生まれません。
――となると、蜂須賀さんが理想とするチームのかたちはどのようなものでしょうか。たとえば「プロダクト責任者を頂点と、その下に少人数のメンバーが集まるツリー型のチーム」に近いでしょうか？
蜂須賀：ツリー型ではなく、スター型ですね。
株式会社オンデーズ代表取締役・田中修治さんが話していたのですが、同社では「役職が上がったり、成果を残したりした人は『組織の上に行く』のではなく『中央に行く』」と考えるそうなんですね。より中心に行くことでやるべき仕事が大きくなり、巻き込む人が増えていく。そういうイメージです。
ビジネスサイドとプロダクトサイドを含む各メンバーが相互につながっていて、その中央にプロダクト責任者がいる。このような組織変革が進んでいくと思う一方で、ひとつ大きなハードルもあると思います。
――どんなハードルでしょうか。
蜂須賀：最初に、PdMに対するよくある誤解として「エンジニア組織の責任者」「エンジニアリングしか分からない人」というようなものがあると言いましたよね。
この手の誤解は、実は珍しくないと思うんですね。さまざまな職種間・部署間で、お互いがお互いのことを勘違いし、あまり口にはしないけれどもモヤモヤを抱えている。そのような環境では他部署とのコラボレーションは円滑に進まないでしょう。
そういったペインの解消に本書を使うならば、たとえば社内で輪読会をするときに「今日は社内のマーケティングチームを呼んで、マーケの章だけ輪読会しましょう」や「来週はPRの人を呼んで、PRの章を読みましょう」といった使い方ができると思います。
「ビジネスサイドとプロダクトサイドの間の垣根を取っ払い、営業・CS・PdM・エンジニアで小さなチームをつくろう」というような組織変革を進めるためにも、ぜひ相互理解を深めるための対話を重ねてほしいと思います。
取材・執筆：川島 昌樹
編集：川島 昌樹、田村 今人
撮影：曽川 拓哉
