CSS Nite LP, Disk 7「IAスペシャル」に行ってきた。
「IA」には領域・専門性としての「情報アーキテクチャ」と役職・専門家としての「インフォメーションアーキテクト」の意味があるそうだが、ここで言うIAは「情報アーキテクチャ」としての意味。
今回とてもおもしろかったのがTwitterハッシュタグ #cssnitelp7 での実況中継。話を聞きながらメモ取りながら考えながらつぶやきながら、とても忙しく頭と手を動かした。
観客でありながら参加しているという感覚は刺激的で、受動的に情報を受け取るより内容に集中できていたように思う。セッションそのものに集中するというより、セッションで取り扱われている内容に集中するという感じ。同じようでいて違う。
各セッションの概要と感想
情報アーキテクチャの全体像〜ワークフローとケーススタディ〜
長谷川敦士さん（コンセント）のセッションでは、IAの全体像と主な手法をおさらい。情報アーキテクチャとは何か、情報アーキテクチャはなぜ重要か、どうやって情報アーキテクチャを設計するか、ケーススタディを見ながら改めて確認することができた。
長谷川さんにとって「IA＝愛」だそうで、ユーザをコンテンツサービスとつなぐものがIAであり、愛なんだそうだ。言葉にして言ってみるとすごい恥ずかしいが、なぜか長谷川さんが言うと不自然じゃないから不思議。
長谷川さんの啓蒙思想はいつどこで聞いても一貫していると感じる。自分の立ち位置を踏まえた姿勢はさすが。
プロジェクトマネジメントから見たIAの大切さ 大規模サイトの情報設計
林千晶さん（ロフトワーク）のセッションは実際の良い例悪い例を挙げての、実務的でPM寄りのお話。IAの専門家ではない人が中〜大規模サイトを作るときにどうすればよいのか、プロジェクトマネジメント計画書の重要性とベンチマークを中心に解説されていた。
なぜ今の時代IAが必要とされるのかを説明するために「Webサイトの制作は一軒家建築からビル建築へ」という例えが用いられ、これは分かりやすいと思った。自分の中でなんとなく分かっていることでも、人に説明して分かってもらうのは難しい。直感的に理解してもらえる手段を持つことは大事だと痛感する。
IAの欠点〜IAの本来の目的と役目
佐藤伸哉さん（ソニー）のセッションは、IAを否定しているようでいて、だから結局IAって必要でしょ？ って逆説的に言っているように感じた。
すべての作業には目的と理由があるので、それがない不必要な作業はやらない。また、その作業がなぜ必要かを常に考え、それを共有する。プラスα、誰がその作業を担当すべきかと次に誰が何をするかも考える。納得。超納得。
個人的には、佐藤さんのプレゼンの空気感が好き。一旦会場に投げかけるかと思いきやすぐ回収、みたいなァ感じがいい。
IAワークショップ〜LPOをテーマに〜
坂本貴史さん（ネットイヤーグループ）のセッションは事前課題を含めたワークショップ。事前課題に目を通していないと分からない部分が多かったので、課題に手を付けていなかった方々は混乱していたようだ。
会場での作業では、与えられた課題にどう取り組んだらよいか判断しきれないといった声が多く聞かれた気がする。私もわりと当惑した。あの規模の人数であの時間内で行うには、ちょっと難しかったのかもしれない。
もやもやは残ったが、「強制的に考えさせられて手を動かされる状況に追い込まれる」というのがワークショップのポイントでもあるような気がするので、次回の何かに繋がればいいのかな、と思う。
実装視点からのボトムアップIA
愛すべき我らがkotarok、小久保浩大郎さん（iA）のセッションはサイトストラクチャの話ではなく、主にページストラクチャの話。ハイパーテキストとか文書モデルとか、耳慣れない人にとっては小難しげな単語がたくさん出てきたので、途中で諸々を見失った方々もいるようだった。
個人的に、このセッションで抽出すべきは「明示的な共有」というキーワードだと思っていり。
小久保さん的見解として「IAは新しく発生した特別な仕事ではなく、デザインタスクのどのレイヤーにも必要な『情報の抽象化スキル』を取り出したもの」と述べているが、それを明示する抽象モデルの例として「文書モデル」を挙げた時点で脱落した方々が多かったように思う。
このセッションの前提がページストラクチャということだから、さらに言うと「実装視点」からの「ボトムアップIA」だから、当然ワイヤーフレームに関する言及もある。
小久保さん的見解ではワイヤーフレームは「コミュニケーションツール」と位置づけられている。実際に制作を行う前に意図を確認・共有するためのツールであり、共有する相手や状況によっていろいろ変わるものであるということ、その結果だけを見せて「設計意図を汲め」というのはナンセンスであるということも述べられた。
要するにワイヤーフレームというのはページ単位の抽象モデルなので、個々のIAスキルによって抽象化された情報を落とし込んで明示することが求められる、ということ。「実装視点」で言えば、文書モデルをベースにワイヤーフレームを拡張するといいよ！ となるけれど、「明示的な共有」は別に選任IAに限った話でなく、どんな担当業務にでも活かせるものである。
...という話だったのかなと解釈するのだが、全然違ってたら申し訳ない。
IAからWebサイトデザインへの突破口
最後に長谷川恭久さんが登場。えーと、恭久さんのプレゼンはすごい。以上。リアルタイムの自分のつぶやきを抽出すると、こんな感じです。
- 恭久さんのプレゼンはカリスマがかっている。
- 溜め。そして手の振り。心理学的観点から見ても興味深いプレゼン。
- 右手と左手の使い分け。立ち位置が逆の時のスタイルも見てみたい。＞恭久さんプレゼン
- 逆でも同じだ。あれは意識しているのか、天分なのか。＞恭久さんプレゼン
真似しようと思ってできる種類のプレゼンと、そうでない種類のプレゼンがある。恭久さんのプレゼンは前者であり、その次元では内容のマッチングや良し悪しは問題ではない。
質問タイム
時間が押したので短い質問タイムだった。ざっくりメモだけ。
IAの納品物をコストとしてどこに突っ込んでいくのか？
- 成果物ベースで話をするなら見積もりとして出してプラスにできる。
- ドキュメントは必須→それを作らなかったことによって起こる繰り返し作業のコストよりは安いから。手直しコストよりも予防のコストの方が安く済む。前向きなコスト。
- IA作業をしっかりしないことによって何を失っているかに気付いてほしい。サイトは公開して終了ではなく続いていくものだから、当初の目的を共有するドキュメントは必要。
サイトを修正したらドキュメントも修正すべきか？
- 変更点は必ず変更しないとドキュメントとして成立しないので、反映は必要。変わった点が目に見える形で表現できれば手書きでもよいと思う。
- コストの話に戻るが、目に見える形で提出することでコスト化できる。
- ドキュメントの位置付けによる。テンポラリーなドキュメントであれば修正しなくてもよいと思う。
- 引き継ぐ時に齟齬が生じないためのメンテナンスが必要なドキュメントは修正する。
- ワイヤーフレームなどは詰めて作りすぎない方がいい。
- ツールの設定も重要。エクセルで書いたかパワーポイントで書いたかで更新の利便性が変わるし、各自の工夫が必要なのでは。
今後IAに特化した職業やスキルは増えるか？
- 誰がそのスキルを見につけるべきかといえば、作る側でなく管理する側ではないか。
- IAって肩書はいらない気がする。
- コミュニケーションは大事。
まとめのまとめ
最後まで飽きずに聴講できたLP7だった。内容も面白かったし、Twitter実況の半端ないライブ感もワクワクした。
IAって結局なんなの？ という答えは、実は出なかったんじゃないかと思うのだが、すくなくとも自分が何をすべきかということはだいぶ見えた気がする。もちろん自分の立ち位置やどの歯車になるかで変わってくるものだし、都度悩みながら取り組むのだろうが、それは今回講演する側に立つ方々にとっても同じことだと思えたのが収穫。
