申請承認システムの要件整理で決める状態と例外処理の考え方

申請承認システムで先に決めたいのは、画面の項目数より、誰がどの状態の申請に何をできるかです。通常の承認だけを作ると、差し戻し、取り消し、担当者の不在で仕事が止まります。申請の開始から終了までと、途中で戻る道筋を整理しましょう。

一つの申請が完了するまでを描く

対象となる申請を一種類選び、下書き、申請中、差し戻し、承認済み、却下、取り消しなど必要な状態を書きます。状態名は現場で使う言葉に合わせますが、差し戻しと却下の違いは明確にします。修正して再提出できるのか、別の申請が必要なのかが変わるためです。

状態ごとに、編集できる項目、操作できる役割、次に進む条件を記載します。承認済みの内容を自由に書き換えられると、何を承認したか分からなくなります。訂正を新しい履歴で残すか、改訂申請を作るかを決めます。

現行の紙や表計算の欄をそのまま移す前に、使われていない欄と判断に足りない欄を確認します。入力者が知らない情報を必須にすると、仮の値を入れる運用が生まれるため、入力する段階も見直します。

「確認担当」という役割に、その時点で誰が割り当てられているかを管理します。名前を処理の中へ直接固定すると、異動のたびに変更が必要になります。一方、小規模な運用で複雑な組織階層を作る必要はなく、必要な役割から始めます。

申請時に決まった担当を固定するか、承認操作の直前に最新の担当へ割り当てるかも確認点です。途中で担当が変わったときに、誰の一覧へ表示されるか、元担当が操作できるかを試作で確かめます。引き継ぎの履歴も残せると状況を追いやすくなります。

想定例として、添付資料だけを差し替える修正でも、その資料が承認判断に関わるなら再確認が必要です。画面上の変更量ではなく、判断へ与える影響から再承認の扱いを決めます。

通知を送るだけで処理が進むとは限りません。担当者の一覧で、次に操作が必要な申請、待っている相手、最終更新時点を確認できるようにします。通知に機密性のある内容を載せる場合は、送信先と表示範囲も考えます。

履歴には承認結果だけでなく、差し戻し理由、経路変更、取り消しを含めます。理由を後から編集できるなら、元の内容が分からなくならない方式を検討します。申請内容の版と操作履歴を対応させると、判断の対象を確認できます。

通常の承認完了に加えて、同じ申請を複数人が同時に開く、古い画面から承認する、権限のない人が直接URLへ入る、通知を受けたあと担当が変わる、といった条件を試します。画面でボタンを隠すだけでなく、処理の入口で権限と状態を確認する必要があります。

確認表には、開始状態、操作する役割、操作内容、期待する状態、記録される履歴を書きます。失敗時に内容が一部だけ更新されないか、再操作で重複処理されないかも確認します。業務上の終了とデータの更新が一致していることが重要です。

判断に必要な役割と例外が同じなら共通化できます。単に画面が似ているだけなら、経路まで統一すると運用に無理が出ます。

変更自体は可能ですが、処理中の申請への適用条件を決めます。新しい申請だけに適用するかを明確にしましょう。

添付ファイルの閲覧範囲も要件に含めます。申請を見られる人だけが資料を取得できるか、取り消し後にどう扱うか、ファイルを差し替えたときに元の判断資料を確認できるかを試します。申請本体の権限と資料の権限がずれないことを確認しましょう。