ベッティングテーブルの再構築
原作では、ピッチを書き終えてもその文書はバックログ(backlog)へは行きません。サイクルが始まる前にベッティングテーブル(betting table)が開かれ、その場に上がってくるのは、前のサイクルのあいだに出たピッチと、誰かがわざわざ掘り起こしてもう一度持ってきたピッチだけです。ここで次のサイクルに何を賭けるかを決める決定がベット(bet)であり、賭けないことにしたピッチは別途追跡せず手放します (第7章: バックログではなくベット, 第8章: ベッティングテーブル)。
この会議が6週間に一度ではなく毎週開かれるなら、テーブルの上の決定はどう変わるでしょうか。
バックログ無用論はより強くなる
原作がバックログを拒んだ理由は二つでした。手をつける時間の取れない項目が積み上がるほど、実際には遅れていないのに常に遅れている気分になるということ、そして古びたアイデアを検討し手入れするのに使う時間が、今まさに時宜を得た仕事を押し進めるのを妨げるということです。
実装が安くなると、この論拠は弱まるのではなく強まります。安くなったのは作るコストだけではありません。アイデアを書き出すコストも一緒に安くなり、エージェントに尋ねれば、もっともらしい候補機能のリストが数秒で返ってきます。ところが、そのリストを読んで分類し、まだ有効かを判断する仕事は、依然として人の注意力から出ます。第2章で二つ目のボトルネックに挙げた資源が、ここに請求されます。リストの生産速度だけが数十倍になり消化速度がそのままなら、バックログは以前よりはるかに速く膨らみ、はるかに速く腐ります。
だから原作の代案がそのまま有効です。重要なアイデアは戻ってきます。本当に重要なものなら誰かが文脈とともに再び持ち出しますし、忘れられたのなら、そもそもその程度のものだったのです。
ベットはオプションの買いになる
原作のベットは高くつく決定でした。一つのチームを6週間ひとつのプロジェクトに縛るという意味であり、その6週間は他の何にも使えませんでした。取り消せないので慎重でなければならず、慎重であるためには、よくシェイピングされた候補がいくつかだけ上がってくる必要がありました。
実装が安くなると、この計算が変わります。ベットはコミットメントというより、オプションの買いに近づきます。VDLCはこの変化を並列ベッティングとして定義します。不確実性の高いピッチには、同じピッチに対して異なるアプローチを2〜3本並べて賭け、サイクルの中で勝者を選びます (VDLC 週次サイクル)。
ここに条件が一つ付きます。勝者選定の基準は、Day 0のベッティング時点で測定可能な形にして文書へ書いておきます。応答レイテンシのp95、コード再生成の成功率、特定のエッジケースを通過するかどうかのように、後から誰が見ても同じ答えの出る基準でなければなりません。事後の好みによる判定は禁止です。結果をすべて見た後に基準を選べば、並列ベッティングは比較ではなく合理化になってしまうからです。
並列で賭けられる本数の上限を決める通貨は、コンピュートではありません。コンピュートだけで言えば十本でも回せます。上限は人間の注意力から出ます。文書に書いておいた基準で人が実際に比較して判定できる本数が天井で、デフォルト値は2〜3本です。コンピュートはその中で、ピッチのアペタイト総額を超えない範囲で自由に分けて使います。
ベッティングテーブルの性格も一緒に変わります。原作でこの会議は、めったに開かれない代わりに重みの乗った場でしたが、週単位のサイクルでは毎週月曜の朝の軽い儀式になります。一度の決定に懸かっているものが6週間ではなく四日だからです。
ソロビルダーのベット
一人で作る人には、ベッティングテーブルがありません。しかしベットはあります。説得すべきステークホルダーがいないだけで、何に今週を賭けるかは依然として決めなければなりません。
むしろソロのほうが危険です。組織にはチーム数という物理的な上限があるので、同時に回せるプロジェクトはおのずと制限されますが、並列エージェントを使う個人にはそうした上限がありません。ソロビルダーの希少資源は自分の注意力ひとつだけなのに、その資源だけが上限なく超過引き出しされる構造です。
ですから、同時に賭けるベットの数を自分で決めておくことが、ソロ版のベッティングテーブルです。一つ新しく開くには一つ閉じるか手放す、というルールを自分に課すことです。誰も代わりに問うてはくれないので、アペタイトの宣言は組織におけるよりもいっそう切実です。サイクルの長さの側では、第5章で見た下方バリエーション、すなわち2日ビルドに1日クールダウンが、ソロと小規模チームのためのデフォルト値としてすでに定義されています。
サーキットブレーカー → コンテキストブレーカー
原作には、プロジェクトが間延びするのを防ぐ仕掛けが一つあります。サーキットブレーカー(circuit breaker)です。一つのサイクルの中でリリースできなかったプロジェクトは自動的には延長されず、基本的には中止となり、再びやるには次のベッティングテーブルで新たに勝たなければなりません (第8章: ベッティングテーブルのサーキットブレーカーの節)。
原作も同じ診断をすでに下していました。6週間で終わらなかったのならシェイピングを誤ったということなので、サーキットブレーカーは次のシェイピングトラックで組み直すよう押し戻します。ただし、そのあいだのデフォルトの動作は依然として中止でした。
VDLCがひっくり返すのはこの診断ではなく、デフォルトの動作と発動のタイミングです。中止ではなく、シェイピングトラックへの即時差し戻しをデフォルト値とします。作り直すコストはすでに安く、高くつくのは、不明確な意図を抱えたまま同じ場所を堂々巡りする人の時間だからです。
発動はサイクルの終わりを待ちません。次の三つの条件のうち一つでも満たされれば、その場で発動します。
- Day 1が終わった時点で、デプロイ可能な垂直スライスが一つもない。
- コンピュート予算を使い切ったのに、必須項目(must-have)として置いたスコープが上り坂に残っている。
- エージェントが同じスコープで相互に矛盾するアプローチを3回以上繰り返す。
ここでの必須項目は、スコープを必須(must-have)とあれば良いもの(nice-to-have)に分けておき、必須さえ終わればリリースするという原作の区分をそのまま持ち込んだものです (第14章: いつ止めるかを決める)。二つ目の条件は、どちらか一方ではなく両者の結合です。予算を使い切っただけでは発動せず、予算に余裕があるのに上り坂が残っているのも正常です。使えるものを使い切ってもなお必須項目が上り坂にある、という組み合わせが信号です。
発動したときに出さなければならない成果物は、失敗報告書ではなく復帰メモです。どの意図が不明確だったのか、どのラビットホール(rabbit hole)がピッチに申告されないまま残っていたのかを書きます。このメモがシェイピングトラックの入力となって、次のピッチを直します。ブレーカーが罰ではなく学習装置になる地点です。
ブレーカーに掛からずサイクルの最後まで生き残ったベットは、何をもって清算されるのでしょうか。原作ならリリースが答えでした。しかし、人が一行も読んでいないコードがデプロイされる時代に、完了の基準はもう一項目を要求します。