「運用しているドキュメントが漠然と使いにくい」

「ページが増えるたびに配置先カテゴリに悩む」

「欲しい情報は検索機能でだいたいヒットさせられるのでオッケー」

そんなプラットフォームエンジニアのあなたには、ぜひ『情報アーキテクチャ 第4版』（オライリー・ジャパン）を読んでほしい。

ドキュメントのUXも我らの責務

我々プラットフォームエンジニアは、分散システムのアーキテクチャやインフラの運用など、放っておけばバックエンドエンジニアリング寄りの分野にばかり力を入れがちで、オライリーの薄紫色のシリーズ（UX系の本が集まっている）などは素通りする人生なのではないだろうか¹。

もちろん我々は、自分たちの仕事がプラットフォーム基盤を構築・運用することだけではないことはわかっている: 守備範囲は、社内顧客向けの利用ガイドやポータル、自チームのための運用ガイドなどの整備・運用にも及んでいる。 こうした情報システムは、各ページの文章をわかりやすく書けばOK、というものではない──利用者が必要なタイミングでコンテンツにたどり着けなかったり、使い勝手の悪いサイトをイライラしながらブラウジングしているようであれば、役立っているとはいえない。

『プラットフォームエンジニアリング』でも、プロダクトアプローチに基づいてUXを設計することの重要性は指摘されているが、一方で、私が知りたかった「ドキュメントの構造や情報の発見可能性をどう設計するか」については、具体的な解説がなかった。 どうやればよいかわからないので専門家チームに丸投げしたい気も起こりそうになるが、我々プラットフォームエンジニアが作るような社内向け製品には、専任のUXデザイナーやテクニカルライターを割り当ててもらえないことも多いのではないだろうか。 そんな状況では、情報システムのUX設計もプラットフォームエンジニアの責務である。

私自身、実務で利用ガイドや運用ガイドを整備する中で、自分たちのドキュメントのUXがよくないことを漠然と感じていたものの、改善策としては文章の改善や配置場所の再考など、自分が思いつく範囲での対症療法しか選択肢になかった。 しかし本書『情報アーキテクチャ 第4版』を読んだことで、我々のドキュメントに必要なのは小改善の積み重ねではなく、情報アーキテクチャその見直し（というか初検討？）による根本治療であることに気づくことができた。

本書は情報システムのUX改善方法を模索するプラットフォームエンジニアにとっても（←大事）広く有用と言えそうなことがわかったので、本記事で紹介する。

なお本書は勤務先の会社のSLP（Self Learning Program）という仕組みを利用して購入した。

私が本書から得たもの

情報探索行動についていかに無頓着だったかの自覚

本書を読んでまず痛感したのは、情報探索という行動を、いかに単純かつ楽観的に捉えていたかということだ。

検索機能一つとっても、「ナビゲーションのクリックなしにあるページに到達する手段」程度にしか捉えていなかった。 そんな程度の認識だから、まして利用者自身が、自分が何を探しているかわかっていないケースなど考えたこともなかったし、typoを含む検索クエリに対してGoogleが “もしかして:” を表示することを知りつつも、それを自分のシステムでも提供しようと考えたことはなかったし、検索語の絞り込み体験について読めば「確かに使ったことあるな」などとエンジニアとしてあるまじき感想まで漏れてしまった。

そういった機能めいたもの（というか明確に機能）は、「検索サービスを作ろう」というモチベーションでメインプロダクトとして開発するときに使うものだと、無意識のうちに自分が考慮すべきものの範疇から外してしまっていたような気がする。

しかし本書を読み終えると、こういった機能は、情報システムのUXを追求するうえでもはや情報の整理法と不可分なもの、つまり「情報アーキテクチャ」の一部を構成するものであることがわかる。

どんなものが設計対象となるのか

上で少し述べたが、そもそも何が「情報アーキテクチャ」として設計対象になるのかを知ることができたことも大きい。 良いUXの実現には、情報の分類や階層構造だけでなく、ラベル、ナビゲーション、検索システム、メタデータの整備など、利用者が情報を理解し、発見するための仕組みを様々な解像度・観点から設計する必要がある。 このような上位設計のないまま進化してきたドキュメントシステムが使いにくいのは、いわば当然のことだ。

「ラベリング」の解像度

これまで「ラベリング」といえば、「タグの同義語」程度にしか思っていなかった。 しかし本書では、ページの見出しやナビゲーション項目、インデックス用語など、利用者に情報の意味を伝えるためのさまざまなラベルが設計対象として扱われている。

