SDD(仕様駆動開発)におけるユースケースとユーザーストーリーの違い
ユースケースとユーザーストーリーは同じものではありません。
どちらも「要求を表現する手法」ですが、役割がまったく違います。
この2つを混同すると、アジャイル開発もSDD(仕様駆動開発)も機能しなくなります。
結論から言うと、ユーザーストーリーは要求の入口、ユースケースは仕様の骨格です。
ストーリーは「なぜ作るか」を示し、ユースケースは「どう振る舞うか」を定義します。
ユーザーストーリーとは何か
ユーザーストーリーは、ユーザーの価値を短い文章で表現する方法です。
一般的な形式があります。
私は（誰として） （何を）したい なぜなら（価値）
例：
私はECサイトの購入者として 購入履歴を確認したい なぜなら以前買った商品を再注文したいから
重要なのは、ここには仕様が書かれていないことです。
画面も、データ構造も、エラー処理もありません。
ユーザーストーリーの目的は、機能一覧を作ることではありません。
開発する理由をチームで共有することです。
これにより、不要な機能を作らなくなります。
ストーリーは設計書ではなく、意思決定の指針です。
ユースケースとは何か
ユースケースは、システムの振る舞いを定義する仕様です。
ユーザーとシステムの相互作用を時系列で記述します。
同じ例をユースケースにするとこうなります。
基本フロー
- ユーザーがログインする
- 購入履歴ページを開く
- システムは購入履歴一覧を表示する
代替フロー
- ログインしていない場合、ログイン画面へ遷移
- 購入履歴が存在しない場合、空状態を表示
ここで初めて仕様が登場します。
システムの挙動が明確になります。
違いを整理する
| 項目 | ユーザーストーリー | ユースケース |
| 目的 | 価値の共有 | 振る舞いの定義 |
| 粒度 | 小さい | 中〜大 |
| 内容 | 要求の動機 | 処理の流れ |
| 読者 | 全員（非技術者含む） | 主に開発・テスト |
| 役割 | 優先順位決定 | 実装とテストの基準 |
両者は競合しません。
連続した工程です。
ユーザーストーリー → ユースケース → 受け入れ基準
この順で具体化します。
なぜ混同すると問題が起きるのか
よくある誤りは、ユーザーストーリーを仕様として扱うことです。
例えば：
- 「ユーザーが簡単に検索できるようにする」
これをそのまま開発に渡すと、解釈が分裂します。
- 開発者：検索ボックスを置く
- デザイナ：サジェストを出す
- テスター：検索できればOK
どれも間違いではありませんが、期待は一致しません。
結果としてレビューで「思っていたのと違う」が発生します。
ユーザーストーリーは抽象的であることが価値です。
しかしそのままでは仕様になりません。
SDD(仕様駆動開発)での使い分け
SDDでは次のように扱います。
1. ユーザーストーリーで価値を決める
2. ユースケースで振る舞いを決める
3. 受け入れ基準で検証可能にする
この3段階で初めて実装可能な仕様になります。
具体例：パスワードリセット
ユーザーストーリー：
- ユーザーとして、パスワードを忘れてもログインしたい
ユースケース：
- メールアドレスを入力
- 確認URLを送信
- URLから新パスワード設定
受け入れ基準：
- URLの有効期限は24時間
- 使用後は再利用不可
- 5回失敗で無効化
役割が完全に違います。
ストーリーだけで開発すると何が起きるか
ストーリーのみで進めると、スプリントレビューが感想会になります。
- 使いづらい
- なんとなく違う
- 思ったより面倒
これは品質問題ではありません。
評価基準が存在しない状態です。
ユースケースがあると、レビューは検証になります。
- 代替フローが満たされているか
- 例外処理があるか
- 状態遷移が正しいか
議論が主観から客観へ変わります。
注意点：ユースケースを巨大化させない
ユースケースの失敗は、詳細設計書になることです。
悪い例：
- DBテーブル定義
- APIパラメータ
- クラス構造
これは設計です。
ユースケースは振る舞いまでです。
技術的実装を書き始めると、変更に弱くなります。
まとめ
ユーザーストーリーとユースケースは代替手法ではありません。
役割分担です。
ユーザーストーリーは「なぜ作るか」を示し、
ユースケースは「どう動くか」を定義します。
ストーリーだけでは曖昧になり、
ユースケースだけでは価値を見失います。
SDD(仕様駆動開発)では、この2つを接続して初めて仕様になります。
まずストーリーを書き、次にユースケースを書いてみてください。
要求と実装の距離が、驚くほど短くなるはずです。
