0:18 - 1:47

範囲、話者の背景、FDE入門の道筋

この章では、講演の範囲と、講演者がどのような立場から話しているかを確認します。その後で、forward-deployed engineering（FDE）という役割を仮に定義し、講演全体の流れを先に見ます。

講演者の背景

Kevin Baiは、Anthropicの応用AIチームでtechnical staffとして働いていると自己紹介します。また、以前はRipplingで最初のforward-deployed機能を作り、Palantirでも働いていたと説明します。つまり、FDEを顧客に近いソフトウェア開発の実務として経験してきた人です。

ここで大切なのは、経歴と証拠を分けて考えることです。RipplingやPalantirでの経験は、講演者がこのテーマを説明できる背景を示します。しかし、その会社名だけでFDEの有効性が証明されるわけではありません。講演では、この経験を出発点にして、役割の意味、事業上の理由、他の会社に当てはめるときの考え方を説明します。

FDEとは何か

この講演でいうFDEは、顧客の事業や現場の課題を理解し、共通の技術基盤であるプラットフォームを使って、顧客向けのソフトウェア解決策を作る、顧客接点のあるソフトウェアエンジニアの役割・機能です。顧客に「使い方を説明する」だけではありません。顧客の状況に合わせて、実際にアプリケーションや業務の流れを作るところまで関わります。

FDEは、普通のソフトウェアエンジニアと同じではありません。普通のエンジニアは、広い利用者に提供する製品そのものを作ることが中心です。一方、FDEは顧客の前に立ち、顧客固有の問題を理解しながら、製品やプラットフォームの上に解決策を作ります。

FDEは、コンサルタントとも完全には同じではありません。コンサルタントは助言や業務設計を中心にする場合があります。FDEには、顧客の業務理解に加えて、ソフトウェアを実装する力が求められます。また、単なる導入担当とも異なります。導入担当が設定や展開を支援するのに対し、FDEは技術的に深いプラットフォーム上で、顧客向けのソリューションを構築します。ただし、実際の組織では、これらの役割が一部重なることもあります。

例：同じ製品でも支援の形が違う場合

たとえば、開発者が自分で設定して使える開発ツールなら、製品を買った会社のエンジニアが導入と拡張を行えるかもしれません。この場合、製品チームや開発者向け支援が中心で、FDEは必要ない可能性があります。

反対に、会社の複数のデータをつなぎ、業務に合わせたアプリケーションを作るプラットフォームを、技術に詳しくない事業責任者が買う場合があります。この場合、買う人は価値を理解していても、自分で実装するための時間や専門性を持っていないかもしれません。FDEは、その理解と実装の間を埋めます。

これは講演全体を理解するための例です。FDEという名前が付いているかどうかよりも、顧客が必要とする技術的な作業を誰が担うのかを見ることが重要です。

この講演で使う中心概念

講演を読むときは、次の概念をつなげてください。

プラットフォーム：複数の顧客向け解決策を作るときに再利用できる、共通の技術基盤です。
成果（outcome）：データが整理されたこと自体ではなく、売上の向上や業務の改善など、顧客の事業に起きる結果です。
企業の買い手（enterprise buyer）：大きな組織で、製品を購入する意思決定者です。実際に使う人や実装するエンジニアと同じとは限りません。
共有プリミティブ（shared primitives）：解決策を組み立てるための再利用可能な基本部品です。毎回すべてをゼロから作らないために使います。
市場開拓・販売活動（go-to-market、GTM）：製品を誰に、どのように届け、販売し、顧客の成果につなげるかという方法です。

講演者の説明では、FDEは「人を顧客の近くに置くこと」だけではありません。プラットフォームと共有部品を使って顧客固有の解決策を作り、その解決策を通じて事業上の成果を届けることが中心です。このため、FDEは人員配置の話であると同時に、製品設計とGTMの話でもあります。

講演全体の道筋

Kevinは、この講演をFDEの歴史と実践的な入門として紹介します。話は次の順番で進みます。

役割の意味を確認します。FDEは何をするエンジニアなのかを見ます。
Palantirのモデルを見ます。Foundryというプラットフォームと、顧客の成果を届ける方法が扱われます。
PalantirがこのGTMを必要とした理由を考えます。どのような製品と買い手の組み合わせでFDEが必要になるのかが中心です。
他の組織への応用可能性を考えます。FDEを導入したいという気持ちだけでなく、本当に必要か、支えられるプラットフォームがあるかを検討します。
AI時代の意味を考えます。AIによってカスタマイズ可能なソフトウェアが増えると、顧客が自力で理解し、実装することが難しくなる可能性があります。これは講演者自身の仮説として提示されます。
聴衆からの質問に答えます。共有プリミティブの細かさ、複数のFDEの協力、顧客固有の機能を共通プラットフォームへ戻す境界などが話題になります。

したがって、後の章では、単に「FDEは顧客のところでコードを書く仕事だ」とは考えません。まず製品の技術的な複雑さと買い手の技術力の関係を見ます。次に、顧客の成果を届けるためのサービスと、再利用可能なプラットフォームをどう組み合わせるかを見ます。最後に、その組み合わせが企業にとって必要かどうかを判断します。

この章での注意点

自動文字起こしでは、FDEがFTEのように聞こえる箇所があります。また、RipplingやPalantirの表記にも揺れがあります。この教材では、講演の題名と文脈に合わせてFDE、Rippling、Palantirという表記を使います。異なる表記が出ても、別の役割や別の会社を指しているとは限りません。

この章の要点は、FDEを流行の職種名として覚えることではありません。顧客に近いソフトウェアエンジニアが、技術基盤を使って顧客の成果を実現するモデルとして理解することです。次章からは、そのモデルを支えるFoundryと、データから業務上の成果へ進む流れを詳しく見ていきます。