業務自動化のギャップを回避するための確認事項

RPAツールで業務自動化する際に発生するギャップについて

　RPAツールを活用した業務自動化は、作業の効率化であったり、ミスの防止だったりと使いこなすことで一つの業務だけに留まらず全社へ良い影響をもたらしてくれる可能性があります。
　しかし、いざRPAツールを導入し、業務を自動化しようと取り組んだ際、思ったように開発がうまくいかなかったり、安定して動作しなかったりと想定していた効果とのギャップが発生することがゼロではありません。
　本記事では、UiPath開発者目線から、そういったギャップを未然に防ぐための確認事項を載せていきます。

 

何がギャップとなるのか

　RPAツールを導入する際に発生するギャップは、主に「実運用でのギャップ」と「開発時点のギャップ」が挙げられます。
　実運用でのギャップとは、RPAツールでの開発を完了し実際に運用するとなった段階で「エラーが頻発してしまう」「想定よりも削減工数・時間が少ない」形になり、思っていたような効果が見込めないことを今回は指しています。また、エラーが頻発してしまうとその分改修のための時間が発生したり、業務が停止してしまったりと作業の遅延に繋がってしまいます。
　開発時点でのギャップは、「開発工数が想定以上にかかる」「RPAツールでの実装が難しく、想定通りの実装ができない」ことが考えられます。前者の場合は、既存ツールとの相性や、テストケースの有無などが原因として挙げられます。
　これらは全て事前の確認とすり合わせで防げるギャップです。いざ業務自動化となった際、思っていたものと違う、と開発者や業務担当者が感じてしまうことを避けるためにも事前準備は怠らないようにしていくことが基本となります。

 

初めに業務整理を行うメリット

　RPAツールを導入して、現行の業務をそのままRPAに落とし込もう、という考えは想定よりも工数、時間の削減効果をもたらさない可能性があります。
　まずは現在の業務手順を振り返り、自動化するにあたって「その作業は必要か？」を確認していくことをおすすめします。例えば、従来は外部ツールから出力されたExcelファイルを印刷用に整形してから人の手で作業を行っている、といった作業があるとします。この人の手で行っている作業の部分を自動化するのであれば、外部ツールから出力されたExcelファイルをそのままRPAツールで利用すればよいため、Excelファイルの整形は不要となります。Excelファイルを整形する分の作業時間も、RPAツールで整形したExcelファイルを作成する必要もなくなるとなれば、開発工数も削減が可能です。
　また、分岐が細かくRPAツールでは対応し難い箇所や、ツールやファイルの形式が他と大きく異なる箇所、もしくは非常に稀な処理パターンといった、従来でも作業工数の大きくかかっていない箇所で、RPAツールでの開発に大きく工数がかかってしまいそうな箇所は最初から人の手で対応する例外パターンとすることで、開発にかかった時間と実際の削減時間のギャップを埋めることができます。
　より短時間で開発できるようになることで、RPAツールの実運用化が早められる効果も期待できます。

 

外部ツールが利用できるアプリケーションか

　例えば在庫管理であったり、顧客管理だったりといった業務を行う際に自社で開発しているアプリケーションを使用している場合があるでしょう。その場合、確認するべき最初の観点は「そのアプリケーションがRPAツールからの操作を受け付けているか？」です。アプリケーションによっては、管理者権限を持つ担当者のように、特定のユーザによってアクセス権を付与してもらわないと外部ツールから操作できない場合や、アプリケーション側の設定を変更しなければならない場合があります。どちらの場合でも、セキュリティの観点などから社内での確認と承認が必要になるでしょう。承認に時間を要する可能性もあるため、先んじての確認は開発工数のロスタイムを防ぐことにもつながります。
　また、操作が可能な場合でも「セレクタはユニークな形で取得できるか？」は安定稼働において重要な観点となります。入力欄やボタンなどのセレクタが一意の値を持っておらず、類似の項目が複数あったり、ページ更新ごとに数値の変わる値を持っていたりすると、RPAツールで選択するべき箇所が見つからずエラーとなる可能性が高くなります。

 

Excelの書式は適切か

