---
type: Reference
title: "ユースケース作成ガイド"
description: "このガイドは、XPプログラマ向けの実用的なユースケース作成手法を提供します。"
tags: [reference]
status: stable
generated: { by: human:kakimomokuri, at: 2026-04-06T03:31:33Z }
---

# ユースケース作成ガイド

## はじめに

このガイドは、XPプログラマ向けの実用的なユースケース作成手法を提供します。ユースケースはシステムの振る舞いに関する利害関係者との契約であり、アジャイル開発においても要求を明確化する重要なツールです。

## ユースケースの基本概念

### ユースケースとは

ユースケースは、システムの振る舞いに関する利害関係者間の契約を表現するものです。

```plantuml
@startuml
title ユースケースの構成要素

actor ユーザー as user
actor 管理者 as admin
actor 外部システム as external

rectangle システム {
  usecase "商品を注文する" as UC1
  usecase "在庫を確認する" as UC2
  usecase "ユーザーを認証する" as UC3
  usecase "レポートを生成する" as UC4
}

user --> UC1
user --> UC2
admin --> UC4
UC1 ..> UC3 : <<include>>
UC1 ..> UC2 : <<include>>
external --> UC2
@enduml
```

### XPとユースケース

XPのユーザーストーリーとユースケースの関係：

- **ユーザーストーリー**：イテレーション単位の小さな要求
- **ユースケース概要**：ユーザーストーリーをまとめた機能群
- **完全形式ユースケース**：詳細な振る舞いの定義

## 1. ユースケースの3つのレベル

### レベルの階層構造

```plantuml
@startmindmap
* システム全体
++ ☁️要約レベル（数日〜数ヶ月）
+++ 🌊ユーザー目的レベル（数分〜数時間）
++++ 🐟サブ機能レベル（数秒〜数分）
-- ビジネスプロセス全体
--- 複数のユーザー目的を含む
--- ライフサイクル全体を表現
-- 個別の目的達成
--- ユーザーが満足して立ち去れる単位
--- 基本ビジネスプロセス
-- 目的達成のための部品
--- 共通機能の切り出し
--- 再利用可能な処理
@endmindmap
```

### レベル判定の質問

**ユーザー目的レベルの判定**

- 主アクターはこれを実行した後で満足して立ち去れるか？
- これは1回の作業セッションで完了するか？

**要約レベルの判定**

- 複数のユーザー目的が含まれているか？
- 時間をかけて実行される長いプロセスか？

**サブ機能レベルの判定**

- これだけでは目的が達成されないか？
- 他のユースケースから呼び出される共通処理か？

## 2. スコープの定義

### 設計スコープの種類

```plantuml
@startuml
title 設計スコープの境界

package "🏢組織（企業全体）" {
  package "💻システム（ソフトウェア）" {
    package "💾コンポーネント" {
      [モジュールA]
      [モジュールB]
    }
  }
  actor 社員
  actor 外部システム
}

actor 顧客

顧客 --> 社員 : 依頼
社員 --> [モジュールA] : 操作
[モジュールA] --> [モジュールB] : 連携
[モジュールB] --> 外部システム : API呼び出し
@enduml
```

### In/Outリストの作成

スコープを明確にするために、何が範囲内で何が範囲外かを整理：

| トピック | In | Out | 備考 |
|---------|----|----|------|
| ユーザー認証 | ✓ | | システムで実装 |
| 決済処理 | | ✓ | 外部サービス利用 |
| 在庫管理 | ✓ | | コア機能 |
| 配送手配 | | ✓ | 物流会社API |
| レポート生成 | ✓ | | 管理機能 |

## 3. アクターの識別

### アクター分析チェックリスト

```plantuml
@startuml
title アクターの種類と関係

actor "主アクター" as primary #lightblue
actor "支援アクター" as support #lightgreen
actor "オフステージアクター" as offstage #lightyellow

rectangle "システム" as system

primary --> system : 目的を持って\n操作する
system --> support : サービスを\n要求する
offstage ..> system : 利益を持つが\n直接操作しない

note right of primary : システムを使って\n目的を達成する人
note right of support : システムが依存する\n外部サービス
note right of offstage : 規制当局、\n管理者など
@enduml
```

### アクター・目的リスト

優先度付きでアクターの目的を整理：

