画面プロトタイプを実現する手段は身近にたくさんあり、かつ、前述したように、プロトタイプの有効性は、さまざまなところで紹介されています。
しかし、昨今のシステム開発の低コスト/短期化を考慮すると、上流でしっかりプロトタイプを作成し、顧客やエンドユーザーなどシステム開発の各ステークホルダー間でイメージを合わせるには、時間がかかりすぎてしまいます。多くのプロジェクトでは、画面プロトタイプで動的な部分を表現するには、開発環境で実装する必要があり、プロトタイプを作るだけで非常に時間がかかっていました。
例えば、「プロトタイプを作ることに注力してしまい、顧客との要件定義に十分に時間を割けない」「画面が中途半端なものになってしまい、要件定義で決めるべき内容と異なる」などの問題が出てしまう可能性がありました。
画面プロトタイプは、顧客に最も見えやすい個所であるため、中途半端なプロトタイプを出すことで、その後のプロジェクトの印象が変わってしまう恐ろしさも秘めています。
しかし、最近相次いでリリースされている画面プロトタイプ作成の専用ツールを使うことで、手軽に画面プロトタイプを作成できるようになり、少しずつこの状況が緩和されていくと期待できます。
一方で、画面プロトタイプ作成のツールを使うことで、プロジェクトの工数面での負担は緩和されるものの、画面プロトタイプそのものが抱える問題が解消されるわけではありません。
それは、顧客がシステムのイメージをつかみやすくなるため、顧客から、要件定義工程で決めるべき画面仕様や画面項目などではなく、画面の色やレイアウト、フォントのサイズなど画面の詳細な部分に議論が発展してしまうことなどの問題です。開発プロジェクトによっては、上流で上記問題を決めていくところもあると思いますが、システム開発においては、基本設計でHTMLやCSSの開発標準を定めていく中で決めていくところが多いのではないでしょうか。上流から画面を使いたくない開発者の多くは、この辺りを危ぐしている人も多いと思います。
さらに、画面プロトタイプが出来上がることで、さまざまなステークホルダーからコメントが発生し、その収束がつかなくなる問題もあります。例えば、開発プロジェクトにおける「いつまでも要件定義が終わらない」という事態です。
このような問題を抱えながら、上流で画面プロトタイプを用いて顧客と要件定義を進めていくためには、いくつかの解決策が必要となってきます。または、問題が起こることを防ぐ仕組みが必要になります。
1つは方法論(手順)の策定です。開発プロジェクトによって、要件定義で決めるべき項目は、さまざまだと思います。まずは、顧客も含めた開発関係者と工程で決めるべき項目を事前に合意することです。
次に、プロトタイプを使い分ける方法です。プロトタイプには、画面の色やレイアウトなど詳細をつめていく「垂直型プロトタイピング」と、画面仕様や項目を決める「水平型プロトタイピング」があります。これらを使い分けることで、先のプロセスと合わせて、議論の発散を防ぐことが期待できます。
最後に、水平型のプロトタイプを用いる場合にも、システム全体の画面遷移を決めているときに、各画面のエラーの話題になりコメントが発散することがあります。そのときには、顧客との要件定義において、正常系と異常系を分けるなど、議論の場を区切ることも必要になります。
この辺りは、プロジェクトの状況や顧客との関係もあるため、調整は必要ですが、どこかで決めごとを用いることが、プロトタイプを成功するための必要条件であるといえます。
「要件定義工程で、画面プロトタイプを基に画面仕様や機能仕様を決めていく」
これは、通常の開発の一部であり、画面プロトタイプで顧客の要件がすべて固まることを意味していません。あくまでも、画面に関する要件を軸とした機能要件の抽出手段の改善、さらには、システムの実現イメージが合っていないことによる後工程での手戻りを防ぐものです。
開発プロジェクトで適用するには、画面プロトタイプで顧客と合意した内容を、画面定義書や機能定義書に書き起こし、画面に関する決まりごとをUI標準のような規約類に整理し、後工程へ開発を進めていくのがよいのではないでしょうか。
画面プロトタイプを含め、UIを取り巻く環境は、画面作成ツールが登場したことにより、少しずつではあるが変化していくことでしょう。手軽に動くプロトタイプを作れることで、これまでより手軽にエンドユーザーを巻き込んだシステム開発が進むと思います。今後は、より一層使いやすさに配慮されたシステムが出来ていくことを期待しましょう!
Copyright © ITmedia, Inc. All Rights Reserved.