🦄

UiPathは使いよう

2021/09/12に公開

RPA

はじめに

この記事ではUiPath経験およそ2年ほどのエンジニアが
個人の経験を元にUiPathってこういう風に使うと良いよね悪いよねを語る記事です。
必ずしもこれが絶対などと言うつもりもありませんし
あなたに取ってのベストプラクティスを提供するものではありません。

なんでこの記事を書こうと思ったか

UiPath絡みは成功事例や質問などは多いものの
より良い作り方に関する考察やノウハウが共有されていないように感じており
個人的にはもっと、シナリオの作り方に関する話や考察があっても良いのではと考えています。

そんなこんなでこの記事を書くことに至りました。

環境

異なる通信環境下で作成+実行用Attendedライセンスが 2つ
実行用Attendedライセンスが1つ

ともに2019年度版のUiPathを利用しています。
職場にあるということありバージョンは思い出せませんが
判明しましたら記載させていただきます。

ちなみに、リモートサーバで実行するタイプのRPAではなく
特定の端末でRPAを実行しています。

ぶっちゃけどうなの

かなり便利な製品であるがゆえになんでもできそうなシロモノですが
暴れ馬なところは結構ある。

また、できることが多い反面、制約に縛られることもしばしばある。

具体的には社内の情報システムを利用するときに技術的には可能でも
現場のルールやセキュリティの観点から不可能なことになる。

シナリオ構築のベストプラクティス(個人的に)

必ずしもこれが正しいということではありませんが
実際に使ってみて思うことを書いていきます。

良いシナリオの作り方

シナリオの階層を深くしない

アクティビティの中にアクティビティを入れてさらにその下にアクティビティを入れるといったことを
やってしまうと運用保守の際に流れが読みにくくなる。
だいたいのシナリオは忘れたことにバージョンアップする必要が出てくるので
忘れた頃にその複雑なシナリオを修正することになる。

そうすると
構造が複雑ゆえに改修ミスが増えてくる
=>運用保守に時間がかかり対応に追われる。
=>次のシナリオ構築に使える時間が少なくなる。

「複雑なシナリオを作ることで技術的な負債を背負わなければならなくなる」ということは
すなわち、シナリオ構築に利用できる時間を浪費することに繋がる。

こうならないようによく使う機能や共有で使う機能、構造がややこしくなるモノに関しては
後述のInvoke WorkFlowとライブラリ の利用が必要です。

※作り方によってはInvoke WorkFlowとライブラリも負債になりうるかも。

Invoke WorkFlowとライブラリを使い分ける

UiPathにはワークフローを別のプロセス(ファイル)に作成してそれを呼び出す機能があります。
これをinvoke WorkFlowと呼びます。

また、自分だけのアクティビティを作る為の仕組みがあります。
この仕組みをライブラリと呼びます。

それぞれ、やっていることは一見して変わらないように見えますが
Invoke Work Flow はワークフロー(ファイルやプロセス)を呼び出すモノに対して
ライブラリはワークフローをアクティビティという単位で呼び出します。

ここで個人的に気を付けておきたいこととしては
ワークフローはある定型化された一連の処理を定義しているモノのことであり
単一の処理には向いていません。

ここでは具体的に日付の文字列を処理することを例に考えてみましょう。

日付からスラッシュを削除して8桁の文字列を取得する場合があり
それをシナリオ内で複数回使うことを想定します。
※日付文字列変換して変数に保存しておき、使いまわすという作戦が取れない場合

このとき使うのはInvokeWorkFlowでしょうか。それともライブラリでしょうか。
結論から申し上げますとこのパターンではライブラリを用いるのが正だと考えています。

というのも
日付文字列を特定の文字列に処理するというのはワークフローではなく
単一の機能になりえます。
これがもし、日付文字列の変換プラスアルファで何かの処理を行い
それをシナリオ内からワークフローとして呼び出す場合は
Invoke WorkFlowになるかと考えています。

すなわち、2つ以上のこと、そのワークフローが一つのシナリオになりえるのであれば
Invoke WorkFlowを利用する。
逆に、単一の処理しかしていないワークフローでシナリオになりえないなら
ライブラリとして作成すべきである。

