【RPA(UiPath)】のワークフローテンプレート(フレームワーク)まとめ

この記事ではUiPathのワークフローテンプレート(フレームワーク)の概要と導入や利用方法について説明します。自社や個人用のワークフローテンプレートを検討されている方や開発者の方に見て頂ければと思います。

【目次】

 はじめに

UiPathのワークフローテンプレートについて説明する前に、一般的なフレームワークとその必要性について説明します。まず開発におけるフレームワークとは開発する際に頻繁に必要とされる汎用的な機能を纏めて提供し、作成時の土台として扱われるもの(枠組みや骨組み)の事です。頻繁に扱われるものをテンプレート(フレームワーク)化しておく事によって、下記の効果を得る事ができます。

<フレームワークの効果>

〇先人の知恵や反省/改善点が盛り込まれており開発生産性があがる

〇誰でも一定の品質で開発ができるようになる。(ベストプラクティスや規約を知らなくても真似て作るとベストプラクティスに近いレベルで作成ができている)

〇ある程度決まった形式で開発がされるため、可読性や保守性が高まる

〇該当部分の開発やテストをする工数が削減される

フレームワークがなければ、開発者は各々で好きなように開発を行い、エラーハンドリングが上手くできていなかったり、開発者毎に作りが違い、レビューや処理内容の理解に時間が掛かってしまったり、同じ処理を毎度開発及びテストをして無駄な工数を掛けてしまったりしてしまいます。

フレームワークはあれば便利なものですが、皆が共通的に扱うものであるため、最適化(無駄な部分がない)がされており、品質が担保されている(バグがない)且つ、開発規約通りに作られている状態である必要があり、初めから良いフレームワークを独自に作成するのは難しいです。しかし、UiPathではこのフレームワークに関して、公式とマーケットプレイスでいくつかを無料で提供されているため、それを利用すれば、導入を容易に行う事ができます。

 UiPathのワークフローテンプレート(フレームワーク)

ご存じの方も多いと思いますが、UiPathのワークフローテンプレートはStudioの標準機能の一部として使える状態になっています。該当のテンプレートは下記6つです。公式サイトに情報がありますが、いまいちどのようなテンプレートなのか分かり難いものがありますので、別途検証してそれぞれの解説記事を作成して説明予定です。(今回は概要の説明のみ記載)

<Studioに標準で搭載されているワークフローテンプレート>

1.オーケストレーション プロセス

人間の介入及び実行時間の長いトランザクションを使用するプロセス向けテンプレート

2.バックグラウンド プロセス

バックグラウンド及び並行で動かせなくなる可能性のあるアクティビティに利用制限が掛かっているテンプレート

3.モバイルテストプロジェクト

モバイルアプリの自動化テストケース用のテンプレート

4.Robotic Enterprise Framework

大規模開発向けのテンプレート(ReFramework)

5.トリガー ベースの有人の自動化

イベントをトリガーにして動作するプロセス向けテンプレート

6.トランザクション プロセス

基本的なオートメーションプロセス用に最適化されたフローチャートに基くプロジェクトテンプレート

【Studioのテンプレート選択画面】

以上がStudioの標準に備わっているテンプレートですが、こちらをベースにして扱うのではなく、マーケットプレイス(旧UiPath Go!)の方から作成した方が日本語化もされており、ガイドも充実しているのでお勧めです。マーケットプレイス にどのようなワークフローテンプレートが存在していており、どれを選べばよいのかの情報は「しおちゃんさん(@Jun96427231)」のブログで分かり易く纏められているので、こちらを参照頂ければと思います。

私のブログではテンプレートを運用させていくための処理手順について説明をしていきます。

qiita.com

 UiPathワークフローテンプレートの導入方法

ワークフローテンプレートの導入は下記のSTEPで導入をしていきます。

<ワークフローテンプレートの導入STEP>

STEP1：基にするワークフローテンプレートを選定する

STEP2：STEP1のワークフローテンプレートに対してカスタマイズを施す

STEP3：ワークフローテンプレートの管理方法を決める

STEP4：ワークフローテンプレートのルールを決めてガイドを作成する

STEP5：ワークフローテンプレートとガイドを展開して運用開始させる

それぞれのSTEPで実施する作業内容の詳細は下記の通りです。ワークフローテンプレート構築はRPA管理が部署毎に完全に分断されない限り、社内全体の運用として動いた方が良いです。部署異動したらロボの作りが別ものになっていたらフレームワークの効果が薄れます。初めから全社的な動きが難しい場合は、1部署から運用を初めて徐々に全社に適用していくやり方もあります。

<STEP1：基にするワークフローテンプレートを選定する>

基となるワークフローテンプレートを選んだら、自社/個人用にカスタマイズを行っていきます。ReFrameworkは開発者レベルが高い人以外の人が理解して扱うようになるにはそれなりの教育が必要となるため、開発者レベルが低い人も扱えるテンプレートをまず用意してから、他のバリエーションのテンプレートを徐々に整えていくのが良いと思います。個人的にお勧めのやり方が「日本語版Attended Framework」を初めのテンプレートとして整備して、その後日本語版Attended Frameworkと日本語版ReFrameworkを必要なバリエーション分徐々に増やしていくやり方です。

Attended Frameworkの繰り返しステータス監視対応版や様々なトリガーに対応した版等が増やしていくテンプレートイメージとなります。これらのテンプレートは実際の案件で作成された成果物からテンプレート化して作り出していくやり方も良いと思います。ReFrameworkはマーケットプレイスに様々なトリガー(ExcelやMail)に対応した派生形テンプレートが既に掲載されているのでSTEP2のカスタマイズを同じように対応すれば、派生形テンプレート作成も短い時間で作成する事が可能になっています。

