ページの本文へ

Hitachi

RPA業務自動化ソリューション RPA業務自動化ソリューション

RPA業務自動化ソリューション 【コラム】RPA専門家に聞いた! ニューノーマル時代のRPA×テレワーク活用のための課題とは

RPAに起こりがちなエラーは「例外」と「変更」。
その原因と対策をRPAのプロが解説

新型コロナウイルス感染拡大の影響でテレワークが増加してから、ソフトウェアロボットによって業務を自動化させる“RPA”の活用が注目されています。しかし残念ながら、「RPAを導入したら、業務が自動化されて楽になる!」と期待して実際にRPAを導入した企業の、課題になってしまいがちなのが、RPAがちょっとしたトラブルで止まりやすいこと。

「思うように動かない」、「動いてもエラーが出て止まる」……。そんな悩みを抱えている方は少なくないのではないでしょうか。そこで、“RPAの専門家”である、株式会社完全自動化研究所の代表取締役社長 小佐井 宏之さんに、その原因と対策について解説していただきました。

小佐井 宏之 氏の写真

株式会社完全自動化研究所 代表取締役社長

小佐井 宏之 氏

京都工芸繊維大学同大学院造形工学専攻修士課程修了後、客先常駐のプログラマーとしてエンジニア人生をスタート。小売企業の情報システム部に所属後、2010年に個人事業主として独立。2017年に株式会社完全自動化研究所を設立。RPAシステムを構築するためのコンサルティング支援やセミナー講師などを行っている。

著書:『オープンソースで作る!RPAシステム開発入門』『UiPath業務自動化最強レシピ RPAツールによる自動化&効率化ノウハウ』(以上、翔泳社)、『実務者のための失敗しないRPAシナリオ設計入門』(秀和システム)

RPAがよく止まる……その原因はハードウェア・ソフトウェアによる「例外」と業務や成果物の「変更」

RPAがよく止まる……その原因はハードウェア・ソフトウェアによる「例外」と業務や成果物の「変更」

RPAがよく止まる原因は、大きく分けて2つあります。それはパソコン環境に変化があったことで起こる「例外(エラー)」と、業務上起こりうる「変更」によるものです。

例外は、「ハードウェア原因」か「ソフトウェア原因」かに分けられる

例外は、RPAがインストールされたパソコンのハードウェアが原因で発生している場合と、RPAが操作対象とするアプリケーションなどのソフトウェアが原因で発生している場合に大別できます。
ハードウェアが原因で例外が発生するケースとしては、たとえばRPAをインストールしたパソコンが故障したり、パソコンの性能が十分でなく止まってしまった、という状況が考えられます。こちらはシステム部門に依頼してパソコンを修理してもらったり、性能を上げてもらったりすることで、ほとんどの場合は解決します。

ソフトウェアが原因で例外が発生するケースとしては、「RPAが操作対象とするユーザーインタフェース(画面)内のボタンの表示などの仕様が変更される」、「ダウンロードするファイルの拡張子が変更されている」など、さまざまなケースが考えられます。これらの変更は事前通知がないことが大半で、防ぐことが難しいものです。しかもとても細かい変更であることも多く、突き止めるのに苦労します。

変更は「業務手順の変更」「成果物の変更」が考えられる

一方の変更は、「業務手順」もしくは「成果物」の変更が考えられます。
業務手順の変更とは、たとえばデータの取得元を既存の基幹システムから新しいクラウドシステムに変更する、というようなケースが該当します。
成果物の変更とは、たとえば売上集計表に「前年度の売上と比較できるようにしてほしい」との要望があったため、前年同月の売上と前年比率を付け加える、というようなケースが考えられます。
業務手順の変更や成果物の変更に伴って既存のRPAのシナリオも修正しなければなりませんが、修正時にはミスが起きやすいものです。最初にシナリオを作成するときは、手作業で行っていた業務を手本にしますが、変更時は手本が無い状態になるからです。
また、元々は正しく動作していたシナリオを誤って修正してしまう、といったミスも発生しがちです。

