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

前回記事では、良い実例や振る舞いの定義がどういうものであるのか、良い定義をすることによってどんな効果が期待できるのかについて述べてきました。ここから、その良い定義をどうやって導くかについて有効性の高いプラクティスをいくつか紹介します。BDDのフレームワークの中身を埋めるためには、さまざまなスキルが必要になります。残念なことに、それらについてはBDDの解説の中ではアドホックに語られることが多いようです。そこで、本稿では各項目を定義しようとするシーンで有効なプラクティスを、伝統的に体系化されてきた実績ある手法の中にあるものも含め紹介します。

それでは推奨手順に沿って説明していきます。取り上げるべきユーザーストーリーが決まっているところからのスタートになります。そのストーリーの質や粒度はこの時点までに適切なものになっていることを一旦は前提として、一つずつ考えていけばよいでしょう。もちろん、例えば粒度が大き過ぎるといった問題も起こり得ます。そういった場合でも以下の手順の中で分解可能なことが多いです。また、分解した一部をバックログに戻すような対処をすることもあります。

ここで、ユーザーストーリーマップがあれば、それが役に立つはずですし、正しい理解のために必ず参照すべきです。その一方、現実にはそこに必要な情報がそろっているとは限りません。ユーザーストーリーマップとの関係を理解しておくことは非常に大事なことなので、本稿の説明もここで少し回り道をすることにします。

自動販売機開発のユーザーストーリーマップはどのようなものになるのだろうと想像すると、ここで簡単に取り上げられるほど全体は小さくはないでしょう。自動販売機は、基本的に販売側の一部の作業を、人手を介す必要なく自動化するものです。しかし、販売という行為は、販売する側だけでなく、購入する側もいなければ成立しません。双方の役割やそれぞれのペルソナを想定したナラティブフローは長くなり、ここで取り上げるには大き過ぎます。そこで、ここでは購入者が自動販売機の前で購入のための操作をする部分だけを取り上げることにします。

ステークホルダーによっては、上記のユーザーストーリーで十分だと考えるかもしれません。しかし、競合他社の製品を超えるものを今から作ろうとしている立場ではこの粒度では粗過ぎます。もう少し細かく分解していくことにしましょう。まず、販売機の前で、購入者は大きく二つのことをしなければならないはずです。「商品を選択肢の中から選ぶ」ことと、「支払いをする」ことです。「商品を選択肢の中から選ぶ」ことは、とても単純なことのように思えるので、そんな分解に何の意味があるのかと考える人もいるかもしれません。しかし、ペルソナが異なればユーザーストーリーも変わってきます。例えば、日本語をよく知らない外国からの観光客である場合や、視力が弱い人である場合などを考えてみるとよいでしょう。役割やペルソナが同じでも、雨が降って傘を差している状況や、強い西日が販売機に差し込んでいる状況などはユーザーストーリーを変化させるでしょう。寒い日に温まりたいので温かい飲み物を飲みたい人のユーザーストーリーはまた別のものとなるでしょう。そういう人に、補充されたばかりで十分に温まっていない飲み物を販売したらどうなるでしょうか。冷たくても売ってしまえばその場では利益が出ますが、きっと二度とその販売機を使ってもらえなくなるでしょう。「支払いをする」についても、少し昔には現金しか無かったのですが、今はいくつもの決済方法があり、どれが望まれるか分かりません。おサイフケータイ®対応のスマホは持っているが、財布を持たない人もいます。現金払いで硬貨を投入中に小銭が足りないことに気付き、電子マネー決済に変更しようとする状況や、反対に電子マネーの残高不足で現金払いに変えようとする状況もあります。そうすると、もう少し丁寧に分解してみるのが良さそうだという判断になることでしょう。

本稿の趣旨はBDDにありますので、ユーザーストーリーマッピングの話はこれぐらいにとどめます。また、最初の段階としては通常起こる事柄〔レギュラリティー〕に注目すべきなので、特殊や例外的なケースではなく、一般的あるいは典型的なケースで説明します。

自動販売機の前で購入のための操作をする部分だけをタスク表現※1に分解すると、次のようになります（図表1）。ユーザーストーリーマッピングでは、ほぼ同時に起こることは縦に並べたりする[1]ので、縦に並んでいるかもしれません。

