1万件のデータを短期間で処理するとき、最も大変なのは1万件を処理している期間ではありません。本番前に行う100件程度の試行です。

BPOや大量データ処理の現場では、この小規模な試行を「フィジビリ」または「フィジビリティ検証」と呼ぶことがあります。フィジビリの目的は、単にその作業ができるか確かめることではありません。仕様、マニュアル、質問対応、検品、進捗管理を整え、件数が100倍になっても同じ方法で処理できる状態を作ることです。

フィジビリが十分にできていれば、本番では完成した仕組みに沿って作業が流れます。反対に、曖昧な仕様のまま本番へ入ると、大量の処理済みデータを修正することになり、品質と納期だけでなく原価も崩れます。

大量処理の成否は、本番が始まる前に決まる

短納期の案件では、少しでも早く本番へ入りたくなります。しかし、処理方法が固まっていない状態で人数を増やすと、曖昧な判断基準もそのまま人数分に広がります。

例えば、10人の作業者がそれぞれ異なる解釈で100件ずつ処理すれば、短時間で1,000件まで進みます。ただし、その後で基準の誤りが判明すると、確認し直す対象も1,000件です。誰がどの基準で処理したのか追跡できなければ、問題のあるデータだけを選んで直すこともできません。

大量処理では、一件の判断ミスよりも、誤った判断が同じ方法で繰り返されることの方が大きな問題になります。だからこそ、作業者を増やす前に、少量のデータで誤りの原因を見つけなければなりません。

1万件の本番より100件のフィジビリに労力をかける

案件によって違いはありますが、実務感覚としては、準備から納品までに必要な労力の8割をフィジビリまでに使い、本番を2割程度の負担で流せる状態が理想です。

本番で管理者が忙しく動き続けている場合、管理者が優秀だから案件が回っているようにも見えます。しかし実際には、作業者が迷うたびに回答し、誤った成果物を直し、遅れている人から作業を回収している可能性があります。管理者の個人的な対応力で運用を支えているため、件数がさらに増えると破綻します。

うまく立ち上がった案件では、本番中に管理者が行うのは、進捗と品質の数値を確認し、例外へ対応することが中心です。何も起きていないように見える状態こそ、準備段階で必要な仕事を終えられた状態です。

フィジビリで完成させるもの

フィジビリでは、実際の作業データを使って、次の項目を確認します。

フィジビリで質問が多く出ること自体は失敗ではありません。むしろ、本番前に仕様の曖昧さを見つけられたということです。質問を個別に回答して終わらせず、マニュアル、判断基準、事例集、作業画面へ反映します。

重要なのは、フィジビリの作業者が理解できたかだけではありません。説明を受けていない別の作業者でも、更新後の資料を見て同じように処理できるかを確認します。特定の担当者だけが理解した状態では、その担当者を増やせないためです。

本番中の修正は、件数に比例して重くなる

100件の段階なら、仕様を修正して全件を確認し直すこともできます。しかし、5,000件まで進んでから変更が発生すると、担当者が手作業で直せる量ではありません。

本番中の仕様変更では、単にマニュアルを書き換えるだけでなく、次の対応が必要になります。

• 変更前に処理された対象を特定する
• 再確認が必要な条件を決める
• 全作業者へ新しい基準を周知する
• 作業中のデータへ変更を反映する
• 修正作業の担当者を確保する
• 新旧の基準が混在していないか検品する

この間にも通常の作業は進みます。新しいデータの処理と過去データの修正が並行し、進捗表も複雑になります。品質と納期を守ろうとすれば人員を追加する必要があり、追加費用を受注金額へ反映できなければ、その分だけ原価が増えます。

大量処理で利益を守るためにも、フィジビリは削りにくい工程です。準備期間を短くして早く本番へ入ることが、必ずしも全体の期間や費用を減らすとは限りません。

件数は最初から均等に配らない

1万件を10人へ1,000件ずつ割り当てれば、管理しやすいように見えます。しかし、この方法では、速い人が終わっても遅い人の完了を待つことになります。品質に問題がある人へ大量に配っていた場合は、その人が処理した範囲をまとめて再確認しなければなりません。

大量処理では、最初から全件を固定配分せず、小さな単位で繰り返し配ります。

1. 全員へ少量の作業を配る
2. 完了速度と検品結果を確認する
3. 完了した人へ次の作業を配る
4. 正確で速い人には配布量を増やす
5. 遅延や誤りがある人への追加配布を調整する

この方法では、最終的に正確で速い人へ多くの件数が寄ります。人数を平等に扱うことよりも、案件全体として納期と品質を守ることを優先した配分です。

小分けにすることで、作業者が途中で離脱した場合も影響を限定できます。未着手の件数を大量に抱えた人から回収する必要がなく、次に対応できる人へ配り直せます。

管理するのは「作業済み」ではなく「納品可能」な件数

作業者が完了ボタンを押した件数だけを見ていると、進んでいるように見えても、検品待ちや差し戻しが積み上がっていることがあります。

進捗は少なくとも、次の状態に分けて管理します。

• 未配布
• 配布済み・未着手
• 作業中
• 作業完了・検品待ち
• 差し戻し中
• 検品完了・納品可能
• 判断待ち・保留

納期の判断に使うべきなのは、作業済み件数ではなく、検品を通過した納品可能件数です。また、どの工程に件数が滞留しているかを見ることで、作業者、検品者、質問対応者のどこを増やすべきか判断できます。

報酬を2倍にしても、処理速度は2倍にならない

作業者を確保するには、作業内容と負担に見合った報酬が必要です。ただし、常識的な報酬が設定されている状態で、単価を2倍にしたからといって、一人の作業速度が2倍になるわけではありません。

大量処理の速度を左右するのは、報酬額よりも、次のような運用条件です。

• マニュアルを読めば迷わず作業できる
• 判断基準と具体例が一致している
• 作業画面が使いやすい
• 質問への回答が早い
• 次の作業が途切れず配られる
• 差し戻しの理由が明確である
• 作業者の得意不得意に合った配分になっている

件数に応じたインセンティブも、期待するほど効かないことがあります。速度だけを評価すると、確認を省略したり、迷った案件を質問せずに処理したりする可能性があります。処理件数が増えても、検品と修正が増えれば、案件全体の速度は上がりません。

報酬は作業者に安心して参加してもらうための重要な条件です。しかし、処理能力を上げる主なレバーは、単価ではなく、迷わず正しく処理できる仕組みです。

本番では見ているだけで終わる状態を目指す

短期大量BPOの立ち上げで目指すのは、管理者が本番中に大量の質問と修正へ追われる状態ではありません。フィジビリまでに問題を見つけ、マニュアルと判断基準を整え、作業を小分けに配り、品質と進捗を数値で把握できる状態です。

本番へ入った後は、決めた工程に沿って作業が進み、正確で速い人へ件数が配られ、検品済みの成果物が継続的に積み上がる。管理者は異常がないことを確認し、限られた例外だけに対応する。この状態を作れれば、件数が多くても品質、納期、原価を同時に管理できます。

大量処理は、多くの人へ仕事を配ることではありません。大量に配っても壊れない作業工程を、本番前に作ることです。