手法3：共有空間でチームの理解を築く

Turn individual understanding into understanding the team can use

The techniques so far have shown how one person can understand a system through explanations and microworlds. Here, the speaker says that understanding has another problem. It is not only an individual problem; it is also a team problem.

For a team to work together, its members need shared names and mental images for system components, interface elements, and problem concepts. This is called shared understanding. For example, if everyone uses the same name for one part of a screen, they can briefly say, “Change it while keeping that part.” If people have different names or different models of the system, they may imagine different things even when they use the same words.

This extends the earlier idea of understanding enough to participate in a work loop to the whole team. If one person keeps an understanding only in their own head, the other members cannot use it. With a shared model, the team can produce its next idea from the same foundation. The speaker tries to support this with a shared space.

Put conversations between people and agents where the team can see them

One method the speaker presents is to put conversations between people and AI agents in a team shared space. In the usual pattern, each member consults their own agent. Then the other members cannot see who asked what, how the agent answered, or which assumptions it used while working.

In a shared space, several people can see the same conversation. When one person sees another person's question, they can learn about a problem that person noticed. By seeing the agent's reply and description of its work, they can also understand other behavior of the system. Because the questions, answers, and decisions are visible, an individual's discovery becomes part of the team's understanding.

In the exploratory example shown by the speaker, people and agents investigate a problem in one conversation. This differs from two people consulting separate agents and exchanging only a summary at the end. A summary alone can easily lose the questions that arose along the way and the reasons for decisions.

Figure 1: A shared discussion addresses the problem of making deleted blocks visible.

What can be confirmed from the figure: The slide presents a proposal to keep deleted blocks visible in their original place instead of removing them completely from the page. The idea is to let the team check information that would be hidden by the final state alone. The detailed UI (user interface) shape and actual functionality cannot be determined from this plan alone. Watch 00:15:42 in the video

The final state alone makes the meaning of a change disappear

When an agent edits a page, attention usually centers on the state after the edit. But the final state alone may not show what was deleted, why it was deleted, or what conversation led to the change.

The specific problem the speaker discusses is an agent deleting blocks. If deleted notes, decisions, and background are not visible, the team can only look at the result and guess. If the deleted location can be inspected, the team can follow the agent's actions and ask necessary questions there. In other words, visible history is not just a record; it is material for understanding together.

Figure 2: A human discussion and the problem of an agent deleting blocks are shown in the same context.

What can be confirmed from the figure: This slide explains that the page's final state alone does not show what the agent deleted. If deleted notes and decisions are made visible, the team can do more than receive the result; it can consider the meaning of the change together. The speaker presents this problem as an example of building shared understanding. The plan does not establish which product feature the UI belongs to. Watch 00:15:59 in the video

Examine a plan together with documents and comments

Another element of a shared space is documents and comments. The agent's implementation plan is collected in a document. People then comment on the relevant parts. This lets the team ask questions, respond, and revise the plan while keeping its context.

This differs from turning a plan into a short summary and sending it somewhere else. With only a summary, it becomes harder to tell which part a question concerns and how it connects to an earlier decision. A comment on the document can link the question directly to the plan. Comments become a basic tool for the team to think about an agent-created plan.

The process shown by the speaker follows this order.

1. A person presents a problem.
2. People and agents investigate the problem together.
3. The agent creates an implementation plan.
4. The team comments on the plan and examines its contents.

With this order, understanding the problem and discussing the implementation are not split across separate summaries.

Figure 3: The team considers the design for displaying deleted content inside a shared implementation plan.

What can be confirmed from the figure: The slide shows a move from comments about the problem to a concrete implementation plan. It can be read as proposing that deleted blocks normally be collapsed and shown when needed, rather than all being displayed from the beginning. This is a design choice that keeps an ordinary page readable while preserving the background of the change. The plan does not reveal the detailed implementation. Watch 00:16:21 in the video

“Shared” means more than storing something in the same place

The shared space here is not simply a place to store the same document. What matters is that the problem, questions, conversations with the agent, plan, and comments are visible to the relevant people. Putting a document on only one person's computer does not automatically create shared understanding.

Example: Suppose two people ask separate agents how to handle the deleted parts and exchange only their conclusions. They can share the conclusions, but not how the questions were asked, the agents' assumptions, or the ideas abandoned along the way. If they investigate in the same thread, the second person can see the question and add their own knowledge or another proposal. This is sharing so that two people can think about the same problem.

Also, we should not assume that the exploratory multiplayer-style conversation between people and agents shown by the speaker is the same UI or feature as the later statement that “coding agents were brought into Notion.” The plan does not establish which UI was actually shown in each scene.

Summary: Shared models produce shared ideas

Even if agents make code and work faster, the team's understanding does not automatically become aligned. If each member has a separate conversation and exchanges only the result, the background of the questions and decisions becomes fragmented.

Shared conversations, documents, and comments reduce that fragmentation. The team can use the same names and concepts, ask questions while watching the agent's actions, and examine the plan on the spot. As a result, members do more than simply say “good” to an output; they can use the same system model to think about the next idea together. This is shared context for a team to discuss and create ideas together.

While explanations and microworlds for individuals help one person understand, shared spaces help a group understand. The goal is not to remove people from the work loop. It is to let people and agents participate more deeply in the same loop.