スペック駆動開発
生産性中級
機能をすぐにコーディングせず、まずソクラテス式質問で要件を明確にしてから実装スペックを作成します。このスペックを基に実装を進めることで手戻りを大幅に削減できます。
トリガー
/spec使用頻度週1-2回
企画者兼開発者（個人開発）なら？ /specで企画と開発を1セッションで体系的に進行
PMが開発チームに要件を伝えるときなら？ 曖昧な要件を具体的なスペックに変換
スペック企画開発プロセス品質
動作フロー
/spec [機能アイデア] 実行 → インタビュー開始
↓
フェーズ1: 質問を通じて4つの領域を定義
scope
スコープ定義
edge-cases
エッジケースの導出
tech-choice
技術選定
acceptance
受入基準の定義
↓
実行スペックドキュメント生成
↓
✓ 実装スペック + このスペックで新セッションからすぐに実装可能
スキルコード
# Spec-Driven Development Skill
## Trigger: /spec [feature idea]
When invoked:
1. Interview phase (ask questions one at a time):
- What exactly should this feature do?
- Who is the primary user?
- What are the inputs and outputs?
- What should NOT be included? (scope boundary)
- What edge cases should we handle?
- Any existing patterns to follow?
2. Generate spec document:
---
## 📐 Implementation Spec: [Feature]
### Overview
[1-2 sentence summary]
### Scope
**In scope**: [list]
**Out of scope**: [list]
### Technical Approach
- [Architecture decision]
- [Key libraries/patterns]
- [File structure]
### Implementation Steps
1. [Step with file and approach]
2. [Step with file and approach]
3. [Step with file and approach]
### Edge Cases
- [case → expected behavior]
### Acceptance Criteria
- [ ] [testable criterion]
- [ ] [testable criterion]
---
3. Save as SPEC-[feature].md for use in implementation session
コピーしてCLAUDE.mdに貼り付ければ、すぐに使えます。
スペック駆動開発 の仕組み
Spec-Driven Devは機能要件についての構造化インタビューを実施し、回答を受入基準付きの正式な仕様書に変換した上で、各基準を満たす実装コードを生成します。
スペック駆動開発 が力を発揮する場面
曖昧な機能要求と正確な実装のギャップを橋渡しします。特にプロダクト要件が不明確で、コードを書く前にテスト可能な仕様に結晶化させる必要があるときに有効です。
主な強み
- 構造化インタビューで正確な要件を抽出
- テスト可能な受入基準を自動生成
- 実装コードが仕様にトレース可能
- 境界を事前に定義してスコープクリープを防止