WebとUIをつなぐトリックスター（5）

プロトタイピングでUIデザインの失敗にさようなら

仲里淳
2009/9/11

※　トリックスター……この連載でのトリックスターのイメージは、相反する2つの者同士が、別個に機能する共同体をつなぐ役目を果たす人。閉鎖的な空間に風穴を開けて風通しを良くする人。エンジニアとコーダー、デザイナの機能システムが組み合わさった緩やかな共同体を創造する人たちです。

WebサイトのUIデザインを効率的に進める「プロトタイピング」が注目されている。この手法に積極的に取り組むビジネス・アーキテクツの伊原力也氏に、実践する際のポイントについて聞いた

悩みの種は納品後に発生するUIデザインの修正

　RIA/リッチクライアントに限らず、納品後にUI（ユーザーインターフェイス）に対して「使いにくい、分かりにくい」「やっぱり画面にアレが欲しいな」といった意見がクライアントから出ることは少なくない。こういったUIトラブルを減らす有効な手段として「プロトタイピング」が注目を集めている。

　初期の設計に沿ってまっすぐに突き進むのではなく、可能な限りプロトタイプ（試作品）を使ってテストし、問題がないか確認するというものだ。この手法を取り入れることで、土壇場での修正作業を減らし、効率的にプロジェクトを進めることができるという。

　ビジネス・アーキテクツのインフォメーションアーキテクトである伊原力也氏も、プロトタイピングの実践に積極的に取り組んでいる1人である。

伊原力也（いはら りきや）　ビジネス・アーキテクツ インフォメーションアーキテクト・マークアップデザインエンジニア。大規模プロジェクトのCSSサイト構築・製品プロモーションサイトの設計・モバイルコンテンツ構築も手掛けるデバイス非依存実装のスペシャリスト。クリエイティブ集団mokuva所属

　同社では、「デザイン」という言葉は「ビジュアルデザイン」だけを指してはいない。何かを形作る、そのための土台作りをも含めて、すべて「デザイン」と定義している。伊原氏の肩書きの１つである「マークアップデザインエンジニア」とは、マークアップにおける設計から実装までの責任者という意味。インフォメーションアーキテクトも兼任しており、情報設計からUIデザイン、その裏にあるシステムとフロントエンドをつないでいくクリエイターだといえる。

　そんな伊原氏がプロトタイピングを実践するようになったのは、「プロジェクト後半に発生する修正のリクエスト」を何度も経験してきたからだという。受注者（制作側）と発注者（クライアントの担当者）の間でイメージのすり合わせができていれば問題ないはずだが、現実は違った。

「いままでの経験からすると、ある程度プロジェクトが後半に差し掛かってきたときに、お互いが一度は確定したと思っていた部分から、個人の好みや立場上の主義主張の話が再開してしまうことが多かった。それを何とか避けられないものかと考えた結果、なるべく初期の段階でUIをイメージできるものを作ることと、ユーザーに喜んでもらうことが一番重要なのだから、ユーザーを初期の段階から巻き込んでしまうことを考えました」（伊原氏）

　伊原氏はケータイ向けサイトの開発経験を持つ。ケータイサイトの開発では、端末の種類が多いうえにユーザビリティが重要視されるため、実際にページを作り操作してみるということを頻繁に繰り返す。従って、プロトタイピングという手法に興味を持ち、抵抗なく受け入れたのは自然なことだといえる。

目的は、関係者の意識統一と、UIの問題の抽出

　プロジェクトの効率化がプロトタイピングの目的だが、その内容はプロジェクトの段階や対象によって細かく違ってくる。

「同じプロトタイプといっても、段階と対象によって違いがあります。初期段階のプロトタイプは、プロジェクト関係者の意識の統一や要件抽出が主な目的です。それぞれが思い描くイメージにズレがあると意味のある議論もできないので、まず叩き台として使うことになります」（伊原氏）

　この段階のプロタイプは、凝ったものである必要はなくて、ホワイトボードや紙に図を描く程度のもので構わない。発注側と受注側の意識を1つの方向に集約していくためのものというのが一般的だという。

