ロボ設計でつまずきがちなところ
Excelに記載された40人分のユーザーにそれぞれ専用のBOXフォルダを作成するロボを作成した、私。
BOXフォルダはアクセスするのにフォルダIDが必要なので、作成したら担当者マスタのExcelにIDを書き込んでいく予定。
フローは単純で
担当者マスタExcel読み込み ⇒ メールアドレスをKEYにBOXフォルダを作成 ⇒ フォルダIDをマスタに書き込み
の流れです。
いよいよ、リリースとなり、初回、みんなが見守る中、処理実行開始！！
【Start】
1人目、作成OK
2人目、作成OK
：20人目でなんかコケちゃった
→ ロボ停止。エラーメール送信。
【End】
BOX上には19人分のBOXフォルダと何も更新されていない担当者マスタが残る。
エラー原因を調査！！
どこまでいったか、担当者マスタのExcelを見ても分からないので、ログを追いかける→20人目でコケタのが分かる→原因を調査→分かった！解決
さて、再実行（あ、BOXのフォルダ消さないと・・・19人分のフォルダ消す→再実行！今度こそ！）
【Start】
1人目、作成OK
2人目、作成OK
：
21人目でなんかコケちゃった
【End】
BOX上には20人分のBOXフォルダと何も更新されていない担当者マスタが残る。
心の声（くそーーーーー！ひとり分も終わらねぇ！！）
ユーザー 「とりあえず、出来てる人だけでも使いたいんだけど」
私 「あ、、BOXIDがかけてないから、使えないっっ。。。。まって、、、レコード絞って再実行します
も、、、もう少々お待ちください
」
ユーザー 「じーーーーーーー。（早くして）」
※これが夜間バッチだった場合、翌朝から使えると思いこんでいた人達からのプレッシャーを受けまくるケースもあります
ループ構成
お気づきの方もいらっしゃると思いますが、あるリストに対する一連の処理をする際には2パターンの設計があります。
A
B
まとめ
こういうループって絶対途中でコケるので、「やれるところまでやりましたロボ」にすることをオススメします。
（もしくは、ユーザーとの仕様決めのときに、ゼロイチロボかやれやりロボかの認識を合わせておく）
エラーはTry-Catchesで受けとめるんだけど、ロボ停止せずに、「コイツの作成失敗した」っていうのをメモって次の行の作業を進める。
ってすると、後から、ダメだった人だけフラグ立てて再実行すればよい。みたいな風にもできます。
エラーをキャッチしたら、ロボを停止しないといけないってことは無いのです。
RPA化するにあたって、「手作業をそのままRPAに再現させる」という方法を取ると、このループに陥る可能性が高いです。
人間のやり方では「纏めてやった方が効率がよい」ので、各処理ごとにまとめてやってしまう流れにしていることが多いと思いますが、RPAではまとめてやっても、1件ずつ全ての作業を流してもほとんど変わらないケースが多いので、そういう目線での設計が大切かなと思います。
以上、よくある事例紹介でした！