FDE：AI駆動のエンジニアリング職における新領域

最近1か月、筆者は前端、ソリューションアーキテクト、プロダクトマネージャー、従来のアルゴリズムエンジニアという4人の転職を検討している友人に出くわした。背景、年齢、都市はそれぞれ異なるが、皆同じ英語の略語を尋ねた：FDE[2]は行く価値があるのか？

FDEは、Forward Deployed Engineerの略称[2]。2年前までPalantirの業界用語に過ぎなかったが、今日ではヘッドハンターの挨拶言葉、求人広告の頻出職種、そしてSNS上で「AI時代で最も価値のある職種」の候補の一つにまでなっている。OpenAIは2026年5月にこの名前でDeployment Company[3]を設立し、初期投資40億ドルを投じ、エンジニアを顧客の現場に派遣し、顧客のワークフローに深く入り込むことを明確に掲げている。AnthropicのApplied AIチームも4つの時差地域で同時にFDEを採用中だ。この用語が業界内スラングから明示的な語彙へと変わるまで、わずか1年余りしかかかっていない。

筆者の前回の記事『スーパーインディビジュアルへ』[4]では、「人間のエンジン」である好奇心、自己学習、自己駆動力、実践能力が、完全なClosed-loopの中でどのように引き出されるかを議論しました。しかし、人間は浮遊しているわけではなく、具体的な職務の座標系に支えられる必要があります。スーパーインディビジュアルがAI時代の生産関係の「原料」であるならば、FDEは今年の市場で最も顕著に現れた「職務の形態」です。

筆者の見解では、FDEはコンサルティングの枠にも、アウトソーシングの枠にも属していない。FDEは、スーパーアイテムに最も近い存在であり、その違いは、FDEが「モデル企業×クライアント」の狭間で組織化されたスーパーアイテムである点にある。

ご存知ですか——「Forward Deployed」という言葉の由来は？もともとは米軍の用語「Forward Deployed Forces」で、海外や前線に配備され、近距離で迅速に対応できる部隊を指し、本土の基地に留まる後方部隊と対比されます。Palantirは2000年代後半にこの言葉をソフトウェア業界に持ち込み、「エンジニアを本社から離して顧客の現場に滞在させる」働き方を表すために使用しました。内部チームさえも軍用音標にちなんで「Delta」と「Echo」と名付けました。今回、OpenAIやAnthropicがこの言葉を再び採用したのは偶然ではありません——エンジニアを前線に派遣するという本質は、これまで一切変わっていないのです。

本文では、筆者が最近この4人の友人から質問された3つの具体的な疑問に答えます。

FDEはAIの外衣を纏ったコンサルティング会社なのか？それと従来のコンサルティングの境界はどこにあるのか？

FDEは、より高度なソフトウェア外注ですか？それと私が現在行っている受託開発との違いは何ですか？

私はFDEに向いているでしょうか？どのようなタイプの人がこの職務で伸ばされ、どのようなタイプが消耗されるでしょうか？

筆者の立場は慎重な楽観です：FDEは確かに育ちつつありますが、すべての人にとっての転換点とは言えません。それを盛り上げるよりも、明確に説明することが重要です。

FDE のこの一連の再ブレイクの瞬間を一つの出来事で示すとすれば、筆者は2026年5月11日を選ぶ。その日、OpenAIはDeployment Companyを設立すると発表し、COOのBrad Lightcapが元のビジネスラインを離れ、special projectsに異動してSam Altmanに直接報告し、このプロジェクトを専任で担当することになった。同じ週、OpenAIは英国のAIコンサルティング企業Tomoroを買収し、150名のForward Deployed EngineerとDeployment Specialistを新会社に一括で迎え入れた。

注目すべきは、OpenAIの採用ページに複数のFDEポジションが同時に掲載されていることだ。サンフランシスコ、ニューヨーク、ワシントンに加え、ライフサイエンス、半導体、政府など業界別に分割された垂直分野でも募集が行われており、FDE採用担当者[6]というポジション自体も募集している。アナリストは、このチームが3年以内に2000～4000人まで拡大すると推定している。これは研究チームの規模ではなく、正規軍である。

