業務を外注した後も、外注先から毎日のように質問が届くことがあります。作業自体は外へ出したはずなのに、発注企業の担当者は元データを確認し、判断し、回答し続けなければなりません。

原因の一つは、作業手順だけを外注し、判断基準が発注企業に残っていることです。マニュアルに書ける通常処理は外注先で進められても、少し条件が外れるたびに発注企業へ確認が戻ります。

例外処理を仕様化する目的は、将来起こるすべての例外と正解をマニュアルに書くことではありません。外注先の案件管理者が、発注企業へ戻さずに判断できる範囲を広げることです。

例外処理は、作業者へ配る前から始まっている

新しい案件を受託したとき、最初に少量を処理するのは作業者ではなく、その案件を管理する人であるべきです。案件管理者が実際のデータに触れることで、仕様書を読むだけでは分からない問題が見えてきます。

• 説明されていない入力形式が混ざっている
• 複数の情報が矛盾している
• 同じ対象が重複している
• どちらに分類するか迷う境界例がある
• 作業者が推測してよい範囲が決まっていない
• 確認が必要な場合の連絡先が分からない

案件管理者が一度も作業しないまま、発注企業から受け取ったマニュアルをそのまま作業者へ渡すと、仕様の穴は質問が出るまで見つかりません。そのときには複数の作業者が同じ箇所で止まり、同じ質問を別々に送っていることもあります。

案件管理者が先に少量を処理すれば、作業者が迷いそうな箇所を予測し、発注企業へまとめて確認できます。質問への回答をマニュアル、判断表、具体例へ反映してから作業者へ展開できるため、本番中のやり取りを減らせます。

経験のある外注会社は、起こりそうな例外を予測できる

業務ごとにデータや顧客条件は異なりますが、例外の発生パターンには共通点があります。似た業務を扱った経験があれば、仕様を読んだ段階で確認すべき箇所をある程度予測できます。

例えば、大量の情報確認、写真収集、データ入力、OCR後の補正といった業務では、次のような問題が起こりやすくなります。

• 必要な情報が一部欠けている
• 表記揺れにより同じ対象を別のものとして扱う
• 対象条件を満たすか判断しにくい
• 画像や音声の品質が基準の境目にある
• 過去の処理結果と今回の指示が矛盾する
• システムの選択肢に該当する項目がない

経験の価値は、すべての例外の正解を知っていることではありません。どの部分に例外が発生しそうか見当をつけ、作業者へ配る前に発注企業との確認事項を絞れることにあります。

フィジビリで例外が多すぎる案件は、そのまま本番へ進めない

BPOや大量処理の現場では、本番前の小規模な試行を「フィジビリ」または「フィジビリティ検証」と呼ぶことがあります。フィジビリでは、作業速度や正解率だけでなく、どの程度の頻度で例外が発生するかを確認します。

フィジビリで一件処理するたびに質問が必要になるなら、作業者を増やしても処理能力は上がりません。質問の数も作業者数に応じて増え、案件管理者と発注企業の回答が追いつかなくなります。

例外が多い状態は、作業者の継続にも影響します。

• マニュアル内を何度も探す
• 判断できず質問を送る
• 回答が来るまで作業を止める
• 途中で基準が変わる
• 処理済みの案件をやり直す

この状態では、想定していた件数を処理できず、時間当たりの報酬も下がります。「正しく処理しても後から基準が変わる」という経験が続けば、質問せず自己判断する、難しい対象を後回しにする、稼働時間を減らす、案件から離脱するといったことも起こります。

例外を減らすことは、品質管理だけではありません。作業者が迷わず処理を続けられる仕事に整えることでもあります。

発注企業は、マニュアルではなく判断基準を渡す

外注先へ渡す情報は、画面操作や処理手順だけでは足りません。案件管理者が発注企業に代わって日常的な判断を行えるよう、判断の背景を共有します。

この共有は、判断基準を外注先の案件管理者へインストールする工程ともいえます。目的と優先順位を理解していれば、過去にない事例でも、既存の判断と矛盾しない処理を選びやすくなります。

作業者は例外を解決するのではなく、正しく止める

すべての作業者へ高度な判断を任せる必要はありません。作業者の役割は、通常処理を正確に行い、基準から外れた対象を見つけたら、独自解釈で進めずに止めることです。

そのため、例外処理の仕様には、正解だけでなく次の項目を含めます。

• どの状態を例外として扱うか
• どの工程で処理を止めるか
• どの例外区分を選ぶか
• 質問時にどの情報を添えるか
• 元データのどこを確認したか
• 回答が来るまで対象をどこへ置くか

「分からなければ質問してください」だけでは、質問内容が作業者ごとに異なります。案件ID、例外区分、発生箇所、確認済みの情報、関連ファイルなどを定型化すれば、案件管理者は状況を調べ直す時間を減らせます。

通常どおり流せる処理をHappy Path、通常工程から外れた処理をException Pathと呼ぶことがあります。例外を通常案件の中へ埋めたままにせず、理由、担当者、期限、対応状況とともに別の一覧へ集める仕組みが、Review QueueまたはException Queueです。名称を付けることが目的ではありません。通常作業者が正しく止めた対象を、判断できる人が見失わずに処理できる状態を作ることが重要です。

案件管理者が吸収する例外と、発注企業へ戻す例外を分ける

外注先の案件管理者へ判断基準を渡しても、すべての判断を任せるわけではありません。日常的な例外は案件管理者が吸収し、契約や業務目的に影響する判断だけを発注企業へ戻します。

この境界が曖昧だと、案件管理者は責任を避けるため、少しでも迷った案件をすべて発注企業へ戻します。反対に権限だけを渡して判断基準を共有しなければ、発注企業が想定しない処理が行われます。

任せる判断、戻す判断、その中間で相談する判断を明確にすることが、例外処理の仕様化です。

回答を一件限りにせず、次の判断へ反映する

発注企業または案件管理者が例外へ回答したら、その回答を今回の一件だけで終わらせません。

1. 回答の理由を記録する
2. 同じ条件の処理済みデータがないか確認する
3. 類似事例にも適用できるか整理する
4. 判断表または事例集へ追加する
5. 作業者全体へ必要な範囲だけ共有する

同じ質問が何度も発生するなら、それはすでに例外ではありません。通常工程の説明、作業画面、データの分け方などを変更し、質問しなくても処理できる形へ移します。

例外の件数や種類を記録しておけば、どの部分で作業が止まっているかも分かります。単にマニュアルへ追記するのではなく、頻出する例外を別工程にする、専門の作業者だけへ配る、入力時点で対象を分けるといった改善につなげられます。

質問が戻り続けるなら、業務はまだ外注できていない

作業を外注しても、発注企業の担当者へ毎日質問が届くのであれば、判断業務は社内に残ったままです。担当者は元データを確認し、回答し、回答が反映されたか確かめる必要があります。

BPOの価値は、作業人数を提供することだけではありません。案件管理者が業務の目的と判断基準を理解し、作業者から上がる通常の例外を引き受けることで、発注企業の管理負担まで減らすことにあります。

すべての例外を予測することはできません。しかし、案件管理者が先に作業し、フィジビリで例外を収集し、判断できる範囲を広げておけば、発注企業へ戻すのは本当に新しい判断だけになります。

マニュアルに書けない例外処理を仕様化するとは、正解を無限に書き足すことではありません。例外を発見し、正しく止め、適切な人が判断し、その判断を次の処理へ生かす流れを作ることです。