FDEとは何か：フルスタックエンジニア、FDSE、アジャイル開発との違い

外資系AI企業を中心に、最近よく目にするようになった職種にFDEがあります。

直訳すると「前方展開されたエンジニア」のような意味になります。

もう少し自然に言えば、顧客の現場に入り込み、課題を理解し、技術で解決策を作り、本番利用まで持っていくエンジニアです。

最近はOpenAIやAnthropicのようなAI企業でもFDEの採用が出ており、日本でもSNS上で話題になることが増えています。OpenAIのTokyo FDE求人では、FDEは戦略顧客とともに、発見、技術スコープ、システム設計、構築、本番展開までを担い、成功を本番利用・業務インパクト・評価フィードバックで測る役割として説明されています。(OpenAI)

一方で、Palantirでは以前からFDSEという職種が有名です。
FDSEは、Forward Deployed Software Engineerの略です。

PalantirはFDSEについて、単なる職種名ではなく「blueprint」、つまり設計思想や型に近いものだと説明しています。優秀なエンジニアを顧客現場に直接入り込ませ、顧客の重要課題を正面から解く役割です。(Lever)

では、FDEとは役割なのでしょうか。
それとも組織なのでしょうか。

フルスタックエンジニアとは何が違うのでしょうか。
従来のスクラム型開発におけるPM＋エンジニアとは、どこが違うのでしょうか。
そして、FDEはアジャイル開発の延長なのか、それともアジャイル開発を超えた何かなのか。

ここを整理しないと、日本企業がFDEを導入する時に、かなり誤解が起きると思います。

まず、FDEは基本的には役割・職種です。

顧客の現場に入り、業務課題を理解し、技術的な解決策を設計し、実装し、本番利用まで持っていく。

これがFDEの基本的な役割です。

ただし、企業によってはFDEを個人の職種としてだけではなく、Forward Deployed Engineeringチームのような組織として持っている場合もあります。

​つまりFDEは、以下の3つの意味を持っています。

ここで重要なのは、FDEは単なる「開発職」ではないということです。

もちろんコードは書きます。
システム設計もします。
しかし、それだけではありません。

顧客が何に困っているのか。
その課題は本当にAIやソフトウェアで解くべきなのか。
どの業務から着手すれば成果が出るのか。
どのデータを使えばよいのか。
セキュリティやガバナンス上の制約は何か。
どうすればPoCで終わらず、本番で使われるのか。

こうした問いに向き合うのがFDEです。

その意味で、FDEはエンジニアリング、コンサルティング、プロダクト導入、顧客成功の交差点にいる役割だと言えます。

FDEと似た言葉に、FDSEがあります。

FDSEは、Forward Deployed Software Engineerです。
FDEは、Forward Deployed Engineerです。

違いを簡単に言うと、FDSEはFDEの一種と考えるとわかりやすいです。

PalantirのFDSEは、顧客の現場に入り込み、顧客の重要課題をソフトウェアとして解く役割です。
一方で、OpenAIやAnthropicのFDEは、AIモデルやAIプロダクトを顧客環境に導入し、本番利用や業務成果まで持っていく役割として説明されています。AnthropicのFDE求人でも、Claudeを使った本番アプリケーション、MCPサーバー、サブエージェント、Agent Skillsなどを顧客環境で構築し、プロダクトやエンジニアリングチームへ知見を戻す役割が示されています。(Anthropic)

つまり、FDSEはソフトウェア実装に強く寄ったFDE。
FDEは、AI、データ、プロダクト導入、業務変革まで含む広めの概念。

この理解が一番自然だと思います。

では、FDEやFDSEは、フルスタックエンジニアと何が違うのでしょうか。

フルスタックエンジニアは、フロントエンド、バックエンド、データベース、API、インフラなどを横断して開発できるエンジニアです。

一言で言えば、広く作れるエンジニアです。

