chibirashka journal

銀座アップルストアで開催された、CSSNite Vol. 36に行ってきました。

今日はさとさんによる
『インフォメーションアーキテクトの過去、現在、そして未来。
The past, present, and the future of Information Architect』
という講演でした。

ブレブレですみません。。。orz

さとさんには、IA Cocktail Hour等々でいつもお世話になっていますが、講演を聞くのは初めて。長くIA、UXといったことに携わっているさとさんのような方しか語れないような情報ばかりで、知らないことがいっぱい！90年代マルチメディアっぽいものが出てきたころのこと、インターネットが出てきたころのこと、情報が増えてサイトが巨大化してきた時期のこと、ノウハウが蓄積されて、メソッドが集約されたりして、デザインファームの統廃合があったこと・・そうした背景的なことから、プロジェクトにおけるIAの役割とか、情報につながった空間、情報環境を場としてデザインするエクスペリエンスデザインといったところまで、広く話してくれました。ま、ともかく最近あちこちでIAというキーワードを目にするけど、別に決して新しいことじゃないんだよ、というお話。

それにしてもCSSNiteの集客力には驚かれます。鷹野さん、いつもありがとうございます。今日もものすごい立ち見が出て、床に座り込む人もいっぱいいて、ものすごい熱気！

CSSNiteの驚異的な集客力

CSSNite後の懇親会も大盛り上がりでした。

いろんな人が来ていたけど、その中でも一番の注目は、サービスインから1週間が経ったkeireki.jpの中の人、浅枝さんとクリストファーじゃないかしら。

浅枝さんとクリス

めちゃ面白い人たちだったなー。クリスの日本語の流暢さ加減にはビビった。そして、浅枝さんには、iPhoneのBumpというすごいアプリを教えてもらって、かなり大盛り上がり！今日提供開始されたiPhone OS3.0よりも私にとってはインパクト！「すげー、衝撃波で情報が交換されるとは！」とか思ったけど、そんなわけないね。位置情報で交換してんのかね。

keireki.jpについてはこないだ記事書いた通り、本名ベースの社会人コミュニティなわけだけど、ニックネームの登録もできるのね。普通、ニックネームって、本名を隠すために使われるものだけど（例えばmixiとか）、keireki.jpの場合、本名を隠すためじゃなくて、本名が分かってもらえるようにするためのニックネームなんだよね。

TwitterとかTumblrとか、フォローによってゆる〜くオンラインで繋がっている知り合いのことって、ニックネームでは認識できても、本名に馴染みがなかったりするから、本名を補完するためにニックネームがあるっていうのはとてもmake sense！面白い。

あと、「たしかに！」とか「イイトコ」っていうのも深いな〜と思った。よくできてるなぁ〜。

おしまいに、とっておきの写真を載せておこう。こんなツーショット滅多に見られない！この写真だけを切りとると「長谷川さんという名字の人は花柄のシャツを好んで着る傾向がある」とか、間違った分析しそうww

長谷川恭久さんとコンセントの長谷川敦士さん

金曜日の午後、代々木公園のオリンピックセンター研修室を借りて、社内研修を行った。元々は、IA/UXチームの研修会として企画が持ち上がったのだけど、PMやディレクターや、コンセントにいるメンバーはできるだけ出た方がよい、ということになったので、ほぼ全員参加の研修に。

研修の前半は座学でのIA、Webプロジェクトのプロセスといった内容で、後半はワークショップ型でいくつかのサイトをヒューリスティック評価するというもの。

昨年の吉田塾以降、社内のマーケ部、ログ部といったクラブ活動（自主参加型勉強会）の中でも、ワークショップを行うことが多い。内容はさまざまなので、ここでは割愛するけど、どのワークショップでも必ず感想として挙がるのは「時間が足りない」ということ。

今回のワークショップでも、正味小一時間で、ブレスト的なポストイット書き出し（個人ワーク）、サイトマップ作成（デカイ紙に）、書き出したポストイットのグルーピングと、課題の抽出、発表準備まで行う必要があり、「あ〜、全然終わらんっ！」っていうのが真っ先に思うところだった。