「既存のUIがあり、その使い勝手を改善するといった場合は、紙ベースのものや、遷移やナビゲーションの確認用にPowerPointでリンクだけ付けたものを使います。一方で『いままでにないようなUI』といった、ユーザビリティよりも斬新さが優先されるような場合は、実際に近いプロトタイプを作ることがあります。モーションデザインやビジュアルデザインと設計を分けて考えない方がよいときもあります。裏側のロジックは作らないにしても、ワイヤーフレームだけでなくある程度デザインまでして、完成形に近いプロトタイプで固めていく場合もあります（※1）」（伊原氏）

※1参考図書：『PowerPointによるインタフェースデザイン開発』（工業調査会）井上 勝雄（著）、岸本 寛之（著）、 伊藤 弘樹（著）

　積み上げていく形をとるのか、デザイン主導で進めていくのかによっても、作るプロトタイプは変わってくる。プロトタイプ自体には、「こういう風に作る」という決まった形があるわけではない。従って、プロトタイプを作るツールも決まったものはない。

　最近の傾向として、UIを標準ガイドラインに沿って作ることが多い。しかし、ビジネス・アーキテクツでは、そういったドキュメントやツールはあくまでもコミュニケーションのための道具としてとらえている。案件の性格や期間、発注者、プロジェクト関係者によって、採るべき選択肢は変わってくるからだ。モーションデザインが目玉となるキャンペーンサイトの制作では、ワイヤーフレームから入ってしまうと逆に失敗することもあるという。

「ユーザビリティを高めるアプローチの1つには、“ユーザーが感じる印象をなくしていくこと”があります。何も意識していなくてもいつの間にか達成できていて、『こんなことが簡単にできるなんて、良い時代になったなあ』とちょっと好印象になるぐらいが本当に優れたユーザビリティです。逆にキャンペーンサイトでは、強い印象を残すような“引っ掛かり”が求められます。ガイドラインありきだと、ついついそれに引っ張られてしまいますから、あくまでも抑えるべきところ抑えるための参考程度にと考えています」（伊原氏）

ユーザーテストのポイントは頻度と目的設定

　プロトタイプはプロジェクトメンバーで共有するだけでなく、ユーザーテストに用いることで初めて生きてくる。プロトタイプを用いた具体的なユーザーテストの方法だが、あまり大げさに構えるのではなく、少人数でもよいので早い段階から数を重ねることを重視すべきだと伊原氏は考える。

「業者に依頼してテスト要員を集めるような大規模なものも必要ですが、それよりももっと前の段階で行うテストの方が効果は高いと考えています。要件定義の段階で、PowerPointや紙などを使ってプロジェクトに関わっていない2、3人に試してもらいます。それを1回ではなく3回、4回とやることによって、致命的なユーザビリティの問題点を洗い出せます。プロジェクトの初期段階からテストをして得られるフィードバックは、たいがいプロジェクトメンバーにとって『思いもよらず』かつ『重大な問題』であることが多いのです。中盤以降に大掛かりなテストをしても、実は同じフィードバックは得られるのですが、そのときに見つかってもすでに軌道修正が難しい場合が多く、対症療法になったり、作り直しになってしまう可能性が高いです。なので、小分けにして繰り上げていくのです」（伊原氏）

　プロトタイプを用いてテストを行う際のポイントは、「何をチェックしているのか」という目的の明確化だという。

「テストをするということは、何らかの根拠を求めているわけです。気軽に回数をこなすことがプロトタイピングの重要な点とはいっても、漠然とやるのでは意味がありません。われわれは、それぞれのフェイズに応じてチェック項目を作っています。テストの手法自体については、参考となる書籍がたくさんあります（※2）」（伊原氏）

※2編集部注：伊原氏の薦めるテストの手法についての書籍には、下記があります。

• 『ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック』（オーム社）樽本 徹也 （著）
• 『ウェブユーザビリティの法則 改訂第2版』（ソフトバンククリエイティブ）スティーブ・クルーグ（著）、 中野 恵美子（翻訳）

「プロトタイプを完成品に」は陥りやすいワナ

　プロトタイピングの手法を取り入れるに当たって注意すべき点は、「プロトタイプはあくまでも問題点を探すための試作品としてテストのたびに捨てる」ということ。決して、そのまま納品物として作りあげていくものではないのだ。これは当然といえば当然だが、意外に陥りやすい過ちでもあるという。

