主語 ← ユースケースの最初の一歩

最近入った開発部隊で、ユースケースらしきものが作られていたが、どうにも酷すぎる。

最初のページにスティックマンを書いたら、残りのページのシナリオに何を書こうがOKなんて思ってるんだろうか・・・

ユースケースを知らないライタが命ぜられるまま書いて、それと同じくらいユースケースを知らないレビュアーが検定して、「どう役に立つか知らないけど、とりあえず何となく意味が通じない事もない気がする。スティックマンと楕円が、何となくユースケースっぽさをかもし出しているし。」みたいなレベルなのが見え見え。

これではいけないので、チェックリストを作って、ライタがレビュー前にそれを使って、ユースケースとしての最低レベルに自力で持って行けるようにしたい。レビュアーも自分が本来意識を向けるべきところにのみ集中できるはず。

という訳で、いつものとおり「まずは必ず他人の成果を利用する事から始める」ポリシーに従って、手持ちの本とかWebでみた資料をいろいろ思い浮かべる。で、Cockburn のユースケース本 に何かあったのを思い出し、実物を開いて裏表紙に載っている「Pass/Fail Tests for Use Cases Fields」 というリストを確認。

以下のような内容。
◆ Use Case Title
1. Is it an active-verb goal phrase that names the goal of the primary actor?
2. Can the system deliver that goal?

◆ Scope and Level
3. Are the fields filled in?

◆ Scope
4. Does the usecase treat the system mentioned in Scope as a black box?
5. If the system in Scope is the system to be designed, do the designers have to design everything in it and nothing outside it?

◆ Level
6. Does the use case content match the stated goal level?
7. Is the goal really at the stated goal level?

◆ Primary Actor
8. Does he/she/it have behavior?
9. Does he/she/it have a goal against the SuD that is a service promise of the SuD?

◆ Preconditions
10. Are they mandatory, and can they be set in place by the SuD?
11. Is it true that they are never checked in the use case?

◆ Main Success Scenario
15. Does it have 3-9 steps?
16. Does it run from trigger to delivery of the success guarantee?
17. Does it permit the right variations in sequencing?

◆ Each Step in Any Scenario
18. Is it phrased as a goal that succeeds?
19. Does the process move distinctly forward after its successful completion?
20. Is it clear which actor is operating the goal--who is "kicking the ball"?
21. Is the intent of the actor clear?
22. Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level?
23. Are you sure the step does not describe the user interface design of the system?
24. Is it clear what information is being passed in the step?
25. Does it "validate" as opposed to "check" a condition?

◆ Extension Condition
26. Can and must the system both detect and handle it?
27. Is it what the system actually needs?

◆ Overall Use Case Content
29. To the sponsors and users: "Is this what you want?"
30. To the sponsors and users: "Will you be able to tell, upon delivery, whether you got this?"
31. To the developers: "Can you implement this?"

ユースケースを書く上での重要なエッセンスだけ抽出した、非常に濃いチェックリストなんだけど、うーん・・・

これは、すでにある程度の経験を積んだ人か、少なくともこの本をじっくり読了した人になら有用だけど、未経験者にはほとんど意味が通じない予感（日本語に訳したとしても）。もうちょい機械的というか事務的に作業できるのを作る必要があるなあ。

まあ、それは後で何とかするとして、ユースケースに余り自信のない人は、とりあえず各ステップの主語をちゃんと書く事から始めるのがお勧め。ただし主語といっても、定義が若干あいまいな日本語文法のそれというより、英語のような動詞に対するものとしての主語。もう少し言うと、状態動詞ではなくて動作動詞で、さらに能動態の主語。

動作の主体、ボールをキックするその人、動きが生じて状況が前進する瞬間の主役を主語として、ステップを記述する。そうすると、ユースケースにまつわる他の事も分かってくる。つうかそれが駄目だと、ユースケース全体の他のすべての項目も多分駄目。

つうわけで、主語だけはしっかりと書くべし。まずはそこからだ。
・・・なんて、上から目線で言ってみる。