ユースケース一覧

ユースケースは、システムがアクターに提供する機能単位を定義する。各ユースケースは領域別に整理される。

領域別一覧

#	領域	主要エンティティ
1	代行	代行事業者 / 顧問先 / 代行スタッフ
2	組織	企業 / 事業所 / 部署 / 従業員
3	家族	家族構成員 / 年度属性 / 親族関係
4	申告	申告者 / 申告書 / 控除
5	給与	給与の支払者 / 給与所得者 / 税額計算結果
6	アイデンティティ	ユーザー
7	国税	源泉徴収義務者 / 源泉徴収票 / 法定調書合計表
8	地方税	特別徴収義務者 / 給与支払報告書
9	サブスクリプション	契約 / 請求
10	横断ユースケース	複数領域にまたがるもの

---

記述ルール

ユースケースは UI・実装方式・インフラ構成の変化に耐える要件の原本である。以下のルールは、画面設計や技術選定が変わってもユースケースを書き直さずに済むことを目的とする。

UI に依存しない

ユースケースはアクターの意図とシステムの応答を記述する。具体的な画面名（「サインアップ画面」「一覧画面」等）やウィジェット固有の操作（「ボタンをクリックする」「タブを切り替える」等）を書かない。画面構成やインタラクション方式は変わりうるものであり、UI設計に委ねる。「入力する」「選択する」のような抽象的な動詞は使用してよい。

アクターが変わればユースケースを分ける

1つのユースケースの主アクターは1つ。フローの途中で主アクターが変わる場合（例: 申請者 → 審査者）、それぞれ別のユースケースに分離する。ただし、主アクター以外のアクターが承認・通知受信等で関与することは妨げない。

分離によりユースケースが断片化して全体像が見えなくなるリスクがある。複数のユースケースにまたがるエンドツーエンドの流れは、業務フロー（BF-xxx）で俯瞰を補完する。

領域の責務を越えない

ユースケースは自領域のエンティティを直接操作する。他領域のエンティティを生成・変更する必要がある場合は、その領域のユースケース（サブ機能）を参照する。

他領域のユースケースを参照した場合、その結果（生成された ID 等）を後続ステップで利用してよい。ただし、参照先の内部構造に依存する記述（内部ステップの言及、中間状態の参照等）は避け、公開された入出力のみに依存する。

<!-- 良い例 -->
5. システムが代行事業者を作成する（→ [UC-101](../agency/uc-101-create-agency.md)）
6. システムが作成された代行事業者の ID を契約に紐づける

<!-- 悪い例 -->
5. システムが代行領域に代行事業者エンティティを生成する

実行方式を規定しない

ユースケースは「何が達成されるか」を記述し、「どう実現するか」（同期/非同期、イベント駆動等）は規定しない。複数領域にまたがる処理は、結果の列挙として書く。実行順序や結合方式は設計フェーズで決める。

<!-- 良い例: 結果の列挙。実行方式は問わない -->
5. システムが以下を実行する:
   - トライアル契約を作成する
   - ユーザーアカウントを作成する（→ UC-701）
   - 代行事業者を作成する（→ UC-101）

<!-- 悪い例: 同期的な逐次実行を暗示 -->
5. システムがトライアル契約を作成する
6. システムがユーザーアカウントを作成する（→ UC-701）
7. システムが代行事業者を作成する（→ UC-101）

列挙内の順序は原則として実行順序を意味しない。ただし、結果間にデータ依存がある場合（「Aの結果をBの入力に使う」等）は、列挙内で依存関係を注記してよい。依存を列挙の外に出すと整合性の範囲が不明瞭になるため、1つのまとまりとして列挙内に保つ。

<!-- データ依存がある場合: 列挙内で依存関係を注記 -->
5. システムが以下を実行する:
   - ユーザーアカウントを作成する（→ UC-701）
   - 代行事業者を作成する（→ UC-101）。作成されたユーザーの識別子を代行管理者として渡す

ただし、以下はビジネスルールであり、ユースケースに明記する:

