人間とAIのハイブリッドチーム向けスプリント：Sharklyでのスプリントの仕組み

スプリントプランニングは、これまで常にひとつの暗黙の前提に支えられてきた。キャパシティとは、人数にタイムボックスを掛けたものだ、という前提である。作業を見積もり、前サイクルでチームが完了した量と比較し、収まる範囲のスコープにコミットする。

そこにAIコーディングエージェントを加えると、この方程式は現実を表さなくなる。エージェントはタスクが準備できた瞬間にそれを引き受け、他のあらゆるエージェントと並行して作業し、それを議論する予定だったスタンドアップが始まる前に、差分とテスト結果を携えて戻ってくる。実行キャパシティは劇的に膨らむ。つい取りたくなる対応は、より多くのスコープにコミットすることだが、そうしたチームはたいてい最初のサイクルの終わりに失敗の形を目の当たりにする。スプリントが終わってみれば、完成したコードは山ほどあるのに、レビュー未了の変更が壁のように積み上がり、誰もそれを受け入れる時間を持てていないのだ。

これが本記事の主張である。チームにエージェントが加わると、実行はもはやスプリントの制約ではなくなり、人間によるレビューがスプリントの制約になる。どれだけのコードを生み出せるかではなく、受け入れスループットを基準に計画を立てよう。具体的な仕組みとしてはSharklyのスプリントを取り上げ、プランニングに関する議論とプロダクトの事実は明確に分けて述べる。

TL;DR

Sharklyのスプリントは、ひとつのスペースが所有するタイムボックス化されたタスクの集合だ。実行と議論の源はあくまでタスクであり、スプリントはそこにスケジュール、スコープ、レポートを加える。スプリントは任意で、2つのモードのいずれかで運用する。Sharklyがスケジュールを維持し未完了の作業を次に繰り越す「自動ケイデンス」か、人が明示的にスプリントを作成・開始・完了する「手動」モードだ。レポートはスコープ、着手済みおよび完了済みの作業、完了率、キャパシティ、バーンアップ履歴をカバーする。人とエージェントのハイブリッドチームにとってのプランニングの転換点はこうだ。エージェントは実行キャパシティを膨らませるが、受け入れは人の手に残る。したがって、誠実なスプリントコミットメントは、エージェントがどれだけ生み出せるかではなく、レビュアーがどれだけの完成した作業を受け入れられるかによって上限が決まる。

Sharklyにおけるスプリントとは

スプリント とは、ひとつのスペースが所有するタイムボックス化されたタスクの集合である。チームが焦点を絞ったスコープを計画し、進捗を追跡し、タイムボックスが終わったときに未完了の作業をどう扱うかを決めるのに役立つ。実行と議論の源はあくまでタスクであり、スプリントはその上にスケジュール、スコープ、レポートを加える。

ドキュメントでは「スプリント」という用語を使っており、これは業界で一般的に使われる意味と同じだ。スクラムガイドはスプリントを、アイデアが価値に変わる固定長のコンテナとして説明しており、Sharklyのスプリントもその系譜を受け継いでいる。Sharklyが変えるのは、その時間枠の中で誰が実行するかという点だ。

この概念を明確に保つ3つの境界がある。

• スプリントは必ずひとつのスペースに属する。タスクをスプリントに入れても、その所有権は変わらない。
• スプリントは任意で、スペースごとに有効化する。継続的フローで考えるスペースは、そもそも有効にしなくてよい。
• スプリントはプロジェクトでもビューでもない。特定のタイムボックス内で何を完了すべきかが問いならスプリントを使う。複数のスプリントやスペースにまたがる成果ならプロジェクトを使う。タスクを確認するための保存された見方ならビューを使う。

この最後の区別はハイブリッドチームで実際に役に立つ。プロジェクトは成果を、スプリントは直近のコミットメントを保持し、ビューは各人が日々必要とする切り口を保持する。

自動ケイデンスか手動モードか

スペースでスプリントを有効にすると、2つのライフサイクルモードからひとつを選ぶ。この選択が変えるのはライフサイクルの挙動であり、タスクの所有権ではない。

自動ケイデンスはカレンダーをSharklyに任せる。スプリントの期間、任意のクールダウン、開始曜日、維持する将来のスプリント数、タイムゾーン、そして選択したステータスカテゴリに入ったタスクを自動的に追加するルールを設定する。あとはSharklyが将来のスプリントを作成し、スケジュールどおりに開始・完了させ、未完了の作業を繰り越す。予定より早く次のスプリントを開始すると、まず現在のスプリントが完了し、その未完了の作業が開始するスプリントに繰り入れられる。

手動モードではライフサイクルの制御はチームに残る。人は必要なときに予定済みスプリントを作成し、設定した日付を変えずに開始し、複数のアクティブなスプリントを並行して走らせ、完了時に未完了タスクの行き先を選ぶ。自動作成、繰り越し、クールダウン、ステータスに基づく追加ルールは、手動モードでは無効のままになる。

