この連載の第 3 部は、AI がエンジニアリング活動のうち増え続ける部分を担うようになったとき、ソフトウェアプロダクトのライフサイクル全体をどう組織すべきかを問う。ドメイン駆動設計、振る舞い駆動開発、仕様駆動開発が、ビジネス知識を生きた仕様へと変える連続体をなすとした Part II を振り返ったのち、記事はソフトウェア開発ライフサイクル（SDLC） — 記事はその起源を 1960 年代としている — に目を向け、エージェント型開発によってこの枠組みの重要性は薄れるどころかむしろ高まると論じる。
記事の診断によれば、多くの企業は当初エージェント型 AI をツールの変更として扱い、プラクティスや組織や知識を変えないまま開発者にエージェントを与えた。その結果は期待外れで、トークンの大量消費、一貫性のない実装、制御しにくい品質、そして場合によってはコストを理由とした取り組みの中止が生じた。記事はこれを、ほとんど制御なしに実践される バイブコーディング と結びつけ、それが理解しにくく進化させにくいコード — 「AI slop」と呼ばれることもある — を生み出してきたと述べる。記事の答えは、SDLC をビジネスに沿った各チームにローカルなガバナンスの枠組みとして読み直し、拡張 SDLC として再定義することである。その目的は、人間とエージェントが共有する知識の蓄積を作り出し、構造化し、検証し、継続的に豊かにしていくことにある。
要点
- 記事は従来の SDLC を 6 つの段階 — 分析（Analyse）、設計（Design）、開発（Develop）、品質保証（Quality Assurance）、デプロイ（Deploy）、サポートと保守（Support & Maintenance） — として説明し、SDLC はどの手法からも独立していると論じる。アジャイル、DevOps、継続的デリバリーは SDLC を置き換えたのではなく、その実装の仕方を刷新したのだという。
- 記事は、SDLC が答えるのは「どのように」ではなく「何を」という問いであり、だからこそ、エージェントが実行の多くを担うようになった今、各段階がどのように遂行されるかを明示しなければならないとする。
- 記事は戦略的な ドメイン駆動設計 に依拠してシステムをビジネスの境界に沿ってサブドメインと境界づけられたコンテキストに分割し、また Team Topologies に依拠して、それらの境界を中心に、認知負荷に応じてチームを編成する。組織の境界とソフトウェアの境界をそろえるべき理由として、コンウェイの法則を挙げている。
- 記事は、エージェントはチームの実行能力を高めるが、人間が把握できる複雑さを高めるわけではないと論じる。そのため、チームの規模を制約するものは実行能力から、チームが吸収できる認知負荷へと移る。
- 記事は、エージェントの作業を導き、制約し、検証する仕組みを「AI ハーネス」と呼び、エージェントが自律的になればなるほど、その環境はより明示的で、構造化され、検証可能でなければならないという原則を示している。
- 記事は拡張 SDLC のための 5 つの継続的なモーメント — 発見（Discover）、設計（Design）、構築（Build）、検証とデプロイ（Validate & Deploy）、学習と進化（Learn & Evolve） — を提案している。これらは「理解する → 明示する → 設計する → 実行する → 検証する → 学ぶ → 豊かにする」というループをなし、品質保証はその前の活動に組み込まれる。
- 記事は各モーメントのプラクティスを説明している。発見では EventStorming、Continuous Discovery、Opportunity Solution Tree、設計では CRC カード、Example Mapping、そして GitHub Spec Kit のような仕様駆動開発ツールに供給される Gherkin シナリオ、学習フェーズではオブザーバビリティプラットフォームに接続されたエージェントが挙げられている。
- 記事は、プロダクトのアイデンティティをなす意思決定 — その目的、事業戦略、ユーザー体験、ビジネスモデル、構造を左右するアーキテクチャ上の選択 — を AI に委ねることに警告を発している。モデルは最も広く普及したプラクティスに収束するため、AI は競争優位を生み出すのではなく増幅するものだ、というのがその理由である。
- 記事は、提案されている多くの AI SDLC やエージェント型開発ライフサイクル（Agentic Development Lifecycle、ADLC）を批判している。それらは従来の構造を保ったまま手順を追加したり人間の担い手をエージェントに置き換えたりして、実行の高速化に焦点を当てる一方、ビジネスについての共通理解を築く活動を暗黙のままにしているという。
背景
これは連載の第 3 部であり、2 回に分けて公開された Part II を参照している。著者の論証された立場として書かれており、測定結果は報告していない。このウィキの関連記事： AI エージェント時代のソフトウェア開発、 AI 時代における開発チームの組織化 - Part II.2。