顧客の一言を仕様に変える前に――引用・要約・仮説を分ける

Wed, 04 Nov 2026 23:08:03 +0900

When transferring meeting notes or interview transcripts into specifications, simply organizing them for readability can change their meaning. Particular care should be taken when what the customer actually said and what the team came up with as solutions are mixed together in a single document.

In the following short editing example, we will separate quotations, summaries, and hypotheses . The statements and situations are fictional examples for illustrative purposes only and do not represent actual customers or research results.

Reading fictional statements in three layers

Quote: Retain the portion included in the statement.

"I explain the background of the same issue from the beginning at every meeting."

What can be gleaned from this sentence is a complaint about the effort required to re-explain the background. It's still unclear which meeting it is, who the explanation is being given to, or what information has already been shared.

Summary: Shorten without adding new facts.

"There was a comment that it would be burdensome to have to explain the background of the case again in multiple meetings."

Even when summarized, the fact that it's just one statement and the context remains unconfirmed doesn't change. Adding information such as "everyone is having trouble" or "existing materials aren't being used" transforms it from a summary into a different argument.

Hypothesis: Write the solution as a proposal to be tested.

"If we can pass on what was decided and what remains unresolved from the previous meeting to the next participant, it might reduce the burden of having to explain things again."

This is not the customer's actual statement, but rather the team's interpretation. It's worth trying out different handover methods, but it's not yet confirmed that a shared dashboard or automated notifications are necessary at this stage.

A sentence that turns into a definitive statement of the specifications.

For example, if we rewrite a fictitious statement as "We need a real-time shared dashboard across the entire company," three additional decisions are required: scope, update frequency, and implementation method. The original statement alone does not provide the basis for these decisions.

The first thing to check is whether re-explanation was necessary, what information had already been provided, and what information the recipient couldn't find. Even if the same materials are available, the solutions to try will differ depending on whether the information is outdated, difficult to find, or the participants are different.

Connecting rationale and design within the document.

When writing draft specifications, it's helpful to include the original source of the statement and the design decisions derived from it, making them easier to verify during reviews. It's important not to write with the same level of assertion about things that are directly evident from the quote and things that still need to be verified.

As an example, the Technical Spec guide, which references customer justifications and code , explains the process of organizing the design, considered alternatives, and acceptance criteria by referring to customer justifications and the target repository. This is a useful resource when considering how to create design documents while maintaining references to the justifications.

The fictional examples in this article do not represent actual results of performing the function or instances where its effectiveness was measured.

Try this in the next document, a small edit

You don't need to change the format of all your documents. The next time you summarize a request, try adding either a "quote," "summary," or "hypothesis" at the beginning of each paragraph. This will make it easier for the reader to determine whether they are reading the text as a record of a statement or as a design proposal.

It's not a problem if some points remain unconfirmed. Leaving those points unresolved, rather than presenting them as finalized specifications, leads to documentation that can be verified later.

This article contains AI-assisted editorial notes created by the team providing the linked product. Product inquiry form .

product-work-notebookのブログ