Post
JA EN

PdM 不要論と FDE 躍進——AI が再編するソフトウェア組織の役割境界

Posted
By
41 min read
PdM 不要論と FDE 躍進——AI が再編するソフトウェア組織の役割境界
  • 想定読者： 自分の役割（PdM / SE / エンジニア / コンサル）の将来性を再評価したい人、FDE 採用を検討するスタートアップ、日本企業の SIer/受託で働くエンジニア
  • 前提知識： Web/SaaS の開発組織における PdM・エンジニア・SE の役割分担を知っていること
  • 所要時間： 約25分

概要

「AI で PdM は要らなくなる」「いや、AI でエンジニアが要らなくなる」——どちらの議論も、片方の職種を消す形で語られている。だが、実際に起きているのは 職種の消滅ではなく、役割境界の再編 だ。

中心仮説はシンプルだ。AI が実装コストを劇的に下げた結果、組織の「中間翻訳層」が剥落しつつある。顧客の曖昧な要望をエンジニアに伝わる形へ翻訳する作業、エンジニアの技術判断を顧客に伝わる形へ翻訳する作業——この翻訳機能が、AI 補助のあるエンジニアによって自力で吸収できるようになった。

その剥落分を吸収する形で躍進しているのが FDE（Forward Deployed Engineer） だ。顧客現場に embed してコンテキストを引き出し、その場でプロトタイプを作り、プロダクト判断まで行う——Palantir が 2008年以来育ててきたこのモデルが、Anthropic・OpenAI・Ramp など AI 時代の主要プレイヤーで一斉に採用されている。a16z が「テクノロジー業界で最もホットな仕事」と呼ぶほどに1。

ただし「PdM が消える」は雑な議論だ。剥落するのは要件翻訳機能だけで、戦略立案・優先順位付け・ステークホルダー調整・ロードマップ管理は残る。むしろ Andrew Ng は「実装が安くなった結果、何を作るかを決める人の需要が増す」と指摘し、エンジニアと PM の比率が逆転（従来 6:1 → 1:2）する可能性すら示唆している2。同じデータが「PdM 不要」と「PdM 増員」の両方向に解釈される——この一見矛盾する状況こそ、職種境界が引き直されている証拠だ。

本記事ではこの構図を、Palantir/OpenAI/Anthropic の FDE 採用実態、Marty Cagan の PdM 論、Coase の取引コスト理論という三層から検証する。最後に、日本企業の SIer 構造との温度差、そしてエンジニアの新しい moat がどこにあるかを論じる。

PdM の役割は消えるのか——剥落と残存を分離する

PdM 不要論の議論が雑になる原因は、PdM の役割を一枚岩として扱う ことにある。実際の PdM の仕事は、少なくとも次の5層に分解できる。

層内容AI 時代の状況
戦略・ビジョン「何のために作るか」を定義残存（むしろ重要性が増す）
優先順位付け限られたリソース配分の意思決定残存
要件翻訳顧客要望 → エンジニア向け仕様への変換剥落しつつある
ドキュメント化仕様書・スプリント計画・進捗管理剥落しつつある
ステークホルダー調整経営層・営業・サポート・顧客との連携残存

Marty Cagan は PdM の本質を「価値（value）と存続性（viability）に対する責任」と定義し、ビジョン・戦略・優先順位付けを中核業務として位置づけている3。この定義は AI 時代になっても揺らがない。

剥落しているのは、Cagan の言う中核業務ではなく、その周辺にこびりついていた 「翻訳・整理・ドキュメント化」という補助作業 だ。AI 補助のあるエンジニアは、顧客との対話ログから自力で要件を整理できる。スプリント計画も AI に下書きさせて自分で整える。この層は、もはや専任の翻訳者を必要としない。

ここで重要なのは、剥落と残存を混同しないことだ。「PdM 不要論」は剥落部分を見て言われ、「PdM 増員論」（Andrew Ng）は残存部分を見て言われている。同じデータの異なる側面を切り取っているにすぎない。

AI が実装を安くした瞬間、何が剥がれたか——中間翻訳層の構造的位置づけ

