FDEはやめとけ?きつい・デメリットと言われる5つの理由と向かない人の特徴

「FDEはやめとけ」と言われる5つの理由の整理

FDEに対するネガティブな評価は、大きく5つに分けられます。前半の2つ(出張・常駐、曖昧さと成果責任)はFDEという職種に本質的に備わる負荷で、どの会社でも程度の差はあれ存在します。後半の3つ(成果が自分の資産になりにくい、市場価値の懸念、名ばかりFDE)は会社の設計次第で大きく変わる負荷で、応募前の見極めで避けられるものです。

以下、理由ごとに一次情報で何が書かれているかを確認し、見極め方と備え方を示します。FDEという職種そのものの定義や仕事内容を先に知りたい方は、次の記事を参照してください。

関連記事FDEとは?Forward Deployed Engineerの仕事内容・年収・SESとの違い

理由1:出張・顧客先常駐の負荷(求人票の比率記載)

FDEは顧客の現場に入り込む職種なので、出張や顧客先での勤務が一定割合を占めます。この比率は多くの会社が求人票に明記しています。Palantirの「Forward Deployed Software Engineer - Japan Government」(東京、2026年10月時点)は、応募要件に「Ability to travel 25 – 75% required. Varies by location and team.(25〜75%の出張が可能であること。勤務地とチームによって異なる)」と記載しています。勤務形態はハイブリッドで、「顧客と、しばしばオンサイトで働く」ことも社風の説明に書かれています。

OpenAIの「Forward Deployed Engineer - Tokyo」(2026年10月時点)は、週3日のオフィス勤務のハイブリッドで、「Travel is expected in this role, mainly within Japan.(この職務では出張が想定される。主に日本国内)」と記載しています。同社の東京のFDEマネージャー求人は「travel up to 40%, although mainly local(最大40%の出張、ただし主に近距離)」とより具体的です。The Pragmatic Engineerが2025年に各社の求人票を調べた記事でも、Palantirは勤務時間の約25%を顧客先で過ごすことを想定し、ヘルスケアAIのCommureは最大50%と見積もっていると紹介されています。

見極め方と備え方

• 求人票の出張比率を読む。「25〜75%」のように幅がある場合は、面接で配属予定チームの実績値を聞く(Palantirの求人票自身が「勤務地とチームによって異なる」と書いている)
• 出張の範囲を確認する。「主に国内」「主に近距離」と書かれていれば宿泊を伴う出張は限られる。官公庁や製造業の顧客では、外部ネットワークから隔離された環境で作業する可能性も聞いておく
• フルリモートを前提にしている人はFDEと相性が悪い。顧客先に行くこと自体がこの職種の価値の源泉なので、交渉で減らせるものではないと考える
• 家庭の事情で出張の上限がある場合は、オファー前に上限を伝える。比率に幅のある求人ほど、チームによって調整の余地がある

理由2:要件の曖昧さと成果責任(「CTO並みの責任」という求人票の表現)

FDEの2つ目の負荷は、要件が決まっていない状態から始まり、結果に責任を持つことです。Palantirの東京のFDSE求人は「As an FDSE your responsibilities look similar to those of a startup CTO: you'll work in small teams with minimal supervision and own end-to-end execution of high stakes projects.(FDSEの責任はスタートアップのCTOに似ている。最小限の監督のもと小さなチームで働き、重要度の高いプロジェクトの実行を端から端まで担う)」と書いています。求める資質にも「急速に変わる環境、動的に変わる目標、ユーザーとの反復に慣れていること」が挙げられています。

OpenAIでFDE部門を率いるColin Jarvis氏は、The Pragmatic Engineerの取材で「FDEs work in a ton of ambiguity, and often what the customer describes in scoping doesn't match the data/system reality on the ground.(FDEは大量の曖昧さの中で働く。顧客がスコーピングで説明した内容が、現場のデータやシステムの実態と一致しないことがよくある)」と述べています。OpenAIの東京のFDE求人も「スコープ・速度・品質のトレードオフを判断し、納期を守るために計画を調整する」「重要度の高い局面で冷静さと判断力を示す」ことを求め、成功を「本番環境での採用、測定可能な業務インパクト、評価にもとづくフィードバック」で測ると明記しています。

ログラスでFDEを率いる坂本龍太氏は、レバテックLABの取材で、FDEの固有の難しさを「顧客への個別最適化と、自社プロダクトのスケーラビリティという、本来トレードオフになる二つの目標を同時に背負う」ことだと説明しています。顧客の要望に応えるだけでも、プロダクトを守るだけでもなく、両方を成立させる解を自分で見つける必要があります。これが「仕様書どおりに作る」仕事に慣れた人にとって、FDEがきついと感じられる最大の理由です。

