UiPath (ja) Advent Calendar 2019 13日目の記事です。
今回は、RPA UiPathでの設計のお話です。
Qiita Advent Calendarということで、エンドユーザーである業務担当者がRPAを開発するケースではなく、大企業でRPAの開発保守に関わっているエンジニア向けの記事となります。
元エンジニアで、RPAコンサルタントとして多くの企業にUiPathの導入をしてきた経験を持つプロコアラが解説していきます。
「RPAの保守してますが、障害ばっかで大変。」
「RPAを導入したが、ROIが思ったより良くない。」
こんなことで悩んでいませんか？
その原因は、RPAの設計にあるかもしれません。
今回は、使用しているサービスを切り替えた時に、大工事とならないように「依存関係逆転の原則（DIP）」を使った設計方法について解説します。
サービス切り替えとは、例えば以下のようなものを指します。
・メールをOutlookからGMailに変える
・オンラインストレージをOneDriveからGDriveに変える
この記事を読むことで将来発生しうるサービス切り替えで、大規模な修正とならないようにする方法を学ぶことができます。
さらに、UiPathを用いた具体的な実装する方法を知ることができます。
サービス切り替えで大工事が必要となるケース
例えば、以下のような業務があるとします。
・ストレージ「OneDrive」からExcelファイルをダウンロード
・Webアプリケーションに内容を入力
・Webアプリケーションの結果の一部をExcelファイルに追記
・追記したExcelファイルをストレージ「OneDrive」にアップロード
ダウンロードURL、格納されているExcelファイルが異なるが似たような業務が複数あるとしましょう。
これをワークフローとして実装する場合を考えていきましょう。
・OneDriveのダウンロード先URLを変数に設定
・ブラウザを開く
・ダウンロードボタンをクリック
・Excelファイルのセルを読み込み
・テキストを入力
・OneDriveのアップロード先URLを変数に設定
・ブラウザを開く
・アップロードボタンをクリック
このように考えた人は地獄が待っています。
OneDriveへのダウンロード、アップロード処理は他の業務でも使えるため、共通部品として使えるようにしましょう。
共通部品化するメリット
・同じ処理を実装する必要が無くなり、実装工数削減
・評価工数も削減
・将来URLの変更があった時、共通部品化しておくことで変更箇所が少なくなる。
共通部品化すると、以下のようになります。
・InvokeWorkflow：OneDriveDownload.xaml
・Excelファイルのセルを読み込み
・テキストを入力
・Invoke Workflow：OneDriveUpload.xaml
実はこれでも設計としては不十分です。
ストレージサービスでOneDriveを使用していましたが、GDriveへ切り替えることになった場合に呼び出し処理を全て変更していかなければならないのです。
共通部品を使用している箇所を変更しなければならないため、大変な作業になります。
もしも、設定ファイルをストレージ上に格納して全プロセスが初期化処理でダウンロードするようなケースであれば、全プロセスに修正が必要になるのです。
では、どうしたらいいのか？
原因と対応策を解説します。
原因と対策
ストレージサービスをOneDriveからGDriveに変える際に、呼び出す側を変えなくてはいけない理由は、何でしょうか？
その原因は、上位が下位の詳細を知りすぎているためです。
SOLID原則の依存関係逆転の原則（DIP）というのですが、今回のように将来的に変更の可能性のある詳細は、抽象化して呼び出すべきというプログラミングの原則です。
興味のある人はSOLID原則でググってみてください。
出典：Wikipedia
UiPathでの具体的な実装方法
SOLID原則の依存関係逆転の原則（DIP）を実装する方法を記載した書籍は多くありますが、その多くがオブジェクト指向言語で解説したものです。
UiPathでどのように実装すればいいのでしょうか？
将来的に変更の可能性のある詳細を抽象化して呼び出す方法を解説します。
実装には、以下の3ステップが必要です。
・何のストレージサービスを使用するか定義
・各ストレージサービスの詳細をXamlとして実装
・ストレージサービスを抽象化して呼び出す
何のストレージサービスを使用するか定義
ローカルのConfigを定義したExcelファイルで定義を追加します。
・Key：StrageService
・Value：Box or GDrive
変数でもいいですが、極力ワークフローを変えたくないので設定はファイルに外出ししておいた方がいいと思います。
各ストレージサービスの詳細をXamlとして実装
以下のような構成で各ストレージサービスの処理を実装しておきます。
・GDrive
・Download.xaml
・Upload.xaml
・OneDrive
・Download.xaml
・Upload.xaml
GDrive、OneDrive、Sharepointでも必要な情報はURLとファイル名であるため、引数のインターフェースも共通となります。
ストレージサービスを抽象化して呼び出す
呼び出し側では、以下のようにして抽象化して呼び出します。
InvokeWorkflowアクティビティ：dicConfig(“StrageService”) + “\Download.xaml”
こうしておけば、Configシートを変更するだけでストレージサービスを切り替え可能になります。
将来、Sharepointなど別のサービスに切り替わったとしても呼び出し側は変更不要です。
C言語の関数ポインタのように、ディレクトリを指定して処理を切り替えています。
まとめ
抽象化を使用することで、将来的な工数を削減できることを解説しました。
ストレージサービス、メールなど切り替えが将来発生しそうなものに対しては抽象化しておいた方がいいと思います。
RPAは、よく以下のようにして作られます。
・業務内容のヒアリング
・ワークフローの作成（実装）
危惧すべき点は、設計フェーズが抜け落ちているのです。
RPAで開発を行う人にとっての腕の見せ所は設計です。ここで将来の忙しさが決まるといっても過言ではありません。
設計が無いため評価も不明確になり、評価の抜け漏れが発生してしまいます。
このため、本番環境で障害が発生してしまい、開発者は対応に追われます。
保守工数がずっと減らずに期待していたよりも成果が出ないという事態につながるのです。
RPAはプログラミングの一種だと私は考えています。
ノンプログラマーでも実装できるのですが、どのように設計するかがRPA開発者としての腕の見せ所です。
良い設計は、将来の自分たちの仕事を楽にします。頑張りましょう。
次回は自動化テストの方法とテストしやすい設計について解説します。
RPA、UiPathについて動画形式で学べるコアワカのUdemy講座を
いつでもお得な価格で受講できるクーポンを発行しています。
研修にも使用できる書籍もこちらから購入が可能です。
動画を受講したい場合はボタンをクリックしてください。
クーポンコードが適用されたUdemyコースのリンク一覧ページに移動します。
