RPA開発を進めるうえで気を付けるべきこと

こんにちは。スマートソリューションセンターの吉田です。

前回RPA記事では、RPAロボットの規模、開発生産性を算出する方法をご紹介しました。
本記事では、クレスコでRPA開発を進めていく中で直面したいくつかの課題と、その対応についてご紹介したいと思います。ここで課題として掲げる内容は、実はRPA導入を進めていく上で、考慮が必要で、ルール化すべき内容だったりします。プログラム開発でいうところの「コーディング規約」にあたり、当社では「RPAガイドライン」という名称で策定を進めております。

では、早速見ていきましょう。

エンジニアの皆様には「あるある」な内容ですが、RPAでも同じようにこれらの課題に直面しました。1人でRPAロボの開発、メンテナンスを行うのであれば、そこまで気にしなくてもよいのですが、組織としてRPAの管理を考える時には、こういった状況に陥らないように方針を示しておくことが必要になります。順番に見ていきましょう。

RPAツールによって、多少異なりますが、いわゆるデザインパターン、アーキテクチャパターンなどのフレームワーク（枠組み）が提供されるわけではないので、自由度が高く、いろいろなつくり方が許容されています。それがいいところでもあるのですが、人によって作り方が異なり、複雑怪奇なフローとなってしまうこともあります。

プログラミングの世界では、こういった設計手法を突き詰めていった結果、デザインパターンというものに集約されたわけですが、RPAでいきなりデザインパターンの話をしても？？？となることが想像できますので、まずは組織における、RPAプロジェクトテンプレートを作成することをお勧めします。

起動から終了までの全体の制御フローをあらかじめテンプレート化しておき、個別の業務処理についてのみ、各担当者が実装するのです。そうすることで管理者も個別の業務処理のレビューに注力でき、開発者も効率よく自動化したい業務の開発に集中できるようになります。

UiPathでは、「ReFramework」というプロジェクトテンプレートをUiPath社が公開しています。

ReFrameworkは、初期化処理（設定ファイルからの設定値読み込み）、個別処理呼び出し、エラー処理、Orchestrator（サーバ管理ツール）との連携などを含むプロジェクトテンプレートになっています。このまま使うには少し使いずらいところもありますが、これをベースに使いやすいプロジェクトテンプレートにカスタマイズして使ってみるのはいいと思います。

ここでいうハードコーディングとは、「変更の可能性がある値や処理を、直接ソースコードの中にべた書きすること」と指します。

例えば消費税や、年号など、変わる可能性がある値をロボの動作に組み込んでしまうと、変更があるたびにロボの修正が必要になります。これをExcelなどの設定ファイルに外出ししておくことで、ロボ本体の修正が不要になります。

まずは、処理フローにべた書きしている箇所を変数化しましょう。見通しが良くなります。
さらに、PC環境や、外部要因によって変更の可能性がある箇所については設定ファイルに外だししましょう。これでそれなりに保守性が高くなるかと思います。

• 設定ファイルから設定値を取得する処理
• 特定のAPI・サービスを呼び出す処理
• 特定のシステムにログインする処理

こういった処理が各所に存在する場合、修正が必要になったときにすべての箇所に修正をかけなければいけません。どこか修正をし忘れてると、それが不具合になってしまいます。共通化ができていると修正するファイルは一箇所で済み、修正し忘れるといったリスクが減ります。

あらかじめ共通処理として作ることができればそれが良いのですが、判断が難しいときもあるので、基本的には作ってみて、重複する処理が出てきた段階で共通化するとよいと思います。

さらには、業務に特化しない処理については、他のロボでも使えるように共通部品化を行うと、効率的にロボ開発が進んでいくと思います。個人的には、どれだけ共通部品が作れるかでロボ開発の効率が大きく変わってくるかなと思っています。

業務自動化において、処理を自動化することが主目的のため、どうしても例外処理、ログは、後回しになってしまいがちですが、なにかトラブルが発生したときに、例外処理の有無、ログの記述量で原因特定・復旧にかかる時間は大きく変わってきます。

対策は難しいことではなく、ルールを決めること。プロジェクトテンプレートに組み込むことをお勧めします。我々のチームでは、ワークフローの最初の処理は呼び出しログであること。制御フロー側で、例外処理を組み込むこと。などルールを定めつつ、テンプレートに反映して運用しています。

RPAでは、簡単にExcelファイルなどの物理ファイルの読み書きができます。
例えばある処理を1ooo回行い、結果データをExcelに書き込みたいとします。皆さんならどうしますか？

①「処理を行う→Excelを開く→1行書き込む→Excelを閉じる。」を1000回繰り返す。
②「処理を行う」を1000回繰り返す→Excelを開く→1000行書き込む→Excelを閉じる。

結果的には、どちらもやりたいことは実現できますが速度面では明らかな差が発生します。
ファイルの開け閉めにはオーバーヘッドがかかる（時間がかかる）ので、まとめて一回でやったほうが効率が良いです。なので、効率性、速度面の観点を含めると、②のほうがよい。ということになります。

では、①は悪いのかというとそうとも言い切れません。処理の途中でエラーが発生し、異常終了した場合、①だと途中までの実施結果はExcelに書き込まれますが、②では途中までの実施結果が書き込まれません。なにを優先するかによって、ケースバイケースで判断することが必要です。

※本例では、②の場合に例外処理をしっかりと設計することで、エラー発生時に途中結果までを書き込むこともできますので、それがベストな設計になるかと思います。

エンジニアからすると当たり前のことですが、RPA開発においても必要なスキルであることが改めてご理解いただけたかなと思います。

以上です。