PdM廃止は正解か？リチェルカの実験から元PdMが学んだ組織設計の本質

こんにちは、仕様書を書かないPM@カイです。元メガベンチャーPdM。今はAIに壁打ち相手・リサーチャー・ドキュメンターを任せて、PM業務の8割を自動化してます。

「PdMを廃止しました。」

この一文を見た瞬間、手が止まりました。

現役PdMのみなさん、正直に聞かせてください。「自分の役割、AIが出てきたあとも本当に必要なのか」——こう考えたこと、一度くらいはありますよね。

先日、Product Management Summit 2026の登壇資料を眺めていたら、あるスライドがその問いに真正面から答えていました。

しかも炎上狙いの言葉遊びではなく、組織設計とビジネスモデルがちゃんと整合している。「肩書きを変えただけ」でも「役割を統合しました」でもない。リレー型の組織構造そのものを破壊して、別のモデルに入れ替えていた。

この記事では、その事例を元PdMの視点で構造的に解剖します。

「PdMを廃止する」という決断は本当に正解なのか、自分たちの会社で真似できるのか、そしてAI時代のPdMが生き残るために何をすべきか——PM歴のある自分が、フレームワーク思考で正直に評価していきます。

「PdMを廃止しました」と言い切ったスタートアップが現れた件

まずは事件の全容から。何がどう「廃止」されたのか、正確に把握しておきましょう。

Product Management Summit 2026でリチェルカが発表した組織改革の概要

2026年4月28日に開催されたProduct Management Summit 2026で、株式会社リチェルカ（RECERQA Inc.）の共同創業者 取締役COO・幸田桃香（こうだ ももか）さんが登壇し、「PdMを廃止しました。」というタイトルで組織改革の事例を発表しました。

登壇資料はこちらです。

Product Management Summit 2026　リチェルカ登壇資料『PdMを廃止しました。』

本日、4/28（火）に「Product Management Summit 2026」に出展しました。 その中で取締役COO 幸田が登壇した際の資料の一部を公開します！

speakerdeck.com

リチェルカは2022年4月設立、シリーズAで17億円を調達したAI社会実装スタートアップです。

ミッションは「AIの社会実装を通じて、今までの『できない』を解決する」。

エンタープライズの受発注領域に特化していて、目標は「1社あたりARR平均1億円」と公表しています。

このスライドで衝撃だったのは、PdMという職種を本当に組織図から消した、という点です。

「役割を統合した」「肩書きを変えた」程度の話かと思ったんですが、よく読むと全然違います。

リレー型の組織構造そのものを破壊して、別のモデルに入れ替えていた。これ、何が変わったのかを理解するには、まず「廃止前」を知る必要があります。

創業時の組織設計——営業→PdM→エンジニアのリレー体制

廃止前のリチェルカは、世の中のtoB SaaSスタートアップによく似た組織でした。

具体的には、

• 営業が顧客のペインをヒアリング
• PdMがERPの業務フローを整理してユースケースを作成
• PdMがPRDを書いて仮説検証
• エンジニアが実装

という、典型的な「営業→PdM→エンジニア」のリレー型です。

自分が前職で5年間まさにこのリレーの真ん中にいたので、痛いほど分かります。

このプロセスが悪いわけではありません。業務フローを整理してPRDを書く工程はプロダクトの再現性を確保するうえで重要だし、エンジニアにいきなり生のお客様の声をぶつけても整理コストがかかる。PdMという中間職種は、組織が大きくなるほど合理的に機能します。

ただ、「エンタープライズ向け×後発SaaS×AI」という条件下では話が変わってくる。

ここでリチェルカは、自分たちの戦場では「リレー型では遅すぎる、深さが出ない」と判断したわけです。

「なぜそう判断したのか」——この問いに、めちゃくちゃ刺さる答えがありました。

なぜPdMを廃止したのか——「伝言ゲームでエンタープライズのペインが薄まる」

幸田さんが資料の中で言語化していたのが「伝言ゲームで薄まる」という表現でした。

PM経験者として、これは本当によく分かるんですよ。

エンタープライズ営業のペインは「深さ」が命です。

「業務システムの何画面目で、どのロールの人が、何分待たされていて、それで月いくらの損失が出ているか」というレベルまで掘らないと、AIで自動化しても刺さらない。

ところが、営業→PdM→エンジニアと情報が伝わる過程で、毎ホップごとに微妙に薄まります。

「重要だけど数値化しづらい」ニュアンスや、お客様の声の温度感が、PRDという形式知に落とすときに最初に削られるんですよ。

