AIはコーディングを高速化したが、デリバリーは変わらず〜真のボトルネックは引き継ぎにある

AIコーディングアシスタントにより、開発者は数秒で関数を書き、ボイラープレートを除去し、昼前にはラフなアイデアを動くコードに変えられるようになった。しかし、チームのデリバリーメトリクス（サイクルタイム、デプロイ頻度、機能承認から顧客利用までの時間）はほとんど変わっていない。このギャップには単純な説明がある。ツールは仕事の特定の一部分、つまりアイデアから出荷される機能までの間のごく一部のみを大幅に改善したのだ。

コーディングは常にタイムラインの小さな部分だった。機能が実際に時間を費やす場所を考えてみよう。エンジニアがコードを書くのは週の一部であり、コーディングという行為はアイデアから本番までの長いチェーンの一段階に過ぎない。機能が承認されてから顧客が使うまでの時間のほとんどは、キューでの待機や人から人への移動に費やされ、コードを書くことではない。AIはごく一部のごく一部を高速化する。コーディングは速くなるが、機能の出荷にかかる週数はほとんど変わらない。なぜなら、それらの週の大部分はタイピング以外のタスクに費やされていたからだ。

時間は引き継ぎの中にある。機能は顧客に届くまでに一連の人々を通過する。各リンクには人、ツール、そして次の人が空くのを待つ時間が含まれる。典型的な経路は以下：プロダクトマネージャーが仕様を書き、デザインの空きを待つ。デザイナーがFigmaでモックを作り、エンジニアリングのキャパシティを待つ。エンジニアがモックを読み、コードで再構築し、モックが曖昧にしたインタラクションの詳細を推測する。QAがビルドをテストし、見つけた問題を報告する。レビュアーがプルリクエストを読み、承認するか差し戻す。各ステップ間の移行はツール間・人々間の翻訳であり、翻訳のたびに元の意図の一部が失われる。デザイナーはプロダクトマネージャーが正確に想像しなかったものを構築する。エンジニアはデザイナーが正確に描かなかったものを構築する。作業は後戻りする。誰かが仕様を更新し、誰かがモックを再構築し、誰かがコードをやり直し、別のスプリントが同じ機能のバージョン調整に消える。

高速なコーディングアシスタントはこの構造全体に手をつけない。チェーン内の1つのリンクを加速するが、チェーンの全長はリンク間の待ちと引き継ぎによって決まる。タイピングを速くしても、キューと翻訳がそのまま残っていると、機能はほぼ同じ時間に到着する。

手動のデザインからコードへの変換は、多くのチームでスプリント容量の大部分を消費し、間隔、状態、インタラクションを明確にするための往復がそれをさらに延ばす。シニアエンジニアは承認されたFigmaファイルをピクセル単位で再構築し、ファイルが暗黙のままにしたインタラクションの詳細をデコードし、デザインとビルドの間で何かが失われたためにさらに2〜3回の反復を行う。エンジニアが書くべき機能ロジックはその間ずっとバックログで待つ。再構築を高速化するAIアシスタントは、そのストーリーの中で既に最も安価な部分の時間を削るが、明確化ループと待ち時間は以前とまったく同じ長さのままである。

なぜ高速化は実感できてもダッシュボードは横ばいなのか？個人の経験とチームの経験を分けると矛盾は解消する。各開発者はアシスタントが自分のタスク内で機能するため、作業が速くなったと感じる。チームはこれまでと同じ調整オーバーヘッドを引き続き負う。そのオーバーヘッドは人々の間のスペースに存在するからだ。チーム内の全エンジニアに最高のAIアシスタントを与えても、チームレベルの数値は安定する。デリバリーの制約は引き継ぎに移っており、シングルプレイヤーのコーディングツールはそこに到達できない。それは単一のエディタ内で機能し、ボトルネックはエディタ間のギャップにある。

チームが自律エージェントを追加すると、この力学はさらに強まる。エージェント群を運用するチームは、より多くの変更、より多くのプルリクエスト、そして人間のレビューを必要とする作業を生成する。安価なコード生産は、調整と承認を待つアイテムの量を増やす。既存のワークフローにさらに多くのエージェントを向けると、ボトルネックがさらに緊密になる。なぜなら、レビューと承認のステップは元々遅い部分であり、今や処理すべきものが増えたからだ。

ここで、ほとんどのAI投資が間違ったレイヤーで測定されている。チームは個人のエンジニアの感覚やアシスタントが生成できるコード量を追跡し、それらの指標は改善する。ビジネスにとって重要な指標、つまりチーム全体の出荷速度はほとんど動かない。

チームメトリクスを動かすには、コーディングを取り巻くタイムラインの99%に取り組む必要がある。つまり、引き継ぎそのものを潰すことだ。目標は、役割間の翻訳とキューを取り除き、チームが同じアイデアのバージョン調整に時間を浪費しないようにすること。チーム全員が機能が存在する最初の瞬間から、同じ場所で、同じ実際のコード上で作業することを想像してほしい。フローは具体的にいくつかの方法で変化する：プロダクトマネージャーがエージェントに機能を説明し、エージェントが実際のコンポーネントとデザイントークンを使ってコードベースに対して構築する。デザイナーが同じブランチを開き、ライブ実装上で直接UIを洗練する。デザインシステムが強制され、ずれが生じない。エンジニアが差分をレビューし、既存のパイプラインを通じてマージする。アーキテクチャの所有権とマージ権限を維持する。QAや他のステークホルダーが実行中の実装をレビューし、コンテキスト内で問題をフラグし、可能であれば自分で変更を加える。

翻訳を待つキューにチケットが滞留することはない。なぜなら、チーム全体が同じアーティファクトを編集するから。プロダクトマネージャー、デザイナー、エンジニア全員が同じブランチに触れるため、開発者に届くバージョンは、既に全員が実際のプロダクトに対してチェックしたものになる。

旧来のチェーンと協調ワークフローの違いは、作業が停止し手が変わる回数にある。このようなワークフローには、チーム全体が同じプロダクションコードで作業できる場所が必要であり、それがBuilderだ。実際のコードベース、デザインシステム、gitワークフローに接続し、プロダクト、デザイン、エンジニアリングが同じブランチで作業できる。エージェントがフロントエンドの実行を担当し、人間が判断、アーキテクチャ、最終承認を担当する。変更は既存のCI/CDパイプラインを通じて出荷される。プラットフォームはリポジトリを読み込み、コンポーネント、トークン、パターンをインデックスするため、エージェントが生成するコードは最初のドラフトから既存のデザインシステムを使用し、プロトタイプからプロダクションへの個別の翻訳ステップが不要になる。開発者はエディタ内で使用するAIアシスタントを引き続き保持できる。コラボレーションレイヤーがその周囲にあり、チームの残りのメンバーが同じ実際のコードで作業できるようにする。その結果、作業は役割境界ごとに停止して待つことなく、アイデアから出荷まで進む。レビューはゲートとして残り、承認はプラットフォーム上に残り、エンジニアはマージ権限を保持する。これにより、標準を維持しながらチームはより速く動く。

この方法で実行するチームはより多くの作業を進めることができる。なぜなら作業が手の間でキューに並ばないからだ。実際に重要な数字はチームの出荷速度である。個人のエンジニアの感覚だけに現れるAI投資は、タイムラインの最も小さな部分を改善したに過ぎない。真の利益を得ているチームは、チーム全体とそのエージェントが実際のコード上で一緒に構築できるようにワークフローを再構築しており、Builderがそれを可能にするプラットフォームである。彼らは結果をチームの出荷速度で測定する。