FDE・セールスエンジニア・SAの違い｜役割分担の設計

はじめに

「技術がわかる人を営業に同行させているが、受注後に引き継ぎでつまずく」 「導入は決まったのに、現場で使われないまま契約更新の時期が来る」 「提案時に話した内容と、実際に動いているものが違う」

BtoBで技術製品を扱う企業から、こうした相談を受けることがあります。多くの場合、担当者個人の能力の問題ではありません。顧客が価値を得るまでの道のりに、誰も担当していない区間があるという構造の問題です。

その区間を埋める職種として、FDE（Forward Deployed Engineer）、セールスエンジニア、ソリューションアーキテクトという3つの名前が挙がります。ただし、この3つは呼び方が近く、企業によって定義も異なるため、混同されがちです。

本記事は、転職や採用の観点ではなく、自社の体制を決める立場の方に向けて書いています。読み終えた時に、「うちに足りていないのはどの役割か」を判断できる状態を目指します。

3職種が混同される理由

3つとも「技術がわかり、顧客と直接話す人」という点で共通しています。実際、小さな組織では1人が3役を兼ねていることも珍しくありません。

混乱の原因は主に2つあります。ある会社のセールスエンジニアが別の会社ではソリューションアーキテクトと呼ばれるなど、呼び方が企業ごとに違うこと。そして「顧客の課題をヒアリングし、技術的な提案を行う」という求人票の記載が3職種とも似ていることです。

そのため、肩書きで判断すると実態を見誤ります。見るべきは「いつ関わり、何に責任を持ち、何で評価されるか」の3点です。

判断軸は「時間軸」で考える

顧客が製品を知ってから、実際に成果を得るまでを一本の線で考えます。

認知 → 商談 → 技術検証 → 契約 → 設計 → 構築 → 導入 → 定着 → 拡大

この線のどこを担当するかが、3職種を分ける最大の違いです。

• ▸セールスエンジニア：主に「商談〜契約」を担当
• ▸ソリューションアーキテクト：主に「設計」を担当
• ▸FDE：「契約後〜定着」まで担当し、実装にも手を動かす

以下、それぞれを詳しく見ます。

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

セールスエンジニアは、契約が決まるまでの技術面を担当します。プリセールス、技術営業とも呼ばれます。

主な仕事は次の通りです。

• ▸顧客の技術要件をヒアリングする
• ▸製品デモンストレーションを行う
• ▸技術的な質問・懸念に回答する
• ▸PoC（試験導入）を設計し、実施を支援する
• ▸提案書のうち技術部分を作成する
• ▸情報システム部門やセキュリティ部門の審査に対応する

営業担当者が商談全体を進める中で、技術的な信頼を獲得する役割です。「この会社の製品なら、うちの環境で動きそうだ」と顧客に思ってもらうことが目的になります。

評価は、担当した商談の受注率や、技術評価を通過した件数で測られることが一般的です。営業目標を営業担当と共有する形もあります。

契約が決まると、担当は次のフェーズへ引き継がれます。 ここが後述するFDEとの決定的な違いです。

ソリューションアーキテクトの役割

ソリューションアーキテクトは、顧客の要件に対して、どう作るかの全体設計を担当します。

主な仕事は次の通りです。

• ▸顧客の業務要件を技術要件に翻訳する
• ▸システム全体の構成を設計する
• ▸既存システムとの接続方法を決める
• ▸使用する技術・製品を選定する
• ▸性能、可用性、セキュリティの要件を満たす構成を検討する
• ▸設計内容を顧客と開発チームの双方に説明する

「どういう構成なら、この顧客の要求を満たせるか」を決めるのが仕事です。建築でいえば設計図を引く役割にあたります。

商談段階から関わることもあれば、契約後に入ることもあります。クラウドベンダーの認定資格（AWS認定ソリューションアーキテクトなど）があるため、この呼称は比較的定義が安定しています。

一般に、実装そのものは開発チームが担当します。設計と実装が分かれている点が、FDEとの違いです。

FDEの役割

FDE（Forward Deployed Engineer）は、顧客の現場に入り込み、実際に動く状態を作るところまで担当します。Palantir Technologiesが体系化した職種として知られています。

主な仕事は次の通りです。

• ▸顧客の業務プロセスを理解する
• ▸どの課題を解けば効果が出るかを見極める
• ▸自ら手を動かして実装する
• ▸実際の業務データで動作を確認する
• ▸現場の担当者が使える状態まで支援する
• ▸使われ方を見ながら改善を続ける

セールスエンジニアやソリューションアーキテクトと比べたときの特徴は、「設計して終わり」でも「提案して終わり」でもない点です。顧客が実際に価値を得るまで関与し続けます。

FDEの詳しい役割や導入背景は「FDEとは？意味・仕事内容・AI導入での役割」で解説しています。営業とエンジニアの境界がなくなっていく背景については「営業とエンジニアの境界が消える」もあわせてご覧ください。

3職種の比較

ここまでを整理します。

参考として、相談先の候補に挙がりやすいコンサルタントも並べます。

※呼称と職務範囲は企業により異なります。実際の判断は肩書きではなく、上記の観点で確認してください。コンサルタントとFDEの違いは「FDEとコンサルの違いとは？」で、成果物・関与の深さ・実行責任の観点からさらに詳しく比較しています。

どこに穴があくのか

3職種を並べると、引き継ぎの境目に穴があきやすいことが見えてきます。