• 整合性要件: 「すべて成功するかすべて失敗するか」等のトランザクション境界。複数領域にまたがる場合、オーケストレーションを担うユースケース（呼び出し元）が整合性の責任を持つ
• 完了の定義: アクターへの応答が「受け付け（処理中）」なのか「完了」なのかが業務上重要な場合、成功時の保証に明記する。「受け付け」で完了とする場合は、処理結果をアクターに通知・確認するユースケースへの関連を示す

## 業務ルール

- トライアル契約の作成、ユーザーアカウントの作成、代行事業者の作成はすべて成功するか、
  すべて失敗する必要がある（部分的な完了状態は許容しない）

横断的な関心事は適切な領域に委ねる

認証・認可、ユーザー列挙防止、メールアドレスの所有権確認などの横断的な関心事は、それを責務とする領域（例: アイデンティティ）のユースケースに記述する。呼び出し元では事前条件として参照し、具体的な手順を重複して記述しない。

<!-- 良い例: 事前条件で参照 -->
| 事前条件 | アクターが認証済みであること（→ UC-7xx） |

<!-- 悪い例: 呼び出し元で認証手順を記述 -->
1. アクターがメールアドレスとパスワードでログインする
2. システムがJWTトークンを発行する

参照のみのユースケースは書かない

ユースケースはシステムの状態を変化させるゴールを記述する。単純なデータ参照（一覧表示、詳細閲覧、検索等）はユースケースとして詳細化しない。参照機能の要件はUI設計やストーリーで扱う。ただし、参照に業務ルールが伴う場合（例: 権限に応じた表示制御、集計ロジック）は、業務ルールを他のユースケースや業務フローに記述する。

代替フローの範囲

業務ルールに抵触する場合（形式不正、期限切れ、権限不足等）の応答は代替フローに記述する。インフラ層の例外（DB接続エラー、ネットワーク障害等）は記述しない。

ただし、障害時の振る舞いが業務仕様として定義されている場合（例: 「外部連携が3回失敗したら管理者に通知する」）は、インフラ起因であっても代替フローまたは業務ルールに記述する。判断基準は「その振る舞いをプロダクトオーナーが決めるか、インフラチームが決めるか」である。

---

ユースケース詳細化テンプレート

各領域の index.md にはユースケースの一覧表がある。ユースケースを詳細化する際は、領域フォルダ内に個別ファイルを作成し、以下のテンプレートに従う。

# UC-xxx: ○○する

| 項目 | 内容 |
|------|------|
| 領域 | 申告 |
| アクター | 従業員 |
| レベル | ユーザー目標 |
| 事前条件 | ... |
| 成功時の保証 | ... |
| トリガー | ... |

## 主成功シナリオ

1. アクターが○○する
2. システムが○○する
3. ...

## 拡張（代替フロー）

- 2a. ○○の場合:
  1. ...

## 業務ルール

- ...

## 関連要件

- → [BF-102 事実確認フロー](../business-flows/annual-cycle.md#bf-102-事実確認フロー)

テンプレートの補足

項目	説明
レベル	「ユーザー目標」（1回の操作で達成する目的）または「サブ機能」（ユーザー目標を構成するステップ）
事前条件	このユースケースを開始するために真でなければならない条件
成功時の保証	主成功シナリオ完了後にシステムが保証する状態
トリガー	このユースケースを開始するきっかけ

---

ID 採番ルール

ユースケースの ID は UC-{3桁連番} 形式で、百番台ブロックで領域を分類する。

→ 詳細は 採番ルール 参照

ブロック	領域
0xx	横断ユースケース
1xx	代行
2xx	組織
3xx	家族
4xx	申告（ライフサイクル・判定）
5xx	申告（控除計算・証憑・通知）
6xx	給与
7xx	アイデンティティ
8xx	国税・地方税
9xx	サブスクリプション

NOTE

現在の各領域のユースケース一覧は領域内連番で記載されている。今後、個別ファイルとして詳細化する際に正式な UC-xxx ID を付与する。