FDE と Platform Engineering の関係：顧客ロックインを成立させる Platform as a Product¶

顧客向けの開発を担う FDE（Forward Deployed Engineer）が社内プラットフォームを使い続けるには、どんな設計と体制が必要でしょうか。FDE がプラットフォームを迂回する理由を整理し、顧客の知見を機能や運用へ蓄積して、顧客ロックインにつなげる条件を考えます。

はじめに¶

2025 年以降、FDE の求人募集や、FDE に言及する記事や投稿を目にする機会が増えました。

私が確認した求人では、FDE に求められる仕事は単なる顧客向けの受託開発ではありません。顧客ごとに必要な機能を実装し、そこで得た知見や機能を社内プラットフォームへ取り込む役割も含まれています。最終的には、顧客が自社のプラットフォームへ依存する状態まで期待されているように見えます。

ここでいうロックインとは、契約によって顧客を縛ることではありません。顧客の業務に必要なデータや機能、運用が自社プラットフォームへ蓄積された結果、別の基盤へ移るよりも使い続ける方が合理的になっている状態を指します。

私は FDE という職種名で働いた経験はありませんが、顧客と継続的に会話しながら、特定企業向けの機能を開発した経験があります。加えて、Platform Engineer として社内プラットフォームの構築にも携わりました。

その経験から考えると、FDE と Platform Engineering は切り離せません。企業が FDE を通じて顧客の知見を獲得し、プラットフォームの競争力や顧客ロックインへつなげるには、FDE だけを強化しても成立しません。実際に顧客課題を解決できるプラットフォームと、フィードバックを受け取る体制が必要です。

FDE の成果はプラットフォームに左右される¶

FDE は顧客の業務フローやドメイン知識を理解し、実際に動くシステムへ落とし込みます。最初から全ての要件が明らかになっているとは限らず、実際に動くコードを顧客へ見せ、フィードバックを受けながら修正する探索のサイクルが必要です。

このサイクルを円滑にするため、社内プラットフォームには、たとえば次のような機能が求められます。

• API を公開するための共通基盤
• 認証認可やテナント管理
• 顧客データを安全に扱うデータ基盤
• 顧客固有のコードを隔離して実行できるアプリケーション基盤
• ログ収集、メトリクス監視、アラート
• FDE が利用するための開発・運用支援

これらが十分に整っていれば、FDE は認証や監視を顧客ごとに作り直す必要がありません。顧客固有のドメインロジックへ集中できます。反対に、プラットフォームを使うための準備や調整だけで時間を消費するなら、支援基盤ではなくプロジェクト進行上の制約になります。

プラットフォームの遅さが FDE の迂回を生む¶

FDE の目的は、プラットフォーム自体を普及させることだけではありません。顧客とのプロジェクトを成立させ、実際に課題を解決することも求められます。FDE にとって社内プラットフォームは、業務を通じて改善していく対象であると同時に、顧客の課題を解決するための手段の 1 つでもあります。

顧客固有の課題を探索している段階では、実装や検証に時間がかかるほどプロジェクト進行上のリスクが増えます。顧客へ成果を見せられない期間が長くなるほど、進捗や解決時期について期待値を合わせるのが難しくなるためです。

たとえば、顧客から「自社の IdP と連携し、特定部署だけが利用できるようにしたい」という要求を受けたとします。社内プラットフォームが必要な認証方式に対応しており、設定だけで使えるなら、FDE は顧客固有の業務ロジックへ集中できます。

一方で、認証基盤を使うためにプラットフォームチームとの調整が必要で、利用可能になるまで長い時間がかかるとします。その間も顧客との定例や進捗共有は続きます。顧客側にとって重要なのは社内事情ではなく、期待していた成果がいつ出るのかです。

プラットフォームを利用すれば、別の顧客へ機能を再利用したり、将来の開発コストを下げたりできます。ただし、導入や社内調整に時間を使い続けた結果、顧客とのコミュニケーションや期待値調整が難しくなり、プロジェクトそのものが止まってしまえば本末転倒です。

このような状況では、FDE が社内プラットフォームを迂回して独自に実装し、まずプロジェクトを前へ進めようとするのは合理的な判断です。

待つコストは顧客との関係にも現れる¶

FDE にとっての判断は、「速度か利益か」という単純な二者択一ではありません。プラットフォームを使えば中長期的な利益を得られる一方で、利用できるまでに時間がかかればプロジェクト上のリスクが増えます。FDE はこのトレードオフを踏まえて判断しなければなりません。

成果の見えない期間が長くなると、顧客が期待していた内容と実際の進捗との差も広がります。期待値を調整するためのコミュニケーションも増えていきます。この状態が続けば、技術的には解決可能な課題であっても、顧客との信頼関係やプロジェクトの継続条件が先に悪化する可能性があります。

そのため、プラットフォームから得られる利益が、導入や調整に伴うコミュニケーションコストとプロジェクト進行上のリスクを上回る状態を作る必要があります。 そうなって初めて、FDE はプラットフォームを選びます。

LLM はプラットフォームの迂回を容易にした¶

LLM によるコード生成を利用できる環境では、必要なコードを独自に実装する選択肢を取りやすくなります。認証やデータアクセス、API などを実装するコストが下がれば、プラットフォームを使うための調査や調整にかかる時間が相対的に目立ちます。

その結果、「必要な部分だけ独自に実装して、まず顧客との検証を進める」という判断が成立しやすくなります。私自身も、プラットフォーム側の調整を待つことで顧客との検証が止まる場面を経験しました。そのような状況では、プラットフォームへ依存しないコードを書いてプロジェクトを進める方が適切な場合もあります。