この情報を基に、BDDの作業に入ります。取り上げたユーザーストーリーによって（特にタスク表現されている場合）は、簡単に振る舞いの表現が導き出せることも多いでしょう。多くの人が簡単に思いつく定義を先延ばしにしても仕方がないので、そういうものは振る舞いから先に暫定的に表現していけばよいと思います。ただ、その後に実例を挙げ出すと、最初に定義した振る舞いは、実はそう単純では済まないことが分かってくることが多いです。

上に示した例（図表1）の最後の部分に注目して説明します。「購入した商品を受け取る」ができるために、自動販売機に要求されるのは「取り出し可能な購入した商品」で、振る舞いとしては「購入された商品を提供する（取り出し可にする）」と暫定的に表現できます。

このように、システムの振る舞いを考えているからといって、技術用語でしか表現できないかといえばそんなことはありません。例外こそありますが、一般的にはビジネスの用語を使ってシステムの振る舞いを表現できます。それは上記した例（図表2）を見ていただければ分かると思います。

この例では、仮にユーザーストーリーマッピングでタスク分解されていなくても、あまり困らないかもしれません。次のように最初のユーザーストーリーから直接振る舞いのルールを思いつけるからです（図表3）。

ユーザーストーリーマッピングとBDDの双方で分解を繰り返すのは無駄だと感じるでしょうか？確かにここまでの結果を見ると、ユーザーストーリーマッピングでもBDDのルールでも、大差ない感じがします。しかし、ユーザーストーリーマッピングの方法での(例えば、先に述べたようなペルソナや状況の違いを考慮に入れての詳細やバリエーション)検討と、これから説明していくBDDの方法での検討は、同じことの繰り返しにはなりません。自動販売機の一見単純そうな部分を考えてみただけでも、違う有意な結果が得られそうだ、と分かっていただけると思います。

購入者は最終的に購入した商品を受け取りたいわけですから、ここでは最後の部分「購入された商品を提供する（取り出し可にする）」を取り上げて検討しましょう。

実例を考える時には、時間順とは逆の順序で検討するのが考えやすいです[2]。次の順序で明らかにしていきます。

　1. 結果(Outcome)

　2. 操作(Action)

　3. 状況(Context)

購入者が缶コーヒーを買う実例の結果の部分を表現すると、次のようになります。

- 結果(Outcome): 購入された缶コーヒーを提供する（取り出し可にする）

このように、結果(Outcome)や出力(Output)から考えることを勧めているのは、BDDに限った話ではなく、他のさまざまな伝統的手法[3]でも共通しています。ユーザーが欲しいのは結果(Outcome)や出力(Output)なので、そこから明確に確定していくのがよいでしょう。

結果や出力を明確にすることは、実は主要な振る舞い(機能)を明確にすることでもあるのです。どうしてそうなるのかを説明します。

伝統的手法※2は、振る舞い(機能)の表現形式について、次のように表現することを推奨しています。

目的語（名詞）+ 動詞を使って、

つまり、

「A（名詞）をBする（動詞）」

「AをBした」結果得られる出力は「BされたA」となるはずです。この関係は常に成り立ちます。ですから、欲しい結果や出力を明確にすること、振る舞い(機能)を明確にすることはほぼ同じ事だと考えてよいのです。

ここで取り上げている自動販売機であれば、期待される振る舞いは、販売員の人手を介さずに「商品を販売する」ことです。その振る舞いの結果得られるものは「販売された商品」となります。この行為には販売者と購入者の双方が必要であり、購入者側から見ると「購入した商品」に表現が代わり、その表現の方が適切なことはあります。ただ、これも特に悩むことなく置き換え可能でしょう。

ここで、もしも結果が複数欲しい時には、分割できないか考えるようにします。

自動販売機に期待することとしては、選択した商品が出てくることと、現金を投入した場合には、釣り銭が出てきてほしいことでしょう。商品が出てくることとは別に、釣り銭のルールを追加します（図表4）。図表の中の並びにはルールとしての意味がないことに注意してください。現状を時間順序に並べるといった工夫は、検討時に漏れなくルールを抽出するためには意味があるのでお奨めします。ただ、その順序でなければならないのであれば、それも一つのルールとして追加する必要があります。ただ、商品と釣り銭を出す順序は決めなくてよいので、ここはそのようなルールは必要ありません。確かに、どちらも速やかに行う必要はありますが、ほぼ同時に起こってほしいというだけのことを並べ出すと、フローチャートのようになっていきます。ここでやりたいことはそういうことではありません。さまざまな要求のつじつまを合わせ全てを達成できるようにフローチャートのように並べることは、後で実装者に任せればよいのです。

