Q&A：プラットフォームの境界と製品フィードバックループ

この質問の中心

この質疑応答では、顧客ごとの開発と、全顧客が使えるプラットフォームの開発をどこで分けるかが話題になります。FDE（Forward-Deployed Engineering）は顧客の近くで仕事をします。しかし、顧客の要望をすべてコア製品に入れるわけでも、すべてを顧客専用のまま残すわけでもありません。

話し手の判断ルール

話し手は、次のような境界を示します。

• 一社だけに固有のものは、その顧客のための仕事として残します。
• 他の顧客にも使えそうなものは、長期的にはプラットフォーム側で汎用化します。

ここでいう「汎用化」とは、特定の顧客のためだけに作った機能を、他の顧客も利用できる共有機能や共有プリミティブ（再利用できる基本部品）に作り直すことです。この判断は、単に顧客の要求を受け入れるかどうかではありません。将来も同じ仕組みを使えるか、という観点で実装の置き場所を決めます。

例（説明用）

ある顧客だけが必要とする特殊な処理なら、FDE側でその顧客向けに実装することがあります。一方、同じ種類の処理が複数の顧客で必要になれば、共有プリミティブや製品機能にできるかを検討します。これは説明のための例であり、話し手が特定の処理や移行条件を挙げたわけではありません。

なぜ境界が必要なのか

同じコードや仕組みを顧客ごとに何度も作ると、重複が増えます。その結果、保守する対象が増え、FDEの仕事が開発会社（dev shop）のようになりやすくなります。反対に、繰り返し使える能力をプラットフォームにまとめれば、一度の改善を複数の顧客に生かせます。つまり、汎用化には重複を減らし、技術的なレバレッジを高める効果があります。

ただし、顧客固有の仕事をすべて共有プラットフォームへ移すべきだ、という意味ではありません。固有性が高いものまで無理に製品化すると、その顧客には不要な複雑さを持ち込む可能性があります。話し手は「一般化できるものは長期的に一般化する」と述べていますが、いつ移すかを決める基準、担当者、期限は示していません。

FDEは納品だけでなく、製品を見つける役割も持つ

この考え方では、FDEの顧客対応は単なる納品作業ではありません。顧客の現場で何を作る必要があるかを調べることで、今のプラットフォームに足りない能力も見えてきます。顧客向けの仕事が、将来ほかの顧客にも役立つ製品やサービスを見つける「スカウティング（探索）」になります。

流れは次のように整理できます。

1. FDEが顧客の課題に合わせて、現在のプラットフォーム上で解決策を作ります。
2. その解決策の中から、一社だけに必要な部分と、他社にも必要になりそうな部分を見分けます。
3. 後者を長期的に共有プリミティブや製品へ発展させます。
4. より強くなったプラットフォームを使って、次の顧客に対応します。

この循環が、顧客への提供とプロダクト発見をつなぎます。FDEは顧客のために作るだけでなく、どの能力を製品として育てる価値があるかを学ぶ場所にもなります。

最初から豊富なプラットフォームは必要か

話し手によれば、FDEチームの初期には共有プリミティブが少なくても問題ありません。顧客案件を進めながら、必要な能力を見つけてプラットフォームを広げていく道があります。したがって、最初から完成した巨大な基盤がなければFDEを始められない、という説明ではありません。

一方で、顧客ごとに作ったものを永久に個別管理すれば、前の章で説明された保守負担につながります。少ない部品から始めることと、共有できるものを長期的に共有側へ戻すことは、両立します。

注意点と、この質疑応答の限界

この回答の直前にあった聴衆の質問は、記録上、完全には残っていません。そのため、プラットフォーム側と顧客側に分ける具体的な変更例は分かりません。また、話し手は「一般化できるものを長期的に一般化する」という方向を示しましたが、移行のしきい値や承認の仕組みまでは説明していません。

したがって、この章から読み取れるのは、固定された運用手順ではなく、固有性と再利用性を見て、顧客専用の実装と共有プラットフォームの境界を考えるという原則です。終盤は次の質問へ移る途中で時間を確認する場面になっており、そこから新しい製品方針を推測することはできません。

出典：Kevin Bai「Forward Deployed Engineering 101」該当箇所（16:12）