第3部:ドキュメントスキル / 第4章:ロジック実装

状態遷移図の読み方

状態遷移図は、オブジェクトの状態とその変化を表した図です。ステータス管理やワークフローの理解に使います。

📖 読了目安 約15分 対象:状態遷移、ステータス管理を理解する方

状態遷移図とは

役割

  • 状態(オブジェクトの状況)を表現
  • 遷移(状態の変化)を表現
  • トリガー(遷移のきっかけ)を明示
  • 許可される状態変化を定義

いつ使うか

ステータス管理実装時許可される遷移の確認
ワークフロー理解時業務の流れを把握
テスト時全パターンの確認
障害調査時不正な状態遷移の特定

状態遷移図の基本要素

基本記号

記号名称意味
開始状態最初の状態
終了状態最後の状態
□(角丸)状態オブジェクトの状態
遷移状態の変化
ラベルトリガー遷移のきっかけ

読み方の基本

状態遷移図の読み方を、シンプルな例で示します:

stateDiagram-v2
    [*] --> 下書き
    下書き --> 申請中: 申請
    申請中 --> 承認済み: 承認
    申請中 --> 却下: 却下
    却下 --> 下書き: 再編集
    承認済み --> [*]
  • 状態:「下書き」「申請中」「承認済み」「却下」
  • 遷移:矢印で表現
  • トリガー:「申請」「承認」「却下」「再編集」のように、状態を変える原因

【サンプル】状態遷移図の実例

実際のビジネスシステムで使われる3つの状態遷移図を、パターン別にご紹介します。それぞれのタブを開いて、図と読み解き方をご確認ください。

ECサイトの注文ステータス

stateDiagram-v2
    [*] --> 注文中
    注文中 --> 決済待ち: 注文確定
    決済待ち --> 決済完了: 決済成功
    決済待ち --> 注文中: 決済失敗(リトライ可)
    決済待ち --> キャンセル: 決済失敗(上限超過)
    決済完了 --> 出荷準備中: 在庫確保
    決済完了 --> キャンセル: キャンセル依頼
    出荷準備中 --> 発送済み: 発送完了
    出荷準備中 --> キャンセル: キャンセル依頼
    発送済み --> 配達完了: 配達完了
    発送済み --> 返品中: 返品依頼
    配達完了 --> 返品中: 返品依頼
    返品中 --> 返品完了: 返品処理完了
    配達完了 --> [*]
    返品完了 --> [*]
    キャンセル --> [*]

読み解き方

  1. 開始:ユーザーが注文を開始すると「注文中」状態になる
  2. 注文中→決済待ち:注文を確定すると決済処理に進む
  3. 決済待ち→決済完了:決済が成功すると「決済完了」になる
  4. 決済失敗時の分岐:失敗が上限未満なら「注文中」に戻る、上限超過なら「キャンセル」
  5. 決済完了→出荷準備中:在庫確保後、発送準備を開始
  6. 複数の終了状態:配達完了、返品完了、キャンセルのいずれでも終了

状態遷移表

現在の状態トリガー次の状態備考
-注文作成注文中初期状態
注文中注文確定決済待ち-
決済待ち決済成功決済完了-
決済待ち決済失敗(リトライ可)注文中3回まで
決済待ち決済失敗(上限超過)キャンセル自動キャンセル
決済完了在庫確保出荷準備中-
決済完了キャンセル依頼キャンセル返金処理
出荷準備中発送完了発送済み-
出荷準備中キャンセル依頼キャンセル返金処理
発送済み配達完了配達完了終了状態
発送済み返品依頼返品中-
配達完了返品依頼返品中14日以内
返品中返品処理完了返品完了終了状態

ユーザーアカウントの状態

stateDiagram-v2
    [*] --> 仮登録
    仮登録 --> 有効: メール認証完了
    仮登録 --> [*]: 期限切れ(削除)
    有効 --> 停止: 管理者による停止
    有効 --> ロック: ログイン失敗(5回)
    停止 --> 有効: 管理者による解除
    ロック --> 有効: 時間経過(30分)
    ロック --> 有効: 管理者による解除
    有効 --> 退会: 退会申請
    退会 --> [*]

読み解き方

  1. 開始:ユーザー登録で「仮登録」状態になる
  2. 仮登録→有効:メール認証が完了すると「有効」になる
  3. 仮登録→削除:認証期限が切れると自動削除される
  4. 有効→停止:管理者が停止処理を行うと「停止」になる
  5. 有効→ロック:ログイン失敗が5回続くと「ロック」になる
  6. 復帰のパターン:「停止」は管理者操作で解除、「ロック」は時間経過か管理者操作で解除
  7. 有効→退会:退会申請で「退会」状態になり、終了

このパターンの特徴:同じ状態から複数の遷移先がある場合(有効→停止、ロック、退会)と、異なる理由での遷移(ロック→有効の「時間経過」と「管理者操作」)を表現しています。

