3行まとめ
- claude-scrum-team は、Claude Code の Agent Teams を使って、要件定義からリリースまでをスクラムの流れで進められるフレームワークです。利用者はProduct Ownerとしてスクラムに関わります
- スピーディーなPDCAサイクルを実現しつつ、スクラムの枠組みによって開発に秩序を持ち込めるようにすることが狙いです
- この記事ではAIだからこそできる拡張やすべき制約など試行錯誤を紹介しつつ、当初の「速さと秩序の両立」というテーマに対して考察をしています
はじめに
Vibeコーディングのスピードは魅力的ですが、開発が長期化すると全体の秩序を保つのが難しくなります。
一方で、Spec-Driven Development（SDD）は秩序を保ちやすいものの、初期段階で多くを定義する必要がある点が悩ましいところです。
実際のプロジェクトの多くはその中間にあり、最初からすべてが決まっているわけではない一方で、進めながらも全体の秩序を守っていく必要があります。
そこで、Claude Code の Agent Teams を使った スクラム開発チーム を立ち上げました。
スクラムの 継続的な見直しと改善のループ を Claude Agent Teams にもたらし、完全な仕様を最初から要求せずに 構造化された反復開発 を実現したものが claude-scrum-team です。
claude-scrum-team は、利用者が Product Owner として関わりながら、要件定義、バックログ管理、スプリントプランニング、設計、実装、クロスレビュー、スプリントレビュー、レトロスペクティブ までを、一連の開発フローとして回せる ようにしています。
この記事では、実際にどのような流れで動くのか、そしてこの取り組みはうまく機能したのかを、すぐに試せるリポジトリ とともに紹介します。
claude-scrum-team 紹介
claude-scrum-team は、単なるマルチエージェント実行ではなく、スクラムの開発フローを実現するフレームワークである のが特徴です。
デモ
開発プロジェクト上で 1つのコマンドを実行するだけ で、AIスクラムチーム が起動します。
あなたは Product Owner として Scrum Master（AIエージェントのリード）に要望を伝え、必要に応じて進め方や成果物にフィードバックするだけです。
リアルタイム TUI ダッシュボードによって、スクラムの進行状況を一目で確認できます。
クイックスタート
# リポジトリをクローン
git clone git@github.com:sohei56/claude-scrum-team.git
# 開発対象のプロジェクトディレクトリへ移動
cd /path/to/your/project
# スクラムチームを起動
sh /path/to/claude-scrum-team/scrum-start.sh
Gitリポジトリ
ぜひ Issue や PR をお寄せください！
セッションの流れ
通常のスクラム開発に近い流れで進行します。
-
要件定義 — Scrum Master が Developer を起動し、あなた から聞き出したプロジェクトの概要を整理して
requirements.mdを作成します - バックログリファインメント — Scrum Master が要件をもとに PBI を作成・詳細化します
- スプリントプランニング — Scrum Master が Sprint Goal を提案し、あなた が承認または調整します
- 設計・実装・クロスレビュー — Developer が PBI ごとに並列で設計・実装を進め、その後、お互いの成果物をレビューします
- スプリントレビュー — Scrum Master がアプリケーションを起動し、完了した PBI をデモします。あなた がそれぞれの動作を確認し、フィードバックします
- レトロスペクティブ — Scrum Master と Developer が改善点を振り返り、以降の Sprint に反映します
- この流れを繰り返す — Product Goal を達成するまで繰り返し、最後に Integration Sprint で自動テストと最終 UAT を実施します
┌─────────────────────────────────────────────────────────────┐
│ Requirements Sprint (Sprint 0) │
│ Requirements Elicitation ──▶ Initial Product Backlog │
└──────────────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────┐
│ Sprint N │
│ │
│ 1. Backlog Refine PBIs: draft ──▶ refined │
│ ▼ │
│ 2. Planning PO approves Sprint Goal │
│ ▼ │
│ 3. Scaffold Specs Create design doc stubs from catalog │
│ ▼ │
│ 4. Spawn Teammates Launch Developer agents for PBIs │
│ ▼ │
│ 5. Design Write design specs (parallel) │
│ ▼ │
│ 6. Implementation Build features with TDD (parallel) │
│ ▼ │
│ 7. Cross-Review Devs review each other's work │
│ ▼ │
│ 8. Sprint Review Demo to PO, accept/reject PBIs │
│ ▼ │
│ 9. Retrospective Record improvements for next Sprint │
└──────────┬──────────────────────────┬───────────────────────┘
│ │
▼ ▼
Next Sprint N+1 ┌───────────────────────────────────────┐
│ Integration Sprint │
│ Smoke Tests ──▶ UAT ──▶ Release │
└───────────────────────────────────────┘
主な特徴
-
スクラムのライフサイクル全体をカバーする14個の ceremony skills
要件整理、バックログリファインメント、スプリントプランニング、設計、実装、クロスレビュー、スプリントレビュー、レトロスペクティブ、結合テストなどを Skill として提供しています -
マルチエージェントによる並列開発
Scrum Master（Delegate mode）が、1 Sprint あたり最大6体の Developer エージェントを並列にオーケストレーションします -
リアルタイムTUIダッシュボード
Textual ベースの4画面構成（Sprint Overview、PBI Progress Board、Communication Log、Work Log）で進行状況を可視化します -
状態の永続化
すべての状態を.scrum/配下の JSON ファイルに保存し、セッションを途中から再開できます -
レトロスペクティブ駆動の改善
過去の Sprint で得られた改善点を、次の Sprint に自動的に反映します
AIエージェントに合わせた調整
claude-scrum-team は、人間向けの Scrum をそのまま適用したものではなく、AIエージェントの特性に合わせて調整したフレームワークです。
AIの強みを活かす拡張
-
ダイナミックなチームサイジング
1 Sprint あたりの Developer エージェント数は、PBI の件数や複雑さに応じて最適化されます -
オンデマンドな専門化
各 Developer は担当する PBI に応じて、awesome-claude-code-subagents のカタログから適切な専門サブエージェントを選択して起動します。
たとえば、フロントエンドの PBI を担当する場合は、UI 専門のサブエージェントを起動します -
POドリブンな Sprint スコープ
Sprint の区切りは velocity の見積もりではなく、PO 目線で意味のあるレビューができるスコープで決めます。
これにより、あなたは各 Sprint Review で毎回新しいものを目にすることになります
AIの弱みを補う制約
-
Requirements Sprint の必須化
最初の Sprint は要件整理専用とし、エージェントが地図を持たないまま突き進むことを防ぎます -
作成可能なドキュメントを制御
設計カタログ.spec/catalog.mdに定義された種類のドキュメントだけを作成可能にすることで、AI が際限なく非構造なドキュメントを増やしてしまうのを抑えます -
品質を保つための各種hooks
フェーズゲート（ソースコード制約）、完了ゲート（終了条件）、品質ゲート（Definition of Done）、ダッシュボードイベント、セッションコンテキスト復元を備えています -
PBI のない作業を禁止
すべての開発作業をバックログ項目に紐づけることを強制し、Scrum Master が会話やフィードバックの途中で場当たり的な修正に流れてしまうのを防ぎます
考察 - この取り組みはうまくいったのか？
結論としては、当初の「速さと秩序の両立」というテーマに対して、一定の成果はあったと感じています。
一方で、シチュエーションによっては多少の秩序を持ち込んだ Vibe コーディングにすぎないと捉えることもできそうです。
よかった点
-
Sprint という区切りを設けることで、AI の開発に細かなレビューポイントを設けられるようになり、早い段階で軌道修正できる仕組みとして機能した
-
ドキュメントや品質の管理については、試行錯誤の結果として、一定程度満足できるアウトプットを出せる仕組みを作ることができた
-
Sprint ごとのマルチエージェントリソースの最適化（ダイナミックなチームサイジング、オンデマンドな専門化）は、少なくとも私が知る限りでは他にあまり見ないアプローチであり、機能しているように感じた。
これにより、開発者が足りない、PBIが足りない、開発者の特性にあったPBIがない、といったスクラムの管理で困りがちな問題を解消できました
改善の余地が残る点
-
PO の質に依存する開発手法ではある。場当たり的な PO が使うと、余計な Token を消費するだけの Vibe コーディングになりかねない
（導入したいくつかの仕組みが、ある程度のガードレールとしては機能すると思うが） -
プロジェクトの終盤はどうしても Vibe コーディング的な進行（フィードバックして修正し、再度レビューするサイクルを複数回回す形）になりやすい。
ここについては、スクラムより適したアプローチがあるようにも感じている -
クロスレビューを導入したことで、先に開発を終えたエージェントが、他のエージェントの実装完了を待つ構造になっている。
この点は、まだ最適化の余地が残っている
さいごに
開発目的に使うAIエージェントとしてはかなり気に入ったので、しばらくはこれを育ててみようと思っています。
これからは投資AIエージェント（私は仮想通貨botterでもあります）やビジネス目的のAIエージェントも作っていきたいです。
余談ですが、claude-scrum-teamを作る際にspec-kitを使ってみたのですが、生成されたドキュメントの管理コストが高すぎてどうにかしたい。。
おまけ
claude-scrum-team を使っていて、特に嬉しかった場面をいくつか紹介します。
① 23 Sprint / 53 PBI の開発を完遂した
中規模の開発でも、秩序を維持したままリリースまで完遂できました。
② 作成されるドキュメントに秩序が生まれた
試行錯誤の末、AI が作成するドキュメント類に、ようやく秩序をもたらせられました。
③ コードとドキュメントの不整合を自分で見つけた
Sprint Review で、AIエージェントがコードとドキュメントの不整合を自律的に見つけ、PBI 化までしてくれました。
④ Retrospective の改善がきちんと実行された
自己改善のループが実際に回ってくれるのは、見ていてかなり嬉しいポイントでした。