Anthropic側ではほぼ鏡像的な動きである。Applied AIチームのForward Deployed Engineerポジション[7]は、ボストン、ニューヨーク、シアトル、サンフランシスコ、ワシントン、ロンドンの6か所で同時に募集されており、顧客現場への出張が25％～50％必要とされている。最近繰り返し引用されている例として、フィンテック企業のFISがある。同社の公告には、「AnthropicのApplied AIチームおよびforward-deployed engineersがFISに組み込まれ、Financial Crimes AI Agentの設計を共同で行い、知識をFISに移転して、今後より多くのAgentを独立して拡張できるようにした」と明記されている。

この言葉には、FDEという仕事の本当の姿が隠されている。それはセールスプリセールスアーキテクトでも、SDRでも、顧客にトレーニングを行うエバンジェリストでもない。モデルを携えて、顧客のコードベースに住み込むエンジニアである。ブラッド・ライトキャップはさらに率直にこう語っている。「我们的客户告诉我们，他们需要的是从 pilot 走到 production 的能力。Deployment Company 就是把我们的工程师塞进他们的团队，给足资源去交付。」

この出来事を図にすると、3者間の関係が非常に明確になります：

この図で最も情報量の多い2本の線は、FDEが両方向に送るフィードバックです。クライアント側には、FDEはモデルをSaaSとして販売するのではなく、クライアントのデータ、権限、コンプライアンス、内部システムを一つのモデルを実行できるパイプに統合します。モデル企業側には、FDEはクライアントのリアルな課題と失敗事例をProductとResearchに持ち帰り、ロードマップに影響を与えます——繰り返しエラーが発生するtool callingパターンが、次期SDKの組み込み抽象化になる可能性があります。

これが、FDEがこのラウンドで2つのトップモデル企業によって同時に再採用された理由であり、その背後には「私たちもPalantirのようにコンサルティングを始める」という単純な話ではない。それはモデル企業が信号収集装置として機能しており、最前線の最も密集した顧客の課題を捉えるには、自社の人員が現場にいなければならない。パートナーを通じて伝えられる要件は、常に一歩遅れる。Anthropicはハイブリッドな道を歩んでいる：FDEを自社で運営しながら、コンサルティング会社やPE業界の巨匠と共同デプロイメントネットワークを構築している。一方は自社主導、もう一方はエコシステム重視だが、その核は同じだ。モデル企業はもはや単なるAPIプロバイダーではなく、自社のエンジニアを顧客の製品に直接派遣するようになっている。

次に答えるのは、最も一般的な2つの比較質問です——FDEと従来のコンサルティング（マッキンゼーやエーカーセンターのような）の境界はどこにありますか？また、私たちがよく知るソフトウェアアウトソーシングとは同じことですか？

多くの人が初めてFDEの職務内容を聞いたとき、最初の反応は「これは新しいマッキンゼー、エーコンシルではないか？」です。

筆者はこのような連想を理解する。スーツを着て、顧客の現場に出張し、顧客の会議室でホワイトボードを描き、Cレベルの経営陣と整合を取る——その光景を見ると、FDEとコンサルタントは確かに似ている。しかし、もう一歩深く見れば、両者の仕事の本質はまったく異なる。コンサルタントはプロセスの境界を売っているのに対し、FDEはモデルの境界を売っている。

これらをテーブルに並べると、差異がすぐに明らかになります。

この表で最も注目すべきは、「資産減価」の行です。

従来のコンサルティングの最も利益を上げるロジックは、資産の再利用——ある銀行向けの提案を、次の顧客には少し修正して再度販売する。小売業のデジタル化プレイブックを30社の顧客に繰り返し適用する。これは過去30年間、Accenture、Deloitte、McKinsey Digitalが成長を遂げてきた基本的な経済モデルである。

FDEにはそのような資産は存在しない。モデルの能力は急速に進化しており、今日では丁寧に設計されたプロンプトチェーンが必要でも、次バージョンのモデルでは一文で済むようになる可能性がある。このような速さの中で、「方法論の蓄積」という概念は急速に価値を失う。したがって、FDEは資産の再利用モデルでは対応できず、毎回クローズドループを再実行しなければならない——モデルの境界を再評価し、ツールスタックを再選択し、製品の形態を再構築する。一見非効率に見えるが、これがモデルの進化速度に追いつく唯一の方法である。

