ステータス遷移図の作り方｜「例外」と「差し戻し」を先に潰す設計手順

ステータス運用が破綻する原因は「状態の数が多い」ことではありません。
破綻するのは、例外（差し戻し、保留、承認待ち、期限超過）が、状態として定義されていないことです。
この記事では、問い合わせ・予約・受注などで使える“遷移図”の作り方を、実務手順で整理します。

1. まず「起点」と「終点」を固定する

遷移図は、全部を一気に描こうとすると迷子になります。
最初に固定するのは、起点（発生）と終点（完了）です。

• 起点：受付（新規）
• 終点：完了（クローズ）

この“最短経路”を定義してから、例外を足します。基本形は 実例とパターン と同じです。

2. 次に「例外」を先に足す（これが本体）

現場を止めるのは例外です。例外が状態にないと、担当者は勝手な運用（メモで管理）に逃げます。
最低でも次を状態として定義します。

• 差し戻し：追加情報待ち（関連：フォローアップ）
• 保留：相手都合/社内都合で止まる（保留理由はカラムにも出す）
• 承認待ち：決裁が必要（関連：承認フロー）
• 期限超過：状態ではなくフラグでも可（関連：SLA）

3. 遷移ルール：禁止遷移を決めないと事故る

状態を決めても、勝手に動かせると意味がありません。
禁止遷移（やってはいけない動かし方）を決めます。

• 差し戻し → 完了（追加情報が揃ってないのに閉じる）を禁止
• 承認待ち → 実行済（承認ログが残らない）を禁止
• 保留 → いきなり完了（保留理由が消える）を禁止

この“禁止”は、権限（権限・ログ）ともセットで設計します。
例：管理者だけは例外的に強制クローズできるが、理由入力を必須にする。

4. 担当・割当との整合：遷移と同時に“担当が変わる”状態を決める

遷移図が現場で機能するかは、担当の動きが揃うかで決まります。
たとえば以下は遷移と同時に担当が変わりやすいです。

• 受付：一次受付（当番）へ
• 振り分け：担当部門へ（関連：割当ロジック）
• 承認待ち：承認者へ
• 差し戻し：申請者/顧客へ（ボールを明確に）

5. 通知：遷移図は“動かす仕組み”がないと机上で終わる

遷移図を描いても、誰も気づかなければ動きません。
通知・リマインド（設計）を、遷移のタイミングに紐づけます。

• 差し戻し発生 → 顧客/申請者へ自動通知
• 承認待ち発生 → 承認者へ通知＋期限超過でエスカレーション
• 期限超過 → 管理者へ通知（放置の見える化）

業種別の典型

製造業（技術問い合わせ・RMA）

解析・部品手配・現品確認など、保留が増えやすい領域です。
業務像は 製造業向けシステム開発例 を前提に、
不具合受付（関連：RMA設計）は「現品待ち」「解析中」「対策案提示」など、現場の実態に合わせた状態が必要です。

自動車販売・整備・タイヤショップ

部品待ち・顧客連絡待ち・入庫待ちが混ざります。業務像は 自動車販売・整備・タイヤショップ向け を前提に、
入庫（関連：ピット割当）の前後で状態が分かれるように遷移図を作ると、現場のボトルネックが見えます。

インテンスでも、遷移図は“見栄え”より「例外が状態として定義されているか」を最優先で見ます。

まとめ

遷移図は、最短経路より例外が本体です。
差し戻し・保留・承認待ちを先に入れ、禁止遷移と担当の動きを揃え、通知で動かす。
この順に作ると、ステータス運用が現場で機能しやすくなります。