AI時代のプロダクト組織を少人数にする前に、誰にリリース権限を渡すか

AI時代のプロダクト組織は、目標人数を決めるだけでは少人数で回らない。検索で上位に出る国内の記事の多くは「PMは不要になるか」「PMを増やすか、エンジニアにプロダクトの責任を寄せるか」を論じ、少人数化は人員の話として語られる。だが実際にPM2人・デザイナー1人で回っている会社の記録を読むと、その中心にあるのは人数ではなく、誰にリリースの権限を渡すかの線引きである。本稿はこの一点に絞る。

プロダクトチームは本当に4〜6人へ向かっているのか

向かっているという主張はある。だが人数だけを見ても、それで回る理由は分からない。

主張のほうから見る。30億人超が使うInstagramの責任者Adam Mosseriが出演したLenny’s Newsletterのポッドキャストの告知には、2026年にプロダクトチームの標準形が十数人の専門家チームから4〜6人のジェネラリストのポッドへ変わりつつある、という論点が挙がっている。PM・デザイン・データサイエンス・リサーチを1人のジェネラリストに混ぜた「プロダクトスタッフ」という役割の台頭も、同じ論点リストに並ぶ（プロダクトチームはなぜ4〜6人のジェネラリストポッドへ向かうのか ― Instagram責任者Mosseriの組織再設計論）。

この元記事の性質は書いておく。手元にあるのは告知と論点の見出しだけで、対談の本編は有料部分にあり読めていない。したがって、Instagramが実際にそう組み替えたのか、何人のポッドをいくつ持っているのかは、この告知からは分からない。言えるのは、Instagramの責任者との対談で「4〜6人」が論点として立てられた、というところまでである。

実数のほうは別の元記事にある。キャリア系ポッドキャストThe SkipのNikhyl Singhalが、3社のプロダクト責任者と対談した回の記事だ。MidjourneyのCPO Sharmeen Chapp、LaurelのCPO Jiaona Zhang（JZ）、Mutinyでプロダクトとデザインを率いるHenrik Berggrenである。3社のプロダクトチームは意図して小さく保たれている。MutinyはPM2人とデザイナー1人、Midjourneyは3人、Laurelはプロダクトとデザイン合わせて9人だ（PM2人でプロダクト組織は回るのか — Midjourney・Laurel・Mutiny に見る少人数体制の作り方）。

Singhalが念を押しているのは、これがAIネイティブの白紙のスタートアップではないという点である。3社とも数年の歴史を持ち、有料顧客とエンタープライズ契約を抱え、AIの波より前からいるチームを抱えている。制約のある会社が、意図してこの人数を選んでいる。

だとすれば問うべきは「何人か」ではない。この人数を選んで回すために、何を開いたのかである。

PMの役割は消えるのか、それとも変わるのか

消えるのは情報を運ぶ中継の仕事で、顧客の理解を全社に行き渡らせる仕事は残る。これはSinghalの整理であり、本稿もこの線で読む。

Singhalによれば、PMはかつて社内の問題を解くところから仕事を始めた。情報を動かし、プロセスを回し、組織の調整を保つ仕事である。これはAIで格段に容易になった。代わりに大きくなるのは社外の問題で、顧客基盤が大きくなるほど顧客を本当に知ることは年々難しくなる。そして彼は、PMが関門になっていたのは意図したことではなかったと書く。その時点の技術では、情報が1人を経由して流れるしかなかっただけだ、と。

MidjourneyのChappは、研究主導で、PMが必要かどうか自信のなかった会社に最初のプロダクト担当として入った。彼女が戻ったのは、顧客を誰よりも理解するというPMの最も古い原則だった。違うのはその先で、理解をPMが抱えるのではなく全社に開く。そのための仕組みが、エンジニアを同席させて週に数回行うユーザーとの通話である。

同じ向きの記述は、OpenAIの内側からも出ている。Creator EconomyのPeter Yangは、OpenAIでCodexのPMを務めるRohan Varmaとの回の要点として、Codexが情報の統合やフォローアップといったPMの手作業を引き受けるので、Varmaはエンタープライズ顧客やチームと会う時間が増えた、とまとめている（PM業務のどこまでをCodexに任せられるのか ― OpenAI現役PMの実践に見る「デモがPRDを置き換える」働き方）。これはVarma本人の発言ではなくYangの要点整理で、記事本文は要点の冒頭3項目で途切れている。

