FDEとは何か、そしてなぜ今もてはやされるのか

フォワードデプロイド・エンジニアリング（FDE）とは、エンジニアを顧客先に送り込み、実際の業務フローをコードに落とし込み、顧客の本物のデータ上でデモを動かす体制を指します。数週間単位でワークフローを実装できるスピードが売りです。

ゴア氏によれば、FDEの売り込みは最初の10分間はどのベンダーも同じことを言います。差が出るのはその後の数か月であり、そして多くのベンダーは直接尋ねられない限りその部分を語りません。投資家はFDEの人員数を成長シグナルとして読み、買い手はスピードの約束として読みますが、どちらもその作業が製品の優位性に変わっているかどうかを示してはいない、というのが同氏の指摘です。

「データにアクセスできること」と「事業を理解していること」は別物

この記事の核心は、多くのエンタープライズ業務におけるボトルネックはモデル選定ではなく、企業が自社について何を言語化できているか、にあるという主張です。業務ルール、例外処理、ワークフローのロジック、定義——これらは10年単位の運用の中で積み上がってきたものです。

具体例として挙げられているのが、大手通信事業者の導入案件です。当初定義された「購買意欲の高い顧客」の定義は、実際の基幹システムに触れた瞬間に崩れました。モデルが出したシグナルが、解約引き止め部隊（セーブデスク）が現場で使っている実際の判断基準と食い違ったのです。その基準は、どのオファーが、どの契約年数帯の顧客に、どの地域で効いたかという長年の蓄積に基づくものでした。そのロジックを記述したスキーマはどこにも存在せず、10年その仕事をしてきた人々の判断の中にだけありました。

エンジニアが引き止めチームの隣に座り、その知識を引き出してコード化する。この工程を経て初めて、インテリジェンス層は「スコアを出す」だけでなく「アクションを起動する」信頼を得ました。そしてロジックが一度エンコードされた後は、新規獲得や解約防止の新しいユースケースが数か月ではなく数日で実行に移せるようになったといいます。各チームが連携を作り直すのではなく、共通の土台に判断を追加していく形に変わったからです。

砂場か、泥沼か

ゴア氏は、FDEの実態を見分ける比喩として「砂場（sandbox）」と「泥（mud）」を対置します。砂場では、汎用エンジンを持ったFDEが厄介な環境に入り、エンジンに足りない部品を見つけ、それを取り付け、学びを本体に還流させる。その部品は次回から製品として出荷されます。泥では、エンジン自体が存在せず、顧客ごとに欠けた機能を手作業で作ります。

多くの企業はその中間にいます。よくあるケースには再利用可能なプレイブックとコネクタがあり、残りは個別判断で埋める。外から見ると、どのパターンも同じに見えます。見分けるための唯一の手がかりは、エンジニアが学んだことがその後どこへ行くか、です。

学習ループの最後の一段で、多くの企業がつまずく

戦略的なFDEの学習ループは、現場で例外を観測し、再利用可能な成果物としてコード化し、評価（eval）とセキュリティレビューで検証し、製品としてリリースし、そして次の導入が実際に楽になったかを計測する——という流れです。ゴア氏は、大半の企業が失敗するのは最後の一段だと述べます。

現場の成果物は、セマンティックマッピング、ポリシーモジュール、ワークフローテンプレート、コネクタ、あるいは将来の導入で判断を守る評価基準になり得ます。FDEとは「まず人として届けられるコンテキスト層」であり、その後それを製品として翻訳・提供する存在だ、という定義です。

ただし現場の発見のすべてを製品に入れるべきではありません。顧客固有で機密性が高いもの、一時的なもの、一般化するには特殊すぎるものもあります。FDEという言葉の下には、（1）全顧客に効いて複利で積み上がる製品インテリジェンス、（2）一社では再利用できるが広く出荷はできない設定可能な顧客ロジック、（3)単発のサービス業務——という三種類の作業が混在しています。失敗とは、どのバケツに入る作業なのかを分類しないこと、そして複利化できるはずの学びを取りこぼすことだ、と整理されています。

追うべき指標と、商談で聞くべき三つの質問

提示されている指標は、稼働ワークフローあたりのエンジニア数、1導入あたりのエンジニア工数、業種別のバリュー実現までの時間、実装作業のうち再構築ではなく再利用された割合の4つ。そして見落とされがちな5つ目が「プロダクト化のラグ」——現場での発見から、テスト済みの機能として次の顧客が使えるようになるまでの時間です。FDEの絶対人数は増えてもよいが、提供価値1単位あたりの人的翻訳量は減っていくべきだ、というのが判定軸です。指標が一つも改善していなければ、人員グラフがどう伸びていようと、その組織は学習せずに納品しているだけということになります。

商談・更新交渉で使える三つの質問も示されています。第一に、FDEはどう価格設定されているか。専門サービスとして別建てなら透明性の表れかもしれず、バンドルされているなら稼働率で回収するロスリーダーかもしれません。契約・更新・利益率が、再現可能なプロダクト化を示すのか個別受託を示すのかを見ます。第二に、現場の学びはどこへ行くのか。FDEから製品への引き継ぎを誰が所有し、どんな成果物が生まれ、どれだけ速くサポート付きの機能になるのか。第三に、直近のリピート案件で何が速くなったのか。業種を特定し、エンジニア工数の削減、価値実現までの週数、カスタム連携の本数、再利用率といった具体的な差分を求めます。「学びがあった」「プレイブックがある」という一般論では足りない、と釘を刺しています。

※本稿はZeta提供のスポンサード記事に基づきます。VentureBeatのスポンサード記事は、掲載費を支払った企業、または同メディアと取引関係にある企業が制作したコンテンツであり、常に明示されます。

💼 事業会社視点：これは自社にどう効くか

日本企業のAI導入で最も効くのは、この記事が示す「三つの質問」を調達側の標準フォーマットにすることです。国内のAI導入案件は、SIerや受託開発会社が伴走支援・PoC支援の名目で人を張る形が主流で、構造はFDEそのものです。しかし契約が人月である以上、学びを製品化するインセンティブは供給側にありません。役員が見るべきは提案書の体制図ではなく、更新時に「前回の同業種案件と比べて工数が何割減ったか」を数字で出せるかどうかです。出せないベンダーは、あなたの会社で学んだことを別の顧客に転用しているだけの可能性があります。

SaaS・自社プロダクト側にとっては逆の示唆です。エンタープライズ攻略でカスタマーサクセスに人を投下する際、現場で判明した例外処理をチケットで閉じるか、コネクタ・テンプレート・評価基準として製品に還元するかで、3年後の粗利率が決まります。「プロダクト化のラグ」を経営KPIに入れ、誰が引き継ぎを所有するかを明文化してください。

EC・通信・金融など解約防止や与信の現場を持つ事業会社は、通信事業者の事例が示す通り、勝負どころが自社の暗黙知の言語化にあります。ベテランの判断基準がどこにも文書化されていないなら、モデルを選ぶ前にそこを掘る工数を予算化するのが先です。