FDE の全体像 — セールスエンジニアでもない、カスタマーサクセスでもない

翌朝9時。渋谷のオフィス近くにある、焙煎所を兼ねたコーヒーショップ。

ソウタがカウンターに着くと、カイはすでに奥のテーブルに座り、iPad Pro を開いて Apple Pencil で何かを描いていた。テーブルにはエスプレッソが2杯。

「おはようございます。昨日の話、一晩考えたんですけど」

ソウタはカバンからノートを取り出した。夜中に書き殴ったメモが3ページ分ある。

「FDE って、要はソリューションアーキテクトですよね？　顧客のシステムに合わせた設計をして、実装まで面倒を見る」

カイは首を振った。

「違う。SA は設計図を描くところまでが仕事だ。FDE は設計図を描いて、それを自分で建てて、住人が住めるようにして、鍵を渡すところまでやる」

「じゃあ、セールスエンジニアの延長？」

「それも違う。SE は契約を取るためにデモを作る。FDE は契約が済んでから本番環境にコードを入れる」

ソウタは腕を組んだ。シニアエンジニアとして5年。自分が知っている職種のどれにも、カイの仕事はぴったり当てはまらない。

「ちょっと整理しよう」

カイが iPad を回転させてソウタに見せた。画面には6つの職種が並んでいる。

6つの隣接ロールとの比較

「エンジニアリングと顧客の間にいる職種は6つある。FDE はそのどれとも違うし、どれとも重なる」

カイが iPad に描いた比較表をソウタは食い入るように見た。

ソウタは「コーディング比率」の行で手が止まった。

「FDE、70〜90% もコード書くんですか。SE の10〜20% と全然違う」

「そう。そこが一番の違いだ。SE はデモのために書く。FDE は本番環境のために書く。コードの寿命が全く違う」

ライフサイクル上のポジション

「もう少し視覚的に見せよう」

カイが iPad に新しいページを開き、顧客ライフサイクルの図を描き始めた。

「注目してほしいのは、SA から FDE への点線だ」

カイが点線を指差した。

「FDE はポストセールスが主戦場だけど、契約前の技術検証フェーズにも引っ張り出されることがある。顧客の既存システムが複雑すぎて、SA だけでは『本当に統合できるか』を判断できないケースだ」

ソウタは頷いた。TechNova でも、大企業向けの商談で「御社の基幹システムと本当につながるんですか」と聞かれて答えに窮した経験がある。

「つまり FDE は、プリセールスの最後尾とポストセールスの最前線にまたがる存在なんですね」

「そういうことだ。どちらにも属さないから、組織図上で居場所を作るのが難しい。エンジニアリング部門に置く会社もあれば、プロダクト部門に置く会社もある」

コーディングの質の違い — SE vs FDE

「コード書く比率が違うのはわかりました。でも具体的にどう違うんですか？」

ソウタの質問に、カイは「いい質問だ」と言って iPad に2つのコードブロックを並べた。

「例えば、TechNova の分析 API を顧客の既存 Rails システムに統合する案件があるとする。SE とFDE で、書くコードがこう変わる」

SE が商談用に書くデモコード

# SE のデモ: 5分で動くことを見せるのが目的
# エラー処理なし、認証はハードコード、本番では使えない
class DemoController < ApplicationController
  def analyze
    response = HTTP.post("https://api.technova.io/analyze",
      json: { text: params[:text] },
      headers: { "Authorization" => "Bearer sk-demo-12345" }
    )
    render json: response.parse
  end
end

「これはこれで正しい。商談の場で『こんなに簡単に繋がりますよ』と見せるのが目的だから」

FDE が本番環境に入れるコード

