開発の柔軟性（アジリティ）と顧客志向に重きを置かれるソフトウェア開発において、「ユーザーストーリー」と「ユースケース」というのはどちらもよく耳にする重要なコンセプトです。具体的にその違いは具体的に何でしょうか。この記事では利用される場面・目的はもちろん、様々な角度からその違いを理解し、なぜそのツールを使うのかをビジネスチーム・開発チームが明らかにできる一助にして頂けると嬉しいです。
共通点
違いを理解する前に以下に両者の共通点を整理しました。
- 要件定義ツール：システム開発において要件を明確化するために使用されます。
- 顧客志向：どちらもエンドユーザーの視点から要件を捉えます。
どちらも利用されるフェーズは、プロダクト設計～要件定義のような上流工程フェーズです。（アジャイル開発の文脈で目にする Discovery phase、Product visioning、という表現もこのフェーズに該当します。）
また、単純に機能を並べて「要件」をまとめるのではなく、「誰（ユーザー）」が何をしたいのか顧客を主語にして要件を引き出していく過程も共通です。
定義の違い
a. ユーザーストーリー
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.”
(ユーザーストーリーとは、システムのユーザーや顧客といった新しい機能を望む人の視点から語られる、短く簡潔な機能の説明です。)出典：Mike Cohn, “User Stories Applied: For Agile Software Development”
b. ユースケース
“A use case is a sequence of actions that provide a measurable value to an actor.”
(ユースケースは、アクターに測定可能な価値を提供する一連の動作です。)出典: Ivar Jacobson, “Object-Oriented Software Engineering: A Use Case Driven Approach”
上記2つの定義からまとめると以下の通りです。
| 種類 | 記述内容 | ユーザーの何を理解できるか |
|---|---|---|
| a. ユーザーストーリー | 機能説明 | こんな機能がほしい（具体的な動きはわからない）という要望 |
| b. ユースケース | 動作の列挙 | （ユーザーの要望を満たすためには）こんな動作が必要だとの考え |
最も大きな違いは、ユーザーストーリーは「機能説明」であるのに対し、ユースケースは「動作の列挙」である点です。ユーザーストーリーが与えられている場合は、その要望を満たすために正解の動作というのは無く、ソフトウェアを見てユーザーが「これが欲しかった」と感じるものが正解です。（少し極端な言い方ですが）
一方で、ユースケースは動作そのもの（場合によってはシステム機能そのもの）を記述しているので、その動きが満たされること＝要件通りのソフトウェア、ということになります。
アウトプットの型の違い
a. ユーザーストーリー
［ユーザー］として、［何］を実現したい。それは［こんな理由］のためです。
‐ “As a [type of user], I want [to be able to perform an action] so that [a goal is achieved].”
b. ユースケース
アクター：［A］［B］
目標 ：AはXXでYYをしたい
主なフロー（メインフロー）：
・Aは〇〇する
・Bは△△する 等
代替フロー：
・Aは〇〇できなかったら、□□という方法で代替する
例外フロー：
・Bは△△できなかったら、終了する
事後条件：
・XXでYYが追加された状態となる
ユースケースはちょっと分かりづらいので、実際の記述例も以下からご参考下さい。実はユースケースの型としては、各フロー1つ1つが「ユースケース」ではなく、これら全体記述をまとめて「ユースケース」と定義されています。
ユースケースの記述例（オンラインショップでの注文）
アクター：顧客、ショップシステム
目標：
顧客はオンラインショッピングシステムを通じて商品を注文したい。
主なフロー（メインフロー）：
・顧客は店舗システムにログインします。
・顧客は製品カタログを閲覧し、希望する製品を選択します。
・システムには、価格や在庫状況などの製品情報が表示されます。
・顧客は製品をショッピングカートに追加します。
・顧客はショッピングカートを表示し、注文を確認し、チェックアウトプロセスに進みます。
・システムは顧客に配送情報の入力を求めます。
・顧客は配送情報を入力し、注文を確認します。
・システムは注文を処理し、顧客の支払い方法から未払いの金額を差し引いて、注文確認を生成します。
・顧客は注文の確認を電子メールで受け取ります。
代替フロー：
製品の在庫がない場合は、顧客に通知され、カートから製品を削除するか、再入荷するまで待つかを決定できます。
事後条件：
製品は顧客の注文に追加されます。
システムは注文確認を生成し、顧客に送信します。
アウトプットの型は、ユーザーストーリーが（1つの単位という意味では）より軽量なのに対し、ユースケースがより包括的で詳細な記述が求められる＝重いという違いがあります。ただし、前者は型の決まりが最低限かつ柔軟であるがゆえ、「どう書いたらいいかわからない」という迷いも生じやすいです。
よく利用される開発手法の違い
a. ユーザーストーリー
- アジャイル開発
- スクラム
- エクストリーム・プログラミング（XP）
- リーン開発
- カンバン方式
-> 柔軟性や機敏性（アジリティ）を重視し、反復的なサイクルで開発をするような手法。短期的な計画も可能で、その中で顧客フィードバックを頻繁に取り入れるという特徴がある。
b. ユースケース
- ウォーターフォールモデル
- 統一プロセス（UP）
- Vモデル
- スパイラルモデル
-> より体系的で詳細な計画を立てる事が多く、フェーズごとの明確な区切りがある手法。包括的な文書化を重視する傾向もある。
まとめると、より不確実性の高いシステム開発においてはユーザーストーリーを、初期段階における要件定義や設計で多くのことを決定できるシステム開発ではユースケースを利用することが多いです。
次工程以降のプロセスの違い
両者のいずれかを用いて要件定義を行った場合、その後のプロセスには以下のような違いが生まれます。
| 後続工程で想定されるプロセス* | a. ユーザーストーリー | b. ユースケース |
|---|---|---|
| 具体的機能への詳細化 | 必要 | ほぼ不要 |
| 詳細設計 (アーキテクチャや振る舞い) | 必要 | 必要 |
| 要件変更の受け入れ | 容易 | 困難 |
| テストケースの作成 | 必要 | 必要だが流用可 |
| 受け入れ基準の作成 | 必要 | 必要だが流用可 |
| リリース | 細かく区切った リリース(も可) | ある程度まとめた リリース |
| ユーザーマニュアル | 必要 | 必要だが流用可 |
| 保守体制への移行(引継ぎ) | 人が代わると 比較的困難 | 人が代わっても 比較的容易 |
ここで注目すべきは、必要な後続工程によっては一見ライトに見える「ユーザーストーリー」を用いた要件定義も、トータルでは多くの工数・手間をかけることになりえる。という点です。
ソフトウェアをまさに構築する・新たに生み出すタイミングで、ユーザーにとっての価値の高いプロダクトを作るために柔軟性や機敏性を重視する場合、その後の工程はどのように進めたいか？も同時に考慮することが意外と大事そうです。
まとめ
改めて両者の違いを本当に完結に表現すると、以下のように捉えることができます。
- ユーザーストーリーは、ユーザーがシステムに期待する価値だけを記述するもの。細かいことは考えないが、ユーザー解像度をあげるもの。
- ユースケースは、ユーザーがシステムに期待する機能まで記述するもの。細かいことまで考えて、以降の工程を楽にするもの。
2つのツールはプロジェクトの性質や組織・チームの特徴（場合によってはその業界の文化）に応じて適切に選択することはもちろん、組み合わせることも有効な選択肢です。例えば、全体的なシステム設計にユースケースを使用し、個々の機能開発にユーザーストーリーを使用するなどです。両者の長所を活かしたバランスのよい活用方法を検討しましょう。
フクロウの図表ラボ 