FDSEとは？FDEとの違い・仕事内容・必要スキルと目指し方を解説

FDSEとは何の略で、どんな職種なのか？

FDSEはPalantirの正式職種名で、顧客先に入り込み、本番品質のソフトウェアを実装まで担うエンジニアを指す。

FDSEはForward Deployed Software Engineerの略だ。「エンジニアなのに客先で要件を聞き、その場でコードを書く」という働き方は、日本のIT業界では長いあいだ、SIerの上流工程やコンサルタントの仕事と重ねて語られてきた。FDSEは、その働き方に「本番品質のソフトウェアを自分で書き切る責任」を加えた職種である。Palantir Technologies（2003年創業、現在の本社は米コロラド州デンバー）が主要職種のひとつとして採用ページに掲げたことで、FDSEという名前も広まった。

FDSEの正式名称と、Palantirが置く役割の定義は？

FDSEは直訳すると「前線配置型のソフトウェアエンジニア」で、Palantir製品の上に顧客専用の解決策を実装する。

Forward（前線に）Deployed（配置された）Software Engineerという名前のとおり、FDSEは顧客の現場に配置される。Palantirの採用情報では、FDSEは顧客の業務課題に直接向き合い、Palantirのプラットフォーム上で解決策を設計・実装する役割と説明されている。FDSEが扱うPalantirの製品は次の4つだ。

FDSEは、これらの製品の上にその顧客専用のデータパイプライン、オントロジー（業務概念のモデル）、業務アプリケーションを組み上げていく。

注意したいのは、FDSEが「営業に同行するエンジニア」ではないことだ。Palantirが定義するFDSEはデモを見せる人ではない。実際に動くものを納品し、現場で使われる状態まで持っていく人である。

FDSEはなぜ生まれたのか？

汎用プロダクトでは埋まらない業務固有の差分を、人が現地で埋めるために設計された職種がFDSEである。

製造ラインの歩留まり、病院の病床運用、サプライチェーンの部品供給。こうした領域では、データの形も意思決定の順序も企業ごとに違う。標準機能だけで解こうとすると、最後の20〜30%が必ず残る。この残りをコンサルタントのドキュメントで埋めてもソフトウェアにはならない。プロダクトチームのロードマップに載せれば、数四半期待つことになる。

FDSEはこの構造的なギャップへの回答だ。8割をプラットフォームで賄い、残りを現地で書く。この分業が成り立つには、プラットフォーム側が「その場で拡張できる」設計になっていなければならない。PalantirのFoundryやAIPは、まさにその前提で作られている。

近年はOpenAIやSierraをはじめとするAI企業が、同じ種類の職種を「Forward Deployed Engineer（FDE）」の名前で募集している。Palantirが生んだ職種の考え方が、業界の共通語になりつつある。

FDSEはFDEや一般的なソフトウェアエンジニアと何が違う？

FDEは職種の総称で、FDSEはPalantirの正式職種名だ。他の職種との最大の違いは実装比率の高さにある。

呼び方が混在しているので、まず整理しておく。日本語の求人や記事で「FDE」と書かれているものの多くは、Palantirの職種名から来た一般名詞としての使い方である。一方、Palantir社内の職種体系は二本立てだ。実装を担うのがFDSE、業務課題の定義と顧客関係を担うのがDeployment Strategist（DS）である。

FDEとFDSEはどういう関係なのか？

FDEは業界共通の概念名で、FDSEはその実装担当としてPalantirが定義した具体的な職名にあたる。

実務者の感覚では、FDEとFDSEの区別をあまり気にする必要はない。転職市場では「FDE」で検索すれば両方が見つかる。日本国内のFDE系ポジションは、Palantirほど役割がはっきり分かれていないことも多い。それよりも、その求人が実装をどこまで求めているかを職務記述書で確認するほうが役に立つ。

SWE・SIer・コンサルとFDSEはどこが違う？

成果物がコードである点はSWEと同じだが、要件を誰が確定させるかと、どこで働くかが決定的に違う。

FDSEだけの特徴は、「要件の出どころ」と「コードを書く比率」の両方が高いことに尽きる。要件を決める権限を持ちながら、実装からは逃げられない。この緊張がFDSEという職種の本質である。

Deployment Strategist（DS）とFDSEはどう分担する？

基本はDSが問いを立て、FDSEが解を実装する形だ。ただし実際の境界は案件の規模ごとに変わる。

小規模な案件では、FDSEがDSの役割を兼ねることも珍しくない。逆に大型導入では、複数のFDSEがモジュールを分担し、DSは顧客の意思決定者と成果指標をすり合わせる仕事に専念する。

日本企業がFDE的なポジションを新設するとき、この二役を一人に背負わせて疲弊させる例がある、という声は現場の実務者からよく聞かれる。立ち上げ期に兼務が避けられないことはある。しかし、ずっと続く体制として置くかどうかは慎重に考えたい。

FDSEの仕事内容と1案件の進め方は？

FDSEは要件定義から実装、定着支援までを一人で担う。1案件は数週間〜数か月で回るのが一般的だ。

FDSEは1案件をどんなフェーズで進める？

現場観察から始め、動くものを早めに見せ、使われ方を見ながら作り込む。これがFDSEの基本形になる。

1. 現場に入る（初日〜1週目）：業務を実際に観察し、誰がどのシステムを何回操作しているかを把握する。ヒアリングだけで済ませない。
2. データを繋ぐ（1〜3週目）：基幹システム、Excel、センサーログなど散らばったデータソースを取り込み、統合されたモデルにまとめる。Palantirの文脈では、オントロジーとして業務概念を定義する工程にあたる。
3. 最小の動くものを出す（2〜6週目）：完成度よりも、現場担当者が自分の業務で実際に触れることを優先する。ここで得た反応が、要件についての最大の情報源になる。
4. 作り込みと運用移管（1〜3か月目）：例外処理、権限、監査ログ、既存業務フローとの接続を詰める。最も地味で、最も落とし穴が多い工程だ。
5. 定着と撤収：顧客側の担当者に運用を引き継ぐ。その後も一定期間は使われ続けているかを追い、必要なら次の課題に広げる。

