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

連載第3回② で説明したこと、ルールや実例を定義する作業を、各担当者任せにしてよいわけがありません。これには賛同いただけるものと思います。ふさわしいメンバーを募って、ワークショップ形式で行った方が、質も効率も上がることは間違いないはずですし、共通認識を得たり、確認したりするためにも必要です。

これは言ってみれば要件ワークショップということになります。ビジネス側ステークホルダーの参加が必要ですが、リーディングするのはデリバリーチームということになるでしょうから、イテレーションのセレモニーのどこかに位置付けたりするとよいでしょう。

ワークショップ形式の中で前述してきた要求仕様や受け入れ基準の明確化、共通理解の形成を円滑に進めるのに、良いプラクティスがあります。

実例マッピング(Example Mapping)と呼ばれるもので、マット・ウィン(Matt Wynne)がブログ記事[1]で紹介したプラクティスです。それを引く形で書籍[2]の中でも説明されており、日本語にも訳されている[3]ので、ワークショップでの詳細手順はそれらを参照してください。

基本的に木構造で分解したり、組み替えたりするので、一人で作業するときにはマインドマップツールなどが便利です。ただし、ワークショップでやるとなれば、カードに記述して参加者皆で動かしながら検討するのがよいです。

上表（図表16）のように内容別にカードを色分けして使用します。「なぜその色なのか」という意味はありませんが、メンバーが入れ替わった時に驚かれないためには示された通りに用いた方がよいでしょう。

まず、出発点としてそのワークショップで取り扱うと決めているユーザーストーリーを1つ置いたところから開始します。30分以内で終わるようにします。もし終わらなければ、おそらく取り上げたストーリーがまだ十分に分解されていなくて大き過ぎるのかもしれません。あるいは、その場で議論しても答えを持っている人がいない課題の検討に入っているのかもしれません。いずれにしろ、その場にふさわしくない方向へ議論がいっている可能性が高いので、ワークショップは打ち切りましょう。

カード記載順が決まっているわけではありません。順次分解していくので何度も書き直しが必要になるのは避けられません。まず分かっている（つもりの）ルールは書き出しておくとよいでしょう。ルールを完全に理解していると思っていても、対応する実例は必ず記述しておきます。理由は本稿の最初で述べました。特にビジネス側ステークホルダーに、ルールが正しい事だけではなく、ルールに当てはまらない事例を思い出してほしいからです。実例を記載する際には3つの項目が含まれていること、検討しやすい項目順もすでに説明した通りです。実例マップは以下のように整理され、出来上がっていきます（図表17）。

次に、最終的なゴールイメージを持っていることは重要です。良いゴールイメージは下図（図表18）のように、青と緑が対になった状態です。また、青いカードは７枚程度までに収まっているとよいでしょう。横方向に青が大きく広がっているときは、黄色の分解が不十分な可能性が高いです。縦方向に長くなっているときは、青の分解が不十分な可能性が高いです。あるいは冗長な実例が含まれているということです。冗長な実例は削除しましょう。せっかく書いたのにとか、後でテストに使えるのでテスト数は多い方がよい、などとは考えないことです。

これはルールが変更になった際などに、冗長な実例があると、それを保守するのにコストがかかるようになるからです。時間がたつと、それが冗長でしかなかったものなのか、ルールに対しての何らかの理由があって複数残してあるのかが分からなくなります。エッジケースやコーナーケースとして特別な意味があるので複数残したい、と考えたくなる場合もあるかもしれません。そのような場合も含めて、もし、複数の実例が別の意味を持つならば、ルールのところから分けられるはずなので、そのようにしましょう。実例を削除するときには勇気が要ります。実例やテストを増やすのは簡単ですが、減らすのは難しいです。1つずつ、よく検討しないと怖くて捨てられなくなってしまいますので、冗長なことがはっきりしたら、すぐに捨てましょう。これはTDDのプラクティス[4]と同じです。