見極め方と備え方

• 求人票に「成功の定義」が書かれているかを見る。OpenAIのように本番採用や業務指標で測ると書いてある会社は、成果責任が明確な分、評価の基準も明確。何も書いていない会社は、面接で「FDEの評価指標は何か」を必ず聞く
• 曖昧さの扱い方を面接で逆に聞く。「顧客の説明と現場の実態が違ったとき、過去のFDEはどう対処したか」という質問への答えで、会社がFDEを支える仕組み(検証フェーズ、エスカレーション先、プロダクトチームとの連携)の有無がわかる
• 備えとして、要件を自分で定義した経験を職務経歴書に書けるようにしておく。SIerや受託で「仕様が決まっていない案件を前に進めた」経験は、そのままFDEの適性の証拠になる
• 「最小限の監督」は裏を返せば、困ったときに頼る先が少ないということ。孤立に弱い人は、FDEチームの人数と、同じ顧客に複数人で入る体制かを確認する

理由3:コードや成果が顧客側に残り、自分の資産になりにくい不満

FDEの成果物は顧客の環境で動くシステムと顧客のビジネス成果です。プロダクト開発のエンジニアのように「自分が作った機能が多くのユーザーに使われる」形にはなりにくく、顧客固有の実装は顧客側に残ります。The Pragmatic Engineerが2026年に公開した「FDEの役割は魅力を失いつつあるのか」という記事は、一部のFDE職が「プロダクトチームが作ったソフトウェアを統合するだけで、プラットフォームへの貢献や本格的なソフトウェアエンジニアリングを超える仕事は限られている」状態になっていると指摘しています。

ただし、これはFDEという職種の宿命ではなく、会社の設計の問題です。Palantirはソフトウェアエンジニア(Dev)を「one capability, many customers(1つの機能を多くの顧客に)」、FDE(Delta)を「one customer, many capabilities(1社の顧客に多くの機能を)」と説明しており、FDEが顧客先で解いた課題をプロダクトの機能に戻す構造を前提にしています。The Pragmatic Engineerによれば、Palantirでは2016年のFoundry公開後、多くのFDEがFoundryの開発に戻ってソフトウェアエンジニアとして働くようになりました。顧客先の知見がプロダクトに戻る会社では、FDEの成果は会社の資産になり、本人の経歴にも「どの機能の原型を作ったか」として残ります。

OpenAIの東京のFDE求人も、職務に「現場のパターンをツール・プレイブック・部品に落とし込み、他の人が使えるようにする」「モデルがどこで成功しどこで改善できるかを、ResearchとProductに伝える」ことを含めています。この還流の仕組みが求人票に書かれているかどうかが、理由3の負荷を見分ける最初の手がかりです。

見極め方と備え方

• 求人票に「現場の知見をプロダクトに戻す」趣旨の職務が書かれているか。書かれていなければ、面接で「過去1年にFDEの提案から生まれたプロダクト機能は何か」を聞く。具体例が出てこない会社は、FDEの成果が顧客側に残るだけの構造になっている可能性が高い
• プロダクトチームとの距離を確認する。FDEがプロダクトのリポジトリにコードを入れられるか、ロードマップ会議に出るかで、還流の実態がわかる
• 備えとして、顧客固有の実装でも「汎用化できる部分」を自分で切り出す習慣を持つ。社内ツールやプレイブックとして残せば、顧客が変わっても自分の資産になる
• 職務経歴書には成果物ではなく顧客の成果(業務指標の改善、本番採用の規模)を書く。FDEの市場での評価は、何を作ったかより何を変えたかで決まる

理由4:営業支援寄りになり市場価値が下がる懸念(The Pragmatic Engineerの論点)

「FDEはやめとけ」論で最も重い指摘が、2026年にThe Pragmatic Engineerが公開した論考です。同記事はウォール・ストリート・ジャーナルの報道を引用し、Indeedの求人数が2025年に前年比10倍以上に増え、決算説明会でこの職種に言及した上場企業がAlphaSenseのデータで8社から50社に増えた一方で、採用支援会社Betts Recruitingの幹部が「誰もが欲しがっているのに、この職種を望むエンジニアは市場の1割程度しかいない」と述べていることを紹介しています。

著者のGergely Orosz氏は、2025年の取材で描いたFDE像(ソフトウェアエンジニアリングとプラットフォームエンジニアリングの両方を担う)が、OpenAIやRampでは実現していた一方で、その後に増えたFDE求人の多くは「ソフトウェアエンジニアリングが大幅に減り、プラットフォームエンジニアリングはさらに少ない」実態になっていると分析しています。多くのFDE職が、受注を支援するセールスエンジニアや、ソリューションエンジニア、コンサルタントに近い機能を果たしているという指摘です。記事は「それなりの給与で需要が高いのに、エンジニアの関心が低い職種があるなら、必ず理由がある」と結んでいます。

