この章では、フォワード・デプロイド・エンジニアリング（FDE）を自社に導入するべきかを判断する方法を扱います。話者は、FDEが流行しているから導入するのではなく、二つの条件を順番に確認するべきだと説明します。第一に、FDEが本当に必要な販売・提供方法なのか。第二に、FDEを持続的に運用できるプラットフォームがあるのか、またはそれに投資する意思があるのか、という条件です。
This chapter explains how to decide whether to adopt forward-deployed engineering (FDE) in your organization. The speaker says not to adopt FDE simply because it is fashionable, but to check two conditions in order. First, is FDE really the necessary way to sell and deliver the product? Second, does the organization have a platform that can support FDE over time, or is it willing to invest in one?
まず「本当に必要か」を確認する
First, check whether you really need it
話者の説明：特別な販売・提供方法が必要な組み合わせ
The speaker's explanation: a combination that needs a special way to sell and deliver
The first question can be restated as follows.
自社は、技術的に複雑なものを、技術に詳しくない買い手に販売していますか。
Does your organization sell something technically complex to buyers who are not technically knowledgeable?
ここでいう買い手（buyer）は契約や予算を決める人です。実際に製品を使う利用者（user）とは別の場合があります。たとえば、業務部門の責任者が購入を決めても、導入後に技術的な設定やアプリケーション開発が必要になることがあります。
Here, the buyer is the person who decides the contract or budget. The buyer may be different from the user who actually uses the product. For example, a business-unit leader may decide to purchase it, but technical configuration or application development may still be needed after adoption.
この組み合わせでは、買い手が価値を認めても、顧客だけで製品を理解し、設定し、実際に使える解決策を作ることが難しい場合があります。FDEは、その間を埋めます。顧客と直接話すソフトウェアエンジニアが顧客の業務を理解し、製品やプラットフォームの上に顧客向けの解決策を作ります。
With this combination, even if the buyer recognizes the value, the customer may find it difficult to understand the product, configure it, and build a solution that can actually be used without help. FDE fills this gap. A software engineer who speaks directly with the customer understands the customer's business and builds a customer-specific solution on top of the product or platform.
逆に、製品が技術的に複雑でも、買い手と利用者が十分に技術に詳しければ、FDEは必要ないかもしれません。また、利用者が自分で設定できる製品でも、製品の上で大きなアプリケーションを作る必要がなければ、FDEとは別の方法が合う可能性があります。したがって、「複雑な製品を売っている」だけでは、FDEを導入する理由になりません。
Conversely, even if the product is technically complex, FDE may not be necessary when the buyer and users are sufficiently technical. Also, a configurable product may be better served by another approach if users can configure it themselves and do not need to build a large application on top of it. Therefore, selling a complex product alone is not a reason to adopt FDE.
補足：FDEは流行ではなく、問題への対応です
Supplement: FDE responds to a problem, not to fashion
FDEの役割が話題になっていることや、エンジニアが顧客案件から売上を生み出せることだけを理由に、チームを作るべきではありません。先に、顧客が自力で価値を実現しにくい理由があるかを調べます。
A company should not create an FDE team merely because the role is attracting attention or because engineers can generate revenue through customer projects. It should first investigate whether customers have a reason they struggle to realize value on their own.
この理由がなければ、開発者向けエンゲージメント（developer engagement）や、通常の営業主導型SaaS（sales-led SaaS）のほうが適しているかもしれません。開発者向けエンゲージメントは、開発者に製品を知ってもらい、試し、使い続けてもらうための活動です。営業主導型SaaSは、営業活動を中心に企業へ標準的なソフトウェアを販売する方法です。どちらも有効な選択肢ですが、顧客ごとにエンジニアが解決策を構築するFDEとは同じものではありません。
Without that reason, developer engagement or a conventional sales-led SaaS motion may be a better fit. Developer engagement consists of activities that help developers learn about a product, try it, and continue using it. A sales-led SaaS motion sells standard software to companies through a sales-centered process. Both are valid choices, but neither is the same as FDE, where engineers build solutions for individual customers.
次に「プラットフォームがあるか」を確認する
Next, check whether you have a platform
話者の説明：顧客向けエンジニアだけでは足りない
The speaker's explanation: customer-facing engineers alone are not enough
The second question is as follows.
エンジニアが共通のプラットフォームの上で仕事をできますか。まだなければ、それに投資する意思がありますか。
Can your engineers work on top of a shared platform? If you do not have one yet, are you willing to invest in it?
ここでいうプラットフォームは、複数の顧客向け解決策の土台になる共通の技術基盤です。その中には、共有プリミティブ（shared primitives）があります。プリミティブとは、何度も使える基本的な部品のことです。FDEは、顧客ごとにすべてをゼロから書くのではなく、こうした部品を組み合わせて、アプリケーションや業務ワークフローを作ります。
Here, a platform is a common technical foundation for solutions for multiple customers. It includes shared primitives. A primitive is a basic component that can be used repeatedly. Instead of writing everything from scratch for each customer, FDEs combine these components to create applications and business workflows.
この土台があると、顧客固有の部分に時間を使えます。**例（筆者）**として、複数の顧客に共通する部分を毎回作り直すのではなく、既存の部品を利用し、その顧客の業務に必要な部分を調整する方法を考えられます。これは、FDEが顧客の成果を目指しながら、開発会社全体を受託開発会社（dev shop）にしないための条件です。
With this foundation, engineers can spend time on customer-specific parts. Example (author's organization): Instead of rebuilding the parts common to several customers every time, they can use existing components and adjust the parts required for that customer's work. This is what allows FDE to pursue customer outcomes without turning the entire company into a dev shop.
補足：共有部品がない場合の負担
Supplement: the burden when shared components are missing
エンジニアが顧客ごとに別のコードをゼロから作ると、案件が増えるほど問題も増えます。似た機能を何度も作ることになります。コードの修正や保守の方法も顧客ごとに異なります。リポジトリが増え、どの変更がどの顧客に影響するか分かりにくくなります。結果として、保守（maintenance）の負担が大きくなり、特定のエンジニアだけが顧客の仕組みを理解している状態にもなります。
When engineers build separate code from scratch for each customer, the problems grow as the number of projects grows. They repeatedly build similar features. The ways to modify and maintain the code also differ from customer to customer. Repositories multiply, and it becomes hard to tell which changes affect which customers. As a result, the maintenance burden grows, and only particular engineers may understand a customer's system.
話者は、このような負担が大きすぎるため、共有プリミティブの上で作ることが重要だと述べています。ただし、プラットフォームがあっても仕事がなくなるわけではありません。どの部品を使うかを考え、顧客の業務に合わせて組み立てる作業は残ります。プラットフォームは、顧客ごとの作業をなくすものではなく、同じ基礎を繰り返し使えるようにするものです。
The speaker says that this burden becomes too great, which is why building on shared primitives matters. However, a platform does not make the work disappear. Engineers still need to decide which components to use and assemble them for the customer's business. A platform does not eliminate customer-specific work; it makes it possible to reuse the same foundation repeatedly.
また、話者は、最初から十分なプラットフォームが存在しなければ、構築や投資を先に行う必要があるとしています。FDEチームを先に増やし、共通の技術基盤を後回しにすれば、顧客案件の数に応じて保守負担も増えます。話者は、必要な機能の最低条件や、許容できる保守量を数値では示していません。そのため、「どの程度のプラットフォームなら十分か」という基準は、この説明だけでは決められません。
The speaker also says that if a sufficient platform does not exist at the beginning, the company needs to build it or invest in it first. If it expands the FDE team first and postpones the shared technical foundation, the maintenance burden will grow with the number of customer projects. The speaker does not give a numerical minimum for the necessary capabilities or for an acceptable amount of maintenance. Therefore, this explanation alone cannot determine what level of platform is sufficient.
二つの条件を一緒に使う
Use the two conditions together
このチェックは、どちらか一方だけで判断するものではありません。
This checklist should not be decided using only one of the two conditions.
- 特別な販売・提供方法が必要かを確認します。技術的に複雑な製品を、技術に詳しくない買い手へ売り、顧客側に理解や実装の不足があるかを見ます。
- 共有プラットフォームがあるかを確認します。顧客向けエンジニアが、再利用できる部品の上で解決策を作れるかを見ます。なければ、構築への投資が必要です。
- Check whether a special way to sell and deliver is needed. Ask whether the product is technically complex, whether it is sold to buyers who are not technically knowledgeable, and whether the customer lacks understanding or implementation ability.
- Check whether a shared platform exists. Ask whether customer-facing engineers can build solutions on reusable components. If not, investment in building the foundation is needed.
第一の条件は、FDEを必要とする顧客上の問題を示します。第二の条件は、その問題を大きな保守負担なしに解決する方法を示します。第一だけがあって第二がなければ、FDEの仕事は顧客ごとのゼロからの開発に近づきます。第二だけがあって第一がなければ、プラットフォームはあっても、FDEという特別な提供方法を選ぶ理由が弱くなります。
The first condition identifies the customer problem that creates a need for FDE. The second identifies a way to solve that problem without an excessive maintenance burden. If the first condition exists without the second, FDE work approaches from-scratch development for each customer. If the second exists without the first, there is a platform, but less reason to choose FDE as a special delivery model.
例（筆者による整理）
Examples (organized by the author)
- 複雑なプラットフォームはあるが、顧客も技術に詳しい場合：開発者向けエンゲージメントや通常の営業主導型SaaSが合う可能性があります。
- 複雑な製品を技術に詳しくない顧客へ売るが、共有基盤がない場合：FDEの採用を急ぐより、まずプラットフォームと共有プリミティブへの投資を検討します。
- 複雑な製品を技術に詳しくない顧客へ売り、共有基盤の上で顧客向けに構築できる場合：FDEを検討する条件がそろいます。ただし、これは導入を自動的に決める規則ではありません。
- There is a complex platform, but the customer is also technically knowledgeable: Developer engagement or a conventional sales-led SaaS motion may fit.
- A complex product is sold to a customer who is not technically knowledgeable, but there is no shared foundation: Consider investing in the platform and shared primitives before rushing to hire FDEs.
- A complex product is sold to a customer who is not technically knowledgeable, and customer-facing work can be built on a shared foundation: The conditions for considering FDE are present. However, this is not a rule that automatically decides adoption.
この三つの例は、話者の二段階の考え方を整理したものです。特定の会社に対する診断結果や、話者が示した数値基準ではありません。
These three examples organize the speaker's two-stage reasoning. They are not a diagnosis of any particular company or a numerical threshold supplied by the speaker.
FDEを導入する前に考えること
What to consider before adopting FDE
FDEは、営業、導入支援、ソフトウェア開発を単純に一つへまとめた名前ではありません。顧客の業務を理解し、技術的に複雑な製品を使って成果を出す必要があるときに、その仕事を顧客の近くで担う役割です。そして、会社がこの役割を繰り返し提供するには、共通のプラットフォームが必要です。
FDE is not simply a name for combining sales, implementation support, and software development into one function. It is a role that works close to the customer when someone needs to understand the customer's business and use a technically complex product to produce an outcome. For a company to provide this role repeatedly, it needs a shared platform.
したがって、導入前には次の順で考えるとよいでしょう。
Therefore, it is useful to think through the following questions in order before adopting it.
- 顧客は、製品を買っただけで価値を実現できますか。
- できない場合、その不足は、技術的な複雑さと顧客側の実装能力の差から生じていますか。
- 顧客向けエンジニアが再利用できるプラットフォームとプリミティブはありますか。
- まだない場合、FDEの拡大より先に、その基盤へ投資できますか。
- Can the customer realize value simply by buying the product?
- If not, does the gap come from the product's technical complexity and a difference in the customer's implementation ability?
- Do you have a platform and primitives that customer-facing engineers can reuse?
- If you do not, can you invest in that foundation before expanding FDE?
話者の結論は、FDEを広く採用せよというものではありません。特別な顧客・製品の組み合わせがあり、さらにプラットフォームによって仕事を再利用できる場合に、このモデルを候補にするべきだという提案です。
The speaker's conclusion is not that everyone should adopt FDE. It is a proposal to consider this model when there is a special customer-and-product combination and a platform makes the work reusable.