技術とは「一子相伝」を「誰もが通れる道」にすること
登壇した中沢氏は、デザイナー、プロダクトマネージャーを兼務しつつ、エンジニアリング領域にも精通するフルスタックプロダクトビルダーだ。同氏はまず、本セッションにおける「技術」の定義から話を始めた。
「技術」という言葉を因数分解すると、「技（巧みな手仕事）」と「術（通う道）」に分けられる。中沢氏はこれを「一子相伝の秘儀を、誰もが再現可能な道に変えること」と定義づける。
また、Technologyの語源である「Techne（制作）」と「Logos（論理）」を引き合いに出し、感覚的に作るのではなく、「なぜそう作るのかを言葉で体系化したもの」こそが技術であると語る。
今回、同氏が提示するInformation Architecture（以下、IA）は、単なる画面設計の手法ではない。混沌とした業務の現実を、システムという論理的な構造へと変換するための、再現可能な「技術」なのである。
「業務世界」の実体は、階層のないネットワークである
システム設計において最も困難なのが、要件定義の前提となる「業務」の捉え方だ。中沢氏はここで、生物学の「環世界（Umwelt）」にヒントを得た「業務世界」という独自の概念を提示した。
「業務世界とは、一人ひとりの役割・目標・業務プロセス・使用するシステムによってかたちづくられた、業務上の知覚世界および行動の枠組みです」
例えば、同じ社内システムを見ていても、経理担当者と営業担当者では見えている景色（重要情報や導線）がまったく異なる。このように主観的で多義的な業務の世界を、中沢氏は「リゾーム（Rhizome）」構造であると解釈する。
リゾームとは、フランスの哲学者ジル・ドゥルーズらが提唱した概念で、竹やレンコンのような「地下茎」を指す。中心や頂点が存在する「ツリー構造」とは異なり、リゾームは非階層的で、どの点からでも接続や変化が起こり得るネットワーク構造を持つ。
中沢氏は、「実際の業務は、組織図のようなきれいなツリー構造ではなく、あらゆる要素が絡み合うリゾーム構造をしている」と指摘する。この認識のズレこそが、使いにくいシステムを生む根本原因なのだ。
事例：リゾームとして「入社手続き」を捉え直す
この抽象的な概念を理解するために、中沢氏は「新入社員の入社」というイベントを例に挙げた。
これを一般的な「ツリー構造（組織図的な縦割り）」で捉えると、以下のようになる。
- 人事：契約締結、受け入れ対応
- 情シス：アカウント発行
- 総務：PC・備品の手配
それぞれの部署が独立したタスクとして処理しているように見える。しかし、これを「リゾーム構造」の視点で捉え直すと、まったく異なる景色が見えてくる。
1. 接続（Connection）
「入社日」という1つの情報は、総務にとっては「PC配送手配の基準日」となり、情シスにとっては「アカウント権限の有効化日」となる。1つの事実が、部署を超えて多目的に接続されているのだ。
2. 切断と再生（Heterogeneity）
人事担当者が不在でも、現場マネージャーがSlackに招待して業務を開始させたり、配属先が余っているPCを貸与したりすることがある。これは正規のフロー（ツリー）からは逸脱しているが、業務現場では自然発生的に行われる「横からの芽（リゾーム的な再生）」である。
3. 多相性（Multiplicity）
「氏名」という単純なデータ1つとっても、文脈によって意味が変わる。給与振込には「カナ名」、社会保険には「漢字名」、メールアドレスには「ローマ字名」、そして社内コミュニケーションには「あだ名」が必要となる。
中沢氏は次のように語る。
「業務世界をリゾームとして捉えることで、情報の多義性や、隠れた関係性を発見することができます。これらを無視してきれいなツリー構造のシステムを作ろうとすると、現場の運用に耐えられないものになってしまうのです」
カオスを構造化する技術「Information Architecture」
では、この複雑怪奇なリゾーム（業務実態）を、どのようにしてシステムというツリー構造（UI）に落とし込めばよいのか。ここで登場するのが「Information Architecture（IA）」だ。
IAの原義は「データのカオスの中に潜むパターンを見つけ出し、複雑なものをシンプルにするための構造」である。中沢氏は、これを住宅建築に例えて解説した。
建築には、「動かせない構造物」と「動かせる装飾」がある。これをソフトウェアに置き換えると、以下のような階層が見えてくる。
住宅建築の階層（上段）と、それをソフトウェア開発に応用した階層（下段）。
「基礎」がおろそかであれば、美しい「内装」も意味をなさない
- Foundation（基礎）≒データモデル
- Superstructure（構造）≒ページ階層・ナビゲーション
- Room（空間）≒体験・機能・レイアウト
- Equipment／Movables（設備・家具）≒ボタン、モーダル、コンポーネント
重要なのは、UI（部屋・家具）を設計する前に、強固なデータモデル（基礎）とナビゲーション（構造）を設計しなければならないという点だ。
中沢氏は「ユニットバス・アーキテクチャ」という独自のアンチパターンを紹介した。
ビジネスホテルのユニットバスは、浴槽・トイレ・洗面が集約されており、建設コスト的には合理的だ。しかし、「誰かがトイレを使っていると洗面所が使えない」といった制約が発生し、居住性は低い。
UIにおいても同様に、安易に機能を1つの画面やモードに詰め込みすぎると、データの整合性が取れなくなったり、ユーザーの自由度を奪ったりする結果を招く。
