企業は、RPAを使って全ての業務の自動化を目指すのではなく、複雑なプロセスの中でも特に単純な作業を自動化することで業務の最適化を目指すべきだ。20人の従業員の業務を100％自動化するよりも、1000人の従業員の業務を50％自動化する方が有効だ。

　また、RPAは自動化の切り札としてではなく、デジタルトランスフォーメーション（DX）の手段として用いることも可能だ。

　DXの目標は、ビジネスを変えることにある。RPAが担うのは一部の業務の最適化だ。DXのためには、最終的にRPAをよりインテリジェントな自動化技術に置き換える必要があるだろう。管理コストがかかる古いレガシーアプリケーションの不適切なプロセスを自動化しても、不適切なプロセスであることは変わらない。

設定すればそれで終わりではない

　RPAは設定すればそれで終わりというものではない。RPAはAPIにとってスケーラブルではなく、IT部門にとってはあまりにも危うい。Pegasystemsがグローバルな意思決定者509人に行った最新の調査によると、回答者の87％が何らかのレベルでbotの障害を経験しているという。回答者の41％は運用中のbot管理に想定よりも時間とリソースを費やしていると答えた。RPAによる自動化をAPIに公開してデジタルインタフェースの設計を見直すことは可能だ。だが、こうしたRPA接続は一時的なものになるだろう。

　DXに真剣に取り組むためにインテリジェントに自動化するなら、RPAよりもはるかに優れた技術がある。以下にその例を挙げる。

• 面倒なスプレッドシートをなくすために、サイロ化されたマクロではなく一元管理型の統制の取れたルールをサポートするローコード設計
• OutlookでRPAを使うのではなく、電子メールを読み取って応答する自然言語処理を備えた一元的な電子メール管理
• 使い古されたプロセスのリプレースと不適切なプロセスを実行するレガシーアプリケーションの廃止を促進するオーケストレーションとローコードの併用

RPAの不使用

　複雑なプロセスの自動化にRPAを使うべきではない。

　RPAの軸となるのは、ユーザーインタフェース（UI）を通じた画面の自動化だ。つまり、画面から何らかの情報を読み取り、データに何らかの手を加えて画面に送り返すことだ。こうした目的のRPAにはあまりインテリジェンスを必要としない。というのも、全てのRPAはOSの制限を受け、そこで実行される多数の複雑なコンパイル済みアプリケーションをサポートする能力の制限を受けるためだ。画面上の文字認識にインテリジェンスを利用することもある。だがこのような場合、アプリケーションの自動化は一部のRPA製品におけるオブジェクトベースの自動化よりも低速で、不安定になる。

　複雑なアプリケーションやGUIを組み込んだ複雑なプロセスはRPAには不向きだ。こうしたプロセスは不安定で、サポートコストが高く、頻繁に機能しなくなる。

　また、EAI（エンタープライズアプリケーションインテグレーション）の長期プロジェクトにもRPAを使うべきはない。アーキテクチャ的に不適切だ。

　UIの簡単な変更でも、RPAチェーンにつながる場合はEAIに深刻な影響を与える可能性がある。検証済みの安全な技術で接続された堅牢（けんろう）でスケーラブルなAPIを使うことを目的とするエンタープライズアーキテクトにとっては悲惨な状況になりかねない。ただし、このようなAPIは短期的な最適化やDXの実現のために必ずしも利用できるわけではない。このような場合は、RPAを応急措置的な手段として考えることは問題ない。

　今後、RPAがどのように進化していくかを見守るのは興味深い。RPAのスケーラビリティの欠如をきっかけに、少なくとも不適切なプロセスに関心が向けられ、最終的にはそれらを変革する計画が始まることになるだろう。

フランシス・カルデン氏はPegasystemsでデジタルオートメーションおよびロボティクス部門のバイスプレジデント。