承認フローと版管理の設計｜ステータス遷移図で修正依頼・修正を止まりにくくする

承認フローは、関係者が少ないうちは動いていても、修正依頼、差し戻し、例外対応が増えると途端に滞りやすくなります。とくに、今どの状態なのか、誰が次に動くのか、どの版が最新版なのかが曖昧になると、確認の往復が増えやすくなります。

見積、予約条件、対応方針、提案書など、修正を重ねながら確定していく業務では、承認フローと版管理を分けずに考える方が運用しやすくなります。本記事では、状態名の揃え方、遷移の切り方、版番号の扱い方を整理し、修正が増えても止まりにくい設計の考え方をまとめます。

承認フローは「通常ルート」より先に「戻り方」を決めておくと扱いやすくなります

承認フローが止まりやすいのは、承認そのものより、修正依頼や例外対応が発生した後です。承認待ちなのか、修正中なのか、再提出待ちなのかが曖昧だと、誰のボールなのか分かりにくくなります。

• 承認待ちと修正依頼が同じ扱いになっている
• 誰が次に対応するのかが分かりにくい
• 修正のたびに最新版がどれか迷いやすい
• 緊急対応や特例だけ別運用になり、一覧で追いにくい

状態と版を同じ画面で見られると、確認の往復が減りやすくなります

下は、承認フローと版管理を一緒に確認する画面の例です。今どの状態にあり、どの版が有効で、どの版に修正理由が残っているかを同時に見られる構成にしています。承認フローだけ、版履歴だけ、と分かれていると判断に時間がかかりやすいため、この2つは近くに置く方が扱いやすくなります。

ステータス名は、運用で使う言葉に揃える方が解釈のずれが出にくくなります

状態名が曖昧だと、同じ画面を見ていても人によって意味の受け取り方が変わりやすくなります。まずは「今どの段階か」「誰が次に動くか」が分かる言葉に揃える方が扱いやすくなります。

見積や提案で使いやすい状態名の例

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

ステータス遷移図は、通常ルートより先に「修正依頼」と「例外」を書く方が崩れにくくなります

通常ルートだけを先に作ると、修正依頼や特例対応が別運用になりやすくなります。最初から戻り先を決めておくと、運用途中で迷いにくくなります。

• 修正依頼の戻り先を固定する（下書きへ戻す、再提出待ちへ戻すなど）
• 緊急対応や特例承認も、通常フローの外に出しすぎない
• 承認後の修正は、同じレコードを上書きせず新しい版で扱う

1. 通常ルートを決める
   下書きから承認までの最短経路を整理します。
2. 修正依頼の戻り先を決める
   どこへ戻るかを固定して、例外処理を減らします。
3. 承認後の変更ルールを決める
   上書きではなく版を分ける前提にします。

版管理は「どれが最新か」を迷わないようにするための仕組みです

見積、予約条件、提案書、対応方針のように、差し替えが発生しやすい業務では、最新版がどれか分からなくなるだけで判断が遅れやすくなります。版番号と最新版の扱いを先に決めておく方が安全です。

最低限のルール

• 版番号を付ける（Rev.1、Rev.2 など）
• 最新版フラグを持つ
• 版ごとに変更理由を残す

承認後の修正は「上書きしない」方が扱いやすくなります

承認後に内容が変わることは珍しくありません。そこで旧版を上書きしてしまうと、何が変わったのか、いつ変わったのか、承認時点で何が確定していたのかが分かりにくくなります。

• 承認済みの内容は履歴として残す
• 変更が必要になったら新しい版を作る
• 旧版は参照用に残し、最新版だけを通常表示にする

最小構成で始めるなら

• 承認者は1段階から始める
• 状態は5つ前後に抑える
• 修正依頼理由は選択式＋補足にする
• 承認後の変更は必ず新しい版で扱う

最初から複雑な多段承認にするより、まずは一次承認と版管理の基本だけを固めた方が、現場では定着しやすくなります。

まとめ

承認フローは、承認そのものより、修正依頼、例外対応、再提出の扱い方で滞りやすくなります。状態名を揃え、戻り先を固定し、承認後の変更を版管理で扱うようにすると、修正が増えても運用が乱れにくくなります。

まず見直しやすいのは、状態名が現場で通じる言葉になっているか、修正依頼の戻り先が決まっているか、承認後の変更を上書きしていないかの3点です。そこから整えていくと、確認の往復を減らしやすくなります。