　以前に「DataTable型で取得できないExcelファイルをUiPathで自動化する方法」の記事でも前提として記載いたしましたが、Excelファイルの記載形式はRPAツールの安定稼働に大きな影響を及ぼします。
　まず、所謂「Excel方眼紙」と呼ばれるような形のExcelファイルはまず間違いなくRPAツールでの自動化に不適切です。この書式を利用しているExcelファイルに対して業務自動化を行いたい場合、まず前述の業務整理を行う段階で、「本当にこの形式でないと業務に支障が出るか？」を確認してください。実際の業務では、複数の部署で同じExcelファイルを利用しているケースもあるため、完全にExcelファイルの形式を変更することは難しいかもしれませんが、ある程度はRPAツールで取得できるような形にできることが望ましいです。
　また、もし表形式になっている場合でも、ヘッダー行の記載方式によってはやや安定性に欠ける可能性があります。ヘッダー行に改行が含まれている場合、DataTable型で表の値を取得した後に使いたい行の特定に手間取る可能性があります。加えて、ヘッダー行に同名の列が含まれているとエラーになることがあるため、こちらも推奨されません。
　Excelファイルを使用する場合は、必ず表形式で、かつヘッダー行は全て重複せず改行も含まない形のファイルにすることを心掛けるとRPAツールの安定稼働に繋がります。
　また、これらの形が含まれているファイルの場合開発に想定以上の時間がかかる可能性もあるため、そちらの観点からもExcelファイルの形式はしっかりと確認してから業務自動化に踏み切りましょう。
　実際、ExcelファイルがExcel方眼紙かつ完全に統一されていない書式が業務利用されている部署へのRPAツール導入では開発工数、エラー原因特定に時間がかかった経験もありますので、こちらはなるべく事前に解決しておきたい問題です。

 

人の手による承認作業は不要か

　作成された書類の内容チェックや、アプリケーション上での続行可否などに対しての承認のように、作業途中で人が承認する必要のある業務はRPAでの「全自動化」に不向きです。承認とまではいかずとも、人が手で作業しなくてはならないものは基本的に「全自動」には出来ないものと考えてよいでしょう。あくまでも「全自動」が不向きというだけなので、もちろん途中途中で中断を挟むような仕様にすれば自動化は可能です。ただ、そうなると人の手による工数は減らないことと、RPAツールで作成された成果物に対しての確認時間が発生するため、思っていたよりも作業時間が削減されない、というギャップが発生する可能性があります。
　作業途中で人の目で確認したい、承認してから次の処理に進みたい、といった場合、UiPathであればUnattended RobotではなくAttended Robotのライセンスを利用することが望ましいです。Unattended Robotは、UiPath Orchestratorから自動でシナリオを開始し、完全に無人で運用することが可能ですが、その分ユーザの入力、操作を待つ業務には不向きです。UiPath Assistantから手動で開始するAttended Robotは、ユーザが使用しているPCを占有してしまうため実行中に他の業務ができないというデメリットこそありますが、このようにユーザのアクションが必要な業務ではこちらのライセンスを使用する形が一般的です。
　もしくは、作業の最後だけ確認が必要な場合はそこまでをRPAツールで実装して確認待ち状態にする、など工夫することで自動化が可能です。ServiceNowなどと連携している場合は、ServiceNowのステータスを変更することで後続処理に繋げる、といった方法も可能でしょう（この場合、ServiceNow側の動作変更が必要になるためServiceNow開発担当者ともすり合わせが必要となります）。

 

Webサイトのセレクタは頻繁に変更されないか

　例えば経費計算など、Web上で検索した情報を取得して自動化に利用したい場合ではWebサイトのUIが頻繁に変更されることがないか確認する必要があります。頻繁にUIが変更されるサイトの場合、UIの変更に伴ってRPAツールで使用していたセレクタの情報も変更になっていることがあります。そうなった場合、シナリオを実行した際にセレクタが見つからずエラーとなって実行が停止してしまう原因となります。
　どうしてもそのWebサイトを利用する必要がある場合は、定期的にシナリオをメンテナンスするか、アンカー機能などを利用してなるべくWebサイトの更新時にセレクタが正しく取得できる状態にしておくことがベストでしょう。
　一点、前提の注意事項として、WebサイトによってはRPAツールでの操作やスクレイピングを完全に禁止しているものもあります。Webサイトの利用規約を確認してから自動化対象にするか判断しましょう。

 

