RPAは正しい選択なのか

RPAが花盛りだ。デファクトスタンダードがまだないので、多くの会社が参入し、乱戦状態である。

しかし、そもそもRPAは正しい選択肢なのか、という疑問は沸く。そもそもプログラムでできるものではないのだろうか。素人が作れば、多くの場合は上手く動いても、ひとたびエラーが出ればたちまち対応不可になってしまわないだろうか。仕様が変わったらとたんに動かなくなり、業務が停滞してしまわないだろうか。

もう20年以上前だと思うが、今のRPAと同様の仕掛けを提案したことがある。そのときの目的は、仕様書がないか不明確でAPIがないシステムとの連係動作だった。自動化するに当たってAPIがないことがネックになっていたシステムに対し、最低限画面で連携すれば繋がるはずだ、だからそれで行う、というのがその理由だ。

今流行っているRPAの意義はもっと単純なもので、単にパンチャーの役割を減らそうとしているだけのように思える。単純な話、APIがあったとしてもそれを無視して画面で繋ごうとしているように思える。カネを出せば作れるかもしれないのに、それをケチって現場で何とかしよう、という意図が透けて見える。

もしそうすれば、上に出たような危険は排除できない。効率が良くなった分仕事を詰め込まれれば、ある日突然大事故を引き起こす。そのときにババを引く(責任を取らされる)のは現場だ。

だからこそ、である。RPAを使おうが使うまいが、自動化するならばその品質管理はきちっとやるべきなのだ。評価し、テストし、保守をする。普通のプログラムと同じに扱うだけだ。

であるなら、RPAを使う理由はそもそもあるのか、というところに落ち着く。下手に素人が触れると、勝手に改造されたりコピーして流用されたりすれば収拾がつかなくなる。

先の提示のように、APIがないシステムの結合だけをRPAに任せ、それ以外は各々のシステムのスクリプトなどで解決するべきではないか。更にはRPA画面をユーザに見えるのではなく、APIの一種として位置付け、仮想マシンとして内部で使用するだけに留めるべきではないか。