👻

Spec-Driven Development (仕様駆動開発) をきっかけに、仕様と設計を整理する

に公開
SDD
Kiro
ears
tech

はじめに｜Spec-Driven Developmentを調べ始めて引っかかったこと

この記事を書いている私は、AI Coding Agent を使った開発を実際に試しながら、
「この知見をチームや関係者にどう説明すればいいのか？」という壁にぶつかっている一人の実務者です。

もしあなたが、次のような状況に心当たりがあれば、この記事はきっと役に立つと思います。

  • AI Coding Agent を使い始めたが、まだ使いきれてないようなメンバーにどうアドバイスすればいいか悩んでいる
  • Spec-Driven Development の Spec (Specification) として何を書くべきかピンときていない

この記事では、ISO/JIS の整理も参照しながら、
なぜ、今Spec-Driven Developmentが必要か・注目されているかを実務目線で整理します。

最近、AI Coding Agentを用いた Spec-Driven Development が注目されているかと思います。
うまくいきそうな気配を感じている人も多いと思いますが、Spec-Driven Developmentについて雰囲気で語られているような気もしています。
例えば、AmazonのKiroのドキュメントを読み進めると、そこでは Spec / Specification / EARS (Easy Approach to Requirements Syntax) といった言葉が、特に説明もなく前提として使われており、私含めて、しっかり理解されているのか怪しい気がしています。

それらのドキュメントを読みながら、

Specって何でしたっけ？
Specification、仕様……あれ、これって設計（Design）とは違うのか！？あれ？Specを決めることは設計じゃないのか？

となりました。
要件定義や設計にそこそこ長く関わってきたつもりでしたが、
いざ説明しようとすると、自分の中でも言葉の境界が曖昧になっていることに気づきました。

改めて、本記事は、Spec-Driven Developmentを理解しようとしたことをきっかけに、
「Specification（仕様）」を軸に、要件・仕様・設計を整理し直したメモです。

なぜ今まで困らなかったのか｜アジャイルとハイコンテキスト

これまで多くのアジャイル開発では、

  • 少人数のチーム
  • 密なコミュニケーション
  • プロ意識の高いメンバー

といった前提のもとで開発が進められてきました。

仕様や前提条件の細かな部分は、
会話やその場の判断、空気感で補完できていたことも多かったと思います。

いわば、ハイコンテキストなコミュニケーションを前提とした開発スタイルだったとも言えます。

そのため、

  • Spec と Design の境界
  • requirement と specification の違い

を厳密に意識しなくても、実務上は大きな問題にならなかったのだと思います。
（もちろん、意識して実施している方も多いとは思いますが、自分は怪しかったです。。。）

先に結論だけ書いておくと、本記事での整理はこうです。

  • requirement：満たすべき条件
  • specification：満たすべき条件を体系化・明文化した成果物
  • design：条件をどう実現するか

KiroやAI Agentの前提は？

AWS Kiro やAI Coding Agentが前提としているのは、AI Agent が開発に参加する世界です。

AI Agent は、

  • 高速に動作できる
  • 並列にいくらでも増やせる

一方で、

  • （明文化しないと）暗黙知を共有できない
  • （明文化しないと）文脈を「察する」ことができない（コンテキストを逼迫する）

という特徴を持っています。

人間同士であれば会話で済んでいた前提や約束事が、
AI Agent 相手には通じません。

その結果、

「何が前提で、何が自由なのか」

を 明文化しておく必要が出てきます。

ここで、何をどうやって明文化するかというところでSpecが重要になったようです。
次から、Spec周辺について調べたことを書いていきます。

requirement と specification がよくわからない

Spec を調べていく中で、次に引っかかったのが
requirement と specification の違いでした。

日本語では、

  • 要求
  • 要件
  • 仕様

といった言葉が、文脈ごとに混ざって使われています。

調べていくと、JIS X 0166（ISO/IEC/IEEE 29148）に行き着きましたが、
そこでは次のように整理されています。

  • requirement は「要求」「要件」どちらとも訳されることがある
  • 規格内では「要求事項」という中立的な表現を用いている

つまり、標準自身が日本語訳の揺れを認めているのです。

日本語訳はどう扱うか

本当は、「要求」「要件」「仕様」といった言葉は、
もっと厳密に整理されていてほしいと感じますが、
訳語の話をしだすと議論が止まってしまいます。
そこで本記事では、

  • 日本語訳の細かな違いはいったん脇に置き
  • ISO/JIS が意図している「役割（レイヤ）」 に注目して整理する