ご存知ですか——Product Overhang とは何でしょうか？筆者は前回の『スーパーインディビジュアルへ』[4] でこの用語を説明しました：モデルの能力は既存の製品形態をすでに超えているが、それを実現するための製品入口、権限、コンテキストが欠けている状態です。FDE という役割の本質的な価値は、顧客のシナリオに浮遊している Overhang を、実際に動作する製品として具現化することです。顧客が購入しているのは、モデル API の呼び出しクォータではなく、「この膨大な Overhang を自社のビジネスに実際に実装してくれる人」の能力です。

これにより、「プロジェクト構成」の行の差異も説明できます。コンサルティングプロジェクトの標準的な構成は、SOW（Statement of Work）＋WBS（Work Breakdown Structure）＋フェーズごとの受入です。契約書には、何を、いつ、どの基準で納品するかを明確に記載します。この構成は、契約締結前に目標が明確に定義されていることを前提としています。

FDEのプロジェクトはこのアプローチではうまくいかない。顧客が最もよく言うのは、「AIが何らかの手助けをしてくれるとは知っているが、具体的に何をすればいいのかわからない」ということだ。目標そのものがプロジェクトの一部である。そのため、FDEはSOWを受けず、むしろミッション——やや曖昧な方向性——を受け入れ、イテレーションを繰り返してその方向性を明確にしていく。そして、あるイテレーションで、これまで蓄積されたモデルの理解を製品形態として実現する。

「納品物」の行も掘り下げる価値がある。FDEが去った後、顧客のシステムに残るのは、動作する機能——小さく、醜く、ユーザーインターフェースがほとんどなくても、毎日誰かに呼び出され、変更され、批判されるものだ。コンサルティングの納品物はPPTと変革管理レポートであり、プロジェクト内でコードを書いたりERPを設定したりしても、最終的に顧客の経営陣の手に残るのは依然として方法論のドキュメントである。

「護城河」という項目が最も繊細である。FDEの護城河は、モデル能力の境界に対するリアルタイムの感覚である——今月どれだけ多くの実際の顧客シナリオを実行したかによって、Claude 4.7が何ができるか、何はClaude 5を待たなければならないかを、他の人よりも深く理解できる。この感覚はPPTに書き込むことも、知識ベースに保存することもできず、直近90日間で実際に手を動かしたエンジニアの脳みそにしか育たない。

だから、次に誰かが「FDEって新しいアクセンチュアだよね」と言ったら、こう返してみてください：アクセンチュアのエンジニアは顧客のプロセスを再設計しに行きますが、FDEはモデルの境界を再発見しに行きます。前者の資産は10年間蓄積できますが、後者の資産は90日後にまた一から育て直さなければなりません。

「FDEは新バージョンのアクセンチュアである」というのは第一層の誤解であり、「FDEは高価なソフトウェアアウトソーシングである」というのは第二層である。この第二層は、表面的な証拠が非常に豊富であるため、より誤解を招きやすい：FDEは実際に顧客の現場でコードを書き、顧客のビジネスに合わせて機能をカスタマイズし、顧客の勤務時間に応じて作業を行う。一見すると、アウトソーシングエンジニアと何ら変わらないように見える。

しかし、フィードバックループを見ただけで、違いは隠せない。

この図で最も重要な違いは、上半分がどれほどシンプルであるかではなく、下半分にモデル企業へと延びるフィードバックの連鎖が追加されている点です。この連鎖は装飾ではなく、FDEという職種が存在する真の理由です。この差異を分解すると、少なくとも四組の対比が見られます。

接するものが異なる。外部委託ではSOW——契約締結前に明確に定義された要件リスト：どの機能を実装するか、どの技術スタックを使用するか、どの基準で検収するか、違反した場合の賠償方法。FDEはミッションを受ける——クライアント自身も何を必要としているか明確でなく、「AIが何らかの手伝いをしてくれればいい」とだけわかっている。SOWは確定性を前提とし、ミッションは探求を前提とする。両者はまったく異なるプロジェクト開始の姿勢である。

範囲が異なります。外部委託は部分的な納品—モジュール、ウェブサイト、データパイプラインなどを作成し、完了次第引き渡して次の案件へ移ります。FDEはエンドツーエンド—ビジネスの課題から始まり、モデル選定、プロダクト設計、そしてリリース後のユーザーの継続率と離脱率までを担当します。