ただし、これら「例外」や「変更」に伴うエラーはRPAに限ったことではなく、ITツール全般に起こりやすい問題です。そこでRPAに限定して止まる原因を見てみると、3つの要因が見えてきます。

RPAが止まりがちとされる3つの要因

1.インターフェースを操作することが多いRPAは、SaaSアプリのアップデートの影響を受けやすい

クラウド系のSaaSアプリを使っていれば、そのユーザーインタフェース(画面)は都度アップデートがかかります。RPAでは「インターフェース上の操作を模倣する」というシナリオが多いため、インターフェースに変更があった場合はエラーが発生することがあります。

2.RPAに不慣れなユーザー部門(現場)の人為的ミス

実際にRPAを利用して業務を行うのは現場のユーザー部門であることが多いです。そのためExcelやCSVファイルを柔軟に活用して、ユーザー部門が使いやすいシナリオを作成します。
ユーザー部門側はITシステムに精通しているわけではないため、RPAシナリオの実行に必要なExcelの商品マスタなどのデータの一部を削除してしまったり、エラーが起こる特殊文字などを入れてしまった、という人為的ミスが起こりがちです。

3.システム開発の経験者が少ない担当者によって作成された、例外・変更に弱いシナリオ

RPAのシナリオはシステム開発に詳しい人が作成するのがもちろんベターですが、人員不足や業務をよく知っている人が作った方が良いなどの理由のためユーザー部門がシナリオの作成を行うことが多いです。当然ユーザー部門にはシステム開発の経験者が少ないため、上記で挙げたような例外・変更に対応できるシナリオを開発することは難しいでしょう。

RPAを利用していくなかで、これら「例外」と「変更」が原因によるトラブル発生はつきものです。だからこそ、ヘルプデスク体制を整えたり、システム運用管理ツールなどを利用して、エラー発生時にも速やかに対応・対処ができるような運用体制を整えることが重要です。

最初のシナリオ設計が肝心!RPAが止まらないようにするための対策方法を伝授

最初のシナリオ設計が肝心!RPAが止まらないようにするための対策方法を伝授

RPAやシステムに関する専門知識の少ないユーザー部門の担当者が、最初からRPAを適切に使いこなすことは困難でしょう。そのため、利用する前に、できるだけRPAのことを“学習”しておくことが大切です。

ここでRPAが止まらないようにするためのポイントを、5つ挙げます。

1.最初のシナリオ作成時に、「例外処理」ができるよう組み込む

エラーを想定して、最初のRPAシナリオ作成時に「例外処理」をきちんと組み込むこと。通常とは異なる例外が起きたときにも業務に支障をきたさないよう処理ができるようにします。

2.利用するデータをシナリオと別ファイルにまとめる

シナリオを書き換えなくても変更に対応できるように、変更される可能性の高いパラメータ(RPAに利用するデータのこと。たとえば、「利用するクラウドシステムのURL」や「利用するExcelファイルのパス」など)を設定ファイルとしてシナリオとは別ファイル(Excelなど)にまとめ、変更のたびにシナリオを書き換えるのではなく、設定ファイルのみの変更で済むように設計しておきます。変更に強いシナリオにする必須技術です。

3.最初のシナリオ作成時に、同様の処理ができるところはなるべく「共通化」

RPAの開発時に「特定のシステムにログインする処理」など、同様の処理が各所に存在する場合は、共通化(同じ処理があったときに複数の箇所から利用可能にする)すること。変更可能性の高い処理を共通処理として一元管理できるようにしておくと、一か所変更するだけで全シナリオに容易に変更が反映できます。これも変更に強いシナリオにする重要な要素です。

4.シナリオを適切な単位で分割する

