良いユースケースと悪いユースケース
開発者は、細かいことまでユースケースに書き込みがち
Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者&LSI設計者のためのUMLガイド」という冊子(以下、UMLガイド)に、自動販売機のユースケースの例が載っていますので、紹介しましょう。
自動販売機の仕様を決めるにあたって、どのようなユースケースを書けば良いでしょうか。
UMLガイドには、間違ったユースケースの書き方として、下記の例が載っています。
この例のように、開発者は、システムの詳細な機能やモジュール構成など、細かいことまでユースケースに書き込んでしまうことが多いようです。これからどうやってシステムを作っていけば良いかを、どうしても考えてしまうためでしょう。
しかし、仕様を決めるために書くユースケースは、アクターが本当にやりたいことを、アクターの視点から示すものでなければなりません。
無意味なほどシンプルなのが、良いユースケース!?
自動販売機の正しいユースケースとして、UMLガイドでは下記の図が紹介されています。
正しいユースケースは、拍子抜けするほどシンプルなものになることもあります。
とはいえ、「商品を購入する」としか書かれていないこのユースケースが、正しい、と言われても、ピンとこない開発者も多いことでしょう。
このユースケースを渡されて、「ユースケースはできたから、さっそく作り始めよう」と言われても、困ってしまいます。そもそも、こんなもので仕様が決まったと言えるのでしょうか?
もちろん、このユースケースは、自動販売機の仕様をすべて表してはいません。自動販売機を作るのであれば、これから、膨大な機能仕様を決めていかなくてはならないでしょう。
だったら、こんな絵を書いている暇があったら、最初から詳しい機能仕様書を書いていった方がマシ、と思うかもしれません。
しかし、そう思うのは、ユースケースの目的を誤解しているためです。
役に立つユースケースとは何か
ユースケースの目的は、できないことを決めること
ユースケースとは、アクターがシステムを使って何ができるか、を表したものです。しかし、それをユースケースの目的だと考えてしまうと、却ってうまくいきません。
そこで、発想の転換をします。ユースケースの目的は、むしろ、システムを使って何ができないのか、を決めることにある、と考えるのです。そう考えることで、ユースケースを書く意味が見えてきます。
システムの要求仕様を決める手順を思い返してみましょう。まずは、顧客から話を聞いて、顧客が何を求めているのかを把握します(要求分析)。次に、顧客の要求の中から、実際にシステムとして作るものを決めます(要件定義)。
たいてい、開発するシステムは、顧客の要求をすべて叶えるものにはなりません。スケジュールや予算の都合だったり、別のシステムを使ったり、人間がコンピュータを使わずに行う方が良かったり、理由はさまざまですが、いずれにせよ、開発するシステムは、顧客のワークフローの一部分だけを担うものとなります。
そのため、システムの要求仕様を決める上では、どこからどこまでがシステムで扱う範囲なのか、を明確にすることが大切です。即ち、ワークフローにおけるシステムの位置付けや、システム外部との境界を決めること、これが、ユースケースの目的です。
さきほどの自動販売機の例で言えば、ユースケースは、自動販売機を使って『「商品を購入する」ことしかできない』、ということを表しています。
自動販売機では、何ができないのかを考える
自動販売機についてもっと広く考えると、例えば、メンテナンス担当者が
- 売上金を取り出す。
- 釣銭を補充する。
- 商品を値上げする。
といったことも、できた方が良いかもしれません。
しかし、ここで開発しようとしている自動販売機のシステムでは、こうしたことはできません。それを表しているのが、さきほどのユースケースなのです。
おそらく、売上金を取り出したり、釣銭を補充するのは、自動販売機の筐体の後ろの扉を開けて、物理的にお金を出し入れすることになるでしょう。
商品を値上げするのは、かなり難しそうです。ROMを差し替えることになるかもしれません。しかし、それは今は考えない、という訳です。
自動販売機のユースケースのあるべき姿
このように、広く浅く考えを広げて、顧客の要求をなるべく拾い上げてから、その上で、実際に開発するシステムの範囲を限定する、というアプローチを採ると、ユースケースを書きやすくなります。
範囲を限定した結果がユースケースに示されているので、一見、無意味なほどシンプルに見えるのです。
しかし、「商品を購入する」とだけ書かれたユースケースから、背後に隠されたできないことまでを読み取るのは、確かに難しいです。
そこで、ユースケースには、要求分析で挙がったユースケースをすべて残しておき、その中で、要件定義で限定したシステムの範囲を、システム境界として示すようにすると良いでしょう。
さきほどの自動販売機の例では、下記のようなユースケースを書いておくと良いでしょう。
視野を広げて、良いユースケースを書こう
ユースケースを書く時は、システムの内部を詳しく分析するのではなく、システムのまわりに広がる外の世界を考える、という発想が必要です。
ユースケースは、システムと外の世界との境界を決めることが目的です。システム境界について、顧客との間に意識のずれがあると、顧客の望むものとは根本的に違った別物を作ってしまうことになります。
詳しい機能仕様書を書くのは、システム境界について、顧客ときちんと合意できてからの話になります。