業務システムで承認フローが必要になる場面は、思っているより多いです。
見積の確定、値引き、返金、与信、取引開始、個人情報の閲覧権限、内容証明の発行…。「誰がOKと言ったか」が曖昧なまま進むと、あとで必ず揉めます。
本記事では、承認を“ステータス管理の一部”として設計し、運用で破綻しない形に落とす要点を整理します。
まず、何を承認するのかを言語化します。よくある承認対象は次の通りです。
粒度が粗すぎると承認が形骸化し、細かすぎると現場が止まります。
「どの承認がないと事故るか」から逆算するのが現実的です。ステータス全体の考え方は 運用ルール設計 と揃えるとブレません。
二段階承認は、単に偉い人を増やす仕組みではありません。役割を分けることで運用が軽くなります。
この分離をしないと、最終承認者の手元に“情報不足のまま”案件が届き、差し戻しが増えます。差し戻しと不足情報回収は フォローアップ設計 の考え方で、責めない文体と次の一手を用意しておくと回りやすいです。
差し戻しが設計されていない承認フローは、必ず「戻したのにどこにあるか分からない」になります。
差し戻しは次を固定します。
理由の書き方は、問い合わせの対応履歴（履歴の書き方）と同様に「社内共有」と「対外説明」を混ぜないルールにすると揉めにくいです。
代理承認や事後承認を許すなら、証跡がより重要になります。監査性は 監査ログ設計 と整合させ、誰が・いつ・何を根拠に承認したかを残します。
滞留対策は、期限と通知（エスカレーション）をセットで設計すると、現場が止まりにくいです。
承認フローは、画面だけ作っても回りません。通知が弱いと、承認待ちが見えずに滞留します。
通知テンプレは 通知テンプレ管理 の考え方で、差し込み項目（案件番号、期限、判断ポイント、URL）を固定し、承認者が迷わず意思決定できる情報だけを載せます。
追加工事、仕様変更、工程変更など、承認が曖昧だと請求トラブルになりやすい領域です。業務像は 建設・工務店向け を前提に、変更申請→承認→確定→通知までを一連で持つと対外説明が楽になります。
受任可否や利益相反チェック、委任範囲の確定など、承認に近い判断が多いです。業務像は 士業事務所向け を前提に、差し戻し理由と記録の分離（社内/対外）を最初からルール化すると事故が減ります。
承認フローは「ステータス」と「通知」と「証跡」をセットで設計すると壊れにくくなります。
対象と粒度を決め、二段階の役割を分け、差し戻し先と状態を固定し、代理・事後承認・滞留を最初から扱う。
この設計があるだけで、承認が“止める仕組み”ではなく“事故を減らす仕組み”として機能します。