ただし、ワークショップでこのゴールまで到達する必要はありません。ビジネス側ステークホルダーやプロダクトオーナーが興味を持っていないような粒度であると確認できたら、ファシリテーターはそこの分解は打ち切るとよいでしょう。要求仕様や受け入れ基準を明確にすることに徹するべきだということです。

ワークショップが終わった後に、残りの分解は誰かが担当し、デリバリーチームの中でレビューなどするとよいでしょう。

なお、検証や妥当性確認のためのテスト用の実例は、テスト方針や計画に基づき、別途テスト設計技法などを用いて系統的に導くべきであることを、くどいですがここでもう一度念を押しておきます。

BDDの中では、実例（あるいはそれを定式化してシナリオにしたもの）は、以下（図表19）のように2種類あると説明されることがあります[5]。

本稿で扱った実例は、理解を助ける(illustrative)の方になります。ディスカバリの後半で、システムの詳細な振る舞いを、実例の明示を通して、単一のルール（要件、受け入れ基準）として表現します。

一方、この粒度のものだけでは不十分で、ジャーニー単位のものも必要です。ジャーニーの実例やシナリオは、システムがどのように有用な結果をもたらすかを表現します。それはステークホルダーの誰もが、読めば十分に理解できる表現になっている必要があります。これも冗長になることは避けるべきで、その数は少数で済むはずとされています。

筆者としては、ジャーニーの実例やシナリオについては、実例マッピングではなくユーザーストーリーマッピングの方から導く方がよいと思っています。

似たものとしてテストの領域にシナリオテストがあります。テストの観点でごく一部が重なることがあるとは思いますが、繰り返しになりますが、BDDのプラクティスはその範囲のことを含んでいません。例えば、シナリオテストとしては次のようなものを含めたりもします。

エラーを起こすような操作と回復の処理をいくつもの機能に対して行う長いシナリオ

このシナリオは、一見回復しているように見えながら内部状態が十分回復されずに壊れたままになっているような欠陥を見つけるのに有効なわけですが、ジャーニーシナリオとは目的が全く違うことがよく分かる例です。

BDDの実例およびそのシナリオは、先に示した目的以外に、自動回帰テスト用としても用いられることになるわけですが、そこでもジャーニーシナリオを不用意に増やすことは避けるべきです。いろいろなルールに関係する長いものは保守し続けるのが大変になりますし、またそのようなシナリオが失敗した場合に、原因解明に時間を要するからです。このようにいろいろとデメリットがあるので、シナリオテストと同列扱いするのはやめましょう。

ここで、ユーザーストーリーと実例およびルール、ユーザーストーリーマッピングと実例マッピングとの関係を整理しておきましょう。名の知れた専門家の中にも若干混乱があるようです。

次のように主張している記事も見かけます。「ユーザーストーリーが日常の言語表現として自然なのに対して、この手法(BDD)の中で用いられる表現は不自然なものである(やはりユーザーストーリーの方が優れている)」。この連載の1回目では、ユーザーストーリーを使うこととジョブストーリーを使うこととの比較をしました※1。同じように、さらに実例およびルールを使うこととの比較を始めてしまいたくなるわけです。しかし、筆者は実例およびルールをユーザーストーリーやジョブストーリーの代わりに使うような前提で比較することは意味がないと考えています。相互に代替はできなくて、両方別のこととしてあるべきです。が、プロジェクトの置かれた状況によってはどちらかを省略できることはあり得るかもしれません。

もう一度筆者の意見を繰り返しますが、「相互に代替はできなくて、両方別のこと」であると考える理由は以下の通りです。

BDDは、ディスカバリー工程の中で、「まずは作り始める前にシステムや製品の振る舞い(Behavior)を正しく十分に定義したい」というところから出発するプラクティスです。システムや製品レベルの要求を定義しようとしているわけです。

アジャイルコミュニティーの人たちは、あまりこのレベル分けに特別の注意を払った説明をしていません[6]。ですが、示されているプラクティスやその目的を鑑みるに、ユーザーストーリーマッピングまでがユーザーレベルの要求の分析・整理・体系化であり、実例マッピングはシステムや製品、ソフトウェアレベルの要求を定義しようとしているように見えます。

