FDEと​プリセールスエンジニアの​違い​｜8軸で​比較

FDE​（Forward Deployed Engineer）と​プリセールスエンジニアは、​どちらも​「技術が​わかり、​顧客と​話せる」​人材である。​求人票の​文面も​似通う​ため、​どちらに​応募すべきか、​あるいは​自社に​どちらを​置くべきかで​迷いやすい。

しかし​両者の​分岐点は​明確である。プリセールスエンジニアは受注前、FDEは受注後を担当する。​この​一点から、​責任範囲・成果指標・​求められる​経験・​時間の​使い方まで、​すべてが​分かれていく。

この​​記事の​​対象読者

• エンジニアから​顧客接点の​ある​職種への​転換を​検討している​方
• プリセールスと​FDEの​どちらに​応募すべきか​判断したい方
• AI実装体制を​組むに​あたり、​どちらの​職種を​先に​採用すべきか​検討している​経営・​人事の​方

2つの​​職種は​​「受注前」と​​「受注後」で​​分かれる

プリセールスエンジニアが​商談の​場で​描いた​実現方​式が、​FDEの​着手条件に​なる。​逆に​言えば、プリセールスの見立てが甘いとFDEの現場が破綻する。​両者は​前後の​工程と​して​連結しており、​対立する​職種ではない。

8軸で​比較する

最も​見落と​されやすいのは顧客との関わり方の違いである。​プリセールスは​多数の​商談を​並行して​回すため、​1件あたりの​深さより​判断の​速さと​再現性が​問われる。​FDEは​少数の​顧客に​長期間張り​付く​ため、​業務理解の​深さと​現場での​粘りが​問われる。​この​違いは、​働き方の​好みに​直結する。

プリセールスエンジニアの​​役割

商談に​同席し、​顧客の​業務課題を​聞いた​その​場で、​実現方​式と​PoCシナリオを​描く。​「AIで​何が​できるのか」を​経営層にも​情報システム部門にも​同じ​解像度で​伝え、​曖昧な​相談を​実装可能な​スコープに​変換する。

具体的な​業務は​次のような​ものになる。

• 技術的な​実現性の​判断と​アーキテクチャ提案
• PoCの​スコープ定義​（工数・体制・成功基準の​言語化）
• 見積り根拠の​構築
• RFP回答、​セキュリティチェックシート対応、​情報システム部門との​折衝
• 受注後の​実装チームへの​引き継ぎ設計​（前提条件・​技術的リスクの​申し送り）
• 頻出パターンの​提案テンプレート化

この職種の価値が最も出るのは、断るべき案件を断れるときである。​技術的に​無理な​条件、​データが​存在しない​前提、​効果が​出ない​適用範囲を、​契約前に​見抜いて​交渉に​反映する。​ここを​通してしまうと、​後工程が​全て​負債に​なる。

FDEの​役割

契約後の​現場に​入り、​戦略立案から​ソリューション設計、​実装、​運用移管までを​一気通貫で​担う。​1〜2社の​クライアントに​常駐または​伴走し、​業務ヒアリングから​要件定義・PoC・本番化までを​完遂したうえで、​顧客の​内製チームが​自走できる​状態を​残す。

FDEと​いう​職種​その​ものの​定義と、​SES・SIer・戦略コンサルとの​違いに​ついては​「FDE​（Forward Deployed Engineer）とは？」および「FDE vs SES vs SI vs 戦略コンサル」で​詳述している。

引き継ぎの​​設計が​​両者の​​接点

両職種を​分けて​置く​組織で​最も​問題が​起きやすいのは、​受注から​実装への​引き継ぎである。

商談で​語られた​前提が​実装チームに​伝わらないまま​着手すると、​次のような​事態に​なる。

• 提案時に​「既存システムから​取得できる」と​された​データが、​実際には​手入力の​台帳だった
• 成功基準が​「業務が​楽に​なる​こと」で​合意されており、​完了判定が​できない
• 商談中に​口頭で​追加された​要望が、​スコープ外のまま​期待だけ​残っている