自分の経験でも、PRDに「業務効率を改善する」と書いた瞬間、議論が一気に抽象化して、現場の本当のペインから離れていく現象を何度も見ました。

「あの場でお客様が言っていたニュアンス、PRDに書けなかったな」と感じたことがある人には、この「伝言ゲームで薄まる」という言葉がすっと入ってくると思います。

リチェルカの「廃止」は、この情報損失を組織構造のレベルで断ち切る判断です。

PdMという呼称・職種を廃止して、各メンバーが自身の領域で「PdM・製品/機能責任者」としての責任を持つ構造にした。

新しい役割体系は次の4つです。

重要なのは、PdMの仕事をなくしたわけではない、という点です。

PdMの責任を「特定の職種」から「役割を持つ全員」に分散した。そして、その中核にFDE（Forward Deployed Engineer）という新しい役職を据えたわけです。

「そのFDEって、結局何者なんだ？」——次のセクションで詳しく解剖します。

FDE（Forward Deployed Engineer）とは何か——AI時代にPdMとどう違うのか

ここが、この事例で一番面白いところです。FDEという役割は「PdMとエンジニアを足して2で割った」ものではありません。設計の思想がそもそも違います。

FDEが持つ4つのケイパビリティ

FDE（Forward Deployed Engineer）は、リチェルカの定義によると「誰よりも業務を理解して、As-Is To-Beを描きながら、自分で開発してお客様の『できない』を解決する役割」とされています。

必要とされるスキルは4つ。

• ドメイン理解力
• 仮説構築力
• 実装力
• コミュニケーション力

PdMの仕事と何が違うのか、整理します。

ドメイン理解力と仮説構築力は、PdMの中核業務とほぼ同じです。業務理解とユースケース作成、As-Is/To-Beの整理は、PdMがやってきたことそのもの。

決定的な違いは「実装力」が入っていることです。

PdMは仕様まで書いて、実装はエンジニアに渡すのが普通でした。FDEは自分で書く。

つまり「お客様のペインを理解したその日に、動くものを作れる」んですよ。伝言ゲームが構造的に発生しない。これが、リチェルカが伝言問題を解決した核心です。

もうひとつ、「コミュニケーション力」が単独のケイパビリティとして並んでいる点も重要です。

リチェルカの整理によると、FDEはPdM・エンジニア・営業それぞれとこう差別化されています。

• PMより「自分でコードを書ける／モックを開発し、語れる」
• エンジニアより「お客様と直接話して仮説を構築できる」
• PdMより「お客様が課題を解決することに責任を持つ／1社に深く入り込む」

要するに、エンタープライズ案件における「業務理解 × 実装 × 顧客折衝」を一人で完結させる役割です。

「そんな人材、本当にいるの？」と思いますよね。実は、これはリチェルカが発明した概念ではありません。

PalantirからOpenAI、LayerXへ——FDEモデルが日本で広がる理由

FDEという職種、リチェルカが発明したわけではありません。

元々はPalantirが2010年代から運用してきた職種で、防衛・金融・製造業のクライアント先に常駐し、データ統合と業務アプリ開発を一気通貫でやるエンジニアを指しました。

直近では、OpenAIが東京拠点でForward Deployed Engineerの採用を開始しています。

日本の事例で言えば、LayerXが「日本版Palantirモデル」としてFDE+DS（Deployment Strategist）のペア体制を公表していて、こちらは@LayerXが実践する「日本版Palantirモデル」FDE/DSの役割・KPI・組織設計 - ALL STAR SAAS BLOGで詳しく解説されています。

Palantir発→OpenAI採用→LayerXとリチェルカが日本で実装。これが「発明」ではなく「潮流」だと分かると、この組織設計が持つ重みが変わってきますよね。

「中間職種を経由せず、業務に深く入り込んで開発まで完結する人材を置く」という設計思想が、AI時代のエンタープライズ攻略の最適解になりつつあります。

「営業×コンサル×開発」の掛け算がAI時代に強い理由

幸田さんの登壇資料で印象的だったのが、求められるケイパビリティを「営業力 × コンサル力 × 開発力」の掛け算として表現していた点です。

「全部できる必要はないが、何かが突出して強くないと辛い」とも書かれていました。

AI時代の人材論として、これは完璧に正しいと思ってます。理由は2つです。

ひとつ目は、単一スキルがAIに代替されやすくなったから。PRD作成だけ、競合分析だけ、議事録だけ、という単機能はAIで秒で出せます。「PRDが書ける」だけのPdMは、もう市場価値を維持できない。

