SDDで要件定義書を書かない理由 ― 実行可能な仕様の意味

SDD(仕様駆動開発)では「要件定義書」を中心にしない

SDD(仕様駆動開発)を理解する上で最初につまずくのがここです。
SDDは要件定義を軽視しているわけではありません。むしろ逆です。
要件を最も厳密に扱うために、要件定義書を中心にしないという考え方です。

一般的な開発では、要件定義書は「合意の証拠」として扱われます。
署名・承認があり、レビューを通り、開発はそれを元に進みます。
しかし実務では、次の現象が頻繁に起きます。

• 要件定義書は正しい
• 実装も仕様通り
• それでもシステムが期待通り動かない

この時、原因は実装のミスではありません。
仕様の解釈のズレです。

文章の要件定義は、読む人の前提知識に依存します。
そしてソフトウェアは、前提知識を理解しません。

ここにSDDが登場します。

なぜ文章の仕様は必ず壊れるのか

例を一つ考えてみます。

「ユーザーが退会した場合、アカウントを無効化する」

この文章は一見明確です。しかし実装に入ると必ず議論が始まります。

• 退会直後のログインは可能か
• APIトークンは即時失効か
• サブスクリプションはどうなるか
• 管理画面からは閲覧できるのか

文章は仕様を説明できますが、振る舞いを確定できません。
つまり、文章仕様は「説明」であって「制約」ではありません。

ソフトウェアが必要とするのは制約です。

実行可能な仕様とは何か

SDDでは仕様をプログラムとして記述します。
これは単なるテストコードとは少し違います。
ポイントは、実装より先に存在し、実装の正しさを定義することです。

例として、ユーザー退会を仕様として表現します。

Feature: ユーザー退会

Scenario: 退会したユーザーはログインできない
  Given 有効なユーザーが存在する
  When ユーザーが退会する
  Then そのユーザーはログインに失敗する

Scenario: 退会後はAPIトークンが無効になる
  Given 有効なAPIトークンを持つユーザー
  When ユーザーが退会する
  Then API認証は401を返す

これがSDDでいう仕様です。
文章ではありません。実行されます。

もし開発者がログインを許してしまえば、CIで失敗します。
つまりこの仕様は説明ではなく、強制力を持つ契約です。

要件定義書と何が違うのか

要件定義書と実行可能な仕様の違いは、読み手ではなく責任にあります。

種類	読む主体	責任
要件定義書	人間	理解する責任
実行可能な仕様	コンピュータ	違反を検出する責任

要件定義書は「理解してくれる前提」です。
実行可能な仕様は「間違いを検出する前提」です。

ここが決定的な差です。

実際のプロジェクトで起きる変化

SDDを導入すると、要件定義フェーズの会話が変わります。

従来の会話:
「仕様書に書いてあります」

SDD導入後:
「そのケースのシナリオを書いてください」

つまり文章のレビューではなく、振る舞いのレビューになります。
レビューの対象が文書からケースへ移動します。

結果として、次の現象が起きます。

• 実装後の手戻りが減る
• QA工程での仕様バグが激減する
• 開発者と業務側の認識が揃う

特に大きいのは、QAが「確認作業」から「仕様策定」に参加できるようになる点です。

ありがちな誤解

SDDは「ドキュメントを書かない開発」だと誤解されがちです。
実際は逆です。

ドキュメントは減りません。
曖昧なドキュメントが減ります。

文章の仕様書は、背景説明や業務フローの理解には必要です。
しかし正しさの保証には使いません。
保証は実行可能な仕様が担当します。

注意点とリスク

SDDには明確なリスクがあります。

• シナリオが増えすぎる
• すべてを仕様化しようとする
• UI挙動まで固定する

最も危険なのは「画面の動作」を仕様に入れることです。
ボタン配置や画面遷移を仕様にすると、リファクタリング不能になります。

SDDの対象はUIではありません。
業務ルールの振る舞いです。

導入のコツ

最初から全面的に置き換える必要はありません。
効果が出やすい部分から始めます。

• 課金処理
• 在庫管理
• 権限制御

これらは「間違えると事故になる」領域です。
ここに実行可能な仕様を置くと、チームの理解が一気に進みます。

最後に

SDD(仕様駆動開発)が目指しているのは、ドキュメントの削減ではありません。
仕様の誤解を構造的に不可能にすることです。

要件定義書は人間のための知識です。
実行可能な仕様はシステムのためのルールです。

ソフトウェアは文章を理解しません。
しかし、実行される仕様は裏切りません。