これは FDE 個人の問題ではありません。プラットフォームから得られる利益と、利用を待つことで生じるリスクを比較した結果です。LLM によって「プラットフォームを使わない」という選択肢の実行コストが下がるほど、プラットフォーム側には利用する理由を明確に提供することが求められます。

自前化が進むとプラットフォームは成長機会を失う¶

FDE が個別にコードを書くこと自体は問題ではありません。探索段階では、個別実装の方が適切な場合もあります。

問題は、そこで得た知見がプラットフォームへ戻らないことです。顧客 A で必要になった機能を FDE が独自実装し、顧客 B でも別の FDE が似た機能を再実装すると、組織内には同じ問題を解くコードが増えていきます。一方、FDE が必要とした機能をプラットフォームへ取り込めれば、次の顧客では共通機能として利用できます。

どちらの場合も、出発点は FDE による顧客固有の課題解決です。違いは、実装から得た知見を次の案件でも使える形にするかどうかです。

この差を繰り返すと、前者ではプラットフォームを使う理由が増えていきます。後者では、反対に使わない理由が増えます。

企業が FDE を通じて得た顧客固有の知見を、自社プラットフォームの競争力へ変換したいのであれば、このフィードバックループを成立させる必要があります。FDE を採用して顧客の知見へアクセスできても、プロジェクト固有のコードとして残るだけでは組織の資産になりません。

プラットフォームへ知見が蓄積されなければ、顧客が使い続ける理由も増えません。そのため、顧客ロックインという狙いも実現しにくくなります。

Platform as a Product が必要になる¶

FDE に社内プラットフォームを使ってもらうために必要なのが、Platform as a Productの考え方です。

重要なのは、FDE が利用することで事業上の利益を得られるプロダクトになっているかどうかです。

プラットフォームチームにとって、FDE は単なる利用者ではなく社内の顧客です。FDE は顧客から直接要求を受けながらプロジェクトを進めるので、プラットフォーム側の都合で長くは待てません。必要な機能への対応が遅れる間も、顧客との進捗共有や期待値調整は続きます。

Platform as a Product で重要なのは、利用を強制することではなく、FDE に対して導入や運用のコストに見合う価値を提供することです。目指すべきなのは、「使わなければならないプラットフォーム」ではなく、利用した方がプロジェクト全体の利益を得やすいプラットフォームです。

FDE にとってプラットフォームを使うのが一番よい選択になれば、FDE は日々の利用の中で改善点に気づき、それをフィードバックとして返しやすくなります。

ロックインを狙うならプラットフォームへの投資が必要になる¶

ただし、FDE が自発的に利用するプラットフォームは、FDE だけでは作れません。企業が顧客固有の知見を自社プラットフォームへ取り込み、FDE を通じて顧客ロックインまで狙うのであれば、プラットフォームへの投資が欠かせません。

FDE だけを増やしても、受け皿となるプラットフォームが弱ければ、顧客ごとの独自実装が増えるだけです。必要なのはプラットフォームのコードだけではありません。FDE の要望を受け取り、事業上の優先順位を判断し、共通機能として提供できる開発体制も必要です。

プラットフォームへの投資、FDE への支援、フィードバックを受け取る体制は別々の問題ではありません。この 3 つをまとめて設計すれば、FDE から得た知見を企業の資産に変えられます。

プラットフォームは個人の知見を組織へ残す仕組みでもある¶

FDE には幅広い能力が求められます。技術力に加えて、顧客とのコミュニケーションや要件整理まで担うためです。こうした役割を高い水準で担える人材を採用できれば、個々のプロジェクトを進めるうえでは大きな力になります。

一方で、難しい判断や問題解決を特定の FDE に任せ続けると、成果も知見もその個人へ集中します。その人がいる間は問題なく進んでも、異動や退職の後に同じ判断や実装を再現できるとは限りません。

もちろん、すべての能力を社内で育成できるわけではなく、高い専門性を持つ人材を外部から採用することも必要です。ただし、同じ水準の人材を継続して採用できることを前提に組織を作るのは難しいでしょう。個人が得た知見を組織へ残す仕組みも同時に必要になります。

ここでもプラットフォームが重要になります。FDE が顧客とのプロジェクトで得た知見を、共通機能や標準的な実装としてプラットフォームへ取り込めば、次のプロジェクトでは別の FDE も利用できます。個人が一度解決した問題を、組織として再利用できるようになります。

この意味で、プラットフォームは、機能や非機能要件をまとめただけの基盤ではありません。個人の能力に依存していた成果や知見を、組織が再利用できる資産へ変える仕組みでもあります。

まとめ¶

FDE と Platform Engineering の関係で重要なのは、FDE に共通基盤を使わせることではありません。顧客とのプロジェクトを成立させながら、現場で得た知見をプラットフォームへ還元できるようにすることです。

FDE がプラットフォームを迂回し始めたなら、FDE 個人の問題として扱っても解決しません。利用による利益が、導入や調整のコストを上回っているかを見直す必要があります。反対に、個別実装だけを続ければ、顧客から得た知見は組織の資産になりません。

顧客の知見を自社プラットフォームへ蓄積し、最終的に顧客ロックインまで狙うのであれば、FDE の能力だけに依存できません。必要なのは、FDE が事業上の合理性から選び続けられるプラットフォームです。Platform as a Product は、そうしたプラットフォームを作るための考え方です。