ブラックボックス化しがちなRPA

　RPAは、単純な作業を履行するだけのプログラミングされた自動処理そのものである。つまり、「ミニチュア化されたITシステム」と言える。当たり前だが、通常のプログラムと同様、人間が考えた手順しか再現できない。もちろん、誤った手順を登録（プログラム）した場合、そのまま履行されてしまう。そのため、プログラミングの際には二重、三重の検証作業が必要であることは言うまでもない。

　ここで起きがちなのが、「自動化対応が完了したので、人を減らそう」と当該事務に精通した人間をワークフローから外し、別の業務を担務させてしまうことだ。とかく銀行の場合、間接部門人材がフロント部門へ再配置されることがブームのようになっていることもあり、この傾向は顕著である。

　たしかに、RPAをいったん登録したおかげで事務作業に従事する職員を減らすことは可能となった。目先の“スループット”も向上しそうである。では、このRPAは今後誰がメンテナンスするのだろうか？

似たような二つの帳票、不要だから一つを削除してしまった

　ここで困った事例を紹介しよう。ある金融機関では、既に導入されていたRPAが存在していたのだが、当該RPA導入後に、事務を担っていた職員が異動となってしまった。なお、当該RPA導入にはシステム部門は関与していなかった。1年ほど経過した頃、新たに赴任した職員は、RPAに詳しかったこともあり、実質的にRPAメンテナンス担当のお役目を負うことになった。

　その職員は「類似の帳票がほかに存在するため、思い切って画面出力と帳票イメージ保存機能をプロセスごと削除してしまえ」と、とある帳票出力系の手続きをRPAから削除してしまった。おかげで事務効率はわずかながらも高まり、単位時間当たりのスループットも向上した。

　ところが1年後、財務局が検査に入り、その職員がワークフローから排除した当該帳票の保存状況を確認されてしまった。その職員は認識していなかったのだが、どうやら当該帳票は法定帳票として保存義務はなかったものの、財務局からのかつての指示により、保存を要請されていたものであったのだ……。

事務に詳しい職員が守ってきた「機能」を保全せよ

　RPAは、「複雑な処理」でかつ「事務にくわしいプロフェッショナルの職人芸」となっているような「面倒な処理」を自動実行することが目的である。一度登録してしまうと、事務職員の手から離れてしまい、その間に人事異動などがあれば「どうしてこのような処理をしているのか」が不明になる可能性もある。

　したがって、事前に「処理の目的」「参照すべき情報」などを整理した「処理フロー」を明文化しておかなければならない。先の事例からもわかるとおり、「どうしてこの帳票出力が必要なのか」「なぜ、この書類を保全する必要があるのか」といった点については、法令以外の面では、事務レベルでの通達を一子相伝のように職員が継承して明文化せずに現在に至るものも少なくないはずだ。

　合理化やフローを見直す際には、こうしたポイントにも配意する必要があることは言うまでもない。


【次ページ】事務に詳しい職員が守ってきた「機能」を保全せよ