デザインパートナーシップとは
What Is a Design Partnership?
スタートアップの初期には、会社も顧客も、製品の形をまだ完全には理解していないことがあります。この段階では、顧客と近い距離で協力しながら、顧客の仕事や問題を学びます。そして、その理解を使って、顧客に役立つ解決策を作ります。
In the early stage of a startup, the company and its customers may not yet fully understand what shape the product should take. At this stage, the company works closely with customers to learn about their work and problems. It then uses that understanding to build a solution that helps the customer.
このような関係を、ここではデザインパートナーシップと呼びます。これは、完成した製品を一方的に売る関係ではありません。顧客との協力を通して、何を作るべきかを発見する関係です。
This kind of relationship is called a design partnership here. It is not a relationship in which a finished product is simply sold to the customer. It is a relationship in which the company discovers what to build through collaboration with the customer.
補足：プロダクト・マーケット・フィットとの関係
Supplement: The Connection to Product-Market Fit
プロダクト・マーケット・フィット（product-market fit）は、製品が特定の市場の重要な問題に合い、顧客に継続して選ばれる状態です。製品がこの状態に達する前は、顧客の現場を知らずに仕様を決めることが難しくなります。だから、初期の顧客と一緒に問題を理解し、解決策を作ることに意味があります。
Product-market fit is a state in which a product fits an important problem in a particular market and customers continue to choose it. Before a product reaches this state, it is difficult to decide on its specifications without knowing the customer's actual work. That is why it is useful to understand the problem and build a solution together with early customers.
たとえば、製造会社の在庫管理に使う新しいソフトウェアを作るとします。最初から一般的な機能を大量に作るのではなく、一社の担当者と仕事の流れを確認します。その会社が、どの情報をいつ確認し、どの判断に困っているかを学びます。そのうえで、実際の問題を解決する画面や処理を作ります。この例では、顧客との協力が製品理解と開発を同時に進めます。
For example, suppose you are building new software for a manufacturer's inventory management. Instead of building many general features from the start, you first review the work process with a person at one company. You learn what information that company checks, when it checks it, and which decisions are difficult. You then build screens and processing that solve the actual problem. In this example, collaboration with the customer advances product understanding and development at the same time.
企業向けに拡大するFDE
Scaling FDE for Enterprise Customers
話者の説明では、フォワード・デプロイド・エンジニアリング（Forward-Deployed Engineering、FDE）は、このデザインパートナーシップを企業向けに拡大したものです。FDEは、顧客の状況を理解し、顧客に合う解決策を作ります。したがって、単に完成品を渡して終わる役割ではありません。
In the speaker's explanation, forward-deployed engineering (FDE) is a way to scale this design partnership for enterprise customers. FDE understands the customer's situation and builds a solution that fits the customer. Therefore, it is not a role that simply hands over a finished product and ends there.
企業向けでは、顧客の組織や仕事の流れが大きく、課題も顧客ごとに異なることがあります。そのため、顧客の文脈を学ぶことと、実際にソフトウェアを作ることを近づけます。FDEは、この二つをつなぐ顧客向けのソフトウェアエンジニアです。
Enterprise customers may have large organizations and complex work processes, and their problems may differ from customer to customer. For that reason, FDE brings learning the customer's context close to actually building software. An FDE is a customer-facing software engineer who connects these two activities.
ただし、顧客ごとに別のソフトウェアを最初から作るだけでは、関係を拡大できません。そこで重要になるのが、共通のプラットフォームと**共有プリミティブ（shared primitives）**です。プリミティブとは、何度も使える技術的な基本部品です。話者は、この部品の具体的な技術構成やインターフェースまでは説明していません。ここで重要なのは、FDEが毎回すべてを作り直すのではなく、共通部品を組み合わせて顧客向けのものを作る点です。
However, the relationship cannot scale if the company only builds separate software from scratch for each customer. This is where a shared platform and shared primitives become important. A primitive is a reusable technical building block. The speaker does not explain the specific technical structure or interfaces of these components. The important point is that FDE does not rebuild everything each time; it combines shared components to create something for the customer.
開発会社との違い
The Difference from a Development Shop
FDEでも、顧客ごとの結果に合わせたカスタマイズは行います。しかし、基礎となる実装を顧客ごとに完全に作り直すわけではありません。共有プリミティブを組み合わせて、顧客向けのアプリケーションやワークフローを作ります。
FDE does customize the result for each customer. However, it does not completely rebuild the underlying implementation for every customer. It combines shared primitives to create customer-specific applications and workflows.
この違いによって、FDEは顧客の個別の成果を支援しながら、共通の技術基盤を保てます。一方、開発会社（dev shop）は、顧客ごとに別のソフトウェアを受託して作る形になりやすいものです。個別開発そのものが悪いのではありません。問題は、すべての顧客のために、同じような基礎機能まで毎回作り直すことです。
This difference lets FDE support each customer's individual outcome while keeping a common technical foundation. By contrast, a development shop, or dev shop, tends to build separate software for each customer as contracted work. Custom development itself is not bad. The problem is rebuilding even the same basic functions from scratch for every customer.
例：同じ部品を組み合わせる
Example: Combining the Same Components
補足として、共有プリミティブを積み木の部品にたとえます。ある部品がデータを取り込み、別の部品が承認の流れを処理し、さらに別の部品が通知を送るとします。FDEは、顧客Aには在庫確認のワークフローとして組み合わせ、顧客Bには発注承認のワークフローとして組み合わせられます。
As an additional illustration, think of shared primitives as building blocks. Suppose one component imports data, another handles an approval flow, and another sends notifications. FDE could combine them for Customer A as an inventory-check workflow and for Customer B as a purchase-order approval workflow.
この例は、話者が部品の具体的な内容を述べたものではありません。共有された基本部品から、顧客ごとのアプリケーションやワークフローを組み立てる考え方を示すための例です。
This example does not describe the specific contents of the components stated by the speaker. It is an example meant to show the idea of assembling customer-specific applications or workflows from shared basic components.
最初から作り直すと何が起きるか
What Happens When Everything Is Rebuilt from Scratch
話者は、顧客ごとにゼロから作る方法の問題を、かなり強い表現で説明しています。似た機能を何度も別々に作ると、コードの品質が下がることがあります。また、顧客ごとにリポジトリが増え、保守（maintenance）の対象も増えます。担当したエンジニアがいなくなると、その人だけが理解しているコードを別の人が引き継がなければなりません。話者は、こうした状況がエンジニアの離職にもつながりうると述べています。
The speaker describes the problems with building from zero for each customer in quite strong language. If similar functions are built separately again and again, code quality can decline. The number of repositories and the amount of code that must be maintained also grow for each customer. When the engineer who worked on a project leaves, someone else has to take over code that only that person understands. The speaker says that this situation can also lead engineers to leave.
ここで言われている「多数のリポジトリ」やエンジニアが辞めるという話は、具体的な測定結果ではありません。話者が、顧客ごとの完全な作り直しから生じる失敗の大きさを説明するために挙げた例です。
The statements about “many repositories” and engineers leaving are not specific measured results. The speaker gives them as examples to explain the scale of the failure that can result from completely rebuilding software for each customer.
原因は、個別の要求があることだけではありません。共通化できる部分まで個別に複製することです。複製が増えると、修正を一か所に反映できなくなります。各顧客のコードを別々に直す必要が生まれ、保守の費用と負担が増えます。
The cause is not simply that customers have individual requirements. It is also that parts that could be shared are copied separately. As duplication increases, a fix can no longer be applied in one place. The company has to fix each customer's code separately, increasing maintenance cost and effort.
プラットフォームが支える拡大
Scaling Supported by a Platform
FDEの考え方は、「顧客ごとに特別な結果を出すこと」と「同じ基盤を再利用すること」を両立させようとします。FDEは顧客の状況を理解して個別の解決策を作ります。しかし、その解決策の土台には、複数の案件で使えるプリミティブがあります。
The FDE approach tries to balance “producing a special result for each customer” with “reusing the same foundation.” FDE understands the customer's situation and builds an individual solution. However, the solution is based on primitives that can be used across multiple projects.
この条件があるから、会社は顧客の成果を提供しながら、すべての案件を別会社の受託開発のように運営せずに済みます。プラットフォームは、単なる販売用の製品ではありません。FDEが顧客の文脈に合わせて作業するための、再利用可能な技術基盤でもあります。
Because this condition exists, the company can deliver customer outcomes without running every project like a separate contracted development effort. The platform is not merely a product for sale. It is also a reusable technical foundation that lets FDE work in the customer's context.
ただし、共有プリミティブを使えば保守が完全になくなるわけではありません。共有部品を設計し、改善し、顧客向けの組み合わせを管理する仕事は残ります。話者の主張は、FDEは自動的に拡大できるということではありません。共有プラットフォームがあることで、ゼロからの重複開発を減らせるという、条件付きの主張です。
However, using shared primitives does not make maintenance disappear completely. Work remains to design and improve the shared components and manage the combinations made for customers. The speaker is not claiming that FDE automatically scales. His conditional claim is that a shared platform can reduce duplicated development from scratch.
デザインパートナーシップは、顧客と協力して問題を理解し、解決策を作る初期の方法です。FDEは、その方法を企業向けに広げます。ただし、顧客ごとのソフトウェアをすべて作り直すのではありません。共有プリミティブを組み合わせて個別のアプリケーションやワークフローを作ることが、FDEと開発会社を分ける境界です。
A design partnership is an early approach in which a company works with customers to understand a problem and build a solution. FDE expands this approach for enterprise customers. However, it does not rebuild all the software separately for every customer. Combining shared primitives to create individual applications and workflows is the boundary that separates FDE from a development shop.
この境界を守れないと、コード、リポジトリ、保守負担が顧客の数に合わせて増えます。逆に、共通の技術基盤を再利用できれば、顧客の個別の成果と、会社全体の技術的な再利用性を同時に目指せます。
If the company cannot maintain this boundary, its code, repositories, and maintenance burden grow with the number of customers. If it can reuse a common technical foundation, it can pursue both individual customer outcomes and technical reuse across the company.