はじめに 

みなさんこんにちは。気づいたらもう10月、暑さも少しずつ落ち着き、夜になると虫の音が秋の到来を知らせてくれますね。 

本日はチームでのUiPathを用いた開発においてとても重要となってくる「フレームワーク」についてお話しようと思います。 

プロジェクト開始にあたって 

チームでのUiPathを用いた開発効率の向上やOrchestratorの導入において、フレームワークやコーディング規約を整備して共有することが大切です。フレームワークやコーディング規約を吟味せずに開発に着手してしまうと、あとから修正を加えるのに大きな労力を伴ってしまいます。 

実際に私がかつて所属していたプロジェクトでは、プロジェクト開始当初は規模があまり大きくならないことを想定していたため、Orchestratorの導入をしない前提でフレームワークを整備しておりました。しかし、プロジェクトが進むにつれてOrchestratorの導入が必須となってしまい、フレームワークの改修が必須となってしまいました。Orchestrator導入を前提としていないフレームワークのままロボットを30台程度作ってしまっていたため、フレームワークの修正に60人日ほどかかってしまい、とても苦労いたしました。 

このようにフレームワークに対してあとから大規模な変更を加えることは、非常に工数がかかってしまうため、規模感を見積もった上でフレームワークを整備することがとても大切となります。 

幸いなことにUiPathでは公式でいくつかのフレームワークと優秀なコーディング規約が用意されています。これらを事前に把握しておくことによってチーム開発をよりスムーズに開始することができます。 

フレームワークの利用の仕方 

実際に各テンプレートの特徴を見ていく前に、テンプレートの利用方法を紹介します。 

今回紹介するテンプレートの多くはマーケットプレイスからnupkg形式で配布されています。これらは既定から変更していない場合、 C:\Users\{あなたのログインユーザー名}\Documents\UiPath\.templates  に配置されます。該当フォルダが見当たらない場合は作って配置してください。 

配置が完了すると、UiPathのテンプレートメニューから該当のテンプレートを見つけることができるようになります。 

フレームワークの紹介 

早速有名なフレームワークを紹介していきましょう。今回はUiPath公式のフレームワークで、特に参考になりそうなものをご紹介させていただきます。 

(1)Attended Framework 

最も初歩的で理解しやすいフレームワークです。設定ファイルを読み込み、業務処理を実施していくというシンプルな内容ですが、エラー発生時にスクリーンショットを撮る機能なども実装されており、自由度が高いながらも最低限欲しい機能が揃っています。フレームワークの名前は「Attended」ですが、Orchestratorに繋いでも使えるので、大規模な処理を想定した開発の場合以外はこちらのフレームワークを使えば良いでしょう。 

https://marketplace.uipath.com/ja/listings/attended-framework 

※派生フレームワーク

・Local Mini Framework

ファイルに記載されたデータをもとに、繰り返し処理するものとなっています。実装内容は後述のREFrameworkに少し似ていますが、ステートマシンを採用していないため、少し大雑把な印象を受けます。
https://marketplace.uipath.com/ja/listings/local-miniframework 

・Queue MiniFramework 

Local MiniFrameworkのキューを使用したバージョン。 
https://marketplace.uipath.com/ja/listings/queue-miniframework

(2)REFramework 

UiPath Academyで学習していると出てくるフレームワーク。公式の学習教材としても用いられることからも、UiPath社が本フレームワークをベストプラクティスとして押し出しているのがよく分かると思います。 

こちらはステートマシン（処理の状態を随時更新し、状態に応じて次の処理を決める）形式を採用しており、Attended Frameworkと比較すると格段に複雑になっています。しかし特定のデータに基づいて繰り返し処理を実施する場合はこちらを選択するメリットが大きいです。トランザクション単位で処理がされ、処理が成功したか否かでの後続処理を意識的に書くことができるので見やすいコードを書くことができます。 

また単体テスト用のワークフローの作成も推奨される作りとなっており、保守性が高いのも魅力の一つです。 

またREFrameworkでは①キューにデータを登録する”Dispatcher” ②キューに登録された情報をもとに処理を実行する”Performer” の２つのプロセスに分けて開発を行うことを推奨しています。これにより分散処理を行うことができます。 

