Last updated on 2020年12月31日
他の猫が作ったワークフローをみたニャ
けど、行っている内容が全く分からないニャ
そうだよね、他人が作ったワークフローを理解することは難しい。
だから、自分が作ったワークフローを他の人が見たときに理解できるように工夫をすることが大切だよね。
みなさん、こんにちは、エピックです。
人が開発したワークフローを見て、「行っている処理がわからない...」となったことはないでしょうか。
自分は何回もあります！
分岐が多くシーケンスが入れ子状態担っていたり、変数が多くこれ何に使っているのとなったり...理由は様々ですが。
今回は、ふっくら猫さんも困っているようなので、いままでの経験からワークフローの可読性を高める工夫について書いてみたいと思います。
見やすいワークフローのポイント
ポイントは次の通りです。
- 処理単位でワークフローを分けている
- 変数に分かりやすい名前がついている
- 個々のアクティビティに適切な名前がついている
- 注釈がついている
個人的に重要だと思うものから上位に記載しました。
それぞれについて下記で記載していきます。
処理単位でワークフローを分ける
UiPathでは、開発を行おうとすれば一つのワークフロー内ですべての処理内容をまとまて開発することができます。
例えば、フローチャート上にすべての処理を記載してしまうことができます。
しかし、この方法はテストの観点また見易さの観点から避けるべきです。
UiPathのワークフローの組み立て方法として、フローチャートとシーケンスがありますが、アクティビティ（例えばExcelアプリケーションスコープ）によってはフローチャート形式では中の処理内容が表示されないものも存在します。
その場合逐次開いて確認する必要が出てきてしまいます。
では、シーケンスを利用した場合はどうでしょうか。
こちらの場合は、複雑な分岐を伴う場合の記述が入れ子状態になるなど一見で概要を把握するには適しません。
これらの点を考慮し、フローチャートで全体的な処理を記述し、具体的な処理は【ワークフローを呼び出し】アクティビティを利用し別のワークフロー（シーケンス）上で記述するようにします。
下記は「今日が作業日か判断し、作業日であればシステムへ登録するワークフロー」のMainのイメージとなります。
ここの具体的な処理はすべて【ワークフローを呼び出し】アクティビティを利用し別のワークフローへ飛ばしています。
そういえば昔教えてもらったのを思い出したニャ
変数に分かりやすい名前をつける
変数には分かりやすい名前をつけるようにします。
例えば、◯◯システム_ID や 〇〇ファイル_パス というような形式です。
命名規則はありませんが、ある程度社内で共有するほうが望ましいです。
昔（３年ほど前）は英語のみの対応でしたが、日本語もスタンダードとなったので日本語で問題ないです。
個人的に気をつけている点は次のとおりです。
- 日本語で定義する
- 助詞は使わず、アンダーバー（_）でつなぐ
- 変数名の先頭に具体的な対象名をもってくる
例としては、システムA_ID や システムA_パスワード 、請求書_フォルダーパス や 請求書_ファイルパス などになります。
個々のアクティビティに適切な名前をつける
クリック処理などを利用した場合、対象のクリック箇所が画像として残されますが次に見た人がそれで理解できるかどうかは難しいところです。
クリックや書き込みを行う等の具体的に記述が可能なアクティビティについては、そのターゲットとなる箇所の名前をアクティビティ名に追加してあげます。
例えば、クリック【Google 検索】、入力【検索欄】のようになります。
また、Mainから呼び出す【ワークフローファイルを呼び出し】については、具体的な処理の内容を記載するように私はしています。
上で貼っている画像を参考にしてみてください。
注釈をつける
UiPathでは、個々のアクティビティおよび変数に注釈というコメントを追加することができます。
複雑な処理を行う際は、必ずこの注釈機能を利用するようにしてください。
追加方法は、対象のアクティビティを選択した状態で右クリック [注釈]→[注釈の追加] から行うことができます。
さきほどのワークフローに注釈を追加した場合次のようになります。
わかりやすくなったのではないでしょうか。
また、変数に注釈を追加した場合は、次のようになります。
注釈なんて知らなかったニャ
次から利用してみるニャ
人にも理解されるワークフローの開発を心掛けて
RPAは、非常に簡単に開発を行うことができ短時間で業務の効率化を行うことができます。
しかし、そのメリット故に開発後に発生する保守や運用のことをおろそかにしがちです。
もし、社内業務の自動化を行った場合、確実にその保守や運用が発生します。
また、その開発した自動化ワークフローに依存すればするほど、長く使われ担当の入れ替わりも発生します。
RPAだからと安易に考えるのではなく、一つのシステムとしてどのようにしたら他人にも分かりやすく将来的な属人化を排除できるか考え開発することが大切だと考えています。
もし、みなさんのこうやったらいいよというアイディアがあったら是非聞かせてください。
最後までお読みいただきありがとうございます。
では。
