FDEとソフトウェアエンジニアの違い｜担当する課題・成果・協働の比較

2026 10/25

2026年10月19日 2026年10月25日

著者: Walkers編集部公開: 2026年10月19日最終更新: 2026年10月25日

製品開発を中心とするソフトウェアエンジニア（SWE）と顧客導入を中心とするFDE（Forward Deployed Engineer）の役割例を比べると、その違いは技術の有無ではなく、課題への関わり方や成果の置き方に表れます。本記事では米Palantir Technologiesの役割区分やAI企業の公開情報を手掛かりに、製品開発寄り・顧客導入寄りそれぞれの実務における力点の違いを比較します。

PalantirのDevとDeltaを手掛かりに違いを読む

FDEという役割の考え方を理解する手掛かりとして、Palantirの採用情報で説明されている「Dev（Product Development）」と「Delta（Business Development）」の対比があります。同社はDevを「1つの能力を開発して多くの顧客へ届ける（one capability many customers）」役割とし、Deltaを「1つの顧客に対して多くの能力を適用する（one customer many capabilities）」役割と表現しています。

組織名に「Business Development」が含まれているため営業職と誤解されがちですが、同社の公式資料においてDeltaは顧客の技術的・運用的な成果（technical and operational outcomes）を直接担う技術職として定義されています。さらに、2019年4月8日の公式記事Dev Versus Delta: Demystifying Engineering Roles at Palantirでは、Deltaが自社基盤を顧客課題へ導入適用する「FDSE（Forward Deployed Software Engineer）」を指すことが明記されています。なお、この記事は同社における当時の役割分担を解説した記録であり、FDEという職種全般の発祥年を示すものではありません。

また、Palantirのキャリア採用情報では、これらの役割は意図的に重複するように設計されている（roles intentionally designed to overlap）と説明されています。Deltaは個別顧客の課題解決だけでなくコアプラットフォームの拡張にも関与し、製品チームと調整しながらコードへ貢献します。一方のDevも、企画から設計、試作、本番運用を含む製品ライフサイクル全体に関わります。両者は完全に分断された二分法ではなく、互いの領域に関わりながら異なる重心を持って協働する関係にあります。

課題の起点・設計判断・成果の見方を比べる

製品開発を中心とするソフトウェアエンジニアと、顧客導入を中心とするFDEの典型的な関心事を整理すると、以下のようになります。この整理はPalantirの公開情報を参考に編集部が比較軸としてまとめたものであり、SWE全般の公的な職務定義や、全社共通の人事評価基準を示すものではありません。

比較軸	製品開発を中心とする役割例（SWE）	顧客導入を中心とする役割例（FDE）
課題の起点	ロードマップや複数顧客に共通する機能要求	個別顧客の業務フローや現場固有の制約
設計上の関心	共通基盤の汎用性、拡張性、APIの下位互換性	現場システムとの連携、権限設定、運用手順への適合
主な協働相手	社内のプロダクトマネージャー、開発チーム、SRE	顧客の業務担当者、情報システム部門、自社製品チーム
成果の置き方	共通機能の提供、可用性の維持、基盤利用の拡大	本番環境での稼働、業務改善の達成、利用の定着
知見の還元	汎用コンポーネントを共通基盤へ組み込む	現場で検証した拡張機能や課題を製品チームへ提案する

製品開発起点と現場導入起点の役割比較と相互連携

製品開発起点の役割例

共通基盤から複数顧客へ汎用機能を届ける。

現場導入起点の役割例

個別顧客の現場課題へ複数機能を適用する。

現場の知見を共通基盤へ還元し、製品ライフサイクル全体で協働する。

製品開発側のエンジニアも顧客ヒアリングや運用監視を通じて現場の状況を確認します。同様に、FDEも現場で実装した拡張処理を社内リポジトリへ還元することがあります。両者は対立する職種ではなく、知見を循環させて製品と運用の双方を強化するパートナーです。発注企業の視点では、FDE型はAI導入の頼み方4類型を比較においてSaaS導入や受託開発、内製と並ぶ選択肢です。

