業務自動化の前に、例外・承認・引き継ぎを再設計する

自動化の出発点は、既存のフロー図をそのままシステムへ写すことではありません。対象を一つの反復業務に絞り、実際の案件が入口から受入済みの結果までどう進むかを証拠で確かめます。そのうえで例外、承認、引き継ぎを分解し、各要素を「削除」「標準化」「明確化」「人によるレビュー継続」のいずれか一つに決めます。メール転送、再入力、意味の曖昧な押印、所在不明の待ち行列を残したままでは、不確実さまで高速化してしまいます。

自動化前の現状マップには何を載せるべきか

現状マップには、一つの案件種別について、観測できる開始条件から下流担当者が受け入れた終了状態までを、製品や自動化方式に依存せず示します。最初に対象の案件、入口、受入済みの結果、結果を使う担当者を固定し、実例で必要性が判明した依存関係だけを境界へ加えます。将来像より先に現状を描き、規程、完了案件、帳票、問い合わせ、監査指摘、現場の振り返りを突き合わせます。

• 工程名と平易な目的
• 開始条件と実行する役割
• 入力、その出所、適用する規則や行動
• 出力とそれを使う担当者
• 利用システムまたは連絡経路
• 実作業時間と待ち時間
• 完了を示す証拠
• 次の担当者と受入条件

実作業時間と、待ち行列を含む経過時間は分けて記録します。イベントデータを使うなら、少なくとも案件識別子、活動名、時刻が流れの復元に必要ですが、それだけで記録の網羅性や正確性は保証されません。時刻から順序や経過時間は読めても、遅延が能力不足、入力不備、優先順位、隠れた作業のどれに起因するかは、案件記録と担当者への確認を重ねなければ判断できません。

標準的な変形と本当の例外をどう分けるか

逸脱は一つの「例外箱」に入れず、発生条件と安全な応答が異なる5群に分けます。BPMNは参加者、メッセージ、分岐、タイマー、エラー、エスカレーションなどを表せるため、代替経路や失敗経路を可視化できます。ただし、表記できることと、業務上その経路をどう扱うべきかは別問題です。分類後は実案件を見ながら、停止、差戻し、再試行、別経路、限定的な上書きのどれが許されるかを決めます。

• 入力不足・入力不正：不足項目を特定し、名指しした担当者へ返す。
• 既知の業務上の変形：安定条件を満たせば標準分岐として扱う。
• 規程・権限の例外：権限者が条件と理由を記録して判断する。
• 処理能力・依存関係・期限の失敗：待ち行列の責任と代替経路を明確にする。
• 技術的な実行失敗：安全な再試行、重複防止、照合、手動復旧、停止条件を定める。

例外台帳には、観測できる契機、代表案件、期間を明示した発生数、影響、安全な応答、復旧責任者、委任範囲、必要証拠、結果、恒久的な記録を残します。正当な変形を標準分岐へ移すのは、入口条件、手順、担当者、証拠、結果が安定した後です。標準作業は改善可能な基準であり、状況が変われば見直します。件数の多寡だけでは、隠れた迂回、誤分類、入力の不安定さのどれかを判定できません。

残す価値のある承認とは何か

残す価値がある承認は、次の状態を変える固有の意思決定を行い、明示されたリスク、資源、規程または統制目的に結び付くものです。承認、否認、差戻し、条件付き承認、上位判断への移行などを選べない工程は、承認ではなく通知、確認、相談、証拠作成かもしれません。遅いから不要、図上で重なるから重複とは決めず、同じ証拠で同じリスクと判断を見ているかまで比較します。

• 何を決め、どの結果を選べるか
• どの目的と評価済みリスクに対応するか
• 承認者の役割と委任された権限
• 必要な能力、独立性、職務分掌
• 判断時に閲覧できる証拠
• 基準または裁量の範囲
• 理由、条件、時刻、次の状態の記録

統制活動は、目的、評価済みリスク、業務環境、複雑さ、データの機密性や価値に応じて設計します。承認者は権限範囲内で判断し、必要に応じて処理、記録、承認、独立した確認を分けます。手動、部分自動、自動の統制は同居でき、自動フロー内に人の承認を残す設計も可能です。ただし、人がいることも自動化されていることも、それだけでは統制の有効性を示しません。AIを含む場合は、役割、限界、利用文脈、許容リスク、監督責任、出力の使い方も文書化します。