「プロトタイプとして作ったものは、最終的な成果物にまで高められないと思っておいた方がよいです。『後でそのまま使えると楽でいいな』なんて考えていると、本来やろうとしていることがおろそかになってしまいます。HTMLに限っていえば、やり方によっては不可能ではありません。ただしその場合でも、プロトタイプといえども完成品に近い形で作るか、工数を削減するために完成形の方をプロトタイプに近づけるなど、最初から想定されていた場合に限ります」（伊原氏）

　プロトタイプとして作ったものをそのまま流用しようとすると、現実には逆に手間が掛かってしまう。そもそも、プロトタイプとはテストのために完成形となるものの一部を切り出したようなもの。それを使い続けようとするのは、例えるなら建築模型を継ぎ接ぎに組み合わせて実際に人が住める家を作る行為と同じというわけだ。

　開発ツールの中には、プロトタイプをそのまま完成形として流用するための機能を売りにしているものもある。しかし、そのようなツールであってもプロトタイプだけと割り切り、そこに肉付けして流用しようとしない方が現実的だという。

　作ったものを捨ててしまうのは、一見すると無駄に思える。しかし、問題発見と修正の工程をプロジェクト全体で満遍なく発生させることで、結果的に各フェイズでの負荷は平準化される。つまり作業の合計は増えたとしても、無理は減る。これこそがプロトタイピングの本質といえるだろう。決定した仕様に基づいて完成形を作るという段階では、実はそれほど時間はかからないという。

「最終形が決まってしまえば、その制作にかかる実質的な時間はそれほど必要としません。もし時間がかかってしまうのであれば、それは制作しながら設計の再検証も行っているからでしょう。前もって気になるところをクリアにしておくことによって、最後の制作を一気に進められます」（伊原氏）

プロトタイピングが秘める可能性を追い求めて

　とはいえ、そんな伊原氏でも「プロトタイプから完成形を」という、クリエイターにとっての理想はまだ持ち続けている。

「これまで、プロトタイプからそのまま最終形にしようと何度か試みたこともありましたが、限定的にしか実現できたことはありません。ただし、いまでもその夢を捨てたわけではありません（笑）」（伊原氏）

　プロトタイピングはまだまだ発展途上の手法であり、簡単に実践できるとはいいがたい面もある。だからこそ、これからのWebサイトやシステムの開発プロセスに革新をもたらす可能性も秘めているといえるだろう。

【関連記事】

開発現場のUIトラブルを解決!? 画面プロトタイプ入門 いまさら聞けないリッチクライアント技術（16）　アプリ／サイト納品後に顧客に「使いにくい」「あれ追加して」といわれた方へ。前もって画面イメージを簡単に作る方法が…… 「リッチクライアント ＆ 帳票」フォーラム 2009/3/11

Silverlight制作をデザイナと開発者でコラボしてみた 実録：デザイナ×開発者コラボを成功するポイントとは　Expression Blend×Visual Studioのコラボは本当に簡単なのか？ 面白コンテンツの制作過程をドキュメントでお届け デザインハック ＜ リッチクライアント 2009/9/7

Flex/AIR開発でデザイナとの協業を楽にする「yui」 デザイナとプログラマを“結”ぶオープンソース（前編）　Flex/AIR開発でデザイナと協業することになったら、ぜひ試してみてほしいオープンソースのフレームワークがあります 「リッチクライアント ＆ 帳票」フォーラム 2008/10/1

人・チームが成功の鍵となるリッチクライアント WCR Watch ［6］　大手国内航空会社の航空券予約サイトなど、RIA開発に豊富な実績を持つセカンドファクトリーに、RIA構築における成功のポイントを聞いた 「Web Client & Report」フォーラム 2005/8/4

GoogleSitesを使って制作プロジェクトをハックしよう GoogleSitesでプロジェクト管理（1）　Web制作の現場をサンプルに、GoogleSitesをツールに用いたプロジェクト管理の方法を紹介する。使いこなしてプロジェクトをハックしよう デザインハック ＜ リッチクライアント 2009/3/17

[an error occurred while processing this directive]

「デザインハック」コーナーへ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）