# FDE の実装: 顧客の本番環境で年単位で稼働する
class TechnovaClient
  include ActiveSupport::Configurable
 
  RETRY_WAIT = [1, 2, 4].freeze # 指数バックオフ（秒）
 
  config_accessor :api_key, :endpoint, :timeout
 
  def initialize
    @connection = Faraday.new(url: config.endpoint) do |f|
      f.request  :json
      f.response :json
      f.request  :retry, max: 3, interval: 0.5,
                 retry_statuses: [429, 500, 502, 503]
      f.adapter  Faraday.default_adapter
    end
  end
 
  def analyze(text:, locale: :ja)
    validate_input!(text)
 
    response = with_circuit_breaker do
      @connection.post("/v2/analyze") do |req|
        req.headers["Authorization"] = "Bearer #{config.api_key}"
        req.headers["X-Request-ID"]  = SecureRandom.uuid
        req.options.timeout          = config.timeout || 30
        req.body = { text: text, locale: locale }
      end
    end
 
    parse_response(response)
  rescue Faraday::TimeoutError => e
    Rails.logger.error("[TechNova] Timeout: #{e.message}")
    raise TechnovaTimeoutError, "分析APIがタイムアウトしました"
  rescue Faraday::ClientError => e
    handle_client_error(e)
  end
 
  private
 
  def validate_input!(text)
    raise ArgumentError, "テキストが空です" if text.blank?
    if text.length > 10_000
      raise ArgumentError, "テキストが上限(10,000文字)を超えています"
    end
  end
 
  def with_circuit_breaker(&block)
    CircuitBreaker.call(
      service: :technova,
      threshold: 5,
      timeout: 60,
      &block
    )
  end
 
  def parse_response(response)
    unless response.success?
      raise TechnovaApiError,
            "API Error #{response.status}: #{response.body['error']}"
    end
 
    TechnovaResult.new(response.body)
  end
 
  def handle_client_error(error)
    case error.response_status
    when 401
      raise TechnovaAuthError, "APIキーが無効です。管理者に連絡してください"
    when 429
      raise TechnovaRateLimitError, "レートリミットに達しました"
    else
      raise TechnovaApiError, "予期しないエラー: #{error.message}"
    end
  end
end

ソウタはコードを見比べて黙った。SE のデモコードは10行。FDE の本番コードは70行超。しかし、違いは行数だけではない。

「リトライ、サーキットブレーカー、入力バリデーション、エラーの種類ごとのハンドリング......これ、普通に SWE が書く本番コードですね」

「そう。FDE は SWE なんだ。ただし、自分のチームのプロダクトではなく、顧客のプロダクトにコードを入れる SWE だ」

「Forward Deployed」の語源

ソウタはふと疑問に思った。

「そもそも、なんで "Forward Deployed" なんですか？　"Field Engineer" とか "Client Engineer" じゃダメなんですか」

カイはコーヒーを一口飲んでから答えた。

「軍事用語だ。"前方展開" — 部隊を前線に配置すること。英語だと forward deployment。司令部（HQ）にいるんじゃなくて、戦場の最前線に展開される」

「つまり、エンジニアが顧客の"戦場"に展開される、と」

「そういうことだ。"Field Engineer" だと、現場で開発する人に聞こえる。でも FDE はフィールドで開発するんじゃない。自分のスキルを前方に展開して、顧客の本当の問題がある場所に行く。開発の場所じゃなくて、問題の場所が "forward" なんだ」

カイが iPad に図を描いた。

「Field Engineer は "出張するエンジニア"。Forward Deployed Engineer は "前線に配備されたエンジニア"。マインドセットが違う。出張は帰る場所がある。配備は、そこが持ち場になる」

企業ごとに異なる FDE の定義

「FDE って呼び方は Palantir が最初ですよね？」

ソウタの質問に、カイは頷いた。

「そう。2010年代初頭、Palantir が最初に使った。でも今は、同じ役割を別の名前で呼ぶ企業が増えている。逆に、FDE と名乗っていても中身が違うこともある」

カイが iPad に企業リストを書き始めた。

Palantir — FDE の原点

2010年代、Palantir は米国政府や情報機関向けにデータ分析プラットフォーム Gotham を提供していた。しかし、政府機関のシステムは複雑で、API ドキュメントを渡して「あとは自分で」では絶対に動かない。

そこで Palantir は、エンジニアを文字通り顧客の施設に「前方展開」した。機密施設の中で、顧客のデータパイプラインを理解し、Gotham との統合コードを書き、現場のアナリストにトレーニングを行う。FDE という名前は、この「前線に配備されたエンジニア」から来ている。

Palantir の FDE が特殊なのは、顧客環境のセキュリティクリアランスが必要な点だ。コードを GitHub に push することもできない。隔離されたネットワーク内で、顧客のデータだけを見ながら開発する。これは極端な例だが、「顧客の環境制約の中で成果を出す」という FDE の本質が最も純粋に現れている。

OpenAI — AI 時代の FDE

OpenAI の FDE チームは、エンタープライズ顧客が GPT-4 を本番環境にデプロイする支援を行う。プロンプトエンジニアリング、API 統合、データパイプラインの構築が主な仕事だ。

特徴的なのは、顧客の業務ドメインを深く理解した上で、プロンプトを設計する点だ。法律事務所向けと製造業向けでは、同じ GPT-4 でもプロンプトの設計思想が全く異なる。

