UiPath (ja) Advent Calendar 2019 21日目の記事です。
今回は、RPA UiPathでの工数削減を行うための設計のお話です。
Qiita Advent Calendarということで、エンドユーザーである業務担当者がRPAを開発するケースではなく、大企業でRPAの開発保守に関わっているエンジニア向けの記事となります。
元エンジニアで、RPAコンサルタントとして多くの企業にUiPathの導入をしてきた経験を持つプロコアラが解説していきます。
「RPAを導入したが、ROIが思ったより良くない。」
RPA企業の導入に失敗している企業から、よく聞く話です。
私は、ある大企業からこのような相談をされたときにRPA開発現場を訪問させていただきました。
ルールも無く無秩序に作られている自動化処理。
本番環境で障害が発生して無数のエラーメールが飛んでいます。
RPAの自動化処理をメンテナンスするシステム会社のエンジニアが常駐しており、人海戦術でエラーに対処しているという状況でした。
業務担当者の負担は減っているかもしれないが、RPAを保守するエンジニアに負担が移っているだけではないのか？
私はRPAは導入するなと言っているのではありません。RPAを導入した経営陣に非があるわけではありません。
RPAを作成するエンジニアは、最初に考えてワークフローを作らないと将来とんでもない目に合うということを考えておかなければなりません。
ユーザーにヒアリングした業務プロセスをそのままワークフロー化することが、システム会社のRPAエンジニアが行う業務ではありません。
それであれば、業務担当者ができる仕事です。
RPAで業務を自動化するワークフローを作成するエンジニアは、設計が求められます。
・データをどのようにどのように持つべきか？
・どの単位でXamlファイルに分割すべきか？
「忙しくて、設計なんてしてられねーよ！」
卵が先かにわとりが先か、設計をしないから忙しくなるのです。
いい設計で作れば、長期的に見て工数は削減できます。
今回は、長期的に工数を大幅に削減できる自動テストの設計方法、UiPathでの実装方法を解説していきます。
この記事を読むことによって、障害対応に追われる日々から抜け出すことができると思います。
RPA設計時に考えるべき将来の変更リスク
設計で考えるべきことは、将来の変更リスクをどのように対処するかということです。
RPAは他のプログラミングに比べて処理は少なめ。
長期的に運用されることが多い。
このため、将来的に変更のリスクを抱えている。
将来的に起こりうるリスクとして代表的な3つを紹介します。
・UIの変更
・業務内容の変更
・使用しているサービスの変更
UIの変更
Windows Update、OfficeのUpdateによりUIが変わることがあります。また、使用しているシステムのVer.upによりUIが変わることもあります。
UIがどのように変更されるかは分かりません。よって事前に変更が起きても動作する処理を作ることはできません。
重要なことは、以下の2点です。
・UI変更によってどのUI操作が動かなくなるのか確認できること。
・UI変更により動かなくなった処理を簡単に修正できること。
業務内容の変更
業務内容は、日々変わっていきます。
例えば、売り上げが上がったからチラシの配布頻度を2倍にするなど。
重要な点は、変わりそうなものはワークフローから外に出してConfigファイルなどに格納しておくことを考えておくことです。
また、評価をしやすいようにビジネスロジックをUI操作処理から切り離しておくことが重要です。
こうしないと、評価の効率が下がります。
・今日はシステムが使えないから評価できない
・システムからデータを取ってくるまで10分くらいかかる
使用しているサービスの変更
ストレージサービスをGDriveからOneDriveに切り替える。メールをOutlookからGMailに切り替えるなどの変更が起こる可能性があります。
このような場合は抽象化しておくことで、呼び出し側を変更せずにできます。
https://koawaka.com/rpa-school/uipath-design-dip
設計のベストプラクティス
変更リスクから、どのように設計すべきかをここで整理します。
UIとビジネスロジックを明確に分けておく
UIとビジネスロジックを明確に分けます。
こうしておくことで、UI変更時にはUIだけを評価でき、ビジネスロジック変更時にはビジネスロジックだけを評価することができるようになります。
こうしないと、もし動作しなかったときに何が動かなかったかあたりをつけるのが難しくなるのです。
変更発生時に修正箇所が少なくて済むように共通部品化しておきます。
サービスが切り替わる可能性があるものは、抽象化して呼び出すようにしておく方がベターです。
Xamlはテストしやすい単位で分割する
Xamlはテストしやすい単位で分けます。
Xamlは、他のプログラミング言語でいうと関数に当たります。
引数と戻り値を設定することができるため、複数のテストパターンを作って呼び出すには最適な処理単位です。
Xamlは、機能単位で分けた方がいいでしょう。
Loginする処理、ページ遷移する処理、データを加工する処理。
こうすることでテストしやすくなります。
引数としてこの情報を入れたときに戻り値としてこのように変えるはず。
例えば、ユーザー名とパスワードが正しい場合はログインできたのでOKを返す。
誤ったパスワードを引数として渡した際はログインできないためNGを返す。
UiPathでの具体的な実装方法
UiPathでの具体的な実装方法に入りたいと思います。
以前はVisual Studioでカスタムアクティベティを作成する必要がありました。この方法では作成する人も限られ、保守も難しくなっていました。
現在はライブラリプロジェクトを選ぶことによって、簡単にカスタムアクティビティを作成することができます。
パブリッシュすることによって、簡単にカスタムアクティビティを管理することができますので、もしバグがあったとしてもバージョンアップすることによって使用しているワークフローに簡単に適用できます。
Xamlを呼び出すテストフレームワーク
テストフレームワークはUiPath Goで公開されている「UiPath Testing Framework」がおすすめです。
まとめ
UiPathでの自動化テストのしやすい設計と実装方法を解説しました。
対抗システム毎に共通部品をライブラリプロジェクトで作成して、自動テストできる環境まで事前に提供しておくことで将来的な工数を削減できます。
自動テストを作っておくことにより、何らかの修正を行った際に他の機能が動かなくなるケースを防止することができます。
RPAを導入しているシステム会社を多く見てきていますが、設計書を作っていないシステム会社もあります。
設計書が無いから何をテストするかもあいまい。動いたから良しみたいになっているから驚きですよね。
RPAは業務を効率化する素晴らしいものです。
EUCでRPAを広めるためにRPAは簡単であるべきですが、そこを取りまとめる人はRPAをプログラミングであると認識して、設計をする力を持っているべきだと考えています。
RPAを導入するエンジニアが、効率化しなくてどうするんですか？テスト自動化してよりクリエイティブな業務をエンジニアも行いましょう。
RPA、UiPathについて動画形式で学べるコアワカのUdemy講座を
いつでもお得な価格で受講できるクーポンを発行しています。
研修にも使用できる書籍もこちらから購入が可能です。
動画を受講したい場合はボタンをクリックしてください。
クーポンコードが適用されたUdemyコースのリンク一覧ページに移動します。
