ハクソク

世界を動かす技術を、日本語で。

どんな混乱も理解する方法

245日前原文(howtomakesenseofanymess.com)

概要

  • 本書は 情報アーキテクチャ の基本を、現実の「混乱」から整理するプロセスで解説
  • 各章は 実践的なフレームワーク や図解ツールを紹介
  • 人・情報・意図・現実 の複雑性を理解し、明確化する方法を提示
  • 言語や構造 の選択が成果に直結することを強調
  • 様々な事例やワークシートで 読者自身の課題解決 をサポート

本書について

  • 情報アーキテクチャ の基本概念と実践手法の解説書
  • 混乱（Mess） の正体を明かし、整理するプロセスの提案
  • 現実 と 意図 のギャップを埋めるための思考法とツールの紹介
  • 人間・組織・情報 の関係性への洞察
  • 実例 や ワークシート で学びを促進

第1章：混乱を特定する

  • 混乱 は 情報 と 人 で構成
  • 問題の可視化が難しい現実
  • 情報アーキテクチャ は日常の至る所に存在
  • 物事は変化しても、 混乱 は形を変えて残る
  • 人 が情報を設計する役割
  • あらゆるもの・知識・情報の 複雑性
  • 情報 は データ や コンテンツ とは異なる概念
  • 情報 は目的に応じて設計される
  • ユーザー や ステークホルダー も複雑な存在
  • 行動＝知識 という理解
  • Carl の事例紹介
  • 読者自身の「混乱」を図式化するワーク

第2章：意図を明確にする

  • 意図 は 言語 で表現
  • 「良い」とは誰にとっての良いか
  • 見た目 と 本質 の違い
  • 意味 が伝達過程で失われる可能性
  • 関係者 の特定が重要
  • 「なぜ」 から始める思考法
  • 「何を」 が「どうやって」より先
  • なぜ・何・どう の相互関係
  • 言語 が意図を形作る材料
  • Karen の事例
  • 意図 を宣言し、適切な言葉を選ぶワーク

第3章：現実に向き合う

  • 現実 を直視することで解決策を発見
  • 多様な 関係者 ・ 要因 が絡む現実
  • チャネル や 文脈 を横断する現実
  • 既存パターンに当てはまらない状況
  • オブジェクト を用いた現実の深掘り
  • スコープ と スケール の設定
  • 時間軸・レトリック・設計順序の重要性
  • 図解ツール （ブロック図・フロー図・ガントチャート等）の活用
  • Maggie の事例
  • 自分自身の現実を 図解 するワーク

第4章：方向性を選ぶ

  • 「なぜ」から「何を」 への移行
  • レベルごとの作業 とその相互影響
  • 「何を作るか」 の明確化
  • 場所 や 空間 を設計する意識
  • 言語不安 の解消
  • オントロジー （概念体系）の理解
  • 既存の オントロジー の活用
  • 「設計する」のではなく「共に設計する」姿勢
  • 使う言葉・使わない言葉 リストの作成
  • 外部の人向けに 用語定義
  • 過去の理解 と 名詞・動詞・関係性 の整理
  • 意見 と 選択肢 の違いに注意
  • Rasheed の事例
  • 語彙管理 と方向性決定ワーク

第5章：距離を測る

  • 現実 と 意図 の間にある距離
  • 目標 が世界を見るレンズ
  • 進捗 と 成功 の両方の測定が重要
  • 指標 による進捗管理
  • よく使われる 指標 の紹介
  • ワークシート を使ったデータ収集
  • ベースライン による現実把握
  • フラグ で進行方向の確認
  • 測定 のリズム感
  • 曖昧さ も通常の一部
  • Jim の事例
  • 目標設定 と 距離測定 ワーク

第6章：構造で遊ぶ

  • 構造化の 多様な方法
  • タクソノミー （分類法）の役割
  • 複数の タクソノミー の組み合わせ
  • 分類 の方法を決めることの難しさ
  • 分類 の明確性と曖昧さのトレードオフ
  • ファセット （分類軸）の特定
  • 人間の 複雑性 と分類の関係
  • 階層型・非階層型・順序型 のタクソノミー
  • ハイパーテキスト による構造の橋渡し
  • 多くのケースで 複数の分類法 が必要
  • Joan の事例
  • 構造化パターン の学習

第7章：調整の準備

  • 調整 は現実の一部
  • 全体最適 の重要性
  • 一人での合意形成の容易さと、議論の必要性
  • 本質 が見えない場合の注意
  • 複数の「主」の存在
  • 情報アーキテクチャ の居場所を確保
  • 「素晴らしいIAだね！」と言われない現実
  • フィルター役 としての自覚
  • 難しさ と やりがい
  • Abby の事例
  • ここまでの内容の 振り返り

