良いユースケースを書くための発想法

開発者は、細かいことまでユースケースに書き込みがち

Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者＆LSI設計者のためのUMLガイド」という冊子（以下、UMLガイド）に、自動販売機のユースケースの例が載っていますので、紹介しましょう。

自動販売機の仕様を決めるにあたって、どのようなユースケースを書けば良いでしょうか。

UMLガイドには、間違ったユースケースの書き方として、下記の例が載っています。

この例のように、開発者は、システムの詳細な機能やモジュール構成など、細かいことまでユースケースに書き込んでしまうことが多いようです。これからどうやってシステムを作っていけば良いかを、どうしても考えてしまうためでしょう。

しかし、仕様を決めるために書くユースケースは、アクターが本当にやりたいことを、アクターの視点から示すものでなければなりません。

無意味なほどシンプルなのが、良いユースケース!?

自動販売機の正しいユースケースとして、UMLガイドでは下記の図が紹介されています。

正しいユースケースは、拍子抜けするほどシンプルなものになることもあります。

とはいえ、「商品を購入する」としか書かれていないこのユースケースが、正しい、と言われても、ピンとこない開発者も多いことでしょう。

このユースケースを渡されて、「ユースケースはできたから、さっそく作り始めよう」と言われても、困ってしまいます。そもそも、こんなもので仕様が決まったと言えるのでしょうか？

もちろん、このユースケースは、自動販売機の仕様をすべて表してはいません。自動販売機を作るのであれば、これから、膨大な機能仕様を決めていかなくてはならないでしょう。

だったら、こんな絵を書いている暇があったら、最初から詳しい機能仕様書を書いていった方がマシ、と思うかもしれません。

しかし、そう思うのは、ユースケースの目的を誤解しているためです。

ユースケースの目的は、できないことを決めること

ユースケースとは、アクターがシステムを使って何ができるか、を表したものです。しかし、それをユースケースの目的だと考えてしまうと、却ってうまくいきません。

そこで、発想の転換をします。ユースケースの目的は、むしろ、システムを使って何ができないのか、を決めることにある、と考えるのです。そう考えることで、ユースケースを書く意味が見えてきます。

システムの要求仕様を決める手順を思い返してみましょう。まずは、顧客から話を聞いて、顧客が何を求めているのかを把握します（要求分析）。次に、顧客の要求の中から、実際にシステムとして作るものを決めます（要件定義）。

たいてい、開発するシステムは、顧客の要求をすべて叶えるものにはなりません。スケジュールや予算の都合だったり、別のシステムを使ったり、人間がコンピュータを使わずに行う方が良かったり、理由はさまざまですが、いずれにせよ、開発するシステムは、顧客のワークフローの一部分だけを担うものとなります。

そのため、システムの要求仕様を決める上では、どこからどこまでがシステムで扱う範囲なのか、を明確にすることが大切です。即ち、ワークフローにおけるシステムの位置付けや、システム外部との境界を決めること、これが、ユースケースの目的です。

さきほどの自動販売機の例で言えば、ユースケースは、自動販売機を使って『「商品を購入する」ことしかできない』、ということを表しています。

自動販売機では、何ができないのかを考える

自動販売機についてもっと広く考えると、例えば、メンテナンス担当者が

• 売上金を取り出す。
• 釣銭を補充する。
• 商品を値上げする。

といったことも、できた方が良いかもしれません。

しかし、ここで開発しようとしている自動販売機のシステムでは、こうしたことはできません。それを表しているのが、さきほどのユースケースなのです。

おそらく、売上金を取り出したり、釣銭を補充するのは、自動販売機の筐体の後ろの扉を開けて、物理的にお金を出し入れすることになるでしょう。

商品を値上げするのは、かなり難しそうです。ROMを差し替えることになるかもしれません。しかし、それは今は考えない、という訳です。

自動販売機のユースケースのあるべき姿

このように、広く浅く考えを広げて、顧客の要求をなるべく拾い上げてから、その上で、実際に開発するシステムの範囲を限定する、というアプローチを採ると、ユースケースを書きやすくなります。

範囲を限定した結果がユースケースに示されているので、一見、無意味なほどシンプルに見えるのです。

しかし、「商品を購入する」とだけ書かれたユースケースから、背後に隠されたできないことまでを読み取るのは、確かに難しいです。

そこで、ユースケースには、要求分析で挙がったユースケースをすべて残しておき、その中で、要件定義で限定したシステムの範囲を、システム境界として示すようにすると良いでしょう。

さきほどの自動販売機の例では、下記のようなユースケースを書いておくと良いでしょう。