一方で、FDEやFDSEは、作れるだけでは足りません。
顧客の現場に入り、何を作るべきかを見極め、作ったものを本番で使われる状態まで持っていく必要があります。

違いを一言で言うと、こうです。

フルスタックエンジニアは、広く作れる人。
FDSEは、顧客現場に入り、ソフトウェアで課題を解く人。
FDEは、顧客現場に入り、AIやプロダクトを本番成果まで持っていく人。

フルスタックエンジニアは、すでに決まった仕様やプロダクトロードマップに対して強さを発揮します。

FDEは、その前段階から関わります。
顧客が何に困っているのかを探り、業務を分解し、AIやソフトウェアで解ける形に変換し、短期間で動くものを作り、利用定着まで持っていく。

つまり、FDEは「作る力」だけでなく、「課題を見極める力」と「使われる状態まで持っていく力」が必要です。

日本の開発現場では、PM的な役割を担いながら、自分でもコードを書くエンジニアがいます。

こうした人は、FDEやFDSEに近く見えるかもしれません。

ただし、厳密には違います。

まず、スクラムガイド上の正式な構成は、Product Owner、Scrum Master、Developersです。PMという役割はスクラムの正式なアカウンタビリティではありません。実務上、日本企業やSIerではPM的な動きとエンジニアリングを兼ねる人がいる、という整理が近いです。(Scrum Guides)

従来のスクラム型開発におけるPM＋エンジニアは、基本的には決まったプロジェクトやプロダクト開発を前に進める人です。

一方でFDEやFDSEは、そもそも何を作るべきかを顧客現場で見極めるところから入る人です。

この違いは大きいです。

従来型のPM＋エンジニアは、プロジェクト、スプリント、バックログ、成果物、納期という枠組みの中で動くことが多い。
FDEは、顧客の業務成果、本番利用、プロダクト改善へのフィードバックまで見ます。

つまり、FDEはプロジェクトの成功だけではなく、顧客の業務が本当に変わったかまで問われる役割です。

整理すると、以下のようになります。

この比較で見ると、FDEやFDSEは、単に「フルスタックエンジニアの上位版」ではないことがわかります。

フルスタックエンジニアは、技術範囲の広さが特徴です。
FDSEは、顧客現場に入り込むソフトウェア実装力が特徴です。
FDEは、顧客の業務成果とプロダクト活用まで含めた導入力が特徴です。
従来のPM＋エンジニアは、プロジェクトやチームを前に進める力が特徴です。

重なる部分はあります。

しかし、役割の重心が違います。

FDEは、アジャイル開発と非常に親和性が高い役割です。

アジャイルソフトウェア開発宣言では、プロセスやツールよりも個人と対話、包括的なドキュメントよりも動くソフトウェア、契約交渉よりも顧客との協調、計画に従うことよりも変化への対応を重視しています。FDEの動き方は、この考え方とかなり近いです。(アジャイルマニフェスト)

FDEは、顧客から要件を受け取って、その通りに作るだけの役割ではありません。
顧客の現場に入り、業務課題を理解し、短期間で動くものを作り、実際に使ってもらいながら改善していきます。

FDEの仕事の流れからも、FDEはかなりアジャイル的です。

これらは、FDEの仕事そのものに近いです。

特にAI導入では、最初から正解を決めることが難しい。

プロンプト、モデルの挙動、評価基準、業務フロー、セキュリティ、ユーザーの受け入れ方など、実際に動かしてみないと見えないことが多い。

そのため、FDEはウォーターフォール型よりも、アジャイル型の進め方と相性が良いと言えます。

一方で、FDEを「アジャイル開発をするエンジニア」とだけ捉えると、本質を見誤ります。

アジャイル開発やスクラムは、基本的にはプロダクトやソフトウェア開発をどう進めるかの考え方・フレームワークです。

一方でFDEは、開発プロセスだけではなく、顧客現場への導入、本番利用、業務成果、プロダクト改善へのフィードバックまで含む役割です。

