Spec Kitを導入して見えてきたアジャイル開発の片鱗──要件・仕様・実装の境界線
はじめに
この記事では、Spec Kit を導入する過程で垣間見えた “アジャイル開発の片鱗” をテーマに、要件・仕様・実装をどう切り分けて議論できるか を中心に考察します。
私たちのチームは、AI に渡す仕様を共通フォーマットで管理するため、Spec Kit を導入しました。目的は、プロンプトごとに属人的なノウハウが散らばる状況から脱却し、仕様の再現性・整合性を高めることです。
導入を進める中で、あるメンバーから次のような疑問が投げられました：
「specify（明示する）という言葉からだと、実装方法までも明示したくなります。でも、そうなると 『specify と plan の違い』 って何なんだろう？」
最初は用語の使い分けの問題に感じられましたが、しだいにこれは 「価値 (What/Why)、仕様による振る舞い、そして実装 (How) の境界をどう扱うか」 という議論に繋がることが見えてきたのです。
職場でのやりとり（思考実験）
以下の会話は、読者の皆さんと一緒に考えるための “思考実験的な対話” です。役割もやりとりも実際ではなく、仮説的な議論の再現として捉えてください。
エンジニアA
「specifyって 『明示する』 という意味だから、実装方法まで AI に指示したくなります。そうすれば期待通りに動いてくれるはず。だけど、そうなると plan との違いって何なんでしょうか？」
テックリード
「仕様駆動開発の文脈では、specify で仕様を定義し、plan で実装方針を与えるとされます。ただ、その分離には理由があるはずです。」
PdM
「正直なところ、要件を書くときに実装方法をつい混ぜてしまうことがあります。以前エンジニアをしていたので、どのように作るかが頭に浮かんで… 『親切』 だと思って。」
エンジニアB
「確かに、PdMさんが実装方法まで指定してくれると、僕はそのまま実装してしまうことがあります。深く考えずに。」
スクラムマスター
「そこが重要な分岐点です。要件 (What/Why) と手段 (How) は別々に考えるべきです。混ぜてしまうと、価値がぼやけ、技術選択に引きずられてしまいます。」
テックリード
「では、要件と仕様は具体的にどう違うのでしょうか？」
スクラムマスター
「要件とは 『何を・なぜ』 を示すもの。仕様とはその要件を、実装技術に依存しない振る舞いとして定義するもの。そして実装方法 (How) は仕様には含めず、後続の段階で選ぶべきものです。」
スクラムマスター（例示）
「例として、パスワードリセット機能を考えてみましょう。
- 要件：ユーザーがパスワードを忘れても再度ログインできること
- 仕様：リセットリンクをメール送信し、ユーザーが新しいパスワードを設定できること
- 実装方法：Rails で
/password_resetsエンドポイントを用意、SendGrid でメール送信など、技術的な詳細」
エンジニアA
「なるほど。つまり、specify では要件から導かれる仕様を扱うのであって、How は含めないということですね。」
PdM
「私がやっていたのは、要件に How を混ぜるアンチパターンだったのだと気づけました。」
この対話を契機として、「要件・仕様・実装をどう切り分けるか」はチーム内で共通の問いになりました。
仮説モデルとしての三層構造
以下は、この思考実験から抽出した仮説的な整理モデルです。これはあくまでひとつの視点にすぎず、普遍的な法則として主張するものではありません。
| 層 | 主な内容 | 扱うべき言葉の粒度 |
|---|---|---|
| 要件 (Requirement) | 何を実現するか / なぜそれが必要か (What / Why) | 高レベル、価値・目的 |
| 仕様 (Specification) | 要件を実装に依存しない形で振る舞いとして定義したもの | 振る舞い、ユーザー視点 |
| 実装 (Implementation) | 仕様を実現するための具体的な技術的手段・方法 (How) | 技術的詳細、構造、モジュール |
この三層構造を Spec Kit の用語体系に重ねると：
- specify フェーズ：要件をもとに仕様を定義（実装技術は含めない）
- plan フェーズ：仕様に対して技術制約やアーキテクチャを与え、実装方針を決める
- tasks → implement フェーズ：仕様と plan に基づいてタスクを分割し、実装を行う
AI と人間、それぞれの視点
この三層モデルを前提にすると、AI と人間が仕様に How を混ぜたときに直面する違いがよく見えてきます。
-
AI の視点
仕様に How が含まれていても、AI はそれにしたがって実装できます。具体的な指示があれば、迷わず処理できます。 -
人間の視点
仕様に How が混ざると、技術的制約や既存の選択肢に影響されやすくなり、要件としての価値 (What / Why) が見えにくくなることがあります。
とくに、価値を練る段階で How が混ざると、実装制約主導で仕様が偏ってしまうリスクがあります。
この観点から、要件 → 仕様段階では How をなるべく除外し、価値の輪郭をしっかり描くことが重要です。
アジャイル開発における意義と示唆
このモデルを軸にすると、開発プロセスやチーム運営に次のような利点が見えてきます：
-
価値 (What/Why) に集中できる
仕様を議論するとき、技術判断に引きずられず、本来の目的にフォーカスできる。 -
実装の柔軟性・工夫を担保できる
仕様段階で過度に How を固定しないことで、実装者に自由な選択肢を残す。 -
レビューや議論の切り分けが明確になる
- 要件 ↔ 仕様の整合性（価値観点）
- 仕様 ↔ 実装方針（技術観点） -
仕様運用と技術的な制約管理が分離できる
仕様変更や価値修正がしやすくなる。技術制限は plan / implement 側で扱う。
補足：この三層構造モデルについて
本稿で提示する「要件・仕様・実装の三層構造」は、個人の思考実験として導かれた仮説モデルです。
Spec Kit が採用する specify → plan → tasks → implement フローとは整合性がありますが、三層構造そのものは公式仕様ではありません。
その点をご理解いただいたうえで、議論整理の道具立てとして、ご自身の文脈に適応して活用していただければと思います。
結びに
この思考実験を通して、Spec Kit 導入を契機に “価値・仕様・実装の切り分けへの視点” を少しでも皆さんと共有できたら嬉しいです。
仕様 (specify) と実装方針 (plan) を明確に区別できる視点は、チームの議論を整理し、設計の迷いを減らすヒントになるはず。
特定の手法としての正解ではなく、探索的な視点としてこの三層構造を皆さんの開発に取り込むきっかけになればと思います。
Discussion