ユースケースを考える

　システム開発の上流工程の中で、要件開発からユーザーインターフェース設計への流れは、現実からシステムへの変換過程における「現実とシステムの変換点」と捉えることができます。また、要件開発に用いるユースケースは、「ユーザーとシステムとの接点」となります。ということは、ユースケース駆動開発という手法があるように、ユースケースはシステム開発における極めて重要な要素、システム開発の中心ともいうべき要素といえます。
　このような前提の基、私はユースケースを深める試行錯誤を行い、次のような整理をしました。

• まず、ユースケースの定義をRDRAの「人とシステムとの接点」とする。
• 次に、ICONIXプロセスを組み合わせ、ユースケースシナリオ、ロバストネス分析を行うことによって、ユースケースの粒度と質をそろえると同時に網羅性を検証する。＊これは、開発者の能力不足を補う意味もあります。

　ところが、あるプロジェクトで実践してみると、他のユースケースよりも粒度の大きなものがひとつだけ残りました。それは次のようなユースケースです。

　顧客の対応をする。

　これは、ユーザーが顧客の対応を行いながら、氏名などの基本となる顧客属性を入力したり、コミュニケーションの内容を記録したりする、複数の機能を必要とする作業です。粒度を他のユースケースとそろえることは簡単ですが、私はユーザーに示すユースケースとしては、この粒度の方が良いと考えました。

　それから数週間ほどの時間が経っていますが、この粒度の違いを正当化する論理を見いだせないでいました。しかし今朝、KenichiroMurata氏のブログ「UMLの参考書籍」を読んで、解決の糸口を見つけることができました。

　ユースケースは何を表すものか？　ユーザーがシステムから受けるサービスか？　それとも、ユーザーが使用する機能か？　そう考えた時、私は「ユースケースとはユーザーにとって魅力的なストーリーであるべきだ」と考えました。
　ユースケースは、ユーザー（要求者）と「何を作るか？」を決めるための重要なコミュニケーションツールであり、それはユーザーにとって魅力的であることが最も重要なはずです。なぜならば、これが実現すれば便利になる、楽になる、安くなる…　こうした魅力（価値）を感じなければ、ユーザーがシステム開発に参加する際のモチベーションが低下し、結果的に十分な問題領域の分析ができなくなってしまうリスクが高まるからです。

　さて、ここで疑問が生じます。であるならば、ユースケースを階層化すれば？

　なるほど、階層化すればボトムのユースケースの粒度は均一になります。しかし、私がユースケースを作る目的は、ユーザーにとって魅力的なシステムを実現するためであり、学術的であったり、規範に準拠することではありません。また、そもそも、ユースケースの粒度をそろえなければならない理由は何なのでしょうか？
　ユースケースポイントによりシステムの規模を見積もろうとするならば、粒度は一定である必要があります。しかし、ユースケースをストーリーとし、ストーリーポイントで相対的に規模を見積もるのであれば、粒度がそろう必要はないはずです。

　では、現時点での私の仮説を整理します。

• ユースケースとは、ユーザーにとって魅力的なシステムとの接点である。
• この段階での規模見積もりにストーリーポイントを採用するのであれば、ユースケースの粒度は無視できる。
• ユースケースシナリオとロバストネス分析は、要件開発段階ではユースケースを深めるための手段であり、プロジェクトやプロダクトの特性によりその使用を判断する。

　この仮説に従い、しばらく検証を続けたいと思います。