振る舞い駆動開発(Behaviour-Driven Development, BDD)とは，ソフトウェア開発が現代ビジネスの基本であるという認識の下で，ビジネス上のステークホルダとソフトウェア開発者のコミュニケーションを支援するものだ — 先頃公開したブログ記事“experiences working with BDD”の中で，Kevin Smith氏はこのような主張を展開した。
Dootrixの共同創業者で同社のテクニカルディレクタを務めるSmith氏は，自身がアジャイルプロジェクトの実践を長く続けた結果，いくつかの共通する問題点に気が付いた。
- ユーザとユーザが達成を望むものを重視したユーザストーリのために，ビジネスニーズが簡単に忘れ去られてしまう。
- ユーザストーリは短期的であるため，アプリケーションの全体仕様が軽視されやすい。
- ユーザストーリに基づいた受け入れ基準は，それが短期間であることなどの理由から，品質面の要求が低過ぎる場合が多い。
- アジャイルのツールボックスには，解決すべきビジネスニーズの発見を支援するツールが欠けている。
- テスト駆動開発(Test-driven development, TDD)は一般化したが，機能実装の正しさではなく，詳細部分のテストに終始することが少なくない。
Smith氏の経験では，これらの問題の解決に有効なのはBDDであり，特に例による仕様(Specification by example)とインパクトマッピングである。
氏が実践する簡単な変更のひとつは，ユーザストーリのテンプレートをBDD形式のフォームにすることだ。これによってビジネス価値への注目度が高まり，常に議論の対象とすることが可能になる。
<役割>として<実現する利益>のために，私は<機能>を希望する
BDDでは，あいまいさを最小限にするため，具体的な例を強調している。これらの例は共通理解の構築に役立つだけでなく，不足している機能の発見にも有効であり，さらに受け入れ基準の記述にも利用することができる。形式言語であるGherkinを使用して記述すれば，例に基づいたテストの自動実行も可能だ。
ソフトウェア開発に共通する課題は，正確なドキュメントの作成である。BDDでは機能を重視し，振る舞いを例で説明するので，これをドキュメント作成の自動化に使用することができる。実際の機能と同期が可能なことから，生きたドキュメント(living documentation)と呼ばれることもある。
BDDには多くの価値がある反面，注意すべき潜在的な欠点も依然として残っている，とSmith氏は考えている。
- BDDはユーザインターフェースには不向きなため，プロトタイプなど他のツールと連携してインターフェースの設計が適切であることを確認する必要がある。
- 記述された例からテストを生成するツールは数多くあるが，どのテストをいつ実行するのかを管理するためのツールが不足している。
- 優れた自動テストスイートの開発は難しく，短期的には高価である。
Smith氏は最後に，BDDはまだアイデアとして日が浅く，アジャイルと関連するためのエコシステムが不十分であることを指摘して，自身の結論としている。しかし同時に，ソフトウェア開発時のコミュニケーションの向上を支援する上で，正しい方向への一歩であるとも考えている。BDDの本質を強調するために，氏は，BDDを生み出したDan North氏のことばを引用する。
BDDとは，例を通じてコラボレーションと発見を促すためのメカニズムに他なりません。
この記事を評価
- 編集者評
- 編集長アクション