穴①：契約直後（セールスエンジニア → 実装チーム）

商談中に語られた「こう使えば効果が出ます」という話が、実装チームに正確に伝わらないケースです。

顧客は提案時の説明を期待して契約しています。しかし実装チームには要件定義書しか渡らず、「なぜその要件なのか」という文脈が抜け落ちます。結果、仕様どおりだが期待と違うものができます。

穴②：導入完了後（設計・実装チーム → 顧客）

システムは仕様どおり動いているのに、現場で使われないケースです。

設計と構築の責任範囲は「動くものを納める」ところまでです。実際の業務フローに組み込む、担当者が使えるようになる、という部分は顧客側の仕事になります。しかし顧客側にその推進力がなければ、そこで止まります。

穴③：課題設定そのもの

そもそも「解くべき課題の選定」を誰も担当していないケースです。

顧客が「これを作ってほしい」と言った要件をそのまま受けると、真の課題とずれたものができます。かといって、顧客の業務を深く理解しないまま「本当の課題はこれです」とも言えません。

FDEという職種が注目される理由は、この3つの穴を埋める設計になっているためです。 課題設定から実装、定着まで一貫して担当するため、引き継ぎの境目が生まれません。

自社に必要なのはどの役割か

以下は、体制を考えるときの目安です。

セールスエンジニアが必要なケース

• ▸技術的な質問に答えられず、商談が止まることがある
• ▸情報システム部門やセキュリティ審査で時間がかかっている
• ▸製品デモの品質が担当者によってばらつく
• ▸営業担当が技術説明に時間を取られ、商談数を増やせない

ソリューションアーキテクトが必要なケース

• ▸顧客ごとに構成がバラバラで、保守が難しくなっている
• ▸大規模・複雑な要件で、全体設計を担う人がいない
• ▸既存システムとの接続方式を毎回ゼロから検討している
• ▸性能やセキュリティの要件を満たせるか判断できる人がいない

FDEが必要なケース

• ▸契約は取れるが、導入後に使われず解約される
• ▸「聞いていた話と違う」という指摘を受けることがある
• ▸顧客が何に困っているのか、現場レベルで把握できていない
• ▸提案内容と実装内容の間にずれが生じやすい
• ▸顧客の成果が出ているかどうかを、誰も追っていない

複数当てはまる場合は、まず「どの穴が最も損失につながっているか」から考えます。 商談が止まっているならセールスエンジニア、解約が多いならFDE、というように、症状から逆算する方が確実です。

1人に全部を任せたときに起きること

小規模な組織では、1人が3役を兼ねることがあります。立ち上げ期には合理的な選択ですが、事業が伸びると次の問題が出ます。

時間の奪い合いが起きる。 商談対応と実装が同じ人に乗ると、商談が増えるほど実装が止まり、実装が忙しいと商談に出られません。売上が伸びるほど、顧客の定着支援が手薄になります。

評価軸が矛盾する。 受注件数で評価すると定着支援が後回しになり、定着で評価すると新規商談に出なくなります。同じ人に両方を求めると、どちらも中途半端になります。

属人化する。 その人が抜けたときに、顧客との関係も技術的な文脈も一緒に失われます。

分けるべきタイミングは、カレンダー上で確認できます。 次のような事象が出始めたら、役割を分ける検討時期です。

• ▸契約から導入支援の開始までが、2週間以上先送りされることが増えた
• ▸既存顧客の定例が、新規商談を理由に延期されることが月に複数回ある
• ▸商談への同行依頼を断る、または別の担当者を立てる判断が出始めた
• ▸その人の予定表が、翌週まで空き枠のない状態が常態化している

いずれも「忙しい」という感覚ではなく、予定表と日付で確認できる事象です。感覚で判断すると対応が遅れます。

体制を考えるときの順番

役割を増やす前に、確認しておきたいことがあります。

1. 1.顧客が価値を得るまでの流れを書き出す — 認知から定着まで、実際に何が起きているかを並べる
2. 2.各段階の担当者を書き込む — 空欄になる箇所が、穴の候補です
3. 3.どこで案件が止まっているかを確認する — 商談段階か、導入後か、定着段階か
4. 4.損失が大きい穴から埋める — すべてを同時に埋めようとしない
5. 5.採用と育成のどちらで埋めるかを決める — 既存メンバーの役割変更で対応できる場合もあります

社内でFDE的な役割を育てる方法については「社内にFDEをつくる」で解説しています。求められるスキルの内訳は「FDEに必要なスキルセットと働き方」をご覧ください。

まとめ

3職種の違いは、肩書きではなく「いつ関わり、何に責任を持つか」で判断します。

• ▸セールスエンジニア：契約まで。技術的に導入できると納得してもらう
• ▸ソリューションアーキテクト：設計。どう作るのが最適かを決める
• ▸FDE：契約後から定着まで。実際に使われる状態を作る

自社に必要な役割を判断するときは、職種名から入らず、「顧客が価値を得るまでの流れのどこで止まっているか」から考えてください。商談が止まるのか、導入後に使われないのか、そもそも解くべき課題がずれているのか。症状によって、埋めるべき穴は違います。

YME Technologyでは、営業と技術をつなぐ体制の設計を支援しています。「提案はできるが導入後が続かない」「技術メンバーをどう配置すべきか判断できない」といった段階からご相談いただけます。詳しくはエンタープライズセールス・営業企画支援をご覧ください。