FDEとソリューションエンジニアの違い｜セールスエンジニア・SA・受託PMと並べて整理

違いの本質は「責任がどこで終わるか」

隣接職種を分ける一番はっきりした軸は、専門性の高さでも顧客と話す量でもなく、担当者の責任がプロジェクトのどの時点で終わるかです。セールスエンジニアは契約が締結された時点で、ソリューションエンジニアは技術的な設計と検証が済んだ時点で、いったん役目を終えます。FDEはそこから先、顧客の環境で実際に動き、使われ、成果が出るところまでを持ち続けます。

この違いは日々の時間の使い方に直結します。契約までが責任範囲なら、時間の多くはデモ・提案資料・技術的な反論への対応に使われます。本番稼働までが責任範囲なら、顧客のデータの汚れを直し、既存システムとの接続を書き、現場の運用に合わせて作り直す作業が中心になります。どちらが上ということではなく、日常の業務内容が別物になります。

FDEという呼び名がPalantirで生まれ、その後OpenAIやAnthropicのようなAI企業に広がった背景も、この責任範囲の話で説明がつきます。AIプロダクトは、導入して終わりではなく、顧客のデータと業務に合わせて作り込まないと価値が出ません。「売った後に現場で作り切る人」を職種として置く必要があった、ということです。

隣接5職種との比較

会社ごとの揺れを承知のうえで、一般的な傾向として並べると次のようになります。実際の求人を読むときは、この表を当てはめるのではなく、表の各列にあたる記述が求人票のどこにあるかを探す使い方をしてください。

セールスエンジニア・プリセールスとの違い

この2つの混同がもっとも多く、そして入社後の不満につながりやすい組み合わせです。セールスエンジニアは営業組織の一員で、営業担当と組んで技術的な障害を取り除き、受注につなげるのが役目です。技術力は「売るために」使われます。

FDEも顧客と直接話しますが、話す目的が違います。FDEが顧客と話すのは、これから自分が作るものの要件を掘るためであり、作ったものが現場で使われない理由を突き止めるためです。売るために話すのではなく、作るために話しています。

見分け方として実務的なのは、評価指標を確認することです。目標に受注額やパイプラインの数字が入っていればセールスエンジニアに近く、稼働したユースケース数や顧客の利用量が入っていればFDEに近い、と考えてよいでしょう。面接で「この職種の目標はどう設定されますか」と聞けば、たいてい率直に答えが返ってきます。

ソリューションエンジニア・ソリューションアーキテクトとの違い

ソリューションエンジニアという名前は、隣接職種の中でもっとも意味の幅が広い呼び名です。会社によっては実質プリセールスを指し、別の会社では導入後の実装まで含みます。つまりこの肩書きだけでは何も分からないので、必ず業務内容の記述まで読む必要があります。

ソリューションアーキテクトは、どう作るべきかの設計と助言に責任を持ちますが、作り切ることまでは持たないのが一般的です。クラウドベンダーのSAが典型で、顧客の構成をレビューし、推奨アーキテクチャを示し、実装は顧客側や別のパートナーが行います。FDEはこの「実装は誰かがやる」の部分を自分でやる職種です。

この差は必要な準備にも表れます。SAは幅広い製品知識と設計パターンの引き出しが要りますが、FDEは加えて、汚いデータを扱い切る力と、動くものを短い期間で出す力が要ります。詳しくはスキルの記事で整理しています。

受託開発のPM・SIerのSEとの違い

顧客先に入って作る、という表面だけを見ると、FDEは受託開発やSIerの仕事によく似ています。実際、日本でFDEを目指す人の多くはこの領域からの転向です。ただし決定的に違う点が2つあります。

1つは、作るものの土台が自社プロダクトであることです。受託開発では毎回ゼロから作りますが、FDEは自社のAIモデルやプラットフォームの上に顧客固有の部分だけを作ります。そのため、顧客先で見つけた共通パターンをプロダクト側に還元する動きが業務に含まれることが多く、求人票にも「再現性のあるパターンを見つけて製品チームに戻す」といった記述がよく出てきます。

もう1つは、要件が固まっていない前提で始まることです。受託開発は要件定義書と見積もりを固めてから着手しますが、FDEの案件は「何を作れば効果が出るか」自体が分かっていない状態から入ることが珍しくありません。契約した要件を守り切る力ではなく、要件そのものを作る力が評価されます。

求人票から見分ける3つのチェックポイント

肩書きが当てにならない以上、求人票の本文で判断するしかありません。実務的には次の3点を見れば、かなりの精度で見分けられます。

3つとも曖昧な求人は、社内でも職種の定義が固まっていない可能性があります。悪い会社という意味ではありませんが、入社後に役割が変わりやすいので、面接で「入社後6か月で何ができていれば成功ですか」を確認しておくと安全です。日本で実際にどんな企業がFDEを募集しているかは、FDE board の求人一覧で確認できます。

• 主な業務の項目に、実装・コーディングが明示されているか。デモ・提案・支援という言葉しかない場合はプリセールス寄りです
• 評価指標や目標に何が書かれているか。受注・商談の語が出てくれば営業組織、稼働・活用・定着の語が出てくればデリバリー組織です
• 顧客先での作業がどう書かれているか。「顧客環境での実装」「オンサイトでの構築」があればFDEの実体に近く、「技術支援」「技術相談」だけなら関与は浅めです

よくあるご質問

FDEとソリューションエンジニアは、結局同じものを別の名前で呼んでいるだけですか?

会社によっては実質同じ場合もありますが、一般的には責任範囲が違います。ソリューションエンジニアは技術的な設計・検証までを持ち、FDEは顧客の本番環境で動き続けるところまでを持ちます。肩書きではなく、求人票の業務内容と評価指標で判断してください。

セールスエンジニアからFDEに移るのは現実的ですか?

顧客と話す力はそのまま活きるため、素地はあります。ただし選考では実装力を見られるため、直近で自分が書いたコードと、それが本番でどう使われたかを説明できる状態にしておく必要があります。準備の進め方は面接の記事で扱っています。

SIerのSEからFDEへの転向はどう見られますか?

顧客の業務を理解して要件に落とす経験は高く評価されます。一方で、要件が固まっていない状態から自分で作り切った経験と、実際に手を動かした実装の中身を示せるかが分かれ目になります。管理業務の比率が高いままだと、選考で実装力に疑問を持たれやすい点は意識しておくとよいでしょう。

どの職種が自分に向いているか、どう判断すればよいですか?

「顧客と話すのは好きだが、最後は自分のコードで解決したい」ならFDE、「技術を武器に売る面白さが中心」ならセールスエンジニア、「設計の正しさで貢献したい」ならソリューションアーキテクトが近いはずです。実際の求人の業務内容を並べて読むと感覚がつかめます。FDE board の求人一覧では、日本で応募できるFDE求人をまとめて読めます。