開発会社化せずにデザインパートナーシップを拡大する

デザインパートナーシップとは

スタートアップの初期には、会社も顧客も、製品の形をまだ完全には理解していないことがあります。この段階では、顧客と近い距離で協力しながら、顧客の仕事や問題を学びます。そして、その理解を使って、顧客に役立つ解決策を作ります。

このような関係を、ここではデザインパートナーシップと呼びます。これは、完成した製品を一方的に売る関係ではありません。顧客との協力を通して、何を作るべきかを発見する関係です。

補足：プロダクト・マーケット・フィットとの関係

プロダクト・マーケット・フィット（product-market fit）は、製品が特定の市場の重要な問題に合い、顧客に継続して選ばれる状態です。製品がこの状態に達する前は、顧客の現場を知らずに仕様を決めることが難しくなります。だから、初期の顧客と一緒に問題を理解し、解決策を作ることに意味があります。

例

たとえば、製造会社の在庫管理に使う新しいソフトウェアを作るとします。最初から一般的な機能を大量に作るのではなく、一社の担当者と仕事の流れを確認します。その会社が、どの情報をいつ確認し、どの判断に困っているかを学びます。そのうえで、実際の問題を解決する画面や処理を作ります。この例では、顧客との協力が製品理解と開発を同時に進めます。

企業向けに拡大するFDE

話者の説明では、フォワード・デプロイド・エンジニアリング（Forward-Deployed Engineering、FDE）は、このデザインパートナーシップを企業向けに拡大したものです。FDEは、顧客の状況を理解し、顧客に合う解決策を作ります。したがって、単に完成品を渡して終わる役割ではありません。

企業向けでは、顧客の組織や仕事の流れが大きく、課題も顧客ごとに異なることがあります。そのため、顧客の文脈を学ぶことと、実際にソフトウェアを作ることを近づけます。FDEは、この二つをつなぐ顧客向けのソフトウェアエンジニアです。

ただし、顧客ごとに別のソフトウェアを最初から作るだけでは、関係を拡大できません。そこで重要になるのが、共通のプラットフォームと**共有プリミティブ（shared primitives）**です。プリミティブとは、何度も使える技術的な基本部品です。話者は、この部品の具体的な技術構成やインターフェースまでは説明していません。ここで重要なのは、FDEが毎回すべてを作り直すのではなく、共通部品を組み合わせて顧客向けのものを作る点です。

開発会社との違い

FDEでも、顧客ごとの結果に合わせたカスタマイズは行います。しかし、基礎となる実装を顧客ごとに完全に作り直すわけではありません。共有プリミティブを組み合わせて、顧客向けのアプリケーションやワークフローを作ります。

この違いによって、FDEは顧客の個別の成果を支援しながら、共通の技術基盤を保てます。一方、開発会社（dev shop）は、顧客ごとに別のソフトウェアを受託して作る形になりやすいものです。個別開発そのものが悪いのではありません。問題は、すべての顧客のために、同じような基礎機能まで毎回作り直すことです。

例：同じ部品を組み合わせる

補足として、共有プリミティブを積み木の部品にたとえます。ある部品がデータを取り込み、別の部品が承認の流れを処理し、さらに別の部品が通知を送るとします。FDEは、顧客Aには在庫確認のワークフローとして組み合わせ、顧客Bには発注承認のワークフローとして組み合わせられます。

この例は、話者が部品の具体的な内容を述べたものではありません。共有された基本部品から、顧客ごとのアプリケーションやワークフローを組み立てる考え方を示すための例です。

最初から作り直すと何が起きるか

話者は、顧客ごとにゼロから作る方法の問題を、かなり強い表現で説明しています。似た機能を何度も別々に作ると、コードの品質が下がることがあります。また、顧客ごとにリポジトリが増え、保守（maintenance）の対象も増えます。担当したエンジニアがいなくなると、その人だけが理解しているコードを別の人が引き継がなければなりません。話者は、こうした状況がエンジニアの離職にもつながりうると述べています。

ここで言われている「多数のリポジトリ」やエンジニアが辞めるという話は、具体的な測定結果ではありません。話者が、顧客ごとの完全な作り直しから生じる失敗の大きさを説明するために挙げた例です。

原因は、個別の要求があることだけではありません。共通化できる部分まで個別に複製することです。複製が増えると、修正を一か所に反映できなくなります。各顧客のコードを別々に直す必要が生まれ、保守の費用と負担が増えます。

プラットフォームが支える拡大

FDEの考え方は、「顧客ごとに特別な結果を出すこと」と「同じ基盤を再利用すること」を両立させようとします。FDEは顧客の状況を理解して個別の解決策を作ります。しかし、その解決策の土台には、複数の案件で使えるプリミティブがあります。

この条件があるから、会社は顧客の成果を提供しながら、すべての案件を別会社の受託開発のように運営せずに済みます。プラットフォームは、単なる販売用の製品ではありません。FDEが顧客の文脈に合わせて作業するための、再利用可能な技術基盤でもあります。

ただし、共有プリミティブを使えば保守が完全になくなるわけではありません。共有部品を設計し、改善し、顧客向けの組み合わせを管理する仕事は残ります。話者の主張は、FDEは自動的に拡大できるということではありません。共有プラットフォームがあることで、ゼロからの重複開発を減らせるという、条件付きの主張です。

要点

デザインパートナーシップは、顧客と協力して問題を理解し、解決策を作る初期の方法です。FDEは、その方法を企業向けに広げます。ただし、顧客ごとのソフトウェアをすべて作り直すのではありません。共有プリミティブを組み合わせて個別のアプリケーションやワークフローを作ることが、FDEと開発会社を分ける境界です。

この境界を守れないと、コード、リポジトリ、保守負担が顧客の数に合わせて増えます。逆に、共通の技術基盤を再利用できれば、顧客の個別の成果と、会社全体の技術的な再利用性を同時に目指せます。

出典： YouTube（7:19から）