ホワイトカラー業務を効率化する「働き方改革」の大本命と話題のRPAソフトウエアですが、人手で行っている業務を自動化するメリットがあるのと同時にRPA化による「デメリット」や「リスク」も存在します。
ここでは、RPAの仕組みや、RPAとはどの様なソフトウエアなのか等をある程度ご存知の方を対象に、RPAを先行して導入された企業の事例で見えてきたRPAを導入するにあたっての注意点や、その後の運用に入っての問題点などのあまり語られる事のないRPAのデメリットや導入する事によるリスク等に関してご紹介しています。
RPA導入におけるリスク
間違った進め方によるリスク
RPAの導入にあたっては、その進め方が非常に重要となります。最初は効果が最も期待できそうな業務からトライアル的に開始して効果を実感してから全社展開を考えようというアプローチ自体は良いのですが、当初からしっかりとした体制や進め方を考えておく必要があり、この点を軽視すると下記のようなリスクを抱えてしまう事になってしまします。
行き当たりばったりのプロジェクトは後々下記のような問題に直面するのが明らかだからです。
【想定されるリスク】
- 部門に閉じた最適化に終始し、業務効率化の定量効果をアピールした全社展開に進み難くなってしまう
- シナリオの再利用が進まず、毎回１からRPAシナリオを作成することになり、開発生産性が悪い状況が続く
- 社内でRPAシナリオ作成・保守に関するナレッジが蓄積されず、結果的に個人に依存する状況となる
- 無管理状態のRPAロボが増殖し、統制不能（Excelレガシー問題の再現）になる
- RPAロボの業務効率化効果が数値で測れない（感覚的には楽になった、ではその先に進みにくい）
- 保守性が著しく低い大量の個別RPAロボが増殖してしまう
なぜなら、
RPAはその導入の仕方によって結果的な効果や導入費用の大小はあったとしても、明らかにROI（投資対効果）が出せるソリューションであり、将来のAI活用を見据えても導入しない選択はない
からです。あるのは、いつ始めるか、どの様に進めるかの選択です。
プログラミング不要は嘘
RPAとはどの様なソフトウエアかと言う説明の中でよく言われてるのが、「RPAはプログラミング不要」という点があります。これ自体は間違いではなく、実際にRPAの導入においてプログラミングをする事自体は必要ありません。
しかし、RPAを多少でも触ってもらうと理解できるのですが、
RPAソフトウエアは作成にプログラミングは不要だが、プログラミングの知識は必要
と言う表現のほうが正しいと思います。ExcelのVBAなどでも良いので何か簡単な１言語でもプログラミング言語の知識・経験があると、RPAのノンプログラミングのありがたみを感じる事が出来るでしょうし、何より理解がし易いのも確かです。
RPAの仕組みはこちらでご説明していますので、参照下さい。 ⇒
RPAシナリオの作成を行う場合、表面的にはプログラムフローとして作成しますが、内部的にはVB（Visual Basic）などの言語が生成されており、画面の各要素やプログラムフローを制御する部品を組み合わせる事で、その機能に相当するプログラムブロックが裏で組み立てられていきます。
実際にその自動生成されたログラムを見る事も出来ますし、そのコードを読めば何をやっているのかだいたい理解できるものになっています。よってRPAシナリオを記述するのも業務フローのレベルではなく、プログラムフローなのです。結論として、
プログラムを直接書くよりは楽だが、フロー制御や内部変数といったプログラム言語の知識・経験を持った要員がRPA開発には必要になる
現在のRPAツールは過渡期の製品と心得る
◆ 作り込み過ぎると後に響く（スピード重視で）
RPAツールの仕組みをご存知の方は理解されているかと思いますが、現在販売されているRPAツールはどれも過渡期・発展途上の製品と考えておいたほうが良いかと思います。
だからと言って「使えない」とか「導入は待ったほうが良い」と言う意味ではありません。現在のRPAツールの仕様でも十分な業務効率化効果を得られますので、積極的に効果を享受したほうが良いかとは思います。（スピードが命です）
従来型の大規模システム開発プロジェクトでやっていたような時間と労力・費用を投入して【 作り込み過ぎない 】
ほうが後々柔軟にバージョンアップやツールの変更などが出来て良いのではないか、と考えられます。
◆ 近い将来のバージョンアップを考慮しておく
実際に WinActor の開発元であるNTT-ATではかなりの勢いで機能改善・開発が進んでいるそうです。（下記は一例）
- Edge、ChromeなどのWebブラウザー接続標準モジュール
- ノーツDBへの接続モジュール
- SAPへの標準接続モジュール
- RPAにはAIの機能が盛り込まれ、柔軟に判断動作が可能となる（ちょっと先）
- バックグランド実行
但し、余程、必須の機能がない限り、これらの機能が盛り込まれたバージョンを待つのではなく、現在のツール機能で可能な自動化効果を早期に享受するのが賢明かと思います。
RPA運用におけるリスク
RPA導入の仕方が運用コストに跳ね返る
RPAの導入アプローチには下記の２通りがあります。
◆ 現状業務のままRPAで自動化
あくまで現状業務の中でPCを使っての繰返し作業になっている部分をRPAで自動化するやり方です。現状業務や使っている基幹システムなどには手を入れずに、ほぼ人が行っている通りにRPAにやらせます。
この場合、現状は社員が手で行っている業務ですから、その流れやどこのシステムにどの値を入力（出力）しているかなど、完全に理解している社員がいるはずです。
従って、何か業務的な変更が必要となっても、その社員の方が理解している業務フローの中で修正が可能なはずです。
◆ 業務を全社規模でRPAに最適化して導入
一方、RPAで自動化する事を前提に、従来の大規模システム導入プロジェクトのイメージで現状の業務を完全に見直してからRPAを導入すると、全く業務に流れが変わってしまい、結果的にデータ、業務処理の流れがどの様になったのか完全に理解している社員が誰もいない状況になりがちです。
まして、外部のコンサルティング会社やSI会社に完全に丸投げで委託して、業務整理から実施すると更に業務がブラックボックス化してしまうリスクが高まります。
こなると、もう完全に俗に言うベンダーロックインの状況ですので、その先をご説明するまでも無いかと思います。（但し、時間と費用をかけてBPRから実施すれば、高い業務効率化の効果が見込める事は確かです）
RPA運用にかかる工数は以外に大きい
元々RPAを導入したら、その運用コスト（工数）をある程度見込んでおく必要があります。そして、RPAは元々プログラミングが不要で開発工数が低いため、運用に入っても開発工数の半分程度の工数を見込んでおく必要があります。
通常、サーバー型の大規模システム開発を行う場合の開発工数を１００とした場合、その運用工数は1/5の20程度と言われています。
RPAの場合は元々業務ユーザーが手軽に自分の日々の業務を自動化するソフトウエアですので、開発工数自体はサーバー開発の1/10程度ですが、日々の業務が変更になるような場合に、自身でRPAシナリオもメンテナンスする事になります。従って、右図の通りRPA導入工数の半分程度の保守・運用工数を見込んでおく必要がある、と言われています。
自社の現状業務をそのままRPAロボに置き換えようとすると、どうしても無理がでたりRPAロボにデータを与える為の前処理を人手で行う追加作業が発生したり、RPAロボが１体１様で非常にメンテナンス性が悪いものになってしまったりします。 ⇒
従って、先ずはRPAで実施する事を念頭に置いた業務プロセスに変更・整理してからRPAシナリオを作成するのが順番的には良いのですが、業務プロセスを自社で変革できる会社はそう多くないものと思われます。よって、
自社で業務プロセスの整理が出来なければ高額でコンサルティング会社に委託する事になり、ROI（投資対効果）が低下する
現時点でRPAに精通しているコンサルティング会社、要員が少なく、受けてくれても相当待たされるか、かなりの高額になってしまう事が予想されます。このあたりも現時点でのデメリットと言えるでしょう。
業務がブラックボックス化するリスク
上でも書きましたが、RPAシナリオを作成するときに記述するのはプログラムフローです。業務フローではありませんので、プログラム言語の知識・経験がない業務ユーザーの方が見ても決して簡単に理解できるものではありません。
それでも、現状手作業で行っている業務をRPAロボに置き換えた当初は、特にプロジェクトに関わったユーザーの方々はどのRPAロボがどの様な業務処理を行っているのか理解していることでしょう。
しかし、時がたち人事異動や退職などで人が入れ替わると次第にRPAで行っている業務がブラックボックス化していくことが想定されます。やはり、プロジェクト中にRPAシナリオだけではなく、しっかりとしたドキュメントを作成し、変更があった場合はドキュメントのメンテナンスも怠りなくやっていく必要があります。
この様にRPAシナリオと関連するドキュメントをメンテナンスしていったとしても、それが完全に外部ベンダーに依存していては、自社の業務を完全にその外部ベンダーに握られてしまうリスクがある
これは、過去のEUC（エンド・ユーザー・コンピューティング）のブームにより起こったExcelレガシー問題に似ています。無管理状態で大量に作成されたExcelマクロやノーツDBが後々になって仕様が解らないため、変更も拡張もできず、しかし、業務に密着している為に廃止する事も出来なくなってしっている企業が多いのです。
向かない判断業務のRPA実装で、柔軟性を失ってしまうリスク
RPAは元々人がPCに向かって手作業で行っている単純繰返し作業を代替してくれるロボットです。その実装方法を見ても複雑な判断を含む業務には向かないにも関わらず、無理してRPAに複雑な判断ロジックを組込もうとしてしまうことがあります。
その様な複雑な業務判断は、ビジネスと密接に関連し取引条件などが変更になれば直ぐに変わってしまう性質のものです。従って、その判断ロジックには高度な可視性、保守性が必要となりますが、残念ながら現在のRPAに実装するには向かず、無理してRPAでやらせようとすると業務運用が極めて制限されてしまうことになりかねないと思われます。
RPA運用の外部丸投げにつながる
◆ 日本企業はITを外部に丸投げしてきた
多くの日本企業は自社のITシステム開発・運用を外部ベンダーに丸投げしてきました。これはこれで合理的な面もありました、それは
- 自社で人材育成・獲得が難しい最先端の技術導入による効率化などの効果を享受できる
- 本業以外のIT要員を多く抱える必要がなく、IT戦略機能のみの保有で済んだ
- 多くの顧客を持つITベンダーと付き合うことで同業他社などとのベンチマークが出来た
しかし、RPAに関して言えばそれ自体は新しい技術要素は殆どなく、枯れた技術の集大成的なソフトウエアである点が違いますし、RPAはITと言うよりも社員と共に業務を任せるロボット社員として捉えるのが良いかと思います。
その意味で、現在のIT開発・運用と同じような意識で外部に依存することは、非常に危険でありデメリットが大きいと言えます。
◆ RPAでもコア業務は外だし出来ない
人事・総務や経理などの間接業務を外部のBPO（ビジネス・プロセス・アウトソーシング）専業に委託している会社は多いかと思います。これらの間接業務は外部に委託することで内部で実施するよりも人員を減らすことが出来て、効率化出来るのであれば良いのだと思います。
情報漏洩などのリスクをしっかり管理できるのであればこれらの間接業務はどこの会社でも然程変わらないでしょう。しかし、RPAロボが代替する業務は間接業務のみではなく、自社のコア業務を含みます。
RPAの導入は自社のコア業務の遂行能力、すなわち競合に対する競争力を左右する重要な業務を含み、一旦RPAで自動化して終わりではなく、導入後も常に改善を繰り返していくべき業務です。
RPAは多くのコンピュータ能力を要する
サーバー開発型RPAはサーバーが必要
RPAソフトウエアにはサーバー開発型、PC導入型、クラウド型などが有りますが、サーバー開発型のRPAは従来のクライアントサーバー型のシステム開発に近く、サーバー上でRPAシナリオを管理していきます。
RPAソフトウエアの種類とライセンス価格のイメージをこちらでご紹介していますので、参照下さい。 ⇒
RPAシナリオの開発自体はユーザー自身のPCで行い、サーバーに開発済のシナリオを登録して、全体の実行管理を行っていく構造が多いのですが、何れにしてもサーバーのハードウエアを自社で調達して、データセンターに管理する必要が出てきます。この様な関係で、
サーバー開発型のRPAはユーザー部門が主導して日々の繰り返し作業を自動化するイメージの手軽さはありません
RPA専用のPCが必要
上記でも書きましたが、RPAロボを導入すると言う事はイメージ的にはロボット社員を新たに雇うようなものです。従ってそのロボット社員が使うパソコンを専用で準備する必要がでてきます。
もしくは、日中は社員がそのPCを使い、夜間はRPAロボが使うような使い方は可能ですが、１台のPCを人とRPAロボが同時に使う事は出来ません。
それはRPAの構造、仕組みをご理解頂ければ納得してもらえるかと思いますが、RPAはPCに対して人が操作しているのと同様に、キーボードやマウスをソフトウエア的に操作し、Windowsに対して同じ信号を出して動かします。 ⇒
そのパソコンはRPAロボ社員の専用となり、少なくとも自動実行している間は基本的に他の方は使う事が出来ませんので、一見すると誰も使っていないPCが置いてあるように見えてしまいます。
RPAの処理能力はPCに依存
RPAロボに多くの繰り返し処理を実行させようとすると、能力が高いコンピュータを準備する必要があります。普通の方が想像するよりも多くのコンピュータ能力をRPAは必要とし、RPAの実行速度はPCの能力に大きく依存します。
ネットワーク環境などに依存
当然の事と言えば当然の事ですが、社員が通常使っているのと同じようにネットワーク環境に繋がったPCでPAロボも作業をしますので、RPAの実行速度はネットワーク環境にも大きく依存します。
その他、通常どこの会社のPCにも入っていると思われるマカフィーやシマンテックなどの様なセキュリティーソフトにもRPAロボの実行速度が影響を受けるものがあります。
RPAシナリオの画面に表示されている処理フローの動きを見ていると、人手では不可能な速度で動作します。
PCローカルにインストールされたソフトを使っている間は非常に高速で動作し、ネットワークを介して使うシステムに移った途端極端に動作が遅くなったように見える場合があり、ネットワークやセキュリティーソフトなどに依存してRPAの能力が削がれているを理解出来るかと思います。
経営戦略の幅を狭め、スピードを失わせる可能性
本業の外部依存に繋がるリスク
RPAが自動化するのが間接業務のみではない以上、
本業の外部依存は高額な委託費用以上に、採り得る経営戦略の幅を狭め、スピードを失わせる
本業を外部に依存することは、自社の存在意義を否定しているに等しいと言えます。今こそ、業務部門が主体的にRPAを使って自社のコア業務の効率化を進めるべきです。
これを避ける為にも、RPAはやはりクイックに現状業務のまま導入して、その後も現場の改善活動として業務効率の改善を継続していくのが良いかと思います。
外部に高額を払い続けるリスク
仮に、自社がコントロールし易い外部委託先がうまく見つかり、その会社にRPAロボの作成・保守を丸投げ出来たとしても100%出資の関連会社でもない限り委託価格の決定イニシアティブは徐々に奪われ、次第に高額になっていくでしょう。
RPAではありませんが、ERPなどの基幹システムの開発・保守を完全に外部に握られ、他社に切り替える事も出来ずに高額を払い続けている会社をこれまで多く見てきました。
デメリットを回避する為には
RPAを導入することにより考えられるデメリットやリスクに関してご説明してきましたが、結論から言うと、
自社の業務を代替するRPAはあくまで現在社員が行っている業務を任せるロボット社員であり、自社が主導して進めるべき
と言う当然と言えば当然の事であり、外部に丸投げ依存するのではなく自社の業務運用・戦略立案能力を高め、RPAロボを前提とした業務プロセスを洗練させていくのが最善であり、その為に社員を育成していくのが結果的には近道と考えられます。
DEXCAでは、RPAロボを完全に受託作成するのではなく、業務プロセスを整理し、RPA化するプロセスを社員の方との協業で行い、社員の方々にRPAに関する開発・運用のノウハウを移転する進め方でご支援させて頂いております。 ⇒
