BDDはアジャイルに向く ― アジャイルコーチから見たBDD

振る舞い駆動開発(BDD)は品質向上や、テスト自動化の役に立つアプローチです。またアジャイルなソフトウェア開発やプロダクト開発に取り入れるのもとても有効ですが、期待できる効果は少し違ったものになります。本記事ではアジャイルコーチとして、アジャイルなチームにBDDを紹介するという立場で、働きや効果について考えてみます。

なおBDDについての素晴らしい解説をブロッコリーさん(風間さん)が執筆されています。BDDとはなにか、基本から使い方まで丁寧に説明されているので、ぜひそちらを参考にしてください。本記事では、TDDとの違い、SbE、「発見・定式化・自動化」のプロセスについて、理解されている前提で書いていきます。

TDDとBDD/ATDD(1)　TDDはテスト手法ではない

コミュニケーションツールとしてのBDD

BDDは「機能を開発する前に振る舞い(テスト)を書く」という点でTDD (テスト駆動開発) に似ています。何を実現すればいいのか、どんな機能が求められているのか、明らかにしてから作業を進めるというものです。作るものを具体的に決めるので、ゴールが明確になり、作るものがブレたりムダなことをしないというメリットがあります。

同時にBDDは利用者やビジネスユーザーといった、開発者ではない人、すなわち使う人の観点から望ましい振る舞いを定義します。同時にその定義を開発者や技術者、すなわち作る人から見ても自明なように書き下すという、コミュニケーションを促進するツールという側面があります。

アジャイルな開発においては使う人と作る人の意思疎通が欠かせません。アジャイル宣言の背後にある原則にもあります。BDDはそこを強化する効果があるわけです。

ビジネス側の人と開発者は、

プロジェクトを通して日々一緒に働かなければなりません。

アジャイル宣言の背後にある原則

使う人がほしいものを表現したり、作る人が作るものを記述するやりかたはたくさんあり、BDDはそのひとつです。BDDには特に、以下のような強みがあります。

• 使う人と作る人が一緒に働く場を提供する
• 成果物である定式化した振る舞いが、使う人と作る人の共通の言語で表現される
• 振る舞いをそのまま自動化でき、テスト資産になる

使う人と作る人が協働して進めるBDDは、以下のステップで進みます。

1. 多様な利用者や開発者が協力して、ほしいものを「発見(Discovery)」する
2. ほしいものを具体的に「定式化(Formulation)」する。開発者にとっては達成すべきゴールとなり、利用者にとっては実現を約束された内容になる
3. 開発者は、自分たちが作ったものがゴールを満たすか客観的に判定できる
     (「自動化(Automation)」すれば判定が圧倒的に容易になるが、必須ではない)
4. 利用者は開発者が提供したものを確認するとき、約束は満たしていると信頼できる。そのため他の点を確認すればよくなる
     (自動化は必須ではないが、されていれば約束通りかどうか信頼しやすくなる)
5. 利用者の期待と異なる点があったら、そこから新たな「発見」につながる

約束は”契約“と呼んでもいいかもしれません。ひとつの機能の一部だけかもしれませんが、作る人が作るもの、使う人が受け取るものについて双方が守るべき”契約“です。この考え方を広げて適用すると、ATDD(受け入れテスト駆動開発)に近づいていきます。

複数のメンバー、とりわけ異なるスキルや背景を持った人々が協調するのがアジャイルの要諦です。BDDはそこに効きます。一般に要件定義と呼ばれるプロセスを、協調作業にできるのです。モブプログラミングあるいはモブワークのやり方も向きます。

協調し会話するためには、お互いに通じる言葉がないと不便です。様々な立場の関係者が共通の語彙として使えるユビキタス言語があれば、効果的な会話ができます。BDDのテストはユーザーの言葉で記述し、開発者がそれを実装の言葉に翻訳するので、自然とそこにユビキタス言語が作られていきます。

開発者どうしのコミュニケーションにもBDDが役に立つ

BDDで振る舞いを定式化して記述すると、開発のゴールができあがります。開発者がチームとして協力するとき、ゴールがはっきりしていると作業計画づくりをしやすくなり、分担や連携の切り口もわかりやすくなります。振る舞いが一連の操作をシナリオとして表現していると、どれだけ完成したか進捗も把握しやすくなります。

