この記事は以前Youtubeに投稿したこちらの動画の原稿になります。
滑舌悪くて聞き取りづらかった方はどうぞ参考にして下さい。
#背景
RPAのオートメーション（自動化ワークフロー）は専門のプログラミングスキルを持たない人でも作成できるため、会社の色んな部署で自発的に作られてるケースは多いと思います。作りやすいゆえにタケノコの如く様々なオートメーションが増殖してゆく・・・するとどうなるか。
その時はいいんです。作った人がそこにいて、何かトラブルがあってもすぐ対応できる。追加の要望もすぐオートメーションに取り込んで、作った人は周囲から「やるじゃん」と褒められ、利用者は仕事が楽になり、みんなハッピー・・・その時はね。
作った人が異動するとどうなるか。たぶん後任者が（仕方なく）オートメーションを引き継ぐでしょう。そして次の日なぜかオートメーションが止まり、利用者から呼び出され、原因調査のためにStudioでオートメーションを開くと・・・はいここからが悪夢の始まり。
１つの巨大なシーケンスの中に100個以上のアクティビティがデフォルト名のままひしめき合い、IFの分岐が何重にも入れ子になって横に膨らみ、いったい何をやっている処理なのか、どこを直せばいいのか全くわからず時間だけが過ぎてゆく・・・作り直せればまだマシな方。最悪ゴメンナサイして総員手作業に逆戻り～。
こんな事態にならないよう、「見やすく」「わかりやすい」オートメーションを作るための決まり事が必要なのです。システム開発ではよく"開発標準"とか"実装標準"という呼び名で、どのようにプログラムを作るかのルールを細かく決めて開発を進めるのですが、オートメーション作成でもやっぱり同じ事をしないといけない。
しかも今度はIT部門じゃない、人事・経理・総務・事業企画といった人達が対象になるので、ITの開発標準と同じくらい細かくルールを決めてしまうと、逆に守れなくなる恐れもある。
というわけで、個人的な経験から「オートメーション作るならコレは最低限守った方が良い」というルールを10個に絞り、オートメーション作成10箇条として挙げてみます。
#1.作り始める前にドキュメントをきちんと用意する
・対象の業務はそもそも何のために存在するか（目的）
・作ろうとするオートメーションが、その業務の中のどの範囲の作業を自動化するものか（対象）
・自動化する作業の具体的な手順（詳細）
といった事を記載したドキュメントが必要です。
このパートだけでも別の記事にするくらい長くなるので詳細は省きますが、これらが有ると無いとではオートメーションを引き継いだ人の理解度が全く違います。結果、トラブル対応やオートメーションの改修スピードに大きな差が出る他、管理資料として部署全体で活用すれば、RPAで良く聞く"野良ロボット"対策にもなります。
#2.１階層目はフローチャートで組む
いざオートメーションを作り始める際、まず最初の階層はシーケンスでなくフローチャートにします。その中に「XX画面検索」とか「XXファイルダウンロード」といったシーケンス／フローチャートを作って線でつなぐ作りにする事でワークフローの可読性が上がります。
20行未満の小さいオートメーションでもこのルールは守ります。将来機能拡張で大きく育つ可能性もありますし、全てが同じルールに則って作っているという事が"次の担当者への優しさ"です。
#3.１シーケンス内のアクティビティは20個以内
"ええ～"という声が聞こえてきそうですが、まぁ20というのは目安で。ここで言いたいのは、作業の流れを"意味のある小さなまとまり"に分けて表現すると見やすいよ、という事。
元の「XXシステムへのデータ登録」が100アクティビティになるなら、それを「Excel台帳の読み込み」「データの存在チェック」「ヘッダ情報登録」「明細情報登録」といったまとまりでシーケンスにバラします。フローチャートの中にフローチャートを入れる事もできるので、１階層で表現できない大きなオートメーションは階層を掘って、階層ごとにイイ感じに作業をまとめる事で、読みやすくできます。
#4.アクティビティの表示名(DisplayName)を書き換える
「文字を入力」「条件分岐」といったアクティビティの表示名を、「顧客名を入力」「単価が10万円以上か」など、そのアクティビティが実際に行う事に書き換えます。#1のドキュメントと組み合わせる事で、トラブル対応や修正時に目的の箇所へすぐたどり着く事ができます。最初は面倒ですが、"次の担当者"だけでなく"作ったオートメーションを数ヶ月ぶりに開いた自分"にも効きます。
１つ１つ書き換えるのが手間なのは否めないので、どのレベルまでやるかは部署ごとに要相談で。ただ最低でもシーケンスやフローチャートといった大きな箱には適用しましょう。
#5.シーケンス内の条件分岐は１階層まで
シーケンスは縦に読むものなので、条件分岐(IF)を入れ子にして横に膨らんでいくと非常に見づらくなります。IFの中にIFは入れない。
何回も条件分岐を通る作業であれば、シーケンスをやめてフローチャートにして、フロー条件分岐(Flow Decision)を組み合わせて作ります。
#6.同じ処理は二度書かない
これはプログラミングでも鉄則で、１つのオートメーションの中で似たような処理が何回も登場するなら、コピー＆ペーストで増やすのではなく、共通ワークフローに切り出すべきです。じゃないと修正する時に１つ１つ直すハメになる。
UiPathであればシーケンスやフローチャートを右クリック→「ワークフローとして抽出(Extract As Workflow)」で簡単に切り出す事ができるので、積極的に共通化していきましょう。
#7.ID/パスワードを埋め込まない
これについては以前の記事
ログイン情報（ユーザーID/パスワード）の持たせ方
を参照下さい。
#8.失敗時にリトライしやすい作り
基本的にオートメーションは止まるものだと思って下さい。言われた事しかできないので、予期しないポップアップが出たり、システムのレスポンスが悪かったり、想定したデータが存在しなかったり、という小さいアクシデントですぐ止まります。
なので止まった時のリトライが簡単になるように作るのが大事。どこまで処理したかをログから読み解いて、中途半端に登録したデータを１つ１つ削除してからリトライ・・・なんて危なくてやってられないでしょ。
一番良いのは、もう一度オートメーションを実行するだけで済むようにする。例えばシステムへデータを登録する作業なら、登録する前に対象のデータがシステムに存在するかを一度検索して、あればスキップ／無ければ登録といった作りにして、二重にデータ登録されるリスクを無くす、など。このへんは日々バッチ処理のリトライと戦うIT部門にノウハウがあるはずです。
#9.ゴミを残さない
いるよね、レコーディングで自動生成されたシーケンスをそこらじゅうに散らかしたままにする人。もちろん線で繋がってなければ悪さしませんが、後で他の人が見たら「これは本当に要らないんだろうか？」と不安になります。
ただ、"一度作ってみたけどうまく動かなかったので別のやり方にした"という例では、前者を（コメント付きで）コメントアウトで残しておくのはアリだと思います。"うまく動かなかった"というのも立派なノウハウなので。
#10.xamlとjsonをソース管理の仕組みに入れる
作り方の話ではありませんが、プロジェクトフォルダ内の*.xamlファイル（ワークフロー定義）と*.jsonファイル（利用するパッケージバージョン等の定義）の保全も非常に重要です。
これらのファイルがトラブルで消えてしまったり、修正したら逆にバグってしまった時など、いつでも前のバージョンに戻せるようIT部門に相談してソース管理の仕組みに入れてもらいましょう。UiPathは公式でTFSとSVNをサポートしてますが、所詮ファイルの管理なのでツールは何でも良いと思います。
それこそバックアップや世代管理といった要件さえ満たせれば、専用のツールでなく共有ファイルサーバーでも良いんじゃないかと。
#最後に
でも一番大事なのは、こうした10ヶ条がきちんと守られているかを定期的にチェックする体制を作る事です。ルールだけ決めても守られなければ意味がないわけで。
ドキュメントなんて作らない人はとことん作らないからね。10個全てクリアするまでそのオートメーションは使わせない、くらい強制力のある運用がとれるかどうかがカギなのです。
今回はここまで。
UiPathに出会ってからほぼ１年経ち、私の周りでもオートメーション作成スキルを身につけて自動化を進める人達が増えてきました。このQiitaブログ自体、半分は自分の趣味、もう半分はそういった人達のスキル底上げを支援する目的で始めたので、だいぶ使命は果たせたと思います。
一方で、オートメーションが増える事で別の問題が出てくるフェーズに入ってきたため、今後はこのオートメーション作成10箇条のように「どうやったら最悪の事態を防げるか」というネタでも記事を書いて行こうと思います。
※半分は趣味なのでしゃべるアクティビティとかUiPath受肉とか、誰得なネタも多いですがご容赦下さい。