ユーザー要件を引出すテクニック： ユースケースかストーリーボードか：The Rational Edge（1/2 ページ）

反復開発実践者の間では、ユーザー要件を引き出すテクニックとしてのユースケースとストーリーボードの利点に激しい議論が集中している。

　機能はITシステムを成功させるために重要な要因の1つだ（最も重要だとする声もある）。ユーザーは、自分たちの仕事が楽に、早く、確実に片付くよう、ITシステムが支援してくれることを期待している。ユーザーは、ヒューマン・コンピュータ・インターフェイス（HCI）経由でシステムと対話するが、1990年代前半にGUIが台頭したことで、多くのユーザーが自分たちのニーズやシステムとの対話方法に対する希望を明確に示すようになった。ソフトウェアエンジニアリングにおけるHCIに重点を置いた場合、そこには解決しなくてはならない2つの問題がある。a）一般に、ユーザーはユーザビリティの専門家ではないこと、そして、b）ソフトウェアエンジニアはHCIの内側にある機能を特定し、それを構築しなくてはならず、HCI自体のユーザビリティはあまり気にしないのが一般的だ。本稿では、ユーザーがHCIを通じて視覚化し、考えながらシステムの機能を特定するのに有効なテクニックを紹介する。

ノート：GUIと、より一般的なHCIの概念との違いは、多くの読者にとってあまりはっきりしないかもしれない。しかし、さまざまな理由（例：パフォーマンスやサイズ）から、ITシステムすべてにGUIが搭載されているわけではない。例えば、コマンドや音声ベースのインターフェイスを搭載しているシステムもある。本稿で紹介するテクニックはたまたまGUIベースの例を使っているが、GUIは、人間とコンピュータが対話するために数多く存在する手法の1つにすぎない（身体障害者が利用できるアプリケーションの開発に関する特集記事などを参考にされたい）。このような理由から、筆者はHCIとGUIの2つのコンセプトを分けることにした。肝心なのは、HCIには多数の形態があり、GUIはその一例だということだ。

◆ 機能性と人間性

　GUIにおいては、不要で好ましくない情報を過剰に提供することなくユーザーが自分の作業をこなせるよう、論理的でビジュアルな流れで機能の論理セットがグループ化され、可視化される。アプリケーションが起動すれば、ユーザーにはシステムとの対話を可能にするウィンドウ、コマンドライン、Webページといった何らかの形態のHCIしか見えない。これでは、ユーザーには技術的な詳細を覆い隠してしまうHCIがシステムのように見えてしまう。例えばユーザーは、システムの内部を理解していなくても、ボタンをクリックすれば関連付けられたリクエストが実行されるものと期待する。

　筆者は、新しいシステムのビジュアルなプロトタイプをユーザーと共同開発した数年前、ユーザーの期待と、ソフトウェアエンジニアの設計上の考えとの間に明確な違いがあることに気付いた。筆者は、自分でできる部分の作業を進め、数日でプロトタイプを用意し、GUIにマッピングした業務フローを提案した。ユーザーはこのプロトタイプに対して非常に期待を高め、「システムはいつ用意できるのか？」と聞いてきた。画面のデータは画面に直接書き込まれたもので、機能もデータベースもない、と筆者が説明したときの彼らの落胆の大きさは想像がつくだろう。このHCIが実際に機能するシステムだとユーザーが思っていたことは、その後になって分かった。しかし、一般にオブジェクトモデルで示される実際の業務ロジックはまだ未開発でGUIともリンクされておらず、「見えない」オブジェクトモデルがないことにはHCIを用意できないことを説明するのは難しかった。

　ほかにも、これらのユーザーからシステムとの対話やウィンドウの表示を切望する声があった。これらのウィンドウは、メインフレームでよく見られるような情報と単純な入力フィールドで埋まった。

　しかし、いくらHCIが素晴らしくても、ユーザーの関心を長期的には引き留めておけない。「この注文に対する領収書はどのように出すのだろう？」あるいは「マネージャはどこで5000ドル以上の注文を承認するのだろうか？」といった疑問がすぐに出てくる。エンドユーザーがプロセスの流れをイメージするのは、HCIの助けがなくてはかなり難しい。彼らが機能に関するブレインストーミングをシステム開発後に行うのには、このような理由もあるのかもしれない。その時点では、当初設計した要件がソフトウェアとなり、ユーザーもそのソフトウェアを理論としてではなく実際のシステムとして体験済みで、システムの実際の使い勝手を説明できるようになっている。もちろん、機能に関するブレインストーミングが開発サイクルの終わりで行われるというリスクは、反復開発手法によって低減できる。

　もう1つ、特に業務ITシステムにとって大きな理由は、アプリケーションが業務ワークフローを効率化するためのツールとして考えられる点だ。好奇心の強いユーザーは、メリットや影響を専門家に慎重に評価してもらう。例えば、なぜユーザーは机の上にあるコンピュータの横にいまも計算機を置いているのだろうか？ 目の前にあるITシステムでは素早く簡単に計算できないことも理由の1つかもしれない。これは機能とHCIが、目の前にある当初からのワークフロー実現手段（この例では計算機）を捨てるようユーザーを説得できなかったケースだ。

　人それぞれではあるものの、筆者の経験では、エンドユーザーはITシステムの構築が楽しいとは思わないのが普通だ。彼らは新しいITシステムが必要であることは分かっていて、開発を進めるに当たりソフトウェアエンジニアに協力するが、要件定義や設計レビューの部分に関してはあまり関心が高くない。要件の収集が彼らの専門であることはまれで、おそらくITの専門用語を学ぶことにも関心がない。また、その必要もないだろう。そこで、ユーザーの一連のニーズを管理し、ユーザーに分かりやすい言葉で対話するのは業務アナリストやソフトウェアエンジニアの仕事になる。