これを​防ぐには、引き継ぎを個人の善意ではなく成果物として定義する必要が​ある。​プリセールス側の​成果物に​「前提条件」と​「技術的リスクの​申し送り」を​含め、​受注時点で​FDE側と​レビューする​運用が​要る。​この​接続設計は、​両職種を​置く​組織に​とって​最初に​整備すべき仕組みである。

拡大 ⤢

PoCが​本番化しない​原因の​一部は、​この​引き継ぎの​断絶に​ある。​関連する​構造は​「AI PoCが​失敗する​5つの​構造的理由と​回避策」で​整理している。

どちらに​​適性が​​あるか

プリセールスエンジニアが​​向く​​人

• 初対面の​相手に、​技術を​相手の​言葉で​説明する​ことに​手応えを​感じる
• 複数案件を​並行して​回すことが​苦に​ならない
• 「作る」より​「作れる​形に​する」ことに​価値を​感じる
• その​場で​プロトタイプを​書いて​動かして​見せられる​実装力が​ある

FDEが​向く​人

• 一つの​現場に​深く​入り、​業務を​理解しきる​ことに​関心が​ある
• 実装から​リリース、​その後の​定着まで​見届けたい
• 顧客の​内製チームを​育てることに​意義を​感じる
• 数ヶ月から​数年単位で​成果を​測る​ことを​受け入れられる

判断に​迷う​場合の​目安は、​「動くものを自分で作りたいか、作れる条件を整えたいか」である。​実装から​離れたくない​場合は、​プリセールスを​担いながら​受注後の​案件に​一部​入る​働き方も​選択肢に​なる。

企業側の​​視点：どちらを​​先に​​採るべきか

AI実装の​体制を​組む際、​どちらを​先に​採用すべきかは現在のボトルネックがどこにあるかで決まる。

拡大 ⤢

初期段階の​組織では、​FDEが​プリセールスを​兼務する​ことが​多い。​兼務が​破綻するのは、​商談数が​増えて​実装時間が​圧迫され​始めた​ときである。「実装できる人が商談に出ずっぱりになっている」状態が観測されたら、分離のタイミングと​判断して​よい。

外部​人材の​活用と​社内育成の​判断基準は​「外部​FDEを​活用する​ vs 社内で​育成する」で​整理している。

FDXの​募集

FDX株式会社では、​両職種を​募集している。​公開している​条件は​次の​とおりである。

いずれも​経験・スキルに​応じて​決定する。​募集要項の​詳細と​選考フローは採用ページに​掲載している。

よく​​ある​​質問​（FAQ）

Q1. プリセールスエンジニアと​​セールスエンジニアは​​同じか？

A. 企業に​よって​呼称の​使い分けが​異なる​ため、​名称だけでは​判断できない。​確認すべきは​職務内容である。​受注前の​技術判断・提案・​見積り根拠づくりを​担うのであれば、​呼称に​かかわらず本記事の​プリセールスエンジニアに​相当する。​導入後の​技術サポートや​保守を​主務とする​場合は、​別の​職種​（ポストセールス、​カスタマーエンジニアなど）に​近い。​求人票では​「受注前か​受注後か」​「成果指標が​受注か​稼働か」を​確認すると​よい。

Q2. 実装力が​​ないと​​プリセールスエンジニアは​​務まらないか？

A. 務まらない​場面が​ある。​商談の​場で​実現方​式を​判断するには、​実装の​勘所が​わかっている​必要が​ある。​FDXの​募集でも​SE・エンジニアと​しての​実務経験3年以上を​要件と​しており、​歓迎条件に​プロトタイプを​その場で​書いて​動かせる​実装力を​挙げている。​ただしFDEほどの​実装の​深さは​求められない。​求められるのは、​深く​作る​力より、​実現​可能性を​素早く​見極める力である。

Q3. プリセールスから​​FDEへ、​​あるいは​​その逆の​​キャリア移行は​​できるか？

