Zenn
tacomsテックブログPublicationへの投稿
🌯

AIでコーディングが爆速化した今、開発組織が向き合う新たなボトルネック

Masato Inoue @ tacoms CTO
に公開
AI
開発手法
開発生産性
フロー効率
aiコーディング
idea

はじめに

「AIでコーディング速度が3倍になったらロードマップも3倍に出来るの！？」セールスチームメンバーとの会話で、そんな話になった時に純粋に3倍にはならないかな〜と回答しました。
なぜ3倍にならないかに関して、エンジニアの皆さんは既知の事実かもしれませんが、開発プロセスは一連のフローであり全てがつながっています。つまり、局所最適をしても全体が速くなるとは限らないという話です。

エンジニアリングの世界において人間とAIはどのように棲み分けしていくのか。コーディング作業の未来はどうなるか。議論が加熱している昨今ですが、今回はAIコーディングが開発プロセスへどのような影響を与えるのか、コーディング時間が高速化することで次なるボトルネックはどうなっていくのかを考えてみました。

結論

気がついたら長文になってしまっていたので、最初に結論を書いておきます。この記事で伝えたい内容は以下の3つです。

AIコーディングの普及によりボトルネックは上流・下流双方向へ移転する

  • 「システム全体のスループットは最も遅い工程に影響される」という原則を踏まえると、AIの進化スピードに合わせて上流（要件定義・設計）と下流（レビュー・QA・デプロイ）両方のボトルネック改善が必要

過去の技術革新と比較しても圧倒的速度でボトルネックが遷移している

  • 制約理論の中にボトルネックの移転を表す制約移転という概念がある。
  • ウォーターフォールからアジャイル、クラウドインフラ普及などの過去の制約移転は数年単位で進行し、組織が対応策を検討する時間があった
  • AI時代の制約移転は最小限の投資で数ヶ月という短期間で発生し、多くの組織が新たな制約に直面しうる

「AIによる変化が小さい領域」への投資が長期的なアップサイドに繋がる可能性

  • 本番へのデプロイ、品質管理など人間の判断や責任が伴う場面においては、AIによる効率化の恩恵は受けづらく相対的に変化のスピードは遅い。
  • AIコーディングの進化スピードの速さに対して開発プロセス全体で最適化していかないとボトルネックが生じる
  • 「AIの変化が少ない領域」への投資も継続的に強化しなければ、AIによって1人あたりの作業効率が上がり続けたとしても、プロセス全体としてのスループットが上がらない。

では本題に入っていきます！

コーディング領域筆頭にAIによる作業効率の急激な上昇

ここ数年マネジメント寄りの業務が多かったのですが、直近半年は自分で手を動かしてコーディングしたりしてます。
新しいプロダクト開発を自分でも手を動かしながら実際に多くのAIツールを使う中で、イシューの要件定義〜設計からPRを作りレビューリクエストするまでのスピードは明らかに早くなったと感じています。
特に最近リリースされたClaude Codeについては、エンジニアコミュニティで大きな話題となっており、多くの開発者がその効果を実感しています。（自分も毎日使ってますがめちゃくちゃ楽しい！）
https://docs.anthropic.com/ja/docs/welcome

今後、開発者がコードを書く時間が短くなり、一定期間あたりの作業量が増えることは明らかです。むしろそのような状況になっていかなければ、企業としての競争力を失うでしょう。

個人の作業スピード向上が開発プロセスにどう影響するか

では、個人の作業スピード向上は開発プロセスにどのように影響してくるでしょうか。
開発プロセスには多くの工程があり、それぞれ依存関係があります。
AIによってメンバー1人1人が開発に費やす時間が圧倒的に向上している今、プロセス全体を俯瞰した時に、どのような変化があるのか、どのように最適化していくべきかについて整理していきます。

開発組織で起きつつあるボトルネックの変化

Before AI）実装がボトルネック

従来の開発プロセスでは、実装作業が最も時間のかかる工程でした。エンジニアがコードを書く時間が長く、この工程がチーム全体の開発速度を決定していました。コードレビューやQA・テストは相対的に短時間で処理でき、実装完了を待っている状態が多い状況でした。

After AI）要件定義・設計 & レビュー・QA・デプロイがボトルネック

AIツールにより実装スピードが劇的に向上している昨今においては、開発プロセス全体のバランスが大きく変化しつつあります。
プロセスは上流から下流に流れており、連続性があるので中間の1プロセスが劇的に向上した場合は、より多くのインプットを求め、より多くのアウトプットがされることになります。
プロダクトマネジメントの要件整理が間に合わない。下流に流れる量が多すぎてコードレビュー、QA、デプロイなどで滞留するという現象に繋がるでしょう。