ソフトウェア産業はこれまで「実装が高価」を前提に役割分担してきた。エンジニアは貴重で稀少なリソースだから、その時間をコードに集中させるべき——だからこそ、要件を整理する人（PdM）、顧客と対話する人（営業・SE）、進捗を管理する人（PjM）といった 中間翻訳層 が分業として独立した。

実装コストが下がると、この前提が崩れる。AI 補助で実装効率が上がれば、エンジニア1人の生産性は上がる。すると 「エンジニアの時間を翻訳業務から守る」 という分業の経済合理性が薄れる。Stack Overflow の 2025年 Developer Survey では、開発者の 84% が AI ツールを使用または使用予定と回答している——AI 補助はもはや一部の早期採用者の話ではなく、業界標準だ4。

ただし、ここで誤解しやすい点がある。AI が翻訳作業そのものを完璧にこなしているわけではない。Stack Overflow の同じ調査では、開発者の 45% が「AI 生成コードのデバッグに時間がかかる」ことを最大の不満として挙げており、66% は「ほぼ正しいが完全ではない AI 出力」の修正に追加時間を費やしていると回答している5。

つまり起きているのは、

  1. AI が要件翻訳の「下書き」を作る
  2. AI 補助のあるエンジニアが顧客と直接対話し、その下書きを整える
  3. 結果として、独立した「翻訳専任者」を介する経済的メリットが薄れる

——という構造変化だ。翻訳作業がなくなったのではない。翻訳作業の担い手が「専任の中間層」から「エンジニア + AI」のペアに移っている のだ。

FDE の正体——Palantir 起点の「現場主義 × プロトタイプ主義」職種

この役割再編を体現するのが FDE だ。Palantir が 2008年に確立したこのモデルは、長らく「特殊な企業の特殊な職種」と見なされてきた。しかし AI 時代に入って、突如として業界標準へと拡散しつつある。

FDE の特徴は、従来分業されていた機能を一人格に統合する 点にある:

  • SE（Solutions Engineer）的機能: 顧客現場に常駐し、要件を引き出す
  • エンジニア的機能: その場でコードを書き、プロトタイプを作る
  • PdM 的機能: 何を作るか、どう優先順位付けするかを判断する
  • コンサル的機能: 顧客の業務プロセス変革まで踏み込む

Palantir の公式説明では、FDSE（Forward Deployed Software Engineer）は「顧客に embed して、Palantir の既存プラットフォームを構成し、顧客の最も困難な問題を解決する」と定義されている6。従来のエンジニアが「1つの機能を多くの顧客に提供する」のに対し、FDSE は「1人の顧客に多くの機能を提供する」——分業の軸が完全に逆転している。

Pragmatic Engineer の調査によれば、Palantir では 2016年頃まで、伝統的なソフトウェアエンジニアよりも FDE のほうが多かった1。これは「中間翻訳層を独立させない」という Palantir の組織設計が、長年にわたって機能していたことを示している。

そして 2024〜2025年、この設計が業界全体に拡散し始めた:

  • OpenAI: 2025年初頭に FDE 採用を開始。当初2名から、現在は8都市で10名以上に拡大1
  • Anthropic: Applied AI チームで FDE を積極採用。「戦略顧客に embed して、Claude を用いた本番アプリケーションを構築する」と職務記述7
  • Ramp: フィンテック企業として約15名の FDE をポッド体制で運用1
  • Salesforce、Commure、Matta、Gecko Robotics、Lindy など、業界横断で採用が拡大1

a16z が「最もホットな仕事」と呼んだのは誇張ではない1。少なくとも、AI 時代の最先端を走る企業群が、揃って FDE 型の組織設計に移行している。

なぜ Anthropic / OpenAI が FDE を主役に置くか——AI 時代の組織設計

ここで疑問が生じる。なぜ AI ベンダー自身が、FDE を中核職種に据えるのか。彼らこそ「AI が翻訳を担うから人間の介在は不要」と主張すべき立場ではないのか。

答えは、AI は質問できるが、暗黙知の重みづけはできない という構造的限界にある。

Anthropic の FDE 職務記述には「production experience with LLMs including advanced prompt engineering and agent development」が必須要件として挙げられている7。同時に「顧客環境で Anthropic の最高レベルの代表者として振る舞い、曖昧さの下で自律的に動くことが求められる」とも書かれている。