販売機は「購入者によって選択された商品の提供」と「代価の回収」という大きく二つの振る舞いをしています。これらは別のことであると一旦は分けられます。（代価の回収は電子マネーでもよいので、電子マネーでの決済を取り入れれば釣り銭を出す必要はなくなります。分けられることは分けておくことで、別々に手段の置き換えや改良を考えられるようになります。）

操作は、その結果がいつ(When)出力されるか、いつ出力されてほしいか、あるいはその振る舞いがいつ起こるか、いつ起こってほしいかを明確にします。1つの実例に2つの操作を入れてはなりません。もし2通りあるのであれば、別々の実例とします。

最近の自動販売機で考えてみると、お金を投入してから商品を選択してもよいですし、商品を選択してからお金を投入してもよいものが増えています。そうすると、商品の提供はお金を投入したタイミングの場合と商品を選択したタイミングの２つがあると表現したくなるかもしれません。しかし、それらはそれぞれ別の実例、そしてルールにすることを考えてください。ただし、インターロックによる安全機構など、わざわざ2つの操作がそろわないと振る舞いが起こらないようなものを考えているときには、別々に分ける必要はありません。別々に分けてしまうとその意味が失われて分からなくなってしまうからです。

ここで「商品ボタンが押されたら」のように、システムや装置、技術用語は使わないようにします。繰り返しになりますが、ビジネス側と理解を共通にするのが狙いだからです。また、「ボタンを押す」ではその意図が表現されていません。さらには、その表現はボタンを使うことを要求してしまうことになり、手段を確定させてしまいます。最近は使い勝手を考えて、同じ意味の操作をさまざまな手段で提供することも増えています。子供や車いすでも届く位置にもう1つボタンを付けたり、タッチパネルにもメニューを出したり、音声での指示を受け付けたり、といった具合にです。それなのに、「商品ボタンが押されたら」と表現してしまったら、もうそれ以外の手段は検討されない可能性が高まります。一方、多様な手段を毎回並べるような表現を歓迎するステークホルダーはいないはずです。ビジネスの用語を使いつつ、システムや製品への要求の表現にするには、「商品が選択された(のを検知した)ら」, 「購入の意思決定を(検知)したら」のように表現するとよいでしょう。

さて、ここまで最近の自動販売機の使用体験を交えて、操作(Action)の候補として価格相当分の硬貨投入、あるいは商品選択の二通りがありそうということで、操作が複数ある場合にどう対処すべきなのか、また手段を必要以上に限定しないための表現の工夫について説明してきました。ではその二通りの操作別に2つの実例を考えていけばよいように思うかもしれませんが、実はよく検討すると、ここで取り上げている部分においては、操作はそのどちらでもないことが分かります※3。

注意深く検討すれば、ここで取り上げている「購入された商品を提供する（取り出し可にする）」の中に、「購入された」と過去形で表現されている通り、すでに最初の時点で「購入される」ことは成り立っていなければいけません。

先に、「購入者によって選択された商品の提供」と「代価の回収」の大きく2つの振る舞いに分けることにしました。その一方で、これらはほぼ同時に特定の順序で行われる必要があります。それはなぜなのかに思いが至れば、重要なルールが出てきます。自動販売機は、通常、先に代価を回収してから商品を提供します。不正行為を防ぐ必要があるからです。これは代価を取り損ねないための重要なルールです。

この部分の操作(Action)にふさわしいのは、「代価の回収が確認できたら」となります。

ここまで検討した内容を付け加えると、実例とルールは以下のように修正できます（図表5）。

ところで、先に代価を回収することにすると、反対に販売者側が代価を取るだけで商品を渡さない、という不正を働くことができそうに思えます。しかし、その不正は実際には起こりません。もしそのようなことをすれば、利用者は自動販売機を信用しなくなり、販売機は利用されなくなってしまうからです。

このように、販売機の機能だけで何もかも解決できるとは限りませんし、またその必要がないこともあります。法や規範、経済原理がどのように働くかということも合わせて考える必要があります。