システム全体のスループットは最も遅い工程に影響される

「AIツールでコーディングが高速化されたのに、なぜ開発全体は同じスピードで速くならないのか？」

この疑問をより深く理解するために、製造業やオペレーション改善の分野で長年研究されてきた「制約理論」という考え方が役立ちます。この理論は、システム全体の性能がどのように決まるかを説明するもので、ソフトウェア開発プロセスにも適用できます。

制約理論とは

制約理論（Theory of Constraints）の創始者であるエリヤフ・ゴールドラット博士によると、「業務全体やシステム全体のパフォーマンスが制約条件に依存し、制約条件を継続的に改善することで全体のパフォーマンスが向上する」とされています。

『This is Lean』という書籍でも同様に、「システム全体のスループットは、最も能力の低い工程（ボトルネック）によって決まり、ボトルネック以外の工程をどれだけ改善してもシステム全体の性能は向上しない」という法則が説明されています。

制約移転（Constraint Migration）という現象

制約理論において重要な概念の1つが「制約移転」です。制約理論の5つの集中ステップでは、現在の制約を改善し続けると、その制約が「破壊」され、別の工程に制約移転することが説明されています。

制約移転のメカニズム

  1. 制約の特定 -> 現在のボトルネック工程を特定
  2. 制約の改善 -> その工程の能力を向上させる
  3. 制約の破壊 -> 改善により、その工程が制約でなくなる
  4. 新制約の出現 -> 以前は隠れていた別の工程が新たなボトルネックとして顕在化
  5. 継続的改善 -> 新しい制約に対して同じプロセスを繰り返す

AIツールによる生産性向上と開発プロセスにおける制約移転

開発プロセスにおいて、まさにこの制約移転が起きています：

制約移転前（AIツール導入前）
制約：実装時間
非制約：レビュー、QA、デプロイ工程は余裕がある状態

制約移転後（AIツール導入後）
旧制約：実装時間が大幅に改善（制約が破壊された）
新制約：コードレビュー・QA・デプロイ工程に移転
結果：システム全体のスループットは新制約によって決定される

制約理論を活用すると、AIによるコーディング効率の向上が、期待される開発速度の向上に直結しない現象を説明できます。コーディング工程が劇的に改善されても、下流工程がボトルネックとして残る限り、組織全体の開発速度はコーディング効率に比例して向上するわけではありません。

ソフトウェア開発における制約移転の歴史的を振り返る

制約移転は、ソフトウェア開発の進化過程で繰り返し観察される現象です。TOC Instituteの事例研究でも、多くの組織で制約移転による改善が報告されていますが、過去の制約移転と現在のAI時代の制約移転には大きな違いがあります。

ウォーターフォールからアジャイルへの移行では、2000年代に多くの組織が要件定義・設計プロセスの柔軟性向上を目指しました。長期間の計画策定という制約を短期イテレーション化によって解消したことで、今度は品質保証・テスト・デプロイ工程が新たなボトルネックとして顕在化しました。この制約移転により、テスト自動化、CI/CD、DevOpsという概念が急速に発展することになります。

クラウドインフラの普及は2010年代に起きた大きな制約移転の例です。従来は数ヶ月を要していたインフラ調達・構築時間が数分に短縮されることで、インフラ制約は劇的に解消されました。しかし、この改善により今度はセキュリティ管理・コスト最適化・運用監視が新たなボトルネックとして浮上し、DevSecOps、FinOps、SREという新しい専門領域の確立に繋がりました。この制約移転も、組織が戦略的にクラウド移行を計画し、段階的に対応策を講じることが可能でした。

AI時代の制約移転はスピードが違う
Aという制約が何らかの要因で解放され、新たなBという制約が生まれる。Bという制約を解放してCという制約が....このループを回すことで改善していくという構図は過去と全く同じですが、唯一異なるのはスピードでしょう。

クラウドインフラの普及の時と異なるのは、組織としての投資時間や投資金額が最小限であったとしても、実装時間という「制約」が移転されているということです。過去2つの大きなパラダイムの変化と比較してもROIが高いため、普及スピードを後押ししているでしょう。

GitHub Copilot、Cursor、Claude Codeなどのツールは、短期間かつ最小の投資額で実装時間という「制約」が劇的に解消しています。
しかし、コーディング効率が向上すればするほど、上流工程（要件定義・設計判断）と下流工程（レビュー・QA・デプロイ）の両方でボトルネックが深刻化するリスクを孕んでいます。

ではどうすれば良いか