欠点として、利用する難易度が高いということが挙げられます。よほど大規模な処理をしない限りは Attended Frameworkを使用すれば問題ないと思いますが、 Orchestratorなどを使用して複数のマシンで分散処理をする場合などは本フレームワークの利用を検討して良いかもしれません。 

https://marketplace.uipath.com/ja/listings/japanese-reframework 

※派生フレームワーク 

・Enhanced REFrameWork 

REFrameworkの拡張版…ですが大変複雑。中身は説明しきれないので実際にソースコードを見てほしいですが、通常のREFrameworkにおける①初期化　②トランザクション取得　③処理の各段階において、更にREFrameworkが入れ子構造になっています。 

https://marketplace.uipath.com/ja/listings/enhanced-reframework-57011 

・ReFramework for Tabular Data 

REFrameworkの入力をExcel/CSVに特化したバージョン。通常のREFrameworkでは前述の通りDispatcherとPerformerの２つに分けて開発する必要がありますが、こちらでは入力が簡易なのでDispatcherの機能も初期処理に含まれている形となっています。分散処理が不要な場合はこちらを参考にすると良いかもしれません。 

https://marketplace.uipath.com/ja/listings/reframework-for-tabular-data 

・ReFramework for MailMessage Data

ReFramework for Tabular Dataの入力がメールとなったバージョン。 
https://marketplace.uipath.com/ja/listings/reframework-for-mailmessage-data 

カスタマイズ 

チームでの開発を行う際はフレームワーク自体をそのプロジェクトに合わせた形でカスタマイズするとより効率が上がるでしょう。処理に失敗したときの挙動（メールでの通知等）や、様々な共通の初期値などを設定しておくと良いと思います。 

特にメール送信については事前に組織と打ち合わせしておいたほうが良いでしょう。メール送信のポリシーは組織によって大きく違い、ロボット用のメールアドレスを用意してもらえるかどうか、どのような経路(Outlook, SMTP, etc…)でメールを送信するかなどを決めておかないと、後々困ることとなるでしょう。 

また、カスタマイズするのはフレームワークに限りません。コーディング規約などについても、開発に長けたメンバーがカスタマイズした上で開発を開始するとスムーズになるでしょう。なお、UiPathの公式のコーディング規約は出来が良いので、こちらをベースに各プロジェクトに合わせて少し追記する形で十分に力を発揮すると思います。 

https://www.uipath.com/ja/solutions/whitepapers/coding-standards 

開発を効率化させる施策 

ここからは話の本筋から少し外れますが、フレームワーク・コーディング規約の最適化の他に実施すると効率化が見込める施策について少し紹介します。 

(1)ワークフローアナライザーを活用する 

もともとはWorkflow Inspectorという名前でリリースされていた機能で、コードの品質が十分であるか解析するツールです。「ファイルを分析」タブがワークフローアナライザーです。 

これを使うことによって、不適切な変数名や重複、ネストしすぎた構造などを知ることができます。開発中に定期的にこの機能を用いてコードの品質を向上させるだけで、開発ロボのレビューの負担が大きく減るので積極的に活用してほしいです。 

https://docs.uipath.com/studio/lang-ja/docs/about-workflow-analyzer 

(2)ライブラリ（共通部品）を作成する 

一つのプロジェクトで多くのロボットを作っていく場合、同じような機能を何度か実装したくなることでしょう。そのようなときにソースコードの流用などをしていると、該当部分に手を加えるときに横展開にかかるコストが大きく増えてしまいます。 

共通の機能をライブラリを用いて実装している場合、横展開が楽な上、バージョン管理が楽になります。共通で必要になりそうな機能は事前にライブラリ（共通部品）として開発をしておくと、管理コストが下がるのでおすすめです。 

最後に

いかがでしたでしょうか。フレームワークは今回紹介したものだけでなく様々な種類があるので、ぜひマーケットプレイスを確認してみてください。 

また弊社では他にもRPA導入の参考になる資料を公開しておりますので、ぜひこちらもご確認ください。