「PMは不要か」に近い問いを立てている人もいる。流通取引総額（GMV）80億ドル超のライブコマースWhatnotのCPO、Tom Verrilliとの回の告知には、Whatnotのプロダクトチームが「プロダクトマネジメントが存在することを残念に思う」という前提の上に作られた理由、そしてシニアIC（管理職ではない上級の個人貢献者）が自ら仕事を担う方向への移行が論点として並ぶ（AI 時代にプロダクトマネージャーは不要になるのか — Whatnot CPO の組織設計に学ぶ）。OpenAIでCodexのデスクトップアプリ開発を率いるAndrew Ambrosinoとの回の告知には、誰もが何でも作れるときにOpenAIのPMがどう動くかを説明する「ゾーンディフェンス」というモデル、チーム内で役割をどう崩しているか、そして役割という概念を丸ごと消すのは大きな間違いだという論点が挙がる。AIファーストの職場で最も価値のある能力として「taste」が浮上している、という論点も同じ回にある（AI時代にPMの役割はどう変わるのか ― OpenAI Codexリードが語る「taste」という評価軸）。この2本も告知だけで、ゾーンディフェンスやtasteの中身、Whatnotの前提がPM不要論なのかどうかは告知からは確認できない。

論拠の重さは揃っていない。Singhalの記事は3社の実践を書いた本編の要約で、YangとVerrilli・Ambrosinoの3本は要点の冒頭か論点の見出しにとどまる。それでも、ここで見た5本の範囲で言えるのは、中身を確認できる記述はどれも、PMの中継の仕事が軽くなり、顧客の理解を配る仕事に重心が移るという向きで書かれていることだ。

Singhalは、この顧客理解の中継を1つ目の関門と位置づけ、2つ目の関門を別に挙げている。作ること、つまりエンジニアリングの関門である。少人数化の本題はこちらにある。

作ることの関門を開いたあと、何が品質を守るのか

Singhalが置く原則は1つで、品質の守り方は会社ごとに分かれる。

かつては、顧客の問題がサポートや営業やPMから長い経路をたどってエンジニアリングの優先順位争いに入り、影響を受ける顧客の少ない問題は途中で消えた、とSinghalは書く。3社ではこの経路が短くなっている。Laurelでは、カスタマーサクセス担当者が顧客の問題を自分で理解して再現できたとき、管理画面の変更を24時間以内に本番へ出す。Mutinyではチームの誰もがCursorに顧客から報告されたバグの調査を頼め、MidjourneyではCPOのChapp自身が社内のエージェントに修正を頼んでいる。どちらも、出てきたプルリクエストはエンジニアがレビューする。

Singhalはこの仕組みを健全に保つ条件として、まず次の原則を置く。

“Shipping rights follow understanding, not availability”

（リリースの権限は、手が空いているかではなく、理解しているかに付いてくる。出典: Lenny’s Newsletter（The Skip のクロスポスト） by Nikhyl Singhal、2026-08-05）

関門を開いても、誰でも何でも出してよいことにはならない。権限は「理解」を条件に付く。もう1つの条件として彼は、これがコードベースの準備ができている場所でしか機能しないと書く。Laurelでは、JZがコードベースを庭の区画のように分けている。中核のエンジニアリングが再設計している区画には他の人は手を入れず、再設計を終えた管理画面は非エンジニアでも変更できる区画にした。カスタマーサクセスの24時間の変更はこの区画で出ている。

一方で、品質の守り方まで3社が揃っているわけではない。MutinyのBerggrenは、線に近づいていると知る唯一の方法はときどき線を踏み越えることだと語り、Mutinyはすべての変更の前にレビューを置くより、一部のリリースが磨き切らないまま出ることを受け入れている。Singhalはこれを、プロセス上の関門よりチームの回復力を取る選択として書いている。Midjourneyは逆に、継ぎ目が見えるまではほぼ調整なしで回し、いまはChappが「最も健全な量」のプロセスを足し戻している。チーム同士がぶつからなくなる程度で、誰の速度も落とさない程度の量だ。

