RPAにかかわって、ロボットで置き換えができる業務、置き換えられない業務、もしくはロボットに向く業務、向かない業務、適した業務、適さない業務について体系的に検証する機会を幸いにもいただくことができた。
せっかくなので、他の人たちがスムーズにRPAを導入できるよう、得られた知見をまとめていきたいと思う。
「適した業務」、「適さない業務」の概念の分類
まず、RPAに「適した業務」「適さない業務」というのはいくつかの基準で考えるべきであることがわかった。一番わかりやすいのは、「それはロボットに操作が可能なのか」といった基準であるが、実はそれだけではなく「操作は可能だけれども人間の補助なしで可能なのか」さらには「補助なしで操作は可能だが現実的に運用可能なのか」といった観点も必要である。
- RPAロボットに操作が可能かどうか
- 物理的・ソフトウェア的に操作可能か
- 人間の判断なしで操作可能か
- 運用が現実的に可能かどうか
- 複雑すぎないか
- 中央からの管理性、担当者不在、野良ボット化の面から
- コスト・ROIの面から
このように、いくつかの観点から判断していく必要があることがわかる。特に気を付けないといけないのは、コスト面の管理である。ロボットも1台追加すればライセンス費用だけで最低年間15～30万円くらいは追加になる。ロボットの種類のよっては100万円近くなることもある。たとえば従業員や派遣社員を雇うのであれば、普通は現場で勝手な判断はせずに常に管理職の判断を仰ぐであろう。最終的にROIが出る運用を目指すなら、コストが管理できずに雪だるま式に増えていくような運用は避けなければならない。
以下では、RPAが得意とする業務であるかを比較表形式(👍, 🔺 or❌)で表してみた。人間が得意なようであれば従業員や派遣社員の増員を検討、高度なプログラミングが必要であればシステム統合の外注や汎用製品・サービスの導入を考える。ロボットが得意であればRPAの導入を検討するとよいだろう。
1. RPAロボットに操作が可能かどうか
そもそもロボットに操作ができなければ、RPA化することはできない。ロボットといってもソフトウェア上で動作するロボットなので、いわゆる人間型のロボットとは全然違うものである。
1-1. 物理的・ソフトウェア的に操作可能か
RPAに操作できるものとできないものがあるので、明らかにしておこう。
| タスク内容 | 人間 | RPA | 説明 |
|---|---|---|---|
| 身体的労働・デスクワーク | 👍 | ❌ | RPAはパソコン上で動作するため、パソコンの外側の世界の仕事は受け付けない。紙の帳票をOCRで読み込んでオンラインデータ化する業務シナリオはあるが、読み込んでデータ化する部分は人間が介在する必要あり。 |
| Windowsの操作 | 👍 | 👍 | RPAが動作する前提の環境である。 |
| Macの操作 | 👍 | ❌ | Mac上で動作するRPAはほぼない。Windowsである必要がある。 |
| Linux・Unixの操作 | 👍 | 🔺 | Linuxで動作するとしているRPAがないわけではないが、実用性はほぼないと言っていい。Linux・Unixの操作はWindowsからターミナルで画面を表示させて操作することは可能。 |
| スマートフォンの操作 | 👍 | ❌ | iOSやAndroid上で動作するRPAはない。iOS、Androidの開発環境ではWindows上でのエミュレータも提供されているが現実的ではない。 |
| タブレットの操作 | 👍 | 🔺 | WindowsタブレットであればRPAソフトウェアは動作するが、サポートしている操作はマウスクリック、キーボード操作であり、タブレットの特徴であるタッチ、スワイプなどの操作はサポートされない。 |
1-2. 人間の判断なしで操作可能か
RPAでは大規模に自動化ができるとROIが出てくる。その時に人の判断がいちいち必要になってくると、人の業務を補佐はしてくれるがロボットだけでは業務がまわらず、効果は限定的になってしまう。
| タスク内容 | 人間 | RPA | 説明 |
|---|---|---|---|
| 定型業務。単純な繰り返しが多い作業 | 🔺 | 👍 | 人間は単純作業は疲れてしまう。ロボットは単純作業は大の得意で昼夜問わず高速で処理できる。ただし、人間の処理待ちが必要なデータを途中で入力する必要がある場合は効率が落ちる。 |
| 非定型業務。柔軟な判断が必要になる作業 | 👍 | ❌ | 判断基準が明確な論理に落とせないもの、例外処理が多いものは機械的な判断ができないため、人の判断にゆだねられることになる。無理に固定的な判断に収めてしまうと、運用時に判断の柔軟性が失われることがある。判断基準に外付けのAI/機械学習の仕組みを入れて判断させることもできる。 |
| 画像認識 | 👍 | 🔺 | 非定型業務の一部。RPAもOCRで文字認識処理が可能だが、画像の解像度、手書き文字、背景画像などの環境要因により認識精度が落ちることがあり、人による再確認が必要になることがある。AI/深層学習で物体認識を行わせたり帳票の種類の特定、軽微な変更の認識を行わせることは可能である。 |
2. 運用が現実的に可能かどうか
ロボットに作業が可能だとしても、運用が大変になったり、事実上破綻してしまうような作業はRPA化すべきではない。システム開発では保守運用は開発費用の1/5程度になるといわれているが、RPAの場合は隙間業務で短期間で変更がかかる業務が多く開発費の1/2程度が運用費用としてかかってくる。汎用製品・サービスが利用できるところや、システム統合の外注コストが見合う場合は、RPAではない選択肢を取るほうが無難である。
2-1. 複雑すぎないか
| タスク内容 | 人間 | 外注 | RPA | 説明 |
|---|---|---|---|---|
| 複雑な判断が入る作業 | 👍 | ❌ | 🔺 | 条件分岐が多すぎる場合は、得てして柔軟な判断が求められることがあり、RPAが継続的に機械的判断をすることは難しい場合が多い。 |
| 複雑な画面構成の作業 | 👍 | ❌ | 🔺 | 画面を頻繁にスクロールしたり、数多くのウィンドウが出てくる、画面のボタンが様々なグラフィックで判別しにくい、などの場合は、RPAの操作が間違う確率が高くなる。 |
| 変更が多い作業 | 👍 | ❌ | 🔺 | 変更が頻繁に入る作業もロボットには向かない。いちいち変更をしていると管理工数があがったり、ミスの原因となる。 |
| タスクの種類が多い作業 | 👍 | 🔺 | 🔺 | タスクの種類が多い場合、ロボットを並行してさまざまな種類を用意しなければならないケースが出てきて管理が煩雑になってしまう。 |
| タスク内の処理数が多い作業 | ❌ | 👍 | ❌ | タスクの中の論理の数が100を超えるような長い作業も向かない。なぜならRPAをまわす現場のノンプログラマーのメンバーの理解が追い付かなくなってしまうからである。RPAツールベンダーは200～300を上限としているようだが、論理数はなるべく少ないほうがいい。 |
2-2. 中央からの管理性、担当者不在、野良ボット化の面から
作業の管理の問題は従業員・派遣社員が作業をする場合であっても、外注する場合でも発生する。これはロボットの場合も同様である。
ロボットの管理は各担当者に任せるのではなく、COEを作ってその指示のもと、プロジェクト全体の進捗管理、ROIが出ていることを確認するコスト管理、ロボットの稼働時間管理によるリソース利用の最適化を行っていく必要がある。また、作業やボットの内容が担当者に依存しすぎない、担当者交代時のブラックボックス化を防ぐようにすべきである。BPOのプロジェクトなどと同様である。
これらのことを実施しようとするとデスクトップ型ではなくサーバ型RPAの導入が必須となる。
2-3. コスト・ROIの面から
| タスク内容 | 人間 | 外注 | RPA | 説明 |
|---|---|---|---|---|
| 汎用製品・サービスが存在する作業 | 🔺 | 👍 | ❌ | 汎用品があるものは、それを使うのがコスト的に一番安くなることが多い。想定する業務フローは業界標準的なものになっていることが多いので、この機会に自社の業務フローを汎用品に合わせる検討をしてもいいかもしれない。 |
| ひとつの製品内で完結する作業 | 🔺 | 👍 | 🔺 | これはケースバイケースだが、Excel/PowerPointで報告書を作るだけのような作業は、付属のマクロを使うとRPAがなくてもできてしまう。マクロや自動化する方法が別にあるものは、そちらを使ったほうがコストが安い。 |
また、今回の記事の範疇ではないが、RPAの導入にあわせて既存業務の見直しは行い業務フローを整理したほうがいい。実は不要な業務とか判断フローが見つかることも多く、RPAを無理やり既存業務にあわせると運用がうまくいかなくなることが多い。事前BPOとも相性がいい。この話題の詳細はまたの機会に。
RPAは指示通りに動く「手」「足」なので、その特性をうまく使いこなせば業務効率をうまく上げられるだろう。