属人化した業務を引き継ぐために、まずマニュアルを作ろうとすることがあります。担当者が普段行っている操作を聞き取り、画面のスクリーンショットを並べ、条件ごとの処理方法を書き出していく方法です。

ところが、実際に文書化を始めると、「この場合は別の処理をする」「前回の対応によって判断が変わる」「数字は合っていても内容が不自然なら確認する」といった分岐が次々に出てきます。マニュアルは膨らみ、引き継いだ人は大量の手順から該当箇所を探すだけで精いっぱいになります。

属人化した業務をBPOへ切り出すときに必要なのは、担当者の行動をすべて文章にすることではありません。担当者が何を見て、何を判断し、どの状態を目指しているのかを整理することです。

属人化した担当者は、マニュアルどおりに働いていない

長く業務を担当している人は、細かな手順を一つずつ思い出しながら作業しているわけではありません。業務の目的や完成形を理解したうえで、目の前の状況に応じて必要な操作を選んでいます。

例えば、複数の現場から届く報告を一つの形式にまとめる業務を考えます。経験のある担当者は、単に項目を転記しているのではありません。

• 今回の報告で必要な情報がそろっているか
• 前回の報告と矛盾していないか
• 入力された数値や日付が現実的か
• 顧客へ確認すべき内容か、社内で補える内容か
• 最終的に誰が何のためにこの情報を使うのか

こうした判断を無意識に重ねています。その結果だけを見て「この欄をコピーする」「空欄なら担当者へ連絡する」と操作手順に置き換えても、担当者の判断までは引き継げません。

すべてを文書化すると、かえって業務が分かりにくくなる

属人化した業務には、明文化されていない例外が多数あります。これを漏れなくマニュアルへ書こうとすると、条件分岐が増え続けます。

「AならB」と書いた後に、「ただしCの場合はD」「過去にEがあればF」「顧客Gについては別の様式を使う」と追記されます。新しい例外が見つかるたびにページが増え、同じ内容が複数の箇所に書かれます。更新されていない手順が残り、どれが現在の正解なのかも分からなくなります。

この状態で引き継いだ人は、業務の目的よりも手順を間違えないことへ意識を集中させます。書かれた操作は正確に実行できても、最終的な成果物が目的から外れていることに気づけません。

ミスの原因が本人の注意不足とは限らないのは、このためです。目的を知らされず、膨大な分岐から正しい手順を選ばなければならない業務構造そのものが、ミスを起こしやすくしています。

最初に整理するのは「何をするか」ではなく「何のためか」

BPOへ業務を移す前に、最初に確認したいのは操作方法ではありません。次の項目を短い言葉で説明できる状態にします。

• 目的：この業務は何を実現するために行うのか
• 完了条件：どの状態になれば処理済みと判断できるか
• 利用者：処理した情報や成果物を、次に誰が使うのか
• 優先順位：速度、正確性、網羅性などのうち何を優先するか
• 重大な失敗：絶対に起こしてはいけないことは何か

例えば、店舗へ掲載許諾を確認する業務なら、電話をかけること自体が目的ではありません。対象店舗の意思を確認し、回答内容と確認経路を後から追跡できる状態にすることが目的です。

この目的が共有されていれば、電話がつながらなかった場合、担当者が不在だった場合、条件付きで許諾された場合にも、「記録を残さず次へ進む」という誤った処理を避けやすくなります。

業務を「作業・判断・確認・例外」に分ける

目的を確認したら、担当者が行っている仕事を四つに分けます。

この四つを分けずに一つの手順書へ書くと、単純作業の途中に高度な判断が紛れ込みます。作業者は、どこまで自分で決めてよいのか分かりません。

反対に、定型作業と判断を分ければ、「通常案件はBPO側で処理し、この条件に当たる案件だけ社内へ戻す」という分担ができます。属人化した担当者の知識を最初からすべて移す必要はありません。

全分岐を書くのではなく、判断の軸を渡す

例外を一件ずつ追加する代わりに、担当者が何を見て判断しているのかを整理します。判断項目は、多くても数個に絞ります。

例えば、OCRで読み取ったレシート情報を人が補正する場合、「誤認識を直す」とだけ書いても作業者ごとに結果が変わります。そこで、次のように判断の軸を決めます。

• 画像上で文字を確認できるか
• 商品名、数量、単価、合計の整合が取れているか
• 推測による補完が許される項目か
• 判読不能として扱う条件は何か
• 再撮影や上位確認へ回す条件は何か

判断の軸があれば、まだマニュアルに載っていない事例にも対応できます。判断できない場合の送り先まで決めておけば、作業者が独自解釈で処理を進めることも防げます。

文章だけでなく、具体例と境界例を用意する

「不鮮明な画像は除外する」「不自然な数値は確認する」といった表現は、人によって受け取り方が変わります。判断基準を共有するときは、文章と一緒に具体例を用意します。

• 処理してよい例
• 処理してはいけない例
• どちらとも判断しにくい境界例
• 過去に実際に迷った例

特に役立つのが境界例です。分かりやすい正解だけを見せても、実務で迷う条件は伝わりません。「この程度なら処理するが、ここまで欠けていたら確認へ回す」という境目を示すことで、判断のばらつきを抑えられます。

例外処理は、解決方法よりも止め方を決める

すべての例外に対する解決方法を事前に用意することはできません。そこで重要になるのが、処理を止める条件と確認経路です。

• どの条件に当たったら通常処理を止めるか
• 質問時にどの情報を添えるか
• 誰が判断するか
• 回答が来るまで対象データをどう管理するか
• 解決した事例をどこへ蓄積するか

例外が発生すること自体を失敗と考えると、作業者は無理に通常処理へ当てはめようとします。例外を正しく発見し、決められた場所へ戻すことも業務の一部として評価する必要があります。

最初から全件を移さず、小さく試す

業務の整理が終わっても、いきなり全件を移管するのは避けた方が安全です。少量の実データを使って試行し、作業者から出た質問を記録します。

試行で確認するのは、作業速度だけではありません。

• 説明を読んでも判断できなかった箇所
• 担当者が当然だと思って説明していなかった前提
• 同じ基準でも作業者によって判断が分かれた箇所
• 想定より頻繁に発生した例外
• 社内へ戻す案件が多すぎる工程

この結果をもとに、判断基準、事例、確認経路を更新します。完成したマニュアルを一度渡して終わりにするのではなく、実際の運用から得られた質問を使って業務設計を改善していきます。

マニュアルは業務設計の結果として作る

マニュアルそのものが不要なわけではありません。問題は、業務の目的や判断構造を整理する前に、担当者の操作をそのまま書き起こすことです。

先に目的、完了条件、判断の軸、例外時の確認経路を決めれば、マニュアルに書くべき内容も絞れます。通常処理は短い手順書にし、判断が必要な部分は基準表と事例集に分け、例外は質問票や管理表で扱うといった構成が可能になります。

属人化の解消とは、担当者が知っていることをすべて文章へ移すことではありません。業務の目的を共有し、他の人でも判断できる部分と、専門的な判断として残す部分を分けることです。

人へ渡せる形にできて、初めてBPOへ切り出せる

属人化した業務は、最初からきれいな仕様になっているとは限りません。実際には、担当者への聞き取り、実データを使った試行、質問と例外の記録を通じて、外部へ渡せる形になっていきます。