4日ビルド + 1日クールダウン

原作がサイクル(cycle)の長さとして6週間を選んだ根拠は、期間の絶対値ではなく二つの条件のバランスでした。意味のある何かを最初から最後まで作り切れるだけ長く、始まりの時点から全員が締め切りの近づくのを実感できるだけ短い期間だ、というものです (第1章: 導入)。

そのバランスは、人がコードを書くという前提の上で合わせられたものです。作るのにかかる時間が6週間を埋めていたからこそ、6週間が「完成させられるだけ長い」期間でありえました。二つの条件はそのままにして前提だけを外すと、答えが変わります。

圧縮の根拠と限界

まず正直に指摘しておくことがあります。サイクルが短くなるという主張は今あふれていますが、その大半はベンダーとコンサルティングのブログであり、「6〜12か月が6〜12週間に」といった文は検証されたベンチマークではありません (SDLC in the AI era)。一次出典に最も近い数値は、GoogleのSundar Pichaiが公の場で明かしたと報じられているエンジニアリング速度の約10%向上で、これは社内コードの4分の1がAI支援で書かれている状態で出た数字だと伝えられています。10倍という物語とは桁が違います。第1章で見たMETRの実測まで並べて置けば、実装が数十倍速くなったのだからサイクルも数十分の一になる、という算術は成り立ちません。

それでも圧縮が成り立つ理由は、別の算術にあります。サイクルの長さを決める変数そのものが変わったからです。実装が分・時間の単位で終わるなら、残る変数はビルド時間ではなく、シェイピングと検証に使う人の時間です。第2章でボトルネックが検証とレビューへ移ったと述べた話が、ここでタイムボックスを測り直す理由として戻ってきます。

ここにもう一つ前提が付きます。サイクルは作業時間の見積もりではなく、再ベッティングのリズムだということです。デプロイはサイクルの終わりにまとめてではなく、サイクルの中でスライス単位で起こり続けるので、サイクルを縮めて手に入るのは、より速いリリースではなくより頻繁な意思決定です。

一週が一つの心拍: 4日 + 1日

ロボコのVDLCは週を日に置き換えつつ、心拍(heartbeat)はカレンダーの週に揃えます。4営業日のビルドに1日のクールダウン(cool-down)、一週が一つの心拍です。月曜の朝にベッティングし、金曜にクールダウンで一週を閉じます (VDLC 週次サイクル)。

Day	やること	完了条件
Day 0 (月・朝)	ベッティングテーブル。ピッチ検討、並列ベッティングの配分	各ベットに二重予算(注意力・コンピュート)を明示
Day 1 (月)	垂直スライス一つをデプロイ可能な状態へ統合	実環境で動作するスライス1本
Day 2–3 (火・水)	委任可能性マップを見て委任	必須スコープのすべてが下り坂に入る
Day 4 (木)	検証ゲート。新規コーディング禁止	Done = Deployed の判定
Day 5 (金)	クールダウン。再生成検証と次のベッティング準備	再生成成功、または負債の逆移転完了

Day 0の用語は原作から来ています。ピッチ(pitch) はシェイピングの成果物である提案書で、解こうとする問題、解決の輪郭、アペタイト、やらないことの境界を一つの文書にまとめたものです(4章)。ベッティングテーブル(betting table) は、そのピッチを並べて今サイクルで何を作るかを決める場です。バックログから次のチケットを取り出すのではなく、ピッチ単位で予算を賭けるベッティングであり、選ばれなかったピッチは持ち越されず手放されます。並列ベッティングの配分はこの時代の変形です。エージェントが複数の案件を同時に進められるため、ベットを一つに絞らず、2〜3件に注意力・コンピュートの予算を分けて賭けます。この再構築は6章で詳しく扱います。

Day 2–3の完了条件に出てくる下り坂(downhill) も原作の比喩です。原作のヒルチャート(hill chart)は作業を丘に見立て、アプローチをまだ探っている上り坂(uphill)と、分かるべきことは分かり実行だけが残った下り坂とで進行状態を表します(第13章: 進捗を示す)。ヒルチャート自体は7章で改めて扱います。

Day 1がやることは新しい発明ではありません。つながっていない断片を積み上げず、意味のある一塊をまず統合してみよという原作の助言 (第11章: 一つのピースを仕上げる) を、一日単位のルールとして釘を刺したものです。Day 4にコーディングを禁じるのも、検証が余った時間にやることではなく割り当てられた段階であることを、カレンダーで強制するためです。

クールダウンの比率は、原作の3対1から4対1へ移りました。クールダウンでやること自体が減ったからではなく、その仕事を実行する側もエージェントなので一日あれば十分だからです。

サイクルの長さはキャリブレーションの対象

一週間はデフォルト値であって下限ではありません。シェイピングと合意にリーダーシップの承認が必要なエンタープライズには8日ビルドに2日クールダウンという上方バリエーションが、検証資産が成熟したチームやソロには2日ビルドに1日クールダウンという下方バリエーションがあります。

長さを決める変数は三つです。第一は検証資産の成熟度で、エージェントの相互レビューと自動評価が検証を吸収するほど、人が守るゲートは短くなります。第二は情報の到着速度です。再ベッティングの価値は新しい情報が到着する速度に縛られているので、情報より頻繁な再ベッティングは、同じ情報で会議だけを増やします。第三は理解の帯域幅です。人が成果物を理解してこそ還流が実質を持ちますが、理解とキュレーションの速度はコンピュートで圧縮できません。

そのため下限を数字で固定せず、手続きで管理します。クールダウンのたびにシェイピングに使った時間とコンテキストブレーカーの発動率を記録しておき、ブレーカーが二サイクル連続で頻発するならシェイピングの時間が足りないという信号なので、一段長いバリエーションへ延ばします。逆に、クールダウンが閑散とし続け、検証ゲートを一度で通過する状態が保たれるなら、一段短いバリエーションへ縮めます。

クールダウンはより重要になる

原作でクールダウンは、バグを潰し先送りにした仕事を片づける整備期間でした。VDLCのクールダウンには、その場所に一つの儀式が入ります。再生成検証です。

今回のサイクルのコンテキスト文書だけを入力として与え、エージェントに成果物をもう一度作らせたうえで、その再生成物が検証ゲートを通過するかを確かめます。通過すれば、今回のサイクルは負債なく閉じられます。失敗すれば、第3章で名前を付けたコンテキスト負債、つまりコードにだけあって意図の文書にはない決定が残っているという意味なので、差を分析して隠れた意図を文書へ逆移転します。逆移転が終わるまで、次のサイクルのベッティングは禁止されます。

第2章で三つ目のボトルネックに挙げた複雑度負債が返済される場所が、ここです。返済の時点を「いつか余裕のあるとき」に置かず、次のベッティングの前提条件として掛けておいたことが、この仕掛けの核心です。

そしてクールダウンは、依然として人の回復期間でもあります。序文と第2章で二度引用したDHHの警告 — エージェントでリリースし続けるドーパミンループがバーンアウトのリスクを高めるという話 — が、この箇所で運用ルールに翻訳されます。同じインタビューで彼は、半年前まではAIでコードを書いていなかったが今は手でコードをほとんど書かない、と語りました。警告した当人でさえ、そのループの中に入っているということです。個人の節制で防げる問題でないのなら、止まる日は日程に打ち込まれていなければなりません。

一週間に一度あらためてベッティングするのなら、そのベッティングテーブルに上がってくるものは何で、何を基準に選ぶことになるのでしょうか。実装が安くなったという事実は、サイクルの長さよりもベットの性格を大きく変えます。