課金方法が異なる。これが最も直感に反する点である。あるモデル企業がFDEを顧客現場に派遣する際、最終的に気にするのは今回のプロジェクトでどれだけコンサルティング料を徴収するかだけでなく、この顧客が今後どれだけのトークンを消費するか、リテンション顧客になるか、さらには他のビジネスラインにも拡大するかである。FDEの真のKPIは、プロジェクト受入書上の数字ではなく、モデルトークンの長期的な消費曲線である。

フィードバックの行き先が異なる。これは4つのグループの中で最も深いレベルである。外部委託プロジェクトでは、クライアントのフィードバックは外部委託会社までしか届かず、同社が今後他の顧客に販売する製品に影響を与えることはない。一方、FDEのフィードバックは、モデル企業のロードマップに還流する。顧客が実際のシナリオで遭遇するあらゆる課題、あらゆるPromptの失敗、あらゆるツール呼び出しのバグは、次バージョンのトレーニングデータ、次バージョンのツール設計、次バージョンの製品機能への入力となる。つまり、FDEを導入する各顧客は、モデル企業にとって天然のデザインパートナーである。

これがモデル企業が高給でFDEを採用する真の理由である。彼らは単にサービスを販売しているのではなく、顧客の現場で現実世界の製品形態のシグナルを収集している。これらのシグナルは、購入することも、捕捉することも、アンケート調査で得ることもできない——それは、特定のエンジニアが特定の顧客のワークフローの中で、数回壁にぶつかってこそ持ち帰れるものなのだ。

ご存知ですか——OpenAI や Anthropic の FDE の総報酬はどのくらいでしょうか？Levels.fyi に公開されている Anthropic のソフトウェアエンジニアのデータ[8]によると、シニアSDEの総報酬の中央値はすでに71万ドルに達しています。FDEというポジションはリスクがより高く、モデル能力の不確実性、顧客ビジネスの不確実性、製品形態の不確実性のすべてに直面しなければならず、業界の整理[9]では、先端AIラボにおける中上級FDEの総報酬は基本的に35万～55万ドルの範囲にあり、Staffレベル以上では63万ドル以上にも達します。この報酬は「外部委託の労働時間」に対して支払われるものではなく、「製品＋顧客＋モデル」という3つのリスクを統合的に担う者に対して支払われるものです。> 2006年、筆者が初めて就職したとき、ある中央企業に勤務しており、当時は情報化への移行が進行中でした。当時、当社グループはエーカー・コンサルティングのコンサルタントを現場に常駐させ、グループは毎日3500元のコンサルティング料を支払っていました。このコンサルタントは数年間滞在し、当時のメディアから「金髪族」と称されました。その後、筆者はドイツのSAP社に転職しましたが、SAPはコンサルティング業界に「SAPコンサルタント」という名前を定義し、SAPコンサルタントは「金髪族」の象徴となりました。このように見ると、FDEの給与は少なくとも24～36ヶ月の間継続的に上昇し、需要も安定的に増加しています。

アウトソーシングは労働力アービトラージであり、FDEはフロントラインセンサーである。この二つを混同すると、クライアントはFDEをSOWの方式で採用できると誤解し、候補者もアウトソーシングの姿勢でFDEに臨むことになる。両者ともすぐに壁にぶつかるだろう。

多くの人が、FDEという用語はOpenAIが発明したと誤解しているが、それは誤りである。FDEには二つの歴史的ルーツがあり、一つはPalantirに由来し、もう一つは2023年以降の新世代モデル企業に由来する。この二つのルーツを並べて見ることで、FDEという職務が実際に何を行っているかをより明確に理解できる。

まずタイムラインをご覧ください。

最初の根はPalantirです。

パランティアは2003年、ピーター・ティール、アレックス・カープ、ジョー・ローンズデールらによって設立され、最初の顧客は米国諜報機関であった。カープ自身はCSのバックグラウンドを持っておらず、フランクフルトで哲学者ユルゲン・ハーバーマスのもとで博士課程を修了した後、ティールに誘われてCEOに就任した。FDEという職位は、まさにこのような「非典型的なCEO＋高度に機密性の高い顧客」という組み合わせから生み出されたものである。36Krの振り返り[10]では明確に記されているが、パランティアの初期段階では、エンジニアが実際のビジネスシーンにアクセスできず、要件が複数段階で伝達されるうちに歪んでしまったとして、諜報機関から激しく批判された。その後、パランティアは自社のエンジニアを顧客の現場に直接派遣し、諜報アナリストと共同で作業させるという取り組みを実現した。このモデルは後にシヤム・サーンカーによって体系化され、FDEの原型となった。