ユーザビリティ評価として、ヒューリスティック評価のほかにユーザーテストが挙げられることも多いけど、ユーザーテストに対し、エキスパートレビューとも呼ばれるヒューリスティック評価は、専門家の経験、知見、経験則により、比較的短期間で網羅的に評価できるのがメリットでもあるし、実際のプロジェクトで業務として行う時にも、限られた時間内で行う必要があるので、こういう訓練は必要だと思った。

サイトを評価する観点として、ざっくりと

• 構造（サイトストラクチャ）
• UI/デザイン（エリア-ゾーニング、要素、ナビゲーション、ふるまい）
• コンテンツ

があるんだけど、そう分かっていても、時間もない！というプレッシャーが加わると、どこから見ていっていいのか分からなかったり、あちこちクリックして見てるつもりでも、焦るばかりで評価できるほどにはちゃんと見ていないなんてこともある。（課題になりそうな「何か」に気づけなかったらどうしよう・・というような不安とかもあり）

この辺もやはり訓練次第なんだろう。どのサイトも（基本的には）オーダーメイドなのだから、まず、ここから見れば絶対にOKです、なんてことはないだろうし。

というわけで、ヒューリスティックの「いろは」というわけにはいかないけど、各チームの発表やそれに対する長谷川さんの総評などから、今後覚えておきたい（いや、知っていてもなかなかできないことが多いから念頭に置いておきたい）ことをメモ的に挙げておく。

【評価時】

• そもそもユーザビリティ評価をしているにも関わらず、「ユーザビリティが良くない」と判断するのは意味がない。どこがなぜ、が分からないと。
• ECサイトの評価では、実際の購入フローを重点的にチェックする
• 使う人の気持ちでのシミュレーション（認知的ウォークスルー）ができると良い。
• 個々のインターフェースを細かく取り上げて説明するより、それが何の問題であるかを言ってしまうと良い（これこれのリンクルールが違っていたり、各メニューごとにレイアウトが違っていたり・・云々　⇒　デザインガイドラインが定まっていないように見受けられる）
• そのサイト（または企業、事業者）独特の問題があれば、それをポイントに考えてみるのもよい（例：既に広く認知されたブランドの場合は、そのブランドで期待されるエクスペリエンスがサイト提供されているかどうか・・など）
• メニューやコンテンツといったサイト内の要素だけでなく、サイト自体の立ち位置（B2BかB2Cかなど）を俯瞰して見てみる

【発表時】

• 全体のうちのどの部分を話すのかを最初に明らかにする（例：サイトの全体構成はこれこれこういう風になっていますが、今回評価するのはこの部分です。）
• 仮説を置いて説明する
• 有限の時間では最初に結論を言えると有益（例：重複コンテンツが多く見られるのが問題だと思いました。なぜなら・・・）
• 事実なのか評価なのかを分けて話す

私自身の反省と今後につなげたい点としては、時間配分もだけど、チーム内役割分担かな。同じチーム内にリテラシーの極端に低い人がいる場合に、どうやって進めるかをよく考えないと、その人があまり参加できないままになりグループワークであることの意義が埋もれてしまう。

というのも、たとえば、書き出したポストイットをある見出し（文脈）でグルーピングしているそばから、「こっちのグループのポストイットにもあっちのグループのポストイットにも”メニュー”という言葉が書いてあったので、ひとまとめにしてグループにしておきました」と言って、文脈を崩されてしまう場面が多々あったから。「うんとね、言葉で分けているわけではなくてね・・・」みたいな・・（汗）

こうなると思考が思わぬところで止まってしまったり、作業のやり直しが発生したりしてしまう。だからといって、「構造というのは・・・」「UIというのは・・・」「ふるまいというのは・・・」から説明するのも時間的に厳しかったりするし。。。今回は、若干自己嫌悪になりつつも牽制しながら（謎）、それとなくカタチにしたんだけど、グループワークでやる以上は、参加者全員が同じぐらいの力を出して、同じようにアイディアを出したり発表するのが望ましいと思うし、知識や経験の差によって見方が違うからこそ新しい発見もあるかもしれないしね。なんとかその辺の課題をクリアしていきたいと思った。ヒューリスティック評価自体の話じゃないんだけど、どちらかといえばファシリテーション技術なのかね。

