検証と完了の基準
原作が定めた完了の定義は一文です。完了とは、デプロイされたという意味です。サイクルが終わるときチームは自分の作業をデプロイし、小さなプロジェクトを複数抱えたチームなら、サイクルの中で準備でき次第出していきます (第10章: 責任を引き渡す)。次の人の待ち行列へ渡すことは完了ではない、という宣言でした。
この定義は、人がコードを自分で書き自分で動かしてみたという前提の上でのみ十分でした。生成が終わってテストも緑なのに、そのコードを誰も読んでいないとしたら、私たちはこれを完了と呼べるでしょうか。
ヒルチャート → 委任可能性マップ
原作には、進行状況を見せてくれる道具が一つあります。ヒルチャート(hill chart)です。あらゆる作業には二つの局面があります。どのアプローチを取るかを見つけ出す上り坂(uphill)、そして関わる仕事がすべて目に入って実行だけが残った下り坂(downhill)です。各スコープが丘のどのあたりにいるかを点で打っておけば、進捗を尋ねなくても状況が見えます (第13章: 進捗を示す)。
VDLCは同じチャートの用途を変えます。進捗報告の道具だったものが、人間とエージェントのあいだの業務分配の道具になります。上り坂にあるスコープは未知が残っているという意味であり、未知が残っているなら人の判断が必要なので、エージェントに完全には委任しません。下り坂にあるスコープは意図が確定したという意味であり、確定しているなら実行はまるごと委任できます (VDLC 週次サイクル)。
そのため、点を下り坂へ動かす行為の重みも変わります。原作でそれは「これでどうやるか分かった」という報告でしたが、VDLCではそれは「このスコープの意図がコンテキスト文書に完結的に記述された」という宣言です。頭の中だけで解けたものは下り坂ではありません。書かれていない理解はエージェントに伝わらないので、ここでの判定基準は担当者の確信ではなく文書です。
QAは端から検証ゲートへ
原作でQAは、端を担う役割でした。メインフローが動くかは作った人がすでに確かめているので、QAは例外的な状況を見つけることに集中し、そこから出た問題は基本的に選択項目(nice-to-have)として入ってきたうえで、深刻なものだけが必須項目(must-have)へ上がります (第14章: いつ止めるかを決める)。
この分業の全体が、一つの前提に乗っています。人間の実装者がメインフローをすでに手で通してみた、という前提です。エージェントが生成したコードにはその前提がないので、誰も一度も踏んでいないメインフローが存在しうるのです。そのためVDLCにおいて検証は、余った時間にやる補助的な活動ではなく明示的な段階へ格上げされ、第5章で見たDay 4の一日全体がここに割り当てられます。この日は新規コーディングが禁止され、検証中に見つかった欠陥の修正だけが許されます。
ゲートで確認する項目は五つです。
- ピッチに書いておいた問題が実際に解消されたか(ベースライン(baseline)との比較)
- 除外項目の違反がないか
- メインフローを人が直接検証したか
- エッジケースの自動テストが通るか
- Done = Deployed、つまり実環境にデプロイされたか
第2章で最初のボトルネックに挙げたものが、プロセスのレベルで吸収される場所が、ここです。AI導入度の高いチームでPRレビュー時間が91%増えたという数値は、検証を日程に居場所のない活動として置いたとき、その負担がどこへ押し出されるのかを示しています。一日を割り当てるということは、その超過分を夜の時間ではなくサイクルの中で払わせるという意味です。
スコープハンマリング → コンテキストハンマリング
固定された期間の中で終えるには、残った仕事を削らなければなりません。原作はこの作業を「切り落とす」より強い言葉で呼びます。スコープハンマリング(scope hammering)です。これが本当に必須項目なのかを繰り返し問い直し、違うと判断されたものにチルダを付けて選択項目へ下ろす仕事です (第14章: いつ止めるかを決める)。
問い直す行為はそのまま残りますが、削る対象が変わります。コードを消してみたところで、同じ意図の文書が残っている限り、次の生成でそれが戻ってくるからです。そのためVDLCのハンマリングは、コードではなくコンテキスト文書を叩きます。ユースケースを一つ切り落とすと決めたなら、実装を削除するのではなく、意図の文書からその項目を下ろして生成し直します。コンテキストハンマリングという名前が付いた理由です。
完了の定義にも条件が一つ付きます。Done = Deployedに再生成可能(regenerable)が加わります。コンテキスト文書だけで同じものを作り直せてこそ本当の完了だ、ということです。第5章で見たクールダウンの再生成検証が、この条件を毎週実測します。デプロイはされたのに再生成が失敗するなら、そのサイクルは完了したのではなく、コンテキスト負債を残したのです。
いつ止めるか
それでも、時間より仕事のほうが多いという事実は変わりません。原作が出した答えは、比較の向きを変えることでした。理想の完成形を見上げて比べるのではなく、ベースライン — この機能がない今日、顧客が使っているもどかしい回避策 — と並べて見下ろせ、というものです。今作ったものがそれより良ければ、リリースできます。
この基準は、実装がどれだけ安いかとは何の関係もありません。顧客が今より良くなるかだけを問うからです。ですから原作の答えのうちこの箇所は手を入れるところがなく、変わったのは誘惑の大きさだけです。以前は、もっと作ろうという提案に数週間という値札が付いていて自然にふるい落とされましたが、今は一時間で済むので、あえて止まる理由を見つけるのが難しくなりました。第2章で引用したJason Friedの言葉が、ここでまた必要になります。速度も、コミットの数も、投入した人数も、プロダクトを本質的により良くはしない、という話です。もっと作れるということは、もっと作るべき理由ではありません。
結び
実装コストは実際に崩れましたが、あらゆる場所で均一に崩れたわけではなく、その場所に検証と注意力と複雑度という新しい希少資源が入り込みました(第1部)。アペタイトとシェイピングはそのため、廃棄されるどころかいっそう重くなり、ただしアペタイトは時間ひとつではなく人間の注意力とコンピュートという二つの通貨へ、シェイピングは文書ではなくプロトタイプラウンドを内蔵した活動へと中身を変えました(第2部)。サイクルとベッティングと完了判定は、4日ビルドに1日クールダウンという週次の心拍へ組み直され、その中でサーキットブレーカーは差し戻し装置へ、ヒルチャートは委任マップへ、QAはゲートへと居場所を移しました(第3部)。
ここまでが、境界線を引く作業でした。次の一歩は、この線の上に建てられた運用ルールを実際の一週間に載せてみることであり、ルールの全体の定義は VDLC 週次サイクル の文書にあります。月曜の朝にベッティングし、木曜にゲートを立て、金曜に再生成をさせてみることで、十分な始まりになります。
原作の 結論 は、方法論をまるごと導入しなくても、言葉と概念のいくつかは持っていって使ってもらえたら、という言葉で終わります。このガイドも同じ場所で終えます。一つだけ付け加えるなら、バイブコーディングという名前を付けておきながら1年で下ろしたKarpathyと、Shape Upのサイクルは終わったと先に言ったDHHが、正反対の方向から出発して同じ結論に行き着いたという事実です。作ることは委ねられても、品質の基準は人が握っていなければならないということ。Shape Upが最初から言っていた話でもあります。