ふたつ目は、複数スキルの掛け算は文脈が必要だから。営業の現場で得たペインを、コンサル思考で構造化して、開発の手段で解く。この一連のフローは、AIが補助はできても、判断と統合は人間がやる必要があります。

リチェルカが「越境する意志が必要」と言っているのは、まさにこの統合判断の話です。

カイの持論ですが、AI時代のPMは「ひとつの専門性 × AIで補強した他領域」という構造で生き残ります。

PM × エンジニアリング、PM × デザイン、PM × ドメイン特化——こういった掛け算をAIで実装できる人が、これからの時代に強い。

ただ、ここで一度立ち止まりたいんです。この設計、本当に正解なんでしょうか。元PdMとして、懸念点を正直に言います。

元PdMとして正直に評価する——リチェルカの「PdM廃止」は正解か

「すごい」と「うちで使える」は別の話です。ここは感情を抜きにして、構造的に評価します。

PdMがいなくなって困ること——伝言ゲームの代わりに何が起きるか

リチェルカの判断には構造的妥当性があります。一方で、PdM経験者として懸念点も正直に書きます。

PdMが消えると、必ず「結局誰が決めるのか」問題が出てくるんですよ。

新しい役割体系では、各メンバーが「PdM・製品/機能責任者」として責任を持つとされています。美しい話ですが、実務だと厄介な瞬間があります。

たとえば、

• クライアントAの要望とクライアントBの要望が矛盾する
• 機能の優先順位がチーム間で割れる
• ロードマップ上、どの案件を後回しにするか決めないといけない

こういうTrade-offの判断は、誰か一人が責任を持って決める仕組みがないと、合意形成のコストが爆発します。

PdMという職種の最大の機能は、実は「製品全体に責任を持つ単一窓口」を組織に設置することだったんですよ。

リチェルカの場合、おそらく代表やCOOがその最終決定を担っているはずで、創業期の少人数組織だから機能しています。組織が30人、50人、100人と拡大したとき、同じ構造で回るかは正直まだ未知数です。

AI時代に「仲介する職種」が消えていく構造的理由

ただし、リチェルカの判断には大きな構造的妥当性があります。

それは、AI時代に「仲介する職種」全般の付加価値が下がっているという事実です。

PdMの仕事の多くは、突き詰めると「翻訳・要約・整理」です。

• 営業の声を仕様に翻訳する
• ユーザーインタビューを要約する
• 散らばった要望をロードマップに整理する

これらは、生成AIが圧倒的に速く・安くこなせる領域に入ってきました。

自分自身、PRD1本に丸2日かかっていたのが、AIと壁打ちしながら半日で仕上がるようになっています。

同じ構造変化は、PdM以外の「仲介職種」にも起きていて、

• システムインテグレーターのSE
• 戦略コンサルのジュニア層
• 編集者・ライター
• 翻訳者

このあたりが軒並み「仲介の付加価値が縮小する」局面に入っています。

リチェルカの判断は、この構造変化を組織設計のレベルで先取りした、と評価できます。

「PdMという中間レイヤーを置かず、ドメインを深く知る人が直接作る」のがAI時代の最適解だ、という賭けです。

全スタートアップで真似できるわけではない——前提条件を整理する

ここが一番重要です。リチェルカの「PdM廃止」をそのまま自社に持ち込むのは危険です。

成立する前提条件が3つあります。

条件1: 顧客が極めて少数のエンタープライズ

リチェルカのターゲットは「1社あたりARR平均1億円」のエンタープライズです。

顧客社数が少なく、1社あたりの単価が高いから、FDEが1社に深く入り込む構造が経済的に成立する。B2C SaaSや、SMB大量獲得モデルだと、同じ構造ではROIが合いません。

条件2: 創業期で意思決定者が現役プレイヤー

PdMの最終意思決定機能を、創業者やCOOが直接担える組織サイズであることが前提です。

社員100人を超えると、誰かが「製品全体の単一窓口」をやらないと、ロードマップ調整が崩壊します。

条件3: メンバーがT字型人材

「営業×コンサル×開発」の掛け算ができる人を採用・育成できる前提があります。

エンジニアがそのまま顧客折衝できる、コンサルがそのまま実装できる、というT字型人材は、採用市場でも本当に希少です。

成熟SaaS、大企業、レガシー業界DXの組織で同じことをやろうとすると、たいてい3つの条件のどれかで詰まります。

リチェルカの事例は「正解」というより、「特定の前提条件下での最適解」と捉えるべきです。

では、自分たちが今すぐできることは何か——ここが本題です。

AI時代のPdMが生き残るために今すぐやるべきこと

「うちはリチェルカじゃない」とすれば、現役PdMが今すぐ取れるアクションは何か。ここからは具体的な話をします。

