振る舞い駆動開発（Behavior-Driven Development、BDD）は、会話を開発の中心に置くことで、業務ドメインの振る舞い — 席の予約、リスクの算定、支払いの検証といった出来事に応じてシステムが適用するルール — を引き出すプラクティスである。ユーザーストーリーを出発点として、業務の専門家、プロダクトマネージャー、開発者、テスターが共同で管理ルール、特殊ケース、受け入れ基準を明確にし、その結果がシナリオとして形式化される。
用法
AI 時代における開発チームの組織化 - Part II.2 は、AI エージェントが関わるようになるとこのプラクティスがどう変わるかを論じている。BDD の従来からの目的は、会話に参加する人々のあいだで期待される振る舞いについての共通理解を築くことだった。この記事は、そこにもう一つの目的が加わったと主張する。すなわち、システムがどう振る舞うかを明示的な記述としてエージェントに与えることである。エージェントはディスカバリーのワークショップに出席せず、質問もせず、自らの仮定を検証することも、経験によって曖昧さを補うこともない — コンテキストの中で明示されていることだけから推論する — ため、暗黙のルールや文書化されていない例外はすべて潜在的な誤りの源になる。
この説明によれば、流れは次のようになる。Example Mapping のワークショップが会話を振る舞いの知識 — ルール、例、反例、エッジケース、未解決の問い — に変える。その知識は次に Gherkin 構文のシナリオとして書かれる。記事によれば、これはもはやテストのための受け入れ基準であるだけでなくエージェントへの指示言語であり、各シナリオが初期条件、きっかけとなる出来事、期待される判断、観測可能な結果を述べる。不正確なシナリオは受け入れテストだけでなくエージェントのコンテキストをも貧しくするため、記事はシナリオに関する BRIEF 原則 — Business language（業務の言葉）、Real data（実データ）、Intention revealing（意図を明らかにする）、Essential（本質的）、Focused（焦点が絞られている）— に新たな重みを置いている。
同じ記事は、BDD を他の 2 つのプラクティスのあいだに位置づけている。ドメイン駆動設計 は「業務は何を表しているのか」に答えて構造的なコンテキストを提供し、BDD は「業務はどう振る舞うのか」に答えて振る舞いのコンテキストを提供し、仕様駆動開発 は両者を生きた仕様にまとめる。記事の説明では、集約が担う不変条件はユーザーストーリーへと分解され、次いで BDD のシナリオによって仕様化される。
適用される場面
- 条件。 記事は、組織の競争優位が存在するドメインのコアドメインについて、DDD や SDD とともに BDD へ大きく投資することを推奨している。サポートドメインは複雑さがそれを正当化する場合に恩恵を受けうる一方、汎用ドメインはより多くの自動化に向いている。
- 前提。 業務の専門家とチームが、このプラクティスの土台となる会話を行うために集まれること、そして結果として得られるシナリオが正確に保たれることを前提としている。
- 失敗モード。 記事は、不正確または不完全なシナリオはエージェントが推論の拠り所とするコンテキストを直接貧しくすると警告し、DDD/BDD/SDD の組み合わせの落とし穴として、長すぎる仕様や薄すぎる仕様、複数の場所に重複した知識、進化が止まった仕様、ニーズではなく解決策を記述した仕様を挙げている。
- 確立の度合い。 BDD 自体は AI エージェント以前から存在する — 記事は、業務の専門家、プロダクトマネージャー、開発者、テスターの認識を揃えるというその本来の役割を説明している。エージェントのための言語としての使い方は、この記事が論じている立場であり、測定された結果ではない。