Forward Deployed Engineer(FDE)を目指す — 本当に必要なソフトウェア知識の地図

はじめに — FDEとは何をする人か
中核となるソフトウェア知識の地図
不慣れな環境でのデバッグ、そしてセキュリティの基礎
FDEは純粋なSWEとどう違うのか
おわりに
参考資料

はじめに — FDEとは何をする人か

Forward Deployed Engineer(FDE)はPalantirが生み出した職種です。PalantirはこれをFDSE(Forward Deployed Software Engineer)、社内では「Delta」と呼びます。核心はPalantir自身の一文に要約されます — 一般的なエンジニアが「多くの顧客のための1つの機能」を作るのに対し、FDEは「1人の顧客のための多くの機能」を作ります。つまり新しい製品を作る人ではなく、すでにある製品を顧客の実環境に入り込んでデプロイ・統合・設定し、問題を解く人です。

一般的なSWE : 多くの顧客のための「1つの機能」   (one capability   -> many customers)
FDE         : 1人の顧客のための「多くの機能」   (many capabilities -> one customer)

The Pragmatic Engineerによれば、FDEは3つの領域が重なる場所にいます。ソフトウェアエンジニアリング、セールス支援(製品が実際に動くことを証明して契約を後押しする仕事)、そしてプラットフォームエンジニアリングです。顧客のオフィス — ときには工場のフロアやエアギャップ(airgapped)網 — に入り込み、ドメインを理解し、解決策を共に作ります。出張の割合は会社によりますが、Palantirは約25%を挙げています。

この古い職種が最近再び盛り上がっている理由はAIです。The Pragmatic Engineerによれば、OpenAIは2025年にFDEチームを立ち上げ、8都市に10人を超えるFDEが顧客インフラ上で直接コードを書いています。AnthropicのFDE(Applied AI)は、顧客システムの中でClaudeモデルを使いプロダクションアプリケーションを作ります — プロダクション級のPython・TypeScriptで、エージェントワークフロー、RAGパイプライン、コンテキスト管理、MCPベースのツールを書きます。

パイロットを本番の大規模展開へ移すことが企業AI最大の壁であり、FDEはまさにその壁を突破する人です。だからこそこの職種は、「コードも書き、顧客とも会い、他人のインフラで最後まで責任を持つ」人を求めます。

中核となるソフトウェア知識の地図

FDE準備の核心は「1つを深く」ではなく「顧客環境で出会うほぼすべての層を実務レベルで」です。いわゆるT字型 — 広い土台の上に、必要な箇所だけ深く — に近い形です。

実際、Palantirの求人はPython・Java・C++・TypeScriptを、Anthropicの求人はPython・TypeScriptを求めます。ただし言語は入場券にすぎず、本当の試験は、その言語で自分が作っていないシステムを読み解くことです。層ごとに見ると:

Linux とシステムの基礎。 他人のサーバーにSSHで入り、systemdサービス、プロセス、ファイルディスクリプタ、cgroup、メモリ・スワップを読み取れる必要があります。FDE業務の半分は「なぜこのマシンだけで動かないのか」です。
ネットワーク。 DNS、TLS、プロキシ、ファイアウォール、curlでのエンドポイント確認。顧客網は常に開いているわけではありません — エアギャップ・プライベートレジストリ・社内プロキシが既定値です。
コンテナとKubernetes。 イメージのビルドから、なぜPodがPendingなのかまで。オペレーターが状態をどう調整(reconcile)するかの感覚があると大きく有利です — 自分で書いてみた話はRustで書いたKubernetes GPUオペレーターにまとめました。
データベースとSQL。 顧客の本物のデータは、たいてい関係データベースにあります。結合・インデックス・実行計画を読み、HAやフェイルオーバーがどう動くかを知る必要があります — CloudNativePGでプライマリを殺してフェイルオーバーを実測した記事が「本番DBが実際どう耐えるか」の感覚をくれます。
APIと統合。 REST、gRPC、Webhook、OAuth。仕事の本質は自分が作っていない2つのシステムをつなぐことなので、認証・ページネーション・レートリミット・リトライを扱えなければなりません。
データパイプライン。 バッチ対ストリーミング、冪等性(idempotency)、スキーマ変更。顧客データを移動・変換する仕事はほぼ毎回出てきます。
クラウドとアイデンティティ。 顧客はたいていAWS・GCP・Azureの上にいます。IAMのロールとポリシー、VPCとセキュリティグループ、オブジェクトストレージ(S3など)を理解して初めて、デプロイが権限の壁で止まらずに済みます。
シェルスクリプトとGit。 繰り返し作業はスクリプトにまとめ、顧客のリポジトリではブランチとPRで協働します。bash・jq・gitが手に馴染んでいないと、他人の環境では手が遅くなります。

