RPAについて会計士協会に意見を送った（5:意見　その２）

(2) RPA における内部統制
会計業務へのRPA の適用の拡大により、内部統制は大きな影響を受けることが想定される。RPA には、決められた指示に対してその指示に準拠して均質に作業を実施するという特徴があるが、この特徴から、RPA が有効に機能するには、決められた指示が正しいということが大きな前提となっているものと考えられる。すなわち、RPA は決められた指示が正しいかどうかを自ら判断することはできず、指示されたとおりに作業を実施することしかできないからである。人であれば、もし指示された内容に明確でないにしろ気になる点があれば、指示者に相談するなどして指示自体の適切性を担保する役割を担うことができる。一方で、デジタルレイバーは指示された内容が適切であるかを判断することができないため、既存の業務プロセスや周辺システムが変更されていたり、法令等の外部環境が変わっていたりした場合で、過去には適切であった指示が適切でなくなっている状況であっても、既に適切ではなくなった指示に従って作業を実施してしまうリスクがある。

また、RPA を導入した場合にデジタルレイバーは間違わないという先入観の下で人が実施した時に比べて作業のモニタリングが弱くなったため、デジタルレイバーへの指示が適切ではなくなっていることに気付くことができない可能性がある。

→ここは現場感のある指摘で良いですね。

この他、RPAと内部統制に関わる問題としては、RPA導入によって業務プロセスが必然的に変更されることを意識する必要があります。
業務プロセスが変更されれば、既存の（J-SOX上の）コントロールが消滅する可能性があるからです。

たとえば、

・証憑を元に会計システムに仕訳を手動入力し上長承認後に登録完了としていた業務プロセス

を自動化して、

・証憑を自動読込させた上でRPAが自動で仕訳登録まで行わせる

すると、業務プロセスも当然変わっていますし、コントロールとしては事前の上長承認が消滅している。
このままだと、重要な財務報告プロセスにおける統制の不備になるかも知れません。

そのため、代替のコントロールを導入する必要が出てきます。たとえば、仕訳と証憑を事後的に突合する、とか。

というわけで、RPAを導入する業務プロセスがJ-SOXの評価範囲に含まれるか確認することって超重要だと思っています。
なぜか、この指摘をしている本や記事を全く見たことがない。

さらにRPA の導入には一般的に高度なシステム技術が必要であり、一度導入されるとインプットからアウトプットまでのプロセッシングについてはブラックボックス化するケースがある。

→ここはまた疑問なところ。

そもそも、「RPAの導入」がRPAソフトウェアの導入か、RPAロボの作成のどちらを意図しているのか？？

RPAソフトウェアの導入という意味であれば、サーバ型であっても技術的な難易度は他の業務システムの導入と変わらない、クライアント型の場合はむしろ非常に簡便に導入は行えると思います。

一方、RPAロボの作成という意味であれば、既存のスプレッドシート上の関数などと比較して高度なシステム技術という意味であればそうかも知れません。
ただし、RPAは「ノンコーディング/ノンプログラミング/現場部門で開発可能」との特徴は良く言われることなので、ここで「高度なシステム技術」と言い切って良いものか？

というわけで、どちらの意味にせよ一般的な理解から離れた記載となっていると考えられるので、何を意図した部分かもうちょっと補足意見が欲しいかなと。

また、RPA では複数のシステムにまたがって処理を自動化することも多く、関連するシステムの全てに関与し続ける人材を確保することが難しいケースがある。このような場合、導入時の部員が異動などにより不在になることでプロセッシング部分を理解している人員がいなくなり、変更対応ができないといった問題が生じることが考えられる。

→この部分、草案が暗黙に想定している「RPA導入会社」の姿が現れている気がします。

会社内でシステム部門やRPA専門部署が集中的にRPA開発・保守を行う場合は上記説明でOKでしょう。

つまり、
開発時：専門部署の人が使用システム/アプリケーションを良く調べながらロボ開発
↓
開発した人が人事異動でいなくなる。一応のマニュアル類とともに引き継ぐ
↓
いきなりロボが止まる
↓
マニュアルから外れたエラーだとロボと使用システム/アプリケーションまで全部網羅的に理解していないと対処不可能

というような情景が目に浮かびます。

ただし、業務部門が自らの業務をRPA開発・保守する場合は、ユーザーが「関連するシステムの全てに関与し続ける」ケースも出てくるのではと思います。

なので、この問題は社内でのRPA開発・保守を誰がやっているかによって発生可能性や影響度が異なってくると考えられます。

またRPA は従来のシステム開発・変更に比べて、システム部門ではなく現業部門での開発がより多く行われる可能性がある。このことは、従来のシステム開発・変更では機能していたＩＴ全般統制が機能せず、不適切なRPA が業務で利用されるという問題を生させることが考えらえる。

→一つ上のところでは「システム部門やRPA専門部署が集中的にRPA開発・保守」という暗黙の前提を置いている感がありましたが、ここは「現業部門での開発」も視野に入れていますね。
これまで何度も書いた通り、RPAの利用状況は千差万別なので、この2つのケースは分けて考えた方が良いのでは、というのが私の見解です。

現業部門が開発しているとITGCがおろそかになるのでは？との危惧もその通りでしょう。

じゃあどうするか？を皆は聞きたい。
現業部門にITGCを守らせよう・・・というのは優等生すぎる。

現業部門は開発させなくする？
いっそ、統制は外側からかける？

というところまで踏み込んで欲しいですね。