分岐は複雑すぎないか

　「値がAであればA処理に進む、BであればB処理に進む」といったような単純な分岐であれば問題ありませんが、「値がAかつ■の箇所が①の場合、次のBの処理を実行する・ただし■の箇所が②であればAに戻る」といったような分岐がそれぞれに複数発生してくると、その業務は自動化には向かないことがあります。あまり多くの分岐があると、RPAツールで条件を判断する際に時間がかかったり、実装が困難になり部分的にしか自動化を実現できなかったりとギャップが生まれる原因となるため、想定よりも開発や実行に時間を要してしまうことに繋がるからです。
　また、このパターンでは開発担当者が別に存在する場合に、業務担当者と開発担当者の間での連絡が往復して要件のすり合わせに時間がかかる可能性もあります。業務担当者の間では当たり前となっていることも細かく条件として洗い出す必要があるため、開発担当者への連携時点で抜け漏れが発生して追加改修が発生する可能性もあります。
　分岐先のパターンによっては発生頻度がごく稀なこともあると思いますので、そういった場合は前述のように「当該分岐の場合は例外処理として人の手で処理する」方法を視野に入れることが望ましいでしょう。

 

テストケース・テスト環境は存在するか

　前述したように、既存で自社開発のアプリケーションやWebツールを使用している場合、当該ツールにテスト環境が存在するか、もしくは本番環境でもRPAツールの開発及び試験段階で使用しても問題ないかの確認が必要です。同様に、セレクタの取得や試験のために使用できるテストケースも必要となります。テストケースがない場合、常に実運用で使用するデータを必要とするため、実作業がないと開発や試験の作業が進められない状態に陥り開発工数が無駄になるリスクがあります。
　また、テストケースを用意する場合は想定される分岐に則したパターンが揃っていることがより望ましいです。一パターンで開発、試験を行って成功しても、別パターンのデータで実行したら他の入力欄に値の入力が必要で開発が手戻りになったり、試験時にエラーとなって修正が発生したりと問題になる可能性があります。また、本来あるべきケースの抜け漏れにもつながる可能性があります。

開発チームとの擦り合わせは重要

　上記のギャップ要因は、基本的に仕様面での注意事項となります。業務担当者が自らRPAツールを開発してシナリオを作成する場合は、業務の手順やツールの使用方法、注意事項が頭に入っているので、それぞれの確認事項に気を付ければギャップを抑えることは可能でしょう。ですが、開発チームが別にいる場合、細かい分岐や外部ツールの仕様を正しく伝えないと想定通りの仕様にならなかったり、追加のすり合わせが発生したりと結果的に工数が増える原因となります。
　RPAツールでは、クリックの一つ一つから細かく作業手順を洗い出す必要があります。業務担当者には当たり前の手順でも、改めて開発チームに説明すると細かい条件などの考慮漏れや伝達漏れが発生する可能性もあります。操作画面のスクリーンショットを順番に貼り付けて簡単な説明文を添えただけの簡易なものでもよいので、業務手順書を用意しておくことがスムーズな要件定義、仕様のすり合わせに役立ちます。
　また、各打ち合わせでの決定事項や注意事項は資料としてまとめておくことで、実装時の抜け漏れや、開発工数の都合で後から実装しようとした箇所の伝達漏れが防げるため簡単なメモでもよいので残しておきましょう。当然ながら、伝えたことの証拠も残りますので、再説明の手間だったり、言った言わないの議論になったりすることも回避できます。

まとめ

　折角コストをかけてRPAツールを導入しても、想定通りの効果が出ないと無駄になってしまいます。事前に業務を整理して、使用するツールやWebサイトの仕様を確認し、開発チームと綿密に相談することで、「想定よりも効果が出なかった」「開発時に想定していた自動化対象箇所が対象外と判定されてしまった」というギャップはかなり防ぐことが可能になるでしょう。
　以下に、ここまでの確認事項を図でまとめたものを掲載します。

　本記事が、これからRPAツールを導入していきたいとお考えの方にとっての一助となりましたら幸いです。

 

• 【UiPath Orchestrator】少ない工数でロボットを安定的に運用するための管理ツール