なかなか奥が深い。。。むずいな、ワークショップ。

本日2本目のお知らせエントリー。

Myボス、長谷川さんの新連載がWeb Designingでスタートしました。
IAというと概念的であったり、小難しそうな印象だったり、ちょっと敷居が高いと感じている方もいるかもしれません。

この連載は、普段のWebサイト構築で、「うんうん、そういうの、あるある〜」という場面を取り上げながら、「ほっ！IAって実はそういうことだったんだー（・・と言うと若干語弊があるけど・・）」と気づいてもらえるきっかけになるような、気軽に読めるネタを提供しています。

ぜひ読んでみてください〜。

クリックしても大きくなりません。買って読んでね！

これまた、IA Summit 09 & IxDA interaction 09 Redux Tokyoの記事を先に書けって話ですが、書きやすいこちらに逃げてみよう。

Myボス、長谷川さんの最新コラムがWeb担当者Forumにあがっています。

• 建築分野に学ぶWebサイト設計——“変化するWebサイト”をどう捉えどう発展させるか

Webサイトは、情報が追加されたり修正されたり、「変化」していくメディアです。

このコラムでは、クリストファー・アレグザンダー氏が、提唱した「パタン・ランゲージ」やスチュアート・ブランド氏の著書『How Buildings Learn』内に登場する「ペースレイヤリング」という概念を紹介しながら、「変化」をWebの設計にどのように織り込んでいくかということについて書いています。

[連載]IA視点のWebプロジェクト
http://web-tan.forum.impressrd.jp/l/3133

料理ネタばかりエントリーしてましたが、たまにはそれ以外も・・。

土曜日にWebSigのIA分科会「明日から実践できるIA vol.3 ユーザー目的からユーザーフローを導き出す」に行ってきました。IA分科会の開催は3回目の今回で終了とのことなので、私が行くのは、最初で最後。

2部構成になっていて、第一部では、ネットイヤーの坂本さんによるライブIAという初の試み。第二部では、第一部の内容をグループワークショップで体験。

ライブIAと言っているのは、坂本さんが情報設計時に頭で考えていることを口に出して言い、実際見ている画面なども見せていくことで、思考プロセスをオーディエンスが追えるようにしたものです。

具体的には、東京都のサイトを例に挙げ、自治体サイトの良いナビゲーションを考えるプロセスを見せていただきました。

坂本さんのプロセスでは、
1. 価値基準を作る
その業界（この場合は自治体サイト）で、どんなサイトが一般的に優秀とされているかを知る。さらにその中で、自分が作りたい（好きだなと思う）のはどんなサイトなのか、モデルになるサイトを選んで、自分の方向性を決める。

●利用できるもの
各種サイトランキング調査

●具体的手法：
ランキング上位のサイトをみて傾向、特徴を掴む。
また、過去数年のランキングも参考に、デザインや評価の変遷を知る

●注意：
価値基準を作る時に、（制作）対象サイトを見すぎてしまわないようにする。そのサイトのルールが刷り込まれてしまい、ニュートラルな判断ができなくなるから。

2. 行動を想定する（自分が利用者になる）
区役所にどんな時に行くのか、実際に行く時にはどんな行動を取るのか、・・・。自分を1ターゲットとして捉え、自分が実際に使う時のことを考える。

●利用できるもの
実際に撮影した写真、Google画像検索した区役所や、フロアマップなどの画像など

●具体的手法：
できれば、実際に場所に行って写真を取りつつ、どういう行動を取っているかプロセスをたどってみる。できるだけ具体的に行動を洗い出すため、例えば「引っ越し手続き」などテーマを持って行う。

3. ユーザーのニーズを知る
想像できる一般的な行動プロセスだけでなく、ユーザーが区役所や自治体に対して想起するような事柄を知る。

