RPAの運用に必要な環境整備

開発して提供するだけなら簡単なのかもしれません。RPAは、いつまでも全く同じで動作し続けることはないのです。それを意識した環境を用意しておく必要があり、それがないと大変なことになります。

RPAが動かなくなる原因としては、参照していたWebサイトの画面が変更になった。ブラウザの機能が変更になった。などなどRPA自体の問題でなくても改修しなければならなくなることがあるのです。その場合にどうやって対応するのかを考えておくことが必要になるのです。

例えば、参照しているWebサイトの画面が変わっただけなら、RPAを直ちに対応させればいいだけなのですが、それでも既存のRPAを止めて改修して試験してリリースしなければなりません。本番環境を直接操作しても問題ないなら、その方法だけで行けそうですが、すぐに直せないくらいいろんな画面の情報が変化していると、ある程度の期間を要することになりかねませんし、その間どうやって対応するのかも考えておく必要があります。

よくある環境としては、ＵＡＴ環境（ユーザーが検証する環境）、本番環境（本番として稼働している環境）、試験環境（開発者が検証する環境）、開発環境（開発・改修のための環境）などがありますが、すべてを持っていればいいというわけでもなく、多くなると、どこで確認したのか、その環境にあう設定を維持する必要もありますし、RPAのアンマッチなども発生しかねないので、運用が面倒になります。

このあたりを考えて、ミニマムな環境で、かつ、操作しても本番にできるだけ影響のない検証ができる環境だけを持つのが理想です。

私の経験では、RPAの仕事内容による環境整備が必要ということです。

①RPAの仕事内容が、申請系の業務の場合は、実施してしまっても、運用権限で手動対応可能なものの場合は、本番環境だけでも問題なく、できるだけ速やかに実行させながらでも改修してしまう方がベストだと思います。理由は、明日にも申請がくる可能性もあり、速やかに動作するように改修しないと利用できなくなる人が多くなり、削除していないとセキュリティ上問題になりかねないからです。ただし気を付ける必要があるのが、ログをそのまま残すことです。アカウントの削除の場合などログを勝手に変更すると法律上問題になりかねない場合もあるので、そのような場合はUAT環境を用意しておかないとダメです。

②RPAの仕事内容が、作業代替の場合は、UAT環境があったほうがよく、本番環境しかない場合でも、ダミーデータを事前に用意してもらう必要があります。理由は、検証すればいいだけでなく、ユーザーがやっていた作業なので、確認してもらう必要があり、かつ、エラーになったときのリカバリーもユーザーに対応していただく必要があるので、ユーザー含めての検証確認が必要になるからです。

③RPAの仕事内容が、データ連携（夜間にAからデータを抽出し、BのDBに格納するようなもの）の場合は、データミスがあると本番に影響を与えすぎてしまうのと、ログが法的に必須の場合には、困ることになりかねないので、UAT環境か検証環境を用意しておく必要があります。

これまで見ていただいたように、RPAの運用環境は、どういうRPAの仕事内容なのか、どういうシステムを操作するのかにより持つべき環境が変わってくるということを強く意識しておいていただきたいです。