Use Case Documentation

ユースケースドキュメント作成スキル

目的

ユーザーが特定の目標を達成するために、システムとどのようにやり取りするかを説明します。ユースケースはユーザー中心の視点から機能要件を捉えたもので、実装前に詳細な仕様が必要となるウォーターフォール型やハイブリッド型の開発環境でよく使用されます。

使用する場面

• 複雑なトランザクションシステム（銀行、医療）。
• 代替フローやエラー処理を厳密に定義する必要がある場合。
• 規制への準拠に詳細なドキュメントが必要な場合。
• ビジネスニーズと技術的な機能仕様との橋渡し。

ユースケースの構成

主な要素

1. ユースケース名：動詞と名詞の句（例：「現金を引き出す」）。
2. ID：一意の識別子（例：UC-ATM-01）。
3. アクター：誰がやり取りしますか？（プライマリ：開始する人、セカンダリ：外部システム）。
4. 説明：目標の簡潔な概要。
5. 事前条件：開始前に満たされていなければならない条件は何ですか？（例：「ユーザーがログインしている」）。
6. トリガー：ユースケースを開始するものは何ですか？（例：「ユーザーが［引き出し］をクリックする」）。
7. 成功シナリオ（基本フロー）：「ハッピーパス」の手順。
8. 代替フロー（拡張）：バリエーションやエラー経路。
9. 事後条件：正常に完了した後に成立している条件は何ですか？（例：「残高が更新されている」）。
10. ビジネスルール：ロジックの関連付け。

ユースケースのテンプレート

例：ATMで現金を引き出す

ID：UC-ATM-01 名前：現金を引き出す プライマリアクター：銀行の顧客 セカンダリアクター：銀行システム（バックエンド）

説明：顧客がATMを利用して、当座預金口座から現金を引き出します。

事前条件：

1. ATMに十分な現金がある。
2. ATMがオンラインである。
3. 顧客が有効なカードとPINを持っている。

トリガー：顧客がカードを挿入する。

成功シナリオ（ハッピーパス）：

1. 顧客がデビットカードを挿入する。
2. システムがカードを読み取れることを確認する。
3. システムがPINの入力を求める。
4. 顧客がPINを入力する。
5. システムが銀行システムでPINを検証する。
6. システムがアプリケーションメニューを表示する。
7. 顧客が「現金を引き出す」を選択する。
8. システムが金額の入力を求める。
9. 顧客が金額（例：$100）を入力する。
10. システムが1日の限度額と口座残高を確認する。
11. システムが取引を承認する。
12. システムが現金を払い出す。
13. システムがレシートを印刷する。
14. システムがカードを排出する。
15. ユースケースが終了する。

代替フロー：

• A1：無効なPIN（ステップ5）

  1. システムが「PINが無効です」というメッセージを表示する。
  2. システムがPINの再入力を求める。
  3. 顧客がPINを再入力する。
  4. ステップ5に戻る。
  • 制約：PINの入力に3回失敗した場合は、**A2（カードをロックする）**を実行する。

• A2：カードをロックする（A1から）

  1. システムが「試行回数が上限に達したためカードをロックしました」というメッセージを表示する。
  2. システムがカードを回収する。
  3. ユースケースが終了する。

• A3：残高不足（ステップ10）

  1. システムが口座残高 < 要求金額であることを確認する。
  2. システムが「残高不足です」と表示する。
  3. システムが金額を減らして入力するか、キャンセルするよう求める。
  4. 顧客が新しい金額を入力する。
  5. ステップ10に戻る。

• A4：ATMの現金不足（ステップ10）

  1. システムが内部の現金払出機の現金 > 要求金額であるか確認する。
  2. システムが現金不足を検知する。
  3. システムが「全額を払い出せません」と表示する。
  4. ユースケースが終了する。

事後条件：

• ユーザーの口座から引き出し額が引き落とされる。
• 取引ログが作成される。
• 現金在庫が更新される。

ユースケースとユーザーストーリーの比較

特徴	ユースケース	ユーザーストーリー
焦点	システムとのやり取りの手順	ユーザーの価値／目標
詳細度	高（フロー、エラー）	低（会話のきっかけ）
形式	ドキュメント／構造化テキスト	カード／付箋（誰が、何を、なぜ）
ライフサイクル	時間をかけて更新／保守	完了後に破棄／アーカイブ
コンテキスト	ウォーターフォール／ハイブリッド／複雑なシステム	アジャイル／スクラム

ベストプラクティス

• 能動態で書く：「システムが PIN を検証する」（「PIN が検証される」ではありません）。
• UI のシステム中立性を保つ：「ユーザーが右上の青いボタンをクリックする」とは書かず、「ユーザーがオプションを選択する」と書きます。
• 目標に焦点を当てる：技術的な詳細（例：「システムが JSON パケットを送信する」）にとらわれないようにします。
• 例外を網羅する：すべてのエラーパスが処理されるようにします。

ツール

• Lark Docs / MS Word：標準的な書式設定に使用します。
• Visual Paradigm / UML Tools：ユースケース図に使用します。
• Gherkin：テスト用にユースケースのフローを Gherkin シナリオに変換できます。