RPAは「プログラミング不要で誰でも簡単に使える」といったイメージが強いのですが、そうとも限りません。
RPAがその威力を発揮できるかどうかは、API連携も含めた全体最適の視点をもって適材適所で活用できるかどうかにかかっています。
今回は、そんなRPAについて、APIやiPaaSとの違いを含めてお話していきます。
目次
RPAは操作対象システムのUIが変わると動かなくなる？
マーケティング・セールスプラットフォームを提供する「HubSpot」社のブログに気になる記事がありました。
実はRPAには大きなデメリットが1つあります。
Zapier（ザピアー）とは？働き方改革を実現するiPaaS活用の極意より一部引用
RPAの基本機能は、コンピューターのマウスやキーボードの動きを模倣して、事前に設定した動作を自動化するというものです。
つまり、これは何を意味するのかと言うと、ソフトウェアのユーザーインターフェースが変わると、場合によっては動かなくなってしまいます。
API連携をノンプログラミングで活用できるiPaaS（Zapier）との対比でRPAの弱点を指摘した部分があるのですが、弊社では「場合によっては」という部分を強調しておきたいと考えます。付け加えるとすると「そういうRPAもある」というのがより正確な表現でしょう。
引用した記事で指摘されているような現象は、「ブラウザで表示された画面を画像としてとらえ、要素の座標を認識しているRPAであれば」という前提付きで理解する必要があります。
そのような形式であれば画面上のわずかな違いでも操作対象要素を認識できず、結果としてRPAの動作が止まってしまうということが起こります。人間が普段使っている状態でも、同じ画面なのに端末やブラウザ・OS・利用者それぞれの環境設定などが変われば同じボタンの場所がそれぞれで違って見える、といったことは珍しくありません。
しかし、操作対象システムのUIが変わっても問題なく動作するRPAも世の中には存在します。操作対象の要素を座標ではなくHTMLソースコードで認識する方式であれば、HTML文書構造がゼロベースで変更されない限りは見た目が変化しても高い確率で動作し続けます。
つまり、これはRPA全般の問題ではなく、そのRPAが操作対象をどのように認識しているかといった各ツールの仕様に起因した個別の問題です。当該記事でも「そのような場合もある」という表現にはなっていますが、RPAすべてが同じ問題を抱えているわけではないというのは改めて申し添えたいところです。
操作対象がスクラッチ開発のオンプレミス型なら「UIが変わる問題」とは無縁？
検討されているRPAが要素の認識に座標等を利用しているか、あるいはHTMLのCSS classなどを利用しているかどうかというのは重要なポイントです。
HubSpot社の同じBlog記事で、日本市場の特徴についても触れられています。
日本企業は、スクラッチ開発したオンプレミスのシステムを利用している場合が多いため、RPAが注目を集めてきました。
Zapier（ザピアー）とは？働き方改革を実現するiPaaS活用の極意より一部引用
近年ではクラウド型のSaaS（Software as a Service）を利用する企業が増えているため、ソフトウェア側のアップデート（本当にUIの変更などは頻繁に発生します）に対応するソリューションが必要となってきます。
これについても「スクラッチ開発のオンプレミスシステムだから安心」ということではありません。UIが頻繁・大幅に更新されるSaaSはもちろんですが、スクラッチ開発されたオンプレミス型のシステムが操作対象であっても例外ではありません。保守運用・改良されている中でUIが変更されるということは、SaaSほど頻繁ではないかもしれませんが、たとえスクラッチ開発のオンプレミス型システムでもまったく無縁というわけではありません。
RPAを選定される際には「そのRPAが操作対象要素をどうやって認識しているか」をぜひ確認してみてください。
RPAよりAPIの方が良い？
「RPAはUI変化に弱い。したがってシステム間連携（iPaaS）用途には不向き」というのはすべてのRPAに当てはまるわけではなく、例外もあります。
別の視点で、複数の業務システムをつなぐ連携を考えるときにはRPAではなくAPIを利用すべきではないか、という議論があります。主要なSaaSはAPIを開放しており、APIを利用すれば効率的かつ安全にデータを活用可能ですからわざわざブラウザとマウスを前提としたようなRPAを使う必要がない、という視点です。
はたして「複数のSaaS間を連携させて業務を自動化する」という目的を果たすための手段として、RPAを使えばよいのか、それともAPIを使えばよいのか、どちらがよいのでしょうか？
RPAを利用する利点は「APIの知識が不要」
RPAのメリットは、人間の普段行っている操作をそのまま自動化できるため、APIが無いシステムでも自動化対応できるという点です。
先に説明したように、座標認識タイプではなく要素classなどを認識するシステムであればUIが変わってもHTML文書構造に大きな変更がなければ動作します。
RPAの設定は、普段の操作をGUIやレコーディングツールで登録すればOKです。業務自動化の設定から実装を進める上でAPIの仕様を理解する必要がないという点は、非エンジニア主導で現場の業務を自動化する上では魅力的です。
RPAの弱点は「安定性やスケーラビリティ」
一方、APIがあるシステムにもかかわらず「APIがわからない」という理由でRPAを使ってしまうと弱点を抱えてしまうことになります。その弱点とは「APIよりも安定性やスケーラビリティが劣る」という点です。
APIはブラウザを使わない、GUIが必要ない、認証の仕組みを備えているなど「アプリケーション間でコンテンツ・データを共有する」という目的をより重視した場合、またエンジニアがアサインできて開発可能な場合などはこちらのほうが効率的かつ安全な開発に適しています。
APIがあるのにRPAを使っているという状況自体はひょっとしたら既に起こっているかもしれません。ただ、「よくわからないからとりあえずRPA」という理由ではなく、RPAとAPIそれぞれのメリット・デメリットを理解した上で適材適所での選択をできるのがベストです。
RPAとiPaaSの違いは？
RPAをシステム間連携に使うとき、もう一つ気になるのがRPAとiPaaSとの違いです。
複数のSaaSを使っていると、クラウド上にあるシステム同士、あるいはクラウドとオンプレミスシステムの間のデータ連携をどう管理するかという問題が生じます。iPaaSはこれを解決するためのプラットフォームです。
2019年末の現時点では、複数のシステムを連携するのであれば、RPAとiPaaSのどちらを利用しても、得られる結果に決定的な大差はないといえます。
そうなるとGUIを使うRPAとAPIを使うiPaaSとの対比、つまり「RPAかAPIか」という問いに戻ることになります。
RPAはAPI連携を急速に強化し、弱点を克服している
RPAとAPIを比較した場合「RPAには安定性とスケーラビリティに弱点あり」と述べました。
ただ、最近はRPAがAPIへの対応を増やす動きになってきており、この弱点を克服しつつあります。
初期のRPAは「ブラウザとマウスの動きを記録して再現する」という単純なものでしたが、利用が進み用途が広がるにつれて安定性、セキュリティ、スケーラビリティといったユーザー側からの要求が高度化してきています。
この流れに答えるため、RPAがAPIへの対応を増やす動きが加速しています。
クラウド型RPAが登場したことにより、まずスケーラビリティの問題を克服しました。さらにクラウドの利点を活かすべくAPI連携が豊富なものも登場しています。
こうなると単に「システム間連携」を目的とした場合には一部のクラウド型RPAとiPaaSはすでに大きな違いはないと言えます。API連携・システム間連携も含めた「自動化できる範囲の広さ」という視点で比較すると、場合によってはiPaaSよりもRPAの方が適用範囲が広く自由度が大きいという場合もあるでしょう。
最適な選択をするために信頼できる相談先を探しましょう
利用者のニーズが高度化・複雑化してきているこの流れは今後も強化され加速していきます。利用者にとってはAPI、RPA、iPaaSなど関連技術やトレンドの正しい理解と正確な判断が求められる中、働き方改革や生産性向上は待ったなしという大変な状況です。
選択肢の多様化・高度化という流れは健全な業界の発展であり自然なものですから、最適な選択をするためには慎重かつ十分な検討が必要です。
「ノンプログラミングで簡単便利」といったメリットだけを過度に訴えるようなベンダーや製品に安易に飛びつくのではなく、APIやiPaaSも含めた選択肢の中から自社のニーズにあった最適解を共に考えてくれるようなベンダーやツールを見極め、ともに新しい働き方・自分らしい生き方を実現できる「パートナー選び」を成功させたいですね。
クラウド型RPAなら「AUTORO」
AUTOROの製品紹介資料を無料でダウンロードいただけます。
製品の特徴や導入のメリット、ご活用事例などをご紹介しています。
