社内wikiの階層構造を綺麗にしたい

f:id:AdwaysEngineerBlog:20201217153919p:plain

Adways Advent Calendar 2020 13 日目の記事です。


 

 いつから、私たちの社内Wikiは情報が探しにくくなってしまったのでしょう。随分散らかってしまったページツリーを目の前にしても、パッと綺麗に直す方法が思いつきません。2019年のAtlassian社 Blog記事「The Marie Kondo guide to organizing your content」 も参考になりましたが、片付けるより遥か手前、情報を作り出す段階でのドキュメントの適切な分類方法、社内Wikiでは特に階層構造の良い立て方を知りたいと思いました。

 欲しい情報を見つけやすくすることは、Wikiのユーザビリティだけでなく組織の生産性に影響する話題ですし、その中でも階層構造に目を向けた理由は、私たちが使っている「Confluence」も、多くのWikiツールと同じようにページツリーによる階層構造が主要なナビゲーションツールになっているためです。少し調べてみたところ、オライリーの『情報アーキテクチャ 第4版』に、 "情報を見つけやすく、分かりやすいものにする" ことの知見がたくさん詰まっていましたので、その中から初見の私にも理解でき、すぐに取り込めそうなものを自分たちの状況に当てはめながらピックアップしてみます。

階層構造がカオスに至るまで

 約1年半前、組織立ち上げとともに私たちが作成したwikiスペースをもとに、徐々に混沌としていく様を振り返ります。実際はもっと複雑な階層構造になっており、4階層から時には6,7階層まで辿らないといけないページもあります。

f:id:AdwaysEngineerBlog:20201217153952p:plain

 振り返ると、1年を迎えたあたりで「情報分類の手法が複数混在」し、「特定のユーザー層に対するカテゴリが増加」、そして何より、情報量が増え続けていることが情報の見つけにくさに関係しているように感じました。

 では、上述の書籍を参考に具体的な混沌要因と改善策を挙げていきます。

私たちの社内Wikiの階層構造は何がよくないのか

1.情報分類の手法がまちまちで、読み手の想像を混乱させている

何が良くないのか

 ある人は「特定の読者向け」に向けたカテゴライズを行ったり、また別の人は「重要プロジェクト」を階層として切り出し、さらに別の人が「組織の業務」で階層を切り出していく。その結果、情報分類手法が複数混在することとなり、読み手のメンタルモデルの形成(どこに情報があるかのイメージ)を阻害します。『情報アーキテクチャ 第4版』では「ハイブリッド型(ごちゃまぜ)の情報組織体系」として安易な使用には注意がなされています。

 読み手が簡単に理解できるシンプルなメンタルモデルを提示できるかどうかが、見つけやすさの力につながるため、一定の秩序が必要となります。

どうすべきか

 情報分類のモデルがごちゃまぜにならないよう、特に読み手が最初に触れる最上位の分類は十分気を配る必要があります。書籍では情報分類の種類として、「トピック(話題)」、「タスク指向」、「顧客指向」、「メタファー」、「ハイブリッド」の5種類が示されていますが、どの分類を軸とするかや無秩序なごちゃまぜは避けるなど、組織wikiの場合は情報を生み出すチーム内で分類のルールを設けるのも一案かと思います。

分類ルール(例)

  • トピック(話題、主題)による分類を基本(軸)とする。
  • トピックではなく別の手法(顧客指向やタスク指向)で分類したい場合は、一箇所に寄せて配置する。
  • 最上位に新たにフォルダを作成したい場合は、チームに一言相談する(もしくは、門番役を決めて許可制とする)

f:id:AdwaysEngineerBlog:20201217154020p:plain

 ルールをもとに、分類手法別で並べ替えしてみました。 こうするだけでも、最上位の見通しが多少改善されたように感じます。

2.曖昧なラベルによって、下位層の情報を推測できない

