ユーザーストーリーはユースケースと互換性がありますか？

インターネットで検索すると、アジャイルの賢者たちはユースケースとユーザーストーリーは二つの異なるものだと考えている：

• マイク・コーン：ユーザーストーリーはユースケースではない
• アリスティア・コブーン：ユーザーストーリーはユースケースに対して、ガゼルがゲイズボに対してのようである
• Extreme Programming.org：ユーザーストーリーはユースケースと同じ目的を果たすが、それらは同じものではない。

ユースケース駆動アプローチは、要件収集のための最も人気のある技術の一つであったが、一部の人々は今やそれが古くさいスタイルの技術であり、ユースケースの問題によってチームが「アジャイル」でなくなる原因となる多くの問題と関連していると考えている。

• 事前要件 – 事前のすべての側面の詳細を定義しようとすると、多くの無駄な労力と時間がかかることになる。なぜなら、多くの作業は再実施が必要になるからである。
• 機能的分解：ユースケースの機能的性質は、拡張および包含のユースケース関連によって関連付けられた具象的および抽象的なユースケースとして、システムの機能的分解を自然に導く。

キーワード「ユースケース対ユーザーストーリー」でインターネットで検索すると、ユースケースアプローチの欠点、問題、落とし穴について述べた記事の長大なリストが得られる一方で、ユーザーストーリーに関する利点についてのリストはさらに長くなる。興味深いことに、IT業界では物事が非常に速く変化しており、かつて「トレンド」だったものを今や「新しいトレンド」に移行する人々にとっては、その変化はさらに速い。

興味深いことに、一部の人々は物事を二値的パターンで捉え、実際に真剣に実践するのではなく、象徴的にそれらと関連づけることでトレンドのものに追いつこうとする。一部の人々は、まだユースケースを使っていることを他の人に知られたくないため、そうしたことが古くさい、陳腐なスタイルと見なされるのを避けたいと考えている。

今や一部の人々はユーザーストーリーとユースケースの間に等号を置いている：

• アジャイル = ユーザーストーリー、またはアジャイル = ユーザーストーリー + スクラム
• ユーザーストーリー = ちょうど必要な量 & ちょうど必要なタイミング
• ユーザーストーリー = ユーザーの期待を満たすこと & 満足度
• ユースケース = 事前詳細な要件収集
• ユースケース = <<include>> + <<extends>> = 機能的分解
• ユースケースは「ユーザー入力」→「システム応答」のみのスタイル
• ユースケース = 古いスタイル & 古い

ツールベンダーとして、私は手法、ツール、技術に対して非常に中立的です。個人的には、私はアジャイル開発、ユーザーストーリー、スクラムプロセスの大ファンであることを強調したいと思います。特に、以下のような概念に関連する基盤となる原則やベストプラクティスについて：

• 要件の発見、要件の提供ではなく
• 上記の原則の下で、アジャイル開発プロセスにおいて二つの重要な特性が得られる。
  • ちょうど必要なタイミング
  • ちょうど必要な量

（上記の原則に関する私の個人的な見解をさらに多くの投稿で述べる予定です。これは1992～1995年の私の博士号研究分野であるメタモデルおよびスキーマ変換と密接に関連しています）

では、もう一度「ユースケース対ユーザーストーリー」の話に戻りましょう。アジャイルの重鎮たちがすでにその点について投票を終えているのですから、私はなぜ彼らの「投票」を覆そうとしているのか、それほど頑固なのでしょうか？『似ている』あるいは『まったく同じ』だと主張して。

ユーザーストーリーが「あまりにも異なる」のかを説明するために、例を示しましょう：

例

良いユーザーストーリーは単なる記述以上のものである。標準的なユーザーストーリーは、一般的に「3C」と呼ばれる3つの部分から構成される。

各ユーザーストーリーの最初の「C」は、標準化されたフォーマットに従うべきである：

[役割]として、[何かを行う]ことを望む。なぜなら[利益]があるからである。

