---
note: 層は誰が検証するかで切り、粒度は何を1件と数えるかで切る。直交する2つの軸
created: 2026-08-08T23:10:21+09:00
---

# 層と粒度は別の軸である

「ユースケースの整理はどの工程の作業か」という問いがある。
答えは「主に要件定義」だが、それだけでは足りない。
ユースケースの記述は、ひとつの文書の中で要求・要件・仕様の3層にまたがりうるからである。

この混乱は、**4層モデルとは別にもうひとつの軸が存在する**ことに由来する。
層は文書の高さを扱い、目的レベルは1つの層の中の粒度を扱う。
2つは直交しており、混ぜると判断できなくなる。

「なぜ工程として必要なのか」で層と工程を切り分けたのと、同じ形の議論である。
あちらを混ぜると「アジャイルなら層は不要」という誤った結論に落ちた。
こちらを混ぜると、**粒度の不揃いを層の問題として誤診する**。

## 2つの軸

| 軸 | 問い | 単位 | 判定基準 |
|---|---|---|---|
| 層（高さ） | どの抽象度の話か | 要求／要件／仕様／設計 | 誰が検証するか |
| 目的レベル（粒度） | 何を1件と数えるか | Cloud／Kite／Sea／Fish／Clam | 誰の、どれだけの目標か |

同じ層の中に複数の粒度が並びうるし、同じ粒度が層をまたぐこともある。
片方だけを整えても文書は読みやすくならない。

なお目的レベルは Alistair Cockburn による整理であり、
本ハンドブックはそれを4層モデルに重ねて用いている。
Cockburn 自身の関心は読みやすいユースケースを書くことにあり、工程や層の分類ではない。
したがって以下の対応づけは本ハンドブックの解釈である。

## 目的レベルと層の対応

| レベル | 内容 | 層 | 扱い |
|---|---|---|---|
| Cloud（雲） | 事業レベルの目的 | 要求より上 | 参照するが書かない |
| Kite（凧） | 業務全体の流れ。複数の関係者にまたがる | 要求 | 背景・文脈として |
| **Sea（海面）** | 1人のアクターが1回で達成する目標 | **要件** | **合意の単位** |
| Fish（魚） | Sea より下位の手続き | 要件の内訳または仕様 | 条件付きで立てる |
| Clam（蛤） | 低すぎるもの | 設計 | ユースケースとして書かない |

### Sea が要件の単位である理由

検証者が一致するためである。

要件の検証者は発注者と開発者の双方だった。
「この一覧で要求が満たせるか」を両者が判定できる粒度が Sea であり、これは偶然ではない。
Sea は「一人のアクターが一区切りの仕事として完了できる単位」であり、
業務として意味があり（発注者が判定できる）、かつ実現手段が見通せる（開発者が判定できる）。

Kite は業務全体の流れであり、開発者は実現可能性を判定できない。
Clam は実装の細部であり、発注者は必要性を判定できない。
**双方が判定できる唯一の粒度が Sea** である。

4層モデルの中で要件だけが検証者を2人持つことと、これは対応している。
要件は業務判断と技術的実現性が交わる層であり、どちらか一方では決めきれない。

### Cloud と Clam を表に載せる意味

どちらも「書かないもの」だが、載せる価値がある。**越境の検出器になる**ためである。

ユースケース一覧に「不正アクセスを防ぐ」があれば、それは Cloud であり要求層の話が紛れている。
「パスワードをハッシュ化して保存する」があれば、それは Clam であり設計層に落ちている。

いずれも粒度が不適切なのではなく、**層が違う**。
粒度の問題に見えて層の問題であるものを、この2つが拾い上げる。

### Fish だけが一意に決まらない

対応表の中で、Fish だけが行き先を1つに定められない。
要件の内訳になることも、仕様に降りることもある。

理由は、Cockburn の軸と4層モデルの軸が完全には一致しないためである。
目的レベルは「目標の大きさ」で切り、層は「誰が検証するか」で切る。
両者はおおむね相関するが一致はしない。
Sea と Kite の境界が比較的くっきりしているのに対し、Fish だけが両側にまたがるのはこのためである。

**Fish が揺れるのは道具の性質であって、書き手の未熟ではない。**

Fish をいつ立てるか、立てたものがどの層に属するかの判断は、
分量と性質が異なるため「Fish の線引き」で別に扱う。

## 承認と検証は別である

層の判定を「発注者が読むかどうか」で決めようとすると失敗する。
発注者は仕様書も設計書も読み、承認する。それは通常の手順である。

| | 承認 | 検証 |
|---|---|---|
| 誰が | 発注者 | 各層の検証者 |
| 何をするか | この内容で進めてよいと合意する | 作られたものが決めたとおりか確かめる |
| いつ | 工程の区切り | テスト時 |

**発注者は全層を承認しうるが、検証できる層は限られる。**
4層モデルの検証者の表が示しているのは後者だけである。

なお仕様の検証者である「レビュアー・テスター」は開発側の人を指す。
V字モデルで仕様に対応するのは結合テストであり、これを実行するのは開発側だからである。
発注者が仕様書を承認することと、仕様の検証者が開発側であることは矛盾しない。

## 粒度が揃わないと何が起きるか

**網羅性を判定できなくなる。**

Sea と Fish が同じ階層に並んでいると、ある業務が一覧に見当たらないとき、
抜けているのか、どこかの Sea の下位に畳まれているのかを読み手が区別できない。
一覧の行数は増えるのに、確からしさは下がる。

ユースケース整理という作業の実質は、この**レベルを揃えること**にある。
数を増やすことでも、細かくすることでもない。

粒度が揃っていれば、一覧を見て「この業務がない」と言える。
揃っていなければ、何も言えない。

## 工程上の位置

| | 内容 |
|---|---|
| 前提 | 要求の成功基準が決まっていること。誰が何を達成したら成功かが、アクターと目標の抽出源になる |
| 主工程 | 要件定義 |
| 成果物 | ユースケース一覧と記述。要件定義書の構成要素であり、要件そのものではなく**要件を漏れなく出すための道具** |
| 引き渡し | 各ユースケースのステップが、画面仕様・API仕様の単位になる |

要求の成功基準が未確定のままユースケースを書き始めると、
アクターと目標を書き手が想像で決めることになる。
このとき作られた一覧は網羅的に見えるが、何に対して網羅的かを誰も言えない。

成果物の位置づけには注意が要る。
ユースケースは要件を出すための道具であって、要件そのものではない。
一覧が埋まったことと、要件が揃ったことは別である。

## まとめ

- 層は**誰が検証するか**で切り、粒度は**何を1件と数えるか**で切る。直交した別の軸である
- Sea が要件の単位なのは、発注者と開発者の双方が判定できる唯一の粒度だからである
- Cloud と Clam は書かないが、越境の検出器として表に残す
- Fish だけが層をまたぐ。これは2つの軸の切り口が異なることの帰結である
- 粒度を揃える目的は網羅性の判定であり、細かくすることではない
- 発注者は全層を承認しうるが、検証できる層は限られる

**この判断は誰が検証するのか。** 層を決めるときの問いはここでも変わらない。
粒度はその問いに答えるための、もうひとつの目盛りである。