つまり、FDEはアジャイル開発のように小さく作って改善するだけではありません。

作ったものを、顧客の業務に組み込む。
本番環境で使われる状態にする。
利用状況や評価結果を見て改善する。
現場で得た知見をプロダクトやモデル改善に戻す。
顧客組織の中で意思決定や定着まで進める。

ここまで見るのがFDEです。

OpenAIのFDE求人でも、成功指標として本番利用、業務インパクト、評価に基づくフィードバックが挙げられており、単なる開発プロセスではなく、本番導入と顧客成果まで含む役割であることがわかります。(OpenAI)

では、FDEはアジャイル開発を超えたものなのでしょうか。

私は、超えたというより、アジャイル開発を顧客現場と本番導入まで拡張したものに近いと思います。

アジャイル開発の中心は、ソフトウェアを継続的に改善しながら価値を届けることです。
FDEの中心は、顧客現場で技術を使い、実際の業務成果に変えることです。

この違いは大きいです。

アジャイル開発は、開発チームの中で価値を早く届けるための考え方です。
FDEは、開発チームの外に出て、顧客現場の中で価値を実現するための役割です。

その意味で、FDEは開発手法ではなく、顧客現場に展開されたプロダクトエンジニアリングだと思います。実はこのようにFDEと言われる前に6年くらい前にこのような動きをする企業を聞いたことがあります。

従来のアジャイル開発では、スプリントごとに動くソフトウェアを作り、フィードバックを得ながら改善します。
これは非常に重要です。

しかしAI時代には、動くソフトウェアを作るだけでは不十分です。

AI機能が動いても、現場で使われないことがあります。
デモでは良く見えても、本番業務に組み込めないことがあります。
モデルの精度が高くても、評価基準が曖昧で使えないことがあります。
セキュリティや権限管理が整っていないために、本番利用できないことがあります。

FDEは、こうした「動くけれど、使われない」という問題に向き合う役割です。

だからFDEは、単にアジャイルに開発するだけではなく、以下まで見ます。

ここまで見ると、FDEはアジャイル開発の延長ではありますが、単なる開発プロセスではありません。

FDEに必要なスキルは、かなり広いです。

コードを書けること。
APIを理解していること。
クラウドやデータベースの基本を理解していること。
認証、権限、セキュリティ、ログ、運用を考えられること。
短期間で動くものを作れること。

FDEは「話せるけど作れない人」では厳しいです。
顧客現場で課題を聞き、その場で技術的な実現可能性を判断し、必要なら自分で手を動かす必要があります。

AIアプリを単体で作るだけなら、それほど難しく見えないかもしれません。
しかし、実際の企業導入では、既存システム、業務データ、権限、監査、セキュリティ、運用、費用、保守性が絡みます。

AIをどこに置くのか。
どのデータを参照させるのか。
どこまで自動化するのか。
人間の承認をどこに残すのか。
ログや評価をどう設計するのか。
障害時にどう切り戻すのか。

こうした設計ができないと、本番導入は難しくなります。

特にAI企業のFDEでは、LLMの特性、プロンプト、RAG、エージェント、評価、ガードレール、セキュリティ、監視、コスト制御などの理解が必要になります。AnthropicのFDE求人でも、顧客システム内でClaudeを使った本番アプリケーションを構築し、MCPサーバーやサブエージェントなどの技術成果物を提供する役割が説明されています。(Anthropic)

FDEは、顧客のIT部門だけでなく、業務部門、管理部門、経営層とも会話します。
現場の言葉を理解し、技術の言葉に変換する。
逆に、技術的な制約を現場にわかる言葉で説明する。

この翻訳力が非常に重要です。

FDEの仕事では、最初から要件がきれいに決まっていることは少ないはずです。

顧客自身も、AIで何をしたいのかを明確に言語化できていない。
現場は困っているが、何が本質的な課題なのか整理されていない。
経営層はAI活用を求めるが、現場は不安を持っている。