2009年までに、FDEは商業分野に拡大した。JPMorganがPalantirのMetropolisプラットフォームを導入した際、120人のFDEが内部脅威監視のために配置された。この時点から、FDEは単に「エンジニアを出張させる」ことではなく、Foundry/Gothamを顧客のビジネスフローに本格的に組み込む、体系的な顧客埋め込み戦略へと進化した。

PalantirのFDE採用には、CSの学歴を要求しないという直感に反する基準があります。これは「知っていますか」に含められます。

ご存知でしたか——Palantir FDEはCSの学位を必要としません？SkillScouterが整理したPalantirの採用基準[11]とPalantir公式キャリアページ[12]によると、PalantirはCS以外の専攻の候補者を明確に歓迎しており、最近のFDE採用者は機械工学、経済学、哲学などの専攻出身です。本当に重要なのは、不完全な情報の中でも行動できる能力と、Cレベルのクライアントと直接対話できる能力です。CSの学位はプラスアルファの要素であり、入場券ではありません。Karp自身がこの基準の最初の例であり、哲学を学んだCEOが、物理、数学、哲学を学んだFDEたちを率いています。

第二条根是2023年以降の新世代モデル企業です。

ChatGPTが2022年末にリリースされた後、OpenAIはすぐに一つの事実に気づいた。モデルAPIをドキュメントに掲載して、顧客が自力で接続する方式では、全く対応しきれないということだった。顧客が使いたくないわけではない。使い方がわからないのだ——彼らにはビジネス上の課題はあるが、製品の形態がない。そこでOpenAI、Anthropic、Cohere、Scale、Glean、Sierra、Hebbia、Decagonといった企業たちは、次々とFDEを大規模に採用し始めた。

今回のFDEは、Palantirの手法を学んでいる——エンジニアを顧客の現場に派遣し、エンドツーエンドでワークフローを実行する。しかし、製品のキャリアはまったく異なるものになった：Palantir時代のFDEはデータ統合とUIカスタマイズを手がけていたが、新世代のFDEはPrompt設計、Agent編成、ツール呼び出し、ワークフロー埋め込みを担っている。

Pragmatic Engineer のFDEに関する専門記事[13]では、この新バージョンを「エンタープライズに組み込まれ、Claudeが実際の具体的な高価値問題を解決する」ものと呼び、表現はPalantir当時とほぼ一致しているが、「データ」を「モデル」に置き換えている。

この二つの根を一緒に見ると、明確な共通点と違いが見られます。

共通点：顧客が購入しているのはソフトウェアではない。顧客が購入しているのは「私の問題を解決してくれるエンジニア＋ツールの組み合わせ」である。これは過去30年間の企業ソフトウェアの歴史において異常なことだった。SAP、Oracle、Salesforceはソフトウェアそのものを販売しており、エンジニアは「顧客がこのソフトウェアを使えるようにする」ための補助リソースに過ぎなかった。一方、Palantirはその逆である：ツールは「FDEが顧客の現場で問題を解決できる」ためのレバーとして存在する。新世代のモデル企業はこの逆転関係を継承している——OpenAIはGPT-4のライセンスを売っているのではなく、「私たちのFDEがGPT-4を使って、あなたのカスタマーサポートを自動化するのを支援する」ことを売っている。

違い：Palantir時代はOPS統合に偏重——主な焦点はデータ統合、オントロジーモデル化、権限管理にある。新世代はモデル能力の実装に偏重——主な焦点はPrompt設計、エージェント編成、リテンション最適化にある。前者はシステムインテグレーターの進化版であり、後者は製品エンジニアの拡張版である。

最後に興味深い事実として、Palantirの早期FDEの多くが起業家となり、あるいは新世代のモデル企業に直接参加しました。Anthropic、OpenAI、Sierra、Hebbiaの初期チームには、数えきれないほど多くの元Palantir社員がいます。これは偶然ではありません——FDEという役職自体が、製品リスク、顧客リスク、エンジニアリングリスクを同時に担うことを求め、まさに起業家の訓練課程です。筆者はPalantirを隠れた起業家育成プログラムと見なしたいと思います。ここで育まれるのは単なるエンジニアではなく、不完全な情報の中でも物事をゼロからイチへ推し進める方法を知る人々です。この二つの根は、2023年以降にようやく合流しました。

