はじめに

現在、AI駆動開発という言葉をよく聞くようになっていますが、いまのところのAI自体は「目的」をもたないので、あたかもAIが主導するかのようなこの表現は変です。この言葉はいずれ使われなくなるだろう、と私は考えています。

代わって、仕様駆動開発（Spec-driven development）に注目が集まり始めていると思います。
結局のところ、これが主流になるのではないか、少なくともこれが主流になったら良いな、と私は思います。

それはなぜなのかというと、BDD（Behavior-Driven Development：振る舞い駆動開発）やATDD（Acceptance Test-Driven Development：受け入れテスト駆動開発）を実践してきた現場では、特別なことをしなくても開発は自然と以下の図のような流れになり、それは仕様駆動開発と呼ぶに相応しいものになるはずだからです。

ただ、日本ではBDDやATDDは今一つ普及しておらず、何のことだかわからないということになると思いますので、本稿はそこを説明したいと思います。

現状のAI駆動開発は、ソフトウェア開発創世記に似ている

現状のガバナンスの効いていないAI駆動開発の現場を見ていると、ソフトウェア開発の創世記を思い出します。

ソフトウェア開発の創世記では、 「とりあえず動くものを作る」ことが優先され、詳細な設計や文書化、テストが軽視されました。これは、「動けばいい」という、極めて場当たり的で開発者個人のスキルに依存する手法でした。

要件や仕様が、関係者間の口頭のやり取りや開発者個人の頭の中に留まり、文書化されない、あるいは曖昧なまま進行しました（「暗黙の仕様」）。

規模の拡大とともに、共通認識やコミュニケーションのためのコストが問題になり、文書化の必要性・重要性が広く認識されることになりました。

しかし、その後もコードとドキュメントを別々に作成・管理した結果、変更が加えられるたびにドキュメントの更新が疎かになり、コードとドキュメントが乖離するような問題がつきまとっていたのです。

ここまで、歴史の話ですが、なんか似たようなことになっていると思いませんか？

試行錯誤は避けられない。しかし着地点のイメージを持っていることも大事

バイブコーディング(Vibe coding)にしても、例えばそれで従来よりもたくさんの人が手軽にプロトタイプを作れるようになになり、それを通してコミュニケーションの効率を向上させたり、相互認識を深めたり、そのようなメリットが得られることは確かです。上手く活用していきたいものです。

特に現在は過渡期ですから、AIの可能性や能力を十分に引き出す方法を探ることや、その限界を把握するようなことも大事な時期です。なので、能力的また機会的に、できる人からばらばらのやり方で挑戦するのも悪くないでしょう。それどころか、むしろ望ましいことです。

しかし一方、ある程度規模の大きい複雑なものを企業組織の中で開発していく際には、多くのステークホルダー間の合意を得る必要がありますし、その拠り所(要求仕様書)の存在が望ましいということになります。

さてそれでは、どういう要求仕様書が望ましいか？どんなルールやマナーに従って定義されているものが良いのか？と考えてみると、そこに相応しい有望な方法論が既に存在していることに気付きます。それがBDDのプラクティスです。

先に示した図で、オレンジ色で示した部分、「整形式(well formulated)の要求仕様または定式化(formulation)された実例およびルール、受け入れ基準」と、その周辺の活動が相当します。

ここがしっかりと定義されていれば、どういう良いことがあるかを先に説明します。

図の右側に示している通り、BDDのツールも含めた環境が構築・運用できていれば、テストの自動化が従来からできました。このテストは、十分な検証や妥当性確認を満たすような(例えばエッジケースやコーナーケースを漏れなく含むような)ものではありませんが、ビジネスルールなどを漏れなく一通りチェックできるようなものです。これにより、他の機能追加やリファクタリングなどの悪影響が出ていないことをいつでも簡単に確認できます。
要求仕様に対応する文書と実装コードが少しでも乖離したら、すぐにアラートが上がってくることになります。
このアラートに対処することで、文書と実装は常に一致するようになります。このような性質を持った文書をリビング(生きている)ドキュメントと呼びます。
逆に言うと、この仕組みのおかげで、機能追加やリファクタリングを安心して行えるようになるわけです。