特に印象に残ったのは、個々のラベルのわかりやすさだけでなく、ラベリングシステム全体の一貫性が重視されていることだ。 名前を一つひとつ考えるだけではなく、情報環境全体でどのような語彙や命名規則を使うかまで、注意深く設計する必要がある。

本書を読めば、「ラベリング警察」になれること間違いなし。

自システムに対する固定観念からの解放

本書で紹介されている情報探索体験について一つずつ学ぶことで、自分達が運用するドキュメントに対する固定観念──昔から使っているドキュメントサイトだからこういうものだ──があったことを自覚した。 これは、「情報アーキテクチャ」という枠組みとセットで学んだからこそ意味があるわけであって、もし単に「絞り込み検索ができたらいいよね」とか「ファセット検索を提供しよう」などと思いつきで機能を追加していったとしたら、フランケンシュタインの魔改造に陥るに違いない。 これは分散システムにもいえることだが、優れた体験は、根本の設計思想と、そこから導かれるアーキテクチャによって支えられている必要がある。

自ら考えるしかないということ

本書を読み終わって、結局のところ、自分たちの情報システムの情報アーキテクチャについては自分たちで考え、自分たちで設計するしかないということがよくわかった。 情報アーキテクチャを考えるうえで重要な「ユーザー・コンテンツ・コンテキスト」は、当然ながら情報システムによって全く異なる。 情報アーキテクチャとは、本書で紹介されている手法をカタログから選んで組み合わせるようなものではなく、利用者にどのような情報探索体験が提供されるべきかを自ら考えたうえで、独自に設計しなければならない。

まとめ

書籍の紹介としてはごく表面的にしかしなかったが、情報システムのUXをなんとかしたいプラットフォームエンジニアの方は、ぜひオライリー『情報アーキテクチャ』を読んでみてほしい²。 本書は実装技術を深掘りする本ではないが、これまで意識していなかった設計対象や、利用者の情報探索を捉えるための概念・視点を得られると思う。

書き終えてふと思ったが、そもそも私にとっては、自分の探していた情報を「情報アーキテクチャ」という用語のもとで体系的に学べることを知ったこと自体に価値があったのだと思う。 この言葉を知らなかったら「ドキュメントサイトの使いやすさを根本的に改善」みたいな表現で情報を探すことになっただろうから。

本書は概念や観点をインプットするのに役立った。 一方で、より具体的な実践については『エンジニアのためのドキュメントライティング』が良かったので、別の機会に紹介したい。

気になった箇所の読書メモ

以下は、本書を読みながら気になった箇所についての個人的メモ。

第1章 情報アーキテクチャが取り組む課題

P.21 情報アーキテクチャとは

情報アーキテクチャはアプリ、Webサイト、音声インターフェースなど、個々のアーティファクトが内部で機能する体系的意味論の定義に取り組みます

この文はわかりにくかった。

大意は概ね下記ようなものと理解している:

情報アーキテクチャは、個々の画面やWebサイトをうまくデザインするだけでなく、そもそも「情報がどのような意味を持ち、どう関係し合い、どのような仕組みで利用されるべきか」を設計する分野である

第2章 情報アーキテクチャの定義

p.26 なぜ情報アーキテクチャを一語で言い表せないか

これは本書を読み終えてみると理解できた。 情報アーキテクチャを一言で言い表すのは無理だが、「一言で言い表せない理由」については一言で言い表せるかも。 「目に見えない情報の構造にはじまり、ひいては人間がその意味をどう理解するか、についてまで幅広く扱うから」でどうだろう。

p.33 ユーザー・コンテンツ・コンテキスト

これら三概念の重要性は、ちょうど直前に『エンジニアのためのドキュメントライティング』を読んでいたので、改めてつながった感覚がある。

第3章 見つけやすさのデザイン

p.44 検索とブラウジング

情報が存在するのを知っている上での検索と、未知の情報のブラウジングは、まったく異なる行動

言われてみれば当然なんだが、ユーザーストーリーを考えるうえでの観点をもらえた。

p.45 図3-1 シンプルすぎるモデル

ユーザーが質問する→何かが起こる→ユーザーは答えを受け取る→終了

馬鹿馬鹿しいほど楽観的なハッピーパスだが、自分がこれまで作ってきた検索機能（システムというほどでもない）が、要はこのモデルでしか考えていないものだったことを自覚して深く反省した。

p.47 安易なUX計測に対する警鐘

…私たちは「情報を見つけるエクスペリエンスは、『正しい』答えを見つけるまでにかかった時間やクリック数、ページビュー数で測定できる」と考えていますが、たいていの場合はその『正しい』答え自体が存在していないのです

…反省した。

