B2B SaaS の現場で「FDE」という役職名を見かけることが増えてきた。Forward Deployed Engineer の略で、Palantir が広めたロールだ。日本語で直訳すれば「前線配備エンジニア」だが、そのままではピンとこない。この記事では FDE が何者なのか、どういうビジネスモデルで成立するのか、そして小規模な基幹システム開発にも当てはまるのかを整理する。

「前線配備」が指す意味

Forward Deployed という言葉はもともと軍事用語で、本国の司令部ではなく最前線に駐留している部隊を指す。FDE もこれと同じ構図で、自社のオフィス（本部）にいるのではなく、顧客のサイトや業務の現場に入り込んで働くエンジニアを指す。

Palantir はこのモデルを政府機関や金融機関へのプラットフォーム導入に活用した。自社プロダクトの上に顧客固有のデータ構造・ワークフロー・UIを構築するために、エンジニアを顧客先に送り込んで長期間滞在させた。単なる導入支援ではなく、現地でコードを書き、要件を引き出し、プロダクトチームへのフィードバックも担う。これが FDE の原型だ。

ロールとポジションの整理

FDE は技術力を持ちながら顧客に直接向き合うロールで、社内のどのポジションとも微妙に違う。

ポジション 主な関与タイミング 技術的深度 顧客接点
プリセールス SE 商談・PoC フェーズ 中（デモ中心） 高
実装コンサルタント 導入フェーズ 中（設定・設計） 高
カスタマーサクセス 継続利用フェーズ 低〜中 高
社内エンジニア プロダクト開発全般 高 低
FDE 導入〜定着フェーズ 高（コードを書く） 高

プリセールス SE は契約前に動き、契約後は引き継ぐ。カスタマーサクセスは関係管理が主で、実装の詳細には踏み込まない。FDE は契約後にコードを書きながら顧客の課題を解く。「エンジニアリングとカスタマーサクセスの交差点」とよく言われる所以だ。

具体的な業務は次のようになる。

  • 顧客のデータ構造・業務フローを理解し、自社プロダクトとの接続ポイントを設計する
  • 顧客環境に合わせた実装・カスタマイズをその場で行う
  • 導入途中で出てきた新たな要件を整理し、プロダクトチームへ伝える
  • 顧客の社内担当者を育てて、FDE がいなくても回るようにする

最後の「自分がいなくても回る状態を作る」は重要で、FDE は永続的に顧客に貼り付くのではなく、顧客が自立できるまでの濃い関与を担う。

ビジネスモデル

FDE がなぜ成立するかは、ビジネスモデルの構造から理解した方が早い。

SaaS ベンダー側の論理

大型の B2B SaaS 契約では、プロダクトを売るだけでは顧客が活用できないケースが多い。データの整備、既存システムとの連携、業務フローへの組み込みなど、技術的な工数が相当かかる。この部分を放置すると解約につながる。

FDE チームはその工数を引き受けることでプロダクトの価値を引き出し、顧客の定着（リテンション）と追加契約（アップセル）につなげる。コスト部門に見えるが、収益への貢献が計算できるため正当化される。

FDE を有する専任チームを持つかどうかは、プロダクトの複雑さと ACV（年間契約額）による。ACV が数百万円以下のセルフサービス型プロダクトでは FDE をつける経済合理性がない。数千万円〜億円規模のエンタープライズ契約であれば、FDE への投資は十分回収できる。

プロフェッショナルサービス型

FDE 機能を独立した有償サービスとして切り出すパターンもある。「導入支援パッケージ」として初期費用を取り、FDE が数ヶ月単位で関与する形だ。この場合、FDE の稼働時間が直接売上に紐づくため、採算の計算がしやすい。

Palantir 自身はこのモデルを取っていて、プラットフォーム利用料とは別に実装サービスの費用を請求していた。

小規模な基幹システム開発でも成立するか

FDE の原型は大型エンタープライズ向けだが、同じ考え方を小規模な基幹システム開発に当てはめることはできる。ただし「成立するか」は条件次第だ。

成立しやすい条件

自社プロダクトやプラットフォームが存在する場合。 FDE は特定のプロダクトを顧客環境に適合させるために動く。スクラッチ開発をゼロから請け負うのではなく、「自社の基盤 × 顧客の要件」という構図が必要だ。SaaS プロダクトを持つ会社や、標準的なプラットフォーム（例: ローコードツール、ERP パッケージ）の上に乗るシステムなら FDE モデルが機能しやすい。

顧客側に業務知識のある担当者がいる場合。 FDE が技術を担う代わりに、顧客側は業務要件を出す役割を担う。この分業が成立しないと、FDE が要件定義と実装の両方を抱えることになり、工数が倍増する。

導入後も継続的な関与が見込める場合。 小規模でも、一度入れたシステムには改修・拡張・障害対応が発生する。FDE モデルの旨味は「最初の実装で終わらない関係」にある。単発案件では通常のシステム開発と差がなくなる。

成立しにくい条件

フルスクラッチで要件定義から納品まで丸ごと受ける場合。 これは請負開発であり、FDE ではない。FDE は既存プロダクトの「最後の 20%」を顧客ごとに作るポジションで、ゼロからすべてを作るロールとは異なる。

顧客規模が FDE コストに見合わない場合。 小規模な基幹システムでも、FDE が 3〜6 ヶ月関与するとそれなりの費用になる。顧客の予算規模や期待する成果と釣り合っていないと、コスト過多になる。

小規模での現実的な当てはめ方

完全な Palantir 型の FDE を小規模案件に持ち込む必要はない。「FDE 的な働き方」として取り込める要素を選ぶ方が実用的だ。

具体的には、既製品・SaaS・プラットフォームを組み合わせた構成を前提に、顧客業務に合わせた実装部分だけを担い、システムの定着まで関与する形だ。スクラッチで全部作るより導入コストが下がり、FDE としての専門性が活きる。

まとめ

観点 内容
起源 Palantir が大型エンタープライズ向けに確立したロール
ポジション エンジニアリングとカスタマーサクセスの交差点。顧客先でコードを書く
他ロールとの違い プリセールス SE（契約前）・CS（実装しない）とは異なる
ビジネスモデル 高 ACV 契約のリテンション貢献 or プロフェッショナルサービスとして独立採算
小規模基幹への適用 自社プロダクトや標準基盤あり・継続関与あり・顧客に業務担当者ありなら成立しうる
成立しない条件 フルスクラッチ請負・単発案件・顧客予算が工数に見合わない

FDE は「プロダクトを持つ側」が顧客の現場に入り込み、導入の最後の 1 マイルを技術力で埋めるポジションだ。日本でも B2B SaaS の成熟とともにこのロールの需要は高まっている。小規模な基幹システム開発では完全な形での適用は難しいが、「自社プラットフォーム × 顧客固有実装 × 継続関与」という設計にすれば FDE 的なモデルを組み込む余地はある。