FDEとSWE・セールスエンジニアの違いは？役割を徹底比較

求人票に「FDE（Forward Deployed Engineer）」と書かれていて、隣に並ぶSWEやセールスエンジニア、ソリューションアーキテクトの募集と何が違うのか、一瞬手が止まったことはないだろうか。肩書きだけを見比べても境界線は判然としない。だが実際には、FDEにしかない立ち位置がはっきりと存在する。

FDEとは何か、まず定義を押さえる

「Forward Deployed Engineer」と聞くと、また新しい肩書きが増えただけのようにも思える。だが発祥をたどると、定義そのものは驚くほど明快だ。

FDEはPalantir Technologies発祥の職種である。Palantir社内では「Delta」と呼ばれ、社内向けにプロダクトを作る「Dev（one capability, many customers）」に対して、FDEは「one customer, many capabilities」――1つの顧客に対して複数の能力を持ち込む役割と定義されている。

中核にあるのは、課題のスコープ設定から構築、本番運用までを同一のエンジニアがend-to-endで担うという「責任一貫性」だ。Palantirは公式に、FDEの責務を「スタートアップCTOに近い」と表現している。顧客組織にembeddedされ、顧客のスタンドアップに参加し、顧客のリポジトリにコミットし、顧客の本番・認証・デプロイ制約の中でコードを書く。ここが、他の技術職と一線を画す点である。

cleanest test：セールス・ソリューション・FDEを1本の線で分ける

セールス、ソリューション、FDE――名前だけ並べても、違いを一言で説明できるだろうか。実は最も簡潔な基準（cleanest test）が、たった3行で存在する。

• セールスエンジニア＝契約を結ばせる：技術デモや提案でお客様の意思決定を後押しし、契約というゴールに導く役割
• ソリューションエンジニア（ソリューションアーキテクト）＝結んだものを設計する：契約後、要件を技術仕様・アーキテクチャに落とし込む役割
• FDE＝本番で動かし続ける：設計を顧客インフラの上で実装し、障害対応まで含めて本番稼働させ続ける役割

この3つは時系列でもつながっている。セールスエンジニアが「売る」段階、ソリューションアーキテクトが「設計する」段階、FDEが「動かし続ける」段階を担い、案件のライフサイクルの中で役割が引き継がれていく。決定的な違いは、FDEだけが実際に顧客の本番環境でコードを書き、障害トリアージまで責任を持つ点だ。

FDEとSWE（ソフトウェアエンジニア）の違い

同じ「コードを書く仕事」なのに、SWEとFDEでは見ている景色がまるで違う。

通常のSWEは自社オフィス（またはリモート）で、自社プロダクトを不特定多数の顧客向けに開発する。コードの利用者は抽象化された「ユーザー」であり、個別の顧客環境に触れることは基本的にない。

一方でFDEは、特定の1顧客の環境に常駐する。オンサイト比率は稼働の25〜50%にのぼり、その顧客の本番・認証・デプロイ制約の中でコードを書く。時間配分は大きく3領域に分かれ、①顧客案件の実装（主軸）②自社プラットフォームの改善③社内タスク、を行き来する。夕方には障害トリアージを行いつつ、そこで得た学びを本社のプロダクトチームへフィードバックする――この自社プロダクトへの還元サイクルも、FDEに特有の動きだ。

つまりSWEが「one capability, many customers」（1つの機能を多くの顧客に届ける）だとすれば、FDEは「one customer, many capabilities」（1つの顧客に多くの機能を持ち込む）という、逆方向のベクトルで動いている。

FDEとセールスエンジニアの違い

契約を取るまでは何でもする、というセールスエンジニアの動き方を見て、FDEと役割が重なると感じたことはないだろうか。

セールスエンジニアの主眼は契約獲得だ。技術的な説得力を持ってデモや提案を行い、営業チームと二人三脚で商談を前に進める。関わる期間は基本的に契約が締結されるまでで、コードを書いて本番稼働させる責務は持たない。

FDEは契約後のフェーズで登場し、実際に顧客のインフラ上でプロダクトを構築・運用する。セールスエンジニアが「動くように見せる」段階を担うのに対し、FDEは「実際に動かし、動かし続ける」段階を担う。似ているようで、責任の重心がまったく異なる。

FDEとソリューションアーキテクトの違い：OpenAIの社内定義から

混同されやすいのは、むしろここだ。

FDEとソリューションアーキテクト（ソリューションエンジニア）の境界線は特に見分けがつきにくい。だがOpenAIの社内定義が、この違いを明確にしている。

OpenAIでは、FDEは「顧客インフラ上で、顧客が実際に使うツールを使ってコードを書く」役割とされ、Solutions Architectは「匿名化データを使ったオフラインのMVP構築が主」とされている。同じ「技術力×顧客対応力」を持つ職種でも、コードが動く場所が本番の顧客環境か、オフラインの検証環境かという点で明確に切り分けられている。

職種比較表

4つの職種を並べると、立ち位置の差はこう整理できる。

職種	立ち位置	主眼	コード実装
セールスエンジニア	商談〜契約段階に伴走	契約を結ばせる	デモ・PoCレベル、本番実装は基本なし
ソリューションアーキテクト	契約後の設計フェーズ	結んだものを設計する（オフラインMVP中心）	匿名化データでの検証実装が主
SWE	自社オフィス・自社プロダクト開発	不特定多数の顧客に機能を届ける	自社プロダクトの本番コード
FDE	顧客組織にembedded	本番で動かし続ける	顧客の本番・認証・デプロイ制約下での本番コード

コンサルとの違い：第3の選択肢

正直なところ、この比較が一番歯切れが悪い。FDEとコンサルタントの違いは、他の比較軸ほど一次情報が固まっておらず諸説あるからだ。

おおまかな整理としては、コンサルは戦略立案や設計図の作成までを担い、実装そのものは別のチームに引き継がれることが一般的とされる。対してFDEは、実装から現場への定着までを自らの手を動かして完遂する点が異なるという見方が多い。

この特徴から、日本では「エンジニアとコンサルの第3の選択肢」という位置づけで語られることがある。技術力だけでもなく、上流の戦略提案だけでもない。両方を橋渡しして本番稼働まで責任を持つ立ち位置が、既存のどの職種にも完全には当てはまらない独自性を生んでいる。

まとめ

FDEと隣接職種の違いは、結局のところcleanest testの3行に集約される。セールスエンジニアは契約を結ばせ、ソリューションエンジニアは結んだものを設計し、FDEは本番で動かし続ける。SWEとの違いは開発対象が不特定多数か特定の1顧客かという点にあり、OpenAIの社内定義に見るソリューションアーキテクトとの違いは、コードが動く場所が本番か検証環境かという点にある。コンサルとの比較も含め、FDEは「技術力×顧客対応力」を両立させながら実装から本番運用までを一貫して担う、独自のポジションだ。次に求人票でこの肩書きを見かけたときは、もう迷わず見分けがつくはずだ。

あわせて読みたい

• Forward Deployed Engineerとは？定義と仕事内容を解説
• FDEに必要なスキルとは
• FDEを採用している企業一覧