セールスエンジニア（Sales Engineer）は、ソフトウェアやクラウドの会社で、営業と組んで技術の面から製品を選んでもらう技術職だ。顧客の課題を聞き、製品で解けるかを説明し、デモと技術評価で確かめてもらう。
顧客と技術の間に立つ職種は、名前が似ていて紛らわしい。セールスエンジニアのほかに、カスタマーサクセスエンジニア、テクニカルアカウントマネージャー（TAM）、ソリューションアーキテクト、そしてFDE（Forward Deployed Engineer）がある。私の見方では、違いは「いつ関わるか」と「何を作るか」の2つで見ると整理しやすい。この記事は、Datadog・GitLab・MongoDB・AWSが公開している東京と日本の求人や説明から、それぞれの仕事内容を比べる。FDEという職種そのものはFDEとは？Forward Deployed Engineerの意味と仕事内容で説明している。
セールスエンジニアの仕事内容
セールスエンジニアの仕事がよく分かるのは、DatadogのSales Engineer（東京）の求人だ。2026年10月23日時点で掲載されているこの求人は、セールスエンジニアを、顧客やパートナーとの商談を見極めて受注につなげる職種だと説明し、営業向けの説明、製品のデモ、技術評価（POC）の支援で技術の知見を出すと書いている。
同じ求人が挙げている仕事を、日本語にして並べるとこうなる。
| 求人に書かれた仕事 | 中身の補足 |
|---|---|
| 営業やカスタマーサクセスのチームと組み、製品の価値と方向性を顧客に説明する | 営業の商談に技術の担当として同席する |
| 見込み客と既存の顧客に、製品と技術の説明をする | 提案の場で、技術の質問に答える |
| 製品チームと直接やりとりし、機能の要望を伝える | 顧客の声を製品の改善に戻す |
| 顧客が製品を試し、使い始めるのを手伝う | 技術評価と導入の初期で詰まりを解く |
| 顧客のライフサイクル全体で起きる技術の問題を解く | 受注のあとも相談を受ける |
応募の条件には、セールスエンジニアリングかソリューションエンジニアリングの2年以上の経験と、DevOps・SRE・プラットフォームエンジニアリングの経験が並ぶ。顧客と直接話すので、日本語のネイティブレベルの力が必須とされ、出張は最大で業務時間の25%までとある。
私の見方では、この職種の中心は技術評価だ。顧客は、製品が自社の環境で動くか、課題を本当に解くかを、契約の前に確かめたい。そこで検証の設計を手伝い、結果を説明し、懸念を一つずつ消していく。デモが上手なだけでは足りず、顧客の環境の制約を聞き出して、検証の範囲を正しく切る力が要る。
カスタマーサクセスエンジニアとテクニカルアカウントマネージャー
セールスエンジニアが主に受注の前の職種だとすると、契約のあとに顧客を技術で支える職種もある。名前の付け方は会社で違うが、公開されている求人には2つの形が見える。
カスタマーサクセスエンジニア
GitLabのSenior Customer Success Engineer（日本）の求人は、顧客がGitLabから測れる価値を得られるよう、技術の助言と利用の促進で支える仕事だと説明している。ZoomとEメールで顧客と組み、利用を広げ、導入の詰まりを解く。営業の担当（Account Executive）と更新の担当（Renewals Manager）と組み、更新と拡大を支えることも仕事に入る。勤務地は日本で、日本語と英語が流暢であることが条件だ。
つまり、カスタマーサクセスエンジニアは、売ったあとに使われるようにする技術職だ。多くの顧客を並行して受け持ち、ワークショップやデモで顧客のチームの使い方を育てる。
テクニカルアカウントマネージャー（TAM）
MongoDBのTechnical Account Manager（東京）の求人は、少数の大口顧客と深く関わり、顧客の技術のリーダーと関係を作りながら、構成・性能・復旧・セキュリティの相談に答える仕事だと書いている。顧客と共有する目標のロードマップを作り、製品チームに顧客の要望を伝える役目もある。求める経験は7年以上だ。
AWSでは、エンタープライズサポートのプランに担当のTAMが付く。AWSの説明では、担当のTAMがWell-Architected Reviewを主導し、セキュリティ、信頼性、性能、コスト、運用についての設計の助言を出し、必要ならAWSの専門のエンジニアを呼ぶ。
カスタマーサクセスエンジニアとTAMの違いは、私の見方では、担当する顧客の数と深さにある。前者は多くの顧客の利用を広げ、後者は少数の大口顧客の重要なシステムに付き添う。
4つの職種とFDEの違い
ここまでを、ソリューションアーキテクトとFDEも入れて並べる。どの職種も会社ごとに定義が違うので、これは私の見方による整理だ。
| 職種 | 主に関わる時期 | 何を作るか | 仕事の終わり方 |
|---|---|---|---|
| セールスエンジニア | 受注の前 | デモと技術評価の環境 | 受注 |
| ソリューションアーキテクト | 受注の前から導入後まで | 構成の設計と検証 | 導入が成功し、利用が広がる |
| カスタマーサクセスエンジニア | 契約のあと | 使い方の手引きとワークショップ | 利用が広がり、更新される |
| テクニカルアカウントマネージャー | 契約のあと、長く | 設計の見直しと運用の助言 | 大口顧客の重要なシステムが安定する |
| FDE | 課題を決めるところから本番まで | 顧客の業務で動く仕組みそのもの | 本番で使われ、業務の数字が動く |
上の4つは、どれも自社の製品が顧客の中で使われることを目指す。作るのはデモ、検証、手引き、助言までで、顧客の業務システムを作るのは顧客かパートナーの役目になる。
FDEは、そこを自分で受け持つ。OpenAIの東京のFDEの求人は、戦略的に重要な顧客と組み、発見、技術的な範囲の決定、設計、構築、本番の展開を受け持つと書き、進捗がそれに左右されるときはコードに直接手を入れることを求めている。成果は本番での採用と、業務への測れる効果で測る。
私の見方では、セールスエンジニアは「この製品で解けるか」に答える人で、FDEは「この業務をどう変えるか」に答えて作る人だ。OpenAIとAnthropicがFDEを置いた背景はOpenAI・AnthropicのFDEに、営業の仕組みを作るGTMエンジニアとの違いはGTMエンジニアとはにまとめた。
セールスエンジニアに向く人と、FDEへの道
私の見方では、セールスエンジニアに向くのは、技術の話を相手の言葉に直すのが好きで、短い期間で多くの顧客と会うことに疲れない人だ。Datadogの求人も、大きさと難しさの違う多くの案件を同時に回した経験を求めている。
身につけることは3つある。
- 担当する製品と、その周りの技術。監視の製品ならクラウドの構成とDevOpsまで
- 技術評価を設計する力。何を確かめれば顧客が決められるかを先に決める
- 説明の力。経営層向けの価値の話と、技術者向けの細かい話を切り替える
セールスエンジニアからFDEに移る道もある。顧客の課題を聞く力と、技術を説明する力はそのまま使える。足りなくなりやすいのは、本番で動くコードを書き、運用し、直し続ける経験だ。FDEになる道筋はFDEになるには？に、面接で聞かれることはFDEの面接で聞かれることにまとめた。
発注する側から見た使い分け
AIやクラウドの製品を入れる会社から見ると、製品ベンダーのセールスエンジニアは、契約の前に技術評価を一緒に設計してくれる相手だ。契約のあとは、カスタマーサクセスエンジニアやTAMが使い方と設計を支えてくれる。ただ、どの職種も自社製品を前提に動く。製品で解けない課題や、業務のどこにAIを入れるかを決める仕事は、持ち場の外になりやすい。
私の見方では、使う製品が決まっていて、自社に作る人がいるなら、ベンダーのこれらの職種の支えで足りる。作る人がいない、または何を作るかから決めたいなら、本番で動くところまで受け持つ相手が要る。私たちの支援の中身はサービス詳細に書いた。