ここから先は本稿の読みである。3社を並べると、作ることの関門を開いたあと、Singhalが一般論として置く「リリースの権限は理解に付く」という原則のもとで、品質の置き場所は違う。Laurelは誰がどこを触ってよいかを区画として先に決め、MutinyとMidjourneyはプルリクエストのレビューをエンジニアに残している。その先でMutinyはリリース前の関門を増やさずチームの回復力に任せ、Midjourneyは後から最小限のプロセスを足した。区画は3つの置き方のうちの1つであって、3社の共通解ではない。少人数で回るために経営が確かめるべきなのは、リリース権限を誰に渡せるかと、その人が触る面のコードベースが整っているかの両方だと読める。

自分の組織で最初に試すチームはどこか

人数を減らせそうなチームではなく、リリース権限を渡せる「理解している人」がPMの外にいて、その人が触る面のコードベースが整っているチームである。

Singhal自身が、3社の条件を限定している。3社はリードを広げ製品ラインを増やそうと競う成長企業で、勢いを守るために保守的に振る舞うより、強く押すほうが得るものが大きい。そのうえで彼はこう書く。

“at a larger company, the same playbook applies with the zones drawn tighter.”

（より大きな会社でも同じやり方は当てはまる。ただし区画をより狭く引くことになる。出典: Lenny’s Newsletter（The Skip のクロスポスト） by Nikhyl Singhal、2026-08-05）

この一文は、どこまで線に近づくかを論じた段落の末尾にある。ここでの zones がLaurelの庭の区画を指すのか、リスクを許す範囲を指すのかは、原文からは断定できない。本稿は前者に近い意味で読み、数百人のエンジニアと複数のプロダクトを抱える組織では、全社のコードベースを一度に塗り分けるのではなく、権限を渡せる面を1つ見つけてそこから始めるという手順に読み替える。

選ぶ条件は3つに整理できる。これは元記事の処方ではなく本稿の整理で、第一・第二の条件はLaurel 1社の例から組み立てたものであり、他社で成り立つかは確かめていない。第一に、PM以外に顧客の問題を自分で再現できる人がいる面であること。Laurelの例では、それが顧客の問題を自分で再現できるカスタマーサクセス担当者だった。第二に、その面のコードベースが整理されていること。Laurelのカスタマーサクセスが24時間で変更を出しているのは、再設計を終えた管理画面だった。第三に、変更がエンジニアのレビューを通る経路が残っていること。MutinyとMidjourneyでは、修正を頼むのがPMやCPOを含むチームの人であっても、プルリクエストのレビューはエンジニアが持っている。

逆に避けるべきは、目標人数を先に置いてPMを減らすことである。権限を渡す相手と、渡せるほど整った面が決まらないままPMを減らすと、中継の仕事は減っても、作ることの関門は開かないまま残る。問題は相変わらず優先順位争いの中で消え、人数だけが少なくなる。

なお、部署を再編すべきかという一段上の粒度の判断はAI活用は部署の再編を必要とするのか ― 海外の実装現場からで扱った。同論考が専任部署として切り出すべきだとしたのは権限設計や監査の機能であり、本稿が「理解している人」に渡すとしたのは、整理された面に限ったリリースの権限である。両者は衝突しない。本稿が扱ったのは、部署の下の単位、プロダクトチーム1つを何人で回すかである。

まとめ: 目標人数より先に、リリース権限の渡し先を決める

AI時代のプロダクト組織が4〜6人へ向かうという論点は、Instagramの責任者との対談でも立てられている。だが実数で語れるPM2人・デザイナー1人のMutiny、3人のMidjourney、9人のLaurelの記録が語る中心は、人数そのものではない。PMが中継していた顧客理解と作ることの関門を開いたことであり、Singhalはそこに、リリースの権限を手が空いている人ではなく理解している人に付けるという原則を置く。品質の守り方は、Laurelの区画、MutinyとMidjourneyのエンジニアによるレビュー、Midjourneyの最小限のプロセスと分かれており、1つの型には収まらない。次の組織計画でプロダクトチームの目標人数を置く前に経営が決めるべきは、リリース権限を渡せる理解している人がPMの外のどこにいて、その人が触る面のコードベースが整っているかを確かめ、最初の少人数化をその条件が揃う1チームで試すこと、その一点である。