AI時代のプロジェクト日程管理: 見積もり・ベロシティ・スプリント計画を瓦礫から立て直す

プロローグ — 見積もりが壊れたのは推定が下手になったからではない

2024年のあるスプリントレトロ。あるチームのvelocityが突然2倍になった。誰も長く働いていない。CursorとClaude Codeがチームに入っただけだ。次のスプリント、velocityはまた半分に落ちた。難しいチケットだけが残ったからだ。

このチームのPMはレトロでこう言った。「うちのvelocityグラフはもう何も予測しない」。

正しい。だが原因を読み違えてはいけない。推定が下手になったのではない。推定の単位だった「人間の労力」という量が、もう安定しなくなったのだ。

story pointは一度も時間ではなかった。それは労力・複雑度・不確実性の束であり、その束がチーム内で比較的一貫していたから機能した。「3ポイント」は全員にとっておおよそ同じ重さだった。AIエージェントがループに入って、この一貫性が砕けた。同じ3ポイントが、ある日は4秒で下書きが出て、ある日は依然として2日かかる。平均を取っても意味がない。分布そのものが2つの山に割れたからだ。

この記事は、その割れた分布の上で日程を立て直す方法を扱う。対象読者はtech lead、EM、そしてsenior ICだ。抽象的な「AIが変えた未来」の話ではなく、次のスプリント計画ミーティングですぐ使えるものを整理する。

扱う内容:

1. story pointが意味を失った正確なメカニズム
2. 新しいボトルネックは実装ではなくreview・integration
3. AI支援作業の見積もり — pointではなくrange、spike優先
4. velocityは今やバイモーダル
5. エージェントが一晩で5チケットを終わらせるときのスプリント計画
6. AI支援作業 vs 人間作業のトラッキング
7. エージェント成果物の「90%完了」の罠
8. reviewが制約のときのcapacity計画
9. 依然として意味のあるメトリクス — lead time、escape rate、review latency
10. エピローグ — チェックリストとアンチパターン

第1章 · story pointが意味を失った正確なメカニズム

story pointを責める前に、なぜそれが元々機能していたかを押さえよう。story pointは3つの仮定の上に立っていた。

3つの仮定がすべて同時に揺れた。

労力の一貫性が壊れた。 CRUDエンドポイントの追加は以前は2ポイントだった。今はエージェントがschemaを見て5分で下書きを作る。だが分散ロック競合をデバッグする5ポイントは依然として5ポイントだ。AIがそこではほとんど役に立たないからだ。同じスケールの中に5分の作業と2日の作業が同じ数字を付けている。

労力が時間のプロキシであることをやめた。 実装時間が0に収束しても、カレンダー時間は縮まない。エージェントが4秒で書いたコードも、人間がreviewし、integrationし、QAするには同じ時間がかかる。労力を合算して時間を予測していた式の分母が消えた。

複雑度と実装コストが分離した。 これが最も根本的だ。以前は「難しい問題」と「コードを大量に書く問題」が強く相関していた。今は違う。仕様が明確でパターンがありふれた作業は — 複雑でも単純でも — エージェントが速く処理する。逆に仕様が曖昧、あるいはシステムの文脈が深く絡んだ作業は — コード量が少なくても — 依然として人間の時間を丸ごと食う。

結論: story pointを捨てる必要はない。だが何を見積もるかを再定義しなければならない。生成時間ではなく — それはほぼ0だ — 仕様コストと検証コストを見積もる。

旧見積もり = f(実装労力)
新見積もり = f(仕様の明確度) + f(review・integration・QA労力)

次章で、この2番目の項がなぜ新しいボトルネックなのかを見る。

第2章 · 新しいボトルネックは実装ではなくreview・integration

制約理論 (Theory of Constraints) の一行要約: システムのスループットは最も遅い段階が決める。他の段階をいくら速くしても無駄だ。

AI以前、ソフトウェアデリバリの段階別の時間配分はおおよそこうだった。