判断の基準はシンプルだ。チームが安定したリズムで動いていて、その仕組みの維持を任せたいなら自動ケイデンスを使う。サイクルが不規則だったり、カレンダーではなくリリースが期間を決めたり、同時に2つのアクティブなスプリントが必要だったりするなら手動を使う。手動に切り替えると既存のスプリントは保持されるが、自動スケジューリングは止まる。スプリントを完全に無効化すると、アクティブなスプリントは完了し、将来のスプリントは削除され、完了済みデータはレポート用に保持される。

タスクがスプリントに入り、出て、スキップする仕組み

スプリントの表示状態は5つある。Current、Upcoming、Planned、Completed、Canceledだ。完了済みおよびキャンセル済みのスプリントは、アクティブなプランニングリストを散らかすことなく、スペースのアーカイブに移動する。

タスクは、そのスプリントフィールドから、タスクリストから、あるいはスプリントプランニング中に追加・移動できる。見た目以上に重要なルールが2つある。

1つ目。タスクはスプリントをまったく持たなくてもよい。バックログの作業や、どのタイムボックスにもコミットしていないタスクにとって、これはごく普通の状態だ。

2つ目。タスクをスプリントに追加してもステータスは変わらない。これはハイブリッドチームがしっかり頭に入れておくべきルールだ。Sharklyでは、バックログのステータスカテゴリは待機状態であり、タスクを作成したりエージェントを割り当てたりしても、タスクがバックログにある限り実行は始まらない。割り当てられたエージェントを動かせるのは、タスクをバックログから準備完了のステータスへ移したときだ。つまりスプリントプランニングと実行のリリースは、まったく別のレバーである。月曜日にスプリント全体を計画し、エージェントもすでに割り当てておきながら、各タスクを意図的に準備完了ステータスへ移すまで何も走らない、ということができる。あとはステータス変更のオートメーションで、標準化したい遷移を拾えばよい。

もうひとつ、履歴を守るルールがある。過去のスプリントに追加できるのは完了済みのタスクだけだ。これにより、未完了の作業を閉じた期間に入れることなく、履歴の修正ができる。

日付について言えば、計画済みスプリントは開始と終了の両方を編集できるが、アクティブなスプリントは開始が固定され、終了は変更できる。

スプリントレポートから読み取れること

スプリントレポートにはタスク数が含まれ、スペースで見積もりが有効になっていれば、スコープ、着手済み作業、完了済み作業、完了率、キャパシティ、バーンアップ履歴という6つの指標で見積もりポイントの合計も示される。

キャパシティはもう少し詳しく見る価値がある。プランニングの会話がよりどころにする数値だからだ。Sharklyは十分な履歴があれば直近の完了済みスプリントのベロシティから算出し、なければスペースの規模に基づく推定値にフォールバックする。ドキュメントでは、これを保証ではなくプランニングの入力として扱うよう書かれているが、ハイブリッドチームにとってこの但し書きは定型文ではない。人間だけの集団で測ったベロシティは、エージェントを3体加えた週から何も予測しなくなる。むしろバーンアップ履歴のほうが雄弁なことが多い。スコープが序盤に一気に完了し、その後グラフが平坦になるなら、エージェントは実行を終え、レビュアーがスプリントの残り時間を追いつくために費やしたということだ。

ハイブリッドチームの制約：実行ではなくレビューを基準に計画する

このセクションの内容はすべてプランニングに関する主張であり、プロダクトの機能ではない。Sharklyは上記のスプリントの仕組みを提供するが、スプリントにどれだけ詰め込むかは判断の問題だ。

まず分業から考えよう。エージェントは調査し、実行し、テストし、報告する。人は方向性を示し、権限を与え、結果を受け入れる。エージェント型コーディングでは、方向性の提示と受け入れの間にあるものはすべて委任できるが、受け入れは人間の手に残る。タスクを終えたエージェントは、スプリントが完了と数えるべき意味ではまだ終えていない。差分、検証結果、既知の限界がタスクに戻ってきており、人がそれを読み、受け入れるか、変更を求めるか、マージを決める必要がある。

では計算してみよう。5人のチームがエージェントを追加し、実行スループットが3倍になったとする。レビューのスループットは3倍にはならない。同じ5人が担っており、受け入れる変更のひとつひとつが実際の注意力を消費する。実行キャパシティを基準にスプリントを計画すれば、余剰は出荷される価値にはならない。レビュー未了の作業の待ち行列になる。そしてレビューされていない変更は進捗ではなく在庫だ。さらに悪いことに、終わりが近づいたスプリントは、レビュアーをエージェント中心の開発を危険にする近道へと追いやる。つまり、読まずに出力を受け入れることだ。

だから問いを反転させよう。2週間でチームがどれだけ実行できるかではなく、2週間で人がどれだけのエージェントの完成作業を受け入れられるかを問う。実際には、これによって4つの習慣が変わる。

