はじめに
前回は、BDDを構成する3つのプラクティス「発見(Discovery)」「定式化(Formulation)」「自動化(Automation)」の概要を紹介しました。
今回以降は、第1回の記事でも用いた自動販売機を題材にして、前回の記事で紹介した、「BDDを用いたプロセス」を行ってみます。
本記事では、「発見(Discovery)」の部分までを、具体例を交えつつ説明します。
1. ユーザーストーリーを選ぶ
ユーザーストーリーマッピングなどを用いて、予めユーザーストーリーを作成しておきます。
そして、次Sprint以降で開発する可能性が高いユーザーストーリーをピックアップします。
今回は、自動販売機に関する以下のユーザーストーリーをピックアップします。
タイトル：顧客が自動販売機で飲み物を購入する
As a：顧客の立場で、
I want：自動販売機から飲み物を購入したい
so that：店舗に行かなくても飲み物をすぐに得られるように2. 要件ワークショップ
1で選んだユーザーストーリーに対して、要件ワークショップを行います。「要件ワークショップ」という言葉は、組織によっては「リファインメント」「スリーアミーゴス」などと呼ばれたりします。
「発見(Discovery)」のフェーズでもある要件ワークショップでは、ドメインを構造的に理解していく協調作業を行います。その際には、明確な具体例を使用することが重要です。
要件ワークショップでは色々なやり方があるのですが、今回は実例マッピングを用いてみます。
実例マッピング
発見(Discovery)を行う活動として「実例マッピング(Example mapping)」というものがあります。
詳しいやり方については、実例マッピングの考案者であるMatt Wynneが説明している「Introducing Example Mapping（邦訳：受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」）」や、私が解説しているスライドや記事を参照ください。
ここからは、今回の題材である「顧客が自動販売機で飲み物を購入する」というユーザーストーリーに対して、実例マッピングを作成していきます。
手順0. 対象のユーザーストーリーを記載する
対象のユーザーストーリーを黄色の付箋で貼ります。
手順1. 具体例を1つ記載する
手順0で記載したユーザーストーリーを行うような具体的な例を考え、緑色の付箋で貼ります。例えば以下のような感じです。
例えば以下のような感じです。
手順2. 具体例が成立するためのルールは何か考える
手順1で緑の付箋に書いた具体例が成立するためにはどのようなルールがあるか考えます。
もしも思いつかない場合は、別の具体例（緑の付箋）を書いてみると良いかもしれません。
今回の場合、以下のようなルールが考えられそうです。
- 自動販売機に投入できる硬貨がありそう
- 選んだ飲み物は出てきてほしい
- 飲み物を買うとお釣りが出てきそう（連続購入はできなさそう）
これらの考えを元に青色の付箋を記載していきます。
手順3. 文章のリファクタリングを行う
実例マッピングを書いていく中で、言葉が揃ってないことに気付くことがあります。その際はTDDでのリファクタリングと同様に、言葉のリファクタリングをしていきましょう。
例えば今回の場合、以下のようなことが気になりました。
・「購入する」と「買う」という単語が存在している。どちらかで揃えられそう。
・「買う」という言葉自体が、どのような振る舞いを表しているのか分かりづらい。何をもって「買う」という状態を表すのかはっきりさせた方が良い
これらを元に、実例マッピング内に書いた文章をリファクタリングした結果が以下の通りです。（太字＋下線が変更した部分）
手順4. ルールを簡潔に表現している具体例を書く
手順3で作成したルール（青色の付箋）を簡潔に表現できる具体例（緑色の付箋）を記載します。
例えば、以下のような感じです。
手順5. 疑問点が出てきたら、赤い付箋で残しておく
実例マッピングを作っていく際に、その場では解決できないものが出てきたら、疑問点として赤い付箋に残しておきます。
例えば、以下のように置きます。
疑問点は疑問点として書き出しておき、要件ワークショップの時間や頭のリソースを疑問点の解消に費やさないことが大切です。
手順6. 手順1〜5を繰り返す
ここまで説明した手順を繰り返します。
なお、手順通りの順番でなくても良いです。例えば、文章のリファクタリングは都度行っても良いですし、ルール（青色の付箋）を最初に書いて、ルールを表現する具体例（緑色の付箋）を書いても良いです。
実例マッピングを行うことのメリット
実例マッピングを行うことで色々なメリットがあります。
メリット1. 「Unknown unknowns（知らないことを分かっていない）」ものが明確になり、他の状態へシフトできる
前回の記事で紹介したラムズフェルド行列において、今まで、どんなことが「Unknown unknowns（知らないことを分かっていない）」状態（ラムズフェルド行列の右下）だったのか明確になります。
疑問点として赤い付箋に残しているものは、「Unknown unknowns（知らないことを分かっていない）」状態から「Known unknowns（知らないことを分かっている）」状態（ラムズフェルド行列の右上）へとシフトできています。
また、具体例として青い付箋に残しているものは、「Unknown unknowns（知らないことを分かっていない）」状態から「Known knowns（知っていることを分かっている）」状態（ラムズフェルド行列の左上）へとシフトできています。
メリット2. 開発開始までに解決しなければならない課題が明確になる
疑問点（赤い付箋）が解決しないまま開発開始しようとする行為は、要件が固まっていないまま開発開始を試みているのと同義です。
開発開始前にPOやビジネス関係者と話し合って、赤い付箋の解決に向かうべきという指針を立てることができます。
メリット3. ユーザーストーリーやルールの大きさが適切か把握することができる
今回の例では、青い付箋が3枚程度、緑の付箋も最大で3枚程度になりました。
しかし、これらの付箋の枚数がもっと多かったりすると、ルールやユーザーストーリーの内容を再考した方が良いということが分かります。
例えば以下のように、緑色の付箋が非常に多くなってしまった場合。
これは、いくつもの具体例を示すことで、やっと1つのルールを表現していることになります。つまり、それだけルールが複雑になってしまっていることが示唆できます。
このようになってしまった場合は、複雑になっているルールをいくつかのシンプルなルールに分けることを検討しましょう。
別の例として以下のように、青色の付箋が非常に多くなってしまった場合。
これは、いくつものルールを用いることで、やっと1つのユーザーストーリーを表現していることになります。
このままですと、ユーザーストーリーが複雑であるため、プランニングの際に考えるストーリーポイントも大きな数になる恐れがあります。
このようになってしまった場合は、ユーザーストーリーをいくつかの小さなユーザーストーリーに分けることを検討しましょう。
メリット4. ルール（青い付箋）は受け入れ基準として使うことができる
ルール（青い付箋）は、Scrum等でよく使われる「受け入れ基準(Acceptance Criteria)」に転用が可能です。
例えば、今回の自動販売機の例の場合、青い付箋で書いた以下のものが受け入れ基準の候補となります。
- 自動販売機に投入できる硬貨が決まっている
- 選んだ飲み物が自動販売機から出てくる
- 飲み物を買うとお釣りが出てくる
おわりに 〜協調作業を伴う「発見(Discovery)」はBDDで最も大切〜
今回は、要件ワークショップの中で行う「発見(Discovery)」のプラクティスとして実例マッピングを紹介しました。
前回の記事でも書いたように、協調作業が行われる「発見(Discovery)」がBDDの中で最も大切です。
またここまでの説明から分かるように、「発見(Discovery)」のフェーズにおいて、「自動テストを書くかどうか」は全く論点ではありません。
一旦、自動テストのことは頭の片隅に置いておいて、ビジネス関係者と協調することを大切にして「発見(Discovery)」のプラクティスを行ってみてください。
連載一覧
TDDとBDD/ATDD(1) TDDはテスト手法ではない
TDDとBDD/ATDD(2) 2種類のBDD
TDDとBDD/ATDD(3) BDDとATDDとSbE
TDDとBDD/ATDD(4) ツールとしてのBDDとプロセスに組み込まれたBDD
TDDとBDD/ATDD(5) BDDのプロセスその1「発見(Discovery)」と実例マッピング
TDDとBDD/ATDD(6) BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則
TDDとBDD/ATDD(7) BDDのプロセスその3「自動化(Automation)」