[設計 15%] → [実装 50%] → [review 10%] → [integration・QA 20%] → [deploy 5%]
                 ↑ ボトルネック

実装が最大の塊で、だから我々は実装を速くすることに全ツールを投資した。IDE、autocomplete、boilerplateジェネレータ。エージェントはその流れの頂点だ — 実装をほぼ無料にした。

では実装が無料になるとどうなるか。ボトルネックが移る。

[設計 25%] → [実装 5%] → [review 35%] → [integration・QA 30%] → [deploy 5%]
                             ↑ 新しいボトルネック

reviewが新しいボトルネックだ。理由は単純だ。reviewは本質的に人間の認知作業であり、その量は検査するコードの量に比例するが、エージェントはコードをより多く、より速く作る。さらにエージェントのコードは人間のコードとreview負担が違う。

reviewerは今や「コードを読む」のではなく「コードが正しいことを証明する」必要がある。作成者の意図という近道がないからだ。これはより遅く、より疲れ、より見落としやすい。

実践的な含意その1。 チームにエージェントを導入してreview capacityをそのままにすると、スループットはほぼそのままだ。実装が速くなった分、PRがreviewキューに積み上がるだけだ。キューは長くなり、lead timeはむしろ増えうる。速くなったのは「PR生成速度」であって「デリバリ速度」ではない。

実践的な含意その2。 integration・QAも一緒に膨れ上がる。PRが増えればmerge conflictが増え、integration環境で壊れる組み合わせが増える。エージェントは自分のPRが他人の未mergeのPRとどう衝突するか知らない。

そこから次章の見積もり原則が出る: エージェントが生成する段階ではなく、人間が検証する段階を見積もれ。

第3章 · AI支援作業の見積もり — pointではなくrange、spike優先

AI支援作業が見積もりにくい本当の理由は、結果の分散が大きいことだ。同じチケットが30分で終わることも、2日かかることもある。その分岐点は作業を始める前にはよく見えない。

分散の大きい量を単一の数字で推定すると、ほぼ必ず外れる。だから2つの原則。

原則1: pointではなくrangeで見積もる

単一のpointの代わりに楽観-悲観のrangeを出す。核心は、rangeの幅そのものが情報だということだ。

幅が広いのは「より大きな作業」という意味ではなく、**「我々はこの作業をまだ理解していない」**という意味だ。広いrangeを見たスプリント計画者は、数字を大きくするのではなく、不確実性を減らす行動を取るべきだ。

原則2: spike優先 (spike-first)

幅が広いチケットはすぐスプリントに入れない。まずtimeboxされたspikeを入れる。

広い見積もり (1〜4日) を発見
   │
   ▼
timeboxされたspike (2〜4時間)
   ├─ エージェントにprototypeを作らせてみる
   ├─ 仕様の空白を見つける
   └─ integrationポイントを確認する
   │
   ▼
再見積もり → たいてい狭いrangeに収束する

AI時代にspikeは以前よりずっと安くなった。エージェントに「とりあえずこれ作ってみて」と言えば30分で動くprototypeが出る。そのprototypeは捨てるとしても、それを作る過程で仕様の曖昧さとintegrationリスクが現れる。これがspikeの本当の価値だ — コードではなく学習。

spikeの後に再見積もりすると、たいていrangeは狭くなる。狭くならなければ? それ自体が強力なシグナルだ。この作業は本質的に不確実なので、スプリントのコミットメントから外すか、より小さく分割すべきだ。

見積もりワークフローの整理

1. 下書き見積もりをrangeで出す (楽観 〜 悲観)
2. 幅が狭ければ → そのままスプリント候補
3. 幅が広ければ → spikeを先にスプリントに入れる
4. spike後に再見積もり → 狭くなれば候補、ならなければ分割
5. スプリントのコミットメントは「狭いrange」のチケットだけで埋める

