アジャイルモデリング(AM)
公式サイト
モデリング成果物>ユーザインターフェースプロトタイプ

ユーザインターフェースプロトタイプの概要

by Scott W. Ambler, Copyright 2003

ユーザインターフェース (UI) プロトタイプは反復的に行う分析手法で、この手法では、システムのUI模型作成にユーザが積極的に加わることができます。UIプロトタイプには以下のような用途があります。

  • 利害関係者と一緒に開発する内容を検討するための分析成果物として
  • システムの実現方式を検討するための設計成果物として
  • システムのUI設計案について伝える手段として
  • システムの開発を進めるもととなる出発点として(プロトタイプを捨てて一から書き直すつもりであれば、時間をかけて質の良いプロトタイプコードを書く必要はありません)

図1のアクティビティ図に示すように、UIプロトタイプのプロセスには4つの大きなステップが含まれます。1つめのステップは、ユーザのUIに対するニーズを分析することです。UIモデリングは、要求定義から始まって、本質UIプロトタイプのすべてあるいはその一部を従来のUIプロトタイプに発展させたと判断できる分析の時点まで行ないます。つまり、手書きの模造紙や付箋を、もう少ししっかりしたものに変換するわけです。このプロセスではまずプラットフォームを決定しますが、これは実際のところアーキテクチャ上の判断です。たとえば、インターネットブラウザ上で動くようにシステムを配置するのでしょうか。Windowsベースのグラフィカルユーザインターフェース(GUI)を持ったアプリケーションにするのでしょうか。クロスプラットフォームのJavaアプリケーションでしょうか。それともメインフレームの「緑の画面」にするのでしょうか。プラットフォームが異なればプロトタイプ作成ツールも異なります。ブラウザを使うアプリケーションではHTML開発ツールを使う必要がありますが、JavaベースのアプリケーションではJava開発ツールが必要になり、UI設計のアプローチも異なってきます。

 

図1. UIプロトタイプ作成プロセス

 

利害関係者のニーズを確定している間に、本質UIプロトタイプを(そもそも作成している場合は、ですが)下絵に書き変えることになるかもしれません。図2は本質UIプロトタイプで、図3はそのプロトタイプにもとづいて作られた2つの画面またはHTMLページの下絵です。書き変えるという言い方はここでは適切でないかもしれません。まったく異なるモデリング方法(ホワイトボードと紙)を使っているので、実際には、本質UIプロトタイプをやめて下絵に取り替えることになるからです。

 

図2. 本質UI

 

私は画面は目的ごとに分けるのが好きなので、プロトタイプを凝集性の高い2つの画面に分けることにしました。基本的な学生情報を入力する画面と、ゼミに学生を登録する画面の2つです。これはおそらく設計上の問題です(分析と設計の間には微妙な境界があって、それをしょっちゅう横切ることになるでしょう)。下絵では紙のプロトタイプよりもさらに詳しく記述することができ、図3では、画面をどう実装するかの感じを、図2よりもずっと簡単につかむことができます。ただし、紙の場合は非常に簡単ですが、下絵では図の上で画面部品をあちこち動かせるという柔軟性がありません。

 

図3. 画面の下絵

 

UIプロトタイプを反復的に行なっていると、他の成果物に記述した方がいい情報がたびたび見つかります。それでいいのです。AMの「他の成果物に移ろう」のプラクティスに従って、その情報を適切なところに記述してください。これは、AMの「複数のモデルを並行して作ろう」というプラクティスが重要である証拠にもなっています。仕事をやり終えるには、たいてい複数の事柄に同時に取り組む必要があります。アジャイルソフトウェア開発は進化型のプロセスですから、これはあたりまえのことです。

UIに関する利害関係者のニーズを理解することができたら、次のステップでは実際にプロトタイプを作ります。プロトタイプツールや高級言語を使って、ユーザにとって必要な画面やページやレポートを作成します。UIのプラットフォームがすでに決まっているなら、本質UIプロトタイプの個々の部分を従来のUIプロトタイプに変換し始めてもよいでしょう。図3のような下絵を作ることもできますし、図4のHTMLページのような具体的な実装に直接移ってもかまいません。下絵の方が皆で作業しやすいため、利害関係者も積極的に作成に加わることができますが、実際のHTMLページの方が動くコード(本来の目的)にずっと近くなります。

 

図4. 具体的なUIプロトタイプ(HTMLページ)

作成中

システム全体のプロトタイプを作成する必要はないことを必ず理解しておいてください。ほとんどの場合には、画面1つ、あるいはHTMLページ1つなど、UIの一部だけのプロトタイプを作成し、その後実装に移ります。アジャイルな開発は進化的に行うことを忘れないでください。次に移る前にすべてをあらかじめ定義する必要はありません。システムのかなりの部分のプロトタイプを作成しなければならないことも時にはありますが、それはおそらく、今後の構想をまとめるためであったり、プロジェクトの予算を得られるようシステムの開発範囲を定義するためでしょう。

UIプロトタイプの1つのバージョンを作ったら、次はニーズに合っているかどうかを利害関係者に評価してもらう必要があります。これは、2、3分時間をとって作ったものを見てくれるよう誰かに頼むだけでいい場合もあれば、ミーティングの予定を立ててグループを対象にソフトウェアをデモしなければならないようや複雑な場合もあります。私は最初の方法が好きです。UIプロトタイプを評価する場合、私の経験では、次の質問をすると必ず意味のあるフィードバックが得られます。

  • このUIプロトタイプの長所は何か
  • このUIプロトタイプの短所は何か
  • このUIプロトタイプに足りないものは何か

プロトタイプの評価が済んだ後、その一部を捨てたり、変更したり、あるいはまったく新しい部分を追加したりする必要があるかもしれません。評価のプロセスを繰り返しても新しいアイデアが出てこなくなったり、少数の瑣末なアイデアしか出なくなったら、UIプロトタイプ作成のプロセスを終えるとよいでしょう。そうでなければ、UIに関する利害関係者のニーズの調査に戻ってください。

 

 

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。


推奨文献

 

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

 アジャイルモデリング

 

Let Us Help (以下、北米での話ですのでご注意ください)

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies.  We offer both consulting and training offerings.  In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

 

visits since November 17, 2003.