ただ、他に販売者の不正や、図らずとも不正になってしまうような振る舞いを防ぐ別の機能は必要になるでしょう。そうしないと、販売機そのものの信用がなくなり、販売機自体が売れなくなってしまいます。在庫がない商品は販売できない。釣り銭が出せないなら売ってはいけない、何らかの機械トラブルで商品が出せなかったら記録を残す、その後の販売を停止する、保守にアラートを上げるなど、さまざまな機能が必要となるでしょう。ただし、これらは別の要求からくる振る舞いです。ほぼ同時に行われるべきことであったとしても、並べ出すと、フローチャートの作成作業に変質してしまいます。そうならないように気を付けましょう。

検討の中で出てきた疑問や仮定は、リスト化し、ステークホルダー間で共有しておくとよいでしょう。それぞれの検討に適切なメンバーはさまざまに入れ替わるはずなので、出てきたその場で検討するのは非効率かつ非合理になることも多いからです。

このように、要求仕様を分析・分解・整理して体系化して理解が間違っていないか、抜け漏れがないかをビジネス側と確認していくことがここでやるべきことです。

また、操作(Action)の検討場面に限らず、振る舞いを分析整理するときには、法や規定、市場(経済原理)、社会規範なども関係している[4]ことを忘れないようにします。

最後に状況を明確にします。先に示したIPO図式で考える場合であれば、入力(Input)を明確にすることに相当します。暫定的に次のように考えられます。振る舞いが「AをBした」結果得られる出力が「BされたA」となるのと反対で、「(Bされる前の)A」が基本的には入力のはずです。

「缶コーヒーを販売する」振る舞いで得られる結果は「販売された缶コーヒー」で、その振る舞いの前に何があったかといえば「販売される前の缶コーヒー」です。これは通常、「販売される前の」は省略して「缶コーヒー」と表現すれば十分なことが多いです※4。

この方法でいつもうまくいくかというと、そうとは限りません。この単純な方法では、大事な他の入力を見落とす可能性があります。例えば、ドリップコーヒーは、「ドリップされたコーヒー」なので、暫定的に入力を考えると「ドリップされる前のコーヒー」となります。「ドリップされる前のコーヒー」とは「コーヒー」である。これでは不十分です。つまりコーヒー粉になっていることや、それ以外にもお湯やペーパーフィルターなども必要です。

このように暫定的に見つけた入力のままでは不十分なので、暫定入力をその状況や状態によって詳細化していきます。その中から、システム設計する意図に沿った入力を改めて選択し直す必要があるのです。

結果を得るためには、他に何が必要でしょうか？「(取り出し可にする前の)購入された商品」が必要です。自動販売機の中には多数の商品が格納されているはずですが、その中のどれが「購入された商品」なのか、特定できる状況(Context)が満たされている必要があることが分かります。

ここまでの説明で、操作(Action)と状況(Context)の区別が難しそうだと感じた方がいらっしゃるかもしれません。これらはシンプルなIPO図式ではどちらも入力(Input)で区別する必要がありませんが、正しい振る舞いを理解するためには区別が大事です。実際、先の例で「商品ボタンを押した時」などとしてしまうと、不正や損失につながってしまいます。

操作(Action)が簡単に見つけられないときは、入力(Input)を詳細化して、後から検討して選び出すとよいでしょう。

入力(Input)の詳細化手法としては、ワークデザイン手法の中で次のようなものが示されています[3]。

　(1) 上方展開（時系列的にさかのぼる）

　(2) 水平展開（空間的に広げる）

　(3) 分岐展開（分解していく）

これらを適当に組み合わせて展開し　、適切なものを選び出します。基本的な方法は(1)の上方展開です。(2)と(3)は、(1)を補足する展開方法として示されています。

(1)の上方展開は、分かりにくい表現ですが、上流にさかのぼるということで、先に暫定的に求めた入力について、その状態を時間的にさかのぼって順序よく並べることです。これは現状(As Is)分析として行えばよいので、次の自動販売機の検討過程で行うとすれば、既存の自動販売機でもよいのですが、自動販売機以外の店舗での人手による販売でもよいでしょう。「(販売される前の)缶コーヒー」について、上方展開した例を以下に示します。

現状(As Is)の順序はたまたまそうなっているだけの場合もあり、それにとらわれることはありませんが、手がかりとして有益な情報が得られます。この程度の情報から、操作(Action)は「商品ボタンを押した(商品選択した)」ではなく、「代価の回収確認を検知したら(支払いが済んだら)」であると確認できます。