二つの根の合流は主に海外で発生している。国内では、FDEという用語の登場はそれほど長くないが、それに該当する業務内容がいきなり生まれたわけではない。国内のFDEを理解するには、まずその二つの地元の前身を把握し、次にアメリカ版FDEとの三つの環境的差異を明らかにすることが必要である。

二つのローカル元々の前身

最初の前身はクラウドベンダーのソリューションアーキテクトである。アリババクラウド、テンセントクラウド、華為クラウドは過去10年間で、顧客に対してアーキテクチャを説明し、POCを作成し、移行方案を策定し、導入から運用までを支援する一連のSolution Architect（SA）チームを育成してきた。華為内部には、プロジェクトを顧客のデータセンターに実装するための専門の「デリバリーエンジニア」職種も存在する。この体制はFDE業務の80％を既にカバーしているが、依然として営業前段階と導入に重心が置かれており、エンドツーエンドの製品イテレーションの責任はSAにはない。要件が変更された場合は変更プロセスを経る必要があり、モデルを変更する場合は本社のスケジュールを待たなければならない。

二番目の前身は、AIスタートアップ内で新たに生まれた職種である。MiniMaxはBOSS直聘に「AIプリセールスソリューションスペシャリスト」を掲載しており、月の裏側、智譜、通義、混元などのモデル企業も同様の職種を掲載している。名称には若干の差異があるが、職務内容（JD）は非常に類似している：顧客のシナリオを理解し、デモを作成し、Promptを調整し、RAGを実行し、納品方案を作成し、顧客のエンジニアリングチームと連携してリリースまで対応する。この一連の職種が真正意义上的「国内FDE」である。

三つの水土の違い

プライベート化部署とデータコンプライアンスが、純粋なモデル呼び出しモデルを圧迫している。国内B2B顧客は、データの域外流出防止、モデル重みの制御、監査の追跡可能性に対する要件が米国市場よりもはるかに高い。FDEプロジェクトにおいて、APIを呼び出してプロンプトを実行する作業量は全体の3割に過ぎず、残りの7割はモデルを顧客のデータセンターに移設し、認証を実装し、データプラットフォームと連携し、コンプライアンス届出を行うことである。

モデルの能力はまだSOTAに追いついておらず、競争の余地はエンジニアリング層に圧縮されている。米国のOpenAIやAnthropicは、モデル自体の能力で顧客を魅了できるが、国内の通義、豆包、Kimi、GLM、DeepSeekはモデルの差別化がそれほど大きくなく、顧客の判断基準はAgentの編成、RAGの検索品質、ツール統合、ワークフロー設計といったエンジニアリング能力に集中している。国内のFDEは「自社のモデルがどれほど強いか」ではなく、「このビジネスを本当に実行できるか」で勝負している。

B端の支払い意欲と価格設定のペースは米国とは異なる。Palantirのような「まずFDEを導入し、その後高単価のサブスクリプションを課金する」モデルは、そのまま適用するのは難しい。国内の顧客は年次予算に沿って支出し、支払いはプロジェクト単位に偏りがちであり、FDEのビジネスモデルは通常、サブスクリプション＋プライベートライセンス＋プロジェクト納品のハイブリッド形態となる。

独自のポジショニング：内部FDE

大手企業の多くのAIチームが、FDEモデルを用いて「内部顧客」にサービスを提供し始めている。阿里雲PAIはエンジニアを淘宝に派遣し、腾讯の混元も微信や広告事業部門と同様のメカニズムを導入している。JDでは「業界実装エンジニア」「AIアプリケーションエンジニア」「スマート化ビジネスエキスパート」として掲載されているが、これらは本質的に内部FDEであり、モデルチームの能力をエンドツーエンドで事業側に実装している。これは大手企業のリーダーに新たなアイデアを提供している：数名の内部FDEを事業側に配置し、最初のデモを実行してROIデータを事業責任者に提出すれば、10回の調整会議よりも早く部門間の壁を解消できる。