このような曖昧な状況の中で、仮説を立て、小さく作り、試し、修正していく力が必要です。

外資AI企業のFDEでは、英語での面接、英語での社内コミュニケーション、英語でのドキュメント理解が求められるケースが多いです。OpenAIのTokyo FDE求人でも、日本語と英語の両方に流暢であることが求められ、面接にも両言語での会話が含まれるとされています。(OpenAI)

つまり、FDEは「少し英語が読める」程度ではなく、技術・業務・顧客対応を英語でもこなせる必要がある場合があります。

FDEに必要なのは、スキルだけではありません。
考え方もかなり重要です。

従来型のSIer的な仕事では、要件定義、設計、開発、テスト、納品が大きな区切りになります。
もちろん、これは重要です。

しかしFDEの場合、納品しただけでは成果とは言えません。
本番で使われ、業務が変わり、顧客にとって意味のある結果が出る必要があります。

顧客が言ったことをそのまま作るだけなら、FDEである必要はありません。
FDEは、顧客がまだ言語化できていない課題を見つける必要があります。

こうした問いを持てるかどうかが重要です。

FDEは顧客ごとに深く入り込みます。
しかし、すべてを個別カスタマイズにしてしまうと、プロダクト企業としてスケールしません。

顧客ごとの固有課題を解きながら、共通化できるパターンを見つける。
現場で得た学びをプロダクトやエンジニアリングチームに戻す。
この動きができないと、FDEは単なる高級受託開発になってしまいます。

AnthropicのFDE求人でも、顧客への導入支援だけでなく、繰り返し使える導入パターンを見つけ、プロダクトやエンジニアリングチームに知見を戻すことが役割に含まれています。(Anthropic)

では、FDEは日本の組織にフィットするのでしょうか。

結論から言うと、思想としては非常に必要だが、そのまま導入するのは難しいと思います。

理由は、日本企業の多くがFDEと相性の悪い構造を持っているからです。

FDEは、顧客現場に入り、短期間で仮説検証を行い、必要に応じて設計や実装を変えながら、本番利用まで持っていく役割です。

しかし日本企業では、現場、IT部門、セキュリティ部門、法務、経営層の意思決定が分かれていることが多い。
データアクセスも簡単ではありません。
契約も成果物や工数を固定しがちです。
PoCはできても、本番導入になると責任者や予算が曖昧になることがあります。

この状態では、FDEが入っても十分に動けません。

たとえば、FDEが顧客現場で課題を見つけても、データにアクセスできない。
業務部門は使いたいが、IT部門の承認が進まない。
セキュリティ部門が止める。
法務確認に時間がかかる。
本番導入の予算がない。
既存ベンダーとの契約があり、変更が難しい。

これでは、FDEのスピード感は出せません。

つまり、日本企業にFDEを導入するには、単に人を採用すればよいわけではありません。
​FDEが動ける組織構造と権限設計が必要です。

日本企業では、FDEを導入しようとすると、次のような誤解が起きやすいと思います。

「アジャイル開発ができるエンジニアを顧客対応に出せばFDEになる」
「PMもできるエンジニアならFDEになれる」
「スクラムを回せる人ならFDEに近い」
「要件定義と開発ができればFDEとして機能する」

これらは一部は正しいですが、十分ではありません。

FDEに必要なのは、アジャイル開発のスキルだけではありません。

顧客現場に入り、曖昧な課題を掘る力。
業務課題を技術課題に変換する力。
短期間で動くものを作る力。
本番導入の障壁を取り除く力。
現場で使われる状態まで持っていく力。
導入から得た知見をプロダクト改善に戻す力。

ここまで必要です。

つまり、FDEはアジャイル開発ができる人ではなく、アジャイル的に顧客現場で価値を実装できる人です。

日本企業にFDEを導入する場合、障壁は大きく5つあります。

FDEは、現場で課題を見つけ、設計し、実装し、改善していく役割です。

