Q&A：共有プリミティブの粒度を選ぶ

この章の問い

ここでは、FDE（forward-deployed engineer）が顧客向けの解決策を作るとき、共有プラットフォームの部品をどのくらい細かく設計するべきかを考えます。

聴衆の質問は、次のようなものでした。

共有プリミティブ（primitive）は、どこまで原子的（atomic）であるべきですか。

原子的とは、これ以上分けにくい小さな単位にすることです。**粒度（granularity）**は、部品の細かさを表します。たとえば、すぐ使える大きな機能を一つの部品にする設計は「粒度が粗い」設計です。反対に、小さな機能を多数組み合わせる設計は「粒度が細かい」設計です。ここでいうプリミティブは、複数の顧客向け解決策で再利用できる、プラットフォーム上の共通部品を指します。

答えは業界と用途で変わる

話者の答えは、単純に「できるだけ細かくする」ではありません。適切な粒度は、業界と用途によって変わります。顧客の仕事の流れが似ているのか、それとも例外が多く、個別の調整が必要なのかによって、適した設計が異なるからです。

この説明は、話者の回答（13:14）から始まります。

一つの方法は、頑健（robust）な土台を先に用意することです。頑健とは、一般的な状況で安定して使えるという意味です。この場合、アプリケーションの大部分はすでに作られています。顧客やFDEは、残りの部分だけを設定・変更します。話者は、この状態を「60％が完成していて、40％をカスタマイズする」というイメージで説明しています。

これは設計上の直感を示す数字です。すべての製品で60％と40％に分けるべきだ、という測定結果や規則ではありません。重要なのは、共通部分を十分に完成させながら、顧客固有の仕事を入れる余地も残すことです。

例：完成した土台と設定の層

例として、複数の会社が同じ種類の業務を管理するプラットフォームを考えます。認証、データの保存、基本的な画面、標準的な処理を共通部品として提供します。FDEは、その上に顧客固有の承認手順やデータ項目を設定します。

この例でFDEは、データベースや基盤の仕組みを毎回作り直す必要がありません。その分、顧客の業務を理解し、必要なカスタマイズを行う時間を増やせます。これは、共有部品がFDEの再利用性を高める、というこの講演の考え方に沿った説明です。具体的な部品の中身は、話者はここでは示していません。

例外の多い用途には、細かい道具が必要になる

もう一つの方法は、より細かい設定やツールを提供することです。業界によっては、標準的なアプリケーションだけでは対応できない、珍しい業務や例外的な処理があります。その場合、粗い一つの部品だけでは顧客の要求を表現できません。FDEや顧客が小さな部品を組み合わせ、細かく設定できるほうが適しています。

ただし、細かくすれば必ずよいわけではありません。部品が細かすぎると、利用者が多くの概念を理解し、組み合わせ方も学ばなければなりません。逆に、部品が粗すぎると、特殊な業務に対応できません。つまり、設計者は「利用者が扱える複雑さ」と「必要な柔軟性」の間で選ぶことになります。

AWSのたとえ：基盤をゼロから作らない

話者は、AWSを共有インフラのたとえとして使います。AWSのようなクラウドでは、データベースなどの共通サービスを利用できます。利用者は、データを保存するための基盤を、毎回ゼロから作る必要がありません。

このたとえでのプリミティブは、完成した業務アプリケーションそのものとは限りません。利用者がその上に自分のサービスや処理を作れる、共通の基盤サービスです。FDEにとっても、最初からデータモデルや基盤を定義・実装するのではなく、すでにあるデータモデルやサービスを出発点にできれば、顧客固有の部分に集中できます。

ただし、これはAWSの設計をすべての会社がまねるべきだ、という主張ではありません。また、文字起こしでは、話者が挙げたAWSのサービス名は完全には確認できません。ここで確かなのは、データベースのような共有サービスを使い、インフラを自作する負担を減らす、という比較の役割です。

利用者の幅が、境界を決める

どこにプリミティブの境界を置くかは、利用者の幅にも左右されます。ここでいう利用者の幅とは、人数だけではなく、業界、専門知識、業務の違い、必要な自由度などの広がりです。

利用者の範囲が狭く、仕事の流れがよく似ているなら、共通の頑健なアプリケーションを提供しやすい場合があります。反対に、利用者の業務が大きく異なるなら、細かいツールや設定層が必要になる場合があります。しかし、どちらが正しいかを決める普遍的な比率は、話者は示していません。実際の顧客の違いと、FDEが毎回作り直さずに対応できる範囲を見て決めます。

この判断は、先ほどのFDEの経済性ともつながります。共有部品が再利用できれば、顧客ごとの再発明を減らせます。一方で、共有部品が粗すぎると、一部の顧客にとって必要な機能を作れません。その顧客のために、結局、別の仕組みを作ることになります。反対に、すべてを細かい部品にすると、組み立てと保守（maintenance）の負担が増えます。

実務での考え方

この回答を、次の順番で使えます。

1. 顧客に共通する業務と、顧客ごとに違う業務を分けます。
2. 多くの顧客で繰り返し使う部分を、頑健な共有部品または標準アプリケーションにします。
3. 例外的な業務に必要な部分には、設定層や、より細かいツールを用意します。
4. FDEが基盤を作り直す時間と、顧客向けの価値を作る時間を比べます。
5. 実際の顧客に対して、共通部品が粗すぎないか、または細かすぎないかを確認します。

この手順は、話者が提示した正式な設計規則ではありません。講演の説明から導ける、学習のための整理です。話者が明確に述べているのは、業界・用途・利用者の幅に応じて、頑健な土台と細かいツールのどちらを選ぶかが変わる、という点です。

文字起こしに残る不確実さ

利用者の幅について話された後、約14:48〜15:05（888〜905秒）には、聴衆とのやり取りが抜けている、または短く圧縮されているように見えます。その後にどのような質問があり、話者が何を答えたかは、ここからは確認できません。したがって、この章では、その空白を想像して具体的な設計方法を追加していません。

このQ&Aの要点は、「最も原子的な部品が常に最も再利用しやすい」ということではありません。共有プラットフォームは、共通部分を十分に引き受けつつ、顧客ごとの違いにも対応できる境界を探します。その境界は、すべての業界や利用者に同じではありません。