また、Invoke WorkFlowでもライブラリでも同じことが言えますが
シナリオ同士の結合度は下げておかないと1度の修正でどれくらいの範囲に影響が出るかわかりません。

具体的には業務A,B,Cとあったとき
業務A、業務B、業務Cが同じInvoke WorkFlowやライブラリを使うということは避けなければいけません。
ここで仮にABCそれぞれが同じワークフローやアクティビティを共有してしまった場合は
技術的な負債を背負うことになるでしょう。

メソッドを利用する

次に大事にしておきたいこととしてはメソッドを利用することです。
メソッドを利用することでアクティビティの削減ができます。

例えば、条件分岐に利用するConditionでメソッドを利用すると
アクティビティの削減が期待できます。

具体的にはファイルの有無を確認、フォルダの有無を確認するというアクティビティがありますが
これらはそれぞれ、FileメソッドやDirectoryメソッドで利用できるので
条件分岐と併用することでアクティビティを削減できます。

ただし、あんまりにも同じ記述が多くなるようであれば
ライブラリ化することをオススメします。

テーブルデータと認識が可能なモノはデータテーブルを用いる

これはWeb上のテーブルタグもそうなんですが、CSVもテーブルデータして認識できます。
そういうことはおそらく、UiPathを利用したことのある人は理解できていることでしょう。

そういうことではなく
ExcelなどにCSVを貼り付けてそれをUiPathに読み込むといったことをしていないでしょうか。
どうしてもそうでなければならない理由があるのであればそれも良いかと思います。
ましてや、秘伝のタレみたいなマクロが組まれていてそれを使わないと
業務を再現できないということであれば、致し方ないと思います。
※ただ、そういうモノに関しては業務を整理する必要があると思いますので
将来的なことを考えてもシナリオ構築の前に業務を整理することをオススメします。

話が逸れましたが、データテーブルオブジェクトとしてCSVを落としこむことができると
UiPathでデータテーブルのメソッドや独自のアクティビティを活用できます。

具体的にはFor Each Row等の繰り返し系のアクティビティを利用することができるようになるので
できることの幅は広まります。

project.jsonを保存しておく

project.jsonは利用環境がアップグレードされた際に発生する不具合やアクティビティの依存関係をチェックすることができます。
また、実行用のUiPathはパッケージのインストールができない為
シナリオの構成を管理していない状態つまりは、XAMLファイルのみの場合は構成をうまく読み取れない場合があります。

加えて、project.jsonは
そのパッケージのバージョン番号やメインのアクティビティファイル名などを管理している為
シナリオのと同時にproject.jsonを読み込まないと作成環境と同じ環境を実現できない可能性があります。

ちなみにアクティビティタイプはこのproject.jsonが管理している為
削除してしまった場合は同じ階層にあるXAMLファイル(ワークフロー)がプロセスなのかライブラリなのかわかりません。

※アクティビティタイプ：プロセスなのかライブラリなのかを表すプロパティ

まとめ

今回は数年間使ってみてUiPathをよりよく付き合っていくにはどうすれば良いかについて
検討してみました。

いろいろ使ってみてこれは一番やってはいけないことなんだなと思ったことは
project.jsonを丁寧に扱わなかったことです。

「どうせUiPath用のXAMLファイルをクリックすればできるんでしょ」と思っていましたが
これが非常にまずい考えで
例えば、これをライブラリに対して行うとライブラリがプロセス用のXAMLファイルとして認識されてしまう為
ひとつのプロセスとして認識されます。すなわち、ライブラリが壊れる！

導入の成功事例なんかよりこういう細かい仕様などについて議論する場が重要だと感じています。
というのも導入して終わりではなく導入してからスタートなんです。
これはどんな製品に対してもそうなんです。

忘れがちですけど導入したらヨシッじゃないんです。

大事なことなので2回言います。
「導入したらヨシッじゃないんです。」

利用するにあたって正しい戦略に練り、どのようにしたらより良い運用になるのかまで
考えることが製品導入の仕事なんです。

少し、叫びみたいになりましたが、今回は以上です。