システムまわりの仕事をするときは、クライアントの要求をヒアリングしたり、こちらからシステムイメージを提案したりしながら、まずはユースケース図をまとめることが多いです。
でも、このユースケース図っていうのが、最初は書くのが難しいんですよね。いや、べつに作図のルールやツールの使い方が難しいわけじゃなくて。そのへんは逆に簡単なんです。あんなもの、いってみれば、子供の落書きみたいなもんで、かかしみたいな貧相なキャラにフキダシをくっつけるだけですからね。でも、絵心じゃなくて、ユースケース心がない人が書くと、ほんとシュールな出来映えになります。真っ白なところにポツンとかかしが立ってて、「メールを受け取る」なんてね。一見して、ガハハ、だめだこりゃ、とかいっちゃいそうになります。
でも、あれは、実はそこがいいところなんですよね。下手だと全然それらしく見えない。クラス図とか、シーケンス図とかは、結構目くらましなところがあって、よくよく見るとなんか変なことが書いてあっても、ぱっと見はなんだかよさげに見えてしまったりします。あと、なんかごちゃごちゃと書いてある箇条書きとかね。少なくとも、だいぶ苦心してんだな、みたいなことは伝わってきたりして。でも、ユースケース図の出来上がりには書き手の苦労なんてちっとも滲まず、実にあっけらかんとしてますからね。
つまり、それだけに、伝えようとしている内容そのものの真価を問いやすい作図法といえるんじゃないでしょうか。適当にやっつけで書くのが難しい。
ユースケース図は、それによって何を表現しようとしているのか、とか、どんな効用が期待されるドキュメントなのか、なんてところをちゃんと確信できていないと上手く書けないかも知れませんね。
まずつまづくのは、どれくらいの粒度で書くかってことだったりしますが、粒度の決定については、次にあげる必要に応じることが根拠になるんだと思います。
ユースケース図の、特に初期のバージョンは、システムの輪郭をクライアントと開発チームの間で共有するために書くんだと思います。それは、範囲の限定と中心の特定といっていいでしょう。
出来上がったシステムを後でユースケース図に還元したようなものがはじめから欲しいわけじゃないですし、また、そんなの書けるわけがない。これからはじまるシステム設計の、進むべき道を照らし出したいわけです。
なにしろ、こういうシステムを作るんだって説明を受けるほうの身になって考えて、彼らが頭に入れやすいシステムイメージを描くことが先決です。そうすると、自然、中心近くのユースケースの粒度は比較的詳細になっていくでしょう。そこには、聞く人になるほどと思わせるような、ロジックやメカニズムが描かれている必要があります。人がなるほど、とか、わかったと思えるのは、複数の項目の関係の仕方が書かれているからなんですよね。ポツンと「メールを受け取る」とか書かれていてもだめなんです。
逆に、周辺は中心から遠ざかるほどに粗くなっていくでしょう。全部いっぺんに頭には入らないですからね。ただし、範囲を明らかにするためには、粗くても欠落していてはいけません。だから、粗いけれどもきちんと数え上げられているか、ということが問われてきます。
そして、この中心と周辺の落差が、今後の開発の方向づけにもなるわけです。ディレクションという言葉には、たしか方向づけという意味もあったと思います。システムに対する要求や要件をまとめる仕事なんて、なんとなく SE 的と思いがちでけれども、そういうふうにユースケースの意義を確かめていくと、案外、システムエンジニアというよりも、むしろディレクターと呼ばれる職域にこそふさわしいタスクかもね、なんて思わないでもありません。
-----------------
sent from W-ZERO3
0 件のコメント:
コメントを投稿