この記事は、AI 時代における開発チームの組織化をテーマとする連載の Part II の続きである。冒頭で改めて示される連載の前提は、AI によって価値がコードから知識と意思決定の質へと移るというものであり、今回の記事は、その知識の蓄積（patrimoine de connaissances）を、チームにとってもエージェントにとってもできるかぎり明示的なものになるよう、具体的にどう構築し構造化するかを示している。
記事の議論は、連続する段階として扱われる 3 つのプラクティスに沿って進む。ドメイン駆動設計 は「ビジネスは何を表しているのか」に答えて構造的なコンテキストを提供し、振る舞い駆動開発 は「ビジネスはどのように振る舞うのか」に答えて振る舞いのコンテキストを提供する。そして 仕様駆動開発 がその両方を、生きていて一貫性があり、バージョン管理された仕様へとまとめ上げ、それがプロジェクトの信頼できる唯一の情報源（source of truth）となる。エージェントは発見のためのワークショップに参加せず、質問もせず、ビジネスについての暗黙知も持たないため、暗黙のままにされたものはすべて潜在的な誤りの原因になると記事は論じる — これこそが、これらのプラクティスに新しい役割を与えるものだという。
続いて記事は組織面での結論を引き出す。エージェント型のチームは、価値が知識へと移ることの原因ではなく結果として位置づけられ、DDD、BDD、SDD への投資 — そしてエージェントに与える自律性 — は、取り組むサブドメインの種類に応じて調整される。
要点
- エージェントの登場によって BDD は新たな目的を得る。ビジネスの専門家、プロダクトマネージャー、開発者、テスターの認識をそろえることに加えて、システムがどう振る舞うべきかの明示的な記述をエージェントに与えるという目的である。
- Example Mapping のワークショップは、会話を振る舞いについての知識 — ルール、例、反例、エッジケース、未解決の問い — へと変え、それが Gherkin のシナリオとして形式化されて、エージェントに対する指示言語として機能する。
- 記事は、シナリオのための BRIEF 原則（Business language、Real data、Intention revealing、Essential、Focused）を、その知識を正確にし、エージェントが直接使えるものにする手段として紹介している。
- 集約が担う不変条件はユーザーストーリーに分解され、そのうえで期待される振る舞いを記述する BDD のシナリオによって仕様化される。
- SDD では、プロンプトに代わって仕様が出発点となる。コードは参照の基準ではなく、明示的に構造化された知識の帰結になる。記事は、これを実践している取り組みとして Kiro（AWS）、GitHub Spec Kit、Tessl を挙げている。
- 記事は GitHub Spec Kit を GitHub によるオープンソースとして説明している。仕様、計画、タスク、アーキテクチャ上の決定を Git でバージョン管理される Markdown ファイルとして保持し、プロジェクトの初期化後は 3 つのコマンドを軸にしたワークフローで進める。
/specify（何を、なぜ）、/plan（選択したアーキテクチャと整合する実装計画）、/tasks（実行可能なタスクへの分解）である。 - プロジェクトのコンテキストを与えられたエージェントは、ワークショップのファシリテーション補助役として振る舞える。既存のルールを思い出させたり、矛盾を検出したり、調査の方向性を提案したりすることで、Example Mapping で出た未解決の問いや EventStorming のホットスポットに答えられる — ただし参加者の意思決定に取って代わることはない。
- SDD はすべてのコードを生成することを意味しない。コアドメインは、エージェントが生成したコードの入念なレビューを伴う DDD、BDD、SDD への重点的な投資に値し、支援サブドメイン（Supporting Domain）はその複雑さが見合う場合に恩恵を受けうる。汎用サブドメイン（Generic Domain）ははるかに多くの自動化や既存ソリューションの利用に向いている。
- 記事はサブドメインごとの目安となるチーム構成を示している。コアサブドメインにはシニア 4 名、支援サブドメインにはシニア 2 名とジュニア 1 名、汎用サブドメインにはシニア 1 名とジュニア 1 名である。
- DDD/BDD/SDD の 3 つ組が誤って適用されうるパターンとして、過剰な仕様化、不十分な仕様化、信頼できる唯一の情報源を保たずに知識を重複させること、ソフトウェアとともに進化しなくなった仕様、そしてニーズではなく解決策を記述する仕様を挙げている。
- エージェント型 AI の導入は、仕事の組織、協働、スキルを変えるため、コミットしたガバナンスと段階的な支援を必要とするものとして示されている。
背景
これは連載の 1 回分であり、Part II の前半を参照している。著者の論証された立場として書かれており、測定結果は報告していない。このウィキの関連記事： AI エージェント時代のソフトウェア開発、 AI 時代における開発チームの組織化 - Part III。