「FDE（Forward Deployed Engineer／フォワード・デプロイド・エンジニア）の求人を見ているが、必須要件と歓迎要件が企業ごとに違い、自分が応募できるのか判断できない」——そう感じていませんか。
FDEとは、顧客に近い位置で課題整理や技術導入を担うエンジニア職です。具体的な担当範囲は企業によって異なり、実装・本番導入・定着まで広く担う求人もあります。この記事では、日本国内で募集中の公式FDE求人5社分を横断的に比較し、共通して評価されやすい要件と企業ごとの差を、一次情報をもとに整理します。読み終えるころには、「自分が応募を検討できるか」を判断する材料がそろうはずです。
結論として、FDEの採用要件には課題整理・設計実装・導入推進・合意形成・自走力という共通して評価されやすい要素がある一方、必須・歓迎の線引きは求人ごとに異なります。職種名ではなく、求人票の必須欄と歓迎欄を分けて読むことが、応募判断の出発点です。
この記事でわかること
・FDE求人で共通して評価されやすい5つの要件
・企業別（OpenAI・ソフトバンク・JDSC・RevComm・LayerX）の要件比較
・必須要件と歓迎要件の読み分け方
・応募可否を判断するチェックリストと判断手順
・職務経歴書・面接・ポートフォリオでの証明方法
この記事の編集者
FDE Journal編集部
FDE Journalは、Forward Deployed Engineer（FDE）に特化した専門メディアです。FDEの仕事内容や年収、必要なスキル、キャリア、求人・採用企業、国内外の最新動向などを発信しています。編集部では、企業の公式情報や求人情報、公開資料などを確認しながら、FDEについて知りたい方に信頼できる情報をわかりやすくお届けします。
FDEの採用要件を求人票から先に整理
まず、採用要件の全体像を3つの区分で確認します。求人票を読むときは、この区分を意識すると判断しやすくなります。
| 区分 | 主な内容 | 読み方の注意点 |
|---|---|---|
| 共通して評価されやすい要件 | 課題整理、設計・実装、導入推進、合意形成、自走力 | 具体的な経験で証明する必要がある |
| 企業によって異なる要件 | 経験年数、AI・LLM、コーディング水準、英語力 | 必須欄と歓迎欄を分けて読む |
| 働き方・勤務条件 | 出社頻度、出張、顧客先での勤務 | スキル以外のミスマッチにも注意する |
よくある疑問には、次のように答えられます。
Q. FDE経験は必須？
必須としない求人があります。JDSCはFDE・AIプロジェクト経験を不問と明記しています。
Q. AI・LLM経験は必須？
求人により分かれます。OpenAIやSB OAI JapanはLLMを活用したシステムの構築・導入経験を必須とし、JDSCやRevCommでは歓迎要件です。
Q. 開発経験は何年必要？
JDSCの2年以上から、OpenAI・SB OAI Japanの5年以上まで幅があります。
Q. 英語力は必要？
OpenAIは日本語・英語の両方に流暢であることを必須としています。一方、調査対象には英語力を必須要件として明記していない求人もあります。
Q. 学歴・資格は必要？
今回確認した5社の公式求人では、学歴や特定資格を必須条件として明記した記載は確認できませんでした。ただし、学歴・資格以外の実務経験や語学要件は企業ごとに異なります。
なお、FDEの担当範囲は企業によって異なり、実装・導入・定着のどこまでを担うかは求人ごとに確認する必要があります。FDEという職種の担当範囲や一般的な仕事内容を先に確認したい方は、FDEの仕事内容や役割を解説した記事をご覧ください。客先で働く点からSESと混同されることもありますが、FDEは職種・役割、SESはサービス・契約形態を指します。詳しい違いはFDEとSESの違いを解説した記事で整理しています。
複数の求人で共通して評価されやすい要件
必須要件、業務内容、求める人物像を横断して確認すると、複数社で共通して重視されている要素が見られました。第一に、要件が固まっていない状況で関係者と対話しながら課題を整理する力です。JDSCは必須要件に、SB OAI Japanも「曖昧な環境下での意思決定力と推進力」を必須要件に明記しています。第二に設計・実装につなげる力、第三に導入まで進める推進力、第四に関係者との合意形成力です。いずれも知識ではなく、証明できる実績として問われます。
企業・ポジションによって変わる要件
経験年数・AI・LLM・コーディング水準・英語力は、後述の比較表の通り必須と歓迎が分かれます。読み分けのコツは、必須欄と歓迎欄を混同しないこと、「FDE」という職種名だけで仕事内容を判断しないことです。歓迎要件をすべて必須と思い込む、PoC経験を本番導入経験のように見せる、といった読み違いも避けてください。
企業差の具体例として、Salesforceの東京求人では、Salesforce経験は歓迎要件である一方、5年以上の本番システム開発、AI・LLM、データ統合、日本語・英語が必須とされています。詳しくは「Salesforce FDEの採用要件と応募可能性」で整理しています。
FDEの採用で共通して評価される5つの要件
共通して評価されやすい5つの要素を、業務プロセスの流れに沿って解説します。
顧客の課題を整理し技術要件に落とし込む力
求人票では「課題特定」「業務要件の構造化」といった言葉で表れます。証明すべきは、抽象的なヒアリング力ではなく、関係者から業務フローや制約を聞き出し、曖昧な依頼を要件に変換した実績です。依頼と最終要件のギャップをどう埋めたかを語れると、説明材料になりやすいでしょう。
制約を踏まえて設計・実装する力
実装型のFDE求人では、本番品質コードの設計・実装が必須要件に挙げられています。一方で、統合設計が中心で内部実装を担わない求人もあるため、「どこまで自分で書くのか」を求人票で必ず確認してください。共通して問われるのは、技術的制約と業務要件のトレードオフの中で下した判断の実例です。
データ・API・クラウドを扱う基礎力
求人票で具体的に挙がるのは、API連携、SQLによるデータ抽出・加工、クラウド環境での構築、認証・セキュリティへの配慮です。証明すべきは、既存システムと接続して動く状態まで持ち込んだ実績です。AI・LLMが歓迎要件にとどまる求人であれば、まずデータとAPIの基礎力で勝負できます。
導入から定着・成果検証まで進める力
今回確認した複数の求人では、PoCで終わらせず本番展開まで進めることが業務内容として明記されています。証明したいのは、リリース後の利用状況を追い、定着のための改善を回した実績です。利用率や業務時間の削減など、成果を測った指標があれば具体的に整理しておきましょう。
曖昧な状況で合意形成し自走する力
「自走力」「オーナーシップ」という言葉で表れますが、一人で抱え込む力ではありません。評価されやすいと考えられる行動は次の通りです。
- 仕様が固まらない段階でも仮説を立てて前に進めた
- 複数部門の利害を調整して着地させた
- スコープ・速度・品質のバランスを再設計した
- 個別案件の知見を再利用可能な形に標準化した
特に知見の標準化は、複数社が業務内容に明記するFDEらしい役割です。抽象語ではなく、行動の実例で証明できるかが問われます。各スキルの具体的な中身や、不足しているスキルを身につける方法は、FDEに必要なスキルと身につけ方を解説した記事で詳しく整理しています。
企業別のFDE採用要件を比較｜求人票の違いを読み解く
2026年7月28日時点の公式求人5社分を比較します。企業名から各社の公式求人ページを確認できます。本記事のタイプ分類は、各社の業務内容を比較しやすくするためにFDE Journal編集部が整理したものです。企業が公式に使用している分類ではなく、一つの求人が複数タイプの特徴を持つ場合があります。
| 企業名 | FDEのタイプ | 必須経験年数 | 主な要件・役割 | AI・LLM | 英語力 |
|---|---|---|---|---|---|
| OpenAI | 実装・プロダクト型 | 5年以上（顧客対応を含む） | 必須：フロント・バックエンド両方の本番品質コード | 必須（LLMシステムの構築・導入） | 日英両方に流暢（必須） |
| ソフトバンク（SB OAI Japan出向） | 実装・プロダクト型 | 5年以上 | 必須：顧客折衝を含む推進、本番品質コード、クラウド構築 | 必須（生成AIアプリの構築または導入） | 歓迎（日本語はビジネスレベル以上が必須） |
| JDSC | 実装・業務変革型 | 2年以上 | 必須：課題整理から実装まで進めた実務 | 歓迎（LLM・RAG開発） | 記載なし |
| RevComm | 導入設計・データ連携型 | 明記なし | 必須：顧客折衝、API・データ連携、SQL活用 | 歓迎（AI・LLMを活用した業務設計） | 記載なし |
| LayerX | 実装・導入複合型 | 公式求人で明示なし | 業務内容：課題の構造化、AIワークフロー構築、導入支援 | 業務内容に記載（LLMのチューニング・精度評価等） | 公式求人で明示なし |
勤務条件にも差があります。OpenAIは週3日出社で出張は主に国内、履歴書は英語で提出します。ソフトバンク（SB OAI Japan出向）は国内出張に加え、米国OpenAI本社への出張可能性があります。JDSCはフレックスタイム制でリモート勤務も可能です。RevCommは自社プロダクト内部の実装を担当しません。LayerXの表中の記載は、公式採用情報の業務内容にもとづく整理です。
LayerXについては、ソフトウェア開発・課題整理・大規模システムの設計運用が重視される一方、LLMの専門経験は歓迎要件に位置づけられています。経歴別に活かせる経験や選考での伝え方は、LayerX FDEの求人要件と応募判断で確認できます。
実装・プロダクト開発の比重が高いFDE
顧客環境で動く本番システムを自ら実装するタイプで、LLMを組み込んだ設計から展開までを一人称で担います。評価されやすいと考えられるのは、本番品質のコードを書き切った実績と、LLMを使ったシステムの構築・導入の実務です。求人票では、必須要件欄のコーディング水準と対象言語、開発範囲の記載を確認してください。
導入設計・データ連携の比重が高いFDE
プロダクト内部の実装ではなく、顧客環境への接続を設計するタイプです。評価されやすいと考えられるのは、API・データ連携の実務、SQLでのデータ活用、技術的な成立条件を整理した実績です。求人票では、実装範囲の記載（内部実装を含むか）と、連携・データ関連の必須要件を確認してください。編集部の見立てでは、プリセールスやソリューションアーキテクトの経験と相性があると考えられます。
業務変革・プロジェクト推進の比重が高いFDE
顧客の業務理解と定着推進に軸足を置くタイプで、課題特定からPoC、本番実装、導入後の改善までを推進します。評価されやすいと考えられるのは、複数部門との合意形成と、導入後の改善まで並走した実績です。求人票では、業務内容欄の担当フェーズと、顧客折衝・推進系の必須要件を確認してください。
本記事で比較した企業以外も含めて求人の特徴を確認したい方は、FDEを採用している企業一覧をご覧ください。
FDEの採用要件に自分が合うか判断するチェックリスト
要件との照合は、点数ではなく「証明できる具体例が語れるか」で行います。以下の9項目を確認してください。
| チェック項目 | 証明できる具体例があるか |
|---|---|
| 顧客や社内ユーザーから課題を聞き出した | 誰に・何を聞き・何が分かったか |
| 曖昧な要望を要件に整理した | 元の依頼と最終要件の差分 |
| 自分で設計・実装した成果物がある | 担当範囲と技術的判断 |
| PoCから本番導入まで進めた | 本番化で乗り越えた課題 |
| APIやデータを扱った | 連携先・データ量・制約 |
| 複数部門と合意形成した | 対立点とその解消方法 |
| 導入後の定着や成果改善を担った | 追った指標と改善内容 |
| 不確実な状況で自ら判断した | 判断の根拠と結果 |
| 技術とビジネスの両方を説明した | 非技術者に説明した場面 |
あわせて、応募条件を2種類に分けると判断しやすくなります。経験年数、語学水準、勤務地・出社条件、出張対応、本番コードの実務経験は代替しにくい傾向があります。一方、FDEという職種名での経験、特定の業界・開発言語、顧客折衝、AI・LLM、推進の経験は、近い実績で説明できる可能性があります。ただし、どの条件を代替できるかは企業ごとに異なります。判断手順は次の通りです。
- 分類：必須要件を「代替しにくい条件」と「代替の可能性がある条件」に分ける
- 照合：不足条件を類似の実績で説明できるか確認する
- 証明：その実績を書類で示せる具体例があるか確認する
- 切替：代替しにくい条件を満たさない場合は、別の求人も検討する
エンジニア出身者の強みと不足しやすい経験
設計・実装・運用の実績は、多くのFDE求人でそのまま強みになります。不足しやすいのは、技術を顧客の業務成果と結び付けて説明する視点と、部門横断の合意形成です。社内ユーザー向け開発で利用部門の要望を要件化した実績も、顧客折衝の説明材料になり得ます。テックリードとしての仕様調整や営業同行の支援も説明材料になります。
ITコンサル・PdM・プリセールス出身者の強みと不足しやすい経験
課題整理・合意形成・推進の実績は、FDEの評価軸と重なる部分が多くあります。一方で、実装型のFDEでは本人のコーディング実績が重視されるため、指示して作らせた案件と自ら実装した案件は分けて説明が必要です。導入設計型であれば、API・データ連携や成立条件の設計の実績が評価されやすいと考えられます。小規模な自作ツールは補足材料にはなりますが、求人が求める開発実務年数の代わりにはなりません。出身職種そのものより、応募するFDEのタイプと自分の実績の一致を重視してください。コンサルティング出身の方で、経験がFDEのどの業務に活かせるかを確認したい場合は、FDEとコンサルタントの違いを比較した記事も参考にしてください。
FDE未経験でも応募を検討できるライン
FDE経験がないこと自体は、応募できない理由になりません。開発実務があり、曖昧な要件を整理して実装まで進めた実績を語れるなら、応募を検討しやすい状態です。開発実務はあるが顧客対応や本番導入が薄い場合は、応募と並行して現職で不足を補う段階です。開発実務そのものがない場合は、代替しにくい条件に該当しやすいため、先に実務の機会をつくることを優先してください。現在地ごとに不足する経験と転職までの手順を確認したい方は、FDEになるための現在地別ロードマップをご覧ください。
FDE Jounral 編集部気になる求人を1つ選び、必須要件を「代替しにくい条件」と「近い実績で説明できそうな条件」に振り分けてみてください。書類で示せる具体例まで思い浮かべば、応募を検討できる状態です。
FDE選考で採用要件を満たす経験を伝える方法
要件を満たしていても、伝え方次第で評価は変わります。職務経歴書・面接・ポートフォリオに分けて整理します。
職務経歴書は「課題・行動・実装・成果・定着」で書く
技術スタックの一覧だけでは、採用要件との対応を示しにくくなります。実績は、誰のどんな課題だったか、担当範囲、要件整理の方法、設計・実装の内容、関係者の巻き込み方、成果、導入後の改善という流れで記述してください。代表的な2〜3案件をこの粒度まで掘り下げ、他は簡潔にまとめる構成が読みやすくなります。書き方の強弱は以下が参考になります。
| 採用要件 | 弱い説明 | 強い説明 |
|---|---|---|
| 課題整理力 | ヒアリングを担当した | 複数部署へのヒアリングから課題を再定義した |
| 実装力 | Pythonを使える | 業務課題に対して設計・実装・検証まで担当した |
| 推進力 | PMを経験した | 関係者の合意形成から利用定着まで進めた |
面接では曖昧な課題を解いた再現性を示す
公開求人の要件から逆算すると、面接に向けて次の実例を整理しておきたいところです。仕様が決まっていない案件の進め方、要望をそのまま受け入れなかった判断、技術的制約下の意思決定、スコープ・速度・品質の調整、失敗から行動を変えた場面です。ソフトバンクのSB OAI Japan向け求人のように、システムデザインやケーススタディを含むディスカッションの実施を公式求人に明記する例もあるため、応募先の公式情報を確認して準備してください。
不足要件はポートフォリオ・PoC・現職経験で補う
前章の通り現職での実務づくりが優先ですが、難しい場合はポートフォリオが補足の説明材料になります。FDE向けには、対象ユーザー、業務課題、仮説、設計上の判断、評価方法、改善内容といった課題解決の過程を示す構成にしてください。チュートリアルの再現では判断の過程を示せないため、身近な業務課題を小さく解いた記録の方が評価につながる可能性があります。
まとめ：FDEの採用要件は求人ごとの差を見て判断する
FDEの採用要件には、課題整理・設計実装・導入推進・合意形成・自走力という共通して評価されやすい要素がある一方、経験年数やAI・LLM、英語力の線引きは企業ごとに異なります。まず、気になる求人の必須要件と歓迎要件を分けて読みます。次に、自分の実績を「課題・実装・成果・定着」の流れで棚卸しします。そのうえで、代替しにくい条件を満たす求人から優先して検討してください。
FDE Jounral 編集部同じ「FDE」でも要求内容は企業ごとに大きく違います。職種名ではなく、求人票の必須欄・歓迎欄・業務内容を読み分けることが、応募判断の一番の近道です。
関連記事
- FDEとは？仕事内容・必要スキル・他職種との違い
- FDEを採用している企業一覧｜国内・外資の求人を比較
- FDEに必要なスキルと身につけ方
- FDEとSESの違い｜SES経験を活かす方法
- FDEとコンサルタントの違い｜転職ルートも解説
- FDEになるには？現在地別ロードマップと転職までの5ステップ
主な参照先（一次情報）