処理の長い複雑なシナリオは適切な単位で分割し、別々に実行できるようにすることで、柔軟に運用できるようになります。RPAが止まった場合も例外発生個所を特定しやすく、復旧後の再実行箇所も限定できます。これにより「一つでも例外が発生したら、最初からすべてのシナリオを再実行しなければならない」といったムダな工数を軽減することができます。

5.分割したシナリオを統合運用管理ツールなどで管理しておく

分割したシナリオをRPA製品に対応した統合運用管理ツール(プログラムやバッチ処理の実行などジョブを統合管理するツール)で管理することで、「複数のシナリオを連続して実行する」「エラーのあった箇所からリカバリーする」などの柔軟な運用が可能になります。なお、RPAのロボットだけでなく、クラウドサービスも含めて業務プロセス全体を自動化する場合はiPaaS(Integration Platform as a Service:複数のクラウドアプリケーションや業務システムを統合し、データ連携を実現するサービス)という選択肢もあります。

5つのポイントを挙げましたが、最初からすべてのポイントを踏まえて、RPAを利用することは少しハードルが高いかもしれません。また、中にはRPA導入の初期段階から取り組んでおかないと、あとになって改修することが難しいポイントもありますので、早い段階で外部のSIerなどが提供する運用支援サービスを利用することも1つの方法と言えます。

ユーザー部門がRPAのエラー対応に必要なのは、「原因の切り分け」ができるスキル

RPAを利用する際は、現場のユーザー部門とシステム部門が連携する必要があります。RPAを利用するのはユーザー部門であっても、ネットワーク上のフォルダーへのアクセス権がなかったり、自動化する対象のアプリケーションのログイン権限がなかったりするケースがあるため、システム部門と相談しながら環境を整えることになるからです。

トラブルが発生した際は「原因の切り分け」が非常に重要になります。最初に確認するのは、冒頭でも挙げた通り、トラブルが「ハードウェアに起因するか、ソフトウェアに起因するか」をチェックすることです。たとえば、パソコンの故障(ハードウェアの問題)であればシステム部門に頼ることになりますが、ソフトウェアのバージョンアップなどが原因で動かない場合は、RPAシナリオを修正する必要があるため、多くの場合はユーザー部門側で解決法を探ることになります。

ただ、この「原因の切り分け」は、専門知識がなければ難しい面があります。そこで、RPAを利用する立場であるユーザー部門に「原因の切り分け」ができる人材を育成、または配置することが必要です。
このような人材を配置することが難しい場合、統合運用管理ツールを利用して自動的にログを収集し、システム部門に管理してもらって原因の切り分けをお願いしたり、RPA運用管理における外部パートナーの知識を頼ったりすることも考えられます。
なお、RPA製品の中にはエラーハンドリングに対応するアクションを用意しているものもあり、エラー発生時の対応を柔軟に設定することも可能ですので、製品の選定も重要と言えます。

まとめ:RPAのエラーを防ぐには、例外・変更に強いシナリオ作成と人員配置がカギ

RPAを止まりにくくするには、「例外・変更に強いシナリオの作成と、トラブルが発生した時に原因の切り分けができる人材の配置」が必要なことがわかりました。次の記事では、「テレワークを導入したくても、社内でしか対応できない業務があるから難しい……」とお悩みの方に、解決するためのヒントを紹介していきます。

関連するお役立ちコンテンツ

RPAに関することなら
日立ソリューションズに
おまかせください

WEBからのお問い合わせ
RPA製品・ソリューション 資料請求・お問い合わせ
資料請求・お問い合わせ

Tagで絞り込み

閲覧数が多い記事

RPAに関することなら
日立ソリューションズにおまかせください

見積依頼、製品・ソリューションへのご質問
見積もり依頼、RPA製品・ソリューションへのご質問
お問い合わせ
製品・ソリューションカタログ
RPA製品・ソリューションカタログ
ダウンロード
RPAに関するセミナー・展示会情報
RPAに関するセミナー・展示会情報
イベント情報を確認
ページTOPへ
メニュー
ページの先頭へ