9:20 - 11:30
導入のチェックリスト：特別な販売・提供方法とプラットフォーム
この章では、フォワード・デプロイド・エンジニアリング（FDE）を自社に導入するべきかを判断する方法を扱います。話者は、FDEが流行しているから導入するのではなく、二つの条件を順番に確認するべきだと説明します。第一に、FDEが本当に必要な販売・提供方法なのか。第二に、FDEを持続的に運用できるプラットフォームがあるのか、またはそれに投資する意思があるのか、という条件です。
まず「本当に必要か」を確認する
話者の説明：特別な販売・提供方法が必要な組み合わせ
最初の質問は、次のように言い換えられます。
自社は、技術的に複雑なものを、技術に詳しくない買い手に販売していますか。
ここでいう買い手（buyer）は契約や予算を決める人です。実際に製品を使う利用者（user）とは別の場合があります。たとえば、業務部門の責任者が購入を決めても、導入後に技術的な設定やアプリケーション開発が必要になることがあります。
この組み合わせでは、買い手が価値を認めても、顧客だけで製品を理解し、設定し、実際に使える解決策を作ることが難しい場合があります。FDEは、その間を埋めます。顧客と直接話すソフトウェアエンジニアが顧客の業務を理解し、製品やプラットフォームの上に顧客向けの解決策を作ります。
逆に、製品が技術的に複雑でも、買い手と利用者が十分に技術に詳しければ、FDEは必要ないかもしれません。また、利用者が自分で設定できる製品でも、製品の上で大きなアプリケーションを作る必要がなければ、FDEとは別の方法が合う可能性があります。したがって、「複雑な製品を売っている」だけでは、FDEを導入する理由になりません。
補足：FDEは流行ではなく、問題への対応です
FDEの役割が話題になっていることや、エンジニアが顧客案件から売上を生み出せることだけを理由に、チームを作るべきではありません。先に、顧客が自力で価値を実現しにくい理由があるかを調べます。
この理由がなければ、開発者向けエンゲージメント（developer engagement）や、通常の営業主導型SaaS（sales-led SaaS）のほうが適しているかもしれません。開発者向けエンゲージメントは、開発者に製品を知ってもらい、試し、使い続けてもらうための活動です。営業主導型SaaSは、営業活動を中心に企業へ標準的なソフトウェアを販売する方法です。どちらも有効な選択肢ですが、顧客ごとにエンジニアが解決策を構築するFDEとは同じものではありません。
次に「プラットフォームがあるか」を確認する
話者の説明：顧客向けエンジニアだけでは足りない
二つ目の質問は、次のとおりです。
エンジニアが共通のプラットフォームの上で仕事をできますか。まだなければ、それに投資する意思がありますか。
ここでいうプラットフォームは、複数の顧客向け解決策の土台になる共通の技術基盤です。その中には、共有プリミティブ（shared primitives）があります。プリミティブとは、何度も使える基本的な部品のことです。FDEは、顧客ごとにすべてをゼロから書くのではなく、こうした部品を組み合わせて、アプリケーションや業務ワークフローを作ります。
この土台があると、顧客固有の部分に時間を使えます。**例（筆者）**として、複数の顧客に共通する部分を毎回作り直すのではなく、既存の部品を利用し、その顧客の業務に必要な部分を調整する方法を考えられます。これは、FDEが顧客の成果を目指しながら、開発会社全体を受託開発会社（dev shop）にしないための条件です。
補足：共有部品がない場合の負担
エンジニアが顧客ごとに別のコードをゼロから作ると、案件が増えるほど問題も増えます。似た機能を何度も作ることになります。コードの修正や保守の方法も顧客ごとに異なります。リポジトリが増え、どの変更がどの顧客に影響するか分かりにくくなります。結果として、保守（maintenance）の負担が大きくなり、特定のエンジニアだけが顧客の仕組みを理解している状態にもなります。
話者は、このような負担が大きすぎるため、共有プリミティブの上で作ることが重要だと述べています。ただし、プラットフォームがあっても仕事がなくなるわけではありません。どの部品を使うかを考え、顧客の業務に合わせて組み立てる作業は残ります。プラットフォームは、顧客ごとの作業をなくすものではなく、同じ基礎を繰り返し使えるようにするものです。
また、話者は、最初から十分なプラットフォームが存在しなければ、構築や投資を先に行う必要があるとしています。FDEチームを先に増やし、共通の技術基盤を後回しにすれば、顧客案件の数に応じて保守負担も増えます。話者は、必要な機能の最低条件や、許容できる保守量を数値では示していません。そのため、「どの程度のプラットフォームなら十分か」という基準は、この説明だけでは決められません。
二つの条件を一緒に使う
このチェックは、どちらか一方だけで判断するものではありません。
- 特別な販売・提供方法が必要かを確認します。技術的に複雑な製品を、技術に詳しくない買い手へ売り、顧客側に理解や実装の不足があるかを見ます。
- 共有プラットフォームがあるかを確認します。顧客向けエンジニアが、再利用できる部品の上で解決策を作れるかを見ます。なければ、構築への投資が必要です。
第一の条件は、FDEを必要とする顧客上の問題を示します。第二の条件は、その問題を大きな保守負担なしに解決する方法を示します。第一だけがあって第二がなければ、FDEの仕事は顧客ごとのゼロからの開発に近づきます。第二だけがあって第一がなければ、プラットフォームはあっても、FDEという特別な提供方法を選ぶ理由が弱くなります。
例（筆者による整理）
- 複雑なプラットフォームはあるが、顧客も技術に詳しい場合：開発者向けエンゲージメントや通常の営業主導型SaaSが合う可能性があります。
- 複雑な製品を技術に詳しくない顧客へ売るが、共有基盤がない場合：FDEの採用を急ぐより、まずプラットフォームと共有プリミティブへの投資を検討します。
- 複雑な製品を技術に詳しくない顧客へ売り、共有基盤の上で顧客向けに構築できる場合：FDEを検討する条件がそろいます。ただし、これは導入を自動的に決める規則ではありません。
この三つの例は、話者の二段階の考え方を整理したものです。特定の会社に対する診断結果や、話者が示した数値基準ではありません。
FDEを導入する前に考えること
FDEは、営業、導入支援、ソフトウェア開発を単純に一つへまとめた名前ではありません。顧客の業務を理解し、技術的に複雑な製品を使って成果を出す必要があるときに、その仕事を顧客の近くで担う役割です。そして、会社がこの役割を繰り返し提供するには、共通のプラットフォームが必要です。
したがって、導入前には次の順で考えるとよいでしょう。
- 顧客は、製品を買っただけで価値を実現できますか。
- できない場合、その不足は、技術的な複雑さと顧客側の実装能力の差から生じていますか。
- 顧客向けエンジニアが再利用できるプラットフォームとプリミティブはありますか。
- まだない場合、FDEの拡大より先に、その基盤へ投資できますか。
話者の結論は、FDEを広く採用せよというものではありません。特別な顧客・製品の組み合わせがあり、さらにプラットフォームによって仕事を再利用できる場合に、このモデルを候補にするべきだという提案です。