AI Agent の時代になぜ Forward Deployed Engineer が注目されるのか
Takeaways
- PalantirではFDEが顧客内部に潜り込んで課題を発見することで価値創造していた
- AI Agentは全く新しい市場カテゴリであり、置き換えるべき既存製品がない
- どんな製品が必要とされるかの模索が必要
- AI Agentで顧客に必要とされる製品は、FDEのモデルのように顧客の中からの視点がないと生み出すことが難しい
- ゆえに急激に注目されており、3年前までは0だったFDEの求人が、今では100社以上から募集されている
元Palantirで現OpenAI CROの話
この記事の内容は、先日Y CombinatorのYouTubeチャンネルに投稿されたこちらの動画をまとめたものです。
非常に示唆に富むもので、個人的にもとても面白かったので簡単にまとめてみます。
ゲストスピーカーはBob McGrew氏で、Paypal -> Palantir -> OpenAI CROというとてつもない経歴の持ち主です。
Forward Deployed Engineerとは
ここ最近のAI界隈では、FDE(Forward Deployed Engineer)と呼ばれる、個人的にあまり馴染みのなかった職種をよく耳にします。
すでに色々な解説記事が出されているので詳細な説明は割愛しますが、ポイントをまとめると以下のようになるかと思います。
- クライアント先に常駐し、抜本的な改革につながるビジネスの重要課題を見つける
- (自社プラットフォームプロダクトの上で)クライアントの課題を解決するためのプロトタイプを高速で構築する
これだけでも非常に難しいことが要求される職種であることが理解できます。
この後に紹介するBob氏も「FDEとしての経験が、スタートアップ創業者になるための訓練そのものになる」と説明しているくらいの水準です。まさにCEO/CTO用のOJTと形容できる気がします。
PalantirにおけるFDE
FDEモデルの誕生
パランティアは軍や政府機関をクライアントとしています。したがって引き受ける案件も特殊であり、動画では「スパイ向けの製品」を作る話が紹介されています。
スパイの仕事がなんなのか、どんな製品なら欲しがってもらえるかといったことは、一般の世界で生きていれば当然わかるはずもありません。
そしてスパイも当然自分の仕事を具体的に説明してくれません。
そこでパランティアでは「デモを顧客に見せてフィードバックを直接回収する」というアプローチを取りました（これは最近のスタートアップだと標準的な取り組みになりつつあると思います。）
これを繰り返すうちに 顧客ごとに必要な製品が微妙に異なる ということを見つけ、この経験が転機になりました。
この発見をもとに、具体的な製品を顧客ごとに作るのではなく、顧客ごとにカスタマイズ可能な、プラットフォームに近いもの を構築するアプローチに移行しました。
そして、社長兼CTO（当時は従業員）のShyam SankarがFDE戦略を考案し、FDEがクライアントサイドで 製品ディスカバリー（模索） を行う役割を担うようになりました。
FDEは「砂利道」を作り（道なきところを切り開き）、プロダクトチームがそれを汎用化して「舗装された高速道路」にするという流れが作られました。
FDEチームの構成
FDEのモデルは主に2つのチームから構成されています。
- Echoチーム（組み込みアナリスト）
- 顧客サイドに常駐し、対話を重ねて解決すべき重要な問題を特定する
- アカウントマネージャーとして顧客との関係管理も行う
- 理想的な人材：深いドメイン知識を持ちながらも、現状を劇的に変化（3から10倍の改善）を起こせる「異端児」のような人材
- Deltaチーム（デプロイドエンジニア）
- Echoチームが特定したアイディアを、短期間で現実のプロトタイプとして構築する
- 理想的な人材：迅速なプロトタイピングに長けており、保守性の高いコードを書ける人よりも「決められた期限で成果を出せる」人材
この動画を見るまで、ビジネス要件をまとめる部分とプロトタイピングは一人のFDEが担うものだと思っていたのですが、パランティアではここが分業されているようです。
この2つのチームが互いに連携しながら、顧客の具体的なニーズに対応し、自社製品であるプラットフォームとニーズのギャップを埋める役割を果たしています。
FDEモデルにおけるプロダクトチームの役割
FDEが切り開いた「砂利道」を「高速道路」に舗装するのがプロダクトチームの役割です。
ここではFDEが抽出した各クライアントごとの問題を「次の5-10の顧客に適用できるような汎用化された問題」を特定し、製品に取り込む、というプロセスが発生します。
個別のカスタマイズをそのまま製品に取り込むと、特定の顧客に特化しすぎた製品になってしまう、典型的な失敗につながります。
また「プロダクトのビジョン」を維持することもプロダクトチームの重要な役割の1つです。
つまりプラットフォームの機能として取り込む上では、ある程度の抽象化が重要な要素となるわけです。
FDEチームとプロダクトチームの対立
この2つのチームの連携も難しいようで、実際にパランティア社内においても常に対立があったと語られています。
この対立の主な原因は、それぞれのチームの動機づけと役割の違いにあるようです。
- FDEチームの視点
- FDEは目の前のクライアントの問題を解決することに焦点を当てます。
- したがってその問題を解決するための最もシンプルで直接的なアプローチを取りたいという動機があります（「顧客にとって何が最善か」という視点から、ある種個別最適化されたソリューションを構築したがる傾向にある。）
- プロダクトチームの視点
- 一方でプロダクトチームは、製品のビジョンを維持しながら汎用化された製品を構築することに焦点を当てます。
- したがってプロダクトとしての長期的な保守性や抽象化されたコードを重視する傾向があります。
この対立を解決するためのアプローチも紹介されています。
協調的なデザインプロセス
あるFDEのユニットが特定した課題を汎用化させる際、そのFDEユニットだけでなく「似た課題を抱える顧客を担当する別のFDEユニット」も議論に参加させることが非常に重要だと語られています。
これによって複数の異なるワークフローに対応できるような製品設計が可能となります。
FDEもユーザーのひとり
もう一つ重要な点として、プロダクトチームがFDEを「もう一人の重要なユーザー」として認識することが大切です。
FDEがより少ない労力でより大きな価値をクライアントに提供できるよう「FDEにレバレッジ」を提供することを目指すべき、と語られています。
もしプロダクトチームがFDEのフィードバックなしに独自のアイディアだけで製品を構築しようとすれば「絶対に間違ったものを作るだろう」と述べられており、FDEからのインサイトが製品開発において不可欠であることが強調されています。
ビジネスの観点で考えるFDE
FDEモデルは単なるコンサルティングと誤解されやすいが、似て非なるものとして語られています。
実際に初期のパランティアは「スケールしないコンサルティングビジネスだ」と言われることもあったそうです。
しかし、FDEはビジネスモデルの観点から異なります。
初期は赤字になることもありますが、製品ディスカバリーによって製品が顧客ニーズにより適合し、より重要な問題にアクセスする権利を得る ことで、時間と共にコストあたりの価値が向上し、利益率がプラスに転じます。
一般的なSaaSモデルではサブスクリプションの形式がよく取られますが、FDEモデルでは 価値を顧客に提供した上で、さらにその価値を継続的に大きなものにできるか が重要な観点となります。
言い換えれば提供する価値が時間とともに増えているか（より重要な課題を解決するソリューションを提供できているか）を考えることが大切な要素となっています。
AI AgentスタートアップでFDEモデルが注目されている理由
AIエージェント市場においてFDEが注目される理由はいくつか述べられています。
- 既存製品がない：AIエージェントは全く新しい市場カテゴリであり、置き換えるべき既存製品がありません。そのため、多くの製品ディスカバリーが必要となります。
- 市場の多様性：パランティアの市場と同様に、AIエージェントの市場も非常に多様であり、顧客ごとに異なるニーズがあります。
- エンタープライズ内部からの製品ディスカバリー：顧客企業の中からでないと真の製品ディスカバリーは難しいです（冒頭で紹介したスパイの話は極端ですが、わかりやすい例だと思います。）
- AIの進歩とそれを市場が受け入れる時間軸のずれ：近年の生成AIの進歩はとてつもない速度で進んでいますが、その適用が追いついていません。FDEはこのギャップを埋めるための存在として重要と言えます。
モデルプロバイダーとスタートアップの関係
動画の最後に、Y Combinator側から興味深いアナロジーが紹介されていたので、最後にこれに触れて終わろうと思います。
Jared Friedman氏が動画の最後にしれっと「ある意味でOpenAIがプラットフォームを作る製品部隊で、多くのスタートアップがFDEとして市場ニーズを模索している、というアナロジーも取れるのでは」と言っており、Bob氏も悪くないアナロジーだと同調していました。
確かに振り返ってみればそうかもしれません。
ChatGPTが登場して最初にスタートアップ界隈で加速したのは「プロンプトエンジニアリングによって制御された生成型チャットボット」であり、OpenAIはGPTsを対応する機能として提供しています。
その後RAGなどによる大規模ドキュメントの処理やデータ連携はそれぞれDeepResearch, Connectorsとして機能化されています。
どれもが目立って重要な"adoption"であり、それがある程度汎用化された形でモデルプロバイダー側から提供されているようにも感じられます。
おわりに
今回の記事ではざっくりとした紹介でしたが、細かなニュアンスなどは私の解釈を挟んでしまっています。
拾いきれなかった面白い要素やニュアンスもまだまだあるので、ぜひ一度元の動画をご覧になることをオススメします。
Discussion