---
note: 層は判断の分離、工程はその並べ方。なぜ分けるのか、なぜ順序があるのか
created: 2026-08-08T17:37:48+09:00
---

# なぜ工程として必要なのか

要求→要件→仕様→設計という分け方は、一見「手続きのための手続き」に見える。
小さな開発なら、頭の中で全部済ませてコードを書き始めても動くものは作れる。
それでもこの分け方が必要な理由を、「層の必要性」と「工程(順序)の必要性」に分けて説明する。
この2つは別の話であり、混ぜると「アジャイルなら不要」のような誤った結論に落ちる。

## 層の必要性: 翻訳は一足飛びにできない

根っこにあるのは、**ビジネスの言葉とコードの言葉は距離が遠すぎて、一度に翻訳できない**という問題である。

「調査時間を半分にしたい」という要求から、`match_phrase` クエリという実装までの間には、
無数の判断が挟まっている。検索対象は何か、何件表示するか、0件のときどうするか、
どの検索エンジンを使うか。一気に飛ぶと、これらの判断が誰にも見えない形でコードに埋まる。

各層は、この翻訳の**中間チェックポイント**である。重要なのは、層ごとに「正しい」と言える人が違うこと:

| 層 | 「正しい」と検証できる人 |
|---|---|
| 要求 | 発注者・ユーザー(それが欲しかったものか) |
| 要件 | 発注者と開発者の双方(それで要求が満たせるか) |
| 仕様 | テスター・レビュアー(振る舞いが決めたとおりか) |
| 設計 | エンジニア(仕様を満たす作りか) |

層を省くと、**誰も検証できない飛躍**がどこかに埋まる。
「なんとなく動くが、これで良いのか誰にも判断できない」状態は、たいていここから生まれる。
V字モデルが各層にテストレベルを対応させているのは、この検証可能性の裏返しである。

もう1つの役割は**変更時の影響範囲の特定**にある。
「表示件数を30件にしたい」は仕様の変更で、要求は変わらない。
「調査時間の目標を10分にしたい」は要求の変更で、要件から下が全部揺れる。
層が分かれていれば、変更がどの高さの話かを最初に見極められる。
分かれていなければ、すべての変更が「コードをどう直すか」の話に潰れてしまい、
文書と実態が静かにズレていく。

## 工程の必要性: 順序には理由があるが、状況依存である

層の分離が普遍的な必要性なのに対して、それを**時間順に並べる(工程にする)**理由はもっと現実的な事情による。

### 手戻りコストの非対称性

要求の間違いは、下流に行くほど修正コストが膨らむ。
仕様まで降りてから「そもそも解くべき課題が違った」と分かれば、仕様も設計も書き直しになる。
運用まで行ってから分かれば、桁が変わる。
抽象度の高い判断ほど先に固めて検証したい、というのが工程順の第一の理由である。

### 合意と責任の区切り

受託開発では、「要件定義完了で合意し、次へ進む」という工程の区切りが、
そのまま契約・責任・支払いの区切りになる。
どこまでが合意済みで、どこからが未確定かを両者が共有するために、工程は区切りとして機能する。
第三者(別ベンダー、後任、監査)が入る場合も、工程ごとの成果物が引き継ぎの単位になる。

### ただし、順序は絶対ではない

手戻りコストが小さい環境では、工程順を崩せる。
自社プロダクトでプロトタイプを先に作り、触ってもらってから要求が明確になる、という逆流は健全に起こる。
アジャイル開発は工程を反復の中に畳み込んでいるのであって、判断を省いているわけではない。

見誤ってはいけないのは、**崩れているのは順序であって、判断ではない**という点である。
プロトタイプ先行でも「これは誰の何を解決するのか(要求)」
「この振る舞いで確定か(仕様)」という判断は必ずどこかで行われている。
行われていなければ、それは速い開発ではなく、検証されていない開発である。

## まとめ: 層は判断の分離、工程はその並べ方の一形態

- **層**は、遠すぎる翻訳を検証可能な単位に区切るためのもの。開発形態によらず必要
- **工程**は、その判断を手戻りコストと合意の都合で時間順に並べたもの。状況に応じて崩せる
- 何を省けるか迷ったら、「この判断は誰が検証するのか」を問う。検証者が消える省略は、していない

本ハンドブックが文書の書き方を層ごとに整理しているのは、この判断の分離を文書の形で残すためである。
文書は工程の副産物ではなく、判断が行われた証拠であり、次の変更のときに「どの層の話か」を
見極めるための基準点になる。