TL; DR
cc-sdd（仕様駆動開発）を用いたプロダクト開発を組織内に展開するにあたり、まずは共通言語となる大まかなプロセスと、それを開発計画（WBS）へ落とし込むための整理が必要だと考えました。個人レベルで運用する分には流れを感覚的に掴めても、チームとして継続的に回すためには、各フェーズで何を行い、どの成果物をどの順序で整備するのかを明確にしておくことが不可欠です。ここが曖昧なままだと、仕様と実装の進行が噛み合わず、手戻りや形骸化につながりやすくなります。
本記事では、cc-sddのコマンド体系に沿った開発の全体像を俯瞰しつつ、現場で扱いやすい形にWBSとして具体化するところまでを扱います。steeringの作り込みやvalidate系コマンドの挿入タイミング、Brownfieldにおける運用上の注意点、レビュー差し戻しの設計など、各工程の細かな留意事項や実践上の工夫については、別途記事を分けて整理する予定です。まずは「cc-sddをどういう流れで回すのか」「チーム運用に向けて何を準備すべきか」という全体の見取り図を把握したい方に向けた内容としてまとめています。
導入の初期段階で重要なのは、個々の熟練度に依存しない、再現性のある進め方を組織として確立することです。本稿が、そのための出発点として参考になれば幸いです。
以下は、cc-sdd（/kiro 系スラッシュコマンド）で仕様駆動開発（SDD）を回すときの基本的なコマンド順です。cc-sdd公式ガイドのライフサイクルに沿っています。
基本フロー（Greenfield / 新規機能を仕様から起こす標準パス）
1. ステアリング（コンテキスト収集）
/kiro:steering（必要なら /kiro:steering-custom）
プロジェクトの原則・命名・アーキ・ドメイン知識を .kiro/steering/*.md に蓄積。以後の全フェーズの前提メモリとなります。
2. 仕様ワークスペース作成
/kiro:spec-init <feature>
.kiro/specs/<feature>/ を作ってこの機能の仕様置き場を確保。
3. 要件定義
/kiro:spec-requirements <feature>
-
requirements.mdを生成（EARS形式の要件・未解決点など）。
4. 設計（調査→詳細設計）
/kiro:spec-design <feature>
必要に応じて research.md を作りつつ、design.md を出力。要件カバレッジやコンポーネント/IFが入ったレビュードキュメント。
5. タスク分解（実装計画）
/kiro:spec-tasks <feature>
tasks.md にTODO粒度で分解。Req-ID紐付けと P0/P1（逐次/並列）優先度ラベル付き。
6. 実装
/kiro:spec-impl <feature> <task-ids>
指定タスク単位で実装＋テストを進める。
7. 品質ゲート（必要に応じて各所で）
- 要件⇄既存コード整合:
/kiro:validate-gap <feature> - 設計レビュー:
/kiro:validate-design <feature> - 実装レビュー:
/kiro:validate-impl [feature] [task-ids]- ブラウンフィールドやリスク高い変更では特に効くガードレール。
8. 進捗サマリ
/kiro:spec-status <feature>
フェーズ承認状況と残タスクを要約。人間レビューの停止点として使う。
フローチャート（標準パス）
了解。繰り返しが発生するポイント（要件⇄設計⇄タスク⇄実装⇄検証）にループを入れた版を出します。 「レビューで差し戻し→前工程に戻る」 と 「タスク実装を回して完了まで反復」 の2種類のループを明示します。
ループの意味（実装の現場目線）
-
上側の仕様ループ
-
validate-gapで既存との差分・矛盾が出たら要件に戻る。 -
validate-designで穴や破綻が出たら要件 or 設計に戻る（どっちに戻すかは問題の起点次第）。
-
-
下側の実装ループ
-
tasks.mdのタスクが残っている限り、spec-impl → validate-implをタスク単位で反復。 - validateでNGなら同じタスクを修正して再実装、OKなら次タスクへ。
これが“仕様が正しくなるまで上流で回し、実装はタスク完了まで下流で回す”っていうcc-sddの実戦的な回し方。
SDDは直線じゃなくて二重ループの製造ラインと思うと運用がブレません。
-
Brownfield（既存コードに後付けで仕様駆動を入れる推奨順）
既存資産とズレやすいので、早めにギャップ分析を挟むのが公式の推奨。
順番はこう：
-
/kiro:validate-gap <feature>（既存コードと要件のズレ洗い出し） /kiro:spec-requirements <feature>/kiro:spec-design <feature>/kiro:spec-tasks <feature>/kiro:spec-impl <feature> <task-ids>-
/kiro:validate-impl ...（必要なら） /kiro:spec-status <feature>
実務のコツ（短く要点だけ）
- steering は“最初だけ頑張る共有脳”。一度厚めに作ると後工程のAI出力が安定する
- validate は“恐いところだけ使う保険”。毎回フルで回すより、手戻りリスクの節目に差す方が費用対効果が高い
- tasks の P0/P1 を真面目に守ると並列開発が安全化する
このフローをベースに、テンプレート（.kiro/settings/templates/*.md）やルール（.kiro/settings/rules/*.md）をいじると、自社プロセスに寄せた“SDD量産ライン”が作れます。
WBSテンプレ（cc-sdd / 仕様駆動開発）
使い方：各行の
[ ]を進捗に使い、Owner / Due / Estimate / Notesを埋める。
タスクIDはtasks.mdのIDと一致させるとトレースしやすい。
0. プロジェクト共通（Steering / 前提整備）
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 0.1 | 既存ステアリングの棚卸し | - | 現状メモ | 既存.kiro/steeringがある前提 |
|||
| 0.2 | Steering 初期化/更新 | /kiro:steering |
.kiro/steering/*.md |
プロジェクト原則/命名/制約/アーキ | |||
| 0.3 | 追加ルール・テンプレ整備（任意） | - |
.kiro/settings/rules / templates
|
自社ルールがある場合 |
1. Spec ワークスペース作成
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 1.1 | Feature名/スコープ決定 | - | Feature定義 | 仕様フォルダ名と一致させる | |||
| 1.2 | Spec初期化 | /kiro:spec-init <feature> |
.kiro/specs/<feature>/ |
ここから仕様の単位が確定 |
2. Requirements（要件定義）
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 2.1 | 要件ドラフト生成 | /kiro:spec-requirements <feature> |
requirements.md(ドラフト) |
EARS/受入条件/未解決点 | |||
| 2.2 | 要件レビュー（人間） | - | コメント/修正案 | 利害関係者レビュー | |||
| 2.3 | 要件Fix | - | requirements.md(確定) |
トレース用にReq-ID安定化 |
Brownfield追加（既存コードがある場合）
| WBS ID | タスク | コマンド | 成果物 |
|---|---|---|---|
| 2.B1 | 既存との差分/矛盾分析 | /kiro:validate-gap <feature> |
gapレポート/課題一覧 |
| 2.B2 | 要件へ反映 | - |
requirements.md更新 |
3. Design（調査・設計）
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 3.1 | 設計ドラフト生成 | /kiro:spec-design <feature> |
design.md(ドラフト) |
必要なら research.md も | |||
| 3.2 | 技術調査の補完（任意） | - | research.md |
API/ライブラリ/既存影響 | |||
| 3.3 | 設計レビュー（人間） | - | コメント/修正案 | アーキ/QA/運用/セキュリティ | |||
| 3.4 | 設計検証ゲート（任意） | /kiro:validate-design <feature> |
design検証結果 |
NGなら2.x/3.xへ差し戻し | |||
| 3.5 | 設計Fix | - | design.md(確定) |
実装の唯一の参照元 |
4. Tasks（タスク分解・実装計画）
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 4.1 | タスク分解ドラフト生成 | /kiro:spec-tasks <feature> |
tasks.md(ドラフト) |
Req-ID紐付け、P0/P1ラベル | |||
| 4.2 | タスク粒度/順序レビュー | - | コメント/修正案 | “2-8時間/タスク”が目安 | |||
| 4.3 | タスクFix | - | tasks.md(確定) |
ここでWBSと同期 |
5. Implementation（タスク反復実装）
tasks.md の P0→P1 の順に回す。
各タスクは「実装→テスト→自己レビュー→検証」で1サイクル。
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 5.0 | 実装サイクル準備 | - | ブランチ/環境 | CI/ローカル整備 | |||
| 5.n.1 | タスクn 実装 | /kiro:spec-impl <feature> <task-id> |
コード変更 | task-idは tasks.md と一致 | |||
| 5.n.2 | タスクn テスト実装/更新 | - | テスト | unit/integration/e2e | |||
| 5.n.3 | タスクn 自己レビュー/静的解析 | - | 修正コミット | lint/format/typecheck | |||
| 5.n.4 | 実装検証ゲート（任意） | /kiro:validate-impl <feature> <task-id> |
検証結果 | NGなら5.n.1へ戻す | |||
| 5.n.5 | タスクn 完了条件チェック | - | Done判定 | 受入条件/Req-ID満足 |
※ 5.n.* を tasks.md の全タスク分だけ複製して使う。
6. Status / Close（進捗・締め）
| WBS ID | タスク | コマンド | 成果物 | Owner | Estimate | Due | Notes |
|---|---|---|---|---|---|---|---|
| 6.1 | Spec進捗サマリ更新 | /kiro:spec-status <feature> |
ステータス要約 | フェーズ承認/残タスク | |||
| 6.2 | リリース準備 | - | リリースノート/手順 | バージョニング/移行 | |||
| 6.3 | リリース/デプロイ | - | 本番反映 | 監視/ロールバック | |||
| 6.4 | 事後レビュー/steering還元 | /kiro:steering |
steering更新 | 学びを次へ残す |
便利な運用ルール（WBSと噛み合わせるコツ）
- WBS ID と tasks.md の Task-ID を一致させる → 要件トレースが自動で通る。
- validate系は “差し戻しが高コストな節目だけ” WBSに入れる（常時は不要）。
- Brownfieldは
2.B1 validate-gapを 最優先でWBSに刺す。これを後回しにすると地獄を見る。
このテンプレをあなたのリポジトリ/運用に合わせて、列（リスク、依存、CIリンクなど）を増やせばそのまま“SDD用の実行計画書”になります。