| アクター | 目的 | レベル | 優先度 | 頻度 |
|---------|------|--------|--------|------|
| 購入者 | 商品を検索する | 🌊 | 高 | 100回/日 |
| 購入者 | 注文する | 🌊 | 高 | 50回/日 |
| 購入者 | 注文履歴を確認する | 🌊 | 中 | 20回/日 |
| 管理者 | 在庫を更新する | 🌊 | 高 | 30回/日 |
| 管理者 | レポートを生成する | ☁️ | 中 | 5回/日 |
| システム | 在庫を自動補充する | 🌊 | 高 | 10回/日 |

## 4. ユースケース記述プロセス

### 段階的詳細化アプローチ

```plantuml
@startuml
title ユースケース作成の段階的詳細化

[*] --> 精度レベル1
精度レベル1 --> 精度レベル2
精度レベル2 --> 精度レベル3
精度レベル3 --> 精度レベル4
精度レベル4 --> [*]

精度レベル1 : アクター名と目的
精度レベル1 : ・アクター・目的リスト
精度レベル1 : ・1行記述

精度レベル2 : ユースケース概要
精度レベル2 : ・主成功シナリオ
精度レベル2 : ・段落形式の記述

精度レベル3 : 拡張条件の追加
精度レベル3 : ・例外処理の識別
精度レベル3 : ・代替パスの定義

精度レベル4 : 完全形式
精度レベル4 : ・拡張処理ステップ
精度レベル4 : ・事前/事後条件
精度レベル4 : ・保証の定義
@enduml
```

### 12ステップの作成プロセス

1. **システムのスコープと境界を識別**
2. **主アクターの一覧作成**
3. **ユーザー目的の洗い出し**
4. **要約レベルユースケースの作成**
5. **要約レベルの見直しと統合**
6. **詳細化するユースケースの選択**
7. **利害関係者と保証の定義**
8. **主成功シナリオの記述**
9. **例外条件の洗い出し**
10. **拡張処理ステップの記述**
11. **複雑なフローの分割と統合**
12. **全体の整理と見直し**

## 5. ユースケーステンプレート

### 完全形式テンプレート

```markdown
# UC-[番号]: [スコープアイコン][ユースケース名][レベルアイコン]

**コンテキスト**: [一般的に起きる条件や状況の説明]

**スコープ**: [設計対象システム]

**レベル**: [要約/ユーザー目的/サブ機能]

**主アクター**: [目的を持つアクター]

**利害関係者と利益**:

- [利害関係者1]: [その利益]
- [利害関係者2]: [その利益]

**事前条件**: 

- [すでに真であると想定している状態]

**トリガー**: [ユースケースを開始するイベント]

**最低保証**: [失敗時でも守られる利益]

**成功時保証**: [成功時に達成される状態]

**主成功シナリオ**:

1. [アクター]が[アクション]する
2. システムが[処理]する
3. ...

**拡張**:

- 1a. [条件]: 
    - 1a1. [代替処理]
- 2-4a. [いつでも発生する条件]:
    - 2-4a1. [処理]

**技術およびデータのバリエーション**:

- ステップ1: [バリエーション]
```

### 略式テンプレート（XP向け）

```markdown
# [ユースケース名]

**主アクター**: [アクター名]
**スコープ**: [システム名]
**レベル**: [レベル]

[主成功シナリオを段落形式で記述。システムの振る舞いと
アクターの相互作用を自然な文章で表現]

[代替パスや例外処理を段落形式で記述]

**頻度**: [実行頻度]
```

### ユースケース概要（ユーザーストーリー形式）

```markdown
# [機能名]

**として**: [アクター]
**したい**: [目的/機能]
**なぜなら**: [ビジネス価値]

**受入条件**:

- [ ] [条件1]
- [ ] [条件2]
```

## 6. シナリオの書き方

### 良いステップの書き方

```plantuml
@startuml
title ステップ記述のレベル

participant アクター as A
participant システム as S
participant 外部システム as E

== 🌊ユーザー目的レベル ==
A -> S: 1. 商品を注文する
activate S
S -> S: 2. 在庫を確認する
S -> A: 3. 注文を確認する
deactivate S

== 🐟サブ機能レベル（詳細） ==
A -> S: 1. ユーザー名とパスワードを入力する
activate S
S -> S: 2. 認証情報を検証する
S -> E: 3. 認証サーバーに問い合わせる
E -> S: 4. 認証結果を返す
S -> A: 5. ログイン結果を表示する
deactivate S
@enduml
```

### ステップ記述のガイドライン

**やるべきこと**

- ✅ アクターの意図を表現する
- ✅ 「誰が何をする」を明確にする
- ✅ 成功する目的として記述する
- ✅ 情報の流れを明確にする

**避けるべきこと**

