Small IA さみっちょ #smallia

8月21日 (金)「Small IA さみっちょ」というイベントを開催しました。最近は「IA」を冠にしたイベントも少なくなり「UX」しかほぼ見なくなったわけですが、そんな中でワイヤーフレームについて掘り下げた中身の濃い議論を、集まっていただいた30名近くの参加者と飲みながらできました。

主催は、以前に東北セミボラでご一緒した、ツルカメの森田さん・インテリジェントネットの和田さん・グッドパッチの村越さんとボクで、グラレコを DeNA の和波さんにお手伝いいただきました。場所は、目黒にあるワンパクさんのオフィスをお借りしました。阿部さんが大阪出張で会えず終いで残念でしたが、ワンパクのスタッフさんにもいろいろとご協力いただき無事開催することができました。

記憶のあるうちに感想を交えて振り返ってみたいと思います。

Small IA さみっちょ from Takashi Sakamoto

Small IA 宣言

by 森田雄＠ツルカメ

はじめに、今回の主旨としての「Small IA」について紹介するとともに、どのように我々は取り組んでいくべきかについて森田さんよりお話いただきました。「IA」は「情報アーキテクチャ」を指しますが、海外カンファレンスなどであった「Big IA vs Little IA」であったようなことも踏まえて、もう一度ワイヤーフレームなどに焦点をあてようというものです。

「小は大を兼ねるが、大は小を兼ねない」という森田さんのセリフはとても印象に残ります。積み上げた経験でより大きなことはできるが、はじめから大きなことはできないというものです。そのため、口先だけのコンサルではなくプロジェクトを推進する原動力になろうというメッセージはとても共感できる内容でした。宣言にある一部を転載しておきます。

Small IA の主要業務とは、一般には Web ディレクター的な役割の人が担うものとされており、具体的なタスクはワイヤーの作成やコミュニケーションの設計などとなります。それは、事業の最初やら企画やら何やら上流設計からプロジェクトの終端たる実装実務の最後まで、全関係者においての仕様の拠り所となるいわゆるワイヤーを、ゼロから作り出し管理し共有し検証していく崇高なものであります。仕様の拠り所たるワイヤーを根拠にコミュニケーションロスをなくしプロジェクトを円滑に進め高品質の証左を作り出す替え難いものなのであります。

以前ブログに書かれた「僕は生涯Small IAでいい」とか「small IA manifesto」も合わせて読めばいいかも知れません (なぞ)。

Big IA が有名な会社の Small IA

by ゆいぴょん@コンセント

ゆいぴょんからは実体験を踏まえた個人的な意見として「ビジネスの立場に近い IA vs UI に近い立場の IA」という視点でお話いただきました。この2つの側面は、ワイヤーフレームだけの話でもなく概要設計と詳細設計という大規模開発に必要な側面としてもご説明いただきました。彼女自身が UI に近い立場の IA ということで、日々実践している Rapid Design と Rapid Markup をその場で実演までしていただきました。

上流工程と下流工程とで起きる問題については、そのタスクにおける当事者（そのタスクの責任）が決まっていないからではないか (?) という役割分担の話として聞くことができました。また、そのときにどの程度まで掘り下げておく必要があるのかによっても成果物のレベルも変わると思うので、背景をもう少し聞いてみたかったです。

コンテンツ企画とページ設計の境界線はどこにあるのか?

by 足立さん@イントリックス

足立さんからは、サイト単位ではなくページ単位において「企画・アナリスト vs 設計・IA」とのやりとりについてお話いただきました。ある事例で、企画時に考えられた2カラムのレイアウトを、設計段階で1カラムに変えることになったという経緯です。これは分業が進むとよくある課題だと思いました。ボクの近くでも同じようなことはよくあります。

この問題も、基本的にはどの時点でどこまで決められているのか、が明確になっていれば良いように思いました。企画時にデザイン経験者がデザインしていないこと、企画意図が正しく伝達されなかったことが問題のように見えますが、個人的には企画意図としての2カラムを設計担当のデザイナーがうまく表現できなかったスキルの問題ではないかとも思いました。

Small IA よもやま話

by 吉岡くん@リクルードジョブズ

