理想的なサイトマップの形と標準書式

第24回WebSig会議「100人で考える、理想的なサイトマップの形と標準書式」に参加してきました。

当時の模様は、公式サイトのエントリーでご覧いただけますしTwitterでも中継 (?) されていたようで「buzztter」で見ることができます。ミクシィでも感想トピックスが立ち上がっているようです。

• 第24回WebSig会議「100人で考える、理想的なサイトマップの形と標準書式」　終了いたしました (WebSig24/7)

また、当日のスライドもSlideshareで公開されています。

第24回WebSig会議「100人で考える、理想的なサイトマップの形と標準書式」 View more presentations from websig.

この中での課題定義については、以前gihyo.jpで書いていたエントリー「サイトマップと情報の構造化」も参考にしていただけたようで、以下のように定義付けをされていました。

サイトマップとは
Webサイトに掲載する情報を組織化し、その論理的な構造をツリー図として表現した資料。画面遷移のフローチャートとして使用できるように情報が付加されることもある。
ワイヤーフレームとは
画面に表示する要素とその配置を簡潔にまとめた資料。ユーザーの操作に対するシステムの反応やインターフェースの振る舞いも定義する場合がある。
ファイルリストとは
Webサイトを構成するファイルの一覧。列記する項目としては最低限、画面名（または識別子）、ディレクトリパスとファイル名（物理的な構造）、URLを含む。

今回の課題は「サイトマップ」だったのですが、やはりウェブサイト構築をする上ではそれだけで完結するものでもなく、ファイルリストなども十分に関係してきます。

ここでも「ワイヤーフレームコミュニケーション研究会」のエントリーでも書いたように「前提を揃える」ことが大切になってきます。そういう意味では前提としていくつか条件があったので取り組みやすかったと思います。

提出した課題

1. ボキャブラリーの標準が浸透していないため表記がバラバラ
   
2. 論理構造なのか物理構造なのかが混在してしまうケースがある
   
3. システムフローと同等の成果物と思われることがある
   
4. すべてを網羅しようとするとA3におさまらない
   
5. 運用上の更新はすべきか、誰がすべきか
   
6. 後工程でどう使うかがわからないとどこまで必要かがわからない
   
7. 結局お客さんはサイトマップを見てもわからない
   
8. 画面IDと連動するシステムがない (ソフトではあるものもあるが)
   
9. コンテンツ管理と連動しようとするとCMSが必要になる
   
10. アセット管理や素材管理と連動したくなる

参加したグループでは以下のようなことをまとめていたと思うので思い出しながら書いておきます。

課題1 (比較的静的なウェブサイト) について

必要な情報

主によく検討する情報としては以下のようなものが必要になるかと思います。

• 識別子 (枝番IDやラベリング)
  
• 単一ページ/複数ページ
  
• 物理的/概念的・論理的 (ファイルがあるのかないのか)
  
• 静的/動的 (HTMLかそれ以外か)
  
• 関係線/導線
  
• 同画面遷移/別画面遷移
  
• 本サイト/外部サイト

必要な表現

ビジュアルボキャブラリーを決めておく。ビジュアルボキャブラリーについては、Jesse James Garrett氏の「A visual vocabulary
for describing information architecture and interaction design」をコンセントの長谷川敦士さんが翻訳された「情報アーキテクチャ、インタラクションデザイン記述のためのビジュアルボキャブラリー」を参照のこと。

印刷対応

全部を1枚に収めるのは不可能なので説明したい箇所だけを切り出す。

課題2 (RIAのウェブサイト) について

ファセットの表現

「どんな情報に整理でき、どんな情報を扱うのか」に着目しました。
画面上にある情報をフラットに並べて再整理をし、カテゴリの整理と出力されている情報の整理をしました。タグのようなものをサイトマップで示そうとすると (ドキュメントとして) 破綻してしまうので、説明する内容を制限し、わかりやすいものに仕上げました。

感想

ないものを作り出すための作業ではなく、すでにあるものからサイトマップを作成するため、どうしてもウェブサイトを見ての判断になり画面の要素に偏ってしまうことです。したがって、サイトマップを作成する作業にも関わらず画面仕様書に近いものを作成しているグループがあったように思います。

もちろん結論として (というか実際の現場だと) わかりやすいものであればなんでもいいのですが、サイトマップを作成するという課題に対して「結果として画面仕様書になりました」だとちょっと違うかなと思いました。

実際にサイトマップを作成する (作成するというより再整理するという表現のほうが適切だと思いますが) 状況の多くが、すでにあるものを参考にすると思うので、そういう意味では近い状況にはできたかと思いますが、であれば、課題1のサイトマップ (あらかじめ印刷されたもの) はいらなかったと思います。結果的にそれにどういう情報を付け加えれば理想のサイトマップになるのかにボクがいたグループは意見を集約できたのでよかったのですが、ほかのグループの結果を見るとあらかじめ用意されたものをなくしてゼロから書き上げていたので、論点が幅広くなってしまった印象がありました。

課題としてあがっていた「理想的なサイトマップの形と標準書式」については以下のようにまとめることができると思います。

• サイトマップの理想のカタチはワイヤーフレームと同様、自分の状況や後工程に依存する
• サイトマップの標準書式はビジュアルボキャブラリーを揃えることで標準化できる

この「自分の状況」や「後工程」にどれだけのパターンがあるのかはイシューだと思いますが、そうしたことを意識しながら日々取り組んで行くことで業界全体としても理想のカタチになっていくような気がします。

少なくても「サイトマップ」という言葉で、しかも「IA」という言葉を使わずに、これだけの参加者が集まれることや、そのことにこれだけ関心を持つ人がいること自体にパワーを感じました。