はじめに（実例マッピングを紹介するに至った背景）
このブログで何回かお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。
leanpub.com
この書籍の中で、実例マッピング（Example Mapping）が紹介されています。
このプラクティスは大変素晴らしいものだと感じているのですが、残念ながら日本ではあまり知られていません。*1また、書籍の中では軽く紹介している状態です。
そこで、プラクティスの詳細の説明をするべきだと感じ、実例マッピングの記事の著者であるMattにも許可をもらい、英文を翻訳する形で紹介します。
なお、原文のページはこちらです。
cucumber.io
2020年11月20日追記：実例マッピングの事例および、どのように会話して実例マッピングを作っていくのかについてスライドにしました。
speakerdeck.com
2022年8月4日追記：実例マッピングの詳細なやり方も載っている書籍を翻訳しました。気になる方はこちらもどうぞ
leanpub.com
2023年4月26日追記：現時点での実例マッピングの日本語情報についてまとめました。こちらもどうぞ
nihonbuson.hatenadiary.jp
これ以降は元記事を翻訳したものになります。ただし注釈部分は、訳した時に必要だと感じた補足説明なので、元記事にはありません。
受け入れ基準設定時の課題感
ユーザーストーリーを開発が取り込む前に、受け入れ基準を明確にして確認するための会話をすることが重要です。
バックログリファインメントやプランニングポーカーセッションの時に行うチームもいます。他にも、スリーアミーゴス*2が参加する仕様ミーティングや仕様ワークショップ、ディスカバリーワークショップなどを行っているチームもいます。
この会話を何と呼ぼうと、多くのチームが難しいと感じています。その結果、構造化されておらず、時間がかかりすぎて退屈になり、定期的や一貫して行われないか、あるいは完全にあきらめてしまうかもしれません。
私はこの会話を短く、強力で生産的にするためのシンプルでローテクな方法*3を発見しました。私はこれを実例マッピングと呼んでいます。
具体的な例を用いることは、問題領域を探索するのに非常に有効な方法であり、受け入れテストのための素晴らしい基礎となります。しかし、これらの例について議論していると、会話の中では他の話題も出てきますが、それらの話題も把握する価値があります。
- 多数の具体例を要約するルール、またはストーリーのスコープ（範囲）に関するその他の合意済みの制約を表現するルール。
- 会話に参加している誰も、何が適切なアウトカム（成果）なのかを知らないシナリオについての疑問点。 もしくは、進めるにあたって私たちが置いている仮定。
- 私たちが発見またはスライスしたが、スコープ外に延期した新しいユーザーストーリー。
実例マッピングでは、4色のインデックスカード（付箋）*4といくつかのペンを使って、会話が展開するときに発生するこれらのさまざまな情報を捕まえます。 私たちは会話をしながら、それらの情報を付箋に記載し、マップに配置します。
まず、議論中のストーリーを黄色の付箋に書き、テーブルの一番上に配置します。
次に、それぞれの受け入れ基準または既に分かっているルールを青い付箋に書き込み、それらを黄色い付箋の下に配置します。
それぞれのルールについて、ルールを説明するために1つ以上の具体例が必要になるかもしれません。 私たちはそれらを緑の付箋に書き、それらを関連するルール（青い付箋）の下に配置します。
これらの具体例を議論しているうちに、参加者全員が答えられない疑問点が出てくるかもしれません。 そのような疑問点を赤い付箋に記録し、会話を続けます。
ストーリーの範囲が明確であるとチームが納得するまで、または時間切れになるまで続けます。
以上です。簡単ですね！
即座のフィードバック
会話の流れに合わせて、目の前のテーブルの上に視覚的に表現されたものを素早く作ることで、ストーリーに対する現在の理解度を反映させることができます。
- テーブルが赤い付箋（疑問点）だらけになってしまった場合は、このストーリーについて学ぶべきことがまだたくさんあることを示します。
- テーブルが青い付箋（ルール）だらけになってしまった場合は、このストーリーが大きくて複雑であることを示します。 おそらく、このストーリーは分割できるのではないでしょうか？ 別の黄色の付箋（ストーリー）に記載して、分割したストーリーをバックログに入れます。
- 1つのルールに対して、多くの緑の付箋（具体例）がある場合、ルールが複雑すぎるかもしれません。 複数のルールがあって、別々に分ける必要があるのではないでしょうか？
具体例が全く必要ないほど明白なルールもあることに気づくでしょう。 会話をしていると、誰もがルールを理解していることは明らかです。 すごい！ BDDに洗脳されたオートマトンのように無理に具体例を出さなくても*5、どんどん先に進めることができます。
タイムボックスの中で考える
少人数のアミーゴであれば、約25分でよく理解された十分なサイズのストーリーを作成できるはずです。
それができない場合、このやり方のコツをまだ得ていない（これは問題ありません）、ストーリーが大きすぎる（間違いなく問題あり）、またはまだ不確実性が大きすぎるかのいずれかです。 だとしたら、ストーリーを分割するか、製品担当者に持ち帰ってもらい、後日、別の実例マッピングセッションで再びそのストーリーを扱うまでの宿題としましょう。
Cucumberのプロジェクトでは、25分後に簡単な親指投票*6を使用して、ストーリーが開発に入る準備ができているかどうかを判断します。 いくつかの疑問点が残っている場合でも、あなたが進むにつれてそれらを解決できるほど十分に小さいと思うかもしれません。 グループでの決定をしてください。
利点
実例マッピングは、ストーリー内の最小の動作にズームインして注目するのに役立ちます。 マッピングすることにより、ルールを分解し、必要な動作の核心を見つけ、残りの部分は後回しにすることができます。 この程度の精査で、実例マッピングはフィルターのような役割を果たし、大きなストーリーがスプリントに入り込んだり、デモの3日前の土壇場でのサプライズで爆発するのを防ぐことができます。
また、時間を節約できるため、忙しい製品担当者のプロセスへの関心を維持するのにも役立ちます。
ツイート訳：私たちは今、2、3か月からアミーゴの時に実例マッピングを行っており、一連の時間を大幅に短縮しています！
多くのチームは、スリーアミーゴスがこのセッション中に受け入れテスト（例えばCucumberのシナリオ）を書き、誰かが正式なgherkin記法*7でシナリオをIDEに入力し、その間、プロジェクターの近くに座っているものと想定しています。 それに価値がある場合もありますが、一般的には良くない考えだと思います。 実は、会話の本当の目的がぶれてしまっているかもしれません。
人々がこの間違いを犯す理由は簡単です。この作業のわかりやすい目的は、いくつか事前定義された受け入れ基準を持つユーザーストーリーを取って、受け入れテストに変えることができそうな具体例を考え出すことだからです。
しかし、私が考える本当の目的とは、ストーリーが完成するためには何が必要なのか、共通の理解に達することです。 ローテクのままでいることで、この目的に向けてはるかに素早く進むことができます。
ドラマ「フレンズ」のタイトル
したがって、本格的な正式なGherkinシナリオを使用する代わりに、シチュエーションコメディドラマ「フレンズ」のタイトルの付け方*8を使用して、おおまかな例のリストを作ってみてください。
例えば：
- 顧客が領収書を忘れた場合
- 製品が破損していた場合
- 製品が15日前に購入されていた場合
不確実性が潜んでいると、本能的にもっと具体的にしたいと思うことがあるでしょう。 しかし、まだGiven When Thenの厳格な構造に頼る必要はありません。
結果（Then）が不明確な場合、例がなく、疑問点だけがある状態です。
「知らない」を知ること
このような会話がループするようになるのは、十分な情報がないためです。 おそらく誰かが会話に参加していないか、ユーザー調査やスパイクが必要かもしれません。
適切なアウトカムについて全員に話してもらうのは避け、さっと疑問だけを捉え、先に進みます。 おめでとうございます！無知の無知（unknown unknown）*9から、無知の知（known unknown）*10に変えられました。 それは大きな進歩です。
多くの人々は、この実例マッピングの1つの側面だけで、彼らのディスカバリーワークショップがつまらなくとりとめのない状態から、きびきびとした生産的で心が通い合った状態に変わったと私に言います。
誰が参加するべきですか？
最低限必要なのは、開発者、テスター、製品担当者（スリーアミーゴス）です。 ただし、これは最低限のことです。 ぜひ、運用者、UX（ユーザーエクスペリエンス）の人々、または議論されているストーリーに関係のある人を招待してください。 新しい疑問を発見したり、会話中に疑問を決定に変えたりできる人は誰でも役に立ちます。
このテクニックを学んでいる間、誰かが正式にファシリテーターの役割を担ってくれると助かります。その人の仕事は、話していることがすべて付箋に記録されているかどうかを確認することです。 実例や疑問が部屋の中を飛び交います。今なにが話されているのかがわかるように、話題を捉えて記述するには訓練が必要です。
それで、いつGherkinを書くのですか？
この記事を見て混乱しないでください。Gherkinを一緒に書くことは、特にプロジェクトの初期には非常に価値があります。 そこでユビキタス言語を開発します。チームの全員が信じられる方法でシナリオを表現することが重要なのです。
しかし、そのように実例を表現するには、実例がスコープ内にあるかを判断し、その根底となるルールを明確にすることとは異なる思考モードが必要です。
かなり成熟したドメイン言語を使用して稼働しているチームの場合、私はよく製品担当者に実例マッピングのセッションで時間と労力を費やしてもらい、実際のGherkinの執筆は他の2人のアミーゴ（開発者とテスター）に任せます。 Gherkin記法での仕様の草案が作成されたら、製品担当者はフィードバックを提供します。
これは私がここまでに書いたやり方と同じでしょうか？
こうすることは、製品担当者の知識を他のアミーゴに伝達するのに、実例マッピングでの会話がどれほど効果的であったかをテストするチャンスです。
どのくらいの頻度でこれを行うべきですか？
製品担当者はたいてい忙しいです。 製品担当者が完全に注意を向けることができるようにこれらをスケジュールするようにして、製品担当者の時間を尊重してください。
いくつかのチームが実際に仕事をしているのを見た経験から私がオススメするのは、頻繁に実行することです。1日おきのリズムが良いです。 ストーリーを1つ選んで25分間だけ注意を払い、その後は仕事に戻ります。 大きなバッチでより多くのことをしようとすると、エネルギーを消耗するだけです。
しかし、私のチームは分散しています！
これについては革新的なハッキングをすでに見ました。Googleドキュメントをシェアすることで、箇条書きを使用する人もいれば、色付きのセルを含むスプレッドシートを使用して付箋を表現する人もいます。 マインドマップを使用することもできます。 重要なのは、すばやく簡単に操作できるようにして、会話に集中できるようにすることです。
最後のTips
実例マッピングを使用する前に、ルールとサンプルの違いを明確に理解することが重要です。 これを教えるための楽しいエクササイズがあり、今後の投稿で共有します。
この会話の全体的な目的は、まだ知らないことを発見することです。 だから、くだらない疑問はありません。 楽しんで、問題を実際に調べてください。
ルールによって、ストーリーをスライスするための自然な断層ができていることに気づくでしょう。 スライスするのをできるだけ先延ばしにして、快適にスライスできるまで待ちましょう。そうすれば問題の核心を解決することに集中できます。 後でもっと洗練された（そして複雑な）ストーリーを追加することができるでしょう。
Janet Gregory, Aslak Hellesøy, Seb Roseのこの投稿へのフィードバック、Theo Englandの忍耐力、そして投稿を後押ししてくれたTom Stuartに感謝します。