チケット(課題)の状態

stateDiagram-v2
    [*] --> オープン
    オープン --> 対応中: 担当者アサイン
    対応中 --> レビュー中: レビュー依頼
    レビュー中 --> 対応中: 差し戻し
    対応中 --> 保留: 保留
    保留 --> 対応中: 再開
    完了 --> 再オープン: 再発
    レビュー中 --> 完了: 承認
    再オープン --> 対応中: 担当者アサイン
    完了 --> [*]

読み解き方

  1. 開始:チケットが作成されて「オープン」状態
  2. オープン→対応中:担当者がアサインされると作業開始
  3. 対応中→レビュー中:レビュー依頼で、別の人による確認に進む
  4. レビュー中→対応中:問題があると差し戻される(ループ可能)
  5. 対応中→保留:外部条件など、一時的に作業を止める
  6. 保留→対応中:条件が揃うと再開
  7. 完了→再オープン:本番運用で不具合が見つかると再開(ループ可能)
  8. 完了で終了:最終的に「完了」で終わり

このパターンの特徴:同じ状態への戻り(レビュー中→対応中)や再ループ(完了→再オープン→対応中)があり、複数回の繰り返しが想定されています。テスト・バグ報告・修正を何度も繰り返すシステムに向いています。

実装での活用

状態遷移をコードで表現する

状態遷移図をプログラムとして実装するときは、許可される遷移を明確にチェックすることが重要です:

// Java: Enumで状態を定義
public enum OrderStatus {
    PENDING,      // 注文中
    PAYMENT_WAIT, // 決済待ち
    PAID,         // 決済完了
    PREPARING,    // 出荷準備中
    SHIPPED,      // 発送済み
    DELIVERED,    // 配達完了
    CANCELLED,    // キャンセル
    RETURNING,    // 返品中
    RETURNED      // 返品完了
}

遷移可否のチェック

// 許可される遷移かチェック
public boolean canTransitionTo(OrderStatus from, OrderStatus to) {
    switch (from) {
        case PENDING:
            return to == PAYMENT_WAIT;
        case PAYMENT_WAIT:
            return to == PAID || to == PENDING || to == CANCELLED;
        case PAID:
            return to == PREPARING || to == CANCELLED;
        case PREPARING:
            return to == SHIPPED || to == CANCELLED;
        case SHIPPED:
            return to == DELIVERED || to == RETURNING;
        case DELIVERED:
            return to == RETURNING;
        case RETURNING:
            return to == RETURNED;
        default:
            return false;
    }
}

DBでの状態管理

-- ordersテーブルのstatus更新
UPDATE orders
SET status = 3,  -- 出荷準備中
    updated_at = NOW()
WHERE id = 12345
  AND status = 2;  -- 決済完了からのみ遷移可能

-- 影響行数が0なら不正な遷移

状態遷移図を読むときのポイント

1. 開始状態を確認する

  • どの状態から始まるか
  • 初期状態への遷移条件は何か

2. 終了状態を確認する

  • どの状態で終わるか
  • 終了状態は複数あることも(正常終了、異常終了など)

3. すべての遷移を確認する

  • どの状態からどの状態へ遷移できるか
  • 遷移できない組み合わせは何か

4. トリガーを確認する

  • 何が起きると遷移するか
  • ユーザー操作か、システム処理か、時間経過か

5. 逆方向の遷移を確認する

  • 状態を戻せるか
  • 戻せない遷移は何か(不可逆な遷移)

状態遷移のテストパターン

正常系

  • すべての正常な遷移パターンをテスト
  • 開始→...→終了までの一連の流れ

異常系

  • 許可されていない遷移を試みる
  • エラーになることを確認

境界

  • 終了状態からの遷移(不可であること)
  • 特定条件下での遷移(時間経過、回数制限など)

よくある疑問

状態遷移図とフローチャートの違いは?
  • フローチャート:処理の流れ(手順)を表現
  • 状態遷移図:オブジェクトの状態変化を表現

フローチャートは「何をするか」を示し、状態遷移図は「何になるか」を示します。同じシステムにどちらも必要なことが多いです。

状態が増えすぎたらどうする?

状態をグループ化(サブステート)したり、状態遷移表で整理します。複雑な場合は設計者に相談しましょう。図が読みにくくなるのは設計に問題がある信号かもしれません。

同じ状態に戻る遷移は?

ありえます。例えば「決済失敗→注文中に戻る(リトライ可)」のようなケース。ただし無限ループを防ぐため、リトライ回数の上限は必ず設けましょう。

状態遷移図でよくある落とし穴

落とし穴対策
遷移できない組み合わせを実装してしまう遷移表で全パターンを確認
終了状態から遷移してしまう終了状態をチェック
不正な状態を許容してしまう遷移可否チェックを必ず実装
同時に複数の遷移が起きる排他制御を検討

関連ドキュメント