The BDD Books – Discoveryがすごく良かったので、本の概要といいなと思ったところを紹介するよ

The BDD Books - Discoveryという本を読んだのですが、今の自分にすごく刺さりました。今回はこの本の概要と、いいなと思ったところを中心に紹介します。

目次

The BDD Books - Discorveryの概要

最初に、本の概要を簡単に紹介します。なお、翻訳者、推薦者の方の紹介ブログもあるので、こちらも読んでみるとより一層内容を掴みやすくなるでしょう。

• BDD/ATDDを学ぶ上で最適な書籍『The BDD Books - Discovery』を翻訳して出版しました！ - ブロッコリーのブログ
• 『The BDD Books Discovery』はQAにも開発者にもPOにもPMにもとにかくみんなに薦めたい - テストウフ

目次は以下のようになっています。

• 第1章 BDDとは何ですか？
• 第2章 構造化された会話
• 第3章 具体例とは何ですか？
• 第4章 誰がいつ何をするか
• 第5章 ビジネスチームのメンバーを参加させる方法

第1章では、BDDが出てきた背景や歴史を踏まえて、BDDは何であるか？何とは違うか、などが紹介されています。その上で、今回はBDDの最初のプラクティスである「発見(Discovery)」に焦点を当てられています。

第2章・第3章では、実例マッピングの説明です。実例マッピングについては、翻訳者のブロッコリーさんのスライドがこれまた非常に分かりやすくてオススメです。

第4章は、BDDの各種活動を、例えばスクラムではどういうタイミングで誰が行っていくか？の説明があります。

第5章は、BDDという解決策からではなく、BDDがどういう問題を解決するかに焦点をあて、そこからビジネスチーム（POなど）とどう協調していくかについて触れられています。

いいなと思ったところ・刺さったところ

BDDを「発見」「定式化」「自動化」に分解することによって、理解しやすくなった

本書では、BDDを「発見」「定式化」「自動化」の3つのステップ・プラクティスに分解しています。

翻訳者・推薦者の方も述べてますが、BDDはCucumberといった「自動化」だけでもないし、Given/When/Thenといった「定式化」だけでもないよと説明されています。また、実例マッピングなども踏まえて「発見」のプラクティスを単独で使うだけで、ソフトウェア開発活動を大幅に改善できるとあり、この点はいいなあと感じました。

（ここでも、翻訳者のブロッコリーさんの発表資料から、該当のプラクティスの説明部分を引用させてもらいます）

また、上記のBDDのプラクティスを含めた、開発のサイクルが例示されています。この開発サイクル中で、タイミングや担当者も説明があったので、一覧で見やすいように表形式に起こしてみました。

	活動	内容	タイミング	担当者	結果
#1	ユーザーストーリーを選ぶ	要件を引き出し、優先順位を付ける	要件ワークショップの前（できれば1日前まで）	プロダクトオーナー、ビジネスアナリスト、顧客、主要なステークホルダー	関連するビジネスルール（受け入れ基準）を定めた、ユーザーストーリーの候補になる
#2	要件ワークショップ	ルールと具体例に焦点を当てて、ユーザーストーリーについて議論する	プロジェクト全体を通して定期的（週に数回、短時間のワークショップの開催がお勧め）	すべての役割（少なくともスリーアミーゴス：開発者・テスター・プロダクトオーナー）の代表が参加	候補のストーリーは洗練され、多くの場合、一連のルールと具体例を伴う小さなストーリーに分解される
#3	定式化	具体例をシナリオへ定式化する	ストーリーの実装が始まる前	最初、シナリオの表現に使用する言語とスタイルが軌道に乗りかけている段階では、チーム全員での実施がお勧め。慣れてきて、ビジネス担当者が成果物を積極的にレビューできるのであれば、開発者とテスターのベアで効率的に実施できる	ソース管理できるシナリオになる
#4	レビュー	シナリオをレビューする	シナリオが作成または変更されたとき	プロダクトオーナー	開発チームがビジネスの要件を正しく理解しているという自信が得られる
#5	自動化	テスト自動化のコードを記述して、シナリオを自動化する	実装開始前に実施	開発者またはテスト自動化の専門家	ローカル環境とCI/CD環境の両方で実行できる自動化シナリオのセットが得られる
#6	実装	アプリケーションコードを実装して、自動化したシナリオが成功になるようにする	最初のシナリオが自動化されるとすぐに開始	開発者	規定通りに振る舞う、動いているアプリケーションが得られる
#7	補足的なテスト	テスト戦略で説明している、手動およびその他の形式のテストを実行する。これには、スクリプト化されたテスト、手動テスト、探索的テスト、パフォーマンステスト、セキュリティテスト、またはその他のテストが含まれる	シナリオが完了するとすぐに、テスト活動を開始できる	テスター	高品質の動くアプリケーションが得られる
#8	リリース	出荷可能なインクリメントを生成する	すべてのテストが成功したとき、特にイテレーションの終了時に実施	リリース可能な成果物の作成は開発チームが担当するが、実際のリリースパッケージを作成する専門チームが存在する場合がある	インストール可能なリリースパッケージが得られる