しかし、現場に意思決定権がない場合、動きが止まります。
業務部門は困っているが、IT部門が承認しない。
IT部門は進めたいが、セキュリティ部門が止める。
セキュリティ部門は条件を出すが、経営判断がない。

このように権限が分散していると、FDEは調整に時間を取られます。

AI活用では、業務データ、ドキュメント、ログ、顧客情報などが重要になります。

しかし、FDEがデータにアクセスできなければ、現場に入っても価値を出しにくい。
もちろん、セキュリティや個人情報保護は重要です。

問題は、アクセスを禁止することではなく、安全に使うための設計がないことです。

データ分類、権限管理、監査ログ、匿名化、利用範囲、モデルへの送信可否などを整理しないと、FDEは動けません。

FDEの仕事は探索型です。

最初からすべての要件が決まっているわけではありません。
作りながら、試しながら、方向修正します。

しかし、日本のIT契約では、成果物、工数、期間、責任範囲を事前に固定しがちです。
これ自体は悪いことではありませんが、FDE型の仕事とは相性が悪い場合があります。

FDEを活かすには、準委任型、アジャイル型、成果指標連動型など、探索と改善を許容する契約が必要になります。

FDEは、開発者としてだけでは評価できません。
PMとしてだけでも、コンサルとしてだけでも評価できません。

顧客課題を理解したか。
本番利用まで持っていけたか。
業務成果が出たか。
再利用可能な知見を作れたか。
プロダクト改善にフィードバックできたか。
顧客との関係を深められたか。

こうした複合的な成果を見る必要があります。

しかし、多くの組織では、こうしたハイブリッド人材の評価制度が整っていません。
結果として、FDEが「何でも屋」になり、評価されにくくなるリスクがあります。

FDEは仮説検証型の仕事です。
小さく作り、試し、改善します。

つまり、小さな失敗は前提です。

しかし、失敗を極端に嫌う組織では、最初から完璧な要件定義やリスクゼロを求めます。
これではFDEは機能しません。

AI導入では、最初から完璧な正解を出すことは難しい。
評価しながら、改善しながら、適用範囲を広げていく必要があります。

FDEは、業務部門、IT部門、セキュリティ部門、プロダクトチーム、外部パートナーなどを横断して動く役割です。

しかし日本企業では、部門ごとに責任範囲や評価指標が分かれていることが多く、横断的な意思決定が進みにくい場合があります。

業務部門は早く試したい。
IT部門は安全性や既存システムへの影響を確認したい。
セキュリティ部門はリスクを抑えたい。
経営層は成果を早く見たい。

このように、それぞれの立場が違うため、FDEが間に入っても、合意形成に時間がかかります。

FDEを機能させるには、単に優秀な人材を置くだけではなく、部門横断で判断できる場や、意思決定のルールを先に設計しておく必要があります。

FDEが価値を出すには、顧客の業務データや既存システムと接続できることが重要です。

しかし日本企業では、長年使われている基幹システム、独自仕様の業務システム、古いデータ構造、属人的な運用が残っていることが多くあります。

この状態では、AIや新しいプロダクトを導入しようとしても、本番環境への接続が重くなります。

PoCではうまく動いても、実際の業務システムとつなぐ段階で止まる。
データ形式が揃っていない。
APIが用意されていない。
改修できる担当者が限られている。
影響範囲が読みにくく、本番反映に時間がかかる。

こうした問題があると、FDEのスピード感は大きく落ちます。

そのため、日本企業でFDEを導入する場合は、FDEだけで解決しようとするのではなく、データ基盤、API整備、権限管理、既存システムの棚卸しを並行して進める必要があります。

では、日本企業でFDE型の役割を導入することは現実的なのでしょうか。

全社一括で導入するのは難しいと思います。
ただし、限定された領域から始めるなら現実的です。

たとえば、以下のような進め方です。

まず、AI活用の重点テーマを1つか2つに絞る。
次に、業務部門、IT部門、セキュリティ、法務、外部パートナーを含めた小さな混成チームを作る。
そのチームに、一定のデータアクセス権と意思決定権を与える。