OpenAI の FDE は、従来の FDE と違ってコードだけでなく「プロンプト」も成果物になる。プロンプトは自然言語で書かれるが、そのチューニングにはエンジニアリング的な思考 — 入力の正規化、出力の検証、エッジケースの処理 — が不可欠だ。

Anthropic — 安全性を重視した FDE

Anthropic の FDE は OpenAI に似ているが、安全性と責任あるデプロイメントに重点を置く。顧客が Claude を導入する際、モデルの出力が規制要件を満たすかの検証まで踏み込む。金融や医療など規制産業の顧客が多い。

具体的には、モデルの出力に対するガードレールの設計、PII（個人識別情報）の検出とマスキング、監査ログの実装など、AI の「安全に動かす」部分を担う。プロンプト設計だけでなく、AI を取り巻くインフラ全体を設計する点が特徴だ。

Stripe — Implementation Engineer

Stripe は FDE を "Implementation Engineer" と呼ぶ。大規模加盟店が Stripe の決済基盤を統合する際、数ヶ月単位で寄り添う。決済は1行のミスが数億円の損失につながる世界だ。FDE のコードには、通常の SWE 以上の正確性が求められる。

Stripe の Implementation Engineer が扱うのは、Webhook のリトライ設計、冪等性キーの管理、PCI DSS 準拠のカード情報取り扱い、複数通貨の端数処理など、決済ドメイン固有の複雑さだ。Rails で書くと、こんなコードになる。

# Stripe Webhook の冪等な処理 — FDE が顧客環境に実装する
class StripeWebhooksController < ApplicationController
  skip_before_action :verify_authenticity_token
 
  def create
    event = construct_event
    return head :ok if already_processed?(event.id)
 
    ActiveRecord::Base.transaction do
      record_event!(event.id)
      handle_event(event)
    end
 
    head :ok
  rescue Stripe::SignatureVerificationError
    head :bad_request
  end
 
  private
 
  def already_processed?(event_id)
    ProcessedStripeEvent.exists?(stripe_event_id: event_id)
  end
 
  def record_event!(event_id)
    ProcessedStripeEvent.create!(stripe_event_id: event_id)
  end
end

「SE だったらこの Webhook 処理は書かない」とカイは言った。「デモでは『Stripe から通知が来ます』と口で説明するだけだ。FDE は冪等性の保証まで含めて本番コードを書く」

Google — Customer Engineer

Google Cloud の "Customer Engineer" は、SE と FDE のハイブリッドだ。プリセールスのデモも行うし、ポストセールスの技術支援も行う。Google のプロダクトラインが広いため、特定領域（BigQuery、GKE、Vertex AI など）のスペシャリストとして動くことが多い。

Google が「FDE」ではなく「Customer Engineer」と名付けたのは意図的だ。Google は FDE の役割をプリセールスまで広げたかった。契約前から顧客と技術的な関係を構築し、契約後もシームレスに支援を続ける。ライフサイクルの分断を嫌った結果、一つの職種で全期間をカバーする設計にした。

Databricks — Resident Solutions Architect

名前は "Solutions Architect" だが、実態は FDE だ。顧客のデータ基盤に入り込み、Spark のジョブを最適化し、データパイプラインを構築する。「アーキテクト」と名乗りながら70% 以上コードを書いている。

"Resident" という接頭辞がポイントだ。一時的な訪問者ではなく、顧客環境に「常駐する」エンジニア。Databricks のプロダクトは技術的に深いため、顧客のデータエンジニアと数ヶ月間一緒に働かないと、本当の価値を引き出せない。

Ramp — FDE

Ramp の FDE チームは、エンタープライズ顧客向けにカスタムの経費管理・財務統合を構築する。ERP システムとの連携、会計ソフトとの同期、社内承認ワークフローの組み込みなど、顧客の業務プロセスに深く入り込む。

Ramp は FDE という名前をそのまま使っているが、金融ドメインの特殊性がある。会計基準（GAAP）の理解、税務ルールの知識、監査対応の設計など、純粋な技術力だけでは務まらない。ドメイン知識とエンジニアリングの両方を高い水準で求められる典型例だ。

ソウタは企業リストを見ながら言った。

「面白いですね。名前は違っても、共通するのは "顧客の現場でプロダクションコードを書く" という点だ」

「そう。それが FDE の本質だ。名前は会社によって違う。でも、役割の核心は同じだ」

ソウタはもう一つ気づいた。

「それと、どの企業も『プロダクトが複雑すぎて、ドキュメントだけでは導入できない』という共通の課題を抱えていますね。FDE が必要になる条件は、プロダクトの複雑さなんだ」

カイは頷いた。

