プロセスをAgent速度に合わせる

どの組織モデルを選ぶにせよ、共通して直面する問題がある：既存のプロセスが遅すぎるのだ。

Agent駆動チームはユーザーストーリーを1日で完了できるべきだ。この速度が何を意味するか？午前中に要件と受入基準を定義し、昼食前に設計とテストフレームワークのセットアップを完了し、午後にAgentが実装とテストを完了し、夕方には受入、マージ、出荷する。Claude Codeチームのリリースケイデンスは10日間で10バージョン、ある日は2～3バージョンをリリースしている。

この速度では、従来のプロセスにおけるすべての手動待ちステップがボトルネックになる。

Four-eyesコードレビューはすべてのコードに2人のレビューを要求する。Agentが1日で機能を完成させても、2人のレビュアーの調整に3日かかる。変更承認委員会は週1回しか開かれない。Agentは1日に10回デプロイできる。手動デプロイプロセスは運用スタッフのスケジュール調整が必要で、枠は週に1回しか空いていない。

これらのプロセスは人間の実行速度では合理的だった：品質保証とリスク管理を提供していた。しかしAgent速度では、それらが提供する保証は待ちコストによって相殺される。待ち自体がリスクだ：コードがレビューされるまで3日間放置され、その頃にはレビュアーのコンテキストは薄れ、実際にはレビュー品質を下げている。

すべてのプロセスステップを再評価する必要がある。自動化できるものは自動化する：CI/CDパイプラインが手動デプロイに取って代わり、自動テストが手動テストに取って代わり、敵対的Agentレビューが一部の人間レビューに取って代わる。自動化できないものは高速化する：Ownerたちが同席し、リアルタイムで意思決定し、問題が発生したらミーティングを設定せずにその場で議論する。デイリースタンドアップのケイデンスはAgent速度ではすでに遅すぎる。意思決定はリアルタイムで行われる必要がある。

実用的なベンチマーク：ユーザーストーリーが1日以内に完了しないなら、ストーリーが大きすぎて分割が必要か、何らかのプロセスステップがブロックしている。