ユーザーストーリー、ユースケース、ジョブストーリー、要件記述は、ソフトウェアが何をすべきかを記述する4つの方法です。これらはしばしば競合として提示されますが、異なる詳細レベルで異なる質問に答えます。ユーザーストーリーは、誰が何をなぜ望むかを尋ねます。ユースケースは、問題が発生した場合も含めて、相互作用をステップバイステップで説明します。ジョブストーリーは、ユーザーが置かれている状況から始まります。要件は、システムが遵守すべきルールを記述します。
このガイドでは、これら4つを比較し、同じ機能を各方法で記述した例を示し、いつどれを使用すべきかを説明します。ストーリー記述の基本については、当社のハブガイドを参照してください。 ユーザーストーリーの書き方.
クイック比較
| ユーザーストーリー | ユースケース | ジョブストーリー | 要件記述 | |
|---|---|---|---|---|
| 形式 | [ユーザー]として、[アクション]を行いたいので、[利益]が得られる | アクター、目標、前提条件、主要成功シナリオ、拡張、事後条件 | [状況]のとき、[動機]を実現したいので、[期待される結果]が得られる | システムは[動作または制約]を実行しなければならない |
| 中心となる要素 | ユーザーの種類と目標 | アクターとシステム間の相互作用 | 状況と動機（ペルソナではない） | システムの動作または品質 |
| 長さ | 1文と受け入れ基準 | 半ページから数ページ | 1文 | 要件ごとに1文、文書ごとに多数 |
| 起源 | エクストリームプログラミング；Connextra（2001年）のフォーマット | Ivar Jacobson（1980年代後半）；Alistair Cockburnの目標ベーススタイル（2000年） | IntercomのPaul Adams；Alan Klementによって開発（2013年） | 従来の要件エンジニアリング（現在はISO/IEC/IEEE 29148） |
| 最適な用途 | アジャイルのバックログとスプリント計画 | 複雑なフロー、統合、規制対象または契約ベースの作業 | 発見とデザイン、特に同じ状況にある多様なユーザー向け | 非機能要件、コンプライアンス、固定スコープの契約 |
| 苦手な点 | 全体フローとエッジケースの可視化 | スピード。高速な反復では最新状態を維持するのが困難 | 計画と見積もりを独自に行う | 理由の説明。テスト不能なリストを記載しがち |
ユーザーストーリー
ユーザーストーリーとは、それを求める人の視点から記述された機能の短い説明です。一般的な形式「[ユーザータイプ]として、[アクション]を行いたい。その結果、[利益]が得られるように」という形式は、2001年にConnextraチームによって提唱され、Mike Cohnの著書『User Stories Applied』を通じて広まりました。ストーリーはExtreme Programming（XP）で発展し、意図的に簡潔に記述されました。Ron Jeffriesは各ストーリーをカード、会話、確認（3Cs）と表現しました。カードは仕様そのものではなく、詳細が合意されるのは会話であり、受入基準がそれを確認します。
強み：ストーリーはスプリント内で見積もりと完了が可能なくらい小さく、非技術的なステークホルダーでも読みやすく、価値（「その結果」）を常に意識できます。Mike Cohnは、 要件としてのユーザーストーリーの利点.
について論じています。限界：個別のストーリーからなるバックログでは、それらがどのように一つのフローに組み合わされるかが見えず、フォーマット上、エラーケースを省略しがちです。チームは前者に対して ユーザーストーリーマップ を、後者に対しては適切に記述された受入基準（弊社の ユーザーストーリーテンプレート).
ユースケース
ユースケースは、アクター（人または他のシステム）が目標を達成するためにシステムを使用する方法を、一連のステップとして、さらにそのシーケンスが分岐したり失敗したりする方法とともに記述します。Ivar Jacobsonは1980年代後半にユースケースを導入し、Alistair Cockburnの著書『Writing Effective Use Cases』（2000年）が、今日多くのチームで使われている目標中心のプレーンテキストスタイルを確立しました（Cockburnのサイト).
完全なユースケースには通常、以下が含まれます：
- プライマリアクター：インタラクションを開始する主体。
- 目標とスコープ：アクターが望むことと、記述対象のシステム。
- 前提条件：すでに真である必要があること。
- トリガー：ユースケースを開始するもの。
- メイン成功シナリオ：すべてが正常に進行した場合の番号付きステップ。
- 拡張：代替パスと失敗パス。それぞれが分岐するステップに紐付けられる。
- 事後条件または保証：成功時と失敗時の終わりに真であること。
強み：拡張セクションにより、何が問題になるかを考えることが強制され、完全なフローが1か所で可視化されるため、統合、決済、監査対象のシステムにおいて価値があります。限界：ユースケースは記述と更新に時間がかかり、1つのユースケースは通常、1つのスプリントで構築するには大きすぎます。
ユースケースはアジャイル開発に適応しています。 Use-Case 2.0において、Jacobsonらは各ユースケースを「スライス」に分割し、それぞれが計画とテスト可能なサイズにしました。これらはユーザーストーリーとほぼ同じ役割を果たします。
ジョブストーリー（Jobs to be Done）
ジョブストーリーはペルソナを状況に置き換えます：「[状況]のとき、[動機]を実現したい。その結果、[期待される結果]を得られるように」。この考えは、Paul AdamsがIntercomブログで初めて言及し、Alan Klementが2013年のIntercomゲスト投稿で説明し発展させました、 ジョブストーリーによる機能設計。これは、Clayton Christensenに関連付けられるJobs-to-be-Doneの思考を機能設計に応用したものです。
ジョブストーリーの利点は、「忙しい親として」という表現にはチームがテストできない仮定が含まれるのに対し、状況（「家を出ようとして、食料品の注文を忘れたことに気づいたとき」）は緊急性、制約、そしてユーザーにとっての「完了」の感覚を説明できる点です。同じ状況にある2つの全く異なるペルソナは、しばしば同じものを必要とします。
強み：ジョブストーリーは発見とデザインにおいて有効で、チームを文脈に集中させ、顧客インタビューのためのより良い質問を生み出します。限界：誰が何を許可されるかについてはほとんど言及しないため、権限や役割には不向きであり、ほとんどのチームは計画のためにそれらをユーザーストーリーやタスクに変換しています。
要件記述
従来の形式は番号付きの記述です：「システムは、5回のサインイン失敗後にアカウントをロックするものとする」。要件仕様は、規制業界、政府の入札、固定価格契約において依然として標準であり、現在の国際標準はISO/IEC/IEEE 29148です。
アジャイルチームも要件記述を使用しますが、主に非機能要件（パフォーマンス、セキュリティ、可用性、アクセシビリティ）など、多くのストーリーにまたがる要件のために使われます。これらは、通常、完了の定義や短い品質属性ページに一度だけ記録され、各ストーリーに繰り返し記載されることはありません。
同じ機能を3つの異なる方法で記述する
機能：ルームメイト向けの共有費用アプリで、ある人が何かを購入し、その費用を他の人と分割する。
ユーザーストーリーとして
共有購入の支払いをしたルームメイトとして、その購入に関わった人々と費用を分割したい。そうすることで、全員が私にいくら支払うべきかを示す残高を確認できる。
- 費用を共有するグループメンバーを選択できる。デフォルトでは自分も含まれる。
- デフォルトの分割は均等だが、正確な金額やパーセンテージに切り替えることができる。
- 合計額と一致しない分割は保存されず、差額がいくらかが通知される。
- 費用が保存されるとすぐに各人の残高が更新され、通知が届く。
ユースケースとして
ユースケース：費用の分割。プライマリアクター：支払者。前提条件：支払者がログイン済みであり、少なくとも1人の他のメンバーがいるグループに属している。トリガー：支払者が「費用を追加」を選択する。
- 支払者が金額、説明、日付を入力する。
- システムがグループメンバーを表示し、支払者が選択されている状態にする。
- 支払者が費用を共有するメンバーを選択する。
- システムが均等分割を提案し、各人の分担額を表示する。
- 支払者が確認する。
- システムが費用を保存し、すべての残高を更新し、選択されたメンバーに通知する。
- 4a. 支払者が正確な金額やパーセンテージに切り替える場合：システムが各値の入力に応じて再計算する。
- 5a. 分担額が合計額と一致しない場合：システムが保存をブロックし、差額を表示する。
- 6a. デバイスがオフラインの場合：システムが費用をローカルに保存し、保留状態としてマークし、オンラインに戻った際に同期する。
- 成功時の事後条件：費用が一度だけ記録され、すべての残高がそれを反映する。失敗時の事後条件：残高は変更されない。
ジョブストーリーとして
レジでルームメイトの分も含まれるものを支払った直後、金額を忘れる前に記録したい。そうすることで、誰かに催促しなくても返金を受け取れる。
要件記述として
- REQ-1：システムは、グループメンバーが金額、説明、日付、支払者を指定して費用を記録できるようにしなければならない。
- REQ-2：システムは、支払者が費用を均等、正確な金額、またはパーセンテージで分割できるようにしなければならない。
- REQ-3：システムは、部分の合計が総額と等しくない分割を拒否しなければならない。
- REQ-4：システムは、保存から2秒以内にすべての影響を受ける残高を更新しなければならない。
各バージョンが何を浮き彫りにしたかを見てみましょう。ユーザーストーリーは推定と計画が最も容易です。ユースケースは、オフラインのケースを提起し、保存が失敗した場合に真でなければならないことを明記した唯一の形式です。ジョブストーリーは、レジでの速度という実際の制約を明らかにしました。これは、最初の画面で金額だけを尋ねるべきであることを示唆しており、他のどのバージョンもこの点を促すことはありませんでした。要件記述は、ストーリーが暗黙のうちに含んでいた測定可能なパフォーマンス目標を追加しました。
どれを使うべきか？
| 状況 | 開始点 | 理由 |
|---|---|---|
| 初期の発見、インタビュー、何を構築するかを決める段階 | ジョブストーリー | チームをユーザーの文脈に集中させ、より良いインタビュー質問を生む |
| アジャイルプロダクトバックログ、スプリント計画 | 受け入れ基準付きのユーザーストーリー | 小さく、推定可能で、全員が読める |
| 複雑なフロー、統合、資金移動 | ユースケースを作成し、それをストーリーにスライスする | 拡張により、バグになる前に失敗パスが明らかになる |
| 規制対象の製品、公募入札、固定価格契約 | 要件記述、多くの場合ユースケースにトレーサビリティを持たせる | 監査や契約には、番号付きで検証可能な記述が必要 |
| パフォーマンス、セキュリティ、アクセシビリティの目標 | 要件記述、または完了定義（Definition of Done） | 1つのストーリーではなく、多くのストーリーにまたがるもの |
| 小規模チームによるMVP | ユーザーストーリーのストーリーマップ、最もリスクの高い1つのフローにはユースケースを付与 | 迅速にスコープを定義し構築するのに十分な構造 |
これらを組み合わせることは可能か？
はい、成熟したチームの多くはそうしています。実用的な順序は次のようになります：
- 調査中はジョブストーリーを使用し、実際のユーザーの状況や動機を捉えます。
- 得られた機能を ストーリーマップ 上にユーザーストーリーとして配置し、最初のリリーススライスを選びます。
- 失敗がコストの高い1〜2つのフロー（支払い、サインアップ、データ同期など）については、拡張性を発見するために軽量なユースケースを作成し、各拡張を個別のストーリーまたは受け入れ基準に変換します。
- 横断的な要件（パフォーマンス、セキュリティ、アクセシビリティ、コンプライアンス）は、番号付き記述または完了定義として一度だけ記録します。
基本原則：チームが正しいものを安全に構築するために必要な分だけ記述する。3人のMVPチームに要件ドキュメントは不要ですが、銀行連携を1文に頼るべきではありません。
よくあるミス
- ユースケースをUIスクリプト（「ユーザーは青いボタンをクリックする」など）として記述し、要件が変わる設計に紐付けてしまうこと。
- 「so that（〜するために）」を欠いたユーザーストーリーを記述し、チームがよりシンプルな解決策を提案できなくしてしまうこと。
- ジョブストーリーを仮面をかぶったペルソナ（「忙しい母親であるとき...」など）として扱うこと。状況は瞬間であり、アイデンティティではありません。
- 長い要件リストをバックログにコピーし、1行ごとに1つのストーリーとして扱うこと。これにより、ユーザーも価値もないストーリーが生まれます。
- 同じバックログで異なるフォーマットを使用し、どれが真実の源（Source of Truth）かについて合意がないこと。
よくある質問
ユーザーストーリーとユースケースの主な違いは何ですか？
ユーザーストーリーは、誰がどのような機能が必要で、なぜ必要かを1文で記述し、作業の計画と優先順位付けに使用されます。ユースケースは、アクターとシステム間の相互作用を、代替パスや失敗パスを含めてステップバイステップで記述します。ストーリーは小さく詳細度が低く、ユースケースはフロー全体を示します。
ユーザーストーリーは要件ですか？
要件を軽量に捉える方法ですが、完全な仕様ではありません。詳細は会話と受け入れ基準に存在します。パフォーマンスやセキュリティなどの非機能要件は、別々に記録されることが多いです。
アジャイルチームではまだユースケースは使われていますか？
はい、主に複雑または高リスクのフローで使用されます。Ivar Jacobson氏らが提唱したUse-Case 2.0では、ユースケースをユーザーストーリーのように計画できるスライスに分割するため、両者は同じバックログで共存できます。
ジョブストーリーとユーザーストーリーの違いは何ですか？
ユーザーストーリーはユーザーのタイプ（「〜として...」）から始まります。ジョブストーリーは状況（「〜するとき...」）から始まり、動機と期待される結果に焦点を当てます。ジョブストーリーはJobs-to-be-Doneの考え方に由来し、ディスカバリーとデザインで最も有用です。
1つのユースケースが複数のユーザーストーリーになることはありますか？
はい。メインの成功シナリオは通常1〜2つのストーリーになり、各重要な拡張は個別のストーリーまたは受け入れ基準になります。これは、エッジケースを失うことなく大きな機能を分割するための信頼できる方法です。
ユースケースとテストケースの違いは何ですか？
ユースケースは、アクターの目標を達成するためにシステムがどのように動作すべきかを記述します。テストケースは、特定の入力と期待される結果を用いて、その動作の1つの特定のパスを確認します。1つのユースケースから通常複数のテストケースが生成されます。
製品にどの程度の仕様が必要か迷っていますか？私たちは創業者がアイデアをスコープの定まったバックログに変え、短いスプリントで構築するのを支援します。詳しくは 月額開発プラン.