注意したいのは、この流れが一直線ではないことだ。フェーズ3で見せた瞬間に「そもそも解くべき課題が違った」とわかることは実際にある。それを早い段階で見つけるためにこそ早く見せる、というのがこの進め方の考え方である。

FDSEは実際にどんなコードを書き、どの技術を触る？

FDSEはデータ処理とフロントエンドの両端を一人で行き来する。専門の深さより守備範囲の広さが効く。

「Palantirプラットフォーム固有の知識が要るのでは」という不安はよく聞く。しかし選考で問われるのは汎用的なプログラミング能力と問題解決力で、Palantir製品固有の作法は入社後に覚える前提になっている。他社のFDEポジションでも事情は同じだ。

FDSEの稼働実態は？出張やオンサイトはどの程度？

FDSEの主な負荷は、顧客先への移動と、案件が切り替わるたびに文脈を一から積み直すことの二つだ。

コロナ禍以降はリモートとの併用が進んだが、初期フェーズではオンサイトの比重がいまも高い。さらに、案件が変わるたびに業界知識をゼロから積み直す必要がある。製造から医療へといった移動は知的な刺激が大きい一方、知識が蓄積されにくい。

この切り替えコストを楽しめるかどうかがFDSEへの適性を最も強く分ける、と複数の実務者が口を揃える。

FDSEに求められるスキルと経験は？

FDSEには、データ処理とアプリ実装の二つに、業務を言語化する力を加えた三層のスキルが求められる。

FDSEに必要な技術スキルは？

FDSEで評価されるのは一点の深さではなく、データからUIまで自力で通せる守備範囲の広さだ。

これは「浅く広く」という意味ではない。どの領域でも本番運用に耐えるものを書けることが前提で、そのうえで範囲が広い、という要求水準である。

FDSEに必要な非技術スキルは？

顧客の言葉を仕様に翻訳し、決裁者がいない場でも前に進める判断力が、FDSEの成果を大きく左右する。

具体的には次の三つだ。

1. 制約を掘り出す力：現場担当者が「面倒だ」と言った作業の裏にある制約を見つけ出す。
2. 合意を取る力：相反する要望が出たとき、優先順位を提案して合意を取る。
3. 暫定判断の力：情報が揃わないうちに暫定の判断を下し、後から修正できる形にしておく。

この三つが揃うと、技術力が同じでも成果は大きく変わる。英語力は、Palantir本体や外資系AI企業を目指すなら実務レベルが必要になる。一方、国内企業のFDE的ポジションでは必須としない求人も多い。

FDSEに向いている人・苦しくなる人は？

顧客の現場に価値を感じる人はFDSEに向いている。技術的な深掘りを最優先したい人には摩擦が大きい。

右の列に当てはまる人には、案件ごとに作って引き継ぐFDSEのサイクルが物足りなく感じられるかもしれない。これは優劣の問題ではなく、仕事から何を報酬として受け取りたいかの違いだと考えたい。

FDSEを目指すには何から始めればいい？

まず現職で顧客と直接話す仕事を取りに行き、実装と業務理解を一つの実績にまとめるのが最短ルートだ。

現職でFDE的な仕事を作るには何をすればいい？

転職前でも、いまの職場で再現できるFDSEの要素が三つある。選考で語れる実績の形にしておきたい。

1. 要件のヒアリングに同席し、自分で仕様に落とす：営業やPdMを経由して降りてくる要件を待たず、一次情報に直接触れる経路を作る。
2. 社内の業務課題を一つ、自分で見つけて自分で解く：部署の手作業をツール化し、使われるところまで面倒を見る。規模は小さくてよい。
3. データ基盤の上流から下流までを一度通す：取り込み・変換・可視化を分業せず、一人で通した経験があると強い。

FDSEの選考では何が見られ、どう準備する？

コーディング力に加えて、顧客の課題をどう定義し直したかを語れるかどうかが選考の分かれ目になる。

給与水準は企業と地域によって大きく違う。米国企業の求人では、法令に基づいて給与レンジが開示されている場合もある。数値は必ず応募先の最新の募集要項で確認してほしい。FDE総研では、ここで推測の数値を挙げることはしない。

FDSE経験者はその後どんなキャリアに進む？

現場の知見とプロダクト実装の両方を持つFDSE経験者は、PdM・アーキテクト・起業のどれにも進みやすい。

FDSEを数年経験すると、「業務の言葉」と「実装の言葉」の両方を話せる人材になる。この組み合わせは珍しく、プロダクトマネジメント、ソリューションアーキテクト、社内の新規事業立ち上げ、あるいは自分での起業へとつなげやすい。実際、米国ではPalantir出身者がFDE的な考え方を持ち込んでスタートアップを立ち上げる例が続いている。

一方で、特定のプラットフォームに依存した経験ばかりが積み上がると、市場価値が偏るおそれもある。FDE総研としては、汎用的な技術スタックでの実装経験を意識して残しておくことを勧めたい。案件で使う道具は選べなくても、個人として何を学び直すかは選べるはずだ。

FDSEのような人材を採用する側の参考記事は？

FDSEのような人材を自社で採用する側に立つなら、姉妹メディアAX総研の採用実務の記事が参考になる。

※本稿は現場実務者への取材メモをもとに構成し、公開にあたっては監修者の確認・承認を経ています。職務内容・待遇の詳細は各社の最新の募集要項をご確認ください。