UML：ユースケースは、コミュニケーションツールです

　誰とコミュニケーションするかって? それは、書いた人と読む人だけでなく、書く人とシステムそのものをコミュニケートするツールともいえます。

　つまりこういうこと。最初にユースケースが描かれるとき、「システム」へ何を期待するかは必ずしも100%決まっているわけではありません。分析を繰り返していくうちに、ユースケースを書き換え/書き足していくうちに、書き手は「システム」がどうふるまうべきなのかを知るのです。

　ユースケースは読まれることを前提に書かれるべきです。かなりの書き手はこの大切な事実を見逃しています。レベルは最も低いレベルに合わせるべきです。最も低いレベルは、おそらく顧客(発注者)でしょう。顧客は、システムへの要望は把握しているが、そのためにシステムが何をしなければよいか分からないからです。

　ユースケースの書き手は、システムがどう振舞ってほしいのかを、外側(アクター)から見ても理解できる形、粒度で書きます。そうすることで、真に理解してもらうべき顧客(アクターが何を期待しているのか押さえている人)に分かってもらえるのです。

　ユースケースはいつまで更新されつづけるべきなのでしょうか? ユーザーレビューをするたびにユースケースの追加が起きているのであれば、顧客はRFP(request for proposal)をまとめられないということです。RFPをまとめきれない顧客は、往々にしてその組織体制に問題があることは経験的に自明です(そんな担当にRFPを任せているという致命的な問題も含む)。その場合は、残念ながら頑張って顧客よりも業務に詳しい人になるか、業務担当と裏で通じるしかありません。

　いずれにせよ、顧客(または業務部門の人)から「システムに期待する振舞い」が全て明らかになり、顧客自身の口からその機能が説明できるような段階になれば、ユースケース分析の段階は完了したといえるでしょう…
















さて、この記事、どこから理想論となっているでしょう?

• どこも理想論ではない
  
• 最初のパラグラフから
  
• 最後のパラグラフから
  
• 題名から理想論だよもん
  

*この記事では「ユースケース」とは「ユースケースシナリオ」および「ユースケース図」の意味で書きました

**このアタリマエな事実を、私はよく忘れます。自戒の意味でアップして、ときどき読み返すことで、1を目指します
--