FDE（フォワードデプロイドエンジニア）に必要なスキル一覧｜市場価値を決める能力の優先順位

フォワードデプロイドエンジニア（FDE） 必要スキル 更新日 2026/8/29

FDE（Forward Deployed Engineer）の求人票には、技術要件とビジネス要件が並列で書かれています。エンジニアからは「コンサルの仕事に見える」、コンサルからは「エンジニアの仕事に見える」と映るため、自分に足りないものが分かりにくい職種です。本記事では、求められるスキルを3つの軸に分解し、それぞれどの水準まで必要か、職務経歴書でどう見せるか、今の職場で経験をどう作るかまでを整理します。

スキルの全体像

FDEに必要な能力は、次の3層で捉えると整理しやすくなります。

3つのうち1つが突出していても、他が水準に届いていないと成果が出ません。LayerXがForward Deployed Engineerの募集を公表した際にも、業務フローを表面的になぞるのではなく深く理解できること、非構造化情報を解きほぐして業務ロジックに組み込む実装力があること、LLMの進化に追随する学習姿勢を持つことが要件として挙げられています。この3点は、上の表の3層とほぼ対応しています。

実装力：どこまで必要か

必須の水準

• バックエンド開発：Python／TypeScriptなどで、API連携を含む処理を本番運用に載せられる
• データ処理：SQLで業務データを自力で調べられる。前処理の設計ができる
• LLM活用の実装：プロンプト設計にとどまらず、RAG・ツール呼び出し・エージェント構成を組める
• 既存システムとの接続：認証、権限、バッチ、既存DBやSaaSのAPIとつなぐ設計ができる

「動くものを作れる」ではなく「他人の環境で動き続けるものを作れる」が基準です。顧客の本番環境で障害が出たときに、自分で切り分けられるかどうかが実務上の分岐点になります。

評価される追加要素

• 評価データセットの設計と、出力品質の定量的な測定
• 監視・ログ設計（何が起きたら誰に通知するかまで決められる）
• コストの見積もり（トークン単価・実行回数から月額を予測できる）
• セキュリティ要件への対応（顧客データの取り扱い、権限分離）

特に評価設計は、FDEの差がつきやすい領域です。「精度が良い／悪い」を議論できる共通の物差しを顧客と合意できる人は多くありません。

業務解読力：FDEの中核

何をする力なのか

業務解読力とは、現場の担当者が言語化していない判断基準を引き出し、再現可能な形に落とす力です。具体的には次のような作業を指します。

• 作業手順を、分岐と例外を含めて図に落とす
• 「だいたいこうしてます」という説明から、実際の判断基準を特定する
• 過去の処理ログを見て、説明と実態のずれを見つける
• どこを自動化すべきか、どこは人が判断すべきかの線を引く

このうち最も重要なのは最後の線引きです。全部を自動化しようとして失敗する導入は非常に多く、逆に「ここは人が見る」と決め切れる人は信頼されます。

磨き方

業務解読力は座学では身につきません。現職で作れる経験としては、次のようなものがあります。

• 社内の他部署をユーザーと見立て、業務ヒアリングから要件定義まで自分でやる
• 既存システムの利用ログを見て、想定と違う使われ方を探す
• 障害・問い合わせの一次対応に入り、現場の言葉を聞く

「開発チームの中で仕様を受け取る側」に留まっている限り、この力は伸びません。

顧客折衝力：期待値を動かす力

必要なのは営業力ではない

FDEに求められる折衝力は、売る力ではなく、期待値を合意する力です。

• できないことを早く言う：技術的に困難な要望を、代替案とセットで返す
• 優先順位を決めさせる：全部やる前提を崩し、顧客に選ばせる
• 成果の定義を先に決める：何が達成できたら成功かを、着手前に文書で合意する
• 悪い知らせを先に出す：遅延・精度不足を、判明した時点で共有する

この4つができないと、要望が積み上がって案件が破綻します。逆にこれができる人は、実装力が平均的でも高く評価されます。

相手のレイヤーを見分ける

顧客側の担当者、部門長、経営層では、聞くべきことも話し方も違います。現場担当者に投資対効果を聞いても答えは出ませんし、経営層に処理手順の詳細を説明しても意思決定は進みません。誰が何を決められるのかを早い段階で把握することが、導入の速度を決めます。

バックグラウンド別・優先して埋めるべきもの

自分の出身に応じて、足りない層を1つに絞って埋めるのが最短です。3つ同時に伸ばそうとすると、どれも中途半端になります。

職務経歴書での見せ方

案件単位で、業務指標とセットで書く

FDEの書類選考では、使った技術の羅列より、案件の構造が読めるかどうかが見られます。1案件あたり次の順で書くと伝わります。

1. 顧客の業種と、扱った業務（例：損害保険の事故受付、製造業の購買承認）
2. 着手時点の状態と、何が問題だったか
3. 自分が決めたこと（自動化の範囲、やらないと決めたこと）
4. 実装した内容と技術選定の理由
5. 導入後の業務指標の変化（工数、リードタイム、エラー率）
6. プロダクト／社内資産へ還元したもの

避けるべき書き方

• 技術スタックの列挙だけで、何を解決したかが書かれていない
• 「顧客に寄り添い」「伴走し」といった抽象語で、実際の判断が見えない
• 成果が「導入完了」で止まり、業務側の数字がない

3番の「やらないと決めたこと」は、多くの候補者が書きません。ここを書けると、要望を全部受けてしまうタイプではないことが伝わります。

よくある質問

Q1. 機械学習の理論知識はどこまで必要ですか？

モデルを自分で学習させるポジションでなければ、論文レベルの理解は求められないことが多いです。ただし、なぜこの出力になるのかを顧客に説明する場面は必ずあるため、LLMの基本的な挙動、ハルシネーションが起きる条件、RAGで改善できることとできないことの区別は説明できる必要があります。

Q2. 資格は評価されますか？

FDE単体を対象にした資格はありません。クラウド（AWS／Google Cloud／Azure）の認定は、顧客環境の話をする際の共通言語として一定の効果があります。ただし、資格の有無で合否が決まる職種ではなく、案件の説明の具体性の方がはるかに重く見られます。

Q3. 一人で全部できる必要がありますか？

チーム構成によります。FDE組織が一定規模ある企業では、業務解読を主に担う人と実装を主に担う人で役割が分かれていることがあります。ただし、分業していても相手の領域を理解していないと連携が破綻するため、「できる」までは不要でも「議論できる」水準は全員に求められます。

Q4. 英語のドキュメントを読む力は必要ですか？

必要です。LLM関連の情報は英語が先行し、日本語の解説が出るまでに数週間から数か月の遅れが生じます。顧客に最新の選択肢を提示する立場である以上、一次情報を読める状態を保つ必要があります。会話力は職場によりますが、読解力はほぼ全ポジションで前提と考えてください。

まとめ

FDEに必要なのは、実装力・業務解読力・顧客折衝力が同じ人の中で成立していることです。突出した一芸ではなく、3つが一定水準を超えているかどうかが評価の基準になります。自分の出身によって足りない層は明確に決まるので、まずそこを1つ埋めることに集中してください。そして職務経歴書では、技術の羅列ではなく「何を解決し、何をやらないと決め、業務のどの数字が動いたか」を案件単位で書くことが、通過率を大きく変えます。