これだけ見るとスクラム型の開発のように見えます。

PoCではなく、本番利用までを成果指標にする。
得られた知見をテンプレート化し、他部門へ展開する。

この形であれば、日本企業でもFDE的な動きは可能です。

ただし、名前だけFDEにしても意味はありません。

「FDEチームを作りました」
「FDEという肩書きをつけました」
「AIに詳しいエンジニアを顧客対応に出しました」

これだけでは機能しません。

必要なのは、仕事の進め方を変えることです。

要件を待つのではなく、現場に入り課題を掘る。
納品で終わるのではなく、本番利用まで見る。
個別対応で終わるのではなく、共通パターンを組織知にする。
技術導入で終わるのではなく、業務成果まで追う。

この転換ができるなら、FDE型の導入は現実的です。

FDEのメリットは大きいです。

FDEは顧客現場に近い場所で動きます。

そのため、机上の要件だけでは見えない課題を把握できます。
現場が本当に困っていること。
使われない理由。
データが整っていない理由。
業務フロー上のボトルネック。
承認や権限の問題。

こうしたものが見えやすくなります。

AI導入でよくあるのが、PoCは成功したが本番化しないというパターンです。

デモでは動いた。
経営層にはウケた。
しかし現場では使われない。
既存システムとつながらない。
セキュリティ確認で止まる。
業務フローに組み込まれない。

FDEは本番利用まで見るため、PoC止まりを減らしやすい。

FDEは顧客固有の課題を見ます。
しかし、その中には他の顧客にも共通する課題があります。

FDEが現場で得た知見をプロダクトチームに戻せば、プロダクト改善につながります。
OpenAIのFDE求人でも、顧客現場からのフィードバックをProduct、Research、Partnerships、GRC、Security、GTMなどのチームと連携することが説明されています。(OpenAI)

これは、FDEが単なる導入支援ではないことを示しています。
FDEは、顧客現場とプロダクト開発をつなぐ役割でもあります。

FDEは、単に製品を売るだけではありません。
顧客の課題に入り込み、成果を出すところまで伴走します。

そのため、顧客との関係は深くなります。
単なるベンダーではなく、戦略パートナーに近い位置になりやすい。

特にAI導入では、顧客側も何が正解かわからないことが多い。
その時に、技術と業務の両方を理解し、一緒に形にしてくれるFDEの価値は高いと思います。

一方で、FDEにはリスクもあります。

FDEは高度な複合スキルを持つ人材です。

そのため、優秀なFDEに依存しすぎると、属人化します。
その人がいないと案件が進まない。
顧客との関係もその人に閉じる。
設計判断の理由もドキュメント化されない。

こうなると、組織としてスケールしません。

サービスやプロダクト開発にFDEをそのまま導入するのは、リクエスト管理やゲート管理等の観点でかなり難易度が高いかもしれません。

FDEは顧客現場に深く入ります。
そのため、顧客ごとの個別要望に応えすぎるリスクがあります。

個別対応が増えると、プロダクト企業なのに受託開発企業のようになります。
これは非常に危険です。

FDEを導入するなら、どこまで個別対応し、どこからプロダクト化するのかを明確にする必要があります。

FDEは、顧客、営業、プロダクト、エンジニアリング、セキュリティの間に立ちます。

そのため、問題が起きた時に責任範囲が曖昧になりがちです。

顧客側の業務設計の問題なのか。
自社プロダクトの問題なのか。
FDEの設計判断の問題なのか。
営業が期待値を上げすぎたのか。
セキュリティ要件を見落としたのか。

ここが曖昧だと、FDEに負荷が集中します。

FDEは負荷が高い役割です。

顧客対応をする。
技術設計をする。
コードを書く。
社内調整をする。
本番導入まで見る。
場合によっては英語でも説明する。

これを高いレベルで続けるのは簡単ではありません。

