第24章 状態と不変条件②:状態遷移表を作る📋🖊️✨

今日のゴール🎯
- 「状態(State)」と「イベント(Event)」を整理して、状態遷移表をサクッと作れるようになる😊
- 「この状態でこの操作していいの?」を、表で一発判定できるようになる✅
- 次の章(遷移の実装)に向けて、設計の地図を完成させる🗺️✨
※この章の例は C# 14 / .NET 10 / Visual Studio 2026 あたりの現行ラインで動く前提でOKだよ😉💖 (Microsoft Learn)
1) 状態遷移表ってなに?なんで嬉しいの?🧠💡
状態遷移表はね、
「いまの状態」×「起きたイベント」=「次の状態(or 禁止)」 を一覧にした表だよ📋✨
これがあると…
- 「支払い前なのに発送できちゃった💥」みたいな事故を防げる🛡️
- 設計メンバー同士で「仕様の認識ズレ」を減らせる🤝
- テストが作りやすい🧪✨(表=テストケースのタネ)
2) 作る前に決めるのはこの4つだけ✍️✨
状態遷移表は、基本この4点を埋めるだけで作れるよ😊
- 状態(State):今どの段階?
- イベント(Event):何が起きた?(ユーザー操作・システム処理)
- 遷移(Transition):次はどの状態へ?
- 禁止ルール(Guard):ダメなときは何が理由?
さらに余裕があれば👇も書くとプロっぽい✨
- アクション(Action):遷移するときにやること(請求作成、在庫引当など)
3) 例題:注文(Order)でやってみよ〜🛒💖
今回は分かりやすく「注文」を題材にするね😊✨
状態(State)候補🎭
Draft:カート状態(まだ注文確定前)📝Placed:注文確定(支払い待ち)📦Paid:支払い完了💳✨Shipped:発送済み🚚Delivered:配達完了🏠Canceled:キャンセル済み🧯
イベント(Event)候補🎬
PlaceOrder:注文確定するPay:支払うShip:発送するDeliver:配達完了にするCancel:キャンセルする
4) 状態ごとの“不変条件”を1行で書こう🛡️✨
表を作る前に、各状態の「絶対守る約束(不変条件)」をサッとメモするのがコツだよ💖
Draft:明細いじってOK、支払い情報はまだ不要🙂Placed:注文番号確定、合計金額は固定、未払い💡Paid:合計金額固定、支払い済みでキャンセルの扱いが変わる⚠️Shipped:配送情報固定、もう明細変更できない🚫Delivered:到着済み、以後は返品/返金イベントに分けるのが多い📦Canceled:処理打ち切り、基本もう何も起きない🧊
この1行メモがあると「禁止理由」を書くとき迷わないよ😉✨
5) いよいよ状態遷移表を書くよ📋🖊️✨
ここでは「行=現在の状態」「列=イベント」にして、セルに
- ✅ 次の状態
- 🚫 禁止(理由) を書いていくよ!
状態遷移表(例:注文)📋✨
| 現在の状態 \ イベント | PlaceOrder | Pay | Ship | Deliver | Cancel |
|---|---|---|---|---|---|
| Draft | Placed ✅ | 🚫(注文前は支払い不可) | 🚫(注文前は発送不可) | 🚫 | Canceled ✅(カート破棄) |
| Placed | 🚫(二重注文防止) | Paid ✅ | 🚫(未払い発送禁止) | 🚫 | Canceled ✅ |
| Paid | 🚫 | 🚫(二重決済防止) | Shipped ✅ | 🚫 | 🚫(要:返金フローへ) |
| Shipped | 🚫 | 🚫 | 🚫(二重発送防止) | Delivered ✅ | 🚫(発送後キャンセル不可) |
| Delivered | 🚫 | 🚫 | 🚫 | 🚫 | 🚫(到着後キャンセル不可) |
| Canceled | 🚫 | 🚫 | 🚫 | 🚫 | 🚫 |
- 「Paid で Cancel したい」みたいなやつは、Cancel じゃなくて Refund に分けるとスッキリするよ🧼✨(無理やり同じイベントにしない)
6) “例外的遷移”をどう扱う?🌀
「管理者なら発送後キャンセルできる」みたいな例外ってあるよね💦
おすすめは2つ👇
パターンA:イベントを分ける(いちばん安全)🛡️
Cancel(通常)ForceCancelByAdmin(管理者専用)
→ 表もコードも読みやすい✨
パターンB:同じイベントだけどガードに条件を書く⚖️
Cancel:IsAdmin == trueのときだけ許可…みたいに
→ 小規模ならOKだけど、増えると地獄になりやすい😇
7) 表ができたら、この5つで“抜け”チェック✅🔍
表って作った瞬間は気持ちいいんだけど、抜けが残りやすいの…!なのでチェック✨
- 開始状態はどれ?(例:Draft)
- 終端状態はどれ?(例:Canceled / Delivered)
- 二重実行は防げてる?(Pay を2回押したら…)
- 必ずどこかへ進める?(詰み状態になってない?)
- 禁止理由が説明できる?(「なんとなく禁止」になってない?)
8) 表をそのまま“設計資産”にするコツ📌✨
状態遷移表は「作って終わり」じゃなくて、こう保存すると強いよ😊
docs/state-transition.mdに置く📄- README に貼る📌
- 重要ならチケット/ADRに残す🧾✨(後で“なぜそうした”が超助かる)
9) AI活用コーナー🤖💖(抜けチェック最強)
AIはこの章だと「穴探し係」がめちゃ得意だよ✨
抜けチェック用プロンプト例🕵️♀️
- 「この状態遷移表で、現実の注文フローとして矛盾や抜けがないか指摘して。特に二重操作・例外遷移・終端状態を重点的に。」
- 「この表から、禁止理由をドメインエラー名(例:CannotShipBeforePaid)に変換して候補を出して。」
テスト化のタネ出しプロンプト🧪
- 「状態×イベントの全組み合わせから、テストケース一覧を作って。OK遷移と禁止遷移を分けて。」
(CopilotでもChatGPTでもCodexでも、ここは相性いいよ〜😉💖)
10) 演習タイム〜!🎀📝
演習A:あなたの題材で状態を決める🎭
次のどれかでOK(好きなの選んで脳内でやってみてね😊)
- 会員登録+メール認証📧
- サブスク課金💳
- 予約+キャンセル📅
- 状態を5つくらい出す
- イベントを5つくらい出す
- 状態遷移表を埋める
- 🚫セルに理由を書く
演習B:AIに抜けチェックさせる🤖✅
作った表を貼って、「抜け・矛盾・二重操作」をレビューしてもらう✨
まとめ🎉
- 状態遷移表は「仕様を表にしたもの」📋✨
- 🚫禁止理由を書くと、設計が一気に強くなる🛡️
- 次の章は、この表をそのまま 遷移メソッド(Pay/Ship…)の実装に落としていくよ✅🔁
次(第25章)は、今日の表を使って「遷移時チェック(ガード)をコードに固定する」へ進むよ〜😊💖 (Microsoft Learn)