WinActorシナリオ作成あるある

# この記事は……
この記事は「RPA Advent Calendar 2021 - Qiita」の **17日目** の記事です。

https://qiita.com/advent-calendar/2021/rpa

[◀　**16日目** の記事は、えのさんです。](https://note.com/nogyu21/n/n6bb351a87d4a "【BizRobo!】我流！仕様書作成ロボ")
[▶　**18日目** の記事は、さおさんです。](https://note.com/master_mbaandit/n/n327ccdf8ef91 "RPAツールって何個も学ぶのがいい？")

また、「RPA Community Advent Calendar 2021」の **17日目** の記事でもあります。

https://adventar.org/calendars/6396

[◀　**16日目** の記事は、たな様です。](https://tana-techlog.net/?p=91 "組織アカウントを利用した場合のPower Automate for desktopで作成したデスクトップフローの落とし穴")
[▶　**18日目** の記事は、さおさんです。](https://note.com/master_mbaandit/n/n6171ae58685d?fbclid=IwAR3Nlj-3s3R-aEeOUoWLHVp1xtZjurxKZU1hMA_aPwdCe0JGvbXyzdzJHe0 "2021年のLT活動について")



# はじめに
私は仕事柄、代行してWinActorのシナリオを修正することが多いです。
今回は、お客様のシナリオ修正をしているときに出会った、

:::note warn
　<strong>ここ修正すれば、さらにいいシナリオになるのになあ……</strong>　:desktop: :thinking: 
:::

と突っ込みたくなった組み方について共有させていただければと思います。

# そんな組み方で大丈夫か？
しばしばシナリオ作成している人は、自分の成果物を**定期的に点検**しています。
定期的に見直すことで、**シナリオの品質・可読性・保守性が高くなり**、その後の**シナリオ作成レベルも上がる**からです。
またRPA担当者が交代したとしても、管理するストレスも少なく、軽微な修正が発生してもすぐ対応することが可能です。

しかし中には、様々なご事情で別の担当者に依頼して作ってもらったシナリオも存在します。
納品されたときには正常に動いていたシナリオも、時とともにエラーが頻発したり、最終的に動かなくなったり……。
ご自分が積極的に関わったシナリオでないと、修正したくてもなかなか手を出しづらいことと思います。

私の所属している会社では、止まってしまったシナリオの修正を委託されることがあります。
シナリオを見直していくと、中にはかなり**クセの強い**シナリオに出会うことがあります。
以下に**私の心のツッコミ**とその**クセ強シナリオの詳細と改善点**をご紹介いたします。

どんな組み方がされたクセ強シナリオかを想像しながら気軽にお楽しみください。

## ダイレクトはつらいんじゃ……
<dl>
<dt>組み方</dt>
<dd>ノードやライブラリの<strong>プロパティに直接パスや設定値を書き込んでいる。</strong></dd>
<br>
<dt>課題</dt>
<dd>シナリオの移動やシステムの入れ替えが発生すると、<strong>ひとつずつライブラリを開いて手修正する必要がある。</strong></dd>
<br>
<dt>改善点</dt>
<dd><strong>変数一覧</strong>の活用です。<br>
変数を作成して［<strong><font color="red">初期値</font></strong>］の欄にあらかじめ入力いただくと、一覧なので可読性もよく、変更箇所がひと目で特定できるのでおススメです。<br>
また、わざわざWinActorを開くのが面倒という方は、外部変数を保存するファイルを作成しておき、
起動毎に読み取って変数に設定するという手もあります。</dd>
</dl>

## マトリョーシカかよ！
<dl>
<dt>組み方</dt>
<dd>ノード<strong>［分岐］の入れ子が多すぎる。</strong></dd>
<br>
<dt>課題</dt>
<dd>入れ子状態が何重にもあると、フローの横幅が広がってしまうので可読性が悪くなり、修正箇所特定の難易度も上がってきます。</dd>
<br>
<dt>改善点</dt>
<dd>本当に入れ子状態にする<strong>必要があるかどうか見直してみる</strong>ことです。処理によっては、入れ子状態にしなくても意外と処理出来てしまう場合が多かったりします。<br>
処理内容によっては、<strong>ノード［多分岐］</strong>を活用するのも一つの手です。<br>
参考までにですが、「<strong><font color="red">入れ子にするなら３分岐まで</font></strong>」がちょうどいいようです。</dd>
</dl>

## わしゃ、ノミか？！
<dl>
<dt>組み方</dt>
<dd>意味のない<strong>サブルーチンを多用</strong>している。<br>
フローチャートを開くと、［メイン］タブ内に、作ったサブルーチンがすべて入っている。<br>
また、サブルーチンの中にさらにサブルーチン呼び出しが配置された入れ子状態。</dd>
<br>
<dt>課題</dt>
<dd>処理フローを追うために［サブルーチンジャンプ］を実行するので、視点の移動が頻繁に発生する。<br>
視点の移動が多すぎると、処理の流れがつかみづらくなり修正作業に時間がかかってしまう。</dd>
<br>
<dt>改善点</dt>
<dd>ここはひと言。「<strong>そこは<font color="red">シンプルであれ</font>！！！</strong>」<br>
サブルーチンやサブシナリオは、何度も繰り返す処理をひとまとめに整理整頓でき、呼び出し用のノードを１つ配置するだけで済むようになる素晴らしい機能です。<br>
しかし何事にも<strong>用法・用量を守ることが肝要</strong>で、多用しすぎると可読性が悪くなり、誰もシナリオを保守したがらなくなってしまいます。<br>
また、こちらも分岐処理と一緒で、入れ子状態にするのもなるべく控えた方がいいと思います。</dd>
</dl>

## いや、フリーダム過ぎ！
<dl>
<dt>組み方</dt>
<dd>作成担当者に<strong>すべてを委ねすぎたことが原因</strong>で自由に作成されてしまっている。</dd>
<br>
<dt>課題</dt>
<dd>自由に作られ過ぎてしまうと、あとで保守する担当者は以下のような困った状況になる。
<ul>
<li>作成するシナリオに規則性がないので、流れを把握するのに時間がかかる</li>
<li>似たようなフォルダ構成やフォルダ名が存在するので、設定を間違えやすくなる</li>
<li>変数名に似たような名前が複数あるので、設定し間違える可能性が出る</li>
</ul>
</dd>
<dt>改善点</dt>
<dd>依頼する側も把握できるような<strong><font color="red">命名規則</font>や<font color="red">作成ルール</font></strong>を設けてから依頼する。</dd>
</dl>

## それ規則に縛られて逆に面倒くさくなってるヤツ！
<dl>
<dt>組み方</dt>
<dd>作成担当者が<strong>ルールを守り過ぎたことが原因</strong>でシナリオを整理整頓できていない。</dd>
<br>
<dt>課題</dt>
<dd>私が出会ったシナリオは「１タブ１サブルーチン」を順守したもので、確かに処理の流れは見やすい状態でした。<br>
しかしサブルーチンが増えると、タブ間の移動が面倒になることと、似たような処理内容があっても気付けていない状態でした。もしくは気付いていても、ルールに外れないよう、あえて分けていたのかもしれません。<br>
あまり処理が重複していると、ノード数の節約にならず、処理速度が遅くなってしまいます。そうなるとサブルーチンを使用している意味合いがなくなってしまいます。</dd>
<br>
<dt>改善点</dt>
<dd>いったん作りきった後に、<strong><font color="red">ルールにこだわりすぎず</font>シナリオ全体を見直してみる</strong>といいかもしれません。<br>
上記課題の場合は、似たようなシナリオを並べてみて、さらに同じ処理をまとめられる箇所を探してブラッシュアップすると良かったと思います。</dd>
</dl>

## そこは、まだまだ頑張れるよ！
<dl>
<dt>組み方</dt>
<dd>このやり方しか出来ないと思い込んで、<strong>不安定な作りのまま運用でカバー</strong>している。</dd>
<br>
<dt>課題</dt>
<dd>私が出会ったシナリオは、画像マッチングが多用されたシナリオでした。<br>
確かに画像マッチングも必要でしたが、部分部分でショートカットキーが使用できたりオブジェクト指定の出来る箇所もあったのに、その個所も画像マッチングを採用している状態でした。</dd>
<br>
<dt>改善点</dt>
<dd>最初は<strong>不安定な作りでもいいので作り切った上で、<font color="red">より安定するような作り方を研究</font></strong>するといいと思います。<br>
上記課題の場合は、ショートカットキーが使えるか、オブジェクト指定ができるか、はたまた別の操作方法がないか……いろいろ探ったり、どうしても画像マッチングで止まってしまう箇所は処理を飛ばして次の処理に移る、というシナリオを作りました。<br>
作り変えたところ、止まる回数もずいぶん減り、たまに出るエラーのデータは手入力でカバーで、グッと止まる回数と処理にかかる時間が減りました。</dd>
</dl>

# 最後に
今回挙げた内容はごく一部です。
もし心当たりのあるシナリオの組み方をされているようでしたら、一度見直しをされることをおススメいたします。
修正される際は、バックアップを取っておくことをお忘れなく。

また興味深いシナリオがありましたらご紹介させていただきます！