<STEP2：STEP1のワークフローテンプレートに対してカスタマイズを施す>

ワークフローテンプレートに修正が必要な部分がないか確認します。例えば自社の人達が扱う際に問題なく扱う事ができるように初期設定ファイルやテンプレートに注釈や補足を追加したり、初期設定ファイルの定数シートに待機時間やタイムアウト時間の情報を追加したり、ロギングに追加が必要な情報(フレームワークバージョン、本番/開発フラグ等)を追加したりします。そのままでも、テンプレートとしては十分に扱えるので、運用開始前に必要なカスタマイズ内容が思い浮ばない場合、実際に使ってみてからバージョンアップさせる対応でも良いと思います。但し、Main.xamlは社内の命名規則チェックに極力引っかからないように修正しておいた方が良いです。また、Attended FrameworkやReFrameworkのプロジェクトフォルダ内のframeworkフォルダに入っているものは、命名規則対応はせず、開発時のコードチェックの対象からもファイルごと外して良いと思います。変数等修正すると無影響確認をしないといけなくなるのと、バージョンアップがあった際に取り込むに時間が掛かるようになるためです。Main.xamlはコードチェックから除外する事は不可能であり、必ず開発者が修正するファイルのため、やむを得ず対応するものです。

【ReFrameworkのfremeworkフォルダ内】

また、マーケットプレイスからダウンロードしてきた、テンプレートのプロジェクトフォルダ内には「Documentation」というフォルダがあります。この中に利用ガイドが入っていますが、ガイドはどこか別の場所で管理するようにして、このフォルダ内からは消した方が良いです。皆が使うプロジェクト全てにこのガイドが入っていると容量を圧迫させてしまいます。

<STEP3：ワークフローテンプレートの管理方法を決める>

ワークフローテンプレート資源の管理場所や修正ルールを決めます。バージョン管理ツール(GitやSVN)やファイルサーバー上等、原本を保存する場所と各所への展開、連携や利用方法を決めます。知らずに勝手に修正されたり、修正後の連携が漏れてしまったりしないような管理にしないといけないのが注意点です。

<STEP4：ワークフローテンプレートのルールを決めてガイドを作成する>

ワークフローテンプレートを扱っていくには、下記のようなルールを決める必要があります。

〇ワークフローテンプレートは必ず使わなければいけないのか

〇使わない場合に守らないといけない開発ルールはあるか

〇複数テンプレート存在する場合、どのように使い分ければよいのか

基本的に原則利用させるようにした方が良いと思います。自由にすると利用はされず、効果が薄れる可能性が高いです。今までの開発スタイルを変えるのを嫌がる人は多いですが必要性を伝えて納得して貰う事も重要です。また、私はテンプレートの中で絶対に守らないといけない場所はロギングの個所が該当すると思っています。後々分析を行う際や、障害対応を行う際に、ロギングが規則通りに作成されていないと、保守と運用に支障をきたすためです。このような取り決めが決まったら、開発ガイドにルールの追加や利用手順に取り込みを行います。

<STEP5：ワークフローテンプレートとガイドを展開する>

上記STEP4まで準備が整った段階で、各所にテンプレートを展開して運用を開始していきます。改善要望やこんなテンプレートもほしいといったような意見を送ってもらう運用構築や管理チームの体制構築もこの段階からできれば理想です。また、必ず守ってほしい規則がある場合はコードレビューチェックリストやworkflow Inspecttor、Analyzerのチェック機能でチェックできるようにしておくと尚良いです。

 UiPathワークフローテンプレートの使い方

自社/個人用に作成したワークフローテンプレートは下記2つの方法で利用する事ができます。2に関してはStudioにテンプレートとして保存(ローカル上)して、Studio上からすぐに呼び出す事ができます。

1.ファイルサーバーやバージョン管理ツールから都度テンプレートを取得して開発

2.一度上記1から取得したテンプレートをStudioに登録して、そこから開発。カスタムテンプレートと呼ばれているものです。登録方法についてはUiPath公式ガイドをご参照ください。

プロジェクト テンプレート

 UiPathワークフローテンプレートの運用

他の共通部品(カスタムアクティビティやスニペット)と同様ですが、現在社内で扱う事が可能なテンプレートの種類やバージョン情報は、関係者が把握できるような運用を構築する必要があります。一覧を作成しておき、関係者が参照可能なところに一覧を配置して、バージョンアップ等なにかあれば連絡で知らせる事ができる運用を考えて、実施していけば問題なく運用できると思います。RPA推進チームやCoE(センター・オブ・エクセレンス)の体制を組んで、全体的に管理できればベストです。

 さいごに

優れた開発テンプレートは開発面や保守面において非常に有効なものとなります。テンプレートを扱っていないで開発されたワークフローはもう見たくないというな気持ちになるくらい違いが出てきます。RPA推進チームがテンプレートを整備してくれない状態であれば、チームや個人で作って運用開始して効果を伝えて社内に広げていく事もできますし、最悪自分だけで扱うだけでも効果はあります。まだワークフローテンプレートを使って開発していない方はまず、日本語版Attended Frameworkを使ってみる事をお勧めします。

共通部品を上手く扱い、効率的に開発をしていく事でUiPathの力は更にあがっていきます。「開発規約×ワークフローテンプレート×共通部品×コードチェック」を充実させていく事で、新たに開発しなくてはならない範囲を徐々に減らしていく事ができます。ロボを作って共通化していけばいくほど、開発時間が短くなり高い品質の開発が可能になっていくのです。この記事が皆様のワークフローテンプレート導入の手助けやきっかけとなる情報となっていれば幸いです。

その他のUiPath情報も記事で纏めています。下記にリンク集があるので他の情報も気になる方はこちらのリンク集記事から飛んでいって頂ければと思います。

syachiku-inu.hatenablog.com