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

個人の理解を、チームで使える理解にする

ここまでの技法は、説明やマイクロワールドによって、一人の人がシステムを理解する方法でした。話者はここで、理解にはもう一つの問題があると話します。理解は個人だけでなく、チームの問題でもあります。

チームが一緒に仕事をするには、システムの部品、画面の要素、問題の概念などについて、共通の名前とイメージが必要です。これを**共通理解（shared understanding）**と呼びます。たとえば全員がある画面の部分を同じ名前で呼べれば、「その部分を残して変更する」と短く話せます。名前やシステムのモデルが人によって違うと、同じ言葉を使っても別のものを考えてしまいます。

これは、前に出てきた「理解して作業のループに参加する」という考え方を、チーム全体に広げたものです。一人が理解したことを自分の頭だけに持っていても、他のメンバーはその理解を使えません。共通のモデルがあれば、チームは同じ土台から次のアイデアを出せます。話者は、これを共有空間（shared space）によって支えようとします。

人間とエージェントの会話を見える場所に置く

話者が示す一つの方法は、人間とAIエージェントの会話を、チームの共有空間に置くことです。通常の使い方では、メンバーがそれぞれ自分のエージェントに相談します。その場合、誰が何を質問したか、エージェントがどう答えたか、どの前提で作業したかは、他のメンバーから見えません。

共有空間では、複数の人が同じ会話を見られます。ある人の質問を見ると、他の人はその人が気づいた問題を知ることができます。エージェントの返答や作業の説明を見ると、システムの別の動きも分かります。質問、回答、判断の流れが見えるので、個人の発見がチームの理解になります。

話者が示す探索的な例では、人間とエージェントが一つの会話の中で問題を調べます。これは、二人が別々のエージェントに相談し、最後に要約だけを交換する方法とは違います。要約だけでは、途中の疑問や判断の理由が失われやすいからです。

図1：削除されたブロックを見えるようにする問題を、共有された議論の中で扱っています。

**図から確認できること：**スライドには、削除されたブロックをページから完全に消さず、その場所で見えるようにする案が示されています。最終状態だけでは隠れる情報を、チームが確認できるようにする考え方です。細かなUI（ユーザーインターフェース）の形や実際の機能は、この計画だけでは確定できません。動画の00:15:42を見る

最終状態だけでは、変更の意味が消える

エージェントがページを編集すると、通常は編集後の最終状態が中心になります。しかし、最終状態だけでは、何が削除されたのか、なぜ削除したのか、どの会話を経て変更したのかが分からないことがあります。

話者が取り上げる具体的な問題は、エージェントによるブロックの削除です。削除されたメモ、判断、背景が見えなければ、チームは結果だけを見て推測するしかありません。削除された場所を確認できれば、チームはエージェントの行動をたどり、必要な質問をその場でできます。つまり、見える履歴は、単なる記録ではなく、一緒に理解するための材料になります。

図2：人間の議論と、エージェントがブロックを削除する問題を同じ文脈で示しています。

**図から確認できること：**このスライドは、ページの最終状態だけでは、エージェントが何を削除したか分からないという問題を説明しています。削除されたメモや判断を見えるようにすれば、チームは結果を受け取るだけでなく、変更の意味を一緒に考えられます。話者はこの問題を、共有理解をつくるための例として提示しています。どの製品機能のUIなのかは、計画からは確定できません。動画の00:15:59を見る

文書とコメントで、計画を一緒に検討する

共有空間のもう一つの要素は、文書とコメントです。エージェントが作った実装計画を文書にまとめます。そして、関係する箇所にコメントを付けます。こうすると、チームは計画の文脈を保ったまま質問し、返答し、計画を直せます。

これは、計画を短い要約にして別の場所へ送る方法とは違います。要約だけでは、質問がどの部分に向けられているか、前の判断とどうつながるかが分かりにくくなります。文書上のコメントなら、質問と計画を直接結びつけられます。コメントは、エージェントが作った計画をチームで考えるための基本的な道具になります。

話者が示す流れは、次の順番です。

1. 人間が問題を提示します。
2. 人間とエージェントが、その問題を一緒に調べます。
3. エージェントが実装計画を作ります。
4. チームが計画にコメントし、内容を検討します。

この順番なら、問題の理解と実装の相談が、別々の要約に分断されません。

図3：共有された実装計画の中で、削除表示の設計を考えています。

**図から確認できること：**スライドは、問題についてのコメントから、具体的な実装計画へ進む様子を示しています。削除されたブロックは、最初からすべて表示するのではなく、基本的には折りたたみ、必要なときに確認する案として読めます。通常のページを見やすく保ちながら、変更の背景も残すという設計上の選択です。細かな実装内容までは、この計画から確認できません。動画の00:16:21を見る

「共有」は、同じ場所に保存するだけではない

ここでいう共有空間は、単に同じ文書を保存する場所ではありません。重要なのは、問題、質問、エージェントとの会話、計画、コメントが、関係する人から見えることです。文書を一人のコンピューターだけに置いても、共通理解は自動的には生まれません。

**例：**二人が別々のエージェントに「削除された部分をどう扱うか」と質問し、結論だけを交換したとします。結論は共有できますが、質問の仕方、エージェントの前提、途中で捨てた案は共有されません。同じスレッドで調べれば、もう一人はその疑問を見て、自分の知識や別の案を加えられます。これは、二人が同じ問題を考えるための共有です。

また、話者が示す探索的なマルチプレイヤー型の人間・エージェント会話と、後で述べる「コーディングエージェントをNotionに取り入れた」という話は、同じUIや同じ機能だと決めつけてはいけません。計画は、それぞれの場面で実際にどのUIが表示されたかを確定していません。

まとめ：共通のモデルから、共同のアイデアが生まれる

エージェントによってコードや作業が速くなっても、チームの理解まで自動的にそろうわけではありません。各メンバーが別々の会話をして結果だけを交換すると、質問と判断の背景が分断されます。

共有された会話、文書、コメントは、その分断を小さくします。チームは同じ名前と概念を使い、エージェントの行動を見ながら質問し、計画をその場で検討できます。その結果、メンバーは出力に単に「よい」と答えるだけでなく、同じシステムモデルを使って次のアイデアを一緒に考えられます。これは、チームが一緒に議論し、創造的な案を出すための共通の文脈です。

個人向けの説明やマイクロワールドが一人の理解を助けるのに対して、共有空間は集団の理解を助けます。目的は、人間を作業のループから外すことではありません。人間同士とエージェントが同じループに、より深く参加できるようにすることです。