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

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

by Scott W. Ambler, Copyright 2003

ユーザインターフェース (UI) は、ソフトウェアのうちユーザが直接対話する部分です。本質ユーザインターフェースプロトタイプ (essential user interface prototype) (Constantine and Lockwood 1999)は、システムのUIの、大雑把なモデル(プロトタイプ)です。UIの背後に存在する概略の考え方を表しますが、正確な詳細までは表現しません。本質ユーザインターフェースプロトタイプ(以下、本質UIプロトタイプと略)では、ユーザインターフェース要求を技術に依存しない形で表します。これは、振る舞い要求の場合の本質ユースケースモデルと同じです。本質UIプロトタイプは、事実上、システムのUIプロトタイプの初期状態、つまり開始点となります。ここではUIに関する要求をモデリングしますが、この要求は分析・設計を通じて発展し、最終的にはシステムのUIとなります。

本質UIプロトタイプの作成には、従来型のUIプロトタイプの作成と比べて、根本的に2つの違いがあります。1つめに、本質UIモデリングでは、システムの機能ではなく、ユーザとシステムの使い方に着目することが目的となっています。これは、本質ユースケースモデリングと本質UIプロトタイプ作成を連携して行う理由の1つです。それぞれが使い方に着目しているのです。2つめに、プロトタイプを作成するための道具がシンプルなことです。たとえば、ホワイトボード、模造紙、付箋などを使います。プロトタイプ作成の作業に電子的な技術を取り入れると、その瞬間におそらく、実装技術に関して設計上の判断をしてしまうことになります。たとえば、UIプロトタイプを構築するのにHTML開発ツールを使うと、それだけで、設計空間がブラウザのサポートしている機能に限定されるかもしれません。Java開発環境を選んだ場合にはJavaに、Windowsベースのプロトタイプ作成ツールを選んだ場合にはWindowsプラットフォームでサポートされているものに、デザインの範囲が限定されるかもしれません。今は設計ではなく要求に焦点を合わせるべきです。そのため、技術をベースとしたプロトタイプ作成ツールはまだ使いたくありません。まず問題を理解し、それからそれを解決してください。

では、付箋と模造紙を使ってどのように本質UIプロトタイプを作成するのでしょうか。まず、用語をいくつか定義しましょう。主UI要素は粒度の大きな項目を表します。おそらく、画面やHTMLページ、レポートなどがそれにあたります。副UI要素は、粒度の小さな項目を表します。ユーザ入力フィールドやメニュー項目、リスト、ラベルなどの静的テキストフィールドといった画面部品がそれにあたります。チームで本質UIプロトタイプを作成するときには、以下の作業を反復的に行います。

  1. システムの利用法を調査する:システムの利用法をさまざまな方法で調査します。まず、おそらくホワイトボードを囲んでアイデアを議論し、皆で初期の図を描き、たいていはホワイトボードの書き換えやすい性質を利用して、システムの議論の対象となっている部分を手早く理解していきます。たとえば大学システムの場合、ホワイトボードの周りに集まって、大学の成績証明書には何が書かれているか、ゼミ登録を提出するには何が必要かについて、初期の図を作成します。次に、システムの振る舞い要求について理解を深めていきますが、これまで見てきたように、そのときには本質ユースケースモデリングの手法が効果的です。

  2. 主UI要素をモデリングする:画面候補やレポート候補などの主UI要素は、模造紙を使ってモデリングすることができます。「候補」と言ったのは、あるものが画面になるか紙のレポートになるかは設計時に判断することだからです。大学の成績証明書は、ブラウザ上で見ることのできるHTMLページとして実装することもできれば、印刷して学生に郵送される書類として、あるいはアプリケーション画面として実装することもできます。模造紙にはそれぞれ、「学生成績証明書」や「ゼミ登録依頼」などといった名前を付け、必要に応じて適切な副UI要素を追加します。模造紙には利点がいくつかあります。まず、壁にテープで貼ることができます。また、皆で見たりやり取りしたりしやすいためグループでの作業に適しています。十分な大きさがあるので付箋などの小さいものを多数貼り付けることができます。絵を書くことができます。それに、モデリングセッションを行なっていないときは片付けることができます。

  3. 副UI要素をモデリングする:入力フィールド、リスト、コンテナ(他の副UI要素を1つにまとめる副UI要素)といった副UI要素は、付箋を使ってモデリングします。ConstantineとLockwood(1999)は、コンポーネントの種類ごとに違う色の付箋を使うよう提案しています。たとえば、入力フィールドなどの能動的なUI要素には明るい色(黄色や赤)を、コンテナなどの受動的インターフェース要素には柔らかな色(白やベージュ)をといった具合です。図1は学生をゼミに登録するための本質UIプロトタイプを示しています。「学生名」という付箋は、「姓」「名」「ミドルネーム」「肩書き」という4つの能動的要素を含んだコンテナです。別の付箋は学生が過去に取ったゼミや現在登録しているゼミの一覧を表しています。それぞれの付箋には、実装方法ではなく目的を表す名前が付けられていることに注目してください。付箋を見れば、どのように使われるかがすぐに分かります。さまざまなサイズの付箋を使って、各UI要素の相対的なサイズを表します。また、UI要素の相対的な順序も付箋の順序によって示されています。学生の肩書きがまずあって、それから名、ミドルネーム、姓と続きます。この順序は設計時に変わるかもしれませんが、今のところはこれで十分正確です。副UI要素が必要かもしれないと気づいたら、付箋を取り出し、適切な名前を付けて、利害関係者がここだと思う主UI要素上の大体の場所に貼り付けます。ときには、副UI要素を置く主UI要素がない場合があります。気にしないでください。これは反復的なプロセスなのですから、適当な主UI要素を見つけて先に進んでください。実際に付箋は本物のGUI部品には見えないので、構築しているのがUIの抽象モデルであって実物ではないことを、チームは常に思い出すことになります。各付箋は事実上何かがそこにあるという位置取りなのですが、どう実装すれば一番よいかはまだ分かっていません。ですから、今のところは未決定のままにしておくとよいでしょう。

  4. UIの使いやすさを調査する:使いやすいシステムとは、身につけやすく、ユーザの生産性を上げ、使い方を覚えやすく、維持しやすいシステムです。

 

 

