なぜRPAには移行ツールが存在しないのか？
RPAツールはいろいろ出ているけれど、Officeソフトやデータベース等で見られるような、競合製品からの移行ツールのようなものは存在していません。これがなぜなのかについて考えてみます。(※個人的見解です)
目次
1. RPA市場が立ち上がってまだ間もなく急拡大中だから
日本でも2017年頃からRPA市場が立ち上がってきて、まだ3年くらいしかたっていません。2019年度の市場成長率も、調査会社によって値が多少異なるものの、150%以上の成長率で急拡大しており、新規参入もタケノコのように出てきているものの、それぞれ新規ニーズをまだ拾えている状況で、他社からの移行を真剣に考えなくてもやっていけている段階だと思われます。
今後、市場成長率が鈍化して、強いプレイヤーが決まってくれば、お互いの移行を行うツールをそれぞれが開発するかもしれません。
2. RPAツールによって作りが全く異なるから
RPAツールは、触ってみるとわかりますがツールによって全く作りが異なっています。
たとえばWinActorはシナリオの背後にはVBScriptのコードが対応付けられていて、VBScriptが動作するようになっています。UI要素の捕捉は画像認識で行うようになっているため、認識精度はあまりよくなく、また、ノードの間にうまくウェイトを入れて時間調整をする必要があります。プログラム本体はJavaで作られていましたが、バージョン7からは.NET Frameworkに移行しています。
一方、UiPathは.NET FrameworkのWindows Workflow Foundationをベースに構築されており、VB.NETやC#に親和性のある環境です。UI要素の捕捉はUI Automationと呼ばれるOSのアクセシビリティAPIを使っており、アクセシビリティ仕様に対応していない一部のアプリケーションを除いて高い精度でUIを認識します。ノードに当たる「アクティビティ」間のウェイトは、シナリオ自体に埋め込まれており普段は意識しなくてよいようになっています。シナリオに当たる「プロセス」はXAMLと呼ばれるXMLで記載されます。
Automation Anywhereは独自実装のようですが、UI要素の捕捉はUiPathと同様UI AutomationやMSAAと呼ばれるOSのアクセシビリティAPIで行っており、高い精度を誇ります。ノードに当たる「アクション」間のウェイトは、アクション自体に埋め込まれており普段は意識しなくてよいようになっています。シナリオに当たる「ボット」ファイルは、XMLがZIPファイルで圧縮された形式になっています。バージョン11までは.NET Frameworkベースのプログラムでしたが、A2019からはJavaベースに移行しています。
これらの間の移行ツールを作るとしたら、単純にファイルフォーマットを変換する以上に、いろいろな調整が入ることが想像され、単純にフォーマットを変えただけのものがきちんと動く気はしませんね...
3. そもそも移行が必要なほど複雑でないから
本番稼働している環境で使われるボットは、時には100以上、500にもわたるステップになることがあるようですが、そもそも現場ユーザーが簡易的に作るのがRPAなので、このような場合はボットを分ける必要があり、また、このステップ数になると現場ユーザーでは手が負えなくなってしまいます。つまり、現場ユーザーが使うステップ数はそんなに多くない、ステップ数50未満に抑えられるような場合を想定すべき、ということになります。
加えて、RPAは数日の実装で稼働開始できることが特徴でもあり、作り直しをしてもあまり手間がかかるものではないのが、通常のSIと異なるところです。
そのため、わざわざ移行ツールで移行をしないといけないという概念そのものが合っていないのかもしれません。
移行ツールについては、筆者が知る限り同じコンセプトで作られているAutomation Anywhere バージョン11とA2019の間でメーカーが移行ツールを実装しているのみです。RPAツールの乗り換え需要もこの1年間はだんだん増えてきているため、今後は状況が変わってくるかもしれませんが、いまのところRPAツールを乗り換える場合は手作業でロボットを作り直すことになります。
