はじめに

RPAで有名なUiPathが職場に導入されました。しばらく触ってみた所感とよき使い方について書きます。

良いところ

・動作が速い
・Elementの認識率が良い
・メタデータの管理にjsonが使える
・条件式などの文法にVBやC#が使われている
・Officeとの連携が強い

悪いところ

・動作が速すぎること
・OracleForm等のElementの認識に一工夫必要なところ
・onchangeイベントを発火させるのにキーボード入力が必要なこと
・細かいアクティビティの仕様に気づかないとハマること
・文字列の変換処理に弱いこと
・過度な条件分岐を入れると複雑怪奇になること
・端末にインストールされていないと使えないこと＊
・優れた機能があるのにも関わらず使われていない

＊サーバ型ならリモート先で利用できるがリモート元では使用できない。

全体的な評価

Excel文化の会社にはとても良い薬になると思う。
どこで役に立つかわからないWindowsアプリケーションの
知識が役に立つこともあったりなかったり。。。

すっげー言いたいこと

サーバ上で処理できることを
わざわざローカルAndクライアントで
処理しようとするのは単なる無駄

なので
そこんところは製品を無理に利用せず
最適解を常に求めていきたい。

弱点

UiPath等のRPA製品は操作の対象がなければ
なんの役にも立たないこと。

惜しいところ

自分がもったいないなと思うことは
その操作の対象を作ることまで

一括で提供すれば、案件や業務の
コントロール性がめっちゃ上がるのに
ベンダー頼みでシステムを発注してしまうこと。

他、気になること

学習コストが高い。
コミュニティ版を使えば
金銭面の問題は解決できそうだけど

ActivityとかElementとかそのあたりの概念が
プログラマかつエンジニアの私にはきつかったな。

きつかったところ

主にElementは「JavaScript」などで言われている
Elementとは違うということ

アクティビティの仕様に気づかないとハマるということ

アクティビティの仕様

シナリオ作成をやっていくなかで
アクティビティをうまく活用しなければ
効率化は夢のまた夢

GetVisibleTextの仕様

表示されているテキストを取得すると聞いて
取得しようにも取得できなくてハマる。

実際には画面を最大化して
画面上に文字が表示されていないと
捉えられないという罠がある。

SetTextの仕様

SetTextはOracle Formでは機能しないこと
代わりにType Into アクティビティを使う。

プルダウンメニューのonchangeイベントが発火しない

これはイベントのメソッドを強制発火させれば
おおむねイケる感じはする。
JavaScriptのアクティビティで強制発火させるとイケる。
がしかし RPA太郎な皆さん、特に非ITな方には嫌われる書き方なので
キーボード入力で発火させる。結局は人間の動き

気づいたこと

人間的なシナリオの組み方を意識すると
結構、安定したシナリオ作成ができる。

例えば、マウスクリックはクリック対象にhoverしてから
クリックするとうまくクリックできたりする。
クリックシュミレートを活用したりするのも有効

クリックシュミレート

画面範囲外のクリック可能な要素もクリックできるように
してくれるすごいやつ

クリックがうまくいかない時はクリックシュミレートの
設定を見直したりするとうまくいく。

UiPathの根幹

dotNetFrameworkですね。
Activityが利用するライブラリ群ですが
Microsoft Docsに仕様が書いてあります。
実際にアクティビティ本体を作る人もいるみたいですね。

まとめ

これからガンガンUiPathを使って効率化してきたい。
（本業のおまけ程度に）