これまで見てきたように、AIによる制約移転は過去の事例と比べて圧倒的に高速で進行しています。この変化に対応するためには、まず開発プロセス全体におけるAIの影響度の違いを理解することが重要です。

すべての工程が均等にAIの恩恵を受けるわけではありません。そのため、AIによる変化が大きい領域と相対的に小さい領域を明確に区別し、変化の小さい領域への先行投資によってプロセス全体を最適化していく戦略が必要だと考えています。

AIによる変化が大きい領域と小さい領域

開発プロセス全体を俯瞰すると、AIによる変化が大きい領域と、相対的に小さい領域が分かれています。この特性を理解すること組織としての投資戦略を立てる上で重要だと考えています。

AIによる変化が大きい領域：コーディング関連プロセス

2025年6月時点で、コーディング領域は劇的な変化を遂げています。GitHub Copilot、Cursor、Claude Codeなどのツールにより、実装速度は従来の2-3倍に向上し、コードレビューの効率化も進んでいます。
この領域の特徴は、外部のイノベーションによって急速に進化することです。LLMの性能向上やAIコーディングツールの競争により、私たちが特別な投資をしなくても生産性が向上し続けています。

もちろん、これらのコーディングツールは個人およびチームの使い方によってより大きな効果をもたらすケースもあります。クオリティの高い新しいサービスの市場投入により状況が変わりうるため、相対的に見ると外部の市場進化への依存度が高い領域と言えるでしょう。

AIによる変化が小さい領域（25年6月時点）

一方で、以下の領域はAIの恩恵を受けにくい特性があります：

上流工程におけるボトルネック

  • 要件定義・プロダクト戦略
    • 「何を作るか」の意思決定速度
    • ビジネス要件の明確化と優先順位付け
    • ステークホルダー間の合意形成
  • チーム間調整
    • 複数チーム間の仕様調整や依存関係管理
    • リソース配分と優先度調整

下流工程におけるボトルネック

  • デプロイメントプロセス
    • 本番環境へのデプロイ / およびロールバック判断
    • CI/CDパイプラインの効率向上
  • 品質管理プロセス
    • テスト戦略の策定
    • 品質ゲートの設計

これらの領域でAIの恩恵が限定的な理由は、人間の判断、組織間の調整、責任の所在が重要な要素となるためです。特に上流工程では、ビジネス理解や戦略的思考、複雑な利害関係の調整が必要で、技術的な自動化を超えた人間特有の能力が求められます。

実際に、AnthropicのCPOであるMike Krieger氏も「以前はエンジニアリングがボトルネックだったが、現在は『何を構築するかを決定し、全員を調整すること』や『本番環境にマージするデプロイ作業』がボトルネックになっている」と言及しています（参考インタビュー）。

ただし、この状況も永続的かどうかは未知数です。
SLOが明確に定義されているプロダクトであり、AIがSLOの監視を100%正確に出来るという担保があればデプロイはAIによって自動化される未来もあり得ます。
ただ責任の所在がAIになることはないと仮定すると、責任が求められるBtoBアプリケーションにおいて「AIがOKと判断して障害が起きました」は許されないように感じています。

※ AIが社会的な責任を担保する存在になれば良いのだろうか。もしくはそのような契約を顧客側と合意する世界が来るのでしょうか。考えてみるのは面白いですね👀

「変化の大きい領域」の効果を最大化するためにも「変化の小さい領域」への先行投資を

AIによる変化の大きい領域と小さい領域があるという話、ボトルネックの法則の話を統括すると、変化の小さい領域において先行投資しておかないと、この先AIコーディングの進化が更に進んだとしても、十分な恩恵が受けられないという結論に至りました。

そして、変化スピードの格差が拡大すれば拡大するほど、ボトルネックは時間の経過とともにより深刻化していくのでより一層スループット高速化から遠ざかってしまうリスクがあります。

AIコーディング領域がこれからどこまで進化するのか。本当に楽しみですしコンテキストウィンドウが増えれば増えるほど複雑なタスクを自律的に任せられるようになることでしょう。
そのような状況になったときにAIの恩恵を最大限に活用するためにも、プロセス全体のバランスを見ながら投資していこうと思います。

参考

制約理論・ボトルネック理論

ソフトウェア開発における制約理論の適用

AI開発ツールと生産性に関する調査

書籍

  • 『This is Lean』- ボトルネックの法則に関する解説
  • エリヤフ・ゴールドラット博士『The Goal』- 制約理論の基礎概念
tacomsテックブログ
tacomsテックブログPublication

株式会社tacomsメンバーのテックブログです！ 各メンバーの日々の学びから会社の取り組みまで掲載していきます！

Discussion