これは、AI を最も熟知している企業が、「LLM × 人間の現場判断」を統合した職種 を主役に置いている、ということだ。AI ベンダー自身が、AI だけでは顧客のコンテキストを完全には引き出せないと認めている——だからこそ、その役割を担う FDE に投資している。

Polanyi の有名な命題「we can know more than we can tell（語れる以上のことを我々は知っている）」8は、ここで再び効いてくる。顧客が真に必要としているものは、顧客自身が言語化できないことが多い。この暗黙知を観察・質問・痕跡から推測する作業は、現状の AI には独立してこなせない。だが AI 補助があれば、人間1人がより広い範囲を担当できる——FDE という統合人格が成立する経済的条件は、ここにある。

詳細は ITエンジニアが認識すべき5層のコンテキスト で論じたが、コンテキストには「顧客が当然と思っている前提」「業界固有の暗黙ルール」「組織内の政治力学」など、明示されない層が積み重なっている。FDE が躍進している理由は、AI が表層のコンテキストを処理できるようになった結果、深層のコンテキスト引き出しを担う人間の希少価値が相対的に上がった ことにある。

エンジニアの新しい moat——「実装速度」から「コンテキスト引き出し力」へ

ここから、エンジニア個人にとっての示唆が見えてくる。実装が安くなった世界では、エンジニアの moat（参入障壁・競合優位の源泉） は実装速度から別の場所へ移動する。

旧来の moat新しい moat
コードを速く書ける顧客の暗黙知を質問・観察・痕跡で言語化できる
アルゴリズムを多く知っているプロトタイプを介して仮説を検証できる
アーキテクチャを設計できるプロダクト判断・優先順位判断を自律的にできる
言語・フレームワークに精通AI に対する適切な指示と評価ができる
ドキュメントを丁寧に書けるステークホルダーとの直接対話で曖昧さを解消できる

ここで一つ留意点がある。Stack Overflow 2025 の調査で、AI ツールへの信頼度は 29% まで下がっている（前年比 11 ポイント減）4。実装を AI に委譲した結果、エンジニアは AI の出力を評価する側に回っている。この評価作業——コードレビュー、ハルシネーション検出、要件との突合——は依然として人間の専門性を要する。

つまり「実装スキルが要らなくなる」のではない。実装スキルは AI 出力を評価するための前提条件 として残り、その上に「コンテキスト引き出し」と「プロダクト判断」のスキルが積み重なる構図に変わるのだ。

詳細は 若手エンジニアのバイブコーディング生産性ガイド と AI委譲のパラドックス で論じたが、この変化は若手エンジニアにとって特にシビアだ。実装経験が浅いままで「コンテキスト引き出し」だけを身につけることは難しい——AI 出力を評価できないからだ。

PdM の生存戦略——剥落した翻訳機能を補う3つの方向

PdM 側の生存戦略はどうなるか。Marty Cagan が定義する PdM の中核業務3——戦略・優先順位付け・ステークホルダー調整——は残るが、剥落した翻訳機能の代わりに、別の何かで価値を出す必要がある。

主に3つの方向が考えられる:

戦略・ビジョンへの深化

「次に何を作るか」を決める判断は、AI でも FDE でも代替されにくい領域だ。市場分析、競合分析、顧客セグメント設計、長期ロードマップ——これらは複数年スパンの判断であり、現場での即興判断とは性質が異なる。FDE が現場の戦術判断を担うなら、PdM は組織全体の戦略判断にスケールアップする という分業が成立する。

ステークホルダー調整の深化

経営層・営業・サポート・法務・コンプライアンス・パートナー企業——複数の利害関係者を調整する作業は、FDE には荷が重い（顧客 embed の特性上、社内政治への帯域幅が限られる）。PdM が組織内の調整専門家として残る という方向もある。

数値・実験設計の深化

A/B テスト設計、コホート分析、リテンション設計——データドリブンな意思決定は依然として人間の判断を要する。AI に分析を委ねつつ、何を測るか・どう解釈するかを決める役割は残る。

ここで指摘しておきたいのは、この3方向はいずれも「PdM の上位機能」への深化 だということだ。剥落した翻訳機能を補おうとして「もっと丁寧に翻訳する」方向に行くと、AI 補助エンジニアとの差別化が効かない。逆に「戦略・調整・実験設計」という上位機能に振り切れば、FDE とも棲み分けができる。

