結論を先に書く。フォワードデプロイエンジニア (FDE) は新しい職種ではない。「顧客の現場に入り込み、自分の手でテクノロジーを使い切る」という、エンジニアリングの一つの姿勢に、たまたま Palantir が名前を付けただけのものである。
日本で言う「ラボ型開発」は 契約形態の話。FDE は 姿勢の話。「準委任に近い柔軟な関わり方」というだけで同じ箱に入れられがちだが、本質はまったく違う。
Xincere は世間から「フォワードデプロイエンジニアの集団」と呼ばれることがある。否定はしない。しかし我々の中では、それはあくまでも「エンジニア」の一形態にすぎない。ビジネスの現場に入り込み、テクノロジーで人間の価値創造を最大化する。これが我々の考えるエンジニアリングだ。
想定読者は、SaaS / 受託 / SIer / 事業会社の意思決定者と、現場のソフトウェアエンジニア。読み終えた頃には、「FDE を採用する」「ラボ型契約を結ぶ」がそれ単体では解にならない理由が腹落ちするはずだ。
FDE は職種ではなく "姿勢" である
フォワードデプロイエンジニアという言葉は、Palantir が自社の Forward Deployed Software Engineer (FDSE) という職種を世に広めた結果として定着した。Palantir 公式ブログでは、FDSE と通常のソフトウェアエンジニアの違いを「多くの顧客に使われる一つの機能を作るのが通常のエンジニア、一人の顧客のために多くの機能を作るのが FDSE」(原文意訳: one capability for many customers vs. many capabilities for one customer) と整理している (A Day in the Life of a Palantir Forward Deployed Software Engineer)。
この定義の本質は「肩書き」ではない。「顧客の業務とデータに自分が責任を持つ」というエンジニアの覚悟である。 同じ仕事を別の名前 (ソリューションエンジニア、ドメインスペシャリスト、現場 PM) で呼んでいる会社はたくさんある。Palantir が言語化したから FDE が流行ったが、姿勢としては昔から世界中に存在していた。
職種ではなく姿勢である以上、肩書きが FDE であってもこの姿勢を持っていない人は世の中にたくさんいる。逆に、肩書きが「Web エンジニア」「バックエンドエンジニア」であっても、顧客の現場に入り込んで価値を出している人もたくさんいる。我々が見るべきは肩書きではなく実態だ。
なぜ今、世界中で FDE という言葉が広がっているのか
Palantir は 2000 年代から FDSE を「Delta」という社内呼称も含めて運用してきた老舗だ。だがここ 1〜2 年で、FDE という言葉自体が業界の共通語になりはじめている。
The Pragmatic Engineer のニュースレターでは、Palantir に加えて OpenAI、Ramp (フィンテック)、Commure (ヘルスケア)、Matta (産業 AI)、Gecko Robotics、Lindy、Salesforce などが明示的に FDE を採用していると整理されている (What are Forward Deployed Engineers, and why are they so in demand?)。
これは偶然ではない。AI 時代になって「汎用プロダクトを並べるだけでは顧客の現場で動かない」という構造的限界が露呈した結果である。 顧客のデータの形、業務オペレーション、人間の癖、組織の力学。これらをエンジニアが理解しない限り、どれほど精度の高い AI モデルも、どれほど機能豊富な SaaS も、価値を出しきれない。
「顧客の現場にエンジニアを送り込む」という古典的なやり方が、AI 時代に再び主流に戻ってきている。それだけのことだ。
ラボ型開発 (契約論) と FDE (姿勢論) はまったく別物
ここからが、日本の文脈で一番伝えたい話だ。
日本では「FDE 的に動ける体制が欲しい」という相談を受けると、ほぼ必ず「ではラボ型開発契約にしましょう」という議論にすり替わる。気持ちは分かる。ラボ型契約は期間と人数を確保する準委任ベースの契約で、柔軟に動ける体制を組みやすいからだ。
だがラボ型契約は箱でしかない。中身に FDE 的な姿勢を持ったエンジニアが入っていなければ、ただ「人月で人を抱える契約」に堕ちる。実際そういう「名ばかりラボ型」案件は多い。
逆に、請負契約だろうが時間契約だろうが、エンジニアが顧客の業務とデータに自分の手で入り込めば、それはもう FDE 的な仕事である。契約は姿勢を保証しないし、姿勢は契約を必要としない。
ラボ型開発自体の契約形態・メリット・デメリットの整理は ラボ型開発とは？メリット・デメリット・請負型・SES との違いをわかりやすく解説 で別途まとめてある。本記事はあくまで「姿勢としての FDE」の話に絞る。
Xincere が "FDE 集団" と呼ばれる理由
我々 Xincere は受託開発・SI を主軸とする会社だ。請負契約も準委任契約もラボ型契約もすべて使う。契約形態は手段にすぎない。
しかし、我々の現場の動き方は、世間から「フォワードデプロイエンジニアの集団」と呼びたくなる類のものになっているらしい。具体的には:
- 案件の初期から、顧客の業務オペレーションを直接見にいく。ヒアリングだけで終わらせない。
- 顧客の本番データに対して、自分の手で SQL を叩いて構造と異常値を確かめる。仕様書を信じすぎない。
- 業務担当者と Slack や対面で日次のレベルで詰める。要件定義は誰がやるかを発注側だけの宿題にせず、共同作業として扱う。
- AI / 生成 AI の活用も、まず顧客の業務フローに具体的な摩擦点を見つけてから設計する。AI 推進リードが最初の 30 日でやるべきことと同じ視点を、外部から持ち込む。
- 案件の終わり方が「納品して終わり」ではなく、「顧客側の運用体制・社内エンジニア体制への移管」になることが多い。
これらは我々の中では特別なことではなく、「エンジニアであるなら当然やること」のリストである。だから「フォワードデプロイエンジニア」と呼ばれることに違和感はない。しかし、それを 肩書き・職種 として受け取るつもりはない。姿勢として持ち続ける ことのほうがずっと重要だ。
なお、システム開発を外注するメリットやSIer とシステム開発会社の違いを整理した記事もあわせて参照すると、Xincere が市場でどの立ち位置にいるかが見えやすい。
FDE 的なエンジニアを採るには? 育てるには?
ここから採用・育成の話に踏み込む。意思決定者向けに具体的な判断基準を書く。
採用観点。 業務理解と技術判断を、同じ脳の中で同時に走らせられる人を採る。逆に言うと、「業務理解は PM の仕事、自分はコードに集中する」と切り分けてしまうエンジニアは FDE 的にはハマらない。両方を地続きに見られるかが分水嶺だ。
育成観点。 評価制度の中に「顧客の業務にどれだけ詳しくなったか」を明示的に組み込む。GitHub のコミット数だけで評価しないこと。コードを書く時間と、業務担当者と話す時間と、本番データを眺めている時間が、ほぼ同じ重みで効くようにする。
よくある落とし穴。
- 営業力のあるエンジニア = FDE と混同しない。 FDE は売る人ではなく価値を出す人だ。提案書ではなく動くものをまず出す。
- コンサルと混同しない。 FDE は手を動かしてコードを書く。スライドではなくコードが成果物の中心にあるかどうかで線を引く。
- 「単独で完結する人材」を求めない。 FDE 的な仕事は、自社のプロダクト / コア技術チームとの往復が前提だ。一人で完結を求めると、ただの「ベテラン PM」になってしまう。
よくある誤解の整理
現場で頻出する誤解を整理しておく。
- 誤解 1: FDE = ラボ型契約。 違う。契約形態と姿勢は別物。ラボ型契約でも姿勢が伴わなければ FDE にならないし、請負契約でも FDE 的に動ける。
- 誤解 2: FDE = SRE や DevOps の派生。 違う。インフラ系職種ではなく「ドメイン理解」職種だ。FDE が SRE 的な仕事を兼ねることはあるが、本質はそこではない。
- 誤解 3: FDE = 営業エンジニア (Sales Engineer)。 重なる部分はあるが別物だ。Sales Engineer は契約締結のための提案・PoC を中心とする。FDE は契約後の長期的な実装・運用・現場の価値創造に中心がある。
- 誤解 4: FDE は AI スタートアップだけのもの。 違う。AI 時代に顕在化しただけで、業務系 SI / 受託の現場には昔から FDE 的な仕事観が存在していた。Palantir はそこに名前を付けたにすぎない。
まとめ ── テクノロジーは現場に入った時はじめて価値になる
FDE は職種でも契約でもない。エンジニアリングの一つの実践論である。
ラボ型開発は良い契約形態だ。柔軟性も高い。だが、ラボ型契約を結べば自動的に FDE 的な成果が出るわけではない。姿勢が伴って初めて出る。
我々 Xincere は、この姿勢を持ったエンジニアの集まりとして仕事をしていく。「フォワードデプロイ」は珍しい肩書きではなく、エンジニアであることの一つの形にすぎない。 顧客の現場に入り込み、自分の手で本番データを触り、業務担当者と毎日話して、テクノロジーで人間の価値創造を最大化する。それを我々は「エンジニアリング」と呼ぶ。
この記事が、自社の体制設計や採用方針、ベンダー選定の整理に少しでも役立てば嬉しい。
