この記事は……
この記事は「RPA Advent Calendar 2021 - Qiita」の 17日目 の記事です。
◀ 16日目 の記事は、えのさんです。
▶ 18日目 の記事は、さおさんです。
また、「RPA Community Advent Calendar 2021」の 17日目 の記事でもあります。
◀ 16日目 の記事は、たな様です。
▶ 18日目 の記事は、さおさんです。
はじめに
私は仕事柄、代行してWinActorのシナリオを修正することが多いです。
今回は、お客様のシナリオ修正をしているときに出会った、
ここ修正すれば、さらにいいシナリオになるのになあ…… 
と突っ込みたくなった組み方について共有させていただければと思います。
そんな組み方で大丈夫か？
しばしばシナリオ作成している人は、自分の成果物を定期的に点検しています。
定期的に見直すことで、シナリオの品質・可読性・保守性が高くなり、その後のシナリオ作成レベルも上がるからです。
またRPA担当者が交代したとしても、管理するストレスも少なく、軽微な修正が発生してもすぐ対応することが可能です。
しかし中には、様々なご事情で別の担当者に依頼して作ってもらったシナリオも存在します。
納品されたときには正常に動いていたシナリオも、時とともにエラーが頻発したり、最終的に動かなくなったり……。
ご自分が積極的に関わったシナリオでないと、修正したくてもなかなか手を出しづらいことと思います。
私の所属している会社では、止まってしまったシナリオの修正を委託されることがあります。
シナリオを見直していくと、中にはかなりクセの強いシナリオに出会うことがあります。
以下に私の心のツッコミとそのクセ強シナリオの詳細と改善点をご紹介いたします。
どんな組み方がされたクセ強シナリオかを想像しながら気軽にお楽しみください。
ダイレクトはつらいんじゃ……
- 組み方
- ノードやライブラリのプロパティに直接パスや設定値を書き込んでいる。
- 課題
- シナリオの移動やシステムの入れ替えが発生すると、ひとつずつライブラリを開いて手修正する必要がある。
- 改善点
-
変数一覧の活用です。
変数を作成して［初期値］の欄にあらかじめ入力いただくと、一覧なので可読性もよく、変更箇所がひと目で特定できるのでおススメです。
また、わざわざWinActorを開くのが面倒という方は、外部変数を保存するファイルを作成しておき、 起動毎に読み取って変数に設定するという手もあります。
マトリョーシカかよ！
- 組み方
- ノード［分岐］の入れ子が多すぎる。
- 課題
- 入れ子状態が何重にもあると、フローの横幅が広がってしまうので可読性が悪くなり、修正箇所特定の難易度も上がってきます。
- 改善点
- 本当に入れ子状態にする必要があるかどうか見直してみることです。処理によっては、入れ子状態にしなくても意外と処理出来てしまう場合が多かったりします。
処理内容によっては、ノード［多分岐］を活用するのも一つの手です。
参考までにですが、「入れ子にするなら３分岐まで」がちょうどいいようです。
わしゃ、ノミか？！
- 組み方
- 意味のないサブルーチンを多用している。
フローチャートを開くと、［メイン］タブ内に、作ったサブルーチンがすべて入っている。
また、サブルーチンの中にさらにサブルーチン呼び出しが配置された入れ子状態。 - 課題
- 処理フローを追うために［サブルーチンジャンプ］を実行するので、視点の移動が頻繁に発生する。
視点の移動が多すぎると、処理の流れがつかみづらくなり修正作業に時間がかかってしまう。 - 改善点
- ここはひと言。「そこはシンプルであれ！！！」
サブルーチンやサブシナリオは、何度も繰り返す処理をひとまとめに整理整頓でき、呼び出し用のノードを１つ配置するだけで済むようになる素晴らしい機能です。
しかし何事にも用法・用量を守ることが肝要で、多用しすぎると可読性が悪くなり、誰もシナリオを保守したがらなくなってしまいます。
また、こちらも分岐処理と一緒で、入れ子状態にするのもなるべく控えた方がいいと思います。
いや、フリーダム過ぎ！
- 組み方
- 作成担当者にすべてを委ねすぎたことが原因で自由に作成されてしまっている。
- 課題
- 自由に作られ過ぎてしまうと、あとで保守する担当者は以下のような困った状況になる。
- 作成するシナリオに規則性がないので、流れを把握するのに時間がかかる
- 似たようなフォルダ構成やフォルダ名が存在するので、設定を間違えやすくなる
- 変数名に似たような名前が複数あるので、設定し間違える可能性が出る
- 改善点
- 依頼する側も把握できるような命名規則や作成ルールを設けてから依頼する。
それ規則に縛られて逆に面倒くさくなってるヤツ！
- 組み方
- 作成担当者がルールを守り過ぎたことが原因でシナリオを整理整頓できていない。
- 課題
- 私が出会ったシナリオは「１タブ１サブルーチン」を順守したもので、確かに処理の流れは見やすい状態でした。
しかしサブルーチンが増えると、タブ間の移動が面倒になることと、似たような処理内容があっても気付けていない状態でした。もしくは気付いていても、ルールに外れないよう、あえて分けていたのかもしれません。
あまり処理が重複していると、ノード数の節約にならず、処理速度が遅くなってしまいます。そうなるとサブルーチンを使用している意味合いがなくなってしまいます。 - 改善点
- いったん作りきった後に、ルールにこだわりすぎずシナリオ全体を見直してみるといいかもしれません。
上記課題の場合は、似たようなシナリオを並べてみて、さらに同じ処理をまとめられる箇所を探してブラッシュアップすると良かったと思います。
そこは、まだまだ頑張れるよ！
- 組み方
- このやり方しか出来ないと思い込んで、不安定な作りのまま運用でカバーしている。
- 課題
- 私が出会ったシナリオは、画像マッチングが多用されたシナリオでした。
確かに画像マッチングも必要でしたが、部分部分でショートカットキーが使用できたりオブジェクト指定の出来る箇所もあったのに、その個所も画像マッチングを採用している状態でした。 - 改善点
- 最初は不安定な作りでもいいので作り切った上で、より安定するような作り方を研究するといいと思います。
上記課題の場合は、ショートカットキーが使えるか、オブジェクト指定ができるか、はたまた別の操作方法がないか……いろいろ探ったり、どうしても画像マッチングで止まってしまう箇所は処理を飛ばして次の処理に移る、というシナリオを作りました。
作り変えたところ、止まる回数もずいぶん減り、たまに出るエラーのデータは手入力でカバーで、グッと止まる回数と処理にかかる時間が減りました。
最後に
今回挙げた内容はごく一部です。
もし心当たりのあるシナリオの組み方をされているようでしたら、一度見直しをされることをおススメいたします。
修正される際は、バックアップを取っておくことをお忘れなく。
また興味深いシナリオがありましたらご紹介させていただきます！