Hackerたちの意見

ランダムな単語のハイライトがあって、読むのが難しいんだよね。

└

そうそう、3単語ずつ並んでるのは本当に最悪だよ。

└

これが混乱を整理する手助けになってるんじゃないかな。スタイルを乗り越えられれば、どんなことでも乗り切れるって感じ。

└

これは絶対にオンオフできるオプションが必要だよね。

└

今のところそれほど気にならないけど、ハイライトを消すためのChrome拡張を作ろうかなって考えてる。

└

本の最初の方に書いてあること: 「ハイライトされた単語を見るたびに、[...] その用語はレキシコン対応の用語であることを意味します。その用語をクリックすると、本の中でその用語が使われている他のすべてのページが表示されます。」

└

Stylebotみたいなのをインストールしているなら、ハイライトを消すには: a { background-color: transparent; } と書けばいいよ。

└

これがブックマークレットだよ: javascript:document.querySelectorAll('a').forEach(el => el.style.backgroundColor = 'transparent')

アビーは素晴らしい人で、2010年代初頭のNYCのUXや情報アーキテクチャのシーンでの古い友達なんだ。彼女の本は最高だし、他の人が言ってるように、ホームページは目次だけだよ。ぜひ買ってみて！結局、混乱はステークホルダーのために役立つように自分で整理するものだからね。

フィンテックで20年近く、いろんな銀行やヘッジファンド、スタートアップで働いてきたけど、これにはすごく共感できる。例えば、クリティカルパスやフローダイアグラムは、何が直列で、何が並行でできるかを整理するのにめちゃくちゃ役立つ。でも、ほとんど使われてるのを見たことがなくて、使われるときは大体俺が作ったときなんだよね。重要なプロセスがドキュメント化されてないから、みんながどう直すべきか意見すら言えない。あるプロセスをドキュメント化したとき、みんながステップ4が間違ってるって同意したんだけど、驚いたことに、ステップ4が実際に何かについては誰も同意しなかった。プロジェクトについての大きな議論は、「何をすべきか」よりも「いつ欲しいか」が多い。例えば、一方は来週欲しいけど、もう一方はもっと機能を追加したいから時間がかかるって感じ。俺はよくこのメタファーを使って対処してる。「ああ、じゃあ2週間ごとに引っ越ししたいってこと？6ヶ月あれば、世界一素晴らしいウィネベーゴやRVを、ジャグジー、衛星テレビ、クイーンサイズのベッド、エアコン付きで作るよ。明日欲しいなら、手押し車と枕、iPadをあげるよ。」

└

ありがとう。この一つのコメントがページそのものよりも価値があったよ。

└

クリティカルパス/フローダイアグラム [0] は、何が直列で何が並行化できるかを整理するのに非常に役立つ。ただ、実際にはほとんど使われているのを見たことがない... 技術的に良い決断をすることは、権力を持つほとんどの人たちに対して、ほんの少しでも試みるだけで大きく前に出られる分野の一つだ。誰もがほとんどやらないいくつかの高度な技術: 「これは良いアイデアだという証拠はある？」 「過去の経験と他の人がやったときに何が起こったかを確認した上で、この行動の最も可能性の高い結果を達成できると仮定したら、これは良いアイデアなのか？」 [0] 「今やっていることを続けたら、12ヶ月後にどこにいるだろう？」 [0] 誰か、次回アメリカの主流の議論でこれを戦争を始めようとしているときに取り上げてくれ！

└

物事が何であるかについて人々がどれだけ意見が分かれるかは、本当に驚くべきことだ。ある会社で、ユーザーリテンションの定義を12から4に減らすのに数週間かかったことがある…

└

フローダイアグラムって、めっちゃ使われてないよね。

└

これ、私もよく見かけるけど、特定の会社文化の中だけなんだよね。共通の問題は、中堅以上の管理職の人たちが混沌の中で生き生きとしていること。重要なことがしっかり文書化されたり安定したりするのは嫌みたいで、それが彼らの「重要な人」としての機会を奪うから。何かが壊れたとき、他のチームには手が届かないようにして、ヒーローとして登場したがるんだよね。奇妙なことに、そういう人たちが文書化を推進して、他のチームの仕事が文書化されてないって理由で妨害しようとすることもある。まるで自分たちがプレイしているゲームを理解しているけど、問題を引き起こしている側ではなく、問題に立ち向かう人たちのイメージを持ちたいみたい。さらに、他のチームに自分の仕事を文書化させることで、ヒーローとして登場して問題を解決するのが簡単になるんだよね。

└

クリティカルパスやフローダイアグラムを作るのに使えるソフトウェアって何がある？