前回の『スーパーアイデンティティへ』[4] で、スーパーアイデンティティの5つのエンジンとして、好奇心が強い、探求・革新精神が強い、自己学習能力が高い、自己駆動力が強い、実践力が高い、という5つを挙げました。これら5つはFDEの入場券ですが、それだけではありません。FDEという職種には、この5つのエンジンに加えて、非常に具体的な追加的特性があり、いくつかの人格タイプは明確に不向きです。筆者は、優秀なエンジニアがFDEに転向した後に適応できず、問題が能力ではなく性格や仕事の好みにあるケースを多く見てきました。

FDEに適した5つの特性

販売やコミュニケーションを避けない。FDEの日常は、閉じこもってコードを書くことではなく、顧客のCTO、ビジネス責任者、調達担当、コンプライアンス担当、IT担当と直接やり取りすることだ。典型的な流れはこうだ：顧客のCTOがデモの最中に中断してきて、FDEの反応は「後でバージョンを修正して来週また来ます」ではなく、その場でIDEを開いてPromptを変更し、再実行して見せることだ。「顧客がいる中で、私が修正中」——これがFDEの日常である。

曖昧な領域を楽しもう。FDEが受け取るのは明確なPRDではなく、「AIを使って何かやりたい」という一言だ。クライアント自身も何を望んでいるか明確に言えないため、FDEはその曖昧な期待を具体的な形に育てるために一緒に歩む必要がある。明確な要件がないと動けないなら、FDEの日々はあなたを不安に陥れるだろう。

エンジニアリング力はしっかりしているが、10xを求めていない。FDEには、会社で最もコードが綺麗で、アルゴリズムが最も深い人である必要はない。必要なのは、エンドツーエンドで動かせることだ：フロントエンドはクリック可能なページを適当に作ればよく、バックエンドは動くサービスを構築できればよく、モデルはビジネスデータソースに接続できればよい。FDEの世界では、「だいたいできればいい」ことは欠点ではなく、美徳である。

フィードバックに磨かれるのが好き。FDEの仕事には、クライアントから「これじゃない！」と叱られてやり直す場面がたくさんある：今日のデモが明日、事業部門から「これは私が求めているものじゃない」と言われる。先週合意したプランが、今週クライアントの経営陣が替わって、また一から作り直しになる。FDEに適している人は、こうしたフィードバックを燃料と捉え、エンドツーエンドの責任を担い、「要件が明確でなかったから」と責任を転嫁しない。

モデルの境界に敏感である。これは最も技術的で、最も隠蔽されたポイントである。FDEは、どのようなタスクがLLMに適しているか、どのようなタスクには不適切か、そしてどのようにフォールバックすべきかを判断できる必要がある。このような敏感さは論文からは読み取れず、失敗事例の積み重ねによってのみ身に付く。失敗事例が蓄積されることで、FDEはモデルの境界に対する筋肉記憶を獲得する——どのシナリオではRAGを使用すべきか、どのシナリオではルールベースで処理すべきか、どのシナリオでは人間へのフォールバック入口を必ず設けるべきかを理解するようになる。

FDEに適さない4つのタイプの人

コードの中に隠れたい純粋なテクニカルマニア。FDEは約50％の時間をコードを書くのではなく、クライアントミーティング、内部調整、製品ディスカッション、契約推進に費やしている。もしあなたの喜びが、4時間連続で誰にも邪魔されずにコードを書くことなら、FDEは長期的に精神的疲弊を引き起こすだろう。

OKRがないと動けない人。FDEの目標は顧客にあり、あなたのパフォーマンス評価表にはない。作業の進捗は、顧客のプロジェクトの節目、モデルの能力の変化、そして自分自身のシナリオに対する判断によって決まる。「まずOKRがあって、それから何をすべきかわかる」という習慣に慣れてしまった人は、支点を見出せなくなる。

「昇進」を「作品」より重視する人。FDEは大手企業の昇進システムでは有利ではない——顧客満足度、プロジェクト契約、再利用率などの指標は、コード量やリリース頻度と比べて、職級審査で響かない。もしあなたの仕事の動機が昇進が最優先なら、FDEは適していない。

ビジネスの文脈に抵抗を感じる人。FDEは、顧客の損益計算書、ROI、調達プロセス、コンプライアンス要件を理解しなければならない。もし金銭や契約、ビジネスロジックの話に自然と抵抗を感じるなら、FDEの仕事は、技術的理想を売っているように感じさせるだろう。

