ステータス運用がうまく回らなくなる原因は、状態の数が多すぎることではありません。 実際に困るのは、修正依頼、保留、承認待ち、期限超過 のような例外が、状態としてきちんと定義されていないことです。
受付から完了までの最短ルートだけをきれいに描いても、現場はその通りには動きません。 追加情報待ち、担当変更、承認差し戻し、顧客都合の停止、社内都合の保留。こうした分岐が画面に表れていないと、担当者はメモや口頭連絡で補うようになり、そこで履歴がずれていきます。
この記事では、問い合わせ・予約・受注・見積などの業務に共通して使える ステータス遷移図の作り方 を、実務の順番に沿って整理します。 見た目のきれいな図を作る話ではなく、運用で詰まりにくい状態設計をどう組み立てるか、という話です。
遷移図を描き始めるときに迷いやすいのは、最初から全部の状態を並べようとすることです。 ここで細かく入りすぎると、かえって話が進みません。
まず固定したいのは、次の2点です。
この2点を置いたうえで、「一番素直に終わるとしたら途中に何があるか」を並べます。 最短経路の基本形は、実例とパターン で扱う考え方と同じです。
基本形 まずは最短経路だけを置く
最初から例外を全部描こうとせず、まず基本線を置いてから分岐を足す方が整理しやすくなります。
遷移図で本当に重要なのは、基本線を細かく分けることではなく、現場で止まりやすい例外を先に状態として持つことです。 例外が状態として存在しないと、現場は結局メモや口頭で補うことになります。
最低でも、次のような状態は先に検討しておいた方が安全です。
修正依頼の扱いは、フォローアップ の考え方とも強くつながります。 単に「差し戻し」の箱を置くだけでなく、差し戻した後に誰が何を確認して戻すのかまで揃えておきたいところです。
状態を定義しただけでは、運用はまだ安定しません。 重要なのは、どこからどこへ動かせるか と同時に、どこへは動かせないか を決めることです。
この禁止遷移がないままだと、現場では都合のよい近道が生まれやすくなります。 たとえば、対応が面倒だから修正依頼からそのまま完了へ飛ばす、承認待ちを飛ばして実行済みにする、といった運用です。
遷移ルール 許可する動きと禁止する動き
| 現在の状態 | 遷移先 | 扱い | 条件 |
|---|---|---|---|
| 受付 | 確認中 / 修正依頼 / 保留 | 許可 | 担当割当または内容確認後に変更 |
| 修正依頼 | 確認中 | 許可 | 追加情報がそろった場合のみ戻す |
| 修正依頼 | 完了 | 禁止 | 必要情報なしのまま閉じるのを防ぐ |
| 承認待ち | 実行済 / 完了 | 禁止 | 承認ログ未取得の処理を防ぐ |
| 保留 | 確認中 / 完了 | 条件付き | 保留理由と解除理由の入力を必須にする |
禁止遷移を明示すると、「なぜこの順番でしか進めないのか」を現場へ説明しやすくなります。
この制御は、権限（権限・ログ）ともセットで考える必要があります。 たとえば管理者だけは強制クローズできるとしても、理由入力や監査ログを必須にしておかないと、あとで履歴が追えなくなります。
遷移図が現場で機能するかどうかは、状態の名前より、状態が変わったときに担当がどう動くか が揃っているかで決まります。 誰の案件なのかが曖昧なままでは、見た目だけ遷移図があっても実務では使われません。
たとえば、次のような状態では、担当や責任の所在も一緒に変わることが多くあります。
担当 状態と担当の関係を一緒に整理する
状態だけを描くより、「その状態では誰が持つか」まで並べると、運用に落とし込みやすくなります。
遷移図を描いても、担当者がその変化に気づけなければ動きません。 また、いつまでに処理すべきかが曖昧だと、状態が増えるほど滞留が見えにくくなります。
そのため、状態設計では通知と期限もあわせて決めておきたいところです。
通知・リマインドの設計は、通知設計 や SLAの考え方（SLA）ともつながります。 状態だけ定義して終わらせず、動かす仕組みまで一緒に決める方が実務向きです。
ステータス遷移図は業務共通の考え方がありますが、例外の出方は業種によってかなり変わります。 そのため、「問い合わせ」「予約」「受注」で同じテンプレを当てるより、何で止まりやすいかを先に見る方が設計しやすくなります。
解析待ち、現品待ち、部品手配待ち、対策案確認など、保留や調査中の状態が増えやすい領域です。 業務像は 製造業向けシステム開発例 を前提に、 不具合受付（RMA設計）では「現品待ち」「解析中」「対策提示」など、現場の呼び方に沿った状態が必要になります。
入庫待ち、部品待ち、顧客連絡待ち、作業完了待ちが混ざりやすい領域です。 業務像は 自動車販売・整備・タイヤショップ向け を前提に、 入庫前後で状態を分け、ピットや担当との連携（ピット割当）を遷移へ反映した方が、詰まりどころを把握しやすくなります。
遷移図を一通り作ったら、最低限このあたりは見直しておくと、あとで困りにくくなります。
確認 ステータス遷移図の最終チェック
図を描いて終わりではなく、現場がその状態を実際に使えるかまで確認しておく方が安全です。
ステータス遷移図は、最短ルートを描くことより、例外がどこで起き、誰がどう持つかを整理すること に価値があります。 修正依頼、保留、承認待ちを先に入れ、禁止遷移を決め、担当・期限・通知まで揃える。この順番で作ると、現場で使える遷移図になりやすくなります。
インテンスでも、遷移図は見た目より「例外が状態として定義されているか」を優先して確認します。 状態名を増やすこと自体が問題ではなく、現場で起きる分岐を画面の中に収められているかどうかが重要です。 そこが揃うと、ステータス運用はかなり安定しやすくなります。