日本企業の温度差——SIer 構造と FDE 化の摩擦

ここまで議論してきたのは、主に米国スタートアップの動向だ。日本企業、特に SIer・受託モデルの組織では、状況がかなり異なる。

日本企業の構造的特徴は次の3点にある:

  1. PdM 概念が浅い: そもそも「プロダクトを所有する人」という概念が、SIer/受託モデルでは育ちにくい。要件を出すのは顧客側で、SIer は「ただ作る人」の集合体になりがちだ
  2. 多重下請け構造: 元請け → 一次請け → 二次請け…と、翻訳層が何重にも積み重なっている。各層が翻訳機能で食っている
  3. 顧客側の要件定義能力が低い: 「要件を出せない顧客」は日本に多い。SIer 側がそれを翻訳してきた構造そのものが、AI 時代の再編に強い慣性を生む

この構造下では、FDE 化への移行は遅れる可能性が高い。特に「ただ作る人」のレイヤーは、AI 代替リスクが最も高い位置にある。実装が安くなった瞬間、「ただ作る」だけの仕事は——多重下請け構造のどこかで——剥がれていく。

一方で、日本企業にもチャンスはある。顧客現場との距離が近い SIer の文化は、本来 FDE 的役割と相性が良い。営業 SE が現場で要件を聞き、エンジニアが作る——この分業を「営業 SE + エンジニア + AI」の統合人格に再編できれば、米国スタートアップの FDE モデルに近づける。

ただし、その再編には組織側の覚悟が要る。多重下請けの中間層を整理し、現場エンジニアに権限と責任を集約する——これは日本企業の組織構造に対する深い変革だ。組織コンテキスト・エンジニアリング・ファースト で論じた組織側の理想形と、ここで議論する FDE 化は、深いところでつながっている。

Coase の取引コスト理論で読む役割境界

最後に、この再編を経済学の視点から読み直す。

Ronald Coase は 1937年の「The Nature of the Firm」で、企業の境界は取引コストによって決まる と論じた9。市場での取引コスト（情報探索・契約交渉・履行監視）が、組織内で同じ機能を担うコストより高ければ、その機能は企業内に内部化される。低ければ、市場（外注）に出される。

この理論を AI 時代の役割境界に応用すると、次のように読める:

  • AI が実装の取引コストを下げた: 「要件を伝える → 実装してもらう → 検収する」というプロセスのコストが下がった
  • だが、要件を引き出す取引コストは下がっていない: 顧客の暗黙知を言語化する作業は、依然として高い取引コストを伴う
  • 結果として、「要件引き出し」と「実装」を統合した職種が経済合理的になる: それが FDE だ

California Management Review の 2025年論文10は、この変化をさらに踏み込んで論じている。AI エージェントは内部の自動化コストを下げるが、同時に 外部プラットフォーム依存の取引コストを上げる。つまり「ある取引コストが下がると別の取引コストが上がる」というシーソー構造があり、組織はその変化に合わせて境界を引き直す必要がある。

FDE の躍進は、このシーソー構造の現れだ。実装の取引コストが下がった結果、相対的に高くなった「要件引き出しの取引コスト」を内部化する形で、職種が再編されている。

日本企業の SIer 構造も、Coase の理論で読み直せる。多重下請けは、かつての「実装の取引コスト」を下げるための分業構造だった。実装コストが AI で下がれば、その分業構造の経済合理性そのものが揺らぐ——これが、日本企業の SIer モデルが直面している構造的圧力の本質だ。

まとめ——中間層が剥がれた後の「コンテキストへの近さ」がすべて

AI が実装コストを下げたことで、ソフトウェア組織の役割境界が再編されている。職種が消えるのではなく、境界が引き直される。