このワークフローの核心メッセージ: 不確実なものを確実なふりで推定せず、不確実性を減らす作業を先にやれ。

第4章 · velocityは今やバイモーダル

velocityグラフが無意味になった理由を統計で見ると明確だ。作業時間の分布が単峰 (unimodal) から双峰 (bimodal) へ変わった。

AI以前、チームの作業時間の分布はおおよそ正規分布に近かった。平均の周りにほとんどが集まり、平均と中央値が近かった。平均を取ることに意味があった。

AI以前 — 単峰分布
頻度
 │        ▁▃▅█▅▃▁
 │     ▁▃█████████▃▁
 └──────────────────────── 作業所要時間
         平均 ≈ 中央値 (意味がある)

AI以後、分布が2つの山に割れた。

AI以後 — 双峰分布
頻度
 │  █                      █
 │  █▆                    ▆█
 │  ██▃                  ▃██
 └──────────────────────────── 作業所要時間
   山A                   山B
   (些細な作業、          (難しい作業、
    エージェントが崩壊させた) ほぼ変わらない)

        ↑ この間の「平均」は誰も住んでいない場所

• 山A — 崩壊した作業。 CRUD、boilerplate、よく知られたパターンの適用、明確なリファクタリング。エージェントが時間をほぼ0にした。
• 山B — 変わらない作業。 曖昧な仕様、深いシステム文脈、新しい設計判断、厄介なデバッグ。エージェントがほとんど役に立たない。

平均は2つの山の間の谷を指す。そこには実際の作業が1つもない。 「今スプリントの平均作業は1.5日」のような文は、平均的な家族構成員が2.3人だと言うのと同じくらい空虚だ。

では何をトラッキングするか

平均の代わりに2つの山を別々にトラッキングする。

特に山Bのスループットが本当のシグナルだ。山Aはエージェントが処理するのでほぼ無制限に増やせる — reviewさえ追いつけば。だが山Bは人間の深い思考が必要で、それがチームの実際の上限だ。四半期計画は山Bのスループットで立てるべきだ。

バイモーダルの認識がレトロの会話を変える

レトロで「velocityが落ちた」という話が出たらこう聞き返す。

「山Aが落ちたのか、山Bが落ちたのか?」

• 山Aが落ちた → reviewキューが詰まったか、エージェント活用が減った。ツール・プロセスの問題。
• 山Bが落ちた → 本当に難しい仕事をしているか、seniorが詰まっている。人・集中の問題。

同じ「velocity低下」がまったく違う2つの処方を呼ぶ。平均1つではこの区別は不可能だ。

第5章 · エージェントが一晩で5チケットを終わらせるときのスプリント計画

ここで現実的なシナリオ。金曜の夕方、senior ICがエージェントにバックログ上位5チケットを任せて退社する。月曜の朝、5つのPRが上がっている。

スプリント計画の前提が揺れる。「2週間でチームがNポイントをやる」というコミットメントの意味は何か、PR生成が一晩で終わるなら?

よくある誤読: スプリントは死んだ

違う。スプリントは生きている。変わったのはスプリントが何をコミットする単位かだ。

• 旧スプリント:「これだけのコードを書く」
• 新スプリント:「これだけのコードを検証し、integrationし、deploy可能な状態にする」

月曜の朝の5つのPRは「終わった仕事」ではない。それはreview・integrationキューに入った入力だ。スプリントのコミットメントは、そのキューを空にする能力へのコミットメントだ。

スプリント計画を2つのトラックに分ける

トラック1 — 生成トラック (エージェント主導)
  ├─ バックログ上位チケットをエージェントに委譲
  ├─ 速く並列的、ほぼ無制限
  └─ 出力: review待ちのPR

トラック2 — 検証トラック (人間主導) ← スプリントのコミットメントはここ
  ├─ review、integration、QA、deploy
  ├─ 人間のcapacityに厳密に縛られる
  └─ 出力: deployされた価値

