「書く」ことで情報設計の筋トレを。
以前より、段飛ばしで高尚なプロセスをあれこれ学ぶよりも、ともかく基礎的なことを理解し、技能の地盤固めをすべきではないか、ということを言ってきた。
わたしの職責範囲はデザインながら、基盤はweb技術の上にあるため「ともかくHTMLの仕様を把握すべき」という理屈ではある。
ただし背景としては、HTMLはmarkup languageであり、文書設計の基礎構造が定義されているところにある。平坦な文字列に意味付け（マークアップ）できるのがHTMLであり、理解できるようになるとおのずと情報設計能力が上がっていくはずだ。
今回フォーカスしている「ドキュメント」は、最小サイズを選択できるため「基礎訓練」にちょうどいい。ドキュメントを他人が読みやすいように作るには、適切な設計がおこなわれている必要がある。
普段一番小規模で遭遇しやすいドキュメント制作においてドキュメンテーション能力を向上していけば、情報設計*1能力の向上につながるのでは？という仮説のもとの話だ。
「練習」になるのか？問題
ちなみにこの仮説は、今までその濃度は様々ながら、色々な人に話してみたことがある。
同じ目線の友人たちからは同意を得られるものの、思い返すと、説明が浅すぎたり（こちらの問題）情報設計に関する認識度合いが異なる場合（あちらの問題）にはうまいこと伝わらず、 「そんなことより有用なことがあるだろう、後にせよ」と一蹴されてしまう気配があった。
ただ1枚ペラのドキュメントだったとしても、「（他）人が読む」という前提に立った場合にはその時点でUXを意識する必要がある。文書をコンテンツとして考えると、目的は「きちんと理解し把握できる」。ドキュメントを人が読めるものにするためには、情報設計が最重要となる。
1枚とて、複数枚とて、多次元構造とて、情報を整理し人間が理解しやすくするように整備することはデザインだ。1枚への対応ができなければ、その先の難度はさらに上がるだろう。そう考えたら最小単位から克服していく方がいい。
と個人的には意義を整理（定義）してはいたものの、先述の通り賛同されづらい面もあり、そんなに主張はしてこなかった。
ところが先日そのモヤモヤを呟いたリプの最後に坂本さん（@bookslope）からこんな言葉をいただいた。
その昔、UX とドキュメンテーションについてプレゼンしてたのを思い出しました。#uxhttps://t.co/POlnLP5Luq pic.twitter.com/gWZ8Znwwye
— Takashi Sakamoto 坂本貴史 (@bookslope) 2021年8月20日
坂本さんといえば、『IAシンキング』というまさに情報設計の書籍を10年近く前に書かれた、いわば情報設計の先生。このリプをいただいて「間違ってなかったああぁぁぁ！」と感激した。
そこで次は、ドキュメント作成での筋トレの仕方について紐解いてみる。
ドキュメントには種類がある
ドキュメントの目的を見失うと、質は突然落ちる。誰に、何のため、どのように使われるのかを明確にすると、その種類が複数あることに気付けるだろう。
それぞれ整理していく方法がわかれば、的確なアウトプットができるのではないだろうか。
ターゲットユーザーを明らかにする
残念ながらきちんとユーザーを定義できていないと、どんなに頑張って情報量を増やしたところでそのドキュメントは意味をなさない。
失敗しやすい要因は、とにかく冗長な説明文や図でページ全体が長くなっていれば、ドキュメントがそれっぽくなるためだ。ただアウトプット量が長くなるだけで満足し、「完璧！」と勘違いしてしまうのだ。
その時足りていないのは、「一体誰のために書いているものなのか」という視点。複数の人に向けて未整理のまま雑多にドキュメンテーションをすれば、そりゃ長くなるだろう。
いざ対象者が「知りたい」と思ったタイミングで情報を探すも、全く無関係な情報が溢れ返り、目的の内容を得られない。それではドキュメントとしては無意味になる。
誰に向けて書くのか、をまず定義するのが重要だろう。
何のためにまとめるのか
次に必要となるのが、なぜそのドキュメントをまとめるのか。こちらでも結局「誰に」の視点が関係してくる。
調査結果なのか、提案なのか、会議のアジェンダなのか、あるいはただのメモなのか、議事録なのか、仕様書なのか。
こちらも混在させてしまうと、突然ドキュメントが死ぬ。
最近個人的に特に気になっているのが、アジェンダを用意できないケースあるいは、アジェンダの意味を取り違えているケース*2。
アジェンダというのは、
- 会議の内容を予測し
- 参加者が理解しやすいように順序立てて説明し
- その会議の目的を達成する
ために作成する。いわばファシリテーションのベースとなるものだ。つまりドキュメントを用意すると見せかけ、実は会議の骨子作りと下準備をおこなっているはずだ。
失敗ケースとしては、会議主催者の「話したいこと」だけ箇条書きしているアジェンダ。他のドキュメントをかき集めればアジェンダの中身は揃うが、残念ながら会議の設計はしていない。そのため、どれだけの時間がかかるのかも把握できないし、何のために会議するのかも主催者も参加者もわからない。結果的に会議は破綻してしまう。
準備と脳内ロールプレイとしてアジェンダを利用することで、万一会議の内容が前後する場合などでも、全体をファシリテーターが把握できているため、リカバリーしやすくなる。
少し話はズレたが、やはり「何のためにまとめるのか」という話につながる。
いつどのような目的で「使われる」ものなのか
最後にもう一つ。参照されるシーンをあらかじめ想定しておく必要がある。
ドキュメントはその性質上、時差で取り扱われる。結局のところやはり、「誰が何のために」参照するドキュメントなのかまで明確にして作ると、成果物の齟齬が生じなくなる。
更なるポイントは、利用者が自分であっても「時間が経ったら自分は他人」という点だ。「自分だったらここは省略してもわかる」という前提を捨てる必要がある。
ある種、客観視点を無理矢理にでも持っている必要があるということだ。都度内容を自身でレビューすることで、結局、他人でも理解できるドキュメントが出来上がる。
たかがドキュメント、されどドキュメンテーション
前項の各内容で察する人もいるかもしれないが、概ね5W1Hを言っている。
その上で、中身の構造については最初の話に戻る。的確にマークアップをしていく必要がある。
読みやすい、理解しやすいとはどういうものかを考えると、HTMLの構造なのでは……とわたしは考える。
何故ここでHTML？と反論される方もいるかもしれない。ただしよく考えてほしい。インターネットができて以来、ただただ文書をマークアップするためだけに磨かれてきた技術がHTMLであり、わかりやすく整備され続けて体系化されてきた仕組みだ。
編集や辞書編纂技術を参照して、自身のドキュメントを設計してもいいと思う。ただそれよりHTMLの方がよほど我々には身近なのではないだろうか。
マークアップは全体構成までは担保しきれない側面もある。最後にやはり客観視点を取り入れ、全体を俯瞰して「きちんとこの文書は、ターゲットユーザーが理解できる流れになっているのか？」の確認も重要だ。
過去に登壇した、Webアクセシビリティの学校 オンライン特別授業でも「デザイナーであれば持っている技能を使って組織構造をデザインしてみてはどうか」という提案をした。
今回のケースもまさに同じ話で、せっかく持っている「設計技能」をドキュメンテーションに活かしてはどうだろうか。また、小さなことからコツコツと、おこなっているのはドキュメント制作ではなくUX設計だとでも思えば、構造設計方法が変わるのではないだろうか。
たかが1ページのドキュメントであっても、webサイト制作やUI設計の基本概念と規模の差はあれ、やっていることは変わらないはずだ。最小単位のドキュメンテーションで筋トレを進めれば、いつかは大規模なものの情報設計もさっくりと進められるはず、とわたしは思っている。
