RPAを用いた業務自動化において、処理にどのくらい時間がかかるかというのはとても重要な点です。 特に、手順が多く処理に時間がかかる場合、「もっと早く処理が終わるといいけど、どのようにロボットを変えたら良いかわからない」ということも多いのではないでしょうか？ このBlogでも以前UiPathを高速化するための工夫を紹介しました。 その中でも特に重要なのが、「無駄な処理を行っていないか、手順を見直す」というポイントでした。 今回はさらに一歩踏み込んで、「無駄になり得る処理を効果的に減らす方法」、つまり状況によって必要だったり必要でなかったりする処理を扱うための方法を考えてみます。 UiPathの画面を例として示していますが、フローチャートの構造そのものを扱うのでRPA全般に共通する話でもあります。
ループでは必要に応じてbreakやcontinueを使う
Excelから読み込んだデータの処理やWebからデータを取り込む場合など、ロボットで繰り返しの処理を行うことはよくあると思います。 しかしときにはループを最後まで回す必要がなかったり、特定の繰り返し処理を飛ばしたかったりする場合があります。 そのようなときに使うのがBreak（繰り返しをブレーク）アクティビティや Continue（繰り返しをコンティニュー）アクティビティです。 いずれもFor Each（繰り返し（コレクションの各要素））アクティビティや For Each Row（繰り返し（各行））アクティビティ内で使うことのできるアクティビティです。
Breakアクティビティはループから抜けるために使います。 例えば「1000個のデータから特定の条件を満たすデータを1つ見つける」というフローを考えます。 このフローで300個目に条件を満たすデータを見つけたので残りの700個のデータは見る必要がないという場合、 データを見つけた時点でループを抜けるようにフローを組んでおけば、残りのデータを調べずに済みます。
条件を満たした時点でBreak（繰り返しをブレーク）アクティビティが実行され、ループ処理は終了するContinueアクティビティはループ内の処理を飛ばしたいときに使います。 例えば「1000個のデータを処理したいが、特定の条件に当てはまるデータは無視したい」というフローを考えます。 この場合、条件によってContinueが実行されるようにフローを組んでおけば、必要なときのみ処理が実行されます。
Continue（繰り返しをコンティニュー）アクティビティが実行されたときは、それ以降の処理はスキップされるただし、UiPathの場合このBreakアクティビティとContinueアクティビティが使えるのは、For EachアクティビティとFor Each Rowアクティビティ内のみです。 そのため、While（繰り返し（前判定））アクティビティや Do While（繰り返し（後判定））アクティビティで同様の動作をさせたい場合、 あえてループ条件から外れる設定をすることでBreakの代わりにしたり、 処理をする場合としない場合に条件分岐することでContinueの代わりにしたりする工夫が必要になります。
複数の条件による分岐の構造を工夫する
「条件Aと条件Bが両方成り立つときに処理Cをし、それ以外の場合処理Dをする」という場合を考えます。 例えばある商品について「『商品ページから価格等の情報を取得できた』かつ『商品リスト（Excelファイル）に情報が掲載されていた』ときに、 『情報を比較してレポートを出力する』それ以外の場合は『比較ができない旨を出力する』」という場合です。 この場合、次の図のように条件Aを判断するための処理と条件Bを判断するための処理をし （それぞれ結果はboolean型の変数result_A、result_Bとして出力されるものとします）、 「result_A And result_B」の真偽で処理Cと処理Dに振り分ければ良さそうです。
しかし、このフローチャートはもっと効率が良い構造に変更することができます。 よく考えると、ここでは「条件Aと条件Bが両方成り立つ」かどうかを知りたいだけなので、 条件Aが成り立たないとわかった時点で条件Bが成り立つかどうかは調べる必要はありません。 そのため条件Aが成り立たない時点で処理Dに割り振ることができ、フローチャートは次の図のように改善できます。
もとのフローでは条件Aと条件Bを調べるための処理が両方とも毎回呼び出されていましたが、 改善したフローチャートでは、条件Bを調べるための処理は必要なときのみ呼び出されるので無駄を省略できることがわかります。
また、「条件Aと条件Bのどちらか一方でも成り立つときに処理Cをし、それ以外の場合処理Dをする」という場合、 つまり「result_A Or result_B」の真偽で処理Cと処理Dに振り分けたいときも同じように考えることができます。 この場合、result_Aの値がTrueだとわかった時点でresult_Bの真偽は調べる必要がないため、次のようなフローチャートになります。
今回は、条件によっては無駄になりうるフローを減らすという観点でフローチャートの構造を改善する方法を紹介しました。 ロボットの改善点を考えるときに、ループや条件分岐が多くあると複雑に感じるかもしれませんが、 その分無駄な処理を減らすチャンスが多いとも言えます。 条件ごとにどこまでの処理が必要なのか考えて、適切にフローを組んでいきたいですね。