物事なんでも、比較するからこそ、その本質が見えてくるものです。

日本の良さ・悪さに関しても、外国で暮らしてみて、初めて見えてくるものが多いというのと同じでしょうか。

さて、最近、WinActorを運用中の法人様から、Power Automate Desktopへの移行をご依頼頂き、その作業を行っています。

移行といっても、作成済みのシナリオをそのまま持っていける訳でもなく、ゼロから作り直しになるのですが。

私は元々、WinActorのRPAエンジニアとして働き、毎日数時間もWinActorを相手にしてきたのですが、Power Automate Desktopで同じ動きを再現するとなった時、改めてWinActorの凄さを再確認することにもなりました。

もちろん、Power Automate Desktopは、急速に発展している途中なので、ここに書いたことも1年後や2年後には昔話として語られるようになるかもしれません。

 

WinActorのロボットをPower Automate Desktopで再現してみて

今回対象のロボットは、大小合わせると両手で数えれないほどの数があり、かなりの時間を費やしています。

その中で感じたことを挙げてみたいと思います。

 

1.WinActorは、パーツ(ライブラリ)が充実している

Power Automate Desktopでは、そのパーツのことを、「アクション」と呼びます。

WinActorを利用していた当時は、その数の多さに辟易としていましたが、いざPower Automate Desktopを使い始めると、今度は少なさを感じるのです(苦笑)

WinActorで簡単に出来ていたことが、Power Automate Desktopでは工夫しないと出来ないことも出てきます。

特にエクセル関係のパーツにおいて、それを感じますね。

WinActorでは、マクロと同じ動きを1パーツで再現できることが多く、それがPower Automate Desktopでは、数アクションを組み合わせてやっと…という状況があります。

 

2.WinActorは、「変数」に漢字が使える

一般的なプログラミングでは、変数に漢字が使えるケースは少ないです。

しかし、純国産を謳うWinActorでは、使えるのです。

WinActorのRPAエンジニアだった当時は、それが素人っぽく感じて、あんまり良い印象を持っていませんでした。

それが、今回、引っ越し作業を行ってみると、「おぉ、変数に漢字が使えるって素晴らしいことだったんだ!」と感じています。

やっぱり、日本人には漢字の方が、一瞬で意味が取れるのです。

アルファベットだと、どうしても長くなりがちで、特にノンプログラマーには敷居が高くなりがちですね。

 

3.WinActorは、フローチャート型での表示

WinActorは、設計画面でブロックと線を繋げてフローを作成していく表示形式、通称:フローチャート型になっています。

一方、Power Automate Desktopは、スクリプト型と言われる文字主体の表示形式です。

好みと慣れの問題が大きいのは確かですが、「どちらが見やすいか?」と言われれば、明らかにフローチャート型でしょう。

自分が最初から作っているロボットであれば、特段不満はありませんが、もし他人が作ったロボットを読み解かなくてはいけないとなると、確かにフローチャート型の方が優しい気がします。

ただ、WinActorの場合、フローチャートにパーツを加えていく作業において、かなりもっさりとしていたり、ドラッグ&ドロップが微妙に設定しづらい箇所があるのも付け加えておきます。

 

4.WinActorは、スピードが遅い

Power Automate Desktopで、同じ内容のロボットを作ってみました。

実際に使うパーツは、WinActorと全く同じではありません。

むしろ、Power Automate Desktopの方が、トータルのパーツは多くなりがちです。

WinActorでは、150パーツくらいで完成しているものが、Power Automate Desktopでは、200パーツ近くまで増えています。

しかし、両者を比較した場合、Power Automate Desktopの方が、ロボットのスピードが速いと感じます。

デザイナー画面を開いた状態でロボットを走らせた場合には、さほど速いとは感じませんでしたが、コンソール画面から走らせると、滅茶苦茶速いと感じるケースがあります。

そういえば、昔も「WinActorは、UiPathに比べて遅い!」といった不満を聞いたこともあります。

そういう意味では、やっぱりWinActorは遅いのかもしれません。

 

とはいっても、そもそもRPAツールにスピードを要求するのは、的外れな気もします。

もちろん、人間が手作業で行うのに比べれば、3倍以上の速さで処理をしますが、純粋なプログラミングに比べると遅いことがしばしばです。

ですので、もしRPA利用において速度を要求される場合、Excel作業においてはマクロを使ったり、メモ帳の編集ではコマンドプロンプトを利用したりといった工夫が必要になってきます。

ちなみに、実際の現場では、マクロで動いていたものを、RPAに置き換えているというところも少なくありません。

理由としては、大昔に作られたそのマクロがブラックボックスになっており、誰も修繕できないからだそうです。

であれば、多少スピードが落ちても、簡単に修正の利くRPAにしておこうという考えなのですね。

 

5.RPAツールの代替は可能

個々のパーツ単位を見ると、そのRPAツールにしか備わっていないものはあります。

それは、WinActorやUiPathを比較した場合でも同じでしょう。

しかし、結果として「同じ動きを再現すればいい」という話であれば、なんとかなるものですね。

その過程において、必然的にExcel操作やWindowsの操作に詳しくなります(苦笑)

今迄気にもしなかった操作にショートカットキーがあったり、そんな関数があったのか!と驚くこともしばしば。

 

6.ロボット制作者の性格が出る

人が作ったロボットというのは、その人の性格が出ますね。

麻雀の打ち方みたいなものでしょうか!?

冗談はさておき、システム開発会社などで正式に習った場合なら、均一化するのでしょうが、やはり独学で作った場合には、個人が一生懸命考えて作った跡が見えます。

今回は素人の方が作ったとは言っても、幸いかなり几帳面な方が作っており、メモや変数名の付け方にも配慮を感じました。

いやむしろ、セミナーに通ったとはいっても、「独学でよくここまで作ったものだ!どれほどの時間を費やして作ったのだろう!?」と感心すらしています。

RPAエンジニアとして開発チームに入って、ロボットの効率的な作り方を教わる前の自分では、間違いなくそのレベルのシナリオを作れなかったでしょう。

 

7.その他

当初思っていたよりも、引っ越し作業は大変だなと(苦笑)

数が多い場合、業務内容の把握に時間と手間が掛かりますね。

最初は、単純にWinActorの中身を見ながら、ただPower Automate Desktopに落とし込んでいけばいいと気楽に考えていました。

しかし、上記の繰り返しになりますが、WinActorでは1パーツで簡単に出来たことが、Power Automate Desktopでは出来ないケースが少なからずあり、その実現方法に頭と時間を使います。

また、社内でもRPA化により半ばブラックボックス化している作業もあったりと、手作業時の正確な操作方法が分からないケースもあります。

シナリオを読み解いてみるのですが、「なぜこんな操作をしているのだろう?」ということが、少なからず出てくるのです。

スタッフの方に確認してみると、実際に必要ない動きだったということもあったりします。

 

とまあ、苦労が多かったですが、Power Automate Desktopの操作方法において気づくことも多く、スキルが数段レベルアップした気がします。

やはり、実際にロボットを作ってみないと、分からないことが分からない状態ですからね。

今回学んだことは、提供中のオンラインレッスンにも反映させていきたいと思いますので、お楽しみに!