人間とエージェントのチームにおけるスプリントプランニングは、実行速度ではなくレビュー容量を軸に計画を立てることで機能します。エージェントはレビュアーが受け入れられる以上のタスクを拾って完了させられるため、1サイクルの本当の制約は「どれだけのコードが書けるか」ではなく「人間が検査してマージできる完了済みの変更がいくつあるか」です。このガイドでは、その計画手法を順を追って解説し、各ステップで起こりがちな失敗パターンを示し、次のスプリント前に実行できるチェックリストで締めくくります。
従来のスプリントプランニングは、希少なリソースはエンジニアがコードを書く時間だという前提に立っています。そこにコーディングエージェントを加えると、この前提が崩れます。Claude Code、Codex、Gemini CLI はそれぞれ、あなたが前のタスクを読み終える前にタスクを拾って動く diff を返してきます。実行はボトルネックではなくなり、受け入れがボトルネックになります。
この変化は、普通の計画を静かに破壊します。開発者日数で2週間のサイクルを見積もったのに、エージェントは3日でバックログを焼き尽くし、完了済みなのに未レビューの変更が、マージを承認できる1〜2人の人間の後ろに積み上がります。スプリントは速く進んでいるように見えて、遅く終わるのです。
Sharkly は、このガイドで計画を立てるためのワークスペースです。コーディングエージェントはすでに手元にあるはずです。Sharkly は、あらゆるタスクとその進捗、ブロッカー、結果、人間によるレビューを、各ターミナルに散らばらせるのではなく1つの共有スペースにまとめることで、それらをチームへと変えます。Sharkly のスプリントは、1つのスペースが所有する、期間を区切ったタスクの集合です。以下の手法は、ホワイトボードで運用しても製品上で運用しても同じですが、作業が共有ボードに戻ってくれば失敗パターンにも気づきやすくなります。
エージェントが実行を担うと何が変わるか
人間とエージェントのチームにおけるスプリントプランニングとは、チームがどれだけコードを生み出せるかではなく、人間がどれだけの完了済みエージェント作業をレビューして受け入れられるかを軸にサイクルを設計する実践です。
エージェントは調査し、実行し、テストし、報告します。人間は方向性を定め、権限を与え、結果を受け入れます。この分担こそが計画上の課題そのものです。エージェントのスループットは伸縮自在で、3体でも10体でも動かせます。一方、レビューのスループットは、diff を読み、変更を実行し、出荷すると判断できる人数によって固定的に決まります。エージェントの出力が5倍になっても、出荷される作業が5倍になるとは限らない理由については、レビュー容量の計算をご覧ください。
つまり、計画の起点となる最初の数字はストーリーポイントではありません。レビュー枠です。レビュアー1人が1日あたりに受け入れられる完了タスク数 × レビュアー数 × サイクルの日数。ほかのすべては、この上限に収まらなければなりません。
スプリントを段階的に計画する
1. まずレビュー上限を決める。 レビュアーが1日に本当に受け入れられる完了タスク数を見積もります。自明でない変更をきちんとレビューするには30〜60分かかります。それにレビュアー数とスプリント日数を掛けます。失敗パターン: これを飛ばしてエージェントの処理能力で計画し、過剰にコミットし、サイクル終了時にスプリント自体より長いレビュー待ち行列を抱えることになります。
2. 実行ではなくレビューを基準にタスクをサイズ設定する。 各タスクが、1人が頭の中で把握できる diff を生むように作業を分割します。失敗パターン: エージェントは喜んで9ファイルにまたがる2,000行の変更を返してきますが、1つのレビュー枠では誰も受け入れられず、ボードの底で腐っていきます。
3. 割り当てる前に受け入れ基準を書く。 各タスクにはテスト可能な完了の定義が必要です。何を作るのか、「正しい」とはどういう状態か、触れてはいけないものは何か。失敗パターン: スコープが曖昧だとエージェントが推測で進め、レビュアーが差し戻し、1つのタスクでレビュー枠を2つ消費します。
4. 意図をもって単一のエージェントかクルーに割り当てる。 小さく明確な作業には1体のエージェントを使います。リーダーエージェントが目標を解釈し、他のメンバーを巻き込み、その結果を1つのタスクにまとめる必要がある場合はクルーを使います。失敗パターン: 些細な作業にクルーを動員すると可動部が増え、それをレビューしなければならなくなります。
5. 進行中の作業に上限を設ける。 カンバンにおけるWIP 制限と同じように、「レビュー中」列に置けるタスク数に上限を設けます。失敗パターン: 上限がなければ、エージェントは人間がさばくより速くレビュー列を溢れさせ、ボトルネックは最終日まで見えません。
6. 余裕のバッファを残す。 手戻りや差し戻す変更依頼のためにレビュー枠を確保しておきます。失敗パターン: 100%まで計画を詰めると、最初の「修正してください」の行き場がなくなります。
スプレッドシートやチケットだけの運用がスケールしなくなる地点
最初のスプリントはスプレッドシートでも回せます。タスクの一覧、担当者列、ステータス列があれば十分です。1人が1つのリポジトリで2体のエージェントを動かしているうちは、それで成り立ちます。
しかし実行とトラッキングが分離した瞬間に機能しなくなります。エージェントの実行、diff、テスト出力、議論はターミナルの中にあり、スプレッドシートには古い「進行中」が残ります。誰かが手作業で行を更新するか、誰も更新しないかです。2つ目のリポジトリに3体目のエージェントを加えれば、ボードは1日で現実から乖離します。そうなると、計画が依存する唯一の問いに答えられなくなります。何が完了し、何が自分の番を待っているのか?
この目的のために作られたタスクボードは、実行と記録を一体に保ちます。作業、進捗、ブロッカー、結果はプライベートなセッションに消えることなくタスクへ戻ってきます。Sharkly では、エージェントが準備完了のタスクを引き受け、並行する変更が衝突しないよう分離された worktree で実行し、その変更サマリー、検証結果、既知の制約がタスクのタイムラインに戻り、人間が受け入れるか差し戻すかを判断します。これが、自分で維持するステータスと、自ら維持されるステータスの違いです。さらに、次の計画セッションに本物のデータをもたらします。前サイクルでエージェントが完了した作業と、レビュー時間がどこに消えたかです。
正直な線引きをしておきます。1つのリポジトリで1体のエージェントを動かし、その都度レビューするなら、タスクボードも Sharkly も必要ありません。ターミナル1つとチェックリストで十分です。状況が変わるのは、複数のエージェント、タスク、リポジトリ、あるいは人をまたいで計画するときで、まさにそこでスプレッドシートが第二の仕事と化します。Sharkly は後者のケースのために作られています。スプレッドシートが嘘をつき始めたらダウンロードしてください。
次のスプリント前に実行するチェックリスト
計画を確定する前に、これを実行してください:
- [ ] レビュー上限(レビュアー数 × 1日あたりの受け入れ数 × 日数)を計算し、それをスプリントの実質的なキャパシティとして扱った。
- [ ] すべてのタスクが、1つのレビュー枠内でレビューできる大きさである。
- [ ] すべてのタスクにテスト可能な受け入れ基準と、明確な「触れてはいけない」境界がある。
- [ ] 各タスクは、デフォルトではなく意図をもって単一のエージェントまたはクルーに割り当てられている。
- [ ] 「レビュー中」列に WIP 上限がある。
- [ ] 手戻りと変更依頼のための余裕が確保されている。
- [ ] すべてのタスクについて、マージとリリースの判断を人間が担う。
- [ ] 進捗、ブロッカー、結果がプライベートなターミナルではなく共有ボードに戻ってくる。
8つすべてにチェックが入れば、エージェントの実行はチームが完了できる計画の範囲内に収まります。最初の1つを逃せば、残りがあなたを救うことはありません。
FAQ
エージェントがコードの大半を書く場合でも、スプリントプランニングは役に立ちますか? はい。ただし制約が移動します。スプリントはエンジニアリング時間の入れ物ではなくなり、レビューと受け入れの入れ物になります。人間がどれだけの完了済み作業を検査できるかを軸にサイクルを計画すれば、エージェントがそれを埋めてくれます。Scrum Guide は今もこのセレモニーを定義しています。変わるのはキャパシティの計算だけです。
人間とエージェントのチームのキャパシティはどう見積もればよいですか? エージェントではなくレビュアーを起点にしてください。1人が正直に受け入れられる完了タスク数を1日あたりで数え、それにレビュアー数とスプリント日数を掛けます。エージェントの数は、この上限を超えるまでは意味を持ちますが、超えてしまえばエージェントを増やしても行列が伸びるだけです。
スプリント中にエージェントが自分でタスクを選ぶべきですか? すでに受け入れ基準を備えた準備完了のタスクを引き受けさせることで、ディスパッチャーなしで並行作業が進みます。人間は方向性、権限、マージに専念します。こうすることで、判断が必要な場面に人間をループ内に残し、それ以外はすべて自動化できます。
通常のプロジェクトマネジメントと何が違うのですか? セレモニーは同じに見えますが、ボトルネックが違います。AIエージェントのプロジェクトマネジメントは、実行がもはや希少なリソースではないため、開発者の可用性ではなくレビューのスループットと変更の分離を軸に計画します。
新しいツールは必要ですか、それとも Jira を拡張できますか? チームがすでに理解しているシステムを使い続けてかまいません。ギャップは、チケットツールが人間が入力するステータスを追跡するのであって、機械が実行する処理そのものを追跡しない点にあります。そのギャップが痛み始める場所については、人間とエージェントのチーム向け Jira 代替ツールをご覧ください。