p.48 魚獲りのメタファー

一見斬新だが、的を射ている。 要は、情報の探索行動には、性質がまったく異なる様式が少なくとも4つあり、それぞれに対して提供すべき解決策も当然ながらまったく異なるということ。

第4章 理解のためのデザイン

p.63 ポーチが意味するもの

個人的エピソードとして、過去にAlexanderの『パタン・ランゲージ』を読んでもあまりピンときていなかったのだが、、本書のこの部分を読んでやっとスタート地点に立てた。 言われてみれば確かに、ポーチが全くなければ、どのドアが建物にとって重要なもの（入り口）なのかはわからない。 当たり前すぎて気づいてなかった。

p.81 情報環境を場所として体験

取引、学習、そして他の人々とつながるなど、さまざまな活動において、私たちは情報環境を場所として体験しています

ドキュメントを書いていると、ユーザー行動を表す動詞としてついつい「読む」を前提としてしまうが、この視点も忘れないようにしたい。

第5章 情報アーキテクチャの解剖学

p.86 見えないことこそ成功のしるし

うまく設計されている情報アーキテクチャはユーザーには見えません（逆説的ではありますが、見えないことこそが情報アーキテクチャが成功しているしるしという、報われないごほうびなのです）

なるほど、情報アーキテクチャもそういう類いのものなのか。 インフラやプラットフォームと同じ。 よい文章と同じ。

p.91 ボトムアップ型情報アーキテクチャ

ちょっとわかりにくいが、要はページに死角をなくすということ。

p.94 情報アーキテクチャは目に見えないことが多いもの

最初にここを読んだときは理解できなかったが、p.94まで読み進めて「検索アルゴリズム」が入っていたことによってやっと理解できた。 情報アーキテクチャに含まれるものについて、例えば下記のような整理で例示するとよいと思う:

• 見えるものの例: 画面のナビゲーション、メニュー、ラベル
• 見えないものの例:
  • 具体的なもの: メタデータのスキーマ、分類体系、制限語彙、シソーラス
  • 抽象的なもの: 情報の概念モデル、カテゴリ間の意味的関係、情報の組織化原則

p.98 検索サポート手段

「検索ゾーン」は確かに重要だ。 ユーザーペルソナに合ったサイト構造を考えるうえでも参考になる。

第6章 組織化システム

p.108 整理軸は人によって異なる

使いやすい組織化システムを設計するには、自分のメンタルモデル（mental model）でコンテンツのラベリングや組織化をすべきではない

肝に命じておくべき教訓だろう。

p.110 組織内政治

設計者は、組織構造の政治的環境に敏感でなければなりません。場合によっては、ユーザーのためのアーキテクチャ作成という主旨について、同僚に根回しする必要もあるでしょう。…（中略）…しかし、政治的なことも理解しておけば、それがアーキテクチャに及ぼす影響をコントロールすることもできます

「現実」が書いてある！

p,125 階層の設計

情報アーキテクチャが扱う範囲は広いとはいえ、やはりここが出発点として適している。

p.126 深さと幅のバランス

何事もバランスは常に悩みどころだが、webサイトの場合にはユーザーやコンテキストによる分割が可能ならば、ある程度難度を下げられると思われる。

ちなみに、将来的に拡張が予想される場合には「広く浅く」のほうがよいとのこと（p.128）。

p.138 個々の良いものをただ合わせただけではだめ

全体像を見落とさないようにすることも重要です。 料理と同じく、適切な材料を正しい方法で混ぜ合わせた時、初めて求めていた結果が得られるのです

情報アーキテクチャは宿命的にカスタムメイドになるということ。 「最高のUXを提供するレシピ」はまぁ論外として、「最高の情報アーキテクチャの創り方レシピ」みたいなものを見ながらポチポチかんたんに構築できるようなものではない。

第7章 ラベリングシステム

p.143 ラベルの作成に全力を注ぐ

多くの場合情報環境は、システムの所有者と作者のメッセージをユーザーへとゆっくり翻訳して伝え、また元に戻す仲介メディアなのです。この「伝言ゲーム」のせいでメッセージがあいまいになってしまいます。…（中略）…相手と直接向き合えないという欠点を最小限に抑えるために、情報アーキテクトはラベルの作成に全力を注がなければなりません

なるほど「全力を注がなければ」とまで言われるようなものなのか。

ちなみにオライリー・ジャパンの正誤表には載っていなかったが、下記の部分は恐らく誤植:

「このページで目立っているラベルは自分が見ても突出した印象を受けるのだろうか？もしそうなら、それはなぜだろう？」

