FDEの働き方Q&A｜1日の流れ・常駐・きつさを想定問答で読む

「FDEは出張・常駐が多いと聞くけれど、実際どれくらいなのか」「二重プレッシャーというが、何が二重なのか」——検索窓にそう打ち込んだことがある人は少なくないはずだ。求人票の職務要件や年収レンジだけを眺めていても、現場の温度感は伝わってこない。

※本記事は想定問答です。実在の人物への取材ではなく、出典に示す公開情報をQ&A形式に再構成しています。Palantir公式ブログやPragmatic Engineer、PostHogブログなど、一次情報として裏の取れた記述だけを再構成の材料にしました。想像や誇張は含みません。

以下、現役FDEに聞きたい8つの質問に、公開情報を通して答える。

Q. 1日はどう流れますか

午前・午後・夕方でモードが切り替わる、というのが実態に近い。午前は顧客とのスタンドアップやスコープ調整のミーティング、午後は顧客のインフラ上での実装、夕方は障害トリアージと、本社（HQ）のプロダクトチームへの学びのフィードバックに充てる（blog.palantir.com）。

コードを書く時間だけが仕事ではない。顧客のリポジトリにコミットし、顧客の本番・認証・デプロイの制約の中で開発を進める。時間配分は大きく3領域——①顧客案件（主軸）②プラットフォーム改善③社内タスク——に分かれ、コードを書く週とスコープ設定に費やす週とで比率は変動する（posthog.com/blog、recruitingfromscratch.com）。

Q. 常駐・出張はどのくらいの頻度ですか

稼働全体の25〜50%が常駐・オンサイトに充てられる。この数値は複数の一次情報で一致しており、FDEという職種を理解するうえで確度の高いデータの一つだ（blog.palantir.com、fdepulse.com、underdog.io）。

なぜここまで比率が高いのか。理由は職種の成り立ちに遡る。初期の顧客がCIA・NSA・米陸軍などで、データが機微かつ独自構成でリモート納品が不可能だったため、現地に入って構築する必然が生まれた。たまたま出張が多いのではなく、出張しないと成立しない仕事として設計されている。

Q. 二重プレッシャーとは具体的に何ですか

顧客側と社内側、2つの主体から同時に評価される構造を指す。顧客側からは、現地で本番を止めないこと、約束した成果を出すこと。社内側からは、現場で得た学びをプロダクト本体にフィードバックし、他の案件にも展開できる形に一般化することを求められる。

どちらか一方だけをやっていればよい仕事ではない。顧客対応に全振りすればプロダクトチームからの評価が下がり、プロダクト還元に気を取られれば顧客の信頼を損なう。この綱渡りが常態化する点が、FDEという職種を特徴づける決定的な差別化要因でもある——顧客と直接働くことと、自社プロダクトに学びを還元することの二重性だ。

Q. 一番きついと感じるのはどんな時ですか

複数の情報源が一致して指摘する要因を並べると、輪郭が見えてくる。出張負荷が25〜50%を占め燃え尽きの主因になっていること、二重プレッシャーに常時さらされること、常時ブロッカー解除役を期待され消耗すること、そして自社のエンジニア文化から孤立しやすいこと——顧客先に単独または2名体制で入ることが多いためだ（fdepulse.com、underdog.io、posthog.com）。

特に見落とされがちなのが孤立だ。オフィスで同僚と雑談しながら知見を共有する機会が構造的に少ない。慣れない本番環境への責任と、案件ごとのコンテキストスイッチが重なり、燃え尽びリスクが積み上がっていく（詳しくはこちら）。

Q. それでも続けている理由・やりがいは何ですか

直接的な顧客インパクトが挙げられる。自分の書いたコードが顧客の本番環境で動き、業務が実際に変わる手応えを得やすい。技術的な多様性、課題設定から運用までを1人が担うend-to-endオーナーシップ、そして「スタートアップCTOに近い」とPalantirが公式に表現する裁量の大きさも、続ける理由として語られる。

きつさとやりがいは別軸の話ではない。責任の重さそのものが、顧客インパクトの実感と表裏一体になっている構造だ。

Q. 技術力と対人スキル、どちらがより問われますか

どちらか一方ではなく、両方の掛け算——いわゆる両利き（bilingual）であることが本質だ。技術面ではPython・TypeScript/React・SQL・Spark・AWS/GCP・Docker・Kubernetes・API統合・システム設計。AI領域のFDEであればLLM基礎・RAGパイプライン・ベクトルDB・MLOps基礎も加わる。対人面では顧客折衝・ステークホルダー管理、ビジネス要件を技術へ翻訳する力、曖昧さへの耐性が求められる（secondtalent.com、fde.academy）。

学歴よりも技術の幅とコミュニケーション、曖昧さ耐性の方が評価される、という点は繰り返し語られる論旨だ。

Q. セールスエンジニアやコンサルと何が違いますか

もっとも整理しやすい対比はこうだ。セールスエンジニアは契約を結ばせる、ソリューションエンジニアは結んだものを設計する、FDEは本番で動かし続ける。OpenAI社内の定義でも、FDEは顧客インフラ上で顧客のツールを使いコードを書く一方、Solutions Architectは匿名化データでのオフラインMVP構築が主とされる（pragmaticengineer.com）。

コンサルとの違いは諸説あるが、コンサルは戦略・設計図までを担い、FDEは実装から現場定着までを手を動かして完遂するという理解が有力だ。日本では「エンジニアとコンサルの第3の選択肢」と位置づけられることが多い。

Q. 未経験からFDEを目指すには何から始めればいいですか

最有力とされる前職はアーリーステージ・スタートアップでの経験だ。「最初の10人のエンジニア」が担う仕事は、すでにFDE的な働き方に近い。ハンズオンなソリューションアーキテクト経験も強みになり、目安として5年以上の実務経験（顧客対応を含む）が語られる（recruitingfromscratch.com）。

日本ではFDEという肩書きでの実務経験者自体がまだ少なく、隣接職からの転身が現実的なルートになる。戦略コンサル、データサイエンティスト・MLエンジニア、SIer・SE出身、PMがその代表だ。米国では中央値約$190,000（求人135件分析）、日本の実求人でも1,000万〜2,500万円という水準（年収の内訳はこちら）が、この働き方に踏み出す動機の一つになっている。

まとめ

3つの要点に絞ると、次のようになる。第一に、常駐25〜50%という数字は「出張が多い」のではなく「出張しないと成立しない職種設計」から来ている。第二に、きつさの正体は出張負荷そのものより、顧客と社内の二重プレッシャー、そして自社文化からの孤立にある。第三に、それでも語られるやりがいは、顧客インパクトの実感とend-to-endオーナーシップという、責任の重さと表裏一体の手応えだ。

FDEとは何かを読んでからこのQ&Aに戻ると、働き方の輪郭がより具体的に像を結ぶはずだ。冒頭の「二重プレッシャーとは何か」という問いは、ここまで読めば自分の言葉で説明できるようになっているだろうか。

あわせて読みたい

• FDEのリアル｜仕事のやりがい・きつさ・1日の流れを解説
• Forward Deployed Engineer（FDE）とは？仕事内容と注目される理由
• FDE（フォワードデプロイドエンジニア）の年収は？米国・日本の実データ