今回は「発見」をテーマとした本ですので、#2：要件ワークショップが主な箇所です。発見のフェーズでは、要件をよりよく理解して、プロダクトオーナー/開発者/テスター間の意思疎通・共通理解を育むことが目的です。なので、下記が注意点として挙げられていました。

• （同値分割法などの）ソフトウェアテストの網羅性を追い求め過ぎない
• できるだけ平易な形式で記録すべきで、Given/When/Thenは使用しない

（もちろん、#2ではやらないだけで、#3以降でやる想定です。ここは、本の続編に書かれていそうなので、期待してます）

また、「スクラムならば、リファインメントのタイミングで#2をやるといい」といったアドバイスもあり、タイミングがイメージしやすくなりました。

BDDという解決策から入るのではなく、BDDが解決する問題に着目できた

今まで、BDDは何となくよさそうぐらいには感じていたのですが、「BDDを導入したら、どう嬉しいの？」に対してちゃんとした回答を持てていませんでした。まさに、本書で提示されている落とし穴に陥っている状態です。

日常業務に BDD を取り入れると、実例マッピング、定式化、自動化を強調する方法でプロダクトオーナーに説明することができます。または、第 4 章「誰がいつ何をするか」で行ったように、 BDD をプロセスとして説明することもできます。

この方法がうまくいくこともありますが、このようにして BDD を提示しても、ビジネスチームのメンバーと話すときにはあまり魅力的には映らないようです。問題は、私たちが日常的に遭遇する問題と似ています。つまり、問題自体ではなく、解決策に焦点を当ててしまっていることです。 BDD は、問題の解決、開発効率の向上、そしてより良い結果の手助けにならない限り、価値がありません。

本書では、BDDが解決可能な典型的な問題がいくつか挙げられています。自分が、これだ！と思ったものは、以下の問題です。

• a. プロダクトオーナーに負荷がかかりすぎている
• b. 本番環境での問題がいつものことになっている

a.については、意識したことなかったのでなるほどと思いました。「負荷がかかりすぎている」のに、「BDDのような新しい取り組みを導入したら、より一層負荷がかかるのではないの？」という疑問を思ったのですが、そうではないとのこと。

実例マッピングなどを用いて、適切に構造化された会話行えるのであれば、共通理解の促進やコミュニケーションの効率がよくなる。それによって、スプリント中に開発者からプロダクトオーナーにアドホックな質問を減らせたり、ストーリーの詳細化を開発者たちに移譲できる、という流れになるという説明がありました。

b.については、分かりやすいメリットだと思ってます。本番環境での問題が起きる原因が、「要件の誤解」にあるのであれば、そこを埋めるためのBDDという手法は上手くマッチする場面も多そうです。

BDDのサイクルを基に、テストに関する今までの取り組みを体系的に整理する機会となった

テストに興味が出だしてから、チーム内でもいくつか取り組みはしていたのですが、各種取り組み・プラクティスがどういう位置づけかを自分の中でも整理しきれていない状態でした。なので、この機会に、上述した開発サイクルの図を照らし合わせてマッピングしてみたのが、下図になります。

（実例マッピング以外の、図吹き出し内にあるテストの取り組みは、弊社伊藤さんのこちらの資料で紹介しています）

自分の中で、全体像と各取り組みの位置づけが整理できたことによって、「この現場・この状況では、どこを重点的にやるといいかな？」が、捉えやすくなりそうです。

---

The BDD Books、今回は「発見(Discovery)」ですが、これだけでもだいぶお腹いっぱいになるぐらい満載でした。これは、続編の「定式化(Formulation)」と「自動化(Automataion)」も楽しみですね。

なお、本家の公式サイトでは、英語ですがFormulationまでは出ているので、目を通してみるのもいいかもしれません。