「ユースケースの整理はどの工程の作業か」という問いがある。 答えは「主に要件定義」だが、それだけでは足りない。 ユースケースの記述は、ひとつの文書の中で要求・要件・仕様の3層にまたがりうるからである。
この混乱は、4層モデルとは別にもうひとつの軸が存在することに由来する。 層は文書の高さを扱い、目的レベルは1つの層の中の粒度を扱う。 2つは直交しており、混ぜると判断できなくなる。
「なぜ工程として必要なのか」で層と工程を切り分けたのと、同じ形の議論である。 あちらを混ぜると「アジャイルなら層は不要」という誤った結論に落ちた。 こちらを混ぜると、粒度の不揃いを層の問題として誤診する。
| 軸 | 問い | 単位 | 判定基準 |
|---|---|---|---|
| 層（高さ） | どの抽象度の話か | 要求／要件／仕様／設計 | 誰が検証するか |
| 目的レベル（粒度） | 何を1件と数えるか | Cloud／Kite／Sea／Fish／Clam | 誰の、どれだけの目標か |
同じ層の中に複数の粒度が並びうるし、同じ粒度が層をまたぐこともある。 片方だけを整えても文書は読みやすくならない。
なお目的レベルは Alistair Cockburn による整理であり、 本ハンドブックはそれを4層モデルに重ねて用いている。 Cockburn 自身の関心は読みやすいユースケースを書くことにあり、工程や層の分類ではない。 したがって以下の対応づけは本ハンドブックの解釈である。
| レベル | 内容 | 層 | 扱い |
|---|---|---|---|
| Cloud（雲） | 事業レベルの目的 | 要求より上 | 参照するが書かない |
| Kite（凧） | 業務全体の流れ。複数の関係者にまたがる | 要求 | 背景・文脈として |
| Sea（海面） | 1人のアクターが1回で達成する目標 | 要件 | 合意の単位 |
| Fish（魚） | Sea より下位の手続き | 要件の内訳または仕様 | 条件付きで立てる |
| Clam（蛤） | 低すぎるもの | 設計 | ユースケースとして書かない |
検証者が一致するためである。
要件の検証者は発注者と開発者の双方だった。 「この一覧で要求が満たせるか」を両者が判定できる粒度が Sea であり、これは偶然ではない。 Sea は「一人のアクターが一区切りの仕事として完了できる単位」であり、 業務として意味があり（発注者が判定できる）、かつ実現手段が見通せる（開発者が判定できる）。
Kite は業務全体の流れであり、開発者は実現可能性を判定できない。 Clam は実装の細部であり、発注者は必要性を判定できない。 双方が判定できる唯一の粒度が Sea である。
4層モデルの中で要件だけが検証者を2人持つことと、これは対応している。 要件は業務判断と技術的実現性が交わる層であり、どちらか一方では決めきれない。
どちらも「書かないもの」だが、載せる価値がある。越境の検出器になるためである。
ユースケース一覧に「不正アクセスを防ぐ」があれば、それは Cloud であり要求層の話が紛れている。 「パスワードをハッシュ化して保存する」があれば、それは Clam であり設計層に落ちている。
いずれも粒度が不適切なのではなく、層が違う。 粒度の問題に見えて層の問題であるものを、この2つが拾い上げる。
対応表の中で、Fish だけが行き先を1つに定められない。 要件の内訳になることも、仕様に降りることもある。
理由は、Cockburn の軸と4層モデルの軸が完全には一致しないためである。 目的レベルは「目標の大きさ」で切り、層は「誰が検証するか」で切る。 両者はおおむね相関するが一致はしない。 Sea と Kite の境界が比較的くっきりしているのに対し、Fish だけが両側にまたがるのはこのためである。
Fish が揺れるのは道具の性質であって、書き手の未熟ではない。
Fish をいつ立てるか、立てたものがどの層に属するかの判断は、 分量と性質が異なるため「Fish の線引き」で別に扱う。
層の判定を「発注者が読むかどうか」で決めようとすると失敗する。 発注者は仕様書も設計書も読み、承認する。それは通常の手順である。
| 承認 | 検証 | |
|---|---|---|
| 誰が | 発注者 | 各層の検証者 |
| 何をするか | この内容で進めてよいと合意する | 作られたものが決めたとおりか確かめる |
| いつ | 工程の区切り | テスト時 |
発注者は全層を承認しうるが、検証できる層は限られる。 4層モデルの検証者の表が示しているのは後者だけである。
なお仕様の検証者である「レビュアー・テスター」は開発側の人を指す。 V字モデルで仕様に対応するのは結合テストであり、これを実行するのは開発側だからである。 発注者が仕様書を承認することと、仕様の検証者が開発側であることは矛盾しない。
網羅性を判定できなくなる。
Sea と Fish が同じ階層に並んでいると、ある業務が一覧に見当たらないとき、 抜けているのか、どこかの Sea の下位に畳まれているのかを読み手が区別できない。 一覧の行数は増えるのに、確からしさは下がる。
ユースケース整理という作業の実質は、このレベルを揃えることにある。 数を増やすことでも、細かくすることでもない。
粒度が揃っていれば、一覧を見て「この業務がない」と言える。 揃っていなければ、何も言えない。
| 内容 | |
|---|---|
| 前提 | 要求の成功基準が決まっていること。誰が何を達成したら成功かが、アクターと目標の抽出源になる |
| 主工程 | 要件定義 |
| 成果物 | ユースケース一覧と記述。要件定義書の構成要素であり、要件そのものではなく要件を漏れなく出すための道具 |
| 引き渡し | 各ユースケースのステップが、画面仕様・API仕様の単位になる |
要求の成功基準が未確定のままユースケースを書き始めると、 アクターと目標を書き手が想像で決めることになる。 このとき作られた一覧は網羅的に見えるが、何に対して網羅的かを誰も言えない。
成果物の位置づけには注意が要る。 ユースケースは要件を出すための道具であって、要件そのものではない。 一覧が埋まったことと、要件が揃ったことは別である。
この判断は誰が検証するのか。 層を決めるときの問いはここでも変わらない。 粒度はその問いに答えるための、もうひとつの目盛りである。