開発現場のUIトラブルを解決!? 画面プロトタイプ入門：いまさら聞けないリッチクライアント技術（16）（1/3 ページ）

UIを取り巻く開発現場の問題点って何？

　システム開発におけるUI（ユーザーインターフェイス。本稿では、画面系の話題をすべてUIといいます）には、大きく2つの問題があります。

■ユーザーいわく「使いにくい、分かりにくい」

　1つは、システムの使いやすさについての問題です。システムをリリースしても、エンドユーザーから「使いにくい、分かりにくい」などのクレームが発生し、システム導入後の運用コストが低減できなくなるなどの問題が発生します。

「OK」と「キャンセル」、どちらが有効か − ＠IT via kwout

■ユーザーいわく「やっぱり画面にアレが欲しいな」

　もう1つは、製造工程以降で、動くシステムが出来上がったときに、顧客から追加の要件が頻発する問題です。これは、システム開発共通の大きな問題ですが、特に顧客の目に付きやすいUIの部分は、その指摘が多く、かつ、業務ロジックに影響することも大きいため、追加要件の発生による手戻りが、大きな問題となります。

　UIは、その要件を上流で作り込むことが難しく、後工程の試験や運用で発生していることが、UIを取り巻く問題の特徴です。

　では、なぜこのような問題が起こるのかを、開発現場の現状を踏まえて分析したいと思います。

■なぜ、使いにくい？

　まず使いにくいUIが起きる問題については、開発プロセスと開発環境で、エンドユーザーを巻き込むスキームを作りにくいことが挙げられます。システム開発における顧客は、顧客先の情報システム部門の人が担当していることが多く、業務として実際にシステムを使う人ではないことが多々見受けられます。そのため、業務上の要件は満たされていても、業務の実状が開発関係者に伝わらないことが、この問題の大きな背景としてあります。

　最近、このような背景から、ISO13407に代表されるように、エンドユーザーの視点を開発に取り入れる「ユーザー中心設計（User Centered Design、UCD）」の考え、ペルソナやシナリオなどのユーザー視点の業務分析の手法が広まりつつあります。

＠IT：Webアプリケーションのユーザーインターフェイス［3］-2 via kwout

＠IT情報マネジメント：利用者の立場を考えたペルソナ／シナリオ法による開発とは via kwout

■なぜ、追加で要件が増える？

　次に、顧客の追加要件が、UIが出来上がる製造工程以降で頻発する問題についてです。

　要件定義工程の段階で顧客とUIの画面項目や画面仕様、機能仕様を決めていくとき、多くのプロジェクトでは、マイクロソフトのPowerPointやVisioを用いてUI、つまり画面を作成していることだと思います。このような場合、静的な画面定義書（仕様書）で顧客とやりとりすることが中心となり、画面の項目や仕様など静的な部分については、合意を得られます。

　一方で、画面の遷移やページ内の状態遷移やインタラクション（対話型操作）を含めた動的な部分は、自然文で機能仕様を記述するに留まることが多くあります。要件定義の段階では文面レベルで意識が合っているものの、実は、開発側と顧客の間での実現イメージが合っていなくて、それが後工程での追加要件の発生につながっていると考えられます。

＠IT：Webアプリケーションのユーザーインターフェイス［1］-2 via kwout

そんなときは画面プロトタイプを使え！

■顧客（関係者）とのコミュニケーション手段としての「画面プロトタイプ」

　これまで挙げてきた問題を解決する1つとして、「画面プロトタイプ」の活用をシステム開発の上流である要件定義工程に導入する取り組みがあります。要件定義の段階から顧客とシステムの完成イメージについて合意し、かつ、エンドユーザーも巻き込むことで、使いやすく、かつ、後工程で手戻りが少ない開発ができると期待できます。

　これを読まれた方の中には、「何をいまさら」「ちょっと古くないか」などの印象を持たれた方もいるのではないでしょうか。アジャイル開発を始め、プロトタイプの有効性は、これまでもさまざまなところで議論されてきており、すでに実践している方もいると思います。

Rubyでアジャイルプロトタイピング（1） − ＠IT via kwout

　一方で、低コストや短期化が進む現状のシステム開発では上流工程に十分な時間を割くことが難しく、画面プロトタイプを始めとする顧客とのイメージ合わせに関する取り組みしっかりと実践できていないのが現状ではないでしょうか。この問題や、なぜ筆者がここで画面プロトタイプを紹介するのか、その背景については、後ほど解説します。

　話題がややそれましたが、ここで画面プロトタイプの有効性について紹介したいと思います。IT企業の顧客は、その多くが非IT企業の場合であることが多く、紙ベースの仕様書や設計書から、システムの実現イメージが湧きづらいことでしょう。実物に近く動くものがある方がシステムのイメージも湧きやすく議論がしやすくなるのは、当然の考えです。

　また、提案段階においては、提案書とセットで開発受注用のプロトタイプとして顧客にアピールすることもできます。プレゼンテーションツールで作るよりも、実システムに近い出来上がりのため、顧客の反応も良くなることは容易に想像できます。

■プロトタイピング作成環境には何を使えばいいの？

　画面プロトタイプを作るには、紙とペンで作るペーパー（紙芝居）プロトタイピングのようにラフなイメージを作る方法を始め、マイクロソフトのPowerPointやVisioのようなオフィス製品、Visual StudioやEclipse、アドビ システムズのDreamweaverのような開発環境やWebオーサリングツール、FireworksやIllustratorのようなデザインツールなど、さまざまな方法があります。

　また、ダイナミックなアニメーションを必要とするアプリケーションでは、アニメーション開発用のツールで最初からプロトタイプを作る場合もあります。絵コンテのようなイメージを手書きで作成してから、ツールでアニメーションを作っていくプロジェクトもあります。

　上記のツールのいくつかを実際に使用し画面プロトタイプを作りながら、顧客との要件定義を実施した人もいるのではないかと思います。しかし、これらのツールは、画面プロトタイプを作るためのツールではないため作成効率が悪かったり、思うようなプロトタイプを作れなかったりなど、ツールそれぞれに一長一短があります。そのため、状況によっては開発プロジェクトの負担になっていることがあります。後述しますが、このような状況も、システム開発で画面プロトタイプの利用が上手く浸透していない原因の1つなのではないかと筆者は考えています。

　一方で最近、このような負担を軽減するような、画面プロトタイプの作成に特化したツール（Axure RPやDENIM、iRise、Pencil）が相次いで注目されています。どれも、米国で開発されたため、初めて名前を聞く人もいると思いますが、UIの専門家をはじめ、国内のブログでも話題となっています。

　次ページでは、上記ツールの位置付けと、それぞれの簡単なツールの特徴を紹介していきます。