承認フローと版管理の設計｜ステータス遷移図で差し戻し・修正を詰まらせない

承認フローは、最初は簡単でも、例外や差し戻しが増えるとすぐに詰まります。 詰まりを防ぐには、状態（ステータス）を言葉で整え、遷移（次に行ける状態）を先に決め、さらに版管理（Revision）で「どれが最新か」を迷わないようにするのが効果的です。

承認フローが詰まる典型パターン

• 承認待ちなのか、差し戻しなのかが分からない
• 誰のボールか曖昧で放置される
• 修正が入って最新版が分からなくなる
• 例外（緊急、特別値引き、条件付き）だけ別運用になり追えない

ステータス設計：言葉を揃える

まず、状態名を「運用で使う言葉」に寄せます。曖昧な状態名は、現場で解釈が割れます。

例（見積・提案の状態）

• 下書き（作成中）
• 提出待ち（社内確認）
• 提出済み（顧客確認中）
• 差し戻し（修正依頼あり）
• 承認（確定）

ステータス遷移図：例外と差し戻しから先に書く

遷移図は、通常ルートより先に「差し戻し」と「例外」を書くと破綻しにくいです。

• 差し戻しは、戻り先（下書きへ／提出待ちへ）を固定する
• 例外承認（緊急・特別条件）は、通常フローの外に出さず、同じ枠で扱う
• 承認後の修正は「新しい版」を作る（上書きしない）

版管理（Revision）の基本

差し替えが増える業務（見積、提案、予約条件、対応方針）は、版管理がないと判断が遅れます。

最低限のルール

• 版番号（Rev.1/Rev.2）を付ける
• 最新版フラグ（現在有効）を持つ
• 版ごとに「変更理由」を残す（短くてOK）

最小構成で始めるなら

• 承認者は1段階（一次承認）から
• 差し戻し理由は選択式＋補足（自由記述だけにしない）
• 承認後の修正は必ず新しい版で

まとめ

承認フローは、状態と言葉が揃っていないと詰まります。ステータス遷移図で「例外」と「差し戻し」を先に潰し、承認後の修正は版管理で扱う。 この形にすると、修正が増えても運用が荒れにくくなります。