同記事には、FDE職に就いたあるエンジニアの投稿が引用されています。「このFDEの仕事は典型的なITサービス企業の思考様式だった。会社は私を営業リード側で使いたがり、ソフトウェア開発はほぼゼロだった。これは自分が同意した内容ではなく、職場の雰囲気や文化も好きになれなかった。4週間後に辞めた」という内容です。これは個人の投稿であり、特定の会社や業界全体の事実を示すものではありませんが、「FDEと書かれていても中身が違う」という懸念が海外でも現実に起きていることを示しています。

一方で、The Pragmatic Engineerの2025年の記事は、Salesforceのシニア FDE 求人が10項目の責任を列挙していることを「シニア以上の経験豊富なソフトウェアエンジニアに暗黙に期待される内容と似ている」と評しています。本来のFDEはエンジニアとしての水準を下げる職種ではなく、むしろ上乗せを求める職種です。First Round Reviewの記事でも、Palantirで採用を担当したTiffany Siu氏は、FDEにソフトウェアエンジニアと同じ面接基準を課し、技術力で妥協しなかったと述べています。市場価値が下がるのは「FDEになったから」ではなく「コードを書かないFDE職に就いたから」です。

見極め方と備え方

• 面接で「FDEの1週間のうち、コードを書く時間は何割か」を具体的に聞く。回答が曖昧、または「お客様との関係構築が中心」であれば、求人票の職種名にかかわらずセールスエンジニア職として判断する
• 評価指標が「受注額・商談数」か「本番採用・業務成果」かを聞く。前者なら営業職の設計、後者ならFDEの設計
• 技術面接の有無と水準を見る。コーディング面接やシステム設計面接がないFDE求人は、エンジニアとしての水準を求めていない可能性がある
• 備えとして、入社後も自分の技術ポートフォリオを更新し続ける。LLMを組み込んだ本番システムの設計・評価(Evals)の経験は、FDEを離れてもプロダクト開発側で通用する

補足:FDEモデルは会社にとっても負荷が高い

FDEの負荷を理解するうえで、会社側の事情も知っておくと見極めの精度が上がります。a16zは「Services-Led Growth」という論考で、FDEを含む実装サービスはAI企業がエンタープライズの複雑な業務に入り込むための競争優位だと主張する一方で、批判的な見方として「プロフェッショナルサービスに依存する動きはスケーラビリティを制限し、低い粗利率はプロダクトがコモディティであることを反映している」という議論があることを認めています。a16zはこれに対し、ServiceNowの粗利率がIPO時の63.2%から2024年には79%に改善した例などを挙げて反論していますが、FDEを多く抱える会社が粗利と拡張性の圧力を受けること自体は、業界内で共有された前提です。

この圧力は、FDEの働き方に直接はね返ります。会社がFDEを「売上を立てるための人員」と見なせば理由4の方向に、「プロダクトを育てるための人員」と見なせば理由3の解消の方向に進みます。a16zによれば、OpenAIは当時公開していた311の求人のうち22が実装・導入系の職種でした。プロダクトと導入の両方に投資している会社は、FDEをプロダクト側の人員として扱う可能性が高いといえます。

理由5:日本では「名ばかりFDE」=SESの可能性

日本で「FDEはやめとけ」と言われるとき、多くの場合は「客先常駐のSESと同じでは」という懸念です。この懸念自体は正当で、自社プロダクトを持たない会社が「FDE」を名乗ると、構造はSESと変わりません。LayerXでFDEグループを率いる白井英氏は、レバテックLABの取材で、SESや技術コンサルタントとの決定的な違いを「プロダクトを持っている」ことだと述べ、FDEは役割というよりビジネスモデルに近いと説明しています。

Sansanの技術ブログは、同社のFDEの役割を「ビジネス・データ・現場の3層をつなぎ、AIが価値を発揮し続ける状態を作る」ことと説明し、技術力・ビジネス理解・推進力の3つを求める資質として挙げています。自社プロダクトを顧客の業務に適応させ、価値が出るまで伴走するという定義です。この定義に照らして、求人票に次の特徴がある場合は、FDEという名前でもSESに近い働き方になる可能性があります。

SESそのものを否定する意図はありません。ただ、FDEを志望する人が期待しているのは「自社プロダクトを顧客の現場で成果につなげる」働き方なので、求人票がその構造を持っているかを確認せずに応募すると、理由3と理由4の負荷を同時に抱えることになります。類似職種との違いの詳細は次の記事にまとめています。