PdM業務のどこがAIに代替され、どこが残るか

まずPdM業務の棚卸しから始めます。

AIに代替されやすい業務は次のあたりです。

• PRDの整形・テンプレート埋め
• 競合プロダクト調査と機能比較表の作成
• 議事録作成と要点抽出
• ユースケース整理・As-Is/To-Be図化
• 仕様書のレビューコメント整理

正直、PdM業務の50〜60%はこのカテゴリーです。

逆に、AIに代替されにくい業務はこちら。

• ステークホルダー間のTrade-off判断
• 戦略的な優先順位づけ
• ユーザーの声のニュアンス解釈
• 組織内政治と合意形成
• プロダクトの最終的な責任を負うこと

意思決定とコミュニケーションの中核は、当面AIには渡せません。

PdMの生存戦略はシンプルです。

「代替されやすい50%をAIに渡し、代替されにくい50%に時間と頭を集中する」

これだけです。

「仕様書を書く仕事」から「AIで壁打ちして仮説を作る仕事」へ

自分の口癖、「それ、AIに壁打ちした？」は、PdM業務の根本的な作業観の変化を表しています。

以前のPdMは「仕様書を書く人」でした。

これからのPdMは「AIで壁打ちして仮説を作る人」です。

仕様書を書かない、という意味は「仕様を持たない」ではなく、「仕様書に時間を使わない状態を作る」ということ。

具体的には、ユーザーインタビューをした直後にAIへ素早く投げて、仮説を一気に広げる。その中から、自分の経験と勘で「これは筋がいい」というものを選び抜く。選んだ仮説について、改めてAIに「反対意見」「弱点」「想定リスク」を出させて潰し込む。ここまでやってから、PRDの骨子を書き始める。

参考に、自分が実際に使っている「壁打ちプロンプト」をひとつ無料公開しますね。

あなたは経験豊富なシニアPMです。
以下のユーザー課題に対して、3つの異なる解決アプローチを提案してください。

【ユーザー課題】
[ここにペインを書く。例：エンタープライズ顧客が、社内システムの承認画面で月平均8時間の待ち時間を発生させている]

【制約条件】
- エンジニア2名・3ヶ月以内で実装可能
- 既存の認証基盤は変更しない
- ROIは1年以内に黒字化

【出力フォーマット】
各アプローチについて、以下の構造で記述：
1. アプローチの概要（100字）
2. 解決される本質的な課題（100字）
3. リスク・反対意見（100字）
4. KPI候補（3つ）

最後に、3つのアプローチを比較する表を出力してください。

これをClaude / ChatGPT / Geminiに投げると、PRDのたたき台が10分で揃います。

ただし、出力をそのまま使ってはいけません。

ユーザーの声のニュアンスは、自分で必ず補正する。特に「ペインの深さ」と「実現可能性」はAIが過大評価する傾向があるので、現場で得た一次情報で必ず上書きします。

5年PdMをやってきた経験が、そのまま「AIへの指示力」に転換される感覚があります。

書ける人が、書かなくなった——これがいまのPdMの実態だと思っています。

「じゃあ、具体的に何をどう自動化しているのか」を、次のセクションで全部出します。

PdM業務の8割をAIで自動化したカイの実践

ここまで読んでいただいた方は、AI時代のPdMが向かうべき方向性は把握できているはずです。

「仲介職種としての役割は薄まる」「意思決定とコミュニケーションに集中する」「壁打ちプロンプトでユーザーの声を仮説化する」。

この方向性を「自分の業務で明日から動かす」には、もう一段具体的な実装が必要です。

有料エリアで公開するのは、自分が実際にPdM業務の8割を自動化した3つのワークフロー——PRD自動生成・競合分析パイプライン・ユーザーインタビュー要約——とそのままコピペで使えるプロンプトテンプレートのセットです。

PMコーチング1回50,000円、PRD作成代行1本100,000円という相場の世界で、自分が実際に使い込んできた実装を、失敗例ごとすべて公開します。

「ここは自分も代替できそうだ」と感じた業務が一つでもあったなら、その直感を実装に変えにきてください。

カイがPdM業務の8割を自動化した3つのワークフロー

ここから、自分が現役PdMだった時代に組み上げて、今も毎週使い続けているAIワークフロー3つを公開します。

ワークフロー1: PRD自動生成（旧2日 → 現在3時間）

まずユーザーインタビューの逐語録をテキストでAIに投入し、Jobs to be Done形式でペインを構造化させます。

次に、出てきたペインを「壁打ちプロンプト」（無料エリアで公開したもの）に通して3つの解決アプローチを生成。