図1. ゼミに登録するための本質UIプロトタイプ

では、図1についてさらに詳しく見ていきましょう。このプロトタイプは標準的な模造紙で作られています。主UI要素ごとに1枚の模造紙を使用します。名前(この場合なら「ゼミに学生を登録する」)は、通常一番上に書きます。2つのコンテナがありますが、これは紙に線を引いてUIの別々のセクションをまとめたものです。「学生番号」や「学生名」などのピンクの付箋は入力フィールドを表し、黄色の付箋は表示専用であることを表しています。「学生名」について興味深いのは、少しごまかして、1枚の付箋に4つの異なるデータ要素を並べていることです。必ずまとまって現れるものについては、たいてい私はこのようにします。また、スペースが必要になると思われる場合もです。この図を見ると分かるでしょう。「検索」「ヘルプ」といった青の付箋はアクション項目を表します。アクション項目は多くの場合、ボタンやファンクションキー、あるいはCTRL-SHIFT-Sなどといった「ホットキー」の組み合わせとして実装されます。リストはすべて、リスト内の情報の選択が可能です。選択をサポートしていないリストの場合は、そのことを示すべきです。

本質UIプロトタイプがどのように使われるかを、私はよく質問します。たとえば、学生が現在満員のゼミに真剣に登録したいとするとどうなるでしょうか。順番待ちをすることはできるのでしょうか。できるのならUIはどう変えなければならないでしょうか。おそらく、既に待ち状態にある人の数を表示する機能が必要になるでしょうし、順番待ち名簿に追加したり名簿から削除したりする方法も必要でしょう。ゼミを教える教授に関する詳細情報を見られるようにすべきでしょうか。前提条件一覧に含まれるゼミに関する詳細情報を見られるようにすべきでしょうか。図1では、番号や名前を入力してゼミを検索できることが分かります。ゼミを開催している学部から検索できるようにすべきでしょうか。あるいは、開催される曜日ではどうでしょうか(私は学生のときに1時間半をかけて通学していたので、できるだけ同じ曜日のゼミを取ろうとしていました)。教える教授ではどうでしょうか。これらはいずれも興味深い質問で、答えによっては新しい要求が見つかることになります。ただし、正式に要求を出すのはプロジェクトの利害関係者であって、開発者ではないことを忘れないでください。必要ではないかと思われる新しい機能が見つかったら、それがいい考えだと利害関係者を納得させ、優先度をつけてもらって、新しい要求を山に追加する必要があります。アジャイルモデリングの「利害関係者の積極的な参加」のプラクティスに従っているなら、これはとても簡単なことです。というのも利害関係者は初めからモデリングの作業に参加しているからです。

ここまで、言われたとおりに、主UI要素をどう実装するかを示さないようにしてきました。現実には、ゼミ登録プロトタイプが画面あるいはHTMLページとして実装されることが分かっています。それならなぜそれを認めないのでしょうか。主UI要素に編集が可能な副UI要素が含まれているなら、それは画面かHTMLページになります。編集可能な要素がなければレポートになるでしょう。主UI要素を実装技術と切り離しておくために、多大な「不自然な」努力をしているのなら、少し制約を緩めて、レポートと画面やHTMLページとを区別してもかまいません。実際、システムをどう配置するかというアーキテクチャ上の決定がなされてしまえば、私はたいていホワイトボード上に画面の絵を書いて、画面やレポートがどのようなものになるかの図をより正確に書けるようにします。ただし、いつも言うことですが、必ず状況に応じてもっとも適切なツールや技術を選択してください。

 

 

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


推奨文献

Information Modeling and Relational Databases

 

本質モデリングに関してはこの本を読んでください。

 

その他の文献

アジャイルモデリング(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.