- ❌ UIの詳細を記述する
- ❌ 「チェックする」ではなく「確認する」
- ❌ 実装の詳細に踏み込む
- ❌ IF文を使う（拡張に記載）

### ステップ数の目安

```plantuml
@startuml
title 適切なステップ数

rectangle "理想的" #lightgreen {
  (3〜9ステップ)
}

rectangle "許容範囲" #yellow {
  (2〜10ステップ)
}

rectangle "要分割" #lightcoral {
  (11ステップ以上)
}

note bottom of "理想的" : 読みやすく\n理解しやすい
note bottom of "許容範囲" : 状況により\n許容
note bottom of "要分割" : サブユースケース\nに分割を検討
@enduml
```

## 7. 拡張の記述

### 拡張条件の識別

```plantuml
@startuml
title 拡張の分岐パターン

start
:主成功シナリオ;
if (条件A?) then (yes)
  :拡張処理A;
  :主シナリオに戻る;
else (no)
  if (条件B?) then (yes)
    :拡張処理B;
    stop
  else (no)
    :通常処理継続;
  endif
endif
:次のステップ;
stop
@enduml
```

### 拡張の記述形式

```markdown
**主成功シナリオ**:

1. ユーザーが商品を選択する
2. システムが在庫を確認する
3. ユーザーが数量を指定する
4. システムが合計金額を計算する
5. ユーザーが注文を確定する

**拡張**:

- 2a. 在庫がない:
    - 2a1. システムが在庫なしを通知する
    - 2a2. ユーザーが別の商品を選択する（ステップ1へ）

- 3a. 数量が在庫を超える:
    - 3a1. システムが利用可能数量を表示する
    - 3a2. ユーザーが数量を調整する

- *a. ユーザーがキャンセル:
    - *a1. システムがトランザクションを破棄する
    - *a2. 終了
```

## 8. データ記述の精度

### 3段階のデータ精度

```plantuml
@startuml
title データ記述の精度レベル

class 精度レベル1 {
  ニックネーム
  --
  "顧客情報"
  "注文データ"
  "商品リスト"
}

class 精度レベル2 {
  フィールド群
  --
  顧客情報:
  - 氏名
  - 住所
  - 電話番号
}

class 精度レベル3 {
  詳細仕様
  --
  氏名: String(100)
  住所: String(200)
  電話番号: String(20)
  + NotNull制約
  + 形式チェック
}

精度レベル1 --> 精度レベル2 : 詳細化
精度レベル2 --> 精度レベル3 : 詳細化

note bottom of 精度レベル1 : ユースケースで使用
note bottom of 精度レベル3 : 設計書で定義
@enduml
```

## 9. 品質チェックリスト

### ユースケース全体のチェック項目

| カテゴリ | チェック項目 | ✓ |
|---------|------------|---|
| **タイトル** | 動詞句で目的を表現しているか | □ |
| | システムが達成可能な目的か | □ |
| **スコープ** | 明確に定義されているか | □ |
| | ブラックボックスとして扱っているか | □ |
| **レベル** | 適切なレベルが選択されているか | □ |
| | 内容がレベルと一致しているか | □ |
| **主アクター** | 振る舞いを持っているか | □ |
| | システムへの明確な目的があるか | □ |
| **事前条件** | 必須かつ検証可能か | □ |
| | ユースケース内で再チェックしていないか | □ |
| **保証** | 利害関係者の利益が守られているか | □ |
| | 成功時に目的が達成されるか | □ |
| **シナリオ** | 3〜9ステップに収まっているか | □ |
| | トリガーから保証まで進んでいるか | □ |

### ステップ記述のチェック項目

- □ 成功する目的として表現されているか
- □ アクターが明確か
- □ 意図が明確か
- □ UI設計を含んでいないか
- □ 情報の流れが明確か
- □ 「確認する」を使っているか（「チェックする」ではなく）

## 10. XPプロジェクトでの活用

### ユーザーストーリーとの連携

```plantuml
@startuml
title ユースケースからユーザーストーリーへの分解

package "ユースケース" {
  rectangle "🌊商品を注文する" as UC
}

package "ユーザーストーリー" {
  rectangle "商品を検索する" as US1
  rectangle "カートに追加する" as US2
  rectangle "配送先を入力する" as US3
  rectangle "支払い方法を選択する" as US4
  rectangle "注文を確定する" as US5
}

UC --> US1
UC --> US2
UC --> US3
UC --> US4
UC --> US5

note right of UC : 1つのユースケース
note right of US3 : イテレーション単位の\nストーリーに分解
@enduml
```