●利用できるもの
各種コミュニティ（アスコエ、kizashi、mixiのコミュニティなど）

4. 行動プロセスの分析
プロセス、行動、要件を洗い出す。

●利用できるもの
AIDMA、AISASなどフレームワーク

5. 要件のマッピング
フローと情報構造は同じではないため、構造的な情報分類と、ユーザーが想起しやすい切り口の動線作りが必要。

●具体的手法：
グローバルレベルのメニュー名（カテゴリ）を抽出し、これ以上分解できないというところまで分解し、情報構造を理解し、再整理する。
想定した行動においてプライオリティが高いもの（例：引っ越しタスクではアクセスマップのプライオリティは高い）については相応の掲載方法をとる

といった感じでした。（うろ覚え・・）

情報設計ってリニアな思考プロセスってわけではないと思うので、短時間内でライブで見せることができるものなのか、すごく疑問だったのですが、なかなか興味深いトライだったのではないかと思います。（ライブIAに限らず、他の人がどう物事を考え、捉えているのかを知るのは興味深いです！）

全く予備知識のない業界のサイトを、どんな風に見ていったら良いか、といった時に参考にできる点がたくさんあると思いました。

ただ、「これが、情報アーキテクチャの設計です」というには、若干違和感を感じます。どちらかといえば、ディレクターや、もしかすると企業の担当者が、情報設計前に行うウォーミングアップみたいな位置づけに近いような・・・。

本来IAが行うべきは良いナビゲーションを作ることではなくて「問題解決」です。課題が何なのかを明確にするのが一番最初で、次に、解決するための方策を考え実施し、結果的にナビゲーション（なり、ラベルなり、構造なり）が、ターゲットユーザーにとって「良い」ものになるのかなと思っています。

一人ブレストするだけの時や、小規模でターゲットが明示的な場合は、自分を1ターゲットとして行動プロセスを考えてみるのは良いかと思いますが、実際の自治体サイトなど大規模なサイトの場合、多種多様なユーザーがいると思われ、また同じユーザーであっても、状況に応じて必要とされる機能や動線も全く変わってくると考えられるので、MECEに検討することと、優先順位の付け方とその根拠がキモだと思います。

HCD-Netの「地方自治体ホームページのユーザビリティ評価〜引っ越しタスク編〜」で評価を行った時も似たようなことを思った記憶があります。サイト内のページ単体の使い勝手の評価という意味では、ヒューリスティックによる、それこそ○×評価や、ベンチマークとの比較とかで良いかもしれません。

でも、本当の意味でユーザーにとって使いやすいか、分かりやすいかどうか、というのは、ペルソナを作ったからといって明確になるわけではなくて、また「引っ越しタスク」といった漠っとした目的に対して分かるものではなくて、ユーザーの一連の行動の中で、ユーザー自身も気づいていない「課題が何か」を知り、それが解決できているか、ということが指標になるのではないかしら。課題が不明なままだと、評価も設計もできないんじゃないのかなーと。

今回のライブIAという試みは、パフォーマンス的な面もあるし、サイト外施策は考えず、前提も緩く、というのが参加者全員の共通認識としてあったので、検討範囲がかなり限定的でも問題ないのかもと思いましたが、第二部のグループワークでのテーマ設定で悩んだ点や、そのHCD-Netのユーザビリティ評価の際に評価しきれないと思った理由に「課題が何か」の観点が欠落しているという共通項があるような気がして、後々の参考のために、超長いエントリーだけどポストしときます。

あ、ちなみに宣伝（？）ですが、WebSigのIA分科会は、IAAJ（Information Architecture Association Japan）の活動に引き継がれます。IAAJでは、毎月1回程度、できるだけ定期的にIA Cocktail Hourという懇親会や、その他勉強会／報告会などを開催しています。この会には、インフォメーションアーキテクトだけでなく、業務としてIA的なことを行っている人、IAに関心がある人など幅広く参加いただいていますので、ぜひ、参加してみてください。開催予告は、IAAJのサイト、メーリングリストのほか、コンセントブログでも行いますー！