優秀な人ほど難しい案件に投入され続け、燃え尽きるリスクがあります。

FDEは顧客課題を深く理解します。
そのため、追加提案や拡張提案にも関わりやすい。

これはメリットでもあります。
しかし、売上優先で技術判断が歪むと、FDEの信頼性が落ちます。

FDEは営業支援もできますが、営業そのものではありません。
技術的に正しい判断を守る必要があります。

日本企業がFDE型の役割を導入するなら、まず必要なのは役割定義です。

FDEに何を期待するのか。

ここが曖昧なままだと、FDEは便利屋になります。

次に、成果指標の設計が必要です。

これだけではFDEの価値を測れません。

こうした指標が必要になります。

さらに、FDEを孤立させない組織設計も必要です。

FDEはスーパーマンではありません。
プロダクトチーム、セキュリティ、GRC、営業、カスタマーサクセス、データ基盤チームとつながっていなければ機能しません。

FDEは個人技に見えますが、本当は組織能力です。

日本企業でFDEを導入するなら、最初から大きな組織を作るよりも、以下のような小さな形が現実的です。

まずは社内向けAI活用から始める形です。

業務部門の課題を聞き、AIで解ける形に変換し、簡単なプロトタイプを作り、実際の業務に組み込む。
社内向けであれば、顧客向けよりも調整しやすい。

ここでFDE的な動き方を学ぶことができます。

外部顧客向けに導入する場合は、全顧客ではなく、重点顧客に絞った方がよいです。

FDEは負荷が高いため、すべての案件に投入すると破綻します。
戦略的に重要な顧客、本番導入の可能性が高い顧客、プロダクト改善につながる顧客に絞るべきです。

日本企業では、すでにPMとエンジニアの中間のような人材がいることがあります。

この人たちに、AI、データ、プロダクト思考、顧客成果指標、英語を加えていく。
これが最も現実的かもしれません。

ただし、従来型のPM＋エンジニアとFDEは同じではありません。
「納品」ではなく「本番利用」を見るように、評価と役割を変える必要があります。

FDEは、単なる新しい職種名ではありません。

役割であり、組織であり、仕事の進め方です。

フルスタックエンジニアは、広く作れる人。
FDSEは、顧客現場に入り、ソフトウェアで課題を解く人。
FDEは、顧客現場に入り、AIやプロダクトを本番成果まで持っていく人。
従来のスクラム型PM＋エンジニアは、プロジェクトやスプリントを前に進めながら開発もする人。

それぞれ重なる部分はあります。
しかし、同じではありません。

FDEとアジャイル開発は、非常に相性が良いです。

これらは、FDEにとっても重要です。

ただし、FDEはアジャイル開発そのものではありません。

アジャイル開発が「どう作るか」に強い考え方だとすれば、FDEは「何を作るべきかを現場で見極め、作ったものを使われる状態まで持っていく」役割です。

特にAI時代には、この違いが重要になります。

AIは作るだけでは価値になりません。
使われる状態にして、業務に組み込み、評価し、改善し続ける必要があります。

日本企業にも、FDE的な役割は必要になると思います。
ただし、名前だけ真似ても機能しません。

FDEを導入するには、権限、データアクセス、契約形態、評価制度、失敗許容度、プロダクトチームとの連携が必要です。

逆に言えば、これらを整えられる企業では、FDEは大きな武器になります。

AIを導入するだけでは、業務は変わりません。
AIを現場で使われる状態にして、業務成果に変える必要があります。

そのためには、技術と現場の間に入れる人材が必要です。

FDEとは、まさにその役割です。

日本企業が学ぶべきなのは、FDEという肩書きではなく、FDEが持つ思想だと思います。

顧客の近くで考える。
現場の課題を技術に変える。
作って終わりではなく、使われるところまで持っていく。
個別案件の学びを、組織の知見に変える。

この動き方を作れる企業が、AI時代に本当に業務を変えられる企業になると思います。