関連記事FDEとSES・SIer・SE・コンサルの違い:名ばかりFDEを見分ける5つの質問

関連記事FDE求人・採用企業一覧:日本でFDEを募集する企業の職種名・年収・応募要件

それでもFDEに向いている人・向いていない人

ここまでの負荷は、すべての人に同じ重さでのしかかるわけではありません。First Round Reviewは、Palantir・Ironclad・Zeta Globalなどで FDE組織を作った人たちへの取材から、FDEに向く人の資質を5つにまとめています。

1. 01他人のプレイブックを持ち込まず、自分で考えて結果を出す。Zeta GlobalのShilpa Balaji氏は、FDEを「結果志向で独立した思考ができ、目の前のどんな問題も解けると信じている人」と表現し、大手テック企業で長く決まったやり方に慣れた人より新卒に近い層を採用したと述べている
2. 02苦しい局面に耐える(grit)。Balaji氏は「苦痛を受け入れる意思」を挙げ、不可能に見えることを実現できると信じる力がFDEの最大の特徴だと述べている。Jake Stauch氏はFDEを「ミニ創業者」のような立場だと表現している
3. 03高い技術水準を満たす。IroncladのJames Honsa氏は、初期の弁護士エンジニアが毎週CTOとコードレビューをしていたと述べ、Palantirで採用を担当したTiffany Siu氏はソフトウェアエンジニアと同じ面接基準を課したと述べている
4. 04作り続ける。Balaji氏は最高のFDEを「何かを作らずにはいられない強迫的なビルダー」と表現している
5. 05ビジネスの仕組みに深い好奇心がある。Honsa氏は、法務や営業といった顧客の業務そのものに興味を持てることを挙げている

同じ記事でHonsa氏は、FDEは「万能薬ではない(not a panacea)」とも述べ、FDEの仕事には「必要だが戦略的ではない仕事」が多く、スコープの膨張が継続的な課題だったと振り返っています。Siu氏は、創業者が「プロダクトを作り、導入し、教育し、カスタマイズし、顧客を満足させる」全能の人物をFDEに期待しがちだが、規模が大きくなると非現実的だと指摘しています。これらは、理由2(曖昧さと成果責任)の負荷が会社側の設計不足で増幅されることを示しています。

坂本氏(ログラス)がレバテックLABで挙げた「技術的・論理的な正しさだけでなく、人間の複雑さを加味しながら前に進める力」も、向き不向きを分ける軸です。技術的に正しい解が、顧客組織にとって受け入れやすい解とは限りません。この調整を「面倒」と感じるか「面白い」と感じるかで、同じ仕事の負荷はまったく変わります。

関連記事FDEに必要なスキル・資格:技術力と顧客対峙力をどう証明するか

応募前に確認すべき質問リスト

5つの理由に対応する形で、面接や カジュアル面談で確認したい質問をまとめます。回答の内容そのものより、具体的に答えられるかどうかが、その会社でFDEが設計された職種か、呼び名だけの職種かを示します。

質問の仕方や、FDEの選考全体の流れは、面接対策の記事にまとめています。選考の各段階で「顧客対峙のシミュレーション」が行われるため、こちらからの質問も顧客に向き合う姿勢の一部として見られます。

関連記事FDEの面接対策:技術面接・ケース面接・逆質問の準備

まとめ:FDEは「やめとけ」ではなく「見極めてから」

FDEが「きつい」「やめとけ」と言われる理由のうち、出張・顧客先常駐の負荷と、曖昧な要件のもとで成果に責任を持つ負荷は、職種に本質的なものです。これらは求人票に明記されており、Palantirは「25〜75%の出張」と「startup CTOに似た責任」を、OpenAIは「出張あり(主に国内)」と「本番採用・業務インパクトで測る成功」を書いています。一方、成果が自分の資産にならない、営業支援寄りで市場価値が下がる、SESと変わらない、という3つの懸念は、会社の設計次第で避けられるものです。

The Pragmatic Engineerが「エンジニアの関心が低いなら必ず理由がある」と書いたように、FDE求人が急増するなかで中身の薄い求人が混じっているのは事実です。だからこそ、職種名で判断せず、自社プロダクトの有無、現場の知見がプロダクトに戻る仕組み、評価指標、コードを書く時間の割合を、応募前に確認してください。First Round Reviewが挙げる5つの資質に自分が当てはまり、設計されたFDE職に出会えるなら、この職種はエンジニアとしての水準を保ちながら顧客の成果に直接触れられる、数少ない仕事です。

関連記事FDE転職ガイド:向いている経歴・職務経歴書・選考対策