FDE（Forward Deployed Engineer）の求人票には、作ったものが本番で使われることが成果として書かれています。
ところが SaaS の会社には、導入した後の定着を専門に受け持つカスタマーサクセス（CS）という職種が前からあります。
Anthropic は FDE とカスタマーサクセスマネージャー（CSM）を同じ時期に募集していて、どちらの募集要項にも導入（adoption）という言葉が出てきます。
両方の募集要項と CS の定義を並べると、FDE は案件が安定して動くまで、CS は契約が続く間を受け持つという線が見えてきました。
私も FDE を学んでいる途中で、書けるのは公開資料から読み取れる範囲までです。
カスタマーサクセスは契約が続く間を受け持つ
書籍『カスタマーサクセス』の共著者の一人、リンカーン・マーフィー氏は、自身のサイトで CS の定義を改訂しながら公開しています。
記事「カスタマーサクセスの定義」（原題 Customer Success: Defined (2024)）では、顧客が自社との関係を通じて望む成果にたどり着くことを CS と呼んでいます。
その結果として、顧客が長く使い、多く買い、ほかの人に薦めてくれるようになるところまでが定義に含まれていました。
望む成果（Desired Outcome）は一度決めたら終わるものとしては扱われず、変わり続けるものとされています。
その変わり続ける成果へ顧客を進めるための人・手順・データ・仕組みを、同氏はカスタマーサクセスマネジメントと呼んでいます。
売った後にまで人を置く理由は、同氏らの書籍の目次にも表れています。
英治出版から邦訳が出ている『カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則』は、原則の 2 番目に「顧客とベンダーは何もしなければ離れる」を掲げました。
契約を続けるかどうかを顧客が選び直せる商売では、売った後も関わり続ける役が要る、という考え方です。
CS のもう一つの特徴は、一人で受け持つ顧客の数が多いことでしょう。
CS 向けのソフトウェアを提供する Gainsight は、顧客との関わり方を 4 つの区分に分けて説明しています。
ブログ記事「テックタッチのカスタマーサクセス」（原題 Tech Touch Customer Success: The Playbook and Metrics）の表によると、専任の CSM が付く手厚い区分（ハイタッチ）ではCSM 1 人あたり 5〜20 社が目安です。
自動化を主にする区分（テックタッチ）になると、1 人あたり 500 社以上とされていました。
テックタッチでは自動のメールや製品内の案内で回し、信号が出たときだけ人が入ります。
どの区分にするかは一度決めて終わりにせず、顧客の数や製品の複雑さに合わせて変える人員配置の判断だとも書かれています。
CS は、限られた人の手を多くの顧客に配り分ける前提で組まれた職種だと分かります。
同じ会社の募集要項に引かれた線
FDE と CS の受け持ちの違いは、同じ会社が出している二つの募集要項を読み比べるとはっきりします。
Anthropic の Forward Deployed Engineer の募集要項（ロンドン）によると、FDE は最も戦略的な顧客の中に入り込んで働きます。
顧客のシステムの中で、Claude を使った本番のアプリケーションを作るのが仕事です。
納めるものには、MCP サーバーやサブエージェント、エージェントスキルといった、本番の業務で使われる技術的な成果物が挙がっていました。
支援の期間（エンゲージメント）を通じて、AI を使える新しい機会を見つけることも責務に入っています。
Anthropic の Customer Success Manager の募集要項（ロンドン）は、書きぶりがかなり違います。
欧州・中東・アフリカ（EMEA）で最初の現地 CS チームを立ち上げるメンバーとしての募集です。
責務には、利用状況の傾向を見て、契約した分を使い切れていないところに先回りして手を打つことが挙がっていました。
利用者に使ってもらうための変更管理も、責務の一つです。
社内で教える人を育てる Train the Trainer や、推進の中心になる組織（Center of Excellence）づくりまで含まれます。
実現した価値を ROI などの数字にまとめ、顧客が継続と追加の投資を社内で説明できる材料を作ることも求められていました。
さらに四半期ごとの事業レビュー（QBR）を開き、顧客のライフサイクル全体にわたって顧客体験を受け持つと書かれています。
FDE の説明にあるライフサイクルが支援の期間を指すのに対して、CSM のほうは顧客との付き合い全体の期間を指しているわけです。
OpenAI の募集要項も、同じあたりに線を引いています。
OpenAI の Forward Deployed Engineer – Tokyo の募集要項は、最初の試作から安定した本番稼働までを技術面で届けきることを、FDE の受け持ちとしています。
作ったものが現場で使われるよう導くことも、責務に入っていました。
そのうえで OpenAI には、導入後の定着を専門に受け持つ職種が別にあります。
Enablement Lead (Builder) の募集要項（東京）は、この職を契約後の利用促進（ポストセールスのイネーブルメント）の専門職と説明しています。
研修や利用促進で受け持つのは、最初のオンボーディングから利用の拡大、長期の定着までの顧客ライフサイクル全体です。
肩書きに CS とは付いていませんが、継続的な利用と測れる事業価値を生むことが責務に挙がっていて、役回りは CS に近いと言えます。
求人票はいずれも 2026 年 10 月 19 日に確認しました。
ここまでを並べると、次のようになります。
| 比べる軸 | FDE | カスタマーサクセス |
|---|---|---|
| 受け持つ期間 | 案件の始まりから安定稼働まで | 契約が続く間（更新や拡大まで） |
| 主な手段 | 顧客のシステムの中で作る | 利用状況の見守り、研修、定例のレビュー |
| 一人が見る顧客 | 最も戦略的な顧客 | 区分しだいで数社から数百社以上 |
| 成果の置き場所 | 本番で使われる仕組み | 継続と拡大につながる価値 |
表にすると、FDE が「動く状態」を作り、CS がそれを「使われ続ける状態」に保つという分担が見えてきます。
定着の受け渡しを3つの節目で組む
Anthropic の FDE の募集要項には、契約後の顧客を受け持つポストセールスのチームと密に組むことも書かれていました。
受け渡しを考える手がかりになるのが、マーフィー氏が共同の責任（Joint Accountability）と呼ぶ考え方です。
同氏は、顧客が成果にたどり着くまでの仕事を、誰がどこでやるかで 4 つに分けています。
- 顧客が製品の外で、自分でやること
- 顧客が製品の中で、自分でやること
- ベンダーが顧客と一緒に、製品の中でやること
- ベンダーが顧客のために、裏側でやること
4 つ目は通常プロフェッショナルサービスの領分で、オンボーディングや導入の段階に入ることもあると説明されています。
FDE が顧客のシステムの中で作る仕事は、この 4 つ目に当たると考えられます。
一方で同氏は CSM に対し、できるだけ多くの仕事を顧客の側へ戻すよう勧めていました。
打ち合わせは作業を代わりにやる場にせず、進み具合の確認と次の計画に使う、という勧め方です。
ベンダーが代わりにやる仕事を減らし、顧客が自分で回す仕事を増やしていくのが、CS の向きだと言えます。
二つの募集要項とこの分け方を重ねると、受け渡しは次の 3 つの節目で組むと整理しやすくなります。
始める前に望む成果をそろえる
マーフィー氏は、ゴールを目的・条件・期限の 3 つでできたものと定義しています。
条件とは、目的を果たしても満たされなければ顧客が成功と感じない性質のことです。
FDE が作る仕組みの要件と、CSM のサクセスプランが別々のゴールを向いていると、作り終えた時点で何が達成されたかの説明が食い違いかねません。
Anthropic の CSM は、顧客の事業目標に根ざしたサクセスプランを持つとされています。
FDE が課題を探るディスカバリーの段階から、その目標を CSM と共有しておくのが自然です。
安定稼働を境に見守りを移す
OpenAI の FDE の受け持ちが安定した本番稼働で区切られているのは、そこから先を別の職種が見る前提だからだと読めます。
ただ、本番で動いたことと、顧客が望む成果に届いたことは同じではありません。
マーフィー氏はこの差を、成功の溝（Success Gap）と呼んでいます。
メール配信の製品で、名簿を取り込み、メールを書いて送ったのに、肝心の催しに人が集まらなかったという例が挙がっていました。
製品の上では正しい操作をすべて終えていても、顧客の目的は果たせていないわけです。
安定稼働の後に残るこの溝を、利用状況の見守りと変更管理で埋めていくのが CS の持ち場になります。
何を数えて定着と見なすかは、FDE の成果の測り方をまとめた記事で整理しました。
新しい使い道はFDEの案件として戻す
Anthropic の CSM の責務には、まだ使われていない部署や使い道を、顧客と一緒に探すことも入っています。
見つかった使い道に新しい作り込みが要るなら、それは FDE の次の支援の入口になるでしょう。
募集要項にこの往復がそのまま書かれているわけではありませんが、両方の責務を並べるとこう読めます。
定着は一度の引き継ぎで終わらず、CS と FDE の間を行き来しながら広がっていくものと捉えると分かりやすくなります。
取り違えやすい3つの場面
ここまでの分担は、少しずれるだけで定着の抜け穴になります。
1つ目は、本番で動いた時点を定着と見なしてしまうことです。
FDE が安定稼働で手を離したあと、成功の溝を見る人がいなければ、書籍の原則が言うとおり顧客は何もしなければ離れていきます。
2つ目は、作り込みを CS に、定例の世話を FDE に寄せてしまうことでした。
マーフィー氏は、CSM が顧客と一緒に製品の中で作業する時間を増やしすぎないよう注意しています。
逆に、業務の流れが分かっている顧客の定例の世話まで FDE が抱えると、高くつく人手を薄く使うことになりかねません。
FDE を置くほどではない顧客の条件は、常駐型が割に合わない場面をまとめた記事で整理しています。
3つ目は、誰がアカウントを持つかを決めないまま、FDE の支援を終えることです。
マーフィー氏は、アカウントを持つことを、顧客の文脈を持ち続けることと定義しました。
文脈には、進み具合や利用状況、顧客側の体制の変化、ゴールの変化、契約の更新などが含まれます。
支援の間に FDE が集めた文脈を CS へ移しておかないと、顧客は担当が替わるたびに同じ説明をやり直すことになるでしょう。
最後に
FDE は案件の始まりから安定稼働までを、CS は契約が続く間を受け持つと整理できます。
定着は、FDE が作った動く状態を CS が使われ続ける状態に保ち、新しい使い道が見つかればまた FDE に戻す、という受け渡しの上に成り立っています。
求人票を読むときは、「導入」という同じ言葉がどの期間を指しているかを見ると、役割の違いを見分けやすくなります。
次は、安定稼働の後に何を数えて定着と見なすかを、上で紹介した成果の測り方の記事で確かめてみてください。
以上です。
コメントを残す