そういうわけで、ここでは(2)の水平展開（空間展開）は不要ということになってしまうのですが、(2)が必要になるのは、暫定的に求めたインプットが抽象的過ぎたり広範囲過ぎたりして、上方展開が難しくなってしまった場合です。先の例で時間をさかのぼった中の少し上の方に、「代価が支払われた」という表現があります。「支払う」という表現は抽象的です。ここは少し具体化して、

「現金を渡す」,「クレジットカード決済する」,「電子マネー決済する」,「モバイル決済する」・・・

これらの間には時間的な前後関係がありません。このような展開は水平展開と名付けられています。この後、それぞれについて再び上方展開すると、多くの手がかり情報が得られます。

残った(3)の分岐展開ですが、上方展開の途中で構成物に分解する必要が出てくることがあります。分解するので、展開として分岐させる必要が出てきます。製品のインプットを考えているときには、一般に人・もの・金・情報があり得ます。物理的なものとしては先にドリップコーヒーの例を挙げましたので、ここではソフトウェア処理機能で構成物としての情報を考えてみましょう。先の例で「代価」もそのままでは抽象的です。「代価」の具体的な価格を求めるには、その構成情報として「選択された商品の識別情報」と「各商品の価格リスト」が必要です。これも、分岐した後に、さらに上方展開を続けていくことができます。こういった展開を続けていくと「切りがないのではないか」と思えるぐらいにかなり継続的に可能なことが多いです。ですから、採用しようと思うレベルの2～3段階上のレベルまで展開したところでやめればよいでしょう。採用できそうなものより少し先まで展開することで、それを採用するのが最適であると確認できます。

こういったことに相当する情報はユーザーストーリーマップにある可能性があります（その表現は、ユーザー視点になっているはずなので、そのまま持ってくれば済むわけではなく、人工物視点に表現の変換を要するはずではありますが）。現状(As Is)を分析しているものは、ジャーニーマップなどと呼ばれていることが多いです。まずそういった上流の成果物を確認すべきです。ただし、粒度が粗くて参考にならない場合もあります。その場合は先に示したように、ここで分析すればよいでしょう。

余談になりますが、USDMをご存じの方は、その中で示される要求階層化の(要求の範囲が広過ぎる時に要求を分割する)テクニックとして以下の4つの分割基準が示されます[5]が、おおむねこれに対応すると考えてよいでしょう。

　① 時系列分割（時間軸分割）

　② 構成分割（時間的順序性を持たない並立する(実行時にどれかが選択される)機能などもこの分類に含む）

　③ 状態分割

　④ 共通分割（共通部分のくくり出し）

対応関係を簡単に説明しておきます。まず④は、要求集合の視点で、他の要求との関係を見た上で判断することなので、ここでは除外しておきます。①は(1)に、②が(2)あるいは(3)に対応します。③はどこに行ったのでしょうか？ そうです。今、入力(Input)を詳細化するための方法論を紹介していて、それを通して、操作(Action)と状況(Context)を明らかにしたいのでした。③は特定したい状況(Context)に対応することになります※5。

時系列で導いたものは、その順に並べます。抜け漏れがないかチェックしやすいからです。ここで注意すべきなのは、この段階では現状(As Is)の分析に主眼があるのであって、これから作るもの(To Be)の振る舞いの順序を決めようとしているわけではないということです。時間順序に並べるのは、ルール(要求仕様)や実例を抜け漏れなく引き出すために過ぎません。現状(As Is)の分析に基づいて並べた順序通りに振る舞うように作る必要はないということです。逆に言えば、並べた順序は振る舞いの順序を規定しないので、守らなければならない順序関係についてはルールや実例の中に表現しないといけないということです(先にも同じ注意をしました)。

検討していた部分の実例とルールは、次のようなものでよいでしょう（図表6）。

ここに示したのは実例と振る舞いの定義の一例です。集まったメンバーによってはこの通りになる必要はありません。表現や分割の仕方が違うことになるかもしれません。

こんなに分解しないでもよいだろうと考えますか？

分解しないで、また検討順序についての助言を無視して、いきなり状況(Context)を検討するところから始めてみましょう。