「鋭い。FDE が存在する企業のプロダクトには共通点がある。セルフサーブで導入できないレベルの技術的複雑さ、顧客環境との統合が不可欠なアーキテクチャ、そして導入の失敗がビジネスに大きな損失をもたらすステークスの高さ。この3つが揃うと、FDE が必要になる」

FDE スキルのベン図

「じゃあ、FDE に必要なスキルを整理してみよう」

カイが iPad に3つの円を描いた。

「FDE は3つのスキルの交差点にいる」

カイが一つずつ説明した。

エンジニアリング（コード力） — 本番品質のコードを書ける。顧客の既存コードベースを読み解ける。パフォーマンス、セキュリティ、保守性を考慮した設計ができる。ここが弱いと、ただの「技術がわかる営業」になる。

ソウタは思い当たる節があった。TechNova の営業に同行したとき、顧客のCTOに「これ、既存のRailsアプリにどうやって組み込むんですか」と聞かれ、営業担当が技術的な回答に詰まった場面があった。

顧客共感（課題理解） — 顧客が言語化できていない問題を発見できる。技術者ではない意思決定者に、技術的な選択肢をわかりやすく説明できる。ここが弱いと、「顧客のことを考えない受託開発者」になる。

「これが一番難しいかもしれない」とカイは言った。「エンジニアは問題を聞くと、すぐに解決策を考え始める。でも FDE に必要なのは、まず相手の言葉を聞いて、その裏にある本当の課題を見抜くことだ。顧客が『レポートの出力が遅い』と言っているとき、本当の問題は『経営会議に間に合わない』かもしれない。技術的な解決策はその次だ」

プロダクト感覚（活用提案） — 自社プロダクトの機能を深く理解し、顧客の課題に対して最適な組み合わせを提案できる。「この機能はこう使えば御社の問題を解決できます」と言える。ここが弱いと、「自社プロダクトを使わないフリーランス」になる。

「プロダクト感覚で重要なのは、"できること" だけじゃなく "できないこと" を正直に伝えられることだ」とカイは付け加えた。「顧客の要件を聞いて、自社プロダクトでは80%しかカバーできないとわかったら、残り20%をどうするかを一緒に考える。無理に100%できると言ってしまうと、あとで地獄を見る」

「普通のエンジニアはエンジニアリングだけ。SE はエンジニアリングとプロダクト感覚。CSM は顧客共感だけ。FDE は3つ全部を高い水準で求められる」

ソウタは唸った。

「......それ、めちゃくちゃ難しくないですか」

「難しい。だから希少で、だから需要がある。そして、これは生まれ持った才能じゃなくて、訓練で身につくスキルだ。特にシニア SWE からの転向は相性がいい。エンジニアリングのベースがあるから、残りの2つを伸ばせばいい」

ソウタは自分のキャリアを振り返った。Rails エンジニアとして5年。コード力はある。でも顧客共感とプロダクト感覚は？　TechNova で顧客の声を直接聞いたことは、ほとんどなかった。

SE は夢を売り、SWE はツールボックスを作り、FDE はそれで完成品を組み立てる

カイがコーヒーカップを置いて言った。

「PostHog の VP of Engineering が言ったことで、すごくしっくり来る表現がある」

SE sells the dream. SWE builds the toolbox. FDE uses the toolbox to build a custom finished product for the customer.

「SE は夢を売る。SWE はツールボックスを作る。FDE はそのツールボックスを使って、顧客専用の完成品を組み立てる」

ソウタはこの表現を噛みしめた。TechNova に当てはめるとこうなる。

SE の仕事: 「TechNova Analytics を導入すれば、御社のユーザー行動を AI が自動分析します」と提案し、デモで可能性を見せる。

SWE の仕事: TechNova Analytics の分析エンジン、API、ダッシュボード、SDK を開発する。汎用的な「ツールボックス」としてのプロダクトを作る。

FDE の仕事: 顧客の既存の Rails アプリに TechNova SDK を組み込み、顧客固有のデータモデルに合わせてイベントトラッキングを設計し、既存の Redash ダッシュボードと統合し、顧客のデータチームが自分たちで運用できるようにトレーニングする。

具体的にはこういうコードだ。

