仕様駆動開発を試す
AWSの生成AIエージェントIDE Kiroの概念である仕様駆動開発をClaue Codeでも試したかったので、それ用の開発ガイドラインを作成して、試験的に全てのコードをClaude Codeに記述してもらいました。
参考記事
使い方
下記のファイルをプロジェクト内にコピペして、Claude Codeにこれから「XXXXX」の機能作るから「ファイル名のパス」参照してといえばこの手順の通りにやってくれます。
注意事項
- 再現性が高いといっても100%ではないです「今回はこのガイドを守らないで」といえばAIは守りません、自然言語による開発というのはそういうもんです
- 重たいので、機能開発の時だけ読み込むのがいいです。また当然英語の方がトークンを圧迫しないので本気で使いたいなら英語版をClaude Codeに作ってもらってください
- 当然ですがこのガイドラインもAIに書かせています、別にこれ使わなくてもあなたの考える最上のプロセスのガイドラインをAIに作ってもらう方がいいです。ただその際にタスクは「/todo:」を使って記述してねと言っておくと再現性が高まります、この「/todo:」を使うと良いというのがこの記事を目にしたあなたの最大にして唯一のメリットです
開発プロセス ガイドラインサンプル
# 開発プロセス ガイドライン
**日付:** 2025-01-09 | **バージョン:** 1.0
この文書は、XXXXプロジェクトにおける新機能実装のための標準的な6フェーズ開発プロセスを定義します。
## 📋 概要
すべての新機能実装は、品質、保守性、適切なドキュメント化を確保するため、この6フェーズプロセスに従う必要があります。
## 🔄 6フェーズ開発プロセス
### フェーズ1: 要件定義
#### 目的
人間との対話を通じて機能の目標、スコープ、期待される成果を明確化する。
#### 活動内容
1. **機能概要**
- 機能の目的と目標を定義
- 対象ユーザーと使用ケースを特定
- 成功基準を確立
2. **人間との対話**
- 不明な点をすべてリストアップ
- 人間とのQ&Aセッションを実施
- すべての決定と根拠を文書化
3. **文書化**
- `/internal/requirements/`に要件文書を作成
- 機能要件と非機能要件を含める
- 進行前に人間の承認を取得
#### 成果物
- 要件文書 (`/internal/requirements/[機能名]-req.md`)
- 人間からの承認確認
#### チェックリスト
/todo: フェーズ1 - 要件定義
- [ ] 機能の目的と目標が定義された
- [ ] 対象ユーザーが特定された
- [ ] 成功基準が確立された
- [ ] 不明な点がリストアップされ解決された
- [ ] 要件文書が作成された
- [ ] 人間の承認が取得された
---
### フェーズ2: 詳細設計
#### 目的
技術アーキテクチャと実装アプローチを設計する。
#### 活動内容
1. **技術アーキテクチャ**
- 技術スタックを選定
- システムアーキテクチャを設計
- コンポーネントインターフェースを定義
2. **セキュリティ評価**
- セキュリティリスクを特定
- 軽減戦略を定義
- データ処理方法を検討
3. **プロトタイプ作成**
- 必要に応じて最小限のPoCを作成
- 技術的実現可能性を検証
- 発見事項を文書化
#### 成果物
- 設計文書 (`/internal/design/[機能名]-design.md`)
- PoCコード（該当する場合）
- 設計に対する人間の承認
#### チェックリスト
/todo: フェーズ2 - 詳細設計
- [ ] 技術スタックが選定された
- [ ] アーキテクチャ図が作成された
- [ ] コンポーネントインターフェースが定義された
- [ ] セキュリティリスクが評価された
- [ ] 依存関係が特定された
- [ ] PoC が実装された（必要な場合）
- [ ] 設計文書が作成された
- [ ] 人間の設計承認が取得された
---
### フェーズ3: テスト設計
#### 目的
実装前に包括的なテスト戦略を設計する。
#### 活動内容
1. **テストケース設計**
- 要件からテストケースを導出
- 正常系テストシナリオを設計
- 異常系テストシナリオを設計
- 境界値テストを定義
2. **テスト計画**
- テストデータ要件を定義
- テスト環境のニーズを指定
- パフォーマンステストを計画（必要な場合）
- セキュリティテストを計画（必要な場合）
3. **受け入れ基準**
- 明確な受け入れ基準を定義
- 基準を要件にマッピング
- 人間の承認を取得
#### 成果物
- テスト設計文書 (`/internal/test-design/[機能名]-test.md`)
- テストケース仕様
- 受け入れ基準チェックリスト
#### チェックリスト
```markdown
/todo: フェーズ3 - テスト設計
- [ ] 要件からテストケースが導出された
- [ ] 正常系テストシナリオが作成された
- [ ] 異常系テストシナリオが作成された
- [ ] 境界値テストが定義された
- [ ] パフォーマンステスト計画（必要な場合）
- [ ] セキュリティテスト計画（必要な場合）
- [ ] 受け入れ基準が文書化された
- [ ] テストデータ要件が定義された
- [ ] テスト環境が指定された
- [ ] テスト設計がレビューされた
- [ ] 人間のテスト設計承認が取得された
---
### フェーズ4: タスク分解
#### 目的
実装を管理可能なタスクに分解する。
#### 活動内容
1. **タスク分解**
- 機能を小さなタスクに分解
- テスト実装タスクを含める
- 各タスクの工数を見積もり
2. **優先順位設定**
- タスクの依存関係を定義
- 実装順序を設定
- クリティカルパスを特定
3. **タスク管理**
- TodoWriteツールでタスクを登録
- 進捗追跡を設定
- 完了基準を定義
#### 成果物
- 優先順位付きタスクリスト
- TodoWriteエントリー
- 実装スケジュール
#### チェックリスト
/todo: フェーズ4 - タスク分解
- [ ] 実装タスクが特定された
- [ ] テストタスクが含まれた
- [ ] タスク工数が見積もられた
- [ ] 依存関係がマッピングされた
- [ ] 優先順位が割り当てられた
- [ ] TodoWriteタスクが作成された
- [ ] スケジュールが定義された
---
### フェーズ5: 実装とテスト
#### 目的
機能を開発し、テストによる品質確保を行う。
#### 活動内容
1. **実装**
- 機能コードを記述
- コーディング標準に従う
- エラーハンドリングを実装
2. **ユニットテスト**
- ユニットテストを記述（80%以上のカバレッジ）
- すべてのユニットテストを実行
- 失敗するテストを修正
3. **統合テスト**
- コンポーネント間の相互作用をテスト
- データフローを検証
- エラーシナリオをテスト
4. **コードレビュー**
- コードをセルフレビュー
- 必要に応じてリファクタリング
- 複雑なロジックを文書化
#### 成果物
- 機能実装
- ユニットテスト (`/tests/unit/`)
- 統合テスト (`/tests/integration/`)
- テスト実行レポート
#### チェックリスト
/todo: フェーズ5 - 実装とテスト
- [ ] 機能コードが実装された
- [ ] ユニットテストが記述された（80%以上のカバレッジ）
- [ ] すべてのユニットテストが通過
- [ ] 統合テストが記述された
- [ ] すべての統合テストが通過
- [ ] コードレビューが完了
- [ ] リファクタリングが実施された
- [ ] コードが文書化された
---
### フェーズ6: 検証と文書化
#### 目的
機能が要件を満たしていることを確認し、文書を更新する。
#### 活動内容
1. **人間による検証**
- 人間に機能をデモンストレーション
- 受け入れテストを実施
- フィードバックを収集
2. **フィードバック統合**
- 人間のフィードバックに対処
- 必要な調整を実施
- 影響を受けた領域を再テスト
3. **文書更新**
- ユーザー文書を更新
- 技術文書を更新
- リリースノートを作成
#### 成果物
- 受け入れテスト結果 (`/internal/test-reports/`)
- 更新された文書
- リリースノート
#### チェックリスト
/todo: フェーズ6 - 検証と文書化
- [ ] 人間に機能がデモンストレーションされた
- [ ] 受け入れテストが実行された
- [ ] フィードバックが収集された
- [ ] フィードバックが対処された
- [ ] 文書が更新された
- [ ] リリースノートが作成された
- [ ] 最終承認が取得された
---
## 📊 テストカバレッジ要件
| テストタイプ | カバレッジ目標 | 測定ツール | レポート場所 |
|-----------|----------------|------------------|-----------------|
| ユニットテスト | 最低80% | 内蔵カバレッジ | `/tests/coverage/` |
| 統合テスト | すべてのクリティカルパス | 手動追跡 | `/internal/test-reports/` |
| 受け入れテスト | 要件100% | チェックリスト | `/internal/test-reports/` |
## 📁 ディレクトリ構造
/internal/
├── development-process.md # この文書
├── templates/ # プロセステンプレート
│ ├── requirements.md
│ ├── design.md
│ ├── test-design.md
│ └── release-notes.md
├── requirements/ # 実際の要件文書
├── design/ # 実際の設計文書
├── test-design/ # 実際のテスト設計
│ ├── unit/
│ ├── integration/
│ └── acceptance/
└── test-reports/ # テスト実行結果
## 🚨 重要な注意事項
1. **フェーズをスキップしない** - 各フェーズは前のフェーズの上に構築される
2. **人間の承認を取得** - フェーズ1、2、3、6で必須
3. **すべてを文書化** - 決定、根拠、変更
4. **テストファースト** - 実装前にテストを設計
5. **品質を維持** - 80%以上のテストカバレッジは必須
## 🔗 関連文書
- メインガイドライン: `/CLAUDE.md`
- クイックリファレンス: `/internal/dev-process-quick-ref.md`
- テンプレート: `/internal/templates/`
## 📝 バージョン履歴
| バージョン | 日付 | 変更内容 | 著者 |
|---------|------|---------|--------|
| 1.0 | 2025-01-09 | 初回作成 | Claude Code |