スプリント計画ミーティングで問うべき質問が変わる。

生成トラックを意図的に制限する

直感に反するが重要だ: 生成トラックに手綱をかけなければならない。

エージェントが一晩で5つ、翌日5つ、また5つ作ると、reviewキューは果てしなく長くなる。これは進捗ではなく過剰在庫だ。未mergeのPRは資産ではなく負債だ — merge conflictのリスクを高め、コードベースに対する仮定が古くなるほどrebaseが難しくなる。

ルール: 検証トラックが消化できる分だけ生成トラックを回す。 reviewキューに一定数以上のPRが積み上がったら、エージェントに新しい作業を委譲しない。KanbanのWIP制限をreviewキューに適用するのだ。

reviewキューのWIP制限 = 3
┌─────────────────────────────────┐
│ review待ち: [PR][PR][PR]  ← 満杯 │
│ → エージェントへの新規委譲を停止  │
│ → reviewが1つ抜けたら再び委譲     │
└─────────────────────────────────┘

これが第5章の核心: スプリントは生きているが、コミットメントの単位が生成から検証へ移り、生成は検証capacityに合わせて意図的に調節しなければならない。

第6章 · AI支援作業 vs 人間作業のトラッキング

「うちのチームでAIがどれだけ貢献しているか」という質問は、必ず経営陣から来る。答え方がチーム文化を作るか壊すかを決める。

トラッキングすべきでないもの

まず罠。次のメトリクスは測るな。測った瞬間にgameされる。

これらのメトリクスの共通の問題: AIを人間と競争させるか、ツールの使用そのものを目標にする。 AIはキーボードやコンパイラのようなツールだ。「今四半期のコンパイラ使用率」をトラッキングしないように、「AI活用率」もそれ自体ではトラッキングする価値がない。

トラッキングすべきもの

代わりに作業の性格をトラッキングする。個人ではなく作業タイプを。

チケット分類 (個人評価ではなく、バックログ理解のため)

  タイプA: エージェント主導、人間が検証
    → 山A。速い処理。reviewが制約。

  タイプB: 人間主導、エージェントが補助
    → 山B。深い思考。人間の時間が制約。

  タイプC: 純粋な人間作業 (設計、デバッグ、交渉)
    → エージェント不適。seniorの時間が制約。

この分類は個人の成績表ではない。 バックログの構成を理解し、capacityを計画するためのものだ。同じ人があるチケットはタイプAで、あるチケットはタイプCでやる。分類の対象は人間ではなく仕事だ。

役に立つたった1つの比率

どうしても「AI効果」の数字が必要なら、これ1つだけを見る。

タイプAのスループット増加分
─────────────────────────  = エージェントの実際のレバレッジ
タイプAにかかったreviewコスト

分子が分母より十分大きければエージェントは純利益だ。分母が分子に追いつけば — reviewコストが生成の利益を食ってしまえば — ツールではなくプロセスを直すべきだというシグナルだ。

報告するときのフレーミング

経営陣にはこう報告する。

「エージェントでタイプA作業のlead timeがX%減りました。その結果ボトルネックがreviewへ移り、次の四半期にreview capacityに投資すれば、その利益をスループットに転換できます。」

このフレーミングは正直で (「行数が増えた」のような虚数がない)、行動可能だ (次の投資先を指す)。「AIがコードの40%を書く」のような文は印象的だが、何の決定もできなくする。

第7章 · エージェント成果物の「90%完了」の罠

ソフトウェア見積もりの古いジョーク:「90%完了した、残りの10%にまた90%の時間がかかる」。エージェントはこの罠をより深く、よりもっともらしくする。

なぜエージェントの出力は90%に見えるか

エージェントが作ったPRを初めて開くと印象的だ。コードがコンパイルされる。テストがある。通る。変数名がきれい。構造が合理的。完成したように見える。

