---
title: シナリオ分岐（Scenarios）
---

このページでは、[abstraction.md](file:///Users/stephenwang/Documents/trae_projects/my_skills/docs/ja-JP/theory/abstraction.md) の分析方法によって「シナリオ集合」を体系的に抽出し、それらのシナリオに含まれる境界条件や制約を情報資産として整理することで、要件の詳細化・プロトタイプ生成・受入テスト設計へどう接続するかを説明します。

また、「主経路 + シナリオ分岐 + 役割の泳道」で要件を会話するやり方は、ビジネス側にも理解しやすい形です。多くの場合、業務は「どんなシナリオが起きるか / 誰が何をするか / どんな例外があるか」という切り口で理解し、API やテーブル設計、実装詳細から入りません。

![企業用車シナリオ（例）](../../assets/ja-JP/visual-spec-scenarios.svg)

## 抽象（flows）からシナリオへ

抽象（flows）は「必ず表現すべき次元」を与え、シナリオ分岐（scenarios）は「その次元がこの業務でどう現れるか」を具体化します。

- flows へのマッピング後、主経路（メインステップ）、制御経路（取消/却下/撤回/ロールバック）、制約ゲート（検証/制約/失敗戦略）が安定して得られます。
- 各ステップについて、役割ごとに「できること / できないこと / いつできるか」を列挙すると、変更・取消・撤回、緊急停止/緊急変更、衝突処理などのシナリオが自然に抽出できます。
- 泳道に落とすことで責任境界が明確になります（誰が起点か、誰が処理するか、誰が確認するか、補償/ロールバックを誰が負うか）。

## シナリオに含めるべき情報

シナリオは名称だけでなく、実装可能・検証可能な情報を持つべきです。

- 発火条件：誰が、どの状態で、並行実行が許されるか。
- 前提と制約：検証項目、資源可用性、到達可能性など（位置、移動時間、勤務時間ルール）。
- 状態遷移：どの状態/フィールドが変わるか、予約（booking）を作成/更新/削除するか。
- 失敗と補償：エラー提示、再試行方針、補償/ロールバック、冪等性。
- 権限境界：どのロール/権限が実行できるか（撤回、緊急停止、緊急変更など）。

## 後工程への効果

- 要件詳細化：シナリオは差分を埋めるチェックリストになり、状態機械・項目・権限・ルール・例外処理を PRD レベルへ落とします。
- プロトタイプ：分岐 UI 状態（通常、不可、衝突、撤回、変更中、ロールバック済み等）を網羅でき、ハッピーパス偏重を防ぎます。
- 受入テスト：シナリオを骨格に、主経路 + 制御経路 + 重要制約を前提条件と期待結果付きで網羅できます。

## シナリオで開発スコープを切る

シナリオ分岐は「網羅」のためだけでなく、「取捨選択」にも使えます。リソースが限られるときは、各シナリオを発生頻度と価値で層別し、今期の開発範囲と受入範囲を明確にします。

- 発生頻度：高頻度の主経路や、よく起きる例外（撤回/変更など）を優先。稀な極端ケースは後回しにできるが、リスクと兜底は明記する。
- 価値：売上/コスト/コンプライアンス/体験に直結するものを優先。価値が低く実装コストが高いものは延期または簡略化する。
- 組合せ判断：「頻度 × 価値 × リスク（法令/資損/評判）」で優先度を付け、P0/P1/P2 の境界を scope と受入基準の両方に書く。

こうするとレビューで「今回はどこまでやるか／やらないか」が合意しやすくなり、実装後の認識ズレによる手戻りを減らせます。