• 100円玉を2枚入れて、120円の温かい缶コーヒーのボタンを押したら、温かい缶コーヒーが取り出し口に、50円玉が1枚と10円玉3枚が釣り銭口に出される。
  　
• 120円の温かい缶コーヒーのボタンを押し、ブランド名○○の電子マネーカードをかざしたら、温かい缶コーヒーが取り出し口に、電子マネーの残高から120円が引かれる。
  　
• 120円の温かい缶コーヒーのボタンを押し、決済方法をタッチパネルのメニューで電子マネーのブランド名○○と選択して、おサイフケータイ®をかざしたら、温かい缶コーヒーが取り出し口に、おサイフケータイ®の該当する電子マネーの残高から120円が引かれる。

分解が不十分なまま、この調子で組み合わせや順序の違う状況を列挙していったら、非常に面倒なことになるのは目に見えています。

さらに、缶コーヒーが十分に温まっていないとか、釣り銭用の10円玉が切れたとか、電子マネーの残高が足りないとか、120円の商品のボタンを押しておきながら、硬貨が110円まで投入された際に、（おそらくもう10円を持っていなかったのか）110円の商品ボタンが選び直されたとか、そんな複雑な状況の実例を必要なだけ挙げられるでしょうか？

そんな細かいことは実装担当者任せで構わない、という粒度の境界線がどこかにあると思いますが、粒度が粗過ぎると、ビジネス側の要求を引き出す機会を失います。

結局、やっていることは、作ろうとしているものへの要求仕様の分解、機能の分解になるので、実装者にしてみれば設計の一部でいずれやらなければいけないことです（もしかしたらコーディング中に担当者の頭の中だけで行われているかもしれませんが）。また、この分解結果は、実装作業(例えばコーディングなど)のタスク分解単位としても活用できますので、しっかり分解できていれば見積もり精度も上がっていきますし、可視化により説明もしやすくなります。

そうやって表現されたルール(要求仕様であり受け入れ基準でもある)、実例、シナリオ（本稿では詳しく説明していませんが、ルールや実例を定式化したものです）は、自然言語のような表現で簡潔なものになるので、簡単に導けそうに見えます。しかし、質の良い表現ができるようになるまでには、トレーニングを積む必要があります。質が良いとはどういうことでしょうか？目標から確認すると、主な目標は3つあります[6]。

　-  説明的であること

　-  全ての人が理解できるように書かれるべき(ビジネス側のステークホルダーが自然に読める必要がある)

　-  製品の進化を支援するものであること

目標の3番目「製品の進化を支援するものであること」が、少し分かりにくいかもしれません。自動販売機の例で、「代価の回収が確認できてから商品を提供する」のような部分を、最初の100円玉が投入開始されてから、商品や釣り銭が出てくるまでのフローチャートのように表現してしまうと、その後に電子マネーでの決済を取り入れる際に、再利用できるよりはむしろ妨げになるだろうと想像できます。

そういった負の資産が大量に生み出されてしまうことを防ぐことも含め、これら3つの目標のために有効な原則が6つ示されています[6]。以下に表にして示します。覚えやすいように、6つの原則の要約タイトルの頭文字をとってBRIEF原則と名付けられています(各原則の頭文字を取っていますが、BRIEFは5文字しかありません。6つ目の原則はBrief自体になります。図表7)。

定義した要求仕様の質の評価基準としては、他にもREBOK[7]やBABOK[8]、『JIS X 0166 (ISO/IEC/IEEE 29148)システム及びソフトウェア技術－ライフサイクルプロセス－要求エンジニアリング』[9]などにも示されています。

目的や目標から考えて、BRIEF原則は納得のいく分かりやすいものですが、その習得はなかなか難しいです。具体的であることが望ましいということで、「缶コーヒーのボタンが押されたら」と表現したくなりますが、それは手段をボタンに制限してしまうことになるので、ダメなのだという説明はすでにしました。BRIEF原則でみても、操作者(アクター)の意図が表現されておらず、やはりダメな表現です。「缶コーヒーが(アクターによって)選択されたら(選択されたのを感知したら)」のような表現にすれば意図が明らかになります。