では、その「整形式(well formulated)の要求仕様または定式化(formulation)された実例およびルール、受け入れ基準」は、どのような表現であるべきか？というと、次のようなものになっているべきだとされています。

ビジネス領域に根差した曖昧さのない用語を使って、システムに期待される振る舞いの共通理解を文書化する

実装する技術者チームと、ビジネス側のステークホルダーの双方が理解可能な表現になっていないといけません。
技術用語ではなく、ビジネス側の用語を使います。なおかつ、システム(人工物)に期待される振る舞いを曖昧さなく、抜け漏れなく定義するのです。

（ここで、BDDをすでにご存じの方は、「Gherkin構文（Given/When/Then）で定義しろってことね」と思うかもしれませんが、それはどうでも良いと考えています。
「Gherkin構文は変な英語で、あれは自然言語的表現ではない」と悪口を言う英語圏の著名な専門家もいますので、ましてや日本語では使う必要はないでしょう。)

次の3つ組をビジネス用語を使った自然言語で定義すればよいのです。

状況(Context): 初期状態（前提）
操作(Action): トリガ、イベント（操作）
結果(Outcome): 期待される結果（システムが満たすべき振る舞い）

これが質の良い状態でできていれば、あとの実装、コーディングは、誰がやっても区別がつかないものが出来上がるとされています。
つまり、AIに作らせても同じことが期待できるわけです。（「誰がやっても」と言ったって、「その担当の力量が不足していたらダメでしょ」というのは、AIでも人間でも、もちろん同じです。）

なので、先の図の右下部分は、AIが自動生成するような表現になっています。

右上のテスト自動化部分と右下のコード自動生成を独立したものとしておけば、かなり安心して任せられる仕組みになりそうだとわかっていただけるのではないかと思います。

まとめ

BDDのプラクティスから得られる、要求仕様書の定義のレベル（抽象度、粒度）、リビングドキュメント、テスト自動化などが、AI支援による仕様駆動開発の方法論の曖昧な部分を見事に補完してくれることを示しました。

少し補足しておくと、BDD（Behavior-Driven Development：振る舞い駆動開発）とATDD（Acceptance Test-Driven Development：受け入れテスト駆動開発）は、出自や系譜が異なるものなのです。しかし、現時点においては「実質的に大差ない」開発手法として捉えられています。少なくとも区別することで特に良いことはないです。

この方法論を成功させる重要な鍵は、「質の良い要求仕様定義」ができることです。先の図にも示してある通り、そこにもAIの支援を活用することができます。ただし、十分な質に到達しているかを評価、判断、見極められなければなりません。そこができて責任をとれることが、人間の技術者に求められることであり、できなければAIに置き換えられてしまうということになるのだろうと思います。

参考

BDD流の質の良い要求定義方法については、本稿では説明しませんでした。
以下の別稿にまとめてありますので、こちらも読んでいただけると嬉しいです。（会員登録が必要になってしまうのですが、無料で読めます。）

【連載】要求工学における「利用状況」の扱いをめぐる考察：アジャイルにもウォーターフォールにも効果的！振る舞い駆動開発(BDD: Behavior Driven Development)のプラクティス（第3回①）
【連載】要求工学における「利用状況」の扱いをめぐる考察：アジャイルにもウォーターフォールにも効果的！振る舞い駆動開発(BDD: Behavior Driven Development)のプラクティス（第3回②）
【連載】要求工学における「利用状況」の扱いをめぐる考察：アジャイルにもウォーターフォールにも効果的！振る舞い駆動開発(BDD: Behavior Driven Development)のプラクティス（第3回③）