セルフチェックリスト

FDEの実際の業務シナリオに対応する7つの質問。5つ以上「はい」と答えた場合、FDEを真剣に検討してください。3つ以下の場合、慎重に検討することをお勧めします。

1. 毎日50％の時間をコードから顧客ミーティング、メッセージの返信、電話に振り替えることに賛成ですか？

2. お客様が「これではダメです、なぜかはうまく説明できません」と言うとき、あなたの最初の反応は好奇心ですか、それともイライラですか？

3. 誰もPRDを書いてくれないが、クラウドコードと協力して、顧客に見せられるプロトタイプを1週間以内に実現できるか？

4. 同じ納品物について、クライアントに8回も修正を依頼されても、機械的に実行するのではなく、判断力を保てますか？

5. モデルが誤った回答を出したとき、あなたの最初の反応はフォールバックを設計することですか、それともモデルができないと文句を言うことですか？

6. 契約に署名し、報告書を作成し、顧客の受入作業を進め、法務部門とコンプライアンス条項を調整できますか？

7. プロトタイプを迅速に作成し、迅速に失敗することを受け入れられますか？

五つの特性、四つの逆画像、七つの自己診断クイズ——最終的に同じ問いにたどり着く：あなたの製品感、エンジニアリング力、ビジネス判断の三つを、同じワークフローの中で同時に磨き上げる気があるか。

前回の記事では、「人間のエンジン」としての好奇心、探求心、自己学習能力、自己駆動力、実践力を、大手企業内でどのように完全なサイクルで引き出せるかを議論しました。今回は別のテーマ、すなわち職務の形態について考察します。FDEは、AI産業革命の中で、名前を持ち、給与帯が設定され、募集要項が存在し、顧客からの支払いによって検証された最初の新しい職務形態です。これは「スーパーインディビジュアル」という概念の同義語ではなく、この再構築の波の中で、初めて虚から実へと具体化された座標です。

FDEは終わりではない。筆者の見解では、FDEは新しい分業の中で最初に名前が付いた形態に過ぎず、その先にはForward Deployed PM、Forward Deployed Designer、Forward Deployed Researcherなどが登場するだろう。クライアントのシナリオと密接に連動し、曖昧な領域で製品を育成する必要があるあらゆる職種が、自らの「前置部署」バージョンを生み出すことになる。職種の名前は変わるが、その根底にあるロジックは同じだ。モデル能力が先行し、製品形態がその後に追いかける。職務構造はワークフローに合わせて再編される。

三つの読者層にそれぞれ一文ずつ。

技術者向け：FDEは、あなたが会社で最もコードが得意な人であることを求めませんが、コードの時間を半分に減らして顧客側に回す意欲を求めます。もし答えが「はい」なら、市場の窓口が開きました。国内のトップAIモデル企業、クラウドベンダー、大手企業の内部AIチームの採用が加速しています。もし答えが「いいえ」なら、問題ありません。新しい分工の中で、あなたに合った新たなポジションが生まれます。

HRおよびODへ：「名実の乖離」に注意してください。あなたの会社にはすでにFDEが存在しており、職務コードには「ソリューションエキスパート」「業界アーキテクト」「AIアプリケーションエンジニア」と記載されている可能性があります。彼らを特定し、再分類し、実際の業務内容に見合ったキャリアパスを提供することは、新規採用よりもはるかに効率的です。

管理者へ：FDEモードは外部だけでなく、内部にも適用できます。社内に数人の「内部FDE」を業務現場に配置し、モデルチームの能力をエンドツーエンドで業務プロセスに組み込む方が、新しいAI部門を設立して十回以上の跨チーム調整会議を開くよりもはるかに効率的です。部門間の壁は組織設計によって解消されるのではなく、実行可能なデモによって解消されます。

AI時代の職業転換がすでに始まっている。FDEはその最初の合図であり、モデルの能力の変化の速さが、新たな職種を生み出すまでに至っていることを示している。筆者は読者に具体的な問いを残したい：3年後、あなたの会社の組織図に新しい職位が3つ追加されたとしたら、それはどのような職位だと思うか？この問いをしっかりと考えることが、この記事を読むことよりもはるかに役立つ。

👦🏻 作者: Henry（DeerFlow チーム）[1]