だが「見える」が核心の言葉だ。エージェントはもっともらしく見えることに最適化されている。表面的な完成度と実際の完成度が、人間のコードより大きく開く。

人間が書いたコード
  表面完成度 ──────────●  70%
  実際完成度 ─────────●   65%
  (作成者が弱い所を知っている。ギャップが小さい。)

エージェントが書いたコード
  表面完成度 ───────────────────●  95%
  実際完成度 ──────────●            60%
  (ギャップが大きい。そしてギャップがどこにあるか見えない。)

表面と実際の間のその35%が「残りの10%」の正体だ。そしてこのギャップはたいてい次に隠れている。

特に最後から2番目が危険だ。エージェントが作ったテストはしばしば自分が書いたコードがやることをそのまま断言する。バグがあってもテストはそのバグを「正解」として固定する。テストが通ることは正確性を保証しない。

罠を避ける見積もりルール

ルール1:「PRが上がった」は0%完了だ。 見積もりの終点を「PR生成」ではなく「deployされて観測された」に置く。エージェントがPRを上げた瞬間は検証作業の起点であって終点ではない。

ルール2: 検証を別チケット・別見積もりで。 生成と検証を1つのチケットに束ねると検証が常に過小評価される。大きなエージェント成果物は「実装」チケットと「検証・integration」チケットに分け、後者を正直に見積もる。

ルール3: エージェントPRには「逆方向review」を。 コードを上から下へ読まず、上の表の5つの隠れる場所をチェックリストとして先に打つ。「エッジケースは? integrationの仮定は? テストが意図を検証するか?」表面的な完成度に騙されないために、意図的にギャップを探さなければならない。

ルール4: 最後の10%にbufferではなくtrackを。 bufferは「もしものために時間を追加」だ。trackは「この作業は必ずあり、別に計画する」だ。エージェント成果物の最後の10%はもしもではなく常にだ。bufferで隠さず、検証トラックの一等市民として計画する。

第8章 · reviewが制約のときのcapacity計画

第2章でボトルネックがreviewへ移ったと述べた。第8章はその事実をcapacity計画に反映する方法だ。

旧capacity計画 vs 新capacity計画

旧方式
  チームcapacity = Σ (個人別の実装可能時間)
  計画 = このcapacityに合わせて実装作業を埋める

新方式
  チームcapacity = MIN(生成capacity, review capacity, integration capacity)
  計画 = 最も小さい項 (たいていreview) に合わせてコミットする

制約理論をそのまま適用したものだ。生成capacityはエージェントのおかげで事実上ほぼ無限だ。だからそれはもう計画の基準ではない。最も小さい項 — ほぼ常にreview — がチームの本当のスループットだ。

review capacityを実際に計算する

review capacityは抽象的ではない。測定可能だ。

review capacity (PR/週)
  = reviewerの数
  × 1人あたり週間review可能時間
  ÷ PR1つあたりの平均review時間

例:
  reviewer 4人
  × 1人あたり週6時間 (reviewに使える現実的な時間)
  ÷ PR1つあたり1.5時間 (エージェントPRはより長くかかる)
  = 16 PR/週

この16という数字がスプリントのコミットメントの上限だ。エージェントが週に50個のPRを作れても、チームがコミットできるのは16個分だ。残りの34個を作るのは進捗ではなくキューの滞積だ。

review capacityを増やすレバー

reviewが制約なら、改善はreview capacityを増やすことから来る。他の所を改善すれば無駄だ。

最も効果が大きいのはたいていPRを小さくすることだ。review時間はPRサイズに線形ではなく超線形に増える — 大きなPRは人間が頭の中に全部入れられないので、より遅くより不正確だ。エージェントに「この機能全体を1つのPRで」ではなく「この機能を5つの小さいPRに分けて」と委譲する規律が、capacityを最も大きく増やす。

capacity計画ミーティングの新しいアジェンダ

