@k2works/claude-code-booster 3.4.1 → 3.6.0

package/lib/assets/docs/reference//343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/344/275/234/346/210/220/343/202/254/343/202/244/343/203/211.md

@@ -1,683 +1,690 @@
-# ユースケース作成ガイド
-
-## はじめに
-
-このガイドは、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プログラマ向けの実用的なユースケース作成手法を提供します。ユースケースはシステムの振る舞いに関する利害関係者との契約であり、アジャイル開発においても要求を明確化する重要なツールです。
+
+## ユースケースの基本概念
+
+### ユースケースとは
+
+ユースケースは、システムの振る舞いに関する利害関係者間の契約を表現するものです。
+
+```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開発プロセスに統合してください。