某大手IT企業の営業マンが語った、RPAを勧めない理由と対処方法

私は会社でRPAの導入検討を行っています。現時点の状況は、各部門から業務自動化対象の手順書・業務フローを頂いており、RPA導入後の処理フローや、予想効果の算出まで完了しています。

そこで、業務自動化が可能なRPA製品をヒアリングするため、誰もが一度は名前を聞いたことがあるであろう、某IT企業大手の営業担当者と打ち合わせを行いました。

ところが、その営業マンはRPAを勧めない、RPAはダメだと主張しており、私も納得した部分もありましたので、ここ記事で紹介し、私が思う対処方法を記載します。

営業マンの言い分：画像認識方式の自動化は、UIデザインや色が変わっただけで使えなくなる

例えば業務アプリケーションでの作業を自動化する場合、人のマウス操作やキーボード操作を自動化する処理方式で実装することが考えられます。

このとき、ボタンやテキストボックスの画像をRPAに登録して、この画像と一致するものを見つけて、クリックしたりキーボード入力したりするのですが、UIデザインが変わるとRPAに登録した画像と一致しなくなるので、動かなくなる、というものです。

まぁ、確かにその通りですね。

対処方法：キーボード操作（キーストローク）で自動化する

画像認識は最終手段で、これ以外でできる方法をまず模索してみるのがいいと思います。その方法の１つにキーボード操作で画面操作していく方式です。これであれば、多少UIが変更されても、ショートカットキーが変わらなければRPAによる自動化は可能だと考えています。

営業マンの言い分：HTMLタグ認識は、HTMLのIDやClassなどの属性が変わると動かなくなる。

まぁこれも、おっしゃる通りだと思います。特に、他社が展開しているウェブサイトだと、他社のやりたいようにフロント側が変わってしまうので、しっかり情報をウォッチしておかないと、「急にRPAが動かなくなった！」という事態がおこります。

対処方法：HTMLタグの属性がページ内に存在しない場合のエラー制御をしっかり実装する

例えば、指定したHTMLタグ属性が存在しない場合はエラーメールを送信して異常を検知するという方法です。HTMLソースはウェブサイトを提供している会社が自由変えられますので、「勝手に変えないで！」と要望を出したところで実現するわけがありません。なので、利用者側としては、RPA処理がしっかり止まって異常終了したことがわかる仕組みの実装が重要です。

営業マンの言い分：WindowsフォームのUIセレクタ(ウィンドウハンドラ)も変わると使えなくなる

ウィンドウハンドラ、詳しいことはわかりませんが、Win32APIで取得できるアレですよね。これもHTMLタグ要素と同じで、UIコンポーネントが変わってしまうとRPAが処理できなくなってしまいます。

対処方法：UIが変わるタイミングでRPAを修正する

内製開発しているシステムであれば、自社内でコントロールできますので、他社が提供しているウェブサイト対応よりはよっぽど簡単にできます。外注しているアプリケーションも、受入試験のタイミングでRPAをテスト対象に組み込めば、事前に不具合があるかどうかを確認できます。

また、パッケージシステムも同様ですね。バージョンアップする前に必ずテストしますので、そのときにRPAの処理もテストすれば、本番運用中に急にエラーになるということは考えにくいです。

営業マンの言い分：RPAは自動化対象のシステムによって処理結果が大きく変わる。プログラミングした方が動作が安定する

上述したとおり、画像認識もタグ認識もウィンドウハンドラ認識も、画像や属性やハンドラが変わってしまうとすぐに動かなくなります。なので、こんなものに頼るよりはソースコードを書いた方がよっぽど安定しますよ、という主張です。

対処方法：内部的にVBscriptなどプログラミング言語で動作するRPAもあるから、必ずしもプログラミングが必要にはならない

RPA製品によっては、内部的にスクリプト言語で自動化を実現している製品もあります。なので、1から10までプログラミングしなくても自動化の恩恵を得られる可能性があります。

ただし、これはRPAパッケージが用意したスクリプトに当てはまりますので、用意されていないものは自分でプログラミングする必要があるかもしれません。

営業マンの言い分：我々はRPAベンダーではないから、実情を話している

まぁ、そうなんでしょう。売る気が無さそうな匂いがプンプンしました。売る気がなさすぎて、なんのための打ち合わせだったのか分からなくなってしまいました。

RPAに欠点があることは重々承知していたつもりです。それを回避するための情報が知りたかったのに、このRPA製品なら出来ますよ！って情報が欲しかったのに。。。

対処方法：RPAで出来ることは、プログラミングするよりも早く簡単に実現できるから、導入するべき

これに尽きると思います。どんな製品だって、欠点を上げればキリがありません。ダメなところなんて、いくらでも言えてしまいます。

利用部門の要求を早くて安くて簡単に実現できるのがRPAなら、既知の問題にしっかり対処して、導入するべきだと思います。

最後に：RPAで年間数千時間も効果が出る理由は、1作業のトータル作業時間が長いから

RPA製品の導入事例やネット記事を見ると、年間数千時間も工数削減できました、という内容のものをよく見ます。しかしこれにはカラクリがあって、ある特定の1作業がトータルで数百時間かかっていて、その1作業だけをRPAで自動化した、という理由のようです。

例えば保険の支払い業務で、申請内容と自社保有のお客様情報の突き合わせを行う作業というのは、年間で数百時間もかかっているそうです。このたった1作業を自動化するだけで、数百時間もの工数を削減できるのです。

そのため、年間数時間の作業をたくさん集めてRPAで自動化させようとすると、1つの製品で様々なことを自動化させる必要が出てきますので、効果よりもシステム変更による保守作業に手間がかかってしまうことが多々あるそうです。

RPAは万能じゃない。自動化対象を出来るだけ絞って、効果が出るものから進める

上述したとおり、RPAは様々な要因で動作停止が起こりうるシステムです。そのため、ある程度部門から自動化させたい業務の分析が完了したら、1つ1つの作業ステップを分類して、出現回数が多くて時間がかかっているものからRPA導入を検討するべきだと考えます。

例えば分析した結果、Excel操作が多いのであれば、Excel操作を実現するスクリプトが多いRPA製品を探すか、VBAでツールを作ることを検討しましょう。ウェブサービスやウェブアプリケーションなど、ブラウザで稼働するシステムが多いのであれば、HTMLタグ解析に強いRPAを導入するぁ、seleniumなどのブラウザ操作自動化ツールの導入を検討しましょう。