# FDE が顧客環境に実装するイベントトラッキング
# 顧客の既存モデルに合わせたカスタム設計
class TechnovaTracker
  BATCH_SIZE = 100
  FLUSH_INTERVAL = 30.seconds
 
  def initialize(client:, queue: Queue.new)
    @client = client
    @queue  = queue
    start_flush_worker
  end
 
  # 顧客の既存の Purchase モデルに合わせた設計
  def track_purchase(purchase)
    enqueue(
      event:      "purchase_completed",
      user_id:    purchase.customer.external_id, # 顧客独自のID体系
      properties: {
        amount:   purchase.total_with_tax,       # 税込み（顧客の要件）
        currency: purchase.store.default_currency,
        items:    purchase.line_items.count,
        channel:  purchase.origin_channel        # 実店舗 or EC
      },
      timestamp:  purchase.confirmed_at.iso8601
    )
  end
 
  private
 
  def enqueue(event_data)
    @queue.push(event_data)
    flush! if @queue.size >= BATCH_SIZE
  end
end

「このコードの purchase.customer.external_id や purchase.total_with_tax は、顧客のドメインモデルに依存している。ドキュメントには書けない。顧客のコードを読んで、会話して、初めてわかる情報だ」

ソウタは深く納得した。

「SE が売った夢を、FDE が現実にする。SWE が作ったツールボックスを、FDE が顧客に合わせて組み立てる」

FDE が埋める「空白地帯」

ソウタはようやく全体像が見えてきた。

「つまり、既存の職種の間に "空白地帯" があって、FDE はそこを埋める存在なんですね」

「その通りだ。もっと具体的に言うと——」

カイが iPad に最後の図を描いた。

1. SE と SWE の間: SE が「できます」と言った機能を、SWE のプロダクトで実現する方法を設計・実装する
2. プロダクトと顧客の間: 汎用プロダクトを、顧客固有の環境で動くようにカスタマイズする
3. 技術と意思決定の間: 技術的な制約を、ビジネスの意思決定者が理解できる言葉で翻訳する
4. 導入と定着の間: ソフトウェアを入れるだけでなく、組織がそれを使いこなせるようにする

「このどれか一つだけなら、既存の職種でカバーできる。でも4つ全部を一人でやれる人材は、従来の職種分類にいなかった」

ソウタは具体的な場面を思い浮かべた。

「TechNova でまさにその空白地帯を経験しました。去年、大手小売チェーンに Analytics を導入したとき、SE が『簡単に繋がります』と言って契約が決まった。でも、実際には顧客の Rails アプリは Rails 5 系で、TechNova SDK は Rails 7 前提だった。CSM は技術的な問題を理解できず、SE は次の商談に移っていて、SWE はプロダクトのロードマップで忙しい。結局、誰も対応できないまま3ヶ月が過ぎて、チャーンした」

カイは静かに頷いた。

「典型的なパターンだ。どの職種も "自分の仕事" はやっている。SE は契約を取った。SWE はプロダクトを作っている。CSM はヘルススコアを追っている。でも、顧客の環境に入り込んで実際に動くようにする人が誰もいない。それが空白地帯だ」

ソウタは昨日の夜、TechNova のダッシュボードに並ぶ「利用率の低い顧客」のリストを思い出した。あの顧客たちに必要だったのは、より良いドキュメントでもなく、追加のサポートチケットでもなく、現場に入って一緒にコードを書いてくれるエンジニアだったのかもしれない。

「カイさん、もう一つ聞いていいですか」

「どうぞ」

「FDE の一日って、具体的にどんな感じなんですか？　朝起きて何をして、誰と話して、何のコードを書くのか。そこがまだイメージできないんです」

カイは微笑んだ。コーヒーカップを持ち上げ、最後の一口を飲み干す。

「口で説明するより、見てもらったほうが早い。来週月曜日、Arclight AI に来いよ。一日ジョブシャドウイングさせてやる」

「ジョブシャドウイング？」

「俺の横にずっとついて、俺の仕事を全部見る。朝の顧客ミーティングから、昼のコードレビュー、夕方のプロダクトフィードバックまで。実際に見れば、テーブルや図では伝わらないことがわかる」

ソウタは即答した。

「行きます」

カイが立ち上がり、iPad をカバンにしまった。

「じゃあ月曜の朝8時半にエントランスで。早いけど、FDE の一日は顧客のタイムゾーンに合わせて始まるからな」

コーヒーショップを出ると、渋谷の朝の空気はまだ冷たかった。ソウタは歩きながら、今日聞いた話を頭の中で整理していた。

FDE はセールスエンジニアでもない。ソリューションアーキテクトでもない。カスタマーサクセスでもない。DevRel でもない。

顧客の戦場に前方展開され、本番品質のコードを書き、プロダクトを「使える状態」にして届ける。エンジニアリングと顧客共感とプロダクト感覚の交差点に立つ、新しい職種。

そして来週の月曜日、ソウタはその現場を自分の目で見ることになる。