フォワードデプロイドエンジニア（FDE）とは AI時代にエンジニアに求められる役割の変化
Microsoft、AWS、OpenAI、Anthropicが、2024年ごろから相次いでフォワードデプロイドエンジニア（Forward Deployed Engineer、以下FDE）の組織を設立・強化しています。この記事では、FDEとは何か、なぜ今この役割に注目が集まっているのかを整理します。
リモートワークが消したのは物理的な距離だけだった
リモートワークの普及によって、エンジニアと顧客の物理的な距離は縮まりました。一方で、技術とビジネスの間には別の距離が残っています。顧客の業務を理解して課題を定義する力と、それをシステムとして実装する力を両方持つ人材は多くありません。
FDEは、この埋まらない距離を1人で埋めにいく役割として位置づけられています。
FDEの起源：Palantirの前線配置戦略
FDEというモデルは、2003年設立のPalantir Technologiesが起点とされています。「forward deployment（前線展開）」という軍事用語に由来し、自社のエンジニアを顧客の現場に直接配置する戦略です。
Palantirの主要顧客は政府機関、警察、軍、医療機関など、業務の停止が許されない現場です。こうした現場では、ソフトウェアを導入するだけでは課題が解決せず、業務プロセスの再設計そのものが必要になります。Palantirは、開発拠点にとどまるのではなく顧客の隣で現場を変えるエンジニアを、FDEという役割として輩出してきました。
現場では、顧客のニーズ分析や現場の力学・業務理解を担う人材と、実装やデータパイプライン構築を担う人材が2人1組で動く体制が取られてきました。現在はDatabricks、Snowflake、OpenAI、Anthropicなども同様の体制を採用しているとされています。
各社の動き
2024年ごろから、大手各社がFDE組織の設立や強化を相次いで発表しています。
- Microsoft: 「フロンティアカンパニー」という組織を設立し、6,000人規模の配置を計画していると報じられています
- AWS: 自社内にFD部門を新設し、数千人規模の体制を計画していると発表されています
- OpenAI: FDE人材を擁する企業を買収し、その人材が合流したと報じられています
- Anthropic: 金融機関向けにFDE専任組織を設立したと報じられています
報道によれば、主要5社の関連投資・組織化の動きは、2ヶ月で合計1兆円を超える規模だとされています。
客先常駐・コンサル・カスタマーサクセスとの違い
FDEは、似たような形態を持つ他の職種とは役割の重心が異なります。
カスタマーサクセスは製品の導入支援が中心で、フィードバックはプロダクトやお願いベースにとどまります。コンサルティングは戦略立案が中心で、実装まで踏み込むことは多くありません。FDEはこの両方に加えて、自社製品を使って現場でその場に課題を解く実装力を持つ点が異なります。
従来型の客先常駐（SES）とも異なります。SESは労働集約型で、プログラミングやテストといった下流工程を中心とした契約労働です。FDEは知識集約型で、課題の明確化や業務プロセスの再設計といった上流工程に重点を置き、下流工程はAIで検証と実装を高速に回します。
| SES（客先常駐） | FDE | |
|---|---|---|
| 型 | 労働集約型 | 知識集約型 |
| 重心 | 下流工程（実装・テスト） | 上流工程（課題定義・業務設計） |
| 下流工程の扱い | 自分たちで対応 | AIで高速に検証・実装 |
| 契約形態 | 契約労働 | 少数精鋭 |
FDEを構成する4つの顔
FDEは、ソフトウェアエンジニア・コンサルタント・データサイエンティスト・プロジェクトマネージャーという4つの役割を兼ね備える人材と定義されます。
| 顔 | 役割 |
|---|---|
| コンサルタントの脳 | 顧客のビジネスモデルを理解し、最もインパクトが出る改善を設計する |
| データサイエンティストの目 | 現場に眠るデータの正体を見抜き、価値のあるインサイトを抽出する |
| 実装者の手 | 設計を絵に描いた餅にせず、その場で動くシステムとして実装する |
| PMの心 | 現場の抵抗に向き合い、人の感情を調整しながらプロジェクトを着地させる |
技術とビジネスの両方に踏み込むからこそ、この4つの顔が必要になります。
現場で回すサイクルと5つの必須スキル
FDEの1日は、次のようなサイクルで説明されています。
- 潜入・観察: 現場に入り、Excelでの手作業など、すでに顕在化している課題を見つける
- プロトタイプ開発: AIを使ってその場でデモや試作を作り、「朝から使える」状態にする
- 現場適用・反応確認: 現場に適用し、反応を見ながら利益が出るまで伴走する
- 改善・製品還元: 得られた知見をもとに改善を提案し、製品にも還元する
システムを納品して終わりにせず、現場そのものを変えることがFDEの本質だとされています。
このサイクルを回すには、次の5つの力が必要になります。
- 技術力: データベース・クラウド・ネットワーク・セキュリティなど幅広い知識と、顧客業務への理解
- マネジメント力: エンジニアリングマネージャーやソリューションアーキテクトが持つような、営業や現場との連携力
- 課題発見力: 部門ごとに異なる「本当の課題」を見抜き、仮説検証を高速に回す力
- 両立力: 顧客に深く入り込みながら、同時に全体の戦略を見失わない力
- 実装スピード: LLMツールを活用してプロトタイプを高速に形にする力
このうち両立力を持つ人材は特に少なく、まだ発展途上の領域だと語られています。
なぜ今、AIがFDEを後押ししているのか
従来のFDEモデルは、戦略を担う人材と実装を担う人材が2人1組で現場に入る体制でした。Claude CodeやGitHub Copilotのようなツールが実装作業を代行できるようになったことで、1人が担う作業のうちどれだけをAIに任せられるかが、この体制の効率を左右するようになっています。
AI以前は、課題定義や要件定義をコンサルタントやPMが担当し、エンジニアは「どう作るか（How）」に集中していれば十分でした。AIが実装を代行する前提に立つと、エンジニアの役割は「なぜ作るか（Why）」「何を作るか（What）」の定義に移っていきます。
- Why: 顧客自身もまだ言語化できていない狙いを対話から引き出し、事業上の意義に組み立てる
- What: 引き出した課題を実現可能な仕様に翻訳し、優先順位をつけてMVPを定義する
- How: AIに対して期待通りの実装をさせる
「言われた通りに作るエンジニア」ではなく「顧客と一緒にWhyとWhatを組み立てるエンジニア」に価値が移っている、というのがここでの見立てです。
何が難しいか
Claude CodeやCopilotを使っていても、実際に差がつくのはどのエージェントを使うかではなく、プロンプトの型やカスタムエージェントといった「仕組み」をどれだけ用意できるかにあります。この仕組み作りは自分だけで抱え込まず、チームで使い回せるロジックとして整備しておく必要があります。
また、打ち合わせを持ち帰って検討するよりも、その場でリアルタイムに図式化したり試作したりして、全員の認識を揃えながら進める場面が増えます。上流の提案書を書くだけで終わらせず、現場側の行動まで踏まえて動く必要がある分、負担は個人に集中しがちです。
淘汰されるエンジニア、選ばれ続けるエンジニア
要件定義書や設計書を書いて実装を下流に投げるエンジニア、決められた仕様通りに書くだけのエンジニアは、AIエージェントに置き換わりやすい領域から淘汰が始まるとされています。分業を前提にしたスキルほど、AIエージェントに置き換わりやすいためです。
一方、顧客の課題を理解し、その場で仮説検証しながら価値を素早く形にできるエンジニアは、これからも選ばれ続けると見られています。特定の技術スタックを持っていること自体は武器にならず、課題にどう向き合い、どう乗り越えてきたかという経験こそが差になります。
FDEは何人体制で動くのか
「開発チーム内のコミュニケーションコストより、AIに実装させて自分で見た方が早いのでは」という疑問はよく聞かれます。
現状は、リソースの制約から1案件1人でアサインされることが一般的です。資金力のある大手企業では2人1組や1案件4人といった体制を組めますが、そうでない場合は1人が担う負担が大きくなります。この負担をAIでどれだけ軽減できるかが、今後の課題になります。
まとめ
FDEは、課題定義・実装・運用・製品還元までを一気通貫で担うエンジニアです。2024年ごろからMicrosoft・AWS・OpenAI・Anthropicが相次いでFDE組織を設立・強化しており、国内でもAI企業がFDE的な職種をサービス化する動きが出ています。
AIが実装（How）を代行する時代になるほど、Why・Whatを顧客と一緒に定義できるエンジニアの価値が上がっていきます。上流・下流を分業するエンジニアから、経験のスピードをAIで上げながら一気通貫で動けるエンジニアへの移行が、これから進んでいくと考えられます。
社内でも、FDE的な立ち回りを実務で実践し、蓄積した経験値を共有していく取り組みを進めています。同じ課題意識をお持ちの方は、お気軽にKDDIアイレットへご相談ください。