はじめに
RPAとiPaaSって似ているところありますよね。
どちらも、一般的なシステムと違って独立した業務機能を提供するものではなく、システムが乱立していることによって発生している無駄な作業を削減することが主な期待となるツールです。
Workato（iPaaS）をお客様へ紹介する際に、「RPAと何が違うの？」と聞かれることがよくあるのでこの場を借りて説明したいと思います。
RPAとiPaaSの機能比較
違いを説明、ということでこういうときは機能比較なので、ぱっと思いつく項目で比べてみます。
| iPaaS | RPA | |
|---|---|---|
| API連携 | ○ | △ （製品による） |
| DBアクセス | △ （製品による） |
△ （製品による） |
| UI操作 （Webブラウザ、オンプレシステム等） |
✕ | ○ |
| ローカルPC環境操作 | △ （ファイル読み書き等限定的） |
○ |
| 対話型操作 | △ （製品による。Teams、Slack等を利用等） |
△ （製品による。製品機能として提供等） |
| 処理のトリガー | イベント起動（レコード追加、メール受信等）、時刻起動等 | 手動起動、時刻起動が中心 |
製品によると言ってしまえば身もふたもないですが、「iPaaS」「RPA」とひとくくりに言っても、いろんなアプローチの製品があり、機能を絞って扱いやすさをアピールする製品もあれば、なんでもござれと多機能路線に進む製品もあります。
RPA、特にUiPathのような多機能な製品の場合、iPaaSでやれる機能も概ね満たしていることがあります。
機能追加に意欲的な製品はそのツールの範疇を超えて総合的なツールへと進化しています。
世の常として人気が出ることで追加投資が可能となったツールは、他のツールの良いところを取り入れて機能が充実していきます。
「このツールでしかできない」という差別化要素は（もともとあったとしても）徐々に吸収されていくことになります。
されど餅は餅屋
そういえばですが、かつてRPAが出始めていた頃も、「Seleniumと何が違うの？」「それってVBAでもできるよね？」という問いを受けることがありました。
SeleniumはWebアプリをテストするためのツールで、ブラウザ操作を自動化することができます。
また、VBAについては一般的にはExcelやAccess内の自動化に使われていますが、やろうと思えばメールを送ったりAPIを使ったりといったことができるので、腕に覚えがある人はVBAに色んなことをさせていたりします。
しょせんはプログラムの世界の話であるので、ゴリゴリやろうと思えばやれることは広がりますし、自分の手になじんだツールにどうしても愛着がわきやすくなります。
ただし、それが最終的な最適解かというと議論の余地はあります。
たとえばVBAについて業務の現場の声としてよく言われるのが、「担当者が異動（退職）して誰もメンテできなくなった」。
コードを書く世界だと、どうしても陥りがちなパターンです。
プログラミングをやったことのない人が"Hello, world"から覚えて前任者に追いつくにはいくつもハードルを越えていく必要があります。
では、ローコードツールであるRPAやiPaaSの選択はどうなるか。
RPAは従来のプログラミングに比べたら学習が容易ですし、なんでもできるという意味でつぶしの効くツールです。
全部RPAにやらせればいいんじゃないかと思う人もいるかもしれません。
そうはいっても、RPAはAPIを使うということに特化したツールではないので、ことAPIを使って自動化するというシーンではiPaaSで開発したほうがより簡単に結果を得られます。
なにより、RPAはやれることが多すぎたり、ローカルPCを主戦場とする性格上、ブラウザの画面遷移遅延や画面デザイン変更など、いろんなことに気を配る必要があり、基本的な機能であればすぐに習得できる一方であれもこれもとやりたいことが増えてくると広範に習得コストがかかります。
うちのメンバーは専門家としてRPAエンジニアをやってますが、こういった蓄積が必要な部分に価値があるからこそかと思います。
全体最適の発想
また、RPAの活用が進んでいる企業では、ひとつのRPAシナリオのなかにいろんなことを詰め込んでしまうということが起きやすくなったりします。
オンプレシステムでの画面遷移を通じてデータを引っ張ってきて、APIを使ってクラウドシステムへ登録して、処理結果をExcelへ書き込んで、といった操作をRPAで実装すると、ローカルPCでエラーが発生するポイントが何ヶ所もあり、最後まで無事に正常終了する確率が大きく下がってしまいます。
99%の確率で正常終了する処理が5つ直列に並んでいると、全体が最後まで行きつく確率は95%（= 0.99 × 0.99 × 0.99 × 0.99 × 0.99）にまで落ちてしまいます。
せっかくRPAでAPIを活用して手堅いロジックを組んでも、安定性に欠ける画面操作と同居することで本領を発揮できないことが起きえます。
iPaaSにはAPIが活用できるシーンに限定して自動化を担わせて高い稼働率を確保し、RPAには安定性に課題は残りつつもRPAが強みを持つUI操作・ローカル環境の操作の自動化を担わせる。
そのような役割分担によってエラー発生時にもリカバリーの切り分けがしやすい自動化の絵が描きやすくなります。
業務ユーザーから見た違い
ここまで言っておいてなんですが、業務ユーザーからしてみると結局のところ、自身の業務を自動化・効率化さえしてくれればツールの違いには興味がないというのが本音ではないでしょうか。
先日、かつてRPA提供側としてお世話になったお客様とお話しした時にも、「ツールなんてなんだっていいんですよ」という声が聞こえてきました。
決定的な違いの無い機能面を比較してどっちのツールがいいという議論を業務ユーザーにぶつけるのは開発側の独りよがりかもしれません。
それよりも、RPAとiPaaSのいいとこどりをして理想的な役割分担を模索することで、業務ユーザーにとってしっくりくる自動化環境を提供することのほうが大事だと思います。
おわりに
RPAとiPaaSの違いって何なの？って真理を求めてきた方には役に立たない記事になってしまったかもしれません。
大げさな話かもしれませんが、RPAやiPaaSといったそれ自体で完結しないツールを導入するときには、どういった世界を描きたいかという「思想」がより大事になってきます。
このツールにはこの部分を担わせて、といった考え方の軸をはっきり持って導入を進めていただければと思います。
なお、Workato(iPaaS)でどんなコンセプトが実現できるかは他のメンバーの記事でも紹介しているのでそちらもヒントにしてください。
※ 弊社の概要はこちら。