そこから自分が一つ選んで、Claudeに「以下のテンプレート構造でPRDを書いてください」と指示します。

テンプレート構造はこちら。

1. 解決する課題（Why）
2. ターゲットユーザーとペルソナ
3. ユーザーストーリー（最低3つ）
4. 機能要件（Must / Should / Could / Won't）
5. 非機能要件（性能・セキュリティ・運用）
6. 成功指標（北極星指標 + サブKPI3つ）
7. リリース計画（Phase 1〜3）
8. リスクと対策

ポイントは、AIが書いた1〜5を必ず自分で読み直して、「ペインの深さ」と「ユーザーストーリーの粒度」を補正すること。

ここの補正に1時間使うのが、PRDの品質を決めます。

ワークフロー2: 競合分析パイプライン

競合5〜10社のWebサイトURLをClaude Codeに投げて、決まったフォーマットで機能比較表を生成させています。

具体的には次の手順。

1. 競合のプロダクトページ・料金ページ・公式ドキュメントのURLをリストアップ
2. Claude Codeに「以下のURLを巡回して、機能・価格・ターゲット・差別化ポイントを表で整理してください」と指示
3. 出力されたMarkdownの表を、Notionに貼り付ける
4. 自分が「強み・弱み・自社との差別化軸」のコメントを各行に追記する

3時間かかっていた競合分析が、30分で終わります。

注意点がひとつあります。

AIは公式サイトの謳い文句をそのまま拾うので、「実際の使用感」は反映されない。ここは、自分でトライアル登録して触る、もしくはX（旧Twitter）でユーザーの本音を検索して補強します。

ワークフロー3: ユーザーインタビュー要約

これが一番時間が浮きました。

90分のインタビューを文字起こしすると、A4で30ページ近くなります。

これを毎回読み込んで要点を抜き出していたら、PMの時間がいくらあっても足りない。

自分のフローはこうです。

1. インタビューをZoom録画 → Whisperで文字起こし
2. 文字起こしをClaudeに投入し、以下のフォーマットで要約させる

• ユーザーの抱える課題（Top 3）
• 現在の代替手段
• 望ましい解決状態
• 印象的な発言（生のまま3つ）

1. 「印象的な発言」だけは原文ママで残す（ここが仮説の種になる）
2. 5名分のインタビューを横串で比較し、共通課題を抽出させる

「印象的な発言を生のまま残す」がコツです。AIに要約させると一番大事なニュアンスが消えるんですよ。

失敗例: AIが作ったPRDをそのまま出して炎上した話

最後に正直な失敗例を。

ある時期、ワークフロー1でAIが生成したPRDを、自分の補正を省略してエンジニアにそのまま渡したことがあります。

結果、「ユーザーストーリーが現場感ゼロ」「成功指標が抽象的すぎる」とエンジニアからボロクソ言われて、信頼を一回落としました。

教訓: AIが書いたものを「最後に必ず読み直む」工程を絶対に省かない。

PMの仕事はAI出力の検閲者だ、くらいの感覚でちょうどいいです。

明日から使えるテンプレート1セット

この記事の有料エリアで紹介した3ワークフロー全部に対応するプロンプトテンプレートを、コピペで使える形で置いておきます。

# PRD生成プロンプト（ワークフロー1）
あなたはシニアPMです。以下の入力からPRDを生成してください。
【ユーザーインタビュー要約】[入力]
【選定した解決アプローチ】[入力]
出力構造: 解決する課題 / ターゲットユーザー / ユーザーストーリー / 機能要件（MoSCoW） / 非機能要件 / 成功指標 / リリース計画 / リスクと対策

# 競合分析プロンプト（ワークフロー2）
以下のURLを巡回して、機能・価格・ターゲット・差別化ポイントを表で整理してください。
【URLリスト】[入力]
出力: Markdown表形式 / 列は「サービス名 / 主要機能 / 価格帯 / ターゲット / 強み / 弱み」

# インタビュー要約プロンプト（ワークフロー3）
以下のインタビュー文字起こしを要約してください。
【文字起こし】[入力]
出力構造:
- ユーザーの抱える課題 Top 3
- 現在の代替手段
- 望ましい解決状態
- 印象的な発言3つ（必ず原文ママ）

このテンプレートを、自分のプロダクト・組織に合わせてカスタマイズしてください。

最後にもう一度。

PMの仕事の核は意思決定です。

AIに渡せる作業をすべて渡しきって、意思決定とユーザーへの責任に時間を集中する。

これがAI時代のPMが生き残る、唯一にして最大の戦略だと自分は思ってます。