Coroidには4種類の作業単位が存在します。これらは入れ子構造になっており、適切な単位を選ぶかどうかは、作業の規模や同時に実行すべき量によって決まります。
| 単位 | 規模 | 完了時期 |
|---|---|---|
| タスク | 1回の変更 | 1つのpull request |
| 計画 | 機能を段階的に実装 | 計画全体に対して1つのpull request |
| スプリント | 一定期間にわたる作業のまとまり | 各タスクが生成する成果物 |
| レーン | 並列で実行される作業の流れ | 計画の作業が統合されるブランチ |
タスク
最も基本的な単位です。1つのタスクは1つのpull requestを生成する作業単位であり、実際に実行される対象でもあります。計画やスプリント、レーンはすべてタスクを整理するための仕組みです。
結果を1段落で説明でき、レビュアーが一度に内容を確認できる場合、それがタスクです。
計画
特定の順序で複数の変更が必要な場合、それが計画となります。これは段階に分けてグループ化されたタスクの順序付けられた集合であり、コードを記述する前に承認を受けます。
以下の場合に計画を使用します：
- 後続のステップが先行するステップに依存する場合
- いずれかのステップを実行する前に全体のアプローチを確認したい場合
- 作業内容が単なる変更ではなく機能である場合
計画を承認するのはシステム内で最もコストが低い介入ポイントです。ここでアプローチを却下するコストは1分程度ですが、3つのタスクが実行された後に却下すると3回分の実行コストがかかります。
計画がリポジトリに到達するまでの流れ
計画のタスクはそれぞれ別のpull requestを作成しません。各タスクは独自のブランチで作業し、共通のレーンブランチにマージされ、そのブランチがベースブランチに対して1つのプルリクエストとして昇格します。
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘こうすることで、未完成の段階ごとに承認するのではなく、完成した機能全体を一度にレビューできます。
例外として、複数のプロジェクトにまたがる作業の場合、レーンとは異なるプロジェクトに属するタスクは個別に処理されるため、クロスプロジェクトの計画ではリポジトリごとにpull requestが生成されます。これは避けられない仕様であり、pull requestは2つのリポジトリにまたがることはできません。
スプリント
時間制限付きの作業コンテナであり、独自の指標とタイムラインを持ちます。スプリントは「この期間に何を実施し、その結果はどうだったか」を問うものであり、「この機能がどのように構築されるか」を問うものではありません。
チームの作業を一定期間調整する場合はスプリントを、1つの機能を分解する場合は計画を使用します。両者は代替関係にあるわけではなく、スプリント内に複数の計画に属するタスクが含まれることもあります。
レーン
レーンは計画の並列作業が統合される場所です。タスクはベースブランチではなくレーンのブランチを対象とするため、複数のエージェントが同時に作業しても競合せず、条件を満たした時点で1つのpull requestとして昇格します。
計画が重視するのは順序一方、レーンが重視するのは並列性と統合です。複数のエージェントを活用でき、厳密に直列化する必要のない作業がある場合、レーンを利用すれば同時に実行しつつ、1つのレビュー可能な変更としてまとめることができます。
選択方法
重要なのはプルリクエストの数ではありません。タスクも計画もどちらも1つとして到達します。重要なのは、結果をレビューする価値があると判断するまでにどれだけの作業が必要かという点です。
- **レビュアーが一度に読めるような1回の変更か？**はい → タスク。
- **全体として意味をなすためには、複数の順序付けられた変更が必要か？**はい → 計画。そのレーンを利用して、可能な範囲で並列に作業を実行します。
スプリントはこれらすべてと並列に位置づけられる計画・報告レイヤーです。
同時に実行できる作業量を制限する要因
構造ではなく能力です。並列実行可能なタスクが10個ある計画でも、エージェントのスロットが1つしかなければ順番に実行されます。詳細は能力とエージェントスロット.