不慣れな環境でのデバッグ、そしてセキュリティの基礎

FDEを純粋なSWEと分ける本当の技術は、自分が作っていないシステムを、ドキュメントも乏しいまま、顧客が見ている前で直す能力 です。ログがどこに溜まるかも分からないクラスターで、根本原因まで絞り込む訓練が要ります。不慣れな箱に初めて入ったときの最初の一手を、あらかじめ手に馴染ませておくとよいでしょう:

# 不慣れな箱に入って最初の10分
uname -a; cat /etc/os-release            # どのLinuxか
systemctl --failed                       # 死んだサービス
journalctl -u myapp --since "1 hour ago"   # 直近のログ
ss -tulpn                                # 開いているポートとリスナー
df -h; free -m                           # ディスクとメモリ
kubectl get pods -A | grep -v Running    # 起動しないPod

たとえば112日間スケジュールされなかったKubeVirt GPU VMの検死記録 — 原因は結局スワップ設定でした — は、他人のインフラで起きる典型的な「なぜ起動しないのか」パズルです。ログ・メトリクス・イベントを素早く眺めて仮説を立てては消す習慣が、不慣れな環境でさまよう時間を何時間も減らしてくれます。

そしてセキュリティは交渉の余地がありません。最小権限、シークレット管理、顧客データの取り扱い規定、監査ログ — 顧客のセキュリティチームは、FDEが最初に通過すべき関門です。AI FDEなら、ここにモデルサービングの知識が加わります。量子化・バッチ・メモリのトレードオフを知って初めて、顧客のGPUにモデルが実際に載ります(LLM量子化の実測を参照)。

FDEは純粋なSWEとどう違うのか

正直に言えば、FDEの道は万人向けではありません。以下の性質は魅力であると同時に、人を選ぶポイントでもあります。

深さより広さ。 1つの言語・1つのスタックのマスターになりたいなら、FDEはもどかしく感じるかもしれません。FDEは浅く広く、必要なら一晩で深くなる人です。
曖昧さが既定値。 きれいに書かれた要件チケットは届きません。Palantirがこの役割を「スタートアップのCTOに近い」と表現する理由です — スコープと優先順位を自分で決めます。
顧客との接点。 コードをうまく書くことと同じくらい、役員に説明し、反対意見を扱い、信頼を築くことが重要です。コミュニケーションは副次的なスキルではなく、中核の業務です。
出張と現場。 25%(ときにそれ以上)の出張、不慣れなセキュリティ環境、顧客のカレンダーに縛られる圧力。これに活力を得る人も、消耗する人もいます。
キャリアの方向。 FDEの経験は、システム・製品・顧客をまたぐ稀な幅を育てます — ソリューションアーキテクト、スタッフエンジニア、起業へとつながりやすい道です。ただしコンパイラやDB内部のような深い専門化が目標なら、この幅がかえって遠ざける場合があります。

おわりに

FDEの準備は資格のリストというより、態度に近いものです。不慣れなシステムの前で固まらず、知らない層を素早く実務レベルまで引き上げ、それを顧客の前で説明すること。上の知識地図 — Linux・ネットワーク・コンテナ・DB・API・パイプライン・デバッグ・セキュリティ — を1つずつ実際に手で試すのが、最速の準備です。画面の中のチュートリアルではなく、本物のクラスターを立ち上げて本当に殺してみる経験こそが、FDEの言葉です。

これらの性質にわくわくするなら、これほどの幅をこれほど速く教えてくれる仕事はそう多くありません。逆に一つの井戸を深く掘りたい人なら、それを承知で入るほうがお互いにとって良いはずです。