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

(3) RPA の利用が監査に与える影響
監査において、内部統制の有効性を検討する場合に、手作業による内部統制の場合は作業が継続的に実施されているかどうかといった運用状況の確認に主眼が置かれることが多かったことに比べて、デジタルレイバーにより実施される作業の場合は、デジタルレイバーへの指示が適切か、または、指示を適切にメンテナンスできるかといった整備状況の確認を重視する必要があると考えられる。また、従来のＩＴ業務処理統制の評価に比べて、業務への適用に関するデザインの評価がより重要になると考えられる。

これは、通常デジタルレイバーへの指示（内部統制のデザイン）は～

→ここも何度も指摘するように、内部統制をRPAロボに組み込むことを前提にしていますね。

RPAロボにはコントロールを組み込まず、あくまでも人間の代わりとして考えて、たとえばRPAロボが行った基幹システムへの登録内容と証憑を照合するとか、ロボ外部にコントロールを整備運用する方法も考えられます。

巨大エクセルを使っていた業務をVBAで時短した場合、わざわざ内部にコントロールが必要とか普通考えないですよね。
むしろ「時短は素晴らしい！けどマクロが間違えていないか心配。いくつかサンプル的にチェックして大丈夫か確認しよう」となることが多いんじゃないかと。

この草案自身「(2)RPAにおける内部統制」でも言及しているように、システム部門ではなく現業部門での開発が多く行われる可能性があることを考えれば、結果的にこのようなコントロールの方法も広く行われるんじゃないかと思います。

ちなみにこの「自動化されたものを人の目でチェック」という考えは、この草案の別セクションで紹介されています。
freeeとかMFを念頭に置いた「クラウド会計ソフト」への考察があるのですが、その中で「人による仕訳のレビュー、すなわちクラウド会計ソフトによる自動処理に対する人によるモニタリングが必要になる」との指摘がされています。

で、ここまでこのニッチな投稿を読み進めてきた皆さんなら当然の疑問として
「本当のところ、RPAにITGC/ITAC組み込んでる例あるの？」
と聞きたいかと思います。

実際に他社ユーザ事例を見たりシステム監査人にヒアリングしたところ、RPAロボ内部へのITAC整備運用が現時点では難しいため、例えばデータの抽出加工までは自動化させても最後の基幹システム登録だけは人間に行わせるという運用の話を聞いています。

ITGCについても、J-SOXに適合したレベルのITGCというよりは、精々「変更管理・アクセス管理はしっかりしましょう」という一般的なレベルから練り上げていっている段階が大多数だと思います。

これは、通常デジタルレイバーへの指示（内部統制のデザイン）は従来よりも複雑な条件判定や複雑な処理を含むものであり、～

→この部分を最初に読んだ時、いきなり文章に出てきた「従来」って何を指すのか全く分からなかったんです。業務システムであればむしろRPAより複雑ですし。

そんな時に読んだのがこれまで何度も紹介したこの記事。
「RPA導入でコンプライアンス違反になる恐れ、必要な対策」
（https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/01267/）

この中で、アビーム安部氏が「EUCとRPAは異なる。EUCはピンポイントの自動化だがRPAは業務プロセスそのものを担う」と言っているんですね。そして記事がアップされたのが11月14日。草案公表から3週間しか離れていません。

おそらく草案をまとめる過程で、協会の方はRPA有識者の一番手である安部氏に話を聞きに行った。そしてEUCとの違いについて意見交換した結果が、草案とこの記事に表れている。だから内容面でもリンクしている。あくまでも勘ですが、そんな気がしています。

邪推を広げると、基本的にBizRoboでRPA商売をしているのがアビーム。そのアビームに聞いた話も参考にして作られた草案。であれば草案がサーバ型RPAを念頭に置いているように見えるのも納得です。

また、そのアウトプットも、単純な単一のデータではなく、複数のアウトプット又は後続への複数のインプットデータとなる。このため、作り手が意図したとおりにデジタルレイバーに指示ができているかについては、慎重に検討を行う必要がある。
すなわち、ＩＴ全般統制におけるプログラムの開発及び変更管理の整備運用状況について、より高度に担保されることが必要となる。
同時にRPA は複数のシステムや多様なデータを連携した処理を行うことが想定されるため、業務処理を行う担当者やシステム、データは広範囲にわたって当初のデザインどおりに運用される必要があり、運用状況の検証や不備が生じた場合の影響についても、より慎重な検討が必要となることが想定される。

→このあたりも「システムとしてのRPA導入」を前提にしていますね。

したがって、ＩＴの専門家の活用がより重要になると考えられる。

→この記述には、はっきり反対します。こんなまとめで良いのか！？

RPAは前述の通り「ノンコーディング/ノンプログラミング/現場部門で開発可能」なことが特徴であり、また草案文章にもあるように「業務への適用に関するデザイン」が重要です。

つまり、個々の業務を深く理解していなければ、そのRPAロボのデザインが適切なのか判断できないはず。

であれば、確かにITの専門家の活用も重要ですが、年度監査・四半期レビューを通して継続的に企業と関わる会計監査人自身がRPAロボと業務プロセスについて深く検討するほうがもっともっともっと大切なのでは！？

ここが草案RPA部分のほぼラストなのですが、こんな風に「IT専門家を良く活用しましょうね」でまとめちゃうと、

「あ～つまりはRPAってテクノロジーの話なのね」

って誤解されませんかね？？？

この変なまとめが、草案が暗黙の前提としている
「コントロール機能を内蔵したサーバ型RPAをシステムとして導入する」
から導き出されたものなら、そもそもこの前提自体が変なことの現れじゃないでしょうか！？

「(2) RPA における内部統制」におけるコメントのように、会社内でのRPA開発・保守体制によってメンテナンス上の問題の発生可能性や影響度が異なることからも、監査人による深度ある検討が必要になってくると思われる。