以下にJIS X 0166[7]が示す「要件プロセスと仕様書の関係性の例」の図を示します（図表20、21）。ユーザーストーリーマッピングと実例マッピングがどの辺りに相当する活動および成果物を狙っているものなのかを確認してみてください。

筆者は、上表（図表21）のようなレベル分けを運用ルールに取り入れて徹底することをお勧めしています。そうすることで、ユーザーストーリーマッピングと実例マッピングのそれぞれの目的、使い分け方、目指すべき質が明確になり、運用しやすくなります。また、それぞれのアウトプットおよびその体系間の関係も明確になります。

両方のマッピングを行うことが、単なる重複でも無駄でもないと理解いただけたことでしょう。もちろん部分的には重複も起こり得ると思います。ただ、次の例のように、ほぼ同じ状況を検討している際にも、発見しやすいことが変わるケースは少なくないと思います。

財布の小銭が足りなくなる状況はユーザーストーリーマッピング中の方が発見しやすいですが、電子マネーの残高が足りない状況は実例マッピング中の方が発見しやすいはずです。なぜなら、財布の中を探すのは購入者ですから、硬貨が足りないことに先に気づくのはユーザーです。一方、電子マネーの場合は、ユーザーはいつもの通り支払い操作に進むため、決済システムの方が先に残高不足の状況を発見します。ユーザーレベルの検討をしているときには、ユーザーと同じ見落としが発生しやすいです。

どちら側で発見されるかに関わらず、それが結局これから作るものの振る舞いを変えることになるのであれば、漏れなく抽出されなければならないことに変わりはないはずです。どちらのレベルも怠れば、そのまま不備につながってしまいます。この小さく狭い範囲の状況の例でも確認いただけたと思います。

ところで、先にも述べましたが、BDDのエバンジェリストの中には、「ユーザーストーリーは要求ではない」と強調する人たちもいます。良いユーザーストーリーの評価基準としてINVEST[9]が広く知られていますが、そのNはNegotiableのNです。つまりまだ交渉可能なことが望ましいのだから要求ではないというのです。その一方、「あるストーリーに対応する開発が完成した時には、(当該のストーリーから作成された)全ての重要な情報がルールとシナリオに取り込まれている必要がある。」と説明しています。これはつまり、ストーリーを要求として受け取っていることを示してもいます。この場面ではユーザーストーリーによるユーザー要求を前提にして、基本的にはシステムや製品、ソフトウェアレベルの要求を明確にし、場合によっては交渉しているに過ぎないわけです。ですから、どちらも要求であるとみてよいでしょう。

ここで、上表の列タイトル「(表現の主語)」が括弧に入れてある理由を説明しておきます。それは、主語はこのように想定しますが、実際の表現には書かない方がよいからです。

まず、ユーザーレベルの方ですが、例えばConnextra Formatのユーザーストーリーで表現する場合、役割やユーザータイプを記述することになっています。それは主語の位置に書かれるのではありません。ですから、日本語の場合は普通に主語を省略していると思います。英語の場合も、動詞句だけでよいのです。しかし、英文として自然な表現にしようとすると省略できないので、主語が置かれていることもあります。Userや、IやWeなどが使われていることが多いように思います。特に意味のない主語を置いておくことで、例えば複数のペルソナを使用する場合、主語をそれぞれのペルソナに置き換えてしまえば自然に読めます。

次に、システムや製品、ソフトウェアレベルについてです。本稿ですでに説明した通り、ルールや実例（特に結果［Outcome］）は、「A（目的語となる名詞）をBする（動詞）」のような表現方法で定義するとよいでしょう。

なぜ、主語を書かないのでしょうか？それは伝統的に広く教えられてきた知恵なのですが、そのことについて触れると長くなってしまいますので、次回以降に説明することにします。

本稿で説明したのはBDDのプラクティスの一部です。ディスカバリー工程の主要な部分を説明しましたが、まだまだ説明しきれなかったプラクティスがあります。BDDの全体像については、BDD Booksのサイト[10]に公開されていますので、参考にしてください。

