要求→要件→仕様→設計という分け方は、一見「手続きのための手続き」に見える。 小さな開発なら、頭の中で全部済ませてコードを書き始めても動くものは作れる。 それでもこの分け方が必要な理由を、「層の必要性」と「工程(順序)の必要性」に分けて説明する。 この2つは別の話であり、混ぜると「アジャイルなら不要」のような誤った結論に落ちる。
根っこにあるのは、ビジネスの言葉とコードの言葉は距離が遠すぎて、一度に翻訳できないという問題である。
「調査時間を半分にしたい」という要求から、match_phrase クエリという実装までの間には、
無数の判断が挟まっている。検索対象は何か、何件表示するか、0件のときどうするか、
どの検索エンジンを使うか。一気に飛ぶと、これらの判断が誰にも見えない形でコードに埋まる。
各層は、この翻訳の中間チェックポイントである。重要なのは、層ごとに「正しい」と言える人が違うこと:
| 層 | 「正しい」と検証できる人 |
|---|---|
| 要求 | 発注者・ユーザー(それが欲しかったものか) |
| 要件 | 発注者と開発者の双方(それで要求が満たせるか) |
| 仕様 | テスター・レビュアー(振る舞いが決めたとおりか) |
| 設計 | エンジニア(仕様を満たす作りか) |
層を省くと、誰も検証できない飛躍がどこかに埋まる。 「なんとなく動くが、これで良いのか誰にも判断できない」状態は、たいていここから生まれる。 V字モデルが各層にテストレベルを対応させているのは、この検証可能性の裏返しである。
もう1つの役割は変更時の影響範囲の特定にある。 「表示件数を30件にしたい」は仕様の変更で、要求は変わらない。 「調査時間の目標を10分にしたい」は要求の変更で、要件から下が全部揺れる。 層が分かれていれば、変更がどの高さの話かを最初に見極められる。 分かれていなければ、すべての変更が「コードをどう直すか」の話に潰れてしまい、 文書と実態が静かにズレていく。
層の分離が普遍的な必要性なのに対して、それを**時間順に並べる(工程にする)**理由はもっと現実的な事情による。
要求の間違いは、下流に行くほど修正コストが膨らむ。 仕様まで降りてから「そもそも解くべき課題が違った」と分かれば、仕様も設計も書き直しになる。 運用まで行ってから分かれば、桁が変わる。 抽象度の高い判断ほど先に固めて検証したい、というのが工程順の第一の理由である。
受託開発では、「要件定義完了で合意し、次へ進む」という工程の区切りが、 そのまま契約・責任・支払いの区切りになる。 どこまでが合意済みで、どこからが未確定かを両者が共有するために、工程は区切りとして機能する。 第三者(別ベンダー、後任、監査)が入る場合も、工程ごとの成果物が引き継ぎの単位になる。
手戻りコストが小さい環境では、工程順を崩せる。 自社プロダクトでプロトタイプを先に作り、触ってもらってから要求が明確になる、という逆流は健全に起こる。 アジャイル開発は工程を反復の中に畳み込んでいるのであって、判断を省いているわけではない。
見誤ってはいけないのは、崩れているのは順序であって、判断ではないという点である。 プロトタイプ先行でも「これは誰の何を解決するのか(要求)」 「この振る舞いで確定か(仕様)」という判断は必ずどこかで行われている。 行われていなければ、それは速い開発ではなく、検証されていない開発である。
本ハンドブックが文書の書き方を層ごとに整理しているのは、この判断の分離を文書の形で残すためである。 文書は工程の副産物ではなく、判断が行われた証拠であり、次の変更のときに「どの層の話か」を 見極めるための基準点になる。