元同僚だった吉岡くんからは、彼の IA としての経験の変遷が見れて、IA や Web 界隈の歴史を感じる内容でした。とくに興味深かったのが、彼がディレクションから IA となり、現在プランナーに至る過程で身につけたタスクです。

GREE 時代には定量的評価の側面ばかりに目をやっていた経緯から、現在は定性的評価の側面も取り入れて進行している点。ワイヤーフレームはデザイナーに託しご自身ではプロジェクト設計をしている点。現在彼がプランナーという肩書で取り組んでいることがよくよくわかりました。狩野分析法は、今度ボクも試してみようと思います。

ワイヤーフレームのツール・定義問題

和田さんがモデレータになり、発起人でもある森田さん・村越さん・坂本とでパネルディスカッションをしました。テーマは、ワイヤーフレームのツールについてとワイヤーフレームの定義についてです。

ワイヤーフレームのツールについては、パネラー自ら作業したワイヤーフレームのサンプルを用意していましたのでそれを見ながらできました。その場で話しましたが、やはり業務上 Microsoft PowerPoint が多いのは否めません。とくに複数人で共同作業をする場合、クライアントも編集したい場合などがあるため、Office 製品はよく使うツールだと思います。

共同作業ではない場合やツールの指定がある場合などでは、専門ツールを使うことがあります。ボクの紹介したサンプルでは、Axure、Balsamiq、Justinmind、InVision や UXPin などです。結局は、コミュニケーション力を高める目的で使うため、いつ・誰に・どのように説明するものなのかにより使い分けている格好です。

ワイヤーフレームの定義の話題では「優先順位を書く」という森田さんの説明が簡潔明瞭なことだと思います。ただし、プロジェクトを推進するためのタスクと体制が直接的に関係することだと思います。個人的には、グラフィックデザインを学んだ背景があるため、デザイン工程が効率よく進むよう企画意図をレイアウトにまで反映したものをつくることが多いです。

たとえば、デザイン工程が効率よく進められるためには、テキスト抽出がひとつの選定基準だったりします。そのため、Cacoo や Balsamiq よりも Justinmind や Axure などの HTML 書き出しまでできるほうが便利です。また、ユーザーテストなどする場合を想定して、テストモードのようにコメントが画面に記入できるものも増えました。

Small IA スキルとキャリア問題

イベント終了後の飲み屋で和田さんらと話したことですが、こうした Small IA の経験とキャリアの話があります。たとえばワイヤーフレームの量産ともなればやはり何十や何百ページを相手にする場合もありますが、それをこなすことが今後のキャリアにつながるのかという疑問があります。

最近では、はじめから「IA」という肩書きではじめる方もいるかも知れませんが、そこははじめの宣言にもあったように、経験値の積み上げで取り組んでいくしかないかなと思います。ボクの場合は、もともとデザイナーだったこともあり、そうした経験を活かして IA タスクをしているというのが正しい見方だと思いますし。

そのため「量産だけをしている場合には、IAの専門スキルは身につかない」というのがボクの率直な感想です。どちらかというと、より経験値の多い先輩といっしょに意見交換をして進めることや、質問や疑問を勉強会などで発信するといったことがなければ難しいという言い方になると思います。

また、そのせいで徹夜をしたりといったことがボクも経験ありますが、それだけではやはり心身ともに疲弊するだけであって、ソフトウェアの習得には役立つと思いますが、IA スキルが身につくかというと難しいと思います。

総括

はじめから参加者もいっしょに飲みながらしたことにも助けられて (なぞ)、カジュアルな進行管理にも関わらず、とても白熱した議論やディスカッションができました。

参加者の中には、経験豊富な方から事業会社の方、制作・開発には関わっていないが関心のある方など、実にさまざまな立場の方も参加いただきました。時間の関係で終了後に皆さんと懇親会というふうにはいきませんでしたが、「IA」をテーマにしたイベントは冒頭にも書いたとおり最近では少なくなってきているため、とても貴重な機会になったと思います。

また、こういったイベント開催やコミュニティ運営はとてもたいへんな面がありますが、発起人を中心に協力ができ無事に終えることができてホッとしています。今後もこうした活動を通じて、自分たちの仕事や社会貢献にも通じる取り組みができればと思います。次回もどこかで企画したいと思います。