という方針を取ります。

読みながら迷ったら、こう扱うのが実務的だと思います。

  • requirement は「満たすべき条件の1文」
  • specification は「条件をまとめた成果物」
  • design は「その条件を満たす具体案」

ISO/IEC/IEEE/JISが分けているレイヤ

ISO/IEC/IEEE 29148（JIS X 0166）が一貫して分けているのは、
言葉そのものではなく、次のレイヤです。

Needs（ニーズ）
↓
Requirements（要求事項）
↓
Requirements Specification（要求仕様）
↓
Design（設計）

ここで重要なのは、

  • requirement：満たすべき条件そのもの（1つ1つの文）
  • specification：それらの条件を体系化・明文化した成果物
  • design：その条件をどのように実現するか

という役割の違いです。

Specification（仕様）は Design（設計）ではありません。

そして、
Spec は「守るべき前提・約束」であり、
Design はその前提の中で考える自由な領域です。

EARSはどこに位置づくのか

Kiro のドキュメントに登場する EARS 記法も、
この整理の中で位置づけることができます。

EARSは、Easy Approach to Requirements Syntax の略で、以下のような形で、自然言語を用いてシステムが持つべきrequirement（要求事項）を記載するものです。

While <任意の前提条件>, when <任意のトリガー>, the <システム名> shall <システム応答>

EARS は、

  • requirement（要求事項）を明確な形で記述するための記法
  • Spec そのものではありません

EARS で書かれた複数の requirement を集め、整理したものが
requirements specification（要求仕様） になります。

EARS は手段であり、Spec は成果物です。
Specの中にEARSで書かれたrequirementsがあるという理解です。

SpecとDesignを分けて考える意味

Spec と Design の区別が曖昧なまま進むと、

  • 何が固定で
  • 何が変更可能なのか

が分かりにくくなります。

その結果、

  • 設計変更のたびに前提条件まで揺れてしまったり
  • レビューの論点が噛み合わなくなったり

することがあります。

Spec と Design を分けて考えることは、
設計を縛るためではなく、設計を自由にするための整理だと感じました。
設計をAI Agentに任せるなら、Specを共有してそれでOKでしょうし、技術的負債を避ける等の理由があれば、Designにも制約を与える必要が出てくると思います。
ここでは、分けて考える必要があるということが重要だと思われます。

なぜ今、Spec-Driven Developmentなのか

ここまで整理してきて、
Spec-Driven Development が注目されている理由も見えてきました。

AI Agent を「優秀なジュニアエンジニア」のように、
並列に大量に働かせようとすると、

  • 暗黙知に依存できない
  • 非同期・分業が前提になる

という状況になります。

これは、ウォーターフォールへの回帰にも見えます。
が、ポイントとしては、

暗黙知に頼らない開発の再評価

と捉える方が自然だと感じます。

大規模システム開発や、SIer 的な文脈で培われてきた
「前提を言語化し、約束を定義する」考え方が、
AI 前提で再び意味を持ち始めているのではないでしょうか。

AWS Kiroをこの整理で読み直す

この整理を踏まえて Kiro のドキュメントを読み直すと、
Kiro が示している流れはとても素直に理解できます。

Specification
→ Design
→ Implementation

Spec を固定された前提として置くことで、

  • Design や Code を AI が探索できる
  • 人と AI、AI 同士が並列に作業できる

Spec-Driven Developmentは新しい概念を作っているというよりも、

  • Specification と Design と Implementation の境界を、AI 前提で明確にしている
  • 人間とAI Agentとのコミュニケーションに、しかるべきスコープを持つドキュメントを用いている
    と感じました。

読後のアクション

最後に、この記事を読んだ後の具体的なアクションを一つだけ提案します。

次のAI Codingで、「仕様（Spec）」と「設計（Design）」を分けてやりとりしてみてください。

  • これは「守るべき前提か？」
  • それとも「実現方法か？」

と一度立ち止まるだけで、
仕様と設計の混線はかなり減らせ、AIとのやりとりがスムーズになるかと思います。

おわりに｜Specificationを軸に考えるということ

Spec は人とAIが並列に働くための、宣言的な共通の前提です。

Spec-Driven Development をきっかけに始まったこの整理が、
同じように引っかかっている方の助けになればうれしいです。

📚 参考リンク

以下は本記事で参照した主要な資料へのリンクです。
原文や公式解説が閲覧できるため、興味のある方はこちらもぜひご覧ください。

GitHubで編集を提案

Discussion