FDEのリアル｜仕事のやりがい・きつさ・1日の流れを解説

「裁量が大きい」「年収が高い」——FDE（Forward Deployed Engineer）を調べ始めると、まずこの二つの言葉にぶつかる。たしかにそれは事実だ。だが、実際に働く時間の中身を数字で見ていくと、印象はすこし変わってくる。常駐比率25〜50%。この数字が何を意味するのか、脚色せずに追ってみる。

FDEの1日はどう流れるか

朝はまず顧客とのMTGから始まる。スコープ調整、要件のすり合わせ——ここまでは普通のエンジニア職と大差ないように見える。だが午後になると景色が変わる。書くのは自社の開発環境向けのコードではない。顧客のインフラの上で、顧客の本番環境に向けて、コードを書く。

夕方は障害対応と社内フィードバックに充てられる。トリアージをこなしたあと、本社（HQ）のプロダクトチームへ現場の学びを持ち帰る。

時間帯	内容
午前	顧客とのMTG・スコープ調整
午後	顧客インフラ上での実装（本番コードを書く）
夕方	障害トリアージ＋本社（HQ）プロダクトチームへの学びのフィードバック

この1日で特徴的なのは、コードを書く時間そのものより「場所」の性質だ。顧客のスタンドアップに参加し、顧客のリポジトリにコミットし、顧客の本番・認証・デプロイ制約の中で開発を進める。時間配分はおおむね①顧客案件（主軸）②プラットフォーム改善③社内タスクの3領域に分かれ、コードを書く週とスコープ設定に費やす週とで比率が揺れる。固定されたルーティンはない。

常駐比率25〜50%が意味すること

なぜここまで出張・常駐が発生するのか。

答えは職種の定義そのものにある。FDEの中核は「課題スコープ設定から構築、本番運用までを同一エンジニアがend-to-endで担う」という責任の一貫性だ。顧客のデータは機微で、構成も独自であることが多い。リモート納品では手が届かない部分が必ず残る。だから現地に入る。

複数の一次情報が一致してこの数字を示している——稼働全体の25〜50%が常駐・オンサイトだ。FDEを理解するうえで最も確度の高いデータの一つと言っていい。裏を返せば、これは「たまたま出張が多い仕事」ではない。「出張しないと成立しない仕事」だということになる。出張負荷は付随的なコストではなく、責任一貫性という設計そのものが生む必然だ。

二重プレッシャーの構造

顧客の信頼さえ守ればいい、という話なら単純だった。

FDEのきつさの核心は、顧客と社内という2つの主体から同時に評価・要求を受ける構造にある。

• 顧客側からの圧力: 現地で本番を止めないこと、約束した成果を出すこと、信頼を維持し続けること
• 社内側からの圧力: 現場で得た学びをプロダクト本体にフィードバックすること、他の顧客案件にも展開できる形に一般化すること

「顧客と直接働く」ことと「自社プロダクトに学びを還元する」こと。このどちらか一方だけをやっていればよい仕事ではない。顧客対応に全振りすればプロダクトチームからの評価が下がる。プロダクト還元に気を取られれば、顧客の信頼を損なう。綱渡りが常態化する。他のエンジニア職やコンサル職には見られない、この職種特有のストレス源だ。

きつさの正体 — 燃え尽きリスク

出張、二重プレッシャー。ここまでの要素は、単独なら乗り越えられる範囲かもしれない。問題は、これらが同時に降ってくることだ。

複数の情報源が一致して指摘する、燃え尽きにつながる要因を整理すると次のようになる。

• 出張負荷が稼働の25〜50%を占め、燃え尽きの主因になっている
• 顧客と社内の二重プレッシャーに常時さらされる
• 常時ブロッカー解除役を期待され、精神的に消耗しやすい
• 自社のエンジニア文化から物理的・心理的に孤立しやすい（顧客先に単独または2名体制で入ることが多い）
• 慣れない本番環境への責任と、案件ごとのコンテキストスイッチが重なり、燃え尽きリスクが高まる

なかでも見落とされがちなのが「自社文化からの孤立」だ。オフィスで同僚と雑談しながら知見を共有する機会が、構造的に少ない。顧客先での孤独な意思決定が続く。コードを書く技術者としての側面と、顧客の期待値をコントロールする対人折衝の側面。この二つを1人で往復し続けるからこそ、認知的な負荷も高くなる。燃え尽きは、この積み重ねの先に語られている。

それでも語られるやりがい

ここまで読むと、割に合わない仕事に見えるかもしれない。だが、FDEという働き方には他の職種では得にくいやりがいも確かに存在する。

• 直接的な顧客インパクト: 自分が書いたコードが、抽象化されたプロダクトの一機能としてではなく、目の前の顧客の業務そのものを動かす
• 技術的多様性: 案件ごとにドメイン・スタック・制約が異なり、同じ仕事の繰り返しにならない
• end-to-endオーナーシップ: スコープ設定から本番運用までを一貫して自分が担うため、途中で仕事が他部署に渡って成果が見えなくなることがない
• スタートアップCTO的裁量: 少人数で顧客の課題に向き合う構造は、Palantir自身が「責務はスタートアップCTOに近い」と表現するほどの裁量を伴う

きつさとやりがいは、別の場所にあるのではない。同じ構造の裏表として存在している。

やりがいときつさの対比

観点	やりがい	きつさ
顧客との関係	成果が直接顧客の業務に反映される実感	顧客からの期待値管理と信頼維持の常時プレッシャー
働き方	end-to-endで裁量を持って進められる	出張・常駐が稼働の25〜50%を占める
組織との関係	プロダクト本体に学びを還元できる手応え	社内文化からの孤立、二重プレッシャー
技術的側面	案件ごとの多様な技術課題に触れられる	コンテキストスイッチの多さによる消耗
中長期	スタートアップCTO的裁量、キャリアの伸びしろ	燃え尽きリスクが高い働き方

この働き方が向いている人・向いていない人

では、誰がこの働き方に向いているのか。

出張・常駐に抵抗が少なく、顧客との折衝そのものにやりがいを感じられる人には向いている。逆に、安定したチーム文化の中でじっくり技術を深めたい人、あるいはプライベートの予定を固定しやすい働き方を優先したい人にとっては、常駐比率の高さと二重プレッシャーが大きな負担になりやすい。年収レンジの高さだけを見て意思決定すると、入社後にこのギャップに気づくことになる。働き方の構造そのものが自分に合うかどうかを、先に見極めておく必要がある。

まとめ

冒頭の「裁量が大きい」「年収が高い」という言葉に戻ろう。それ自体は嘘ではない。だが、その裏側には常駐比率25〜50%・顧客と社内の二重プレッシャー・自社文化からの孤立という構造が張り付いている。やりがいときつさは切り離せない一枚のコインであり、どちらか一方だけを見て決めると入社後のギャップにつながる。FDEという職種そのものの成り立ちや他職種との違いを理解したい場合は「Forward Deployed Engineerとは何か」、キャリアパスの具体的なルートを知りたい場合は「FDEになるためのキャリアパス」、年収の相場感を確認したい場合は「FDEの年収」もあわせて参照してほしい。

あわせて読みたい

• Forward Deployed Engineerとは何か
• FDEになるためのキャリアパス
• FDEの年収