開発しているプロダクトが複数のレイヤーで構成されていると、開発者もレイヤーごとに担当を分けることが多くなります。ユーザーから見た振る舞いはすべてのレイヤーを縫い合わせるように動作するため、担当者同士の連携ポイントを提供します。一部のレイヤーの開発が進んだり遅れたりしていても、すぐに気がつけるわけです。

またレイヤーごとに開発するとき、レイヤーごとに単体テストをするためのテストケースやテストデータが必要となります。担当者それぞれに適当なデータを作ると、認識違いや検討漏れが出る場合があります。BDDの振る舞いに具体的な値を含めておけば(SbEのアプローチ)、共通のテストデータができます。SbEについて、詳しくはブロッコリーさんの連載の第3回を参照してください。

TDDとBDD/ATDD(3)　BDDとATDDとSbE

BDDで表現する要素としない要素

BDDでは振る舞いとして作るもののゴールを表現できます。ただしBDDでは捉えにくいものもあります。以下に、BDDで表現できる要素と表現しにくい要素を整理しました。

表現しにくいものは、別の方法でゴールを記述したり共有したりする工夫が必要になります。頑張ればBDDで実現できるかもしれませんが、おそらく他にもっと効果的な方法があります。自分たちのプロダクトと状況に合わせて、BDDが向くところを選ぶようにします。

試行錯誤をコントロールするBDD

アジャイルな開発に限らず、スピードを重視して開発しているとき、ムダなことはやりたくありません。使う人の要望が分かりきっているならそのまますぐに作りたいですし、不確実性が高いなら試行錯誤を効果的かつできるだけ頻繁にやりたくなります。望まれていないものを作るのはムダです。不確実性が高いときには試したいポイントが不明瞭だとムダが発生しやすく、またコミュニケーションやドキュメントも余分に過ぎるとムダになります。

分かりきっていることはどう表現し、伝えればいいのでしょうか。試行錯誤するとき、何を試すのかはどう表現するのでしょうか。ここでBDDが使えます。

BDDで振る舞いをテストケースとして定式化します。ここに書かれているのは、求められていることです。ここには書かれていないこともたくさんあります。それは都合よく解釈すればいいのです。都合よくというのは、ランダムや勝手ではありません。いまの状況で求められている通りにしつつ、開発者にとって最もムダがないようにするのです。

業務システムのデータ入力機能なら、決まり切った項目をすべて正しく登録できるという、たくさんのステップを書いたテストになります。すべてのデータ項目を網羅しないといけないし、バリデーションもテストしたいでしょう。

いっぽう、ECサイトの商品検索にAIを組み込む機能開発を考えてみると、話が違ってきます。おそらく実証実験段階で、さまざまな使い道とその実現可能性を検討したいはずです。このときBDDでテストしたいのは1テストケースでひとつの点のみです。「関連する商品がヒットする」「文意を汲んで結果に反映する」「売りたいものが上位に出る」などを確認したいわけです。検索の細かな手順や例外系、異常系は、今は関心の対象外です。関心がない点は、作る人が都合よく、早く出来上がるように作ればよい。エラーになったらクラッシュしても構わないわけですね。

一発で完全な品質の完成品を狙うのなら、そのように作ります。試行したい要素以外は関係ないのであれば、できるだけ省略し簡素にすませます。こうしてムダを省きます。その度合いを、定式化した内容の詳細さや網羅性でコントロールできるというわけです。

定式化した振る舞いを、約束や契約として考えるという話をしました。品質の高いものが求められるなら、網羅的で細かい点まで記述した契約になるでしょう。試行錯誤の一環でとにかく早く試したいなら、その試すこと以外は契約に含めず、大部分を開発者の裁量に任せる簡潔な契約になるでしょう。

約束や契約と言われると、詳細まで完璧に網羅するのが正しいという気がします。しかしコミュニケーションツールとして考えれば、そのときどきに応じて伝えたいことを適確に伝えるのが正しい使い方になります。協調するのに必要十分な詳細さ、あるいは曖昧さを選んでください。

このこともアジャイルソフトウェア開発宣言にありましたね。

契約交渉よりも顧客との協調を

アジャイルソフトウェア開発宣言

本当にBDDのほうがスピードが出るのか