これは、カードに記載するユーザーストーリーの最小限の内容である。

会話（Conversations）は、ユーザーストーリーの2番目の「C」を構成する内容であり、エンドユーザー、プロジェクトオーナー、開発チーム間の議論を表す。これらの会話では、口頭の議論や、メール、ワイヤーフレーム、プロジェクトに関連するその他の有用な情報が記録される。

ユーザーストーリーの最終的な「C」は確認（confirmation）であり、ユーザーストーリーが正しく実装され、成功裏に提供されたことを確認するために使用される受容基準である。

ユーザーストーリーの確認部分の作成方法についてもう少し詳しく説明する。ここでは、ユーザーストーリーの受容テストを書く際にガイドするため、最も有名なテンプレート「Gherkin」を使用する。このテンプレートは「Given-When-Then」の形式を採用している。

• (Given… そして) ある文脈
• (When… そして) あるアクションが実行される
• (Then… そして) いくつかのアクションを実行する

CucumberやJbehaveといったテストフレームワークは、自動テストを実施する際に「Given/When/Then」テンプレートの使用を推奨しているが、ツールを使用するかどうかに関わらず、単なるヒューリスティックとして使用することも可能である。

「コース登録」ユーザーストーリーに関するすべての情報を集め、3C形式にまとめる。

私は「コース登録」ユーザーストーリーを表現するために一般的に使われる3C形式を採用した。同様に、「コース登録」ユースケースを記述する際に最も広く使われる形式も採用した。ユーザーストーリーの確認部分（最後のC）のステップを、ユースケース記述に記載したステップ番号に対応させて番号付けを行った。これらは、それぞれのアプローチに適用される「9ステップ」のシナリオであり、順序は異なる。私は、それぞれのモデル表現が対応する指導者や支持者にとって受け入れ可能であると考えている。では、再び問うべきは、ユーザーストーリーはユースケースと非常に似ているが、実際には異なるのか、あるいはステップの順序がユースケースアプローチに対してさまざまな批判を引き起こしているのか？

意味的に同等だが、意味は異なる？

モデリング分野に同様の事例があるかどうかを調査し、ここでの状況と比較することで、「ユーザーストーリー対ユースケース」について自らの意見を表明する助けになるかもしれない。しかし、群衆に盲目的に従うか、賢者の言葉を鹦鹉のように繰り返すだけではいけない。

例：意味的に同等

UMLでは、ユースケースのシナリオをシーケンス図で記述できるが、同じ目的で協調図（collaboration diagram）を使うことは通常ない。ただし、両者の図は意味的に同等である。言い換えれば、シーケンス図と協調図の両方とも、同じ数のオブジェクトがシナリオに参加し、同じ数のメッセージが同じオブジェクトの集合間をやり取りして、シナリオのタスクを実行している。しかし、前者は時間的側面に注目し、後者は空間的側面に注目する。シナリオモデリングと組み合わせて使用する際、シーケンス図は直感的である一方、協調図はオブジェクト間の構造的関係をモデリングするのに適している。たとえば、MVCフレームワーク（モデル／ビュー／コントロール層）に参加するオブジェクトのシナリオを構造的に表現したい場合である。

個人的には、ユーザーストーリーを使うことでチームがアジャイルになるとは思わないし、ユースケースを使うことでチームが「前もって」になってしまうとも思わない。最も重要なのは、どのようなマインドセットとベストプラクティスを背景にこれらのツールを適用・使用するかである。実際にアジャイルに行動しているのに、他人に「古風」や「時代遅れ」と思われるのをあまり気にしない。

構造化分析・設計の時代をまだ覚えている。1980年代にOOPのサポートがなくても、ADAの抽象データ型（Abstract Data Type）を使ってオブジェクト指向の分析・設計の原則を適用できたかもしれない。しかし、残念ながら、抽象データ型の概念にすら触れることはないかもしれない！ああ、神様、つい誤って明かしてしまった――私は年を取ったのか？それとも、前向きに考えれば――経験を積んだだけなのか？