A. できる。​両者は​前後の​工程であり、​必要な​素養​（技術理解と​顧客対話）は​重なる。​移行時に​補うべき​ものは​方向に​よって​異なる。​プリセールスから​FDEへは、​長期プロジェクトの​完遂経験と​運用移管の​経験。​FDEから​プリセールスへは、​多数案件を​並行処理する​運びと、​見積り・提案の​型である。​FDXでは、​プリセールスを​担いながら​受注後の​案件に​一部​FDEと​して​入る​働き方も​相談できる。

Q4. 年収レンジが​​近いのは​​なぜか？

A. どちらも​事業への​貢献経路が​明確で、​代替が​難しい​職種だからである。​プリセールスは​受注の​成否に、​FDEは​納品と​継続の​成否に​直結する。​担当する​局面が​違うだけで、​事業インパクトの​大きさは​同等と​位置づけている。​レンジ内での​決定は、​経験年数ではなく、​担える​案件の​難度と​再現性に​よる。

Q5. 自社に​​プリセールス職を​​置く​​場合、​​営業組織と​​エンジニア組織の​​どちらに​​所属させるべきか？

A. 一概には​決まらないが、​判断材料は​評価指標である。​受注への​貢献で​評価するなら​営業組織、​技術的な​判断品質と​スコープ精度で​評価するなら​技術組織に​置く方が​整合する。​実務上の​失敗パターンは、​営業組織に​所属させたうえで​受注数のみで​評価する​ことである。​取れない​条件でも​通す動機が​生まれ、​後工程が​破綻する。​受注件数と、​受注後の​プロジェクト成否の​両方を​評価に​含める​設計が​要る。

Q6. 案件数が​​少ないうちは、​​FDEが​​商談も​​兼務すれば​​よいのではないか？

A. 初期段階では​その​形が​合理的である。​問題に​なるのは、​商談数が​増えて​実装時間が​圧迫され​始めてからである。​実装できる​人材が​商談に​出ずっぱりに​なると、​受注は​伸びるが​納品が​滞る。​判断の​目安は​「実装担当者の​稼働の​うち、​受注前活動が​占める​割合」である。​この​比率が​上がり続けているなら、​分離を​検討する​時期に​ある。

次に​​読むべき記事

• FDE​（Forward Deployed Engineer）とは？​AI時代の​実装パートナー
• FDE vs SES vs SI vs 戦略コンサル — 4つの​モデルを​徹底比較
• FDEを​組織に​組み込む — スキルマップ・評価基準・育成ロードマップ

まとめ

• プリセールスエンジニアは​受注前、​FDEは​受注後を​担当する。​この​一点から​責任範囲・成果指標・​働き方の​すべてが​分かれる
• プリセールスは​多数の​商談を​並行し​（年間30〜50件規模）、​判断の​速さと​再現性が​問われる。​FDEは​1〜2社に​深く​入り、​業務理解の​深さと​定着まで​見届ける​粘りが​問われる
• プリセールスの​価値が​最も​出るのは、​断るべき案件を​契約前に​見抜いて​交渉に​反映する​とき
• 両職種を​置く​組織で​最初に​整備すべきは​引き継ぎの​設計。​前提条件と​技術的リスクの​申し送りを、​個人の​善意ではなく​成果物と​して​定義する
• 適性の​目安は​「動く​ものを​自分で​作りたいか、​作れる​条件を​整えたいか」
• 企業側の​採用順序は​現在の​ボトルネック次第。​商談が​詰まらないなら​プリセールス、​実装が​滞るなら​FDE
• 兼務の​限界は、​実装担当者の​稼働に​占める​受注前活動の​比率が​上がり続けた​とき

FDXで​​働く​​ことに​​関心の​​ある​​方​​へ

FDEと​プリセールスエンジニア、​いずれも​募集中です。​どちらが​合うか迷う​場合も、​まずは​ご相談ください。

採用情報を​見る​ →

AI実装体制の​組み方に​ついての​ご相談は、お問い合わせから​ご連絡ください。

出典・参考文献

• FDX株式会社 採用情報​（Forward Deployed Engineer／プリセールスエンジニア 募集要項）
• 独立行政法人情報処理推進機構​（IPA）​「IT人材白書」