みなさまごきげんよう、永瀬です。

今回の記事は技術的な内容ではなく、Automation Anywhere でのボット作成にあたって、どのような心構えで臨めばよりストレスを感じずにすんなりと製品に馴染んでいけるかという点を記していきたいと思います。

基本的には私が Automation Anywehre v11 を使い始めたときにストレスに感じた点を題材にして、なんらかのプログラミング言語でのコーディングができる人（以下、プログラミングできる人）が Automation Anywhere でのボット作成でひっかかると思うところを、あらかじめ「AA でのボット作成とはそういうものですよ」とお話ししておくというのがゴールです（なのでほとんど字ばっかりです）。

文章中の細かい説明は Automation Anywhere v11 を念頭に置いていますが、考え方は A2019 でも同様になります。

【目次】

１．利用する値は、必ず一回、変数に受ける
２．汎用性とか、動作時の効率とかは考えない

　

---

１．利用する値は、必ず一回、変数に受ける

複数のデータをバッチ処理するボットを作る場合を考えます。ボットのなかで、Excel や CSV や PDF やなんらかのアプリケーションから表形式のデータを取得してきて、別のアプリケーションなりに入力するとします。取得してきたデータは、自動的に割り当てられるシステム変数「$Excel Clumn$」などに二次元配列形式で値が格納されます。

プログラミングできる人なら、この自動的に割り当てられた二次元配列形式のシステム変数を直接操作したくなります。つまり、二次元配列形式の変数で、例えば array[i][0] のように、要素を指定して直接出力先に指定したくなります（だってすでに値がメモリー上にあるんだから...）。しかし、それは Automation Anywhere では悪手です。

Automation Anywhere では、読み込んできたデータは使う前に必ず一度ユーザー定義変数に受けるのがベストプラクティスです。二度手間のように見えますが、二次元配列形式のシステム変数から取得した値は、各行ごとにそれぞれの要素をいったん別の変数に受けてから使うことになります（上記スクリーンショットの選択反転部分）。何を隠そう、Automation Anywhere のウリの一つである Bot Insight は、このお作法によって成り立っています。Bot Insight は「RPA 向けに設計された唯一の組み込み式アナリティクス機能」ですが、ボット実行中に変数に格納された値を自動的に収集・集積して、自動的にダッシュボードに表示してくれます。そう、つまり、変数に格納されなかった値は Bot Insight に面倒を見てもらえない*のです。
※実際には、v11 では変数のプロパティで「Log For Analytics」にチェックを入れた変数に格納された値が収集されます。

また、自動的に割り当てられた二次元配列形式のシステム変数は、Loop を回してその中で各行にアクセスすることになります。v11 では特定の行を指定して直接アクセスすることができず、Loop を回して順番にアクセスしなければなりません。このため、各行の処理の判断（分岐）が発生する場合は、判断に必要なデータはその行内に含まれていることが重要になります。人間が操作しているのであれば暗黙の裡に判断しているようなこともボットが判断できるようにフラグも含んだ整形されたデータを読み込んで使う、あるいは、必要であればデータを整形してから改めて読み込んで使うことが重要になり、いかにきれいにデータセットを作るかが勝負であるともいえます。

きれいに整形したデータセットを用意し、順次それを変数に受けて使うということをお作法として受け入れておけば、Automation Anywhere でボットを作成する際に最初に感じるストレスはかなり軽減されると思います。

　

---

２．汎用性とか、動作時の効率とかは考えない

ボット開発のステップで、ボット化する対象業務の処理フローが固まると、プログラミングできる人はついついエラーや例外のことを考え始めてしまいます。これはもう、そういう風に訓練されてきたからというしかない、プログラマーの思考様式の癖のようなものです。

しかし、少なくとも最初は Automation Anywhere ではエラーや例外のことはあまり考えず、まずはメインのフローを実装していくことを考えます。なぜなら、エラーが発生した場合には復旧にせよ継続にせよ何某かの人間の判断が必要になるので、エラー発生時にボット内でできることはそんなになく、エラーをトラップすることができればボット実装の取っ掛かりとしては充分といえます。
# 実際には、エラーとなった場合に途中まで進んでしまった処理を復旧すべきかどうかなど、頭の痛くなる問題はいろいろあると思います。

また、ついついプログラマー目線から見て美しいロジックやきれいな処理を作りたくなりますが、あまり動作時の効率とかは考えず、まずは泥臭く地道にひたすら決められたフローを処理していく実装を行います。Automation Anywhere で作成したボットで処理を行うのですから、自分でコードを書いて実装するよりは実行時の処理は遅くなる可能性のほうが高いですが、それでも人が手作業で処理するよりは必ず早く正確になります。

加えて、作成したボットに汎用性があるのかどうかということも、あまり考えないようにします。現在対象となっている業務のシナリオについて動作すればよいのであって、別の似たような業務にも同じボットで対応する必要はありません。似たような処理であってもインプットやアウトプットが異なるような場合は、別のボットとして作成することになります。対象となっている現在の処理フローが動作することが重要です。

Automation Anywhere でのボット作成時には本来のコーディングが必要になることはあまりないため、つまるところ、ひたすらドラッグアンドドロップと変数の指定を繰り返すことになります。肝要なのはプログラミング言語での実装とボット作成は違うレベルの話であるということ、ボット作成は特定のシナリオでの特定の処理を組み立てているということを念頭に置いていただければと思います。

　

---

　

熟練ボット開発者の方々には笑われる内容かもしれませんが、新たに Automation Anywhere を使ってボット開発を始める方に少しでも心の安らぎを届けられれば幸いです。

今回はここまで。また次回まで、みなさまごきげんよう。