判断の意味を明確にする
承認の目的は、通知を速く送ることだけではなく、判断をたどれるようにすることです。対象、承認者が見た版、承認後の処理を決めます。後から内容が変われば再承認が必要かもしれません。そうしないと、誰も認めていない内容に承認履歴が付いてしまいます。
役割と選択肢
小規模なら、判断を記録する共通の待ち行列で十分な場合もあります。代理承認、上位への確認、申請者と承認者の分離が必要かを整理します。不在や期限切れの扱いを決め、無応答を勝手に承認とみなさないでください。
変更を追ってみる
架空の購買申請では、担当者が仕入先、金額、理由を提出し、上司がその版を承認します。購買部門が仕入先を変えたら再審査します。上司の不在時は指定の代理人に送り、その記録も残します。待機、承認、却下、差し替え済みは別の状態として表示します。
失敗する経路を確かめる
メールの到達は承認の証明ではありません。連続クリックで発注を重複させず、判断を永続保存し、後続処理を安全に再試行できるようにします。取り下げ、却下、古いタブ、同時承認を試します。過去の判断を直す場合は、変更理由を残します。
判断を後から再現できる記録にする
購買例では、申請、判断、その後に作る発注を分け、それぞれにIDを付けて審査した版を残します。実行者、その時点の権限、時刻、必要な理由を記録します。他人の受信箱や添付の推測に頼らず、同僚が経過を再現できる履歴を目指します。
運用責任者と競合操作を確認します。二人が同じ版を開くと、先の判断で後の画面が古くなることがあります。後の操作には明確な結果を返し、先の判断を上書きしません。審査中に取り下げた申請を遅いクリックで発注させないことも必要です。全員の承認が必要か、一件の却下で終了するか、何を変えたら集めた承認を取り直すかを決めます。
規則の問題と送信の問題を分けます。購買システムへ届かない承認済み案件は、承認を残したまま実行を保留または失敗にします。管理者へ再承認を求めると、認可と通信を混同します。重複を防ぐIDで未処理だけ再試行し、運用担当には履歴の残る修復手順を用意します。発注結果で完了を確認し、例外処理を定期的に見て通常ルールの不足を探します。
小さな受入確認表
| 場面 | 見るべき証拠 |
|---|---|
| 承認後に仕入先を変更 | 新版を再確認し、旧版の承認では差替えを認めない。 |
| 二人が同時に判断 | 双方に結果が伝わり、上書きや余計な発注がない。 |
| 承認後の通知が失敗 | 判断は残り、再送で承認をやり直さず発注も重複しない。 |
| 代理権限が期限切れ | 次の操作で現在の権限を確認して拒否し、過去の正当な処理は残す。 |
合意しておくルール
誰が申請、判断、代理、例外処理を行えるか。どの変更で承認が無効になるか。期限後はどうするか。通常の申請と意見が割れた例外を持ち寄り、画面より先に運用ルールを固めます。