整理すると:

  1. PdM の役割のうち、要件翻訳・ドキュメント化機能は剥落しつつある——AI 補助のあるエンジニアが自力で吸収する
  2. PdM の中核業務（戦略・優先順位付け・ステークホルダー調整）は残存——むしろ重要性が増す（Andrew Ng は「PdM 増員」を予測）
  3. FDE が剥落分を吸収する形で躍進——Palantir 起点、Anthropic / OpenAI / SaaS スタートアップに拡大
  4. エンジニアの新しい moat は「コンテキスト引き出し力」——実装速度ではなく、顧客の暗黙知を言語化する能力へ
  5. 日本企業の SIer モデルは慣性が強い——多重下請けの中間翻訳層は AI 時代の経済合理性を失いつつある
  6. 構造の本質は Coase 的——取引コストの変化が組織の境界を再編する自然な反応であり、AI 固有の現象ではない

ここから個人レベルで何が言えるか。「コンテキストへの近さ」がキャリア戦略の核になる、という一言に尽きる。

  • 顧客に近い場所で働く（FDE 的キャリアパス）
  • 暗黙知を言語化する技術を磨く（質問力・観察力・痕跡解読力）
  • AI を評価する側として、実装スキルを「土台」として保持する
  • PdM の上位機能（戦略・調整・実験設計）に深化するか、FDE 的統合人格を目指すか、自分のポジションを選び取る

親記事の コンテキストは自分で育てる で書いたのは「組織がコンテキストを供給しない前提でのサバイバル術」だった。本記事で論じたのは、その 逆の未来——AI がコンテキスト引き出しを補助し、現場との距離が組織設計の主軸になる時代 が来るとしたら、何が起きるかという話だ。

両者は矛盾しない。現状は「コンテキストが出てこない」のがデフォルトだが、その状況下で個人がコンテキストを育てる作法を身につけた人こそ、FDE 的な役割が標準になった時代に最も価値を発揮できる。今のサバイバル術が、未来の moat に直結する——これが本記事の最終的な示唆だ。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. What are Forward Deployed Engineers, and why are they so in demand? - Gergely Orosz, The Pragmatic Engineer (2025). FDE の歴史・採用動向・主要企業の実態を網羅的に整理した一次情報。a16z による「最もホットな仕事」評価、Palantir / OpenAI / Ramp の具体的人数も本記事から。【信頼性: 中〜高】 ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6

  2. Andrew Ng: Product Team Ratios Evolving to Just One Software Developer for Every Two Product Manager - HackerNoon (2025). Andrew Ng の発言を元にした分析記事。原典は Ng の X 投稿。【信頼性: 中】 ↩︎

  3. The Role of Product Management - Silicon Valley Product Group - Marty Cagan, SVPG. PdM の本来役割（価値・存続性、戦略、優先順位付け）に関する一次情報源。【信頼性: 中〜高】 ↩︎ ↩︎2

  4. Developers remain willing but reluctant to use AI: The 2025 Developer Survey results - Stack Overflow Blog (2025). AI ツール採用率（84%）、AI への信頼度（29%、前年比11ポイント減）の出典。【信頼性: 中〜高】 ↩︎ ↩︎2

  5. 2025 Stack Overflow Developer Survey: AI section - Stack Overflow (2025). 45% が「AI 生成コードのデバッグに時間がかかる」を最大の不満として挙げ、66% が「ほぼ正しいが完全ではない AI 出力」の修正に追加時間を費やしている、などの詳細データの出典。【信頼性: 中〜高】 ↩︎

  6. Palantir Technologies - Forward Deployed Software Engineer - Palantir 公式採用ページ. FDSE の役割定義の一次情報。【信頼性: 高】 ↩︎

  7. Forward Deployed Engineer, Applied AI - Anthropic - Anthropic 公式採用ページ. Anthropic の FDE 職務記述・必須要件の一次情報。【信頼性: 高】 ↩︎ ↩︎2

  8. The Tacit Dimension - Michael Polanyi (1966). 暗黙知の概念を確立した古典書。「we can know more than we can tell」の出典。【信頼性: 高】 ↩︎

  9. The Nature of the Firm - Ronald H. Coase, Economica (1937). 取引コスト理論と企業境界の関係を確立した古典論文。【信頼性: 高】 ↩︎

  10. From Coase to AI Agents: Why the Economics of the Firm Still Matters in the Age of Automation - California Management Review (2025). Coase 理論を AI エージェント時代に応用した最新の論考。【信頼性: 中〜高】 ↩︎

キャリア・働き方
FDE プロダクトマネジメント AI時代のキャリア 組織設計 役割再編
This post is licensed under CC BY 4.0 by the author.