今回はRPA導入についてのリスク(※)について、洗い出し方の説明と具体的な例をあげて気を付けなくてはいけない点を説明していこうと思います。今後ユーザがよりローコード、ノーコード開発への参入が活発化してきた際に、リスク対策を講じていないと、セキュリティ事故等の大きな問題に繋がってしまう可能性があります。
※リスク･･･将来のいずれかの時において何か悪い事象が起こる可能性と影響
この記事でどういう事に気を付けなくてはいけないのかを知って頂き、各自がリスクに対して意識しながら、開発やロボットの実行をして頂ければと思います。リスクは存在を知り、適切に事前対策を講じておけば、重大な問題発生までは防いでいく事ができます。
【目次】
RPA導入でのリスクとは
リスクとは、冒頭で注釈している通りのもので日本では「危険」や「危機」という意味で使われている事が多い言葉です。RPA導入でのリスクというのは、RPAを開発、利用していく際に発生する「危険」や「危機」というものです。これまでのシステム開発はITの前提知識を持っていなければ、開発する事が難しかったですが、開発自体が簡略化される事により、前提知識がない人でも開発自体ができるようになってきています。こちらに関して開発への敷居が下がったと同時に、開発や利用時に起こりうるリスクの一部分の発生確率が高まっていると考えています。怖いと思う方もいるかと思いますが、正しい基礎知識を身に着け、気を付けるべき事に気を付けていれば発生確率を下げる事ができますので、ここのポイントについて学んでいきましょう。
RPA導入でのリスクの大項目
RPA導入のリスクはどのようなものがあるかの概要について、説明していこうと思います。世間でよく言われているリスクは下記の通りです。
〇業務がブラックボックス化するリスク
自動化前で完璧な業務フローと業務手順書が揃っている場合は良いですが、自動化対象の業務フローや手順書が不十分な状態でRPA化をした場合は、担当者の異動や退職により、将来業務の知見を持っている人がいなくなった時に問題が発生します。再度業務の見直しが必要になったり、人手で対応しないといけない状態になったりする際に、業務を知っている人がおらず、ドキュメントもなくRPAのプログラムから業務把握を行わなければならないという事態になってしまうリスクがあります。そうならないようにドキュメントをしっかり整備しておく対策が必要になります。(RPAのプログラムを見て万事の際は人手でも対応できる体制であれば、ドキュメントはそこまで力入れなくても大丈夫なケースはあります)
〇不正使用や誤った利用により情報が漏洩するリスク
RPAが各システムにログインする用のIDやPWを悪意のあるものに利用されてしまったり、RPA利用自体を不正な処理に使われたり、誤った相手に重要な内容を誤送信してしまったりするリスクです。こちらはIDとPWは全員が見えないように権限を絞った場所で利用するか暗号化するかして対応する事ができます。RPAを開発できる人は知る術を持っているので、誰が不正利用したか追えるようにより厳重にする場合はアクセス履歴から追える仕組みを構築したりする必要があります。RPAが使うアカウント情報(ID/PW)と業務担当者が使うアカウントが同じである場合、RPAによって操作されたものか、業務担当者によって操作されたものか判別が難しかったり、共有IDを作ると誰が共有IDを使って、操作したか対策をしっかりしないと問題になる事があるため、情報システム部門とアカウントの運用ルールは相談する事が必要です。
〇RPAで誤作動を起こすリスク
RPAを誤って実行してしまい、2重でデータを登録してしまったり、開発環境向けの作業を誤って本番環境向けに動かしてしまったりして問題がおきるリスクです。RPAの開発では連携システムへの本番環境へ影響を与える事が多いため、ここはかなり気を付けておかなければいけないリスクです。本番と開発で切り替えした後に動かす際は動かしたい対象のURLや設定内容になっているか、指差し確認をする等動かす人が注意を払っておく事が重要です。
〇RPAの誤った処理に気づけないリスク
テストで全バリエーションを実施しなかったり、テストの時に誤りを見逃してしまっていたりして、RPAが誤った処理を実施していても気づけないリスクです。RPAが処理した結果をRPA処理後の方で誤りに気付けるような仕組みになっていない場合は、正しい動きができているか念入りに確認をする必要があります。ミスが許されないような業務は想定されるパターンが全て対応できているか本番で確認できるまでは結果を確認しておくことをお勧めします。更新や登録処理はボタンを押した後に、エラー画面に遷移したり、エラーメッセージが表示される可能性がないか絶対気にしてください。処理は正常に終わったのに、登録できていないとかが起きてしまいます。
〇RPAが動かなくなるリスク
このリスクはRPAが動かなくなってしまうというリスクです。RPAは画像やプログラム認識を作成された順番通りにしか動く事ができませんので、処理対象の見た目やプログラム内容が変わったり、処理途中に操作が増えたり(セキュリティポップアップ等)、処理が遅延してタイムアウトしてしまったりすると止まってしまう事があります。止まってしまった時どうするかを予め考えておく必要があります。自社内のシステムの場合は変更を気付けるようにシステム変更時にRPA利用チームに連絡がいくようにすると急に止まるリスクを軽減する事ができます。稀ですが端末やサーバが故障してしまい動かせなくなるリスクも存在しています。
〇野良ロボットの発生リスク
どこの場所でどのようなロボットが使われているか、使っていないか把握できなくなり、不要なライセンス費用を払い続けてしまったり、リスク対策の対象から漏れてしまったり管理上問題となってしまうリスクです。こちらは各RPA製品のサービスである管理サーバや個別の管理台帳にどこで利用できる環境が揃っているか、利用されているか定期的に確認することで防ぐ事ができます。
概要だけでは理解し難い部分もあると思いますので、実際のリスクの発生事例を次に見ていきましょう。
リスク発生事例
<ケース①：本番のデータを誤って更新、削除してしまった>
こちらは本当に起こりやすく影響の大きいものになっており、幅広い人が注意しなくてはならないものです。自身が開発中に動かした時に誤ってRPAにより更新や削除してしまう事もありますが、誰かが作ったロボットの引継ぎを受けて理解できていないまま実行して、問題を起こしてしまう事もあります。このリスクへの対策で有効なものは2つ。1つ目は更新や削除等周りに影響を与える処理がどこにあるか、必ず気にして対応する事。2つ目は自分が理解できていないコマンド等の箇所が登場した際、必ずどのような事がされるか調べる事。自分がこれから動かそうとしているものが、操作の結果周りにどんな影響を与えるか理解する事が重要です。開発経験者はデータが消えてしまう事件等を近くで見ている人が多いため、このような点には常に細心の注意を払っています。そのためこのリスクを発生させない事ができるのです。皆様もここは常に細心の注意を持って頂ければと思います。(本番というのは開発やテスト環境ではなく、実際の業務で扱っている環境やシステム、ファイルの事です)
<ケース②：誤った宛先にメールやチャットを送信してしまった>
こちらは外部の宛先も絡んでくる場合、非常にリスク影響が高いものとなります。高すぎるためにメールやチャットの送信をRPAだけで完結するのはルールとして禁止している企業がある程です。もし仮にRPAで送信を試みる場合は、チェック機能(アドレスチェック等)を合わせて実装する事でリスク発生確率を下げる事ができますのでチェック機能を搭載させることをお勧めします。
<ケース③：誤ったバージョンをリリースしてしまった(デグレ)>
こちらもよく発生するもので、幅広い人が注意しなくてはならないものです。どこに最新の資源を配置してどこに過去のバージョンを管理するかのルールを決めて、決められた箇所で決められた運用を徹底していく事が重要です。複数人が同じ資源を修正したりし始めるとこのデグレのリスクは人数に比例して高まります。共通ルールの認識を持つか、どうしてもデグレの発生率を抑える事ができなければ、バージョン管理システムの導入を検討しましょう。(但し、このシステムを扱うための運用ルールを決める必要もあります)
<ケース④：実行するロボットやプロセスを誤ってしまった>
同じ端末に複数プロセス選択できるようになっていたり、管理サーバから実行できるようになっていたりする場合、実行する対象を誤ってしまうリスクがあります。実行時は間違うと問題おきてしまう可能性があると意識して、集中する事と実行対象の名称を間違いにくい命名規則にしておくなり対策することで発生リスクを抑える事ができます。検索機能を使い検索して対象を1つに絞ってから実行すると選択できる対象が一つになるので間違える可能性を限りなく低くしてくれます。
<ケース⑤：ロボット端末や管理サーバの容量が逼迫して異常終了>
ログを細かく出力するような設定にしていると、ログで結構な量のディスク容量を消費する場合があります。容量が一杯になるとログ出力できずエラーとなったり、生成するファイルの出力や更新に失敗したりしています。各端末やサーバの残りディスク容量が残りいくつあるか定期的に気にしておき、容量が一杯になりそうになる前に不要なものを削除したり、移動したりする対応を行うことでこのリスクを回避する事ができます。
<ケース⑥：外部から送られてきた不正なメールを開いたり、添付ファイルを実行したりしてしまい、ウイルスに感染した>
ロボットが外部から送られてきたファイルを無条件に開いたり、添付ファイルを実行する仕組みのものを作ってしまったたりする場合、このような事態が起きてしまいます。最悪の場合、ウイルス感染して感染を広げてしまう等のリスクに繋がります。このような機能を実装する際は、信頼できるメールやファイルの内容しか操作しないようにチェック機能を搭載する事をお勧めします。無条件では決して添付ファイル実行の操作はしてはいけません。
<ケース⑦：ロボットが操作するファイルを人が同時に操作して更新失敗してしまった>
基本的にロボットがファイルを操作している時は人が操作しないように運用を徹底させるか、ロボットが操作するときは一時フォルダに移動して更新が終わったら名前を変えて保存し直すようにするか検討が必要です。共有ファイルを人もロボットも使わせてしまう運用をと取らざる得ない運用になっているケースもありますが、その際は必ず操作前にバックアップを取得する仕組みを入れておいた方が良いです。ファイルサーバ上の共有ファイルは特に注意が必要です。人の速さでもファイルが破損したりするときがあるので、ロボットの更新スピードではより破損確率が高くなっていると思われます。
<ケース⑧：メモリ不足によりロボが異常終了>
メモリというのは、パソコンが扱うデータの一次領域の事で作業場所のようなものです。このメモリ内で使用できる限界容量というのが決まっており、その容量を超えると異常終了してしまいます。該当の事象は容量が大きいファイルを操作したり大量のデータを操作したりする時に発生します。大量データを操作するようなものを自動化する場合、メモリ不足になる可能性がないか気にして、本番で想定される最大データ量でテストを実施してエラーにならない事を確認するといった対策をとることで本番での発生を防ぐ事ができます。この負荷テストの際にどうしてもメモリエラーとなってしまう場合は、不必要に引数でデータを渡していないか確認してMainに返す前に不要な列や行を削除できるものがあれば、削除しておく対策をしてそれでもダメな場合はVBA等の違う対応を検討したりすると良いです。大量データを扱う場合はVBAやDBで処理させた方が速度も速く、扱えるデータ量も多くなると思います。
<ケース⑨：徐々に実行時間が長くなり、後続のスケジュールに影響がでたり処理がタイムアウトになったりしてしまった>
自動化対象の普段皆様が扱っているシステムはデータ量が年々増えてきたりする場合が多いです。そうなると今までは登録ボタンを押したら3秒で応答が返ってきていたものが5秒、10秒と掛かるようになり、実行時間が伸びて他のプロセスの実行が遅延してしまったり、処理が遅いことにより処理がタイムアウトになってしまい、失敗してしてしまいます。これを防ぐには月次程度で実行時間の伸びを監視して、後続に影響が出そうな場合、処理を高速化できないか検討したり、スケジュールを組みなおしたりする対策が必要です。また、処理のタイムアウトに関しては、待機時間の値を全て変数にして、その変数を設定ファイルから読み込むようにしておけば、時間が伸びてきたらその設定ファイルを更新するだけで対応できるようにしておくことで柔軟な対応をとる事ができます。
<ケース⑩：不要なプロセス(Excel等)が立ち上がっており、ロボットが異常終了してしまう>
ロボットが動く前に不要なプロセスが立ち上がっているとそれが邪魔をしてエラーになってしまうケースがあります。これにはプロセスKILLが有効ですが、プロセスKILLは強制的にプロセスを落とす手法ですので、極力動作させないように普段からロボットが実行可能な状態を意識して、動かすことが重要です。無人ロボットの場合、前のプロセスが異常終了してそのプロセスが使っていたプロセスが悪さをしてしまう事もあります。対策としては異常終了した時に、使っていたプロセスを正常に落とす処理をエラー時の処理に組み込んでおくのが一番良い対策と考えます。(サーバでプロセスKILLを利用する場合、メモリ領域を複数アカウント共通利用しているとUiPath標準のプロセスKILLでは失敗してしまう事があるのでご注意ください)
<ケース⑪：テストと本番で動かす端末が違うのが原因でロボットが異常終了してしまう>
これもよくあるケースです。ロボットは繊細で設定内容が少し違うだけでも異常終了してしまう事があります。ここでの対策は扱う関係する各種設定を抑えておいて、極力設定を統一化させる事です。会社のPCだと一度設定を変えても再起動したら元に戻ってしまったり、一定のタイミングで設定が元にもどったりする場合があります。これは会社毎に共通設定を情報管理部門が決めて運用しておりその設定が再適用されているためです。これに対する対策は各種設定の内容を押さえておき、何が正しい設定なのか分かるように情報を整理し、比較を簡単にできるようにしておく対策が有効です。また設定を一括で正しいものに変えてくれるバッチを作っておくことも有効な手段です。この辺りはまた別の記事でやり方を纏めて紹介していこうと思います。
<ケース⑫：ファイルサーバや各システムのPW有効期限切れで異常終了してしまう>
IDとPWが必要なものの多くには有効期限が設定されている事が多いです。こちらを気にしておかないと有効期限切れのポップアップが出てきた際に異常終了したり、ログインできなくて異常終了したりしてしまいます。対策としてはPWの有効期限を切らさないように運用をする事です。またPW変更作業自体もプログラムに組み込んでしまったりする対応が有効です。処理の途中でこのエラーが発生すると対策が面倒になったりしますのでそのようなプロセスの場合、処理の一番初めにファイルサーバに接続可能か利用予定のシステムにログイン可能か確認してから処理を始める作りにするのも有効な対策です。
<ケース⑬：処理対象のファイルやフォルダがなくて異常終了してしまう>
処理対象のファイルやフォルダが誰かに消されたり、名前を変えられたりしてしまい異常終了してしまうものです。これもケース⑫と同じように処理の途中でエラーとなると復旧が面倒である場合が多いので、処理の一番初めにファイルが存在しているか、フォルダが存在しているか確認してから処理をする仕組みにすることが有効な対策です。
<ケース⑭：設定ファイルの更新内容を誤って異常終了または誤った動作をしてしまう>
設定ファイルの更新を人が誤って、その結果ロボットが異常終了又は誤った動作をしてしまうものです。重要なロボットである場合は、更新内容をチェックする仕組みを構築したり、他の人に確認してもらう事が有効な対策となります。
<ケース⑮：他システムに障害が起きてロボットが異常終了してしまう>
障害が起きるのはRPAだけではありません。利用している端末やサーバ、業務システムやクラウドシステムでも障害が起きる事があります。人でやっている時もエラーとなるようにロボットでも異常終了します。そのようなときは復旧後にどのように対応するかどのロボットに影響があるのか調べて対策を実施する必要があります。各ロボットで利用しているシステムが一覧上で確認できるようにしておくと各システム障害時に影響調査は容易になります。または利用システムをログに出力しておいて、ログから影響調査を可能とする手段もあります。
<ケース⑯：大量の処理を高速で行ったもしくはやり続けた事により対象システムがダウンした>
これまで人の速さや操作量でしか、考慮されていなかったシステムがRPAの処理速度や処理量に耐え切れず、ダウンしてしまうというものです。内部システムでも問題ですが、外部(他社)のシステムに対して問題を起こした場合、賠償請求される可能性もあります。これまでの速度よりも大きく速さやデータ量が変わる場合は扱うシステムも問題ないかは確認をとりましょう。(外部システムはそもそもRPAやプログラムによる操作を禁止しているサイトもあるので、利用規約を良く読んでおく必要があります)
<ケース⑰：予測変換機能が機能して想定外のデータが登録されてしまった>
IEやクライアントアプリに登録を行う際に、予測変換が機能してしまい想定外の値が登録されてしまう事があります。予測変換は基本されないように設定を変更しておくのがお勧めです。又は、UiPathの場合は、文字入力アクティビティではなく、張り付けをしたりして対応する事も代替手段の一つです。(他製品でも同様な手段を検討して下さい)
<ケース⑱：他の人が保守困難な状態になり、保守不可やミスが起きてしまった>
これまであげているようなリスクがそのロボットに存在しているため注意すべき事項や開発と本番機で切り替えが必要な場合はその手順等他の人が再度修正やテストを行う際に存在しないと一から調べなおしたり、誤った認識で修正や実行をしてしまうものです。他の人が任された時にないと困るだろうと思うものを残しておく事は非常に重要な事です。どんな情報を残すべきかは下記別のブログでも紹介しているのでこちらも見て貰えればと思います。
上記でご紹介したリスクはよく発生する初心者でも気にするべきものとなります。このようなリスクをどのように洗い出していけば良いかについて、次は説明していきます。
リスクの洗い出し方
リスクの洗い出し方についてですが、事例を知る事と経験により培われていくのが多いです。実際に普段から気を付けるようにしておくと、他にも気を付けなくていけない事に視野が広がっていきます。経験で培われる部分は各皆様が作業していく中で備わっていくものですので、ここでは知識的な所で参考となる情報を記載します。
〇PwCあらたとUiPath社のRPAガバナンス構築ガイドライン
こちらにRPA関連のリスクとコントロールのポイントをAppendix1の箇所で纏められている無料公開されているドキュメントが存在します。これまでの事例で紹介していないプロジェクトを遂行していく上でのリスクも含めて全体的なリスクへの考え方が説明されています。プロジェクトマネジメントレベルを実施する方は見ておくと良いです。
〇IPA：ITプロジェクトのリスク予防への実践的アプローチI
こちらはプロジェクト管理よりのリスクについて説明されていますが、ITプロジェクトでのリスクとは何か、洗い出しと対策の立て方について参考にする事ができます。こちらもプロジェクトマネジメントを目指すような方は見ておくと良いです。
https://www.ipa.go.jp/files/000026834.pdf
〇IPA：非機能要求グレード
非機能(機能以外の性能、信頼性、セキュリティ、運用性等)についての評価観点やレベルが定義されているものです。今回開発する対象のもので各評価項目でどのレベルの非機能要件になるのか次第でリスクの対策をどれくらい実施するかや、非機能要件観点でリスクがないか洗い出すのに役に立ちます。
さいごに
事例いくつか紹介させて頂きましたが、それ以外にも細かいリスクというものが存在します。IT開発初心者の方は紹介したリスクが存在するという事を覚えて頂き、「本番環境に問題を起こさない！」「セキュリティ事故を起こさない！」の2つの大きな観点をまずは気にして頂ければと思います。
誰かが作った手順(RPA)の中身を理解しないでその通りに実施していると、手順(RPA)の中のどこで注意しなくてはいけないか分からず、集中すべき所で集中しないでミスを起こしてしまう事があります。コマンド一つ発行するものでもそのコマンドによって、何が行われるか調べて覚えていく事でリスクの高い作業の勘所が養われてきます。日々分からない事をそのままにせず覚えていく事が自分でリスクに気付けるようになる確実な一歩となると思います。皆様が事故を起こさずRPA開発や運用ができるようになるためのご参考情報となっていれば幸いです。
RPAのUiPathの事を知りたい場合は、下記に私が纏めている情報のリンク一覧の記事がありますので、そこから気になる箇所の記事をみて頂ければと思います。