正しくは「このページで目立っているラベルは自分以外の人が見ても突出した印象を受けるのだろうか？もしそうなら、それはなぜだろう？」だと思われる。

p.150 裸のバンジージャンプ？

「裸のバンジージャンプ」という語のパワーが強すぎて文意が頭に入ってこなかった。 要は、ラベルは役割という軸で何種類にも分類できるが、その分類は排他的ではないし、もっといえばまったく同じ文字列をまったく異なる役割のラベルとして使うこともできる、ということ。

p.157 絶対数よりも一貫性

たとえ選択肢が10以下のナビゲーションシステムでも、一貫しないオプションがひとつあるだけで1,000以上のインデックス用語よりもあっという間に雑多なものになってしまう

ナビゲーションシステムはサイトに繰り返し登場するので、ナビゲーションラベリングの問題は拡大されて広がります

なるほどすぎて、足すべき言葉もない。

p.160 インデックス

インデックス用語は人がコンテンツの意味を確認して表現したものなので、単純に検索エンジンで全テキストからクエリーと合うものを探すより、インデックス用語を検索したほうがより効果的なは ず

なるほど。 逆に言えば、その文字列で検索してもヒットしないようなインデックスもあり得るし、利用者が内容を想起しやすいようなラベルをインデックスにすべきということか。

p.166 一貫性のあるラベリングシステム

「スタイル」のところにある句読法について、日本語だとあまり句読法って意識されないような気がしていたけど、明治に文部省から出ていたらしい:

「構文法」については、日本語だと「語尾の形を揃える」と表現されるだけのケースが多い気がする。 英語は、こういった論述技法の解像度が高いとつくづく思う。

p.168 ねじれた文

下記の文は主述がねじれていて意味がわからなかった:

既存のラベリングシステムを詳しく調べる主な利点は、それらがシステムだからだということを覚えておいてください。あまりにも奇妙で雑多なラベルで、ひとつにまとめてもうまくいかないシステムなのです

上記が意味するところろはたぶん「既存のラベリングシステムを調べる最大の利点は、個々のラベルだけでなく、ラベル同士の関係や体系全体を参考にできることです。ラベリングシステムは、雑多なラベルを寄せ集めただけではうまく機能しません」みたいな感じだろう。

第8章 ナビゲーションシステム

p.199 グローバルナビゲーション

グローバルナビゲーションバーはサイトにおいて、唯一の首尾一貫したナビゲーション要素であることが多いため、利便性という点で大きな影響力を持っています。 そのためユーザー中心の設計となるよう、徹底して繰り返しテストを行うべきです

ハイ。

p.204　サイトのすべてのページがメインページと思え

コンテキストナビゲーションシステムを設計する場合、サイトのすべてのページがメインページ、あるいは独自の目的を持ったポータルであると考えてください

学びたての用語で言い換えるならば「ボトムアップ型情報アーキテクチャ（p.91）を洗練せよ」ということだろう。

p.208 サイトマップ

サイトマップって、いちユーザーとしてはよく見かけるけど、エンジニアとして自分が関わるシステムだとなぜか考慮から抜けてしまっていた。 確かに必要だ。

p.212 「最適の結果」？

下記の文の意味がわかりにくかった:

もうひとつの面白い例が図8-20に示したミシガン州立大学のサイトインデックスで、最適の結果をアルファベット順のリストで表示しています

上の文はおそらく、インデックスにはただ機械的に生成された語ではなく、利用者にとって有用と思われるラベルが並ぶようになっている、ということだろう。

また、下記の部分は日本語としては問題ないのだが、意図するところがわかりにくかった:

それに対して、コンテンツ管理が分散している大規模なサイトでは、ドキュメントレベルで制限語彙インデクシングを利用し、サイトインデックスを自動的に作成すればよいでしょう

こちらはおそらく、単一の記事ページのような、一般には自由記述しがちなコンテンツにも、制限語彙を利用してインデックス作成に役立てるという意味だと思う。

第10章 シソーラス・制限語彙・メタデータ

p.327 並行階層

いわゆる「コウモリ問題」の解決策の一つだが、「並行階層」という用語があることを知った。 というか、コウモリ問題の解決はタグだけだと思っていた。 タグと並行階層、2種類の実装手段を持っていることは、よい情報アーキテクチャを実現するうえでより柔軟な設計ができるようになると思われる（そのぶん管理コストも上がる）。

p.331 ファセット

もちろんいちユーザーとしてはこの検索体験は知っているのだが、自分が関わるシステムとなるとなぜか考慮から抜けてしまっていた。 そもそも「ファセット」という用語を得たことが大きい。