序
みなさんは，あることについて議論をするとき，どのような構造を念頭に置いているだろうか．
おそらく多くの人は，かなり自然に 限られたスコープの木 を前提にしている． いま話している根があり，その下に枝があり，その枝の中で話を進める． 脇道に逸れたら「いったん戻ろう」と言い，別の枝が見えたら「それは別論点」として切り分ける．
この態度は，実務上はかなり好まれやすい． 議論が暴れにくいように見えるし，会議の時間も読みやすくなるように見える． 人に説明するときも，木の形に落とした方が親切だ，と言われることが多い．
しかし私は，この前提が全く好きではない． もっと強く言えば，議論を木として進めることは正しくない と思っている．
情報の本質的な構造はグラフであり，木はその部分構造に過ぎない． 議論を木として進めることは，しばしば本来そこにあった辺を落とし，その欠落を正規の構造として扱うことでもある．
そして落とされた辺は，あとから「考慮不足」という名前で帰ってくる．
木は正しくない
グラフ理論の言葉を借りれば，木はだいたい「閉路のない連結グラフ」として捉えられる． つまり木は，グラフの特殊な形である． グラフの方が先にあり，木はそこに強い制約をかけたものだ．
この関係は，情報にもそのまま当てはまると思っている． 木で表せる情報があるのではなく，木で表せるほど単純な情報だけがたまたま木として扱える． そして議論は，ほとんどの場合，そんなに単純ではない．
ある情報が一つの親だけを持つとは限らない． ある論点が一つの根だけに従属するとも限らない． ある判断材料が一つの枝の中だけで完結するとも限らない．
実際，ファイルシステムを考えるだけでもすぐに無理が見える． 一つのファイルを「仕事」配下に置くのか，「個人研究」配下に置くのか，「2026」配下に置くのか，「あるプロジェクト」配下に置くのかは，その時点の都合でしかない． 親を一つに決めると，別の文脈から見た自然さが失われる． だから私たちは検索を使い，タグを使い，リンクを使い，ショートカットやシンボリックリンクのような逃げ道を使う．
これは単なるUIの好みではない． 木に押し込めること自体が，情報の形に対してかなり強い，そして多くの場合は間違った仮定を置いている．
この問題意識は古くからある． Vannevar Bushは1945年のAs We May Thinkで，記録を機械的に扱う未来を考え，関連する記録をたどるassociative trailsのような発想を示していた． 今の言葉で言えば，これはかなりハイパーテキスト的で，グラフ的な想像力である．
現代のツールでも同じ方向は見える． ObsidianのGraph viewは，ノートをノード，内部リンクをエッジとして可視化する． Scrapboxは2024年にHelpfeel Cosenseへ名称変更されたが，ページ同士をゆるくリンクさせながら知識を育てる思想は，まさに木ではなくグラフに近い．
これらが示しているのは，「情報は親子関係だけでは扱い切れない」という当たり前の事実だ． 私はこの当たり前さを，議論の場でも徹底したい．
なぜ人は木を好むのか
では，なぜ木の形がこんなに好まれるのか．
理由はかなり単純で，人間のワーキングメモリには限界があるからだ．
George A. Millerの有名な論文The Magical Number Seven, Plus or Minus Twoは，人間の情報処理容量の限界をめぐる古典的な参照点になっている． ただし，この「7」という数字を雑に神聖視してはいけない． Nelson CowanはThe magical number 4 in short-term memoryで，短期記憶の容量をより小さく，おおむね3から5チャンクの問題として整理している．
また，Cognitive Load Theoryでも，複雑な課題では，同時に処理すべき情報要素が多すぎると，容量の限られたワーキングメモリが圧迫される，という整理がなされている．
つまり，人が「もっと簡単に話してほしい」「論点を絞ってほしい」「今はこの話だけにしてほしい」と感じるのは自然だ． それ自体は悪ではない． むしろ他者への配慮として重要な場面も多い．
ただし，ここで混同してはいけないことがある．
人間が一度に扱える情報量が小さいこと と，問題そのものが小さい木で表現できること は，全く別である．
前者は受け手の制約であり，後者は対象の構造についての主張である． この二つを混ぜると，とても危ない． 木が好まれるのは，木が正しいからではない． 人間の処理系が狭いから，そう見せると楽に感じるだけである．
楽であることと，正しいことは違う．
間違ったツリーシェイキング
人と働いていると，「頭が良い人」や「話がわかりやすい人」という評価は，多くの場合，その時必要な情報を必要十分に絞って簡略化できる人に向けられる．
この評価自体はわかる． 実際，聞き手に合わせて話す順番を調整できる人は強い．
しかし，話す順番を調整すること と，議論の構造を木に変換すること は違う． 前者はグラフ上のtraversalを選ぶ行為であり，後者はグラフから辺を消す行為である．
しかし，本当の意味でこれができる人はかなり限られている．
なぜなら「何を落としてよいか」を判断するには，すでにグラフ全体の構造が見えていなければならないからだ． ある辺が今の説明に不要なのか，それともあとで意思決定をひっくり返す重要な依存なのかは，木に畳まれた断面だけを見ていても判断できない．
多くの場合，人は必要十分な簡略化をしているのではなく，単に処理しきれない辺を落としている． これはいわば，間違ったツリーシェイキングである．
使われていないコードを落としているつもりで，実は副作用を持つimportを消している． 議論でも同じことが起きる．
「それは今の話ではない」として，実は前提条件だった話を落とす
「細かい話」として，実は実装可能性を左右する制約を落とす
「別チームの話」として，実は責任境界を決める依存を落とす
「感情論」として，実は合意形成の失敗を予告している信号を落とす
そしてあとから，なぜかうまくいかない． なぜか認識がずれている． なぜか仕様がひっくり返る．
それは，議論の途中で必要だった辺を落としたからである．
フォーカスもグラフ上の操作である
もちろん，「常に全ての情報を同時に発話しろ」と言いたいわけではない． 人間はそんなに広いワーキングメモリを持っていないし，発話にも文章にも順番がある．
重要なのは，フォーカスを 削除 として扱わないことだ．
フォーカスとは，グラフに対するviewportである． いま中心に置くノードを決め，深さを決め，その範囲を見る． ただし，viewportの外にあるものが存在しないことにはしない． これは木ではない． グラフをグラフのまま見ているが，視野の中心と半径を変えているだけである．
「今はこの話だけ」と言うなら，それは本来，
いまはこのノードを中心にdepth 1で見ている
という意味であるべきだ．
「それは別論点」と言うなら，それは本来，
この論点とは別ノードだが，辺は残す
という意味であるべきだ．
「あとで話す」と言うなら，それは本来，
この辺は閉じていないので，後で戻る
という意味であるべきだ．
ところが実際の議論では，「フォーカス」という言葉がしばしば「存在しないことにする」という意味で使われる． これはよくない．
グラフの一部だけを見ることはある． しかし，見ている対象は最後までグラフである． グラフを木へ変換してはいけない．
議論は依存グラフである
ここで言っているグラフは，何でもかんでも平等に散らばった無方向グラフではない． むしろ議論には，かなり強い方向がある．
Aを主張するにはBが必要である
Cが真ならDは弱くなる
EはFの具体例である
GはHの用語定義に依存している
IはJの実装可能性を制約している
KはLの合意形成を壊しうる
こういう辺がある． つまり議論は，親子関係というより依存グラフである．
この依存グラフを無理に木へ畳むと，「何を親とするか」という不自然な選択を強いられる． しかもその親は，たいてい会議の主催者，ドキュメントの見出し，チケットの粒度，組織図，その時の力学によって決まる．
しかし情報の依存関係は，そんなものに従ってくれない．
だから，グラフに方向がないと言いたいわけではない． 単方向の親子関係として扱うのは正しくない，と言いたいのである． 議論は依存グラフとして進めるべきだ． 「今どの辺をたどっているか」を意識することはあっても，「この枝以外はない」としてはいけない．
外部化せよ
議論をグラフのまま進めるために，人間の脳内だけで頑張る必要はない． むしろ，脳内だけで処理しようとするから木に畳みたくなる．
ボトルネックが人間のワーキングメモリにあるなら，解くべきは「問題を小さく見せること」ではなく，グラフを外部化すること である．
この意味で，議論を地図として扱う試みはかなり重要だと思っている． たとえばDialog Mappingは，会話の中で出てきた質問，アイデア，賛否の議論を共有のネットワーク状の地図として記録する方法として説明されている． その背景にあるIBISも，議論を単なる箇条書きではなく，問い・案・根拠の関係として扱う発想に近い．
もちろん，毎回専用ツールを使う必要はない． 大事なのは，議論中に見えているグラフを，少なくともどこかに残すことである．
たとえば，
論点をノードとして名前付けする
辺に種類を付ける
「あとで戻る」を単なる口約束にせず，未解決の辺として残す
「別論点」を削除ではなくリンクとして扱う
議論の最後に，落とした辺がないかを見る
この程度でもかなり違う．
議論が複雑になること自体を恐れすぎなくてよい． 複雑なものが複雑に見えているなら，それはむしろ正しい表示かもしれない． 恐れるべきは，複雑なものを単純に見せた結果，重要な依存を消してしまうことだ．
読む順番と構造を混同するな
私は，少なくとも議論の内部表現としては，木を捨てろと言いたい．
文章を書くとき，発表するとき，誰かにオンボーディングするとき，順番は必要になる． 見出しも必要になる． どこから読み始め，次にどこへ進むかを決める必要もある．
しかし，それは木ではない． それはグラフのtraversal orderである．
本当に良い説明者は，背後にあるグラフを見たまま，その時にたどる経路を選んでいる． だから相手が別の質問をしたとき，別の経路へ移れる． 前提が変わったとき，辿り方を変えられる． 一度は視野の外に置いた辺を，必要に応じてすぐ戻せる．
逆に，悪い説明は，経路を構造だと誤認している． 一度たどらなかった辺を落とし，落としたことも忘れ，最後にはその順番が世界そのものだと思い込む．
これは危険だ．
本当に必要なのは，グラフをグラフのまま保持しながら，その上をどう歩くかを選ぶ能力である． そしてその能力が十分でないなら，歩き方を単純化するより先に，グラフそのものを残すべきだ．
結
議論はグラフのまま進めろ．
もちろん，人間のワーキングメモリには限界がある． だからviewportは必要だし，順番も必要だ．
しかし，それらはグラフ上の操作であって，木への変換ではない．
情報の本質的な構造はグラフである． 木はその部分構造に過ぎない． 議論を木に畳むたびに，辺が落ちる． 辺が落ちれば，依存が落ちる． 依存が落ちれば，判断を誤る．
もし議論をグラフのまま扱えないボトルネックが人間の側にあるなら，私は，問題の方を切り刻むより，人間の側を拡張する努力をしたい．
外部化する． リンクする． 未解決の辺を残す． 局所的に見るとしても，グラフであることをやめない．
議論をグラフのまま進めよ． それは「全部を一度に話せ」という意味ではない． いま見えていない辺を，存在しなかったことにするな という意味である．