- AIコーディングツールは開発速度を高めると言われるが、実際のボトルネックはコード記述ではなく、組織の非効率なプロセスにある
- コード生産量を増やすと、レビュー待ち、デプロイ遅延、要件の不明確さなど、非開発工程の滞留が深刻化し、実際のサイクルタイムはむしろ増加する
- Eli Goldrattの**制約理論（Theory of Constraints）**によれば、ボトルネックではない工程を最適化しても、システムは速くなるのではなく、むしろ悪化する
- AIが生成したコードを作成者自身ですら完全には理解していない状況では、障害対応の対象領域は広がり、システムを推論できる人材は減っていくという構造的リスクが生じる
- 競争優位は最も速くコードを書くチームではなく、何を作るべきかを見極め、ユーザーの手に届けるチームに帰する
誤った最適化の始まり
- AIコーディングアシスタント導入により、コード出力量が40%増加したという発表が出ている
- しかし、「何に向けた速度なのか」という問いが抜け落ちている
- すでに速い工程（コード記述）にリソースを投入すると、システム全体はむしろ遅くなる
- ボトルネックでない部分を加速すると、未完成コードの在庫が積み上がり、品質低下と混乱が起きる
ボトルネックではない場所を最適化すると、システムはさらに悪化する
- 1984年にEli Goldrattが書いた小説 The Goal で示された**制約理論（Theory of Constraints）**の核心は、すべてのシステムには正確に1つのボトルネックが存在し、全体の処理量はそのボトルネックの処理量で決まるということ
- ボトルネックではない工程を最適化してもシステムは速くならず、未完了作業の在庫だけが積み上がって、リードタイムの増加、混乱、品質低下につながる
- たとえるなら、Aステーションがウィジェットをより速く作っても、ボトルネックであるBステーションの処理速度がそのままなら、AとBの間に未処理ウィジェットの山が積み上がるだけなのと同じ
「コード出力3倍」が実際にもたらす状況
- 開発者はこれまでになく速くPRを生み出すが、レビューアーの数は変わらないため、PRはレビューキューで1日、2日、1週間と待たされる
- 作成者はすでに次のAI支援機能へとコンテキストスイッチしており、8日前に書いたコードへのレビューコメントに対応する時点では、そのコードをほとんど覚えていない
- レビューが多すぎて、まともに読まずに承認するラバースタンプレビューが発生する
- CIには45分かかり、flakyなテストで失敗して再実行、デプロイパイプラインは会議中の担当者による手動承認待ちで、機能はステージングに3日間放置される
- 開発者はすでにさらに2本のPRを上げており、**WIP（Work In Progress）**が急増し、全員が6件を同時並行で抱えた結果、何も完了しない
- コードはより多く生産しているのに、リリースされるソフトウェアは減る。サイクルタイムは悪化しているのに、ダッシュボードには生産性40%向上と表示される
- AI生成コードの追加リスクとして、「書いた」本人が実際に書いたのではなく、プロンプトで生成してざっと眺めただけなので、深夜2時の本番障害時にはオンコール担当者もプロンプト作成者もそのコードを説明できない
- コードは増え、理解は減る。この状態は生産性向上ではなく、より見栄えのよいダッシュボードを備えた時限爆弾である
本当のボトルネック 1: 何を作るべきか分かっていない
- PMが実際のユーザーと2か月話していない状態で、要件はJiraチケット3行とFigmaリンクとして届く
- エンジニアは日々50種類ものマイクロな意思決定（挙動、エッジケース、エラー処理）を、仕様もないまま推測で行う
- あるチームは、営業担当がSlackで伝えてきた「見込み客が通話でたぶん言っていたこと」をもとに6週間かけて機能を開発したが、その見込み客は購入せず、その機能を使ったのは11人だけ（うち9人は社内QA）だった
- コードを書くのを速くしても、間違ったものを速く作る速度が上がるだけで、推測を自動化しているにすぎない
- ボトルネックは問題理解そのものであり、タイピングを速くしても解決しない
本当のボトルネック 2: コードが「完了」した後のすべて
- ほとんどの組織では、コード記述は全体の旅路の約**20%**にすぎず、残り80%はコードがさまざまなキューで待っている時間である
- 午後ひとつで書き上げた機能が、本番到達まで2か月かかった例もある
- PRレビュー、CI、ステージング、QA、セキュリティレビュー、製品承認、デプロイウィンドウ、カナリアロールアウトなど、長いハンドオフ、待機、キューの連鎖がある
- ほとんどの時間、コードは動いておらず、誰かに見てもらうこと、パイプラインが回ること、存在を許可されることを待っている
- より速くリリースしたいなら、作業が待たされている地点を見つけなければならず、実作業時間に対するキュー待ち時間の比率を測るべきである
本当のボトルネック 3: デプロイ信頼性の悪循環
- テストはflakyで、可観測性はひどく、カナリアプロセスも誰からも信頼されていない状態では、チームはデプロイを恐れる
- 恐れがあるため変更をより大きなリリースにまとめるようになり、それがさらに高いリスクを生み、デプロイをいっそう恐ろしくし、またより大きくまとめるという恐怖の悪循環が生まれる
- ここにさらに高速なコード出力を加えると、コードは増えるのにデプロイ文化は恐れたままなので、バッチはさらに大きくなり、リリース頻度はさらに低下する
本当のボトルネック 4: リリース後のフィードバック不在
- 機能を作ってリリースした後、適切な分析もなく、リリース後のユーザーインタビューもなく、その機能が本当に問題を解決したのか確認する人がいない
- 次の機能も推測、その次も推測で、製品ロードマップ全体がフィードバックなき推測の連続になる
- より速いコード出力とは、「作って、出して、肩をすくめる」サイクルを速く回しているだけにすぎない
本当のボトルネック 5: カレンダーが耐力壁になっている
- ボトルネックは技術的なものではなく、意思決定のための会議、1か月も会話していない3チーム間のAPI契約合意、あらゆる重要設計の単一承認ポイントになっているアーキテクトの2週間分たまったバックログであることもある
- 6週間かかる四半期計画プロセスのせいで、緊急作業ですら5週間待たないと始められないことがある
- 機能がリリースされない理由が「休暇中の人との会議待ちだから」という状況も実際にある
- これは調整の問題、人的な問題、政治的な問題であり、コードを書く速さとは無関係である
代わりにやるべきこと
- バリューストリームマッピング: 機能1つをアイデアから本番まで追跡し、各工程の所要時間と工程間の待ち時間を記録すること
- サイクルタイム測定: コード行数、マージされたPR数、ストーリーポイントではなく、コミットから本番投入、そしてユーザーが使えるようになるまでの時間を測るべき
- 待機状態の除去: PRレビューに2日かかるなら、ペアプログラミング、小さなPR、レビュー専用時間、非同期レビューの規範などで解決する。デプロイが手動承認待ちなら、自動化するか、少なくともSlackボタンに切り替える
- 始めるのをやめて、完了に集中する: WIP制限には理由があり、進行中の10件より完了した3件の方がよい。進行中のすべての項目にはコンテキストスイッチのコストがある
- 現場の人と話す: 開発者はすでにどこがボトルネックか知っており、スタンドアップで不満を口にし、Slackで何か月もミームにしている。ただ、誰も聞いていないと思っていただけだ
核心の結論
- VPは「コード出力量が40%増えた」と発表する代わりに、「バリューストリーム分析の結果、機能は工程間で平均9日待たされており、これを半減させる」と言うべきだった
- 競争優位は最も速くコードを書くチームではなく、何を作るかを見極め、作り、それをユーザーの手に届けるチームに帰する
- ボトルネックはキーボードではない
4件のコメント
> その潜在顧客は購入せず、その機能を使ったのは11人だけ（そのうち9人は社内QA）
lol
パイプラインはそのままで
ただ開発者たちが無責任になっただけのように思えます
ソフトウェア職人になりたい
Hacker Newsの意見
私たちのチームがエージェントベース開発を本格導入したとき、コーディング速度は上がるがレビュー時間が増えるのではないかと心配していた。
まだ明確な変化はなく、全員が新しいワークフローを学んでいる最中なので、十分なデータはない。
ただし、速いコーディングが特に有用な場面はいくつもある。アイデア実験、複雑な反復作業、単純だが労働集約的な実装、ハッピーパス後のエッジケース処理などだ。
特に既存ブランチやPRをそのまま拡張する場合、エージェントは非常にうまく機能する。
最大の生産性向上は、エージェントがコーディングしている間に自分が別の仕事をできる点だ。たとえばPRレビューをして戻ると、成果物ができている。
最初は懐疑的だったが、今は慎重に期待している。10倍向上は無理でも、2倍向上するだけでも大きい。
このやり方が使えるのは、ミスのコストが低いか変更範囲が小さいときだけだ。そうでなければ品質も満足度も下がり、スケジュールが圧縮されるだけだ。
結局、並列化で時間を取り戻すというより、先延ばしにしていたことを少し先延ばししにくくなる程度だ。
ただ、エージェントがコーディングしている間に別のことをするのは、奇妙な疲労感をもたらす。
AIは生産的だが、人間の職人的なコーディングとはまったく別種の労働だ。
自分でやっていたら諦めにくかったリファクタリングでも、AIがやったものなら「これはいまいちだった」と率直に判断しやすい。
ずっとマルチタスクしていたら燃え尽きがすぐ来る。議論から人間的な要素が抜け落ちているのが残念だ。
私は常に「最適化された状態」で働きたいわけではない。
誰かが「問題を理解することがボトルネックだ」と言っていたが、私はなぜ速いタイピングが問題理解の助けにならないのかと聞きたい。
間違ったものを素早く作ってみれば、むしろ正しい方向をより早く見つけられるかもしれないのではないか。
私はよく、何かを作ってみることで自分が本当に欲しいものに気づく。プロトタイプ作成が安くなるほど、この傾向は強くなる。
もちろん、最終的には「もっとユーザーと話すべきだった」という振り返りで終わることも多いが、それはまた別の問題だ。
銀行のようなところでは、うまくいっても週に一度程度しか実験できない。
だがソフトウェアの大半はそうではない。コードを書くことは全体の仕事の一部にすぎない。
外科医が単に「切る仕事」だけをしているわけではないのと同じで、エンジニアも単にコードを書くだけではない。
一人でコードだけを磨いているなら、それは単により大きな混乱を生むだけだ。
ときにはPMや顧客と1時間話すほうがはるかによい。
今のLLMブームは、問題より先に解決策が出てきた感じがする。
本当に速度を上げたいなら、まず「何がボトルネックなのか？」と問うべきだ。
経営陣がAIのプレゼンを見て「これを使えば速くなる」と信じるのは、単なる**雰囲気経営(vibe management)**にすぎない。
コーディングはその中でも最も労働集約的で自動化しやすい部分だ。
LLMはこの部分をかなり軽減できる。特にテストコード作成のような作業はAIが得意だ。
人間の開発者はいまだにコードへの執着を捨てられていない。
実際にはコードは単に解決策の中間表現（IR）にすぎない。
GCCがアセンブリに変換するとき内部最適化を気にしないのと同じで、エージェントがコードを生成しても、私たちは結果の正確さだけを見ればよい。
明確な仕様と反復的なレビュー過程があれば、人間でもエージェントでも同じ実装を出せる。
LLMはそうではない。誤解したり、**幻覚(hallucination)**を起こしたりすることがある。
だから依然として人間がレビューしなければならない。
エージェントが誤ったパターンを選んだり、技術的負債を積み上げたりすることは多い。
いつかはプログラミング言語そのものをなくせるかもしれないが、まだ先は長い。
意味が拡張されたり圧縮されたり、場合によっては失われたりもする。
多くの企業は本気で良いコードを求めてはいない。
社内評価は「どれだけ多くデプロイしたか」で決まり、問題を指摘すると「細かすぎる」と言われる。
結局、社内ステークホルダーは単に「成功した」という名目を欲しがっているだけだ。
技術者にはそのリスクを説明する責任がある。
AI導入後、品質低下が実際に現れている。
うちの会社はPR承認も適当で、CIには45分かかり、デプロイは何日も遅れる。
しかもAI利用も禁止されている。ほとんどが人間の書いたコードだと言われるが、疑わしい。
この記事が見落としているのは2点ある。――(A) エージェント利用とプロセス最適化は両立可能だということ、(B) 本当にコードがボトルネックになっているチケットもあるということ。
結局重要なのはAIかどうかではなく、ボトルネックを取り除くプロセス改善だ。
私は一人開発者だ。コーディング速度は実際に問題になる。ほかの仕事に使える時間を奪うからだ。
今日Claude Codeを設定したが、これでググる時間やテスト作成にかける時間が減った。
生産性が10倍になるわけではないが、省力化技術として十分に価値がある。食洗機のようなものだ。
今ではAIがテストまで書き、エッジケースも警告してくれる。
完璧ではないが、新機能のリリース速度が上がり、自分の時間も増えた。
「AIは信頼できない」という言葉は、まるで「コンパイラは信頼できない」と言っているように聞こえる。
結局は人間が方向性を示し、プロンプトを改善しながら一緒に成長していく過程だ。
スタートアップやVCの環境では、コーディングよりビジネス問題の解決が核心だ。
コード生産量が増えても、システム全体の結果が良くなる保証はない。
テンプレートやコードジェネレータのように速度は上がるが、要件収集が10倍速くならない限り、10倍の生産性は不可能だ。
比喩としては少し不適切だ。
AIが人間ならあまりしないミスを犯さないようにするには、どうすればよいのだろうか？
人間はコードを段階的に論理的に検討するが、AIはそうではない。
Amazonのようにシニアエンジニアがレビューするとしても、レビューはすべてのバグを捕まえるためのプロセスではない。
しかもシニアほど会議が多く、コードの文脈をよく知らない。こうしたレビューはどれほど有効なのだろうか？
人間が完璧だと思うのは錯覚だ。
私たちはAIに人間より高い基準を要求している。
結局重要なのはQAプロセスの強化だ。テストを開発者任せにしてはいけない。
以前読んだ本『The Goal』を思い出す。工程の一段階を自動化すると、次の段階がボトルネックになるという現象だ。
ソフトウェアも同様で、コード生成が速くなってもプロセス全体が追いつかなければ意味がない。
結局すべては利益創出という目標の下にある。コード品質もその目標に従属する概念にすぎない。
コードを書く速度は、リスクが大きい状況ではボトルネックではない。
ときにはゆっくり計画し、結果を熟考するほうがよい。
たとえばAI産業のように巨大なシステムをあまりに速く構築すると、誤った方向への文明的リスクを招く可能性がある。
一方、週末に一人で作る小さなゲームなら問題ない。結局、速度を決めるのはリスクの大きさだ。