「缶コーヒー」の方の表現も良いとは限りません。本稿の実例では使用しましたが、他の実例で「ペットボトルのお茶」と誰かが表現するかもしれません。そうすると、ルールや実例を読む側としては、「きっと、缶とペットボトルとでは何かルールが違って振る舞いが異ならなければならないのだな」と、その違いに注目することになります。ところが、単に選んだ具体的なものがたまたま違っただけで、そこには何の意味もなかった、ということが起こり得ます。また、同じ缶コーヒー(銘柄さえ同じ)でも、温めてあるものと、冷やしてあるものとでは、別の商品として扱わなければならず、振る舞いが違う別のルールが必要なこともあるでしょう。そうすると、ルールだけではなく実例も「商品」という抽象レベルの表現の方が適している、となるかもしれません。ちょうどよい抽象レベルの表現を見つけることは、誰に何を説明し、共通の理解を得たいかということにかかっています。個々のルールや実例としてだけではなく、ルールや実例の集合として(特に理由がなければ)一貫した表現を用いなければならないという点で、さらに難しさが増します。うまく表現できるようになるまでには、トレーニングが必要になるでしょう。また、プロジェクトごとにふさわしい運用ルールを調整し続ける必要もあります。

※1) ここで「タスク表現」と呼んでいるのは、動詞＋目的語（名詞）のような簡潔な表現と理解してください。すでに分解前のストーリーからペルソナや役割などが明確になっていて、Connextra Formatにこだわる必要がないストーリー表現ということです。

※2) 伝統的手法の例としては、バリューエンジニアリングにおけるファンクショナルアプローチ[10][11][12][13]、システム思考におけるワークデザイン手法[3][14]などです。最近では、XDDP（eXtreme Derivative Development Process）で使用されるUSDM (Universal Specification Describing Manner)の中のマナーの一つとしても示されています[5]。アジャイルのコミュニティーではあまり明確にこのような伝統的手法の説明がされることがありませんが、例えばJeff Pattonの著書[1]ではタスク(未来の機能)の表現形式について、この形式を推奨しています。この書籍で例示されているマップ図を丁寧に見ると、配置されているカードの中に書き込まれている表現は、基本的にこの形式に統一されています。

※3) 検討の途中で、そういう実例を挙げることはあってよいことだと思います。検討が進む中で他の実例に置き換えられて、破棄されることになりますが、実際にはそうやって何回も表現し直さないとうまくいかないのは当然のことです。

※4) 「缶コーヒーを販売する」は、「顧客に缶コーヒーを販売する」であり、「(顧客に販売される前の)缶コーヒー」と「(缶コーヒーを販売される前の)顧客」がインプットと考えることもできます。

※5) USDMの提唱者である清水吉男氏は著書[5]の中で状態分割について次のように説明しています。
『「状態」という概念が見えている場合は、それを使った方が分割はスムーズにできます。分割の基準としては、時系列分割と構成分割で大部分がカバーできると思われます。「状態」は、ある視点で見ると「時系列」の要素を持っていることがあり、また別の場面では「構成」の要素を持っていることがあります。』

[1] Jeff Patton (著), 川口 恭伸 (監修), 長尾 高弘 (翻訳)『ユーザーストーリーマッピング』オライリージャパン

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

[3] 五百井清右衛門, 黒須誠治, 平野雅章 著『システム思考とシステム技術』 ＜早稲田大学システム科学研究所叢書＞白桃書房

[4] ローレンス レッシグ (著), 山形 浩生 (翻訳)『CODE VERSION 2.0』 翔泳社

[5] 清水吉男, 『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？』, 技術評論社

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

[7] 情報サービス産業協会REBOK企画WG (編集)『要求工学知識体系 第1版』近代科学社

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

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

[10] ローレンス・D.マイルズ (著), 玉井 正寿 (翻訳)『VA/VEシステムと技法』日刊工業新聞社

[11] 秋山兼夫『機能分析―企業のシステム革新・効率化の基礎的ツール』( 財) 日本規格協会(1989年)

[12] 石井 浩介, 飯野 謙次『設計の科学 価値づくり設計』養賢堂

[13] 前野隆司, 保井俊之, 白坂成功, 富田欣和, 石橋金徳, 岩田徹, 八木田寛之, 『システム×デザイン思考で世界を変える 慶應SDM「イノベーションのつくり方」 』, 日経BP

[14] ジェラルド ナドラー, 日比野 省三『新・ブレイクスルー思考 : ニュー・コンセプトを創造する7つの原則』ダイヤモンド社