社内問い合わせ支援機能における設計判断の違い

【架空例】以下は、同じ問い合わせ支援機能を扱う際に、製品開発側と導入側で生じる設計判断の違いを示すために編集部が作成した架空の状況です。

ある企業群に向けて社内文書を検索・回答するシステムを導入する場面を想定します。製品開発を担当するソフトウェアエンジニアは、多数の顧客企業が利用することを前提に設計を進めます。具体的には、数千件の同時リクエストに耐えうる検索APIの応答速度を維持することや、テナント間でデータが混ざらない論理分離の仕組みを共通基盤として実装することに注力します。

一方、特定企業への導入を担当するFDEは、その企業の現場環境に即した調整を行います。例えば、カスタマーサポート部門が日常的に使用しているCRM画面の配置に合わせて検索UIを組み込み、既存の問い合わせ履歴に含まれる表記ゆれを吸収する前処理を整えます。

この現場で「特定の機密情報を含むマニュアルは、一部の管理職のみに検索結果を表示させたい」という要望が出たとします。FDEは、その企業の既存ID管理基盤と連携する権限フィルタを現場環境向けに設計・検証します。同時に、「部署や役職に応じたアクセス制御」は他社でも必要とされる共通要求であるため、FDEは製品チームと仕様を協議し、共通の認証・認可機能として製品本体のロードマップへ反映させる提案を行います。現場の要求を個別のカスタマイズで終わらせず、共通基盤の進化につなげる点が協働の要点です。

生成AIを扱うFDEの役割と評価指標

前述のPalantirの公式ブログ記事にある「顧客の目標へのインパクトで成功を測る」という観点は、近年の生成AIや大規模言語モデル（LLM）を扱うFDEにも受け継がれています。現在のAI導入では、単にAPIを接続するだけでなく、生成結果の精度を評価し、業務フローへ定着させることが求められます。

例えば、OpenAIの東京オフィスにおけるFDE採用情報では、初期検討から適用範囲の定義、設計、構築、本番展開までを一貫して担当すると記載されています。成功を測る指標としても、本番環境での利用定着や業務への影響、評価指標に基づく改善へのフィードバックが明記されています。東京オフィスの詳しい要件については、OpenAI東京FDEの職務と応募条件で整理しています。

【架空例】ここでのログ評価や回答保留の処理は、AI導入の流れを説明するための編集部の架空例であり、OpenAIの指定実装ではありません。

AIを活用した問い合わせシステムでは、モデルが社内規定に基づかない誤った回答を出力していないかを検証する必要があります。FDEは過去の問い合わせログを用いて回答精度を測定し、確信度が低い場合には「回答を保留して担当者へ引き継ぐ」運用ルールをシステムに組み込みます。実際の業務で使われたログを観察し、評価結果をプロンプトや検索手順、さらには自社製品の基盤機能へフィードバックしながら改善を繰り返します。

自分に合う役割は求人の担当範囲から判断する

自身が製品開発中心のソフトウェアエンジニアと顧客導入中心のFDEのどちらに向いているかを検討する際は、実際の求人票や面談を通じて、業務の担当範囲を確認することが有効です。具体的には次の4つの軸で誰がどの段階に関わるかを調べます。

課題の抽出：ロードマップ策定から顧客現場でのヒアリングまで、どの段階から課題の抽出に関与する想定か
協働の相手：社内開発チームや顧客の情シス・業務部門など、誰とどのような時間配分で協議を進めるか
成果の確認：基盤の安定稼働指標や現場での定着度など、どの成果指標に対してどのような確認責任を負うか
製品との関係：共通機能の設計実装や現場拡張の還元など、製品ライフサイクルのどの工程にどのように関わるか

製品開発側も本番運用や顧客成果と無関係ではなく、FDEも製品開発と無縁ではありません。曖昧な要件を整理してソフトウェアとして形にしてきた経験は、どちらの道でも役立ちます。自分が技術基盤の普遍性を追求することに関心があるのか、技術を特定の業務現場へ届けて実効性を確かめることに関心があるのかを手掛かりに、これまでの実績を振り返ることが推奨されます。