「会議のお知らせって、なんでこんなに読みにくいんだろう」
陸が不満そうにプリントを見ている。
「構造がないから」葵が即答した。
「構造？」由紀が聞く。
「メッセージを効率的に伝えるには、適切な構造が必要だ」
ミラが静かにノートパソコンを開き、二つのメールを見せた。
一つ目：「明日午後3時に第2会議室で部会があります内容は文化祭の準備について持ち物は筆記用具です」
二つ目：
件名: 部会のお知らせ
日時: 明日 15:00
場所: 第2会議室
議題: 文化祭の準備
持ち物: 筆記用具
「全然違う！」由紀が驚いた。
「内容は同じ。でも、構造化されている方が読みやすい」葵が説明した。
「これも情報理論？」陸が聞く。
「関連する。メッセージの符号化には、構造が重要だ」
葵がホワイトボードに書いた。「プロトコル設計の基本原則」
「プロトコル？」
「通信の規約。どういう形式でメッセージを送るかの約束」
ミラが例を追加した。「HTTP, TCP/IP, JSON, XML」
「全部、構造化されたメッセージ形式」葵が解説した。
由紀が理解し始めた。「形式が決まっていると、パースしやすい」
「パース？」陸が聞く。
「解析すること。構造に沿って、情報を取り出す」
葵が続けた。「人間のコミュニケーションも同じ。構造があると、理解が早い」
「例えば？」
「論文のAbstract。決まった形式で、内容を要約する」
陸が納得した。「背景、目的、方法、結果、結論」
「そう。この構造を知っていれば、効率的に読める」
ミラがメモを見せた。「Structure = Context = Compression」
「構造は文脈であり、圧縮だ」葵が訳した。
由紀が考えた。「構造があると、情報量が減る？」
「正確には、条件付きエントロピーが減る」
「どういうこと？」
「構造を知っている場合、メッセージの不確実性が下がる」
葵が例を示した。「『日時：』の後には、時刻が来ると予測できる。だから、驚きが少ない」
「驚きが少ない = 情報量が少ない」陸が理解した。
「そう。でも、それは悪いことじゃない」
「なぜ？」
「予測可能性が高いということは、誤解が少ないということ」
由紀がまとめた。「構造化は、正確な伝達のため」
「正確だし、効率的だ」葵が頷いた。
陸が新しい疑問を持った。「でも、構造が複雑すぎたら？」
「良い指摘」葵が認めた。「構造自体にもコストがある」
「コスト？」
「構造を説明するための情報。これをオーバーヘッドという」
ミラが図を描いた。シンプルな構造と複雑な構造の比較。
「メッセージが短いなら、シンプルな構造が良い」葵が説明した。「でも、長いメッセージなら、複雑な構造でも効率的」
由紀が理解した。「構造のコストを、メッセージで回収できる」
「まさに」
陸が提案した。「じゃあ、部会のお知らせ、構造化してみようか」
「いいね」由紀が賛成した。
四人で話し合う。必要な情報は何か。どう並べるか。どう区切るか。
ミラがテンプレートを作成した。
【部会通知】
日時: [date] [time]
場所: [location]
議題: [topic]
必須: [yes/no]
備考: [notes]
「これなら、誰でも読みやすい」由紀が評価した。
「そして、書きやすい」陸が付け加えた。
葵が微笑んだ。「構造は、送り手と受け手の両方を助ける」
「メッセージの構造化会議、成功だね」由紀が言った。
四人は頷いた。見えない構造が、確かにコミュニケーションを支えている。