### イテレーション計画での利用

1. **リリース計画時**

     - 要約レベルのユースケースで全体像を把握
     - 大まかな規模見積もり

2. **イテレーション計画時**

     - ユーザー目的レベルをストーリーに分解
     - 詳細な見積もりと優先順位付け

3. **実装時**

     - ユースケースを設計ガイドとして利用
     - 受入テストケースの基準

### ユースケースから機能リストへ

```markdown
## UC-001: 商品を注文する

### 抽出された機能リスト

| ID | 機能 | 優先度 | ストーリーポイント |
|----|------|--------|------------------|
| F1.1 | 商品検索機能 | 必須 | 3 |
| F1.2 | カート追加機能 | 必須 | 2 |
| F1.3 | 在庫確認機能 | 必須 | 3 |
| F1.4 | 配送先入力機能 | 必須 | 2 |
| F1.5 | 支払い処理機能 | 必須 | 5 |
| F1.6 | 注文確認メール送信 | 重要 | 2 |
| F1.7 | 注文履歴保存 | 重要 | 1 |
```

## 11. テストケースへの変換

### ユースケースベースのテスト設計

```plantuml
@startuml
title ユースケースからテストケースへ

rectangle "ユースケース" as UC {
  rectangle "主成功シナリオ" as MSS
  rectangle "拡張1" as EX1
  rectangle "拡張2" as EX2
  rectangle "拡張3" as EX3
}

rectangle "テストケース" as TC {
  rectangle "正常系テスト" as NT
  rectangle "異常系テスト1" as AT1
  rectangle "異常系テスト2" as AT2
  rectangle "異常系テスト3" as AT3
  rectangle "境界値テスト" as BT
}

MSS --> NT
EX1 --> AT1
EX2 --> AT2
EX3 --> AT3
UC --> BT

note bottom of TC : 各パスを網羅する\nテストケースを生成
@enduml
```

### テストケーステンプレート

```markdown
## テストケース: [ユースケース名]_[パス]

**基になるユースケース**: UC-XXX
**テストパス**: 主成功シナリオ/拡張XX

**事前条件**:

- [システムの初期状態]
- [必要なテストデータ]

**入力**:
1. [入力データ1]
2. [入力データ2]

**期待結果**:

- [期待される出力]
- [期待される状態変化]
- [期待される副作用]

**事後条件**:

- [システムの最終状態]
```

## 12. よくある問題と対策

### 問題パターンと解決策

| 問題 | 症状 | 解決策 |
|------|------|--------|
| スコープ不明確 | 要求が増え続ける | In/Outリスト作成 |
| レベル混在 | ステップが不均一 | レベルアイコン使用 |
| UI記述 | 実装に依存 | 意図の記述に変更 |
| 長すぎる | 10ステップ以上 | サブユースケース分割 |
| 曖昧な記述 | 解釈が複数 | 具体例の追加 |
| 保証なし | 目的が不明 | 利害関係者分析 |

### アンチパターン

```plantuml
@startuml
title ユースケースのアンチパターン

rectangle "❌ 悪い例" as bad {
  usecase "データを処理する" as UC1
  usecase "画面を表示する" as UC2
  usecase "ボタンをクリックする" as UC3
}

rectangle "✅ 良い例" as good {
  usecase "注文を確定する" as UC4
  usecase "在庫を確認する" as UC5
  usecase "支払いを処理する" as UC6
}

note bottom of bad : 技術的すぎる\nUI依存\n目的が不明
note bottom of good : ビジネス目的\n実装独立\n価値が明確
@enduml
```

## まとめ

### ユースケース作成の原則

1. **読みやすさ優先**

     - 完璧さより理解しやすさ
     - 自然な言葉で記述

2. **段階的詳細化**

     - 広く浅くから始める
     - 必要に応じて深堀り

3. **適切なレベル選択**

     - ユーザー目的を中心に
     - サブ機能は最小限に

4. **XPとの統合**

     - ユーザーストーリーと連携
     - イテレーション計画で活用
     - テストケースの基準

### クイックリファレンス

**アイコン凡例**

- 🏢 組織スコープ
- 💻 システムスコープ
- 💾 コンポーネントスコープ
- ☁️ 要約レベル
- 🌊 ユーザー目的レベル
- 🐟 サブ機能レベル

**記述の黄金律**

- 3〜9ステップ
- アクターの意図を記述
- UI詳細は書かない
- 成功する目的として表現

このガイドを参考に、プロジェクトに適したユースケースを作成し、XP開発プロセスに統合してください。