#おことわり
UiPathのタグをつけていますが製品に関することには触れません。
質問されてもチョットデキル程度なのでご期待に添えるかわかりません。
はじめに
VBAやC#などの自動化の延長で分からないながらも
UiPathのシナリオを作成するときに考えるべきことをまとめてみました。
RPAに出会ったキッカケ
日頃から自動化ソリューションに携わっていた私は
ここ最近の成果で月間８０時間の業務効率化を実現していたこともあり
クライアントから「UiPathでRPAやってみない」と
まるで「今日飲みに行かない？」感覚でお誘いを受け
業務自動化や効率化の傍らでRPAのシナリオ作成を始めました。
レッツトライ、そのまえに
UiPathとは何ぞやというところからのスタートでしたが
よくわからないソフトウェアやハードウェアを扱うことが多い人生を
歩んでいたこともあり
こういうハツモノやフメイな奴を相手にするときに重要なスタンスを
無意識にとっていました。
言葉で表すのであれば
分からないながらも走りながら考える
ということ
自動化において大事なこと
いくつかの業務自動化案件を実行に移してきて
シナリオ作成や自動化ツール云々の前に大事なことがあると私は考えています。
そこにヒトがいるかどうか
自動化は主に２つに分類できます。
・無人の自動化を Unattended
・有人の自動化を attended
と分類できます。
詳しく書くと一つの記事になってしまうので割愛しますが
要するに、自動化をキックする存在が機械か人間なのかということです。
タスクスケジューリングを設定して機械に定期的に動かしてもらうのか
それとも、人が動かすのか。
この点のユースケースを明確にしておかないと
どんなにすごいシナリオを作成しても意味がありません
Unattendedのシナリオをヒトが実行する
ということが無いようにしっかり
シナリオのユースケースを意識しましょう。
何を目的とした自動化であるか(そもそも必要な自動化であるか)
自動化対象の業務のほとんどが
この質問ひとつでなくなることもある。
このようなことが起きる主な理由として
業務従事者含め業務の目的が分からない
ということ。
誰に必要とされている業務かわからないけど
研修時代に教わった仕事なので
継続してやってますというパターンがとても多い。
この点のミスマッチがあると
意味のない無駄な自動化シナリオの積み上げ をしてしまうということ
たくさんのRPAシナリオ作成や自動化ツールの作成を
やってきたと豪語される方には
こういう真の自動化について勉強されたほうが良いかと思います。
そうするとあなたはどうなのかという質問があるかと思いますが
私は無駄だと判断できる仕事については
その理由を明確に述べたうえでお断りしています
わざわざ無駄なことに時間を割くことはないですし
もっと重要なことに時間を使うべきだと考えています。
ターンアラウンドタイムがどれくらいの自動化であるか
これはアプリケーションを作成する人も意識するところになりますが
キックしてから終わるまでのターンアラウンドタイムがどれくらいかというところ
このターンアラウンドタイムが長いと
Unattendedの場合は他の自動化の妨げになる。
attendedの場合はユーザが終了まで長いこと待つことになる。
これはツール開発、シナリオ作成におけるデメリットもあり
検証時の結合テストに時間がかかってしまうという業を背負ってしまう。
こういうときのベストプラクティスとして
自動化する業務を最小限の工程に分離して独立させる
例えば、作業工程の多い業務Xがあったとすると
それを頭から順に自動化するのではなく
業務XA,業務XB,業務XC という形に分離して自動化する。
そして、それらを順に実行するという形をとる。
プログラミングで表現すると
Sub Auto(工程番号 As Integer)
Select Case 工程番号
Case 1 :
Call 業務XA()
Case 2 :
Call 業務XB()
Case 3 :
Call 業務XC()
End Select
End Sub
Sub main()
Call Auto(1)
Call Auto(2)
Call Auto(3)
End Sub
結合度
自動化対象の業務には
既に秘伝のタレを使った味玉のようなマクロやツールが存在する場合がある。
こういう場合はその秘伝のタレを使った味玉と連携をとることを
考えなければならない。
マクロと同じ内容を一から作り直すという発想もあるかとは思いますが
マクロで実行している内容を
一から組みなおすことは業務従事者含め業務の内容が分からないということもあり
とてもリスキーなので連携をすることを先に考える。
このときに大事なことは
シナリオの中に秘伝のタレを使った味玉を混ぜないこと。
例えば、RPAのシナリオ作成においては
シナリオ内に奇妙なマクロやスクリプトを挟まないことが挙げられる
ここでそういった秘伝のタレを使った味玉入りラーメンを作ってしまうと
ラーメンそのものの味を確認することが困難になってしまう。
また、食べ方よっては
秘伝のタレを使った味玉を最後に食べたいという人もいるだろう。
なのでラーメンと秘伝のタレを使った味玉は皿を分けておくことがとても大事なのです。
ラーメンをシナリオ,秘伝のタレを使った味玉を奇妙なマクロやスクリプトと
置き換えるとお分かりいただけるだろう。
自動化対象のシステムが必ずそこにあるか
既にユーザ（ヒト）が扱うことを想定したWebシステムを
導入している会社がほとんどだと思います。
案件の中には自社開発もしくはベンダー依頼のシステムを自動化することもあります。
このときに大事なことは
RPAのシナリオを実際に扱うときそのシステムが必ず稼働しているかということ
例えば、システムメンテナンス時のことを考慮せずに
RPAのシナリオを作成してしまうとエラーを吐いた状態で停止したり
接続できないことに気づかずにシナリオが何回もシステムに対して接続を試みて
メンテナンスページを繰り返し開いてしまうといったことが起きる。
そもそも、立ち止まって考えて欲しい話ですが
ユーザ（ヒト）が扱うことを想定したWebシステムは
ヒトが扱うことを想定しています。（当たり前かよw）
つまり、システムが使える時間かどうかと
そのシステムを使うかどうかはユーザの判断に委ねられている為
シナリオにもそういう旨の内容を定義すべきなのです。
シナリオの実行環境が整っているかどうかという観点は絶対に忘れてはなりません
まとめ
長々と書きましたが、いかがだったでしょうか。
それではまとめです。
・分からないながらも走りながら考える
・シナリオのユースケースを意識する
・意味のない無駄な自動化シナリオの積み上げをしない
・自動化する業務を最小限の工程に分離して独立させる
・シナリオの中に「秘伝のタレを使った味玉」を混ぜない
・シナリオの実行環境が整っているかどうかという観点を意識すること
最後にひとつ大事なことを書いて終わります。
RPAもマクロも万能ではありません。夢は見ず、現実を見ましょう。
シナリオがうまく作動しないこともちゃんと考慮してマニュアルを作成しておきましょう。