俺が気づいたのは、混乱や複雑さって、しばしばだけどいつもじゃない、ただの騒がしい情報の流れだってこと。質の低いデータの大量に基づいて決断しようとすると、世界が信じられないくらい複雑で、常に変わっていて自己矛盾しているように感じる。信号対雑音比を改善できれば、ずっと管理しやすくて理解しやすくなるよ。昔、企業アーキテクトと一緒に働いたことがあったけど、彼は「この複雑で常に変わる情報の風景の中で」という言葉から始まらないことは何も言えなかった。あなたがこの複雑で常に変わる情報の風景を作り上げたんだよ、サー。それは、あなたの六角形のアーキテクチャやマイクロサービス、Kubernetesクラスターから成り立っている。

俺の経験では、一つの混乱はかなり単純だけど、厄介なのは相互に関連した混乱だ。システムAが最優先の修正で、システムBの一部をシステムAに組み込みたいんだけど（本来はBにあってはいけないもの）、それをシステムAに移すと、システムBの他の部分が壊れちゃう（だからそれを修正する必要がある）し、さらにシステムCも動かなくなるから、それを修正しなきゃいけない、って感じで、どんどん続く…

これにはちょっと混乱したけど、これはただの目次で、各章の文はリンクになっているって気づいた。明らかにハイパーリンクのスタイルにはなってないんだよね。

└

おお！ありがとう、全然わからなくて、なんか変な意識の流れみたいなものかと思ってた。

いつも頼りにしてるテクニックは、依存関係グラフを作ることなんだ。会議では昔はyuml.comを使ってたけど、今はmermaidを使ってる。テキストと矢印を打ち始めるだけで、リアルタイムで何が何に依存してるかが表示されるんだ。ライブミーティングでは、問題がどこにあるのかをみんなに集中させるのに役立つし、ドキュメントでは、ここを変えるとあそこに影響が出る理由を示すのにいいよね。yumlもmermaidもレイアウトのコントロールはできないけど、それが逆にいいところだと思う。レイアウトエンジンがきれいな図を作れるってことは、依存関係がそれほど複雑じゃないってこと。でも、グラフがひどくて複雑に見えるなら、システム自体もやっぱりひどくて複雑なんだろうな。

└

レイアウトコントロールがないことが隠れた強みだってのには完全に同意だよ。グラフがスパゲッティみたいになってるのはツールの問題じゃなくて、システムの問題なんだよね。

└

他の人の混乱を避けるために言っておくけど、yuml.comじゃなくてyuml.meだよ。UMLダイアグラム作成ツールだから。

パイロットの意思決定プロセスを思い出すな。- 状況: パイロットは現在の状況を認識し、可能な危険を特定する必要がある。これは意思決定プロセスの中で最も重要なステップで、状況を正確に把握することで、正しいプロセスを始めるための重要な情報が得られる。- 選択肢: 成功の可能性に関わらず、あらゆる選択肢を生成する。できるだけ多くの選択肢を作ることが重要で、それによって状況に最も適した解決策を選ぶための選択肢が増える。- 選ぶ: 生成された選択肢の中から、リスクと実行可能性を評価して行動を選ぶ。- 行動: 安全と時間の余裕に従って計画を実行する。このプロセスで最も重要なのは時間で、パイロットは状況がさらに悪化する前に問題を解決するために時間との戦いを強いられる。- 評価: 「選択した行動は成功したか？」と問いかけ、今後の発生に備えて計画を評価する。

└

パイロット訓練から借りられる良いコンセプトがたくさんあって、ほとんど馬鹿げてるよ。自分はパイロットじゃないけど、リスク管理やクルーリソース管理、意思決定なんかを勉強したことがある。もちろん anecdotal だけど、プロジェクトや問題に対処するのにかなり大きな違いがあったと思う。

ウェブサイトがめちゃくちゃで、特にレイアウトが変に「ずれてる」せいだと思う。テキストが多くの行で端まで行くのにちょっと横スクロールが必要なんだ。人々がウェブ上のテキストの標準的なデフォルトレンダリングを壊すためにどれだけの手間をかけるのか、全然理解できない。ここには良いアイデアがあるかもしれないけど、モバイルでの表示はほぼ使えないよ。

└

本当にそうだよね。普通のHTMLを使ってれば、読みやすいテキストラインになったはず。ウェブデザイナーがやるべきだったのは、「わざわざ悪化させるようなことをしない」ことだけだったのに。

歴史によってデザインされた vs 意図によってデザインされた --- 昨年、レガシーコードベースで作業しているときに、自分に何度も言い聞かせてたんだ。「彼らは動かすことができたけど、合理的には作ってない。」