1件処理するのに1分かかる業務があれば、当社もまずは1分の作業として見積もります。しかし、受注後もそのまま1分かけ続けるとは限りません。どうすれば30秒で処理できるかを、かなり真剣に考えます。

同じ品質の成果物を半分の時間で作れるようになれば、処理できる件数は増え、原価も下がります。大量処理を請け負うBPO会社にとって、工程改善は便利な付加サービスではなく、利益を生み出す仕事そのものです。

ただし、作業者に「今までの倍の速さで作業してください」と求めるわけではありません。人の手を速く動かすのではなく、1分かかるように作られている工程を作り直します。

F1のタイヤ交換は、作業者が超人的に速いからではない

工程分解の考え方をイメージしやすいのが、F1のタイヤ交換です。2023年のカタールグランプリでは、マクラーレンが4本のタイヤ交換を1.80秒で完了したとF1公式サイトが伝えています。

一般的なタイヤ交換では、一人が車体を上げ、ナットを外し、古いタイヤを取り、新しいタイヤを付け、ナットを締めます。F1では、この一連の作業を細かく分け、複数人が同時に動きます。車体を上げる人、ホイールナットを扱う人、外したタイヤを回収する人、新しいタイヤを差し出す人が、それぞれ決められた一つの動作を担当します。

それだけではありません。一般車のように複数のナットを順番に外すのではなく、一つのセンターロックでホイールを固定するなど、道具や車体側も短時間で交換できる構造になっています。

速さは、担当者の気合いや手先の器用さだけから生まれているのではありません。作業の分け方、道具、部品、配置、動作の順序まで、すべてが短時間で終わるように設計されています。

1分という時間を、そのまま受け入れない

データ入力を例にすると、1分の中には複数の作業が混ざっています。

• 対象データを探す
• 必要な箇所を読む
• 条件に照らして判断する
• 入力先を探す
• 文字や数値を入力する
• 入力結果を確認する

これらをまとめて「入力作業」と呼んでいる限り、改善方法は「慣れて速くなる」程度しか見つかりません。まず、どの動作に何秒かかっているのか、どこで手が止まっているのかを分けて見ます。

実際には、文字を入力している時間より、入力すべき内容を探したり、判断に迷ったり、別の画面を開いたりする時間のほうが長いことがあります。短縮すべきなのは、作業者のキー入力ではなく、その前後に発生している迷いと移動です。

マニュアルを読みながら行う仕事をなくす

工程を細かく分ける大きな利点は、一つひとつの作業を質問が出ないほど単純にできることです。

作業者が毎回マニュアルを開き、「この場合はどの規則に該当するのか」と考えなければならない業務は、処理時間が安定しません。理解の差によって品質も変わり、質問への回答や差し戻しにも工数がかかります。

そこで、画面に必要な情報だけを表示し、自由入力をドロップダウンやボタンへ変えます。選択肢も、業務全体で使われるすべての項目を並べるのではなく、その工程で必要なものだけに絞ります。別画面にある情報が必要なら、同じ画面に表示するか、あらかじめデータを結合しておきます。

複数の画面やシステムを行き来し、一方を見ながら他方へ転記する仕事は、英語圏ではSwivel-chair Workと呼ばれることがあります。人がシステム間の接続部分になっている状態です。システムを全面改修できなくても、必要情報を一画面へまとめたり、転記する項目を減らしたりするだけで処理時間は短くなります。

目指すのは、詳しいマニュアルがなくても「この画面を見て、この操作をする」と理解できる状態です。

良いマニュアルを作ることより、マニュアルを読みながら作業しなくてよい工程を作るほうが、処理時間は安定します。

マニュアルは必要ですが、それを作業中の検索画面として使わせないことが重要です。頻繁に参照される説明があるなら、作業者の記憶に頼らず、画面、選択肢、入力制御の側へ移したほうが速くて確実です。

判断が必要な案件だけを別の工程へ送る

すべての案件を単純作業にできるわけではありません。どれだけ通常工程を整えても、想定外の記載、情報不足、複数の条件に該当するケースは発生します。

ここで通常作業者に例外の判断まで求めると、マニュアルが膨らみます。発生頻度の低い例外を全員が覚える必要が生じ、一件の例外が出るたびに作業が止まります。

当社では、通常作業者の役割を「例外を解決すること」ではなく、「通常条件から外れていると気づき、例外として送ること」までにする場合があります。作業者は例外フラグを付けた時点でその案件を終了し、判断基準を深く理解した担当者が例外だけをまとめて処理します。

• 通常作業者：定められた条件に沿って処理し、当てはまらないものを例外として送る
• 例外処理担当者：集まった案件を確認し、判断して処理する
• 案件管理者：繰り返し発生する例外を通常工程へ組み込む

仮に100件中90件が通常処理であれば、90件は長いマニュアルを読まずに流せます。複雑な判断が必要な10件だけを、判断に適した担当者へ集められます。全員を例外処理まで教育するより、処理速度も判断の一貫性も高くなります。

例外ボタンは作業放棄ではなく、正規の処理である

例外フラグを用意しても、作業者が「できないと評価されるのではないか」と感じれば、無理に通常処理しようとします。その結果、迷う時間が増え、推測による入力ミスも起こります。

そのため、通常条件に当てはまらない場合は例外として送ること自体を、正しい作業として明示します。ただし、何でも例外にできる状態では処理が集中してしまうため、例外にする境界はフィジビリや本番初期の全件検品で調整します。

例外として集まった案件も重要な改善材料です。同じ種類の例外が何度も発生するなら、それはすでに例外とは呼べません。新しい選択肢を追加する、判定条件を画面に表示する、前処理で振り分けるなどして、通常工程へ戻します。

この更新を繰り返すほど、通常作業は単純になり、例外処理担当者へ届く件数も減っていきます。

工程を分ければよいとは限らない

分業には受け渡しが発生します。前工程と後工程でデータを移す、担当者ごとの進捗を管理する、処理結果を再び結合するといった工数が増えるため、少量案件では一人が最初から最後まで担当したほうが速いこともあります。

また、前後の文脈を見なければ判断できない仕事を細かく切りすぎると、かえって品質が落ちます。工程分解は、単純に担当者を増やすことではありません。

見るべきなのは、分割によって減る判断時間と、受け渡しによって増える管理時間の差です。フィジビリでは、作業時間だけでなく、例外率、質問数、差し戻し率、検品時間まで記録します。入力が10秒短くなっても、質問対応が20秒増えるなら改善とはいえません。

実際に手を動かしている時間はTouch Time、受付から完了までの待機を含む経過時間はCycle Timeと区別できます。作業そのものが30秒でも、回答待ち、検品待ち、件数の再配布に数時間かかれば、納期は短くなりません。工程改善では、Touch Timeだけでなく、両者の差にある待ち時間も確認します。

処理時間の短縮が、品質を守る余力になる

見積もり時点で1分かかっていた作業を、工程設計によって30秒にできれば、同じ時間でより多くの件数を処理できます。これは、作業者へ無理な速度を求めたり、報酬を下げたりすることではありません。迷い、待ち時間、不要な入力、重複確認を減らした結果です。

短縮によって生まれた余力は、BPO会社の利益になるだけでなく、検品、例外処理、管理者の配置にも使えます。通常工程の原価を下げることで、品質を守る工程へ十分な工数を残せます。

1分の作業を30秒にするとは、同じ仕事を倍速で行わせることではありません。判断する仕事と手を動かす仕事を分け、通常処理から迷いを取り除き、道具と画面を作り替えることです。作業者の能力だけに頼らず、速さを工程の中へ組み込むことが、BPOにおける業務設計だと考えています。