引き継ぎはいつ完了したと言えるか

引き継ぎが完了するのは、名前のある受領担当者が、次の行動に必要な情報と証拠を受け入れ、案件の責任移転が記録された時です。メール送信、共有フォルダーへの格納、キューへの投入だけでは、受領、内容の充足、開始可能性を確認できません。BPMNは参加者間のメッセージや人の作業、データ、状態変化を表現できますが、受入条件そのものは業務側で合意する必要があります。

• 案件識別子と現在の状態
• 送付する役割と受領責任者
• 必須情報、添付資料、前工程の完了証拠
• 受入条件と次に行う作業
• 現場で定めたサービス上の期待
• 不備、異議、時間切れ、誤送付の経路
• 受領時刻と永続的な記録場所

測定するなら、引き渡し可能になってから受領されるまでの時間を実作業時間と分けます。併せて、不足情報による差戻し、担当変更、未受領案件の滞留、現場で定めた期待からの逸脱、証拠で関連を確認できる後工程の手戻り、管理外の連絡経路で完了した案件を追います。記録は重要な出来事を後から調べる助けになりますが、記録があるだけで判断の正しさや統制の有効性が証明されるわけではありません。

マップ上の各要素をどう再設計するか

各工程と分岐には、削除、標準化、明確化、人によるレビュー継続の4区分から一つだけを割り当てます。これは、全体フローの改善、標準作業、明示的な責任、リスクに応じた統制、人の監督を組み合わせた本稿独自の整理であり、出典機関がこの名称で定めた方法ではありません。二つの区分を併記したくなった場合は、工程が複数の目的を抱えていないかを分解します。

例えば、新しい外部業務サービスの社内申請なら、申請の存在しか確認しない押印は目的を検証したうえで削除候補にします。必須項目、案件識別子、重複確認、スポンサー、サービス区分、必要証拠、通常の振り分けは標準化します。不備申請、既知の例外、提供部門への受入条件、否認、時間切れ、システム障害の責任者と復旧経路は明確化します。予算の確保、評価済みリスクに応じた専門・独立確認、規程外案件は、組織要件に従って権限者の判断を残します。

受け継いだ図を自動化するのではなく、業務を成立させる判断、証拠、例外、責任を先に設計し直す。

実装へ進める状態を何で証明するか

実装へ進めるのは、通常案件だけでなく、不備、否認、境界、時間切れ、上書き、手戻り、技術障害を新しい設計で通し、責任、証拠、復旧を説明できる時です。見やすい現状図だけでは実装仕様になりません。文書化を目的としたプロセスモデルは非実行のままでも成立しますが、実装には権限、入力検証、状態遷移、失敗時の動作など、より形式的な詳細が必要です。

• 全工程と分岐に名前のある責任者がいる。
• 全例外に観測可能な契機、安全な応答、証拠、記録結果がある。
• 全承認に固有の判断、目的、権限、選択可能な結果がある。
• 全引き継ぎに受領責任者、受入条件、不備時の経路がある。
• 削除する統制の理由と適切な内部統制レビューが記録されている。
• 権限、手動確認の契機、安全な再試行、重複防止、照合が定義されている。
• 監視指標、変更責任者、運用後の見直し方法が決まっている。

統制の設計、記録、承認、職務分掌、予防的統制と発見的統制の組み合わせは、組織の目的と評価済みリスクに応じて決めます。AIを使う場合は、利用文脈、責任、システムの限界、人の監督、許容リスクを導入判断へ反映します。稼働後は、差戻し、同じ例外の反復、上書き、滞留増加、欠陥、管理外経路を監視します。増加は調査の合図であって、特定の対策が正しいという証明ではありません。

法務、規制、財務、セキュリティ、プライバシー、安全、調達、人事、内部統制などの義務や統制を変更する場合は、組織内の資格と権限を持つ担当者による確認を受けます。方針、委任、独立性、リスク受容、必要証拠、専門判断に関する重要な疑問が残るなら、曖昧な規則として実装してはいけません。「条件付きで進む」「設計を戻す」「停止する」を明示的に選び、未解決事項を解消してから再判定します。