長年にわたり、CIO（最高情報責任者）は少ないリソースでより多くの成果を上げることを求められてきた。しかし今、その要求を単なるクリエイティブな予算繰り以上のものにするテクノロジーが存在する。
ソフトウェア開発におけるAIは、かつて開発者、ビジネスアナリスト、テスター、プロジェクトマネージャーからなるチーム全体を必要とした作業を圧縮し始めている。エージェントはコードを書き、テストし、文書化し、アーキテクチャ上の判断を下し、人間の介入を限定的に抑えながら開発の複数段階を進めることができる。
ただし、落とし穴がある。AIをSDLCに単に追加するだけで、劇的に優れた成果を期待することはできない。エージェントを真に活用し、より少ないリソースでより多くを成し遂げるには、組織はソフトウェア開発ライフサイクルそのものを再設計しなければならない。それには、人間とエージェントの双方が担う仕事を見直すこと、必要な成果物は何か、品質をどう評価するか、チームをどう編成するかを再考することが含まれる。
従来のSDLCは「人間同士の引き継ぎ」を前提に構築されていた
従来のソフトウェア開発には、要件定義書、ユーザーストーリー、受入条件、設計書など、長い成果物のリストが存在する。これらが存在する理由は、作業がある人やチームから別の場所へと移動するからだ。たとえばアナリストが開発者に要件を引き渡す際、ドキュメントを作成することで「構築すべきもの」に対する認識を共有する。
エージェントはその構図を変える。1つのシステムが開発プロセスの複数のステップを実行できるようになると、チームは現在使用しているすべてのドキュメントを必要としなくなるかもしれない。問うべきは「既存のどの成果物を自動化できるか」ではなく、「どの成果物が今なお必要なのか」だ。
アーキテクチャ決定記録（ADR）は、後で人間が理解する必要のある決定を記録するため、引き続き価値がある。しかし、エージェントへの指示やワークフローにすでにテストの実施方法が説明されているなら、チームは別個のテスト戦略書を必要としないかもしれない。
組織は、高品質なソフトウェアを生み出すためにシステムが必要とする情報と、ガバナンス、コンプライアンス、意思決定のために人間が必要とする情報を区別しなければならない。さもなければ、チームはエージェントにもビジネスにも実際には必要ない文書の作成に膨大な時間を費やすことになりかねない。
人間ではなく「エージェント」を中心にSDLCを再設計する
この転換を実現するには、リーダーはソフトウェア開発における4つの根本的な要素を再考しなければならない。
1. AIアシスタントからエージェントチームへ移行する
今日、多くの企業は依然としてAIを個々の従業員のためのアシスタントとして捉えている。ソフトウェア開発で言えば、開発者がGitHub Copilotを使ってコードを書いたり、テスターがAIを使ってテストケースを生成したり、ビジネスアナリストがAIで要件のドラフトを作成したりするようなものだ。個々の作業は速くなるが、仕事の進め方そのものは変わらない。
より大きな機会は、複数のエージェントをオーケストレーションし、チームとして作業を実行させることにある。1つのエージェントが作業を計画し、別のエージェントがコードを開発し、さらに別のエージェントがアウトプットをレビューする。その時、人間の役割はソフトウェアのすべてのパーツを手動で構築することから、方向性の指示、判断、そして監視へとシフトする。
2. AIエージェントの作業を細分化する
エージェントにエンタープライズアプリケーション全体を開発させることは、究極の効率化に思えるかもしれない。しかし実際には、その結果はあまり好ましいものではない。
筆者の所属するセントリック・コンサルティング（Centric Consulting）では、エージェントにエンタープライズアプリケーションの数百の要件を与える実験を行ってきた。エージェントはすべてを完了したように見えたが、実際に動作したのはごく一部だった。残りは実質的にダミーのスケルトンコード（スタブ）に過ぎなかった。
作業を小さな縦割りの単位に分割すれば、ミスの影響範囲ははるかに小さくなる。アプリケーション全体を一度に構築させて最後に問題を発見するのではなく、小さく完結した機能単位をエージェントに構築、テスト、レビューさせてから、次の作業へと進むことができる。
3. 検証をより厳格にする
AIが生成する成果物が増えるにつれ、人間はその成果物を評価するためのより強力な仕組みを必要とする。
エージェントは与えられた目標に対して最適化を図るが、時に人間が予想もしない方法で行うことがある。エージェント主導の開発実験において、テストに合格することが目的の一部として指示された場合、エージェントは根本的な問題を解決せずにテストをパスする方法を見つけ出してしまうことがあると判明した。
コーディングエージェントに関するマイクロソフトの2026年の研究では、研究者はエージェントがテストスイートに対してほぼ満点を獲得しながらも、要求された機能の一部を不完全なまま残すことがあることを発見した。研究者たちはこの挙動を「テストに合わせた構築（building to the test）」と表現し、根本的な限界を強調した。つまり、テストに合格したからといって、必ずしも背景にある問題が解決されたわけではないということだ。
これは、品質保証（QA）が単にソフトウェアが動くかどうかを確認することから、動かなくなる可能性のある方法を積極的に探すことへと進化しなければならないことを意味する。
筆者の会社で開発したアプローチの1つは、同一の成果物に対して複数のレビューを実施することだ。確認レビューでは、エージェントが実行すると述べたことを実際に行ったかを問う。他のレビューでは内側から外側へ、また外側から内側へと作業を検証し、敵対的レビューではソリューションが失敗し得る方法を探す。
4. 判断力を中心にSDLCの役割を統合する
従来のSDLCでは、ビジネスアナリスト、開発者、テスター、スクラムマスター、アーキテクトなどの役割が分かれていた。エージェントが実行作業を担うようになるにつれ、これらの役割が必ずしも消失するわけではないが、その境界線は変化する。開発者は、ビジネス上の課題を理解し、期待する成果を定義し、アーキテクチャを評価し、コードをレビューできる「エンジニア、アーキテクト、ビジネスシステムアナリストを兼ね備えた存在」へと変化していくだろう。
組織は今後もビジネスを理解し、構築すべきものを定義できる人材を必要とする。しかし、各専門ステップを担う人員は同じ数だけ必要ないかもしれない。
ビジネス側もスピードアップしなければならない
開発チームがAIを活用してプロセスを再定義すると、新たな課題が浮き彫りになる可能性がある。それは、AIがソフトウェアの記述作業を加速させても、組織が実際に本番環境にデプロイするソフトウェアの量は増えないという点だ。
新たな研究は、ボトルネックがすでに下流へ移動していることを示している。50万人以上のGitHub開発者を分析した全米経済研究所（NBER）の2026年のワーキングペーパーによると、自律型コーディングエージェントの導入により、コーディング活動量は240%増加した。しかし、プロジェクト単位で測定すると増加率は80%に低下し、実際のソフトウェアリリース単位ではわずか30%にとどまった。
企業は何年もかけて、限られた開発リソースを管理するためのプロセスを構築してきた。プロダクトバックログ、四半期ごとの計画サイクル、精緻な優先順位付けの作業が存在するのは、ビジネス側が望むすべてを実現するには開発能力が常に不足しているからだ。AIはこの制約を緩和し始めているが、同時に「開発の後に控える制約」を露呈させている。
IT組織が開発のスループットを劇的に向上させることができても、ビジネス側が同じペースで意思決定を行い、フィードバックを提供し、新しい機能を導入できるようにならなければ意味がない。
セントリックでもすでにその一例を目撃している。あるチームがアプリケーションを構築したが、それはビジネス側の受け入れ態勢が整うよりも遥かに早いペースだった。テクノロジーの準備はできていたが、ユーザーの受入テスト、トレーニング、チェンジマネジメント（組織変化の管理）に何カ月もかかったのだ。
その結果どうなるか。組織は最終的に、人間が変化に追いつく以上のスピードでソフトウェアを構築できるようになるかもしれない。
「古いSDLC」を単に自動化してはならない
多くの組織は、ソフトウェア開発プロセスのあらゆるステップにAIアシスタントを導入したくなる誘惑に駆られる。これは大きな組織変革を必要とせず、「安全な」選択に感じられる。しかし、潜在的なリターンも制限してしまう。
ソフトウェア開発におけるAIから最も大きな恩恵を受ける組織とは、エージェントが得意とすることを中心にプロセスを再設計する組織だ。そうした組織は、必要な成果物を再考し、作業を管理可能な単位に分割し、品質レビューをプロセスに組み込み、ビジネスと技術の双方の判断を下せる人材を中心に役割を統合する。最も重要なのは、AIがソフトウェアの構築方法だけでなく、開発プロセス全体を支える前提条件そのものを変えるのだと理解することだ。
数十年にわたり、「少ないリソースでより多くの成果を上げる」ことはテクノロジーリーダーにとって聞き慣れた至上命令だった。AIはついにそれを可能にするかもしれない。しかし、少ないリソースでより多くの成果を出せるのは、従来のやり方で作業するのを止めた時だけなのだ。
