企業が本当に FDE を必要とするのはいつか？ チーム立ち上げ前に通過すべき2つの関門

エンタープライズソフトウェアには、何度も繰り返される難題がある。ベンダーが強力な基盤プラットフォームを提供し、顧客が料金を支払っても、その能力をどう実際の事業成果に結び付ければよいのかが分からない。Palantir Foundry を例に取ると、データを集約し、オントロジー（ontology）を構築して、基盤データを倉庫などの業務オブジェクトに変換し、その上でアプリケーションを開発できる。それでも企業の責任者は「これが実際の事業にどう役立つのか」と問う。技術だけを売れば、課題の理解、プラットフォームの学習、アプリケーションの構築は顧客の責任として残る。

フォワード・デプロイド・エンジニア（Forward Deployed Engineer、FDE）が埋めようとしているのは、まさにプラットフォームの能力と事業成果の間にある距離だ。現在 Anthropic に所属する Kevin Bai は、AI Engineer World's Fair の『FDE 101』という講演で、FDE とは何か、なぜ企業に必要なのか、そしてなぜ AI 時代に採用する企業が増えると考えるのかを説明した。彼は以前 Palantir で関連業務に携わり、その後 Rippling の FDE チームに最初のメンバーとして加わり、1年で約25人のチームに拡大するのを支えた。特に実用的なのは、FDE が本当に必要な「製品と買い手の組み合わせ」と、FDE が受託開発に変質しないために必要なプラットフォーム基盤を、具体的に判断できることだ。

顧客が買うべきなのは成果であり、学ばなければ使えないプラットフォームではない

プラットフォームだけを売ると、顧客はソフトウェア料金に加えて、使い方を学ぶ人手も投じなければならず、そこで初めて役立つアプリケーションを作れる。FDE はプラットフォームとエンジニアリングサービスを一体化する。エンジニアがまず顧客の業務を理解し、既存のプラットフォーム上でソリューションを組み立てる。顧客が買うのは、単なるソフトウェアでも、特定の人の作業時間でもなく、実際に動く事業成果になる。通常はベンダーがプラットフォームを売った後、顧客が学習と実装を担う。FDE では、業務の理解、ソリューションの構築、成果の提供までが顧客の購入内容に含まれる。そのため FDE は、受注後に問題を補修する実施担当者ではなく、製品を売り、届ける方法そのものの一部だ。

消費財（CPG）企業を例に取ると、事業部門が気にするのは、商品をより多くの棚に並べられるか、売上を伸ばせるかであり、データの構造は実現手段にすぎない。FDE の仕事は、その業務要件を理解し、すでにあるプラットフォームの能力を使ってソリューションを作ることだ。

この協業方式は新しいものではない。B2B スタートアップの初期には、作り手も顧客も、最終的な製品が何か、顧客が実際に何を買っているのかをまだ十分に理解できていないことが多い。顧客は現実の課題を提供し、チームは時間、資源、技術を投じて一緒にソリューションを作る。その過程で、顧客が本当に対価を支払う製品の形、つまりプロダクト・マーケット・フィット（PMF）を見つけていく。FDE は、この「デザインパートナーシップ（Design Partnership）」を創業後の最初の18カ月だけで終わらせず、大企業との長期的な提供に延長する仕組みと考えられる。

1枚の ACV 図が示せること、示せないこと

年間契約額（ACV）とは、1社の顧客が1年間にベンダーへ支払う金額だ。これらの数字は、すべての企業に共通の投資基準を示すものではない。Palantir の顧客1社あたりの売上が、他の大手エンタープライズソフトウェア企業とどれほど違うかを示している。

推計図では、Palantir の ACV は約400万ドル、ServiceNow は約120万ドル、Workday は約80万ドル、Snowflake は約32万2,000ドル、Salesforce は約25万2,000ドル、Microsoft Azure は約21万4,000ドルとされている。Workday には、別の留保付き推計として約60万ドルという数字もある。

