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

The Question in This Chapter

Here we consider how finely the parts of a shared platform should be designed when an FDE (forward-deployed engineer) creates a solution for a customer.

The audience's question was roughly as follows.

How atomic should a shared primitive be?

Atomic means making something a small unit that is difficult to divide further. Granularity describes how fine-grained the parts are. For example, a design that makes one ready-to-use large function into a single part has coarse granularity. In contrast, a design that combines many small functions has fine granularity. Here, a primitive means a common platform component that can be reused in solutions for multiple customers.

The Answer Depends on the Industry and Use Case

The speaker's answer is not simply to make the parts as fine-grained as possible. The appropriate granularity changes with the industry and use case. That is because the right design differs depending on whether customers have similar workflows or many exceptions that require individual adjustments.

This explanation begins with the speaker's answer (13:14).

One approach is to prepare a robust foundation first. Robust means that it can be used reliably in typical situations. In this case, most of the application has already been built. The customer or FDE configures and changes only the remaining part. The speaker describes this state as an image in which 60% is complete and 40% is customized.

These numbers express a design intuition. They are not a measurement or a rule saying that every product should be divided into 60% and 40%. What matters is completing enough of the common part while leaving room for customer-specific work.

Example: A Completed Foundation and a Configuration Layer

As an example, imagine a platform that lets several companies manage the same kind of business operation. It provides authentication, data storage, basic screens, and standard processing as shared components. The FDE configures customer-specific approval procedures and data fields on top of them.

In this example, the FDE does not need to rebuild the database or underlying infrastructure each time. As a result, the FDE can spend more time understanding the customer's work and making the necessary customizations. This follows the talk's idea that shared components increase the reusability of FDE work. The speaker does not show the specific contents of the components here.

Exceptional Use Cases Need Fine-Grained Tools

Another approach is to provide finer-grained configuration and tools. In some industries, there are unusual operations or exceptional processing that a standard application cannot handle. In that situation, one coarse component cannot express the customer's requirements. It is more suitable for the FDE or customer to combine small components and configure them in detail.

However, finer-grained is not always better. If the parts are too fine-grained, users must understand many concepts and learn how to combine them. If the parts are too coarse, they cannot support specialized operations. In other words, the designer chooses between the complexity users can handle and the flexibility they need.

The AWS Analogy: Do Not Build the Foundation from Scratch

The speaker uses AWS as an analogy for shared infrastructure. In a cloud such as AWS, users can use common services such as databases. They do not need to build the infrastructure for storing data from zero every time.

In this analogy, a primitive is not necessarily a complete business application itself. It is a common infrastructure service on which users can build their own services or processing. For an FDE as well, starting with an existing data model or service instead of defining and implementing the data model or foundation from scratch lets the FDE focus on the customer-specific part.

However, this is not a claim that every company should copy AWS's design. Also, in the transcript, the name of the AWS service mentioned by the speaker cannot be confirmed completely. What is clear here is the role of the comparison: using a shared service such as a database reduces the burden of building infrastructure yourself.

The Breadth of the User Base Determines the Boundary

Where to place a primitive's boundary is also affected by the breadth of the user base. Here, breadth means more than the number of people. It includes the range of industries, expertise, differences in work, and required freedom.

If the user group is narrow and its workflows are very similar, it may be easier to provide a common robust application. In contrast, if users' work differs greatly, fine-grained tools or a configuration layer may be necessary. However, the speaker does not give a universal ratio for deciding which is correct. The decision should be based on the actual differences among customers and on how much the FDE can support without rebuilding everything each time.

This decision is also connected to the economics of FDE discussed earlier. If shared components can be reused, the company can reduce reinvention for each customer. On the other hand, if a shared component is too coarse, it cannot provide a function that some customers need. The company will end up building a separate mechanism for those customers. Conversely, if everything is made from fine-grained parts, the burden of assembly and maintenance increases.

A Practical Way to Think About It

You can apply this answer in the following order.

1. Separate work that customers have in common from work that differs by customer.
2. Turn the parts reused across many customers into robust shared components or a standard application.
3. Provide a configuration layer or finer-grained tools for the parts needed by exceptional operations.
4. Compare the time an FDE spends rebuilding the foundation with the time spent creating value for the customer.
5. Check with real customers whether the shared components are too coarse or too fine-grained.

This procedure is not a formal design rule presented by the speaker. It is an organization for learning that can be derived from the talk's explanation. What the speaker clearly states is that the choice between a robust foundation and fine-grained tools changes according to the industry, use case, and breadth of the user base.

Uncertainty Remaining in the Transcript

After the discussion of the breadth of the user base, the exchange with the audience at about 14:48–15:05 (888–905 seconds) appears to be missing or heavily compressed. We cannot confirm what question followed or what the speaker answered. Therefore, this chapter does not imagine that gap and add a specific design method.

The key point of this Q&A is not that the most atomic parts are always the easiest to reuse. A shared platform looks for a boundary that handles enough of the common work while also supporting differences among customers. That boundary is not the same for every industry or user base.