1. 見積もるのは構築コストだけでなくレビューコスト。エージェントにとって実行が簡単なタスクでも、受け入れにはコストがかかることがある。
2. 完了済みだが未受け入れの作業の同時数を上限で抑える。レビュアー1人が1スプリントで本当に受け入れられるタスク数を決め、その合計を超えて計画しない。これはSharklyの設定ではなくチームのワーキングアグリーメントだが、超過したときは完了の指標が教えてくれる。
3. 実行のリリースは意図的に行う。バックログが実行を待機させるので、開始をずらし、2日目に一気にではなく、レビュアーが消化できるペースで完成作業が届くようにできる。
4. 完了率はレビューの数値として読む。エージェントが遊んでいるのにバーンアップが平坦になるなら、制約が正体を現したということだ。それはレビュアーを増やすか、コミットを減らす合図であり、エージェントを増やす合図ではない。

これらはどれもエージェントの速度を落とすものではない。狙いを定めるものだ。受け入れスループットを基準に計画されたスプリントは、コミットしたものをすべて出荷し、読む時間のなかったコードを承認するよう人に求めることはない。

ハイブリッドスプリントの計画手順

1. スペースでスプリントを有効にし、モードを選ぶ。安定したチームリズムなら自動ケイデンス、リリース主導の作業なら手動が向いている。
2. スコープを形づくる。候補タスクをスプリントプランニングまたはスプリントフィールドから次のスプリントに引き入れる。コミットしない作業はスプリントなしのままにしておく。
3. 各タスクの両方の側面を割り当てる。Sharklyは人間の責任とエージェントの実行を分けている。人は担当者のセットに入り、エージェントまたはクルーは単一の実行スロットに入る。片方を変えても、もう片方は変わらない。
4. エージェントが動けるタスクを書く。説明には、新しい人やエージェントが進めるために必要な目標、制約、受け入れ基準を含める。
5. レビューのペースで作業をリリースする。レビュアーの余力ができたタイミングでタスクをバックログから移す。
6. 意図を持ってクローズする。手動モードでは、未完了のタスクすべての行き先を選ぶ。自動ケイデンスでは、何が繰り越されたかを確認し、スコープが大きすぎたのか、レビューが遅すぎたのかを問う。

このように仕事を進めるためのより広い方法論は、AIエージェントプロジェクトマネジメントに関するピラー記事で扱っている。スプリントはそのシステムのタイムボックス化された一部分だ。

今スプリントをJiraで運用しているなら

これらを試すためにプロセスを作り直す必要はない。SharklyのJira連携はJiraのスプリントデータを取り込むことができ、スプリントのインポートを有効にすると、対象のスペースをJiraスプリントモードに切り替えられる。こうして、チームがすでに回しているケイデンスをゼロから始めるのではなく、そのまま持ち込める。JiraチケットをAIエージェントに割り当てる方法のウォークスルーでは、同じ考え方をチケット1枚のレベルで説明しており、Sharklyのドキュメントではスプリントの設定とJira連携を詳しく扱っている。

移行よりも小さく始めよう。ひとつのスペースでスプリントを有効にし、レビュアーの実際の受け入れキャパシティを基準に2週間の期間を1つ計画し、バーンアップを直前の人間だけのサイクルと比較してみるといい。

FAQ

Sharklyでスプリントを使う必要はありますか？

いいえ。スプリントは任意で、スペースごとに有効化します。継続的フローを好むスペースなら、まったく有効にしなくても構いません。また、スプリントを有効にしていても、タスクがスプリントをまったく持たないことは可能で、これはバックログの作業では通常の状態です。

スプリントが終わったとき、未完了のタスクはどうなりますか？

自動ケイデンスでは、Sharklyがスケジュールどおりにスプリントを完了し、未完了の作業を次のスプリントへ繰り越します。手動モードでは、完了フローで未完了タスクの行き先を尋ねられます。スプリントなし、別のアクティブまたは今後のスプリント、あるいは新しく作成したスプリントのいずれかです。

エージェントはスプリントのタスクを自動的に進められますか？

タスクの実行担当として設定されたエージェントまたはクルーは作業を進められますが、スプリントに属しているだけでは何も始まりません。バックログは待機状態なので、バックログのタスクにエージェントを割り当てても実行は始まりません。タスクを準備完了ステータスへ移すことで実行が始まります。この分離により、まずスプリント全体を計画し、レビュアーが消化できるペースで実行をリリースできます。

Sharklyはスプリントのキャパシティをどのように算出しますか？

キャパシティは、十分な履歴があれば直近の完了済みスプリントのベロシティを使い、なければスペースの規模に基づく推定値にフォールバックします。ドキュメントでは、保証ではなくプランニングの入力として扱うよう勧めており、これはハイブリッドチームではなおさら重要です。ベロシティは内部のレビューのボトルネックではなく、システム全体を測るものだからです。

すでに終了したスプリントにタスクを追加できますか？

過去のスプリントに追加できるのは完了済みのタスクだけです。これにより、期間内に完了したものの記録されなかった作業を反映するといった履歴の修正が可能になり、未完了の作業を閉じた期間に入れることはありません。