BDD (Behavior-driven Development) について

最近BDD (Behavior-driven Development) についてエンジニア仲間で話題になったので、記事を書こうと思い立ちました。

結論から言うと、筆者は、BDDには懐疑的な立場です。

BDDとは(あくまで筆者の理解)

BDD (Behavior-driven Development)は、
ビジネス側が書いたシナリオ(誰が、どんなとき、どの条件で、どうしする)や仕様をもとに、コンピュータで実行可能なテストを自動生成し、システム側がそのテストを通るようにシステム開発をしていく方法です。ビジネス側がBehaviorを書く際の言語は、ビジネス側でもできるだけ理解できる自然言語風の、BDD専用言語です。

BDDのメリットは、

1. ビジネス側の仕様記述から、システムテストを作成できるので、ビジネス側の望んでいるシステムを素早く正確につくれる
2. ビジネス側の仕様変更がダイレクトにシステムテストに反映されるので、仕様変更にも強い

ことかと思います(筆者の理解)。

筆者がBDDを支持しない理由

１番目の理由は、そもそもビジネス側の期待している振る舞い (Behavior) 自体が曖昧で、それを論理的に整合性のある仕様に落とし込むことが、システム開発で最も困難な場合が多いと感じるからです。

ビジネス側の期待している振る舞いが簡潔で、論理的であればあるほとプログラムとして記述しやすくなるはずなので、その場合は、システム側だけのTDD (Test Driven Development) 方式で開発を進められると思います。

BDDの記述方法も所詮は論理記述の一種なので、それが綺麗に書ける人はそもそも、エンジニアとしての才能があるので、普通に綺麗な仕様を書ける場合が多いのではないでしょうか。

２番目の理由はBDDの記述言語です。
自然言語風にするのはいいのですが、自然言語に近づければ近づけるほど、論理の矛盾や文法チェックが必要になり意味解釈が面倒になると思います（自然言語処理が簡単であれば、自然言語処理という研究分野は存在しないはず）。

もちろんBDDの記述言語はプログラム言語を自然言語風にしたシナリオ記述言語なので、意味解釈の面で問題が出ることはないと思います。
しかしそうすると、BDDの記述言語には表現に制約があり、最終的な表現の制約はプログラミング言語と同等の制約となるはずです。ビジネス側の担当者は、制約があるゆえに、無理にBehavior記述しようとしてBDDの記述言語に対して煩わしさを感じるかも知れません。
結局、BDDの記述言語以外にも資料が必要になり、BDD導入前とシステムの開発スピードや維持コストは下がらなくなってしまうことになりかねません。

逆にシステム側でプログラミング言語に熟達している人であれば、BDDの記述言語を覚えるのは面倒以外の何物でもありません。

筆者には、BDDを記述は、「なんちゃらツクール」といったプログラムを書かずにゲームを作れるツールやゲームの「シナリオエディタ」を使う感覚が一番近いのかなと感じました。

筆者は、プログラミング言語が、あの限られた表現制約の中で、多様なシステムを生み出す能力に感心しています。また逆に、あれだけ制約のあるプログラミング言語ですらも、いわゆる「クソコード」が生み出してしまうことに、いら立ちを感じることもあります。

終わりに

人間は非論理的な生き物であり、コンピュータは完全に論理的なものだと、（少なくとも筆者は）思っています。
現状のシステム開発では、「ビジネス側の矛盾も混じった要望」と「コンピュータの求める論理的完全性」の整合性をとるのが、最も難しい部分であり、その整合性をとることのできるシステムを構築できる人が、「優秀な技術者 (エンジニア/設計者/プログラマ)」なのではないかと思います。

恐らく、AIが発達して、ビジネス側の書いた仕様書、スライドを掘り込むと、システムが完成するレベルになるぐらいでないと、BDDはメリットがないと思います。(でもそこまで言ったら、既にBDDではないかもしれませんね。)