スピードを求めるときBDDが役に立つと書きましたが、これは本当でしょうか。状況による、というのが答えになります。考え方として、いまの(BDDを用いない)やり方と、BDDを用いるやり方を比べて、ムダが少ない方が速いわけですね。ではいまのやり方にどんなムダがあるのか、それがBDDでは減るのか、プラスBDDで発生するコストはないか、検討することになります。

いちばん典型的で分かりやすいのは、手戻りのムダでしょう。開発者が作ったものが、利用者の思ったものと違ったり、実際に使ってみると問題があって、作り直さないといけない。これが利用者と開発者のあいだのコミュニケーション不足に起因するものなら、BDDで不足を補えるチャンスがあります。BDDの発見プロセスに利用者と開発者の両者が参加するのでコミュニケーションそのものの労力は増えますが、そのおかげで手戻りや作り直しが減れば、トータルでペイできそうです。

利用者がほしいものを説明できない、言語化に苦労するような場合には、BDDやSbEのアプローチで楽に記述できるかもしれません。抽象的な仕様をMECEに書き下すのにはそれなりのスキルや経験が必要なので、そのせいでコミュニケーションのムダが発生しているなら、BDDで効率化できるかもしれません。

作りすぎのムダも、BDDで減らせるかもしれません。一般的な仕様書の書き方では「このときはどうなってもよい」「ここは好きにしていい」とはあまり書きません。そうすると、どうなってもいいんだけどな…と思いつつ、何か決めて仕様書に書くことになります。作る人から見ると、仕様書に書いてあればすべてかならず実現するしかありません。選択肢はありません。

このとき、もっと低コストで実現できる仕様にすればムダが減ります。開発者はいちばんムダの少ない実現方法を選べるかもしれません。また、今の時点では不要な部分を実装しないですませれば、これもムダを減らせます。「任せる」や「今はどうでもいい」という表現、コミュニケーションを許容するために、BDDが役に立つかもしれません。

すべての機能をBDDで作ろうとすると、コストがかかりすぎるかもしれません。仕様を表現する方法はBDDだけではないので、今のやり方で十分ムダなく作れるなら、BDDを選ぶメリットはないかもしれません。上記のムダが発生しそうな箇所のみBDDを適用すれば十分です。機能で選ぶ手もあるし、仕様を把握しているのが誰かによって選んでもいいでしょう。テストを記述したり自動化するのが得意な人が担当する部分だけBDDにする作戦もあります。

BDD≠E2E

BDDで「自動化(Automation)」まで取り組むならば、自動化のコストも重要な要素です。TDDに比べるとBDDのほうがテストを実行するためのレイヤーが増えがちで、インフラや仕組みなどを準備して自動化にこぎ着けるまでの作業は多くなります。また個々のテストを自動化する際も、ステップ実装まで含めた手間がかかります。テスト自動化によって開発工数全体を削減しようと思うと、BDDはハードルが高いかもしれません。

BDDは使う人の観点からふるまいを記述するので、テスト自動化のテクノロジーとしてはE2Eテストになりがちです。しかしE2Eテストは実装やメンテナンス、また実行コストも高くなります。BDDだからといってE2Eテストにする必要はないと、頭を切り替えましょう。ビジネスロジックに関する振る舞いであれば、ロジックを実装している箇所のユニットテストとして実現できるかもしれません。シナリオテストであれば、バックエンドのAPIテストで十分かもしれません。

おわりに

BDDのプロセスの最初に「発見」があります。BDDをコミュニケーションツールと考え、ここを使う人と作る人の協調作業にするのが、とりわけアジャイルな開発におけるBDDの大きなメリットです。シフトレフトという言葉で考えれば、「仕様を考えるところ」まで左に持って行くことになります。逆に言うと、仕様が決まった後でBDDを利用するのでは大きなメリットを捨てることになります。

BDDの定式化で書く内容を増減して作る内容をコントロールできます。しっかり書けばしっかり作ることになり、軽く書けば軽く作れるので、いま現在大事なことにフォーカスしやすくなります。もちろん最終的にはすべてを完全な品質で作るわけですが、いま必要なことをいまやり、後でやればいいことを後に回して、時間を味方につけるのがアジャイルな計画づくりです。

アジャイルコーチからアジャイルチームにBDDを紹介するという内容で、本記事を書いてきました。BDDがみなさんのセンターになったら嬉しいです。