なぜ良くないのか

 読み手がページツリーから情報を辿るとき、階層に付いたラベル(名前)から「この下にはこういう情報があるはずだ」という想像をしながら進んでいきます。当然、ラベルの意味が曖昧で複数の可能性を示すようでは、読み手はここでも混乱してしまいます。  例えば、"組織情報"というのは曖昧なラベルの適例です。組織のどのような情報が下にあるのか、人によって「組織の指針」、「組織の変遷」、「組織で使っている技術情報」など様々な期待を持ち、そして見事に打ち砕かれます。

 多くの読み手にとって内容を理解しやすいラベルである必要が求められます。

どうすべきか

 曖昧なラベルを作ってしまう理由の多くは、①コンテンツ、②ユーザー、③コンテキストを広範囲にカバーしようと欲張るために生じると書籍では述べられています。無理やり多くの情報を押し込めることで、かえって欲しい情報を探しづらくさせているため、まずは、テーマの範囲を小さくすることを考えます。

 また、似たようなページでよく使われているラベルを借用することも、読み手の推測を手助けするため、わかりやすさに繋がります。特に社内wikiではオリジナリティ溢れる表現より、単純明快な言葉を選んだ方が多くの読み手に優しくなります。

f:id:AdwaysEngineerBlog:20201217154035p:plain

3.階層が深く、読み手が辿ることを諦めてしまう

なぜ良くないのか

 読み手にとって、深い階層をクリックして進んでいくのは単純に面倒で、道にも迷いやすくなります。各カテゴリの配下の情報は相互排他的であること(欲しい情報が複数のカテゴリに当てはまることがない状態)を基本ルールとしつつも、それを徹底するあまり、狭く深い階層構造になってしまうことが起こりえます。

f:id:AdwaysEngineerBlog:20201217154048p:plain

どうすべきか

 組織Wikiのように時間とともに情報が増えていくような状況では、広く浅い階層構造が書籍では推奨されています。ただし、理想は「狭く深い階層」と「広く浅い階層」の中庸とのこと。排他性と包含性(あいまいさを許容)とのバランスを取ると良いそうです。バランスと言われると難しく感じますね。2番目に挙げた曖昧さを避けるTipsと相反するような気もしてきます。
 この辺りは一人でベストな答えを導けるようなものでもないので、この知見をチームに共有して意見を交わしながら程よいバランスを決めて行くのが良さそうです。

 また、Wikiも階層構造だけがナビゲーションツールではなく、ハイパーリンクによる誘導や検索機能もありますから、階層構造だけで綺麗にしようとしすぎず、階層を抑える分類ができないかも工夫のしどころでしょう。

Tipsまとめ

  • 情報分類の手法をごちゃまぜにせず、秩序立った並びにする。チームでルールを設けるのも一案。
  • 広範囲なテーマを曖昧なラベルで分かりづらくするよりは、テーマを小さくすることを選ぶ。
  • オリジナリティ溢れるラベルよりは、似たようなページでよく使われているラベルを借用する。
  • 階層は狭く深くしすぎず、情報が増えていくWikiでは広く浅い階層構造を意識する。バランスを見極めるにはチームで意見を交わそう。

おわりに

 広大で深淵な情報アーキテクチャのうち、書籍を一読して理解できた部分を今回は紹介しました。当たり前のようなTipsに感じる方も多いかもしれませんが、なぜ良くないのかの理由を含めて書籍で触れられたのは私にとって収穫でした。

年末の大掃除の季節に、皆様の組織Wikiも綺麗になりますように。
今日は金谷が書きました。明日は遠藤さんの記事です。
最後までお読み頂き、ありがとうございました。

参考文献

「情報アーキテクチャ 第4版――見つけやすく理解しやすい情報設計」 Louis Rosenfeld、Peter Morville、Jorge Arango 著、篠原 稔和 監訳、岡 真由美 訳 2016年11月 発行

「The Marie Kondo guide to organizing your content」 Claire Maynard By Atlassian


 

次は遠藤さんの記事です。