これらの数字には、共通の基準日や完全な算出方法がない。売上高を企業が開示した顧客数で割った数字もあれば、完全なデータが公開されていない場合に、近い事業セグメントの数値や第三者の推計を使った数字もある。したがって、この図を厳密に比較可能な業界財務ランキングとして使うことはできず、Palantir の高い ACV が FDE だけで生まれたことも証明できない。読み取れるのは、プラットフォームとエンジニアリング提供を組み合わせた Palantir の顧客1社あたりの売上が、一般的な SaaS 企業より明らかに高いということまでだ。

本当の判断軸：製品はどれほど技術的か、買い手はどれほど技術的か

すべてのエンタープライズソフトウェアに FDE が必要なわけではない。必要性を判断するには、製品の実装の難しさと、顧客チームが自力で実装できるかを同時に見る必要がある。重要なのは、契約に署名する役員が技術を理解しているかではなく、実際にソリューションを構築し使う担当者が、プラットフォームを稼働する業務システムに変えられるかだ。

技術的な製品を技術的な買い手に売る場合、FDE は必要ない。 GitHub や Datadog は複雑でも、ユーザー自身がソフトウェアエンジニアであり、その複雑さを理解して使える。

設定で使える製品を非技術的な買い手に売る場合も、FDE は必要ない。 Rippling、Jira、Slack も複雑な製品だが、ユーザーが製品上で開発するのではなく、設定を変えて使えるように設計されている。

技術的なプラットフォームを、ソフトウェア実装力の不足した事業チームに売る場合こそ、FDE が本当に必要になる。 Google、Meta、AI ラボには、必要なアプリケーションを自社で作れるエンジニアリングチームがある。しかし、『Fortune』500社に入る石油・ガス企業が同じ能力を持つとは限らない。石油・ガス企業は石油パイプラインの建設には長けていても、データをシステム間で流す「データパイプライン」の構築に長けているとは限らない。顧客が自力で実装するには、エンジニアを採用・管理し、離職を防ぎ、チーム全体に新しいプラットフォームを学ばせる必要がある。FDE が提供するのは、プラットフォームに精通し、顧客の現場で業務を理解できるエンジニアリング力だ。顧客と一緒に問題を定め、使えるソリューションを作る。

このマトリクスは、FDE の誤用を避けるために役立つ。「大企業の顧客だから」という理由だけで設ける職種ではなく、ACV が高い製品に必ず必要な役割でもない。判断を左右するのは、製品の複雑さと、買い手が実装できる能力の間に、本当に隔たりがあるかどうかだ。

FDE と受託開発の境界線は、顧客向けソリューションの下にある

「企業顧客ごとにカスタマイズするなら、最終的には互いに関係のない大量のコードが残り、誰も保守したがらなくなるのではないか」という反論はもっともだ。FDE が顧客ごとにゼロから構築するのなら、チームが行っているのはここでいう FDE ではなく、受託開発（dev shop）だ。

すべての顧客向けにゼロから開発すると、顧客数が増えるほど独立したコードベースと保守負担も増える。同じ機能を何度も作れば、長期的な保守費用が利益を食い潰し、その前にエンジニアが離れてしまうおそれもある。

両者を分けるのは、データモデル、アプリケーションコンポーネント、ワークフローなど、繰り返し使える共通モジュールがあるかどうかだ。顧客向けソリューションはカスタマイズできるが、毎回白紙から始めてはいけない。

例えば、1社目の小売顧客が「在庫が安全水準を下回ったら購買担当者に自動通知する」機能を必要としたとする。FDE はまずその顧客向けにソリューションを作る。2社目、3社目も同じニーズを持つなら、在庫判定、通知、承認フローをプラットフォームの共通モジュールにするべきだ。次の顧客は自社のデータを接続し、安全在庫水準と承認者を設定するだけでよく、通知システムを作り直す必要はない。1社にしかない特殊なルールは、その顧客固有のソリューションに残せばよい。

