「失敗しないRPA」のススメ 導入・運用で注意すべきポイントは？：特集・RPAで仕事が変わる（5/6 ページ）

[小林啓倫，ITmedia]

　図1の領域B〜DをRPA化する場合、従来のシステム開発よりも多種多様で多くの業務について、現状を調査したり要件を定義したりすることになる。しかしIT部門の限られた人材で、その全てに対応するのは現実的ではない。「現場の従業員にも調査や要件定義に深く関わってもらいたい」という思いから一歩進んで、業務部門でRPAの開発をできる人材を育ててしまおうと考える企業も多い。システム開発の経験やノウハウを持たない人々が、RPA開発に関わるようになるのだ。

　そうなると出てくるのが、「RPAは簡単に設定できて、現状の変化に柔軟に対応できるツールなのだから、現場の好きなようにさせれば良いのではないか」という話だ。確かにRPAは従来のシステム開発に比べ、環境変化にある程度柔軟に対応できる。

　ウォーターフォール型（前の工程には戻らない前提のシステム開発）の開発に見られるような、厳密なドキュメント作成やフェーズ管理、工程を先に進める際の厳しい評価を行っていては、せっかくのスピード感を生かせなくなってしまうだろう。

　とはいえRPAは他のシステムやアプリケーションを操作するものである以上、一定のガバナンスを効かせなければ、社内のIT環境は大混乱に陥ることになる。

　IT部門が存在を認識していない、あるいは存在は知っていてもどのような動きをするのか詳しく把握していない「野良RPA」が増えると、既存システムに負荷がかかってしまう。既存システムに障害が発生した際、それがシステム側の問題かRPA側の問題かを切り分けるのに時間がかかることもあるだろう。

　問題がRPA側にあることが分かり、いざ修正しようと思っても、開発時の関係者が全て異動し、ドキュメントが残されていないために誰も手を触れることができないという事態も発生しうる。

　「RPAがなかなか普及してくれない」と嘆く導入担当者は多いが、普及したら普及したで、別の問題が待ち構えているのだ。

　他にもRPAが使うアカウントの問題もある。ロボットに人間と同じアカウントを与える場合、明確に「ロボットによる操作だ」と分かるようにすべきかどうか、などだ。そのアカウントにひも付ける権限の問題も同様だ。ロボットがデータベースへのアクセスやメールの送信を行うからといって、何でもかんでも実行可能な権限を与えるとセキュリティ上のリスクになる。

　開発中のRPAをテストする環境についてはどうだろうか。個々のシステムのテスト環境はあるが、AシステムとBシステム、さらにはOutlookを連携させることができる総合テスト環境が存在しないという例もある。

　従って、基本的にはRPA開発も通常のシステム開発と同等と捉え、既存のシステム開発関連ルールに従い、IT部門の責任者にも関与してもらった方が安全だろう。