FDEは誰に向くか——現場常駐の仕事と、必要な能力の組み合わせ

給与の高さから入ると、職名の中身を見ないままになります。先に聞くべきなのは、その席が何を終わらせる仕事か、です。

FDEは、何をする仕事か

近い言い方をすると、FDEは「AIの技術が分かるソリューション担当」と「顧客の成功に責任を持つ人」と「納品までやるエンジニア」が、同じ一人に寄った役割です。

モデルや製品を渡して終わり、ではありません。客の現場に入り、業務上の詰まりを聞き、どのAIの使い方が合うかを判断します。エージェントや大規模言語モデルの応用、PoCを短期間で形にし、本番へ載せます。相手の技術責任者やプロダクトマネージャ、現場の担当者に使い方を渡し、その後の保守と改修にも残ります。

以前なら、営業、ソリューション、プロダクト、プロジェクトマネージャ、開発、納品が別の人でした。いま一部の会社は、そのうちのかなりの区間をFDE一人に担わせようとしています。

注目される理由は二つ重なっています。AI Codingで、Claude CodeやCodexのような道具を使えば、以前は人数が要った実装の一部を一人が速く済ませられます。同時に、企業側は「業務が分かり、AIも分かり、方案を本当に動かす人」を欲しがっています。FDEはその隙間に出てきました。

図は、同じFDEという名前でも会社の型で仕事が割れることを示しています。左列はモデル会社で、中心目標はモデルを客の環境へ載せ、用途に合わせて広げて使うことです。中央はプラットフォーム会社で、現場の課題から方案を組み、その経験を自社製品の改修へ戻します。右列はSaaSやソリューション型で、導入前の設計、製品の改造、納品と顧客教育が主になります。下の注記は、肩書きではなく募集要項が解かせようとしている問題を見ろ、と言っています。

もう一枚は、FDEをソフトウェアエンジニア、コンサルタント、プリセールス、プロジェクトマネージャと横並びにした表です。働く場所、納品物、何に責任を持つか、技術の深さ、業務理解、顧客との関係、成功の基準が列ごとに違います。FDEの列だけが、顧客先への長期常駐と、動く方案および業務結果への責任を同時に置いています。表の末尾は、現場に入り、技術を載せ、繰り返し直し、結果に責任を持つ、という式でまとめています。

複合であるがゆえに、誰にでも向く仕事ではありません。

向いている人

第一は、もともと開発、プロダクト、プロジェクトマネジメント、ソリューション、プリセールスをしていた人です。足りない側だけを足せばよい、という位置にいます。開発は技術の土台がある一方、業務の読みと顧客との会話、納品の進め方が薄いことが多いです。プロダクトは要求と製品は分かっても、大規模言語モデル、Agent、RAG、実装の手触りが要ります。プロジェクトマネージャは進行は得意でも、AIの中身を自分で判断できるところまで補う必要があります。ソリューションやプリセールスは客と業務に近い代わりに、動くものにする工程が弱いです。

転身は、十年の経験を捨てて新しい職名を一から覚えることではありません。もとの経験の上に、AIで現場を動かす力を足すことです。

第二は、一つの業界に長くいる人です。製造、金融、医療、教育、エネルギー。AIへ移ると業界経験が無駄になる、と思いがちですが、FDEでは逆に効きます。客が欲しいのは、モデルの用語に詳しい人だけではありません。その業界のどこにAIを入れる価値があるかを言える人です。業務、手続き、客、痛みが既に分かっていて、技術と納品を後から足すほうが、差がつきやすいです。

第三は、曖昧な問題をほぐすのが好きな人です。現場に着くと、要件定義書が綺麗に置いてあることは少ないです。ある日は知識ベースの検索が外れます。翌日はツール呼び出しが壊れます。その次の日には、モデルではなく客の業務手続き自体が整理されていない、と分かります。それを「自分で見てみよう」と思えるなら、この仕事は合います。手順と正解と境界が先に全部決まっていないと動けない人には、かなり疲れます。

向かない人

コードに触りたくない人です。AI Codingで敷居は下がりましたが、FDEが技術を見なくてよい、という意味ではありません。毎日大量に手で書く必要はありません。ただしシステムの流れは読めないと困ります。Agentがどう動くか、インターフェース、RAG、モデル呼び出し、デプロイで何が起きているか、障害のときどこを疑うか。コードを見た瞬間に拒否反応が出るなら、この席は苦痛になりやすいです。

客と話したくない人、出張や常駐が嫌いな人も同じです。いまのFDEは現場の比重がまだ大きいです。要求を聞き、方案を説明し、本番の合意を取り、意見が割れたときに進め、相手のチームに教えます。静かに技術だけ触りたいなら、純粋な開発の席のほうが合います。

高給という二文字だけで追う人も、ここで止まりやすいです。高い報酬の求人はあります。ただし数件の募集要項を見て、全部がその水準だと思わないほうがいいです。市場はまだ動いている途中で、会社ごとに責務も給与もばらつきます。自社がどんなFDEを欲しいのか、会社側も言語化できていないことがあります。職名より、その席が解かせる問題と、自分の能力が重なるかを見たほうがいいです。

図は中央にFDEを置き、左を緑の「向く人」、右を赤の「向かない人」に分けています。向く側は、技術の土台、現場の実問題、技術と業務の翻訳、結果への責任、変化への耐性、客の側に立つ姿勢です。向かない側は、コードだけ書いて業務に出ない、部門をまたいだ会話を避ける、方案だけで実装に降りない、安定だけを求める、給与だけを見る、結果のオーナーシップを持たない、です。下部の一文は、適合を「技術＋業務＋対話＋結果＋変化への耐性」、不適合を「技術か方案だけ、対話と変化からの逃避、短期の得」と要約しています。

本当に要る能力の組み合わせ

市場の要求を分けると、四つに寄ります。AI技術、AI Coding、業務の理解、納品と対話です。

AI技術では、大規模言語モデル、RAG、Agent、モデル呼び出し、知識ベース、ツール呼び出しを、使う側として理解している必要があります。研究者のように中身の数式までやる必要はありません。いつ使うか、なぜその選択か、うまくいかないとき原因がどこに寄りやすいかは、言えないと困ります。

AI Codingでは、この仕事は速さに寄っています。数ヶ月かけて作る前提を、客は置いてくれないことが多いです。要求を早く試し、PoCを出し、方案を動かします。Claude CodeやCodexは、そのための作業の仕方になりつつあります。

業務では、知らない業界と知らない会社を短時間で読めることです。「エージェントが欲しい」と言われて「できます」で止めません。どの業務の区間に価値があるか。Agentが必要か、普通のワークフローで足りるか。詰まりはモデルか、データか、手続きか。そこまで下ろします。

納品と対話では、作ったものは客が使って初めて終わります。デモで止めません。本番に載るか、受け入れられるか、壊れたとき誰が直すか。そこまでが納品の結果です。

要するに、FDEが要るのは新しい道具が一つ、ではありません。企業の中でAIを動かし切る一式の能力です。

これからどう見るか

情報として職名の一覧を集めても、判断にはなりません。見るべきは、その会社のFDEがモデルを配る人か、プラットフォームを現場で鍛える人か、製品を客の業務に埋め込む人か、というニッチの差です。深く入った業界の理解は、汎用のモデル知識より信頼が積み上がります。自分のこれまでの経験は捨てる資産ではなく、この仕事でのレバレッジです。

同じ種類の整理をもっと読みたいときは、サイトのお問い合わせから運営者へ連絡できます。