このように、現場プロジェクトは保守作業を増やすだけでなく、製品を継続的に強化する。逆に、顧客ごとに独立したコードベースがあり、同じ機能を何度も開発し、古いプロジェクトを当初の担当エンジニアが長期にわたって保守するなら、顧客数に比例して負担も重くなり、チームは事実上の受託開発会社になる。

ここから、「エンジニアを顧客の現場に送れば、直接売上を生み出せる」という考えが魅力的に見えても、それだけでチームを立ち上げてはいけない理由が分かる。強固なプラットフォームがあっても、顧客向けソリューションの保守負担は重い。プラットフォームはその負担を管理するための前提であって、負担をなくすものではない。プラットフォームがなければ、この問題は致命的になる。

AI により、「顧客が自力で実装できない」技術製品が増える

AI はコードを書きやすくし、複雑なカスタムソフトウェアも作りやすくした。さらに大きな変化は、課題を自律的に分解し実行できるプラットフォームが増え、顧客がカスタマイズできる範囲も広がっていることだ。しかし、カスタマイズの自由が大きいほど、使い方は固定的な SaaS 機能ほど明確ではなくなる。顧客は能力の高さを理解できても、自社のどの業務課題を解決できるのか、データをどう接続し、業務フローをどう設定し、実際のユーザーにどう届けるのかが分からないことがある。コードを作ることが簡単になっても、問題定義、ソリューション設計、企業への実装まで自動的に簡単になるわけではない。

ソフトウェアベンダーが実装の成否をすべて顧客に委ねると、より大きな企業に提供するとき、さまざまな用途に広げるとき、新しい業界に進出するときに、より大きな障壁にぶつかる。

まだ検証が必要な仮説は、AI によって「製品はより技術的になる一方、実際の買い手には実装を完了できるだけのエンジニアリング力がない」というミスマッチに直面する企業が増える、というものだ。これは証明済みの普遍的な法則ではなく、自律的にタスクを実行できるすべての AI 製品が FDE を必要とする意味でもない。確かめるべきなのは、製品を購入してから実際に使えるようになるまでに、どれだけのエンジニアリング作業が残っており、顧客がそれを自力で完了できるかだ。

5つの実務上の問いで、境界を明確にする

FDE チームを立ち上げ、運営するときには、5つの具体的な問いが生まれる。機械的に当てはめられる唯一の正解はないが、チームの役割分担とプラットフォーム設計を点検するために使える。

プラットフォーム側でどこまで事前に用意し、どこからを顧客ごとにカスタマイズできるようにするか？ 答えはユーザー層と業界によって異なる。「アプリケーションの60%が完成しており、顧客が残り40%をカスタマイズする」状態から始められる業界もあれば、より基礎的で柔軟なツールが必要な場面もある。60/40 は例であり、目標値ではない。AWS に置き換えると分かりやすい。エンジニアリングチームは理論上、自らサーバーを購入し保守できるが、通常はクラウドプラットフォームを使う。DynamoDB も、データベースをゼロから発明する必要をなくしている。ユーザー間の違いが大きいほど、プラットフォームは多くの用途に使える基礎モジュールを提供する必要がある。ユーザーが狭い業界に集中しているなら、業界で共通する能力をプラットフォーム側でより多く事前に用意できる。すべての企業に通用する固定比率はない。

1つの顧客アカウントを複数の FDE で担当すべきか？ 2人以上がプロジェクト情報を共有する方が安全だ。1人しか詳細を知らなければ、その人が休みを取ったり退職したりしたとき、他の人が引き継ぐことが難しくなり、プロジェクトが止まるおそれもある。

異なるベンダーの FDE は、1つのプロジェクトでどう協業するか？ AWS と Palantir のエンジニアが同じプロジェクトに参加する場合を例に取ると、まず両社が同じ契約を奪い合う関係なのか、パートナーとして共同提供するのかを分けて考える必要がある。後者なら、最終的な納品に責任を持つのは誰か、誰がそれを支援するのかを事前に明確にする。これで決まるのは基本的な役割分担だけで、ベンダー間で意見が分かれた場合の解決方法は別途決める必要がある。