本稿を執筆することを通して、筆者自身も改めて確認できたのですが、BDDのプラクティスの多くはアジャイルであることとあまり関係がないようです。ウォーターフォールの現場にも無理なく取り入れられ、効果が期待できます。

従来のウォーターフォールとの違いは、コーディング直前までステークホルダーとのコミュニケーションを取り続けることを前提に仕組みが整えられている点です。もっとも、ウォーターフォールモデル自体がコミュニケーションを制限していたわけではありません。実際にはベースラインが確定した後、ドキュメント至上主義によりコミュニケーションが制限される現場が普通でした。これは契約形態に対応した合理的な態度でもあるため、契約形態も合わせて見直さないと、BDDのプラクティスはうまく機能せず、従来と同じ結果になってしまうことでしょう。

本稿が主に説明したディスカバリー工程の後、定式化と自動化のプラクティスもBDDには含まれているわけですが、それは主に(最初の)コーディング以降で効果が得られるものになっています。リリースし、使っていたただき、そこではじめて発覚したことによる必要な変更に対して、その仕組みは大きな効果を発揮するものになっています。

そういうわけで、BDDのプラクティスはディスカバリーまでとそれ以降の大きく2つに分けて、段階的に導入できますし、最初のディスカバリーの部分までを導入しただけでも効果が期待できます。その後の第二段階として、定式化と自動化のプラクティスも取り入れれば、これもアジャイルに限らず、ウォーターフォールの現場でも大きな効果が期待できます。なぜならば、ウォーターフォールの現場でも、派生開発が繰り返されることはよくあることだからです。

BDDは、アジャイルに限定されることなく、一度作ったものに対する繰り返しの変更や修正に強い開発手法であり、広く活用できるプラクティスを含んでいます。

BDDの導入に成功していれば、本格的にアジャイル開発に移行する準備もかなり整っているので、スムーズな移行が期待できると思います。

従来の安定したウォーターフォール開発を維持しつつ、アジャイルへの移行の準備を整えることになるため、リスクが低く、有効性が高いアジャイル移行方法の1つといえるのではないでしょうか。

※1) 筆者は連載の1回目で、ディスカバリーの前半辺りでの話としてジョブストーリーとユーザーストーリーを比較しているのであり、より上流のマーケティングの工程で使用する前提のジョブストーリーを別のもので代替するような比較はしていません。

[1] Matt Wynne, Introducing Example Mapping, https://cucumber.io/blog/bdd/example-mapping-introduction/, Accessed Feb 2, 2025.

[2] Gáspár Nagy and Seb Rose, Discovery: Explore behaviour using examples, BDD Books

[3] ブロッコリーのブログ【翻訳記事+α】受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」, https://nihonbuson.hatenadiary.jp/entry/ExampleMapping, Accessed Feb 2, 2025.

[4] TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング(1:56:45 リリースから3年後の世界（テストをメンテナンスしやすくする）), https://www.youtube.com/live/Q-FJ3XmFlT8?t=7005s, Accessed Feb 2, 2025.

[5] Seb Rose and Gáspár Nagy, Formulation: Document examples with Given/When/Then, BDD Books

[6] digitalsoul, BDDの導入 - Dan North, https://digitalsoul.hatenadiary.org/entry/20090819/1250686015, Accessed Feb 2, 2025.

[7] JIS X 0166:2021(ISO/IEC/IEEE 29148:2018)システム及びソフトウェア技術―ライフサイクルプロセス―要求エンジニアリング(Systems and software engineering -- Life cycle processes -- Requirements engineering)

[8] IIBA (著), BABOK: A Guide to the Business Analysis Body of Knowledge, Lightning Source Inc

[9] Bill Wake's original article: INVEST in Good Stories, and SMART Tasks, https://xp123.com/invest-in-good-stories-and-smart-tasks/, Accessed Feb 2, 2025.

[10] BDD tasks and activities, https://www.bddbooks.com/articles/bdd-tasks-and-activities.html, Accessed Feb 2, 2025.