この記事はHTアドベントカレンダー12日目の記事です。
tl;dr
- 7人チームでcc-sdd（仕様駆動開発）を導入した
- requirements→designのPRレビュー、Claude Hooks、モノリポ化で運用を回している
- 実装より仕様検討の比重が増え、チーム構造の再定義を検討中
自己&チームの紹介
- CREATIVE BLOOM DISPLAY Adsの開発・TLをしてます。
- AIを活用し、ディスプレイ広告作成業務の効率化・高度化を実現「CREATIVE BLOOM DISPLAY Ads」を提供開始
チームの概要
- クリエイティブ (画像・動画)の制作・管理・分析を支援するプロダクトを開発
- 開発メンバー7名 + 企画2名のチーム
- 開発はBE/FE/インフラをメンバー全員が取り組む
- BEとFEはモノリポ管理
AI機能のための非同期ジョブに関するリポジトリやインフラのリポジトリは別々で管理 - 企画メンバーが機能要望 + 画面仕様を上げて開発メンバーがそれをもとにチケット化して実装
- 機能要望が多く、7名がそれぞれ異なる機能を担当している
仕様駆動開発
- 仕様駆動開発（Spec-Driven Development）は、要件定義→設計→タスク分解→実装というプロセスを構造化し、AIエージェントと協調しながら開発を進める手法です
- 従来の開発では、頭の中で設計しながらコードを書くことも多かったですが、AIエージェントに実装を任せる場合は「何を作るか」を明文化しておかないと意図しない実装になりがちです。仕様駆動開発では、各フェーズでドキュメントを生成・レビューすることで、人間とAIの認識を揃えながら開発を進められます
- 今回チームで導入したのが cc-sdd です。AWSが発表したkiroの仕様駆動開発ワークフローを、Claude CodeやCursorなどの既存ツールで再現できるようにしたOSSです
# まずプロジェクトコンテキストを確立、その後開発を進める
/kiro:steering # AIが既存プロジェクトコンテキストを学習
/kiro:spec-init 既存認証にOAuthを追加 # AIが拡張計画を作成
/kiro:spec-requirements oauth-enhancement # AIが明確化のための質問
/kiro:validate-gap oauth-enhancement # オプション: 既存機能と要件を分析
/kiro:spec-design oauth-enhancement # 人間が検証、AIが設計
/kiro:validate-design oauth-enhancement # オプション: 設計の統合を検証
/kiro:spec-tasks oauth-enhancement # 実装タスクに分解
/kiro:spec-impl oauth-enhancement # TDDで実行
cc-sddを選んだ理由
- 作者が日本人: ドキュメントやツール内の回答文も日本語なので馴染みやすいです
- チーム開発向けのアップデートが充実: 個人利用だけでなく、チームでの運用を想定した機能が頻繁に追加されています
- 導入ハードルの低さ: 実態はClaude Codeのカスタムコマンド。すでにClaude Codeを使っていれば、新しいツールを覚える必要がありません
チームでの運用ポイント
- requirements → designまで生成したら一度PRでレビュー実施
- Claude HooksでLintとTestを実施
- TDDはしてくれるが、Lintをよく忘れる
- PR作成、PRレビューに関するカスタムコマンドを作成
- 高頻度かつ大量にPR作成とレビューがされるので、なるべく自動化する基盤を整えておく
- リポジトリは集約させて状態で要件を生成
- AI駆動関係なくBEとFEのリポジトリをモノリポ化していた。
- ローカル開発するのに必要な機能はモノリポでほぼ足りるのでコンテキスト漏れがなくせた。
導入してよかったこと
Agentic Codingの開発手法としてチーム内で共通化できる
- Claude CodeやCursorなどのツールを導入しただけでは、メンバー全員がすぐにAgentic Codingを実践できるわけではありません。Claude Codeが利用開始された当初はチーム内でもCopilotとのVibe Coding利用のメンバーが多かったです
- その点cc-sddの場合はカスタムコマンドを順に叩いていくだけなのでわかりやすいです
- 仕様駆動開発というワークフローに従っていったほうがAgentic Codingの勘所を掴みやすいと感じました
- 特にcc-sddはSubAgentの活用やコンテキストのメモリー化のやり方において勉強になる部分が多いです
- 作者のGota(https://x.com/gota_bara) さんはSub AgentやAgent Skillsに関する資料も公開されていて、こちらも併せて勉強になりました
既存プロジェクトでもワークしやすい
- steeringによって既存コードの慣習をドキュメント化してくれます
- それをガードレールに実装が進められるため意図しない実装になることが少ないです
- 既存プロジェクトの場合を想定したコマンドがあります (validate-*)
(個人的なメリットとして)作業再開時の集中状態が作りやすい
- TLというポジション柄、作業途中で相談を受けたりナッジングのためにSlackを徘徊することがあります
- 自力コーディングしていた時はMTGや相談を受けた後に再度フロー状態を作るのに15minくらい要していました
- タスクの実施状況と次何すればよいか？が明確なのですぐに作業に戻れます
困ったところ・疑問点
どういう場面で有効？
- 詳細設計→実装のフェーズで有効かと思います
- ゴールは決まっているが、道筋がぼんやりしているようなときに使えます
- UIの微修正や修正箇所が明らかな場合はVibe Codingまたは自力のほうが早いです
要件生成 (spec-init) の際にどんな情報を渡したらいい？
- 基本的になるべく多くの背景情報を渡してあげるべきです
- READMEには
/kiro:spec-init Photo albums with upload, tagging, and sharingと
簡易な文章が書いてありますがここは長文も入力できます - tipsとして、planモードで壁打ちした内容をmarkdownドキュメント化して、そのドキュメントを渡すというのをやっています
タスクはどの粒度で実行したらいい？
- 認知負荷を減らしたいのであれば、最小単位で実行させるのが良いです
- TDDで実装が進められるため、テストカバレッジも確保されレビュー時の品質担保がしやすくなります
- 同じ要件で複数同時開発させてその中で良いものを選ぶというやり方もできます
実装が思っていたようなものではなかった。
- エラーハンドリングやパフォーマンス最適化、E2Eテストなどを凝りすぎる傾向があるので要件生成の段階でそれらを消します
- 要件生成後に修正箇所が最小限になるように見直すように指示したり、設計生成後に本当にそれで良いのかultrathinkさせています
- requirementsのレビューを徹底することが大切です。最近手戻り発生は減りました
- kiroがPBT (Property Based Testing)に対応したことを受けてcc-sddでもPBT採用されるので、もう少しやりやすくなりそうです
ドキュメントのレビューが大変
- 正直ここは自分も模索中です
- SDDが生成する設計ドキュメント (design.md)は詳細設計レベルに踏み込んでいて、レビューするには骨が折れます
- ただ、タスク実行によってAIエージェントにコードを書かせるためにはある程度実装に踏み込んでエージェントと合意する必要があるので致し方ないと割り切っています
- 抽象的だと実装フェーズにおける手戻りが増える可能性が高まります
- レビューする時のコツとしてはrequirementsを丹念に読むことです
- 量も少ないし、ここで余計な要件が織り込まれていないかをチェックします
- cc-sddでは生成されるドキュメントのルールやテンプレートを設定可能です
PRサイズが大きくなりがち
- PRはなるべく小さくするのがチーム開発やDevOpsにおける原則とされています
- これはAgentic Codingとの相性は正直良くなく、実装が一気通貫で完了する良さを打ち消してしまいます
- 人間によるレビューもしますが量の面で限界があります
- チームとしてはGitHub Copilotによるレビューを入れています。また、チーム全員で機能をモンキーテストする時間を設けて動作保証をしています
マルチレポの場合はどうするべきか？
- 検証中ですが、集約リポジトリを一つ作ってそこにgit submoduleで関連リポジトリを集約して設計させるようにしています
- トークン消費は増えますが、リポジトリ間で情報を補完しあってくれるようになるので大規模な機能実装の際に使えないかと思っています
- /add-dirでもできなくはないですが都度指示する必要があり大変でした
今後やろうと思うこと
- 仕様駆動用の統合リポジトリの運用
- コンテキスト消費が激しそうなので、Token-Oriented Object Notation (TOON)やKIRI MCP Server
を使ってみたいです
- コンテキスト消費が激しそうなので、Token-Oriented Object Notation (TOON)やKIRI MCP Server
- チーム構造とロールの再定義
- 仕様駆動によって実装と仕様の時間比率が、以前は「実装7：仕様検討3」くらいだったのが、今は逆転しつつあります。実装はAIに任せられる部分が増えた一方、requirements や design のレビューに時間がかかるようになりました
- 現状の「1人1機能」体制だと、仕様の壁打ち相手がいません。AIと自分だけで要件を詰めていくと、視野が狭くなったり、レビューで初めて認識齟齬が発覚することがあります
- そこで「2人2機能」のようなペア体制を検討しています。エンジニア2名 + AIで1チームを組み、仕様検討の段階から議論できる構成です
- この辺りの議論は各所でも始まっています