顧客固有の機能と、プラットフォームの共通機能をどう分けるか？ 1社だけに必要な機能はその顧客向けソリューションに残し、多くの顧客が繰り返し必要とする機能は、プラットフォームの共通モジュールにする。初期に共通モジュールが少ないのは自然なことだ。FDE が顧客の現場で見つけた繰り返しのニーズは、製品チームが次に何を作るべきかを判断する材料になる。

どのような人が FDE に向いているか？ 基本条件はしぼれる。ソフトウェアエンジニアとしての採用基準を満たし、同時に会社が顧客と直接話す役割を安心して任せられる人だ。つまり、「顧客と直接向き合えるソフトウェアエンジニア（customer-facing software engineer）」である。

FDE チームを立ち上げる前に、2つの関門を通過する

第1の関門：顧客は自分で実装したくないのか、それとも実装できる能力がないのか？

契約書に署名する役員ではなく、製品を実際に使えるシステムに仕上げる顧客チームを見る。次の3つの場合は分けて考える必要がある。

• 顧客に成熟したエンジニアリングチームがあり、製品に慣れていないだけなら、まず技術文書、デベロッパーリレーション（DevRel）、技術サポートで支援する。通常、FDE を長期にわたって参加させる必要はない。
• チェックボックスを選び、データを接続し、ルールを調整すれば実装できる製品なら、営業、カスタマーサクセス、導入コンサルタントで十分なことが多い。
• コードの記述、データモデルの設計、複雑なワークフローの構築が必要な製品で、それに必要なエンジニアリングチームが顧客側にないなら、第1の関門を通過する。

簡単な確認質問は、ベンダーがエンジニアを派遣しなくても、顧客は現実的な期間で製品を稼働するシステムに変えられるか？ だ。答えが「はい」なら、FDE は必須ではない可能性が高い。「いいえ」であり、その障壁が本当にエンジニアリング力の不足にある場合だけ、第2の関門へ進む理由がある。

第2の関門：今回この顧客のために作ったものを、次の顧客でも使えるか？

FDE は顧客ごとにカスタマイズできる。ただし、企業は繰り返し登場するニーズを共通モジュールにしなければならない。さもなければ、各エンジニアが独立したコード一式を抱えて、長期にわたり1社の顧客に張り付くことになり、チームはすぐに受託開発に変わってしまう。

次の4つのサインを直接確認できる。

• 新しい顧客向けソリューションの大部分を、既存のデータモデル、コンポーネント、ワークフローで組み立てられるか？
• 2社の顧客が似た機能を必要としたとき、共通部分をすべての顧客が使えるプラットフォーム機能にしているか？
• 特定の顧客だけのルールを共通モジュールから切り離し、1社の特殊な要求が他の顧客に影響しないようにできているか？
• 顧客が増えるほど、次の顧客への提供が速くなっているか？ それとも毎回ゼロから始めているか？

例えば、3社の顧客がいずれも在庫アラートを必要としているとする。健全な方法は、在庫判定、通知、承認をプラットフォームモジュールにし、各顧客が自社の安全在庫水準と承認者だけを設定する方法だ。3社それぞれに独立したコードがあり、それを作ったエンジニアだけが保守できるなら、第2の関門は通過していない。

「プラットフォーム側で60%を事前に用意し、顧客ごとに40%をカスタマイズする」というのは1つの例であり、すべての企業に共通する合格基準ではない。本当に見るべきなのは、1社の顧客向け開発を終えるたびに、次の顧客がそのまま再利用できる能力がプラットフォームに増えているかどうかだ。

2つの関門をともに通過してから、チームはより具体的な問題を決めればよい。1人のエンジニアが同時に何社を担当するのか、1社の顧客に2人を共同担当させるのか、繰り返し登場するどのニーズを製品チームが正式にプラットフォームに取り込むのか、といった問題だ。どちらかの関門を通過していないのに FDE を採用すると、製品や顧客選びの問題を、より高額なエンジニアリング保守の問題に変えるだけになる。