スプリントcapacity計画 — 新しいチェックリスト
  □ 今スプリントのreview capacityは何PRか? (上の式で計算)
  □ integration・QA capacityは? (merge conflict・環境時間を含む)
  □ 2つのうち小さい値がスプリントのコミットメントの上限
  □ 生成トラックはその上限に合わせてWIP制限を設定
  □ senior review時間が山Bに十分残るか?

最後の項目が微妙だが重要だ。seniorが山AのエージェントPRをreviewするのに時間を全部使うと、山Bの本当に難しい仕事をする人がいなくなる。review capacityを計画するとき、seniorの深い作業時間を先に取り分けなければならない。

第9章 · 依然として意味のあるメトリクス — lead time、escape rate、review latency

story pointとvelocityが揺れたからといって測定を諦めることはできない。幸い、揺れないメトリクスがある。共通点: これらは「労力」を測定せず「フロー」と「結果」を測定する。だからAIが労力を変えても意味が保たれる。

メトリクス1: lead time

作業が始まった瞬間から、deployされてユーザーに届くまでのカレンダー時間。

なぜ生き残るか: lead timeは生成時間ではなく全体のフローを見る。エージェントが実装を0にしても、lead timeが縮まなければボトルネックが別の所にあるという意味だ。lead timeはそのボトルネックを隠さない。

lead timeの分解 (ボトルネック診断用)
  [待機] → [生成] → [review待ち] → [review] → [integration] → [deploy]
                        ↑
            ここが長くなったらreviewが制約

lead timeを段階別に分けると、どの段階が膨れたかすぐ見える。AI時代にはほぼ常に「review待ち」区間が犯人だ。

メトリクス2: escape rate

productionまで抜け出した欠陥の比率。review・QAを通過したがユーザーが発見したバグ。

なぜ重要になったか: エージェントコードの「90%完了の罠」(第7章) が正確にescape rateとして現れる。表面的に完成して見えるPRがreviewを通過しやすく、隠れたギャップがproductionで爆発する。escape rateが上がれば、検証トラックが生成速度に追いついていないという直接の証拠だ。

escape rateが上がっているのにvelocity (生成速度) も上がっているなら、それは良いことではない。検証されていないコードを速く出しているだけだ。

メトリクス3: review latency

PRが上がった時刻からreviewが始まる時刻までの時間。reviewにかかる時間ではなく、reviewを待つ時間。

なぜ核心メトリクスか: review latencyはreviewキューの長さを直接示す。第2章・第8章で見た新しいボトルネックの体温計だ。

review latencyが教えてくれること
  latency ≈ 0      → review capacityに余裕。生成トラックをもっと回してよい
  latency増加傾向   → キュー滞積が開始。生成トラックの調節が必要
  latency急増      → ボトルネックが深刻。即座にWIP制限を強化

review latencyは先行指標だ。lead timeは事後に「遅かった」と教えるが、review latencyは「今詰まっている」をリアルタイムで教える。

メトリクス4: 山Bのスループット (第4章の再登場)

難しい作業 (タイプB・C) のスプリントあたりの完了数。第4章で強調したそのメトリクス。

なぜ四半期計画の基準か: 山Aはエージェントが処理するので伸縮的だ。だが山Bは人間の深い思考が上限で、それがチームが実際に作れる価値の限界だ。ロードマップのコミットメントは山Aの速い処理に酔わず、山Bのスループットに基づくべきだ。

メトリクスの総合

この4つの共通点を再び強調する。1つも「コードをどれだけ速く書いたか」を測定しない。 すべてフロー・結果・能力を測定する。だからAIが実装を無料にしても意味がそのまま保たれる。測定すべきものは最初から労力ではなくフローだった — AI時代はただその事実をもう無視できなくしただけだ。

エピローグ — 瓦礫から立て直す

見積もりが壊れたという話は半分だけ正しい。労力ベースの見積もりが壊れた。フローベースの計画は無傷だ — むしろAI時代にもっと明確になった。我々がやるべきことは測定を諦めることではなく、測定の対象を労力からフローへ移すことだ。

核心を一文で: エージェントは実装を無料にし、だからボトルネックはreview・integrationへ移り、計画と測定の中心もそこへ移らなければならない。

実践チェックリスト

次のスプリント計画ミーティングの前に点検すること。

1. 見積もりはrangeで。 単一のpointを捨て、楽観-悲観のrangeで見積もる。rangeの幅を不確実性のシグナルとして読む。
2. 広い見積もりにはspikeを先に。 幅が広いチケットはスプリントに直接入れず、timeboxされたspikeを先に入れて再見積もりする。
3. velocityを2つの山に分ける。 平均を捨て、山A (些細) と山B (難しい) を別々にトラッキングする。四半期計画は山B基準。
4. スプリントのコミットメントを検証トラックに。 「コードを書く」ではなく「検証し、integrationし、deployする」をコミットする。
5. 生成トラックにWIP制限。 reviewキューが消化できる分だけエージェントに委譲する。未mergeのPRは資産ではなく負債だ。
6. review capacityを数字で計算する。 reviewerの数 × 週間review時間 ÷ PR1つあたりreview時間。この値がスプリントのコミットメントの上限。
7. PRを小さく委譲する。 review時間はPRサイズに超線形。小さいPRがreview capacityを最も大きく増やす。
8. エージェントPRは「0%完了」と見る。 PR生成は検証の起点。検証・integrationを別チケット・別見積もりで。
9. 隠れたギャップをチェックリストで打つ。 エッジケース、integrationの仮定、非機能要件、テストの隙間、エラー処理 — 上から下へ読まず、ギャップを先に探す。
10. 揺れないメトリクスを見る。 lead time、escape rate、review latency、山Bのスループット。この4つは労力ではなくフローを測定する。

アンチパターン

避けるべきこと。1つ1つすべてよくある間違いだ。

• velocityの平均に固執する。 双峰分布の平均は誰も住んでいない谷だ。平均が上がったと喜んだり下がったと心配する前に、どの山かを聞く。
• AI活用率を目標にする。 「AI支援PR 80%」のような目標はツールの使用そのものを目的にする。AIはツールであり目標ではない。
• 行数で貢献を測定する。 AIが書いたコードの行数を自慢する報告書は過剰生成を報酬し、何の決定もできなくする。
• 生成トラックを無制限に回す。 エージェントが作れるからと全部作らせるとreviewキューが果てしなく長くなる。進捗のように見える過剰在庫だ。
• 「PRが上がった = 完了」と扱う。 エージェントPRは表面的に完成して見える。PR生成を完了と数えると検証が常に過小評価される。
• seniorをエージェントPRのreviewで消耗させる。 seniorが山Aのreviewに時間を全部使うと、山Bの本当に難しい仕事をする人がいない。seniorの深い作業時間を先に取り分ける。
• 検証が制約なのに生成ツールにもっと投資する。 ボトルネックでない所を改善するのは無駄だ。制約 — ほぼ常にreview — に投資する。
• escape rateを無視して速度だけを見る。 velocityが上がっているのにescape rateも上がるなら、それは速いのではなく検証されていないコードを速く出しているのだ。

次の記事の予告

次の記事は**「AI時代のコードレビュー: エージェントPRを検証する実践ワークフロー」**だ。この記事で「reviewが新しいボトルネック」と繰り返したので、次の記事はそのボトルネックの中に入る。エージェントPR専用のreviewチェックリスト、逆方向reviewの具体的な手順、自動ゲートと人間reviewの役割分担、そしてjuniorがエージェントPRをreviewできるよう育てる方法まで — review capacityを実際に増やす方法をコードレベルで扱う。

見積もりが壊れた跡地は空き地ではない。フローを測定し、ボトルネックを追い、検証を一等市民として扱う — より正直な計画が立つ場所だ。