RPAと業務システム

近年のワークフローからRPAにいたる技術の進歩を見ていると、昔UNIXオタクが自動スクリプトを書いては自慢していた頃を見ているようで、変に懐かしい気分になる。やっていることは本質的には同じで、ルーチンワークの楽をしたいだけなのだが、それが一部のマニアから一般に降りてきただけのような感覚がある。

BPMSとRPA、ワークフロー。どれも最近流行っているものだ。その共通的な思想は、何でもシステム開発に取り込もうとしていたことへの反発にも見える。エンドユーザ(業務担当者)ができる範囲のことは自分でする、ほんの少しの変更でもいちいちベンダに開発依頼をして高いカネを取られることのないようにしたい、あるいはもっと変更に柔軟な体制にしたい。思いは色々あるだろうが、ベンダ丸投げの弊害を認識し始めた現場の想いが出てきているように思う。

これらが発達し、エンドユーザが開発に加われるようになると、従来のソリューションも様変わりしてくる。ここでは、大きくは二つの方向性について考える。

一つ目は、アプリケーションの粒度が変化するということ。ひとつの巨大なソフトがでんと構えるのではなく、基本的な機能をもった処理ソフト群と、それを使って仕事をするエージェント群に分かれ、前者は従来のソフトベンダが、後者はエンドユーザやコンサルが協力して作り上げるものになる。

もうひとつは、アプリケーションが使うデータが、門外不出の隠された内部データではなく、エンドユーザにも見えるデータマート的なものになる、ということだ。また、中間成果物も同様に、エンドユーザに理解可能な形式になるだろう。

BPMSにしてもワークフローにしてもRPAにしても、ノンプログラミングである。まあ2次元の絵によるフローチャート的なものであるからプログラムだと強弁することも可能だろうが、少なくともエンドユーザに分かる形になっている。これはつまり、個々の業務は人でも対応可能であり、入力も出力も人間が理解できるフォーマットである必要がある。そうでなければチェックができないからだ。

これは中間成果物にもフォーマットを与えるということでもある。例えば、DBから吐き出した生データを別のSQLに直接突っ込むのではなく、生データを帳票にして渡し、受け取ったほうがまたデータにして処理を続ける、というようなものだ。コンピュータ資源的には無駄な処理だが、人間の理解を得る上では必要な処理だ。

ここで言う中間成果物は、チェック機構としても働くことができる。つまりこれはワークフローの承認部になり、ここで人手(中間管理職)のチェックを経てから先に進んでいたところ、そのチェックもやはりRPAで書きます、といった類のものだ。もちろん人手でやっても良いし、むしろ機械の不具合時は人手でそのまま代替することが可能である。それもフォーマットが人間可読であればこその技だ。

コンピュータが十分に速く安くなってくれれば、こういった形の方が間違いが目に見えてくれるのでむしろありがたいのではないか。そしてもちろん、ロジックが正しいと確認できれば、「コンパイル」して、中間の帳票作成及びその逆変換処理は事実上パスしてよいのだから、スピードはあまり落ちない。

また、中間成果物を入力とするBIを出しておけば、管理職としてもマクロ視点でのチェックができるし、システムが安定稼動していることも確認できるから安心だ。

一方で、従来のアプリケーションでは肥大化していた自動化処理は、ほとんどこちらに移ることになり、アプリケーションの機能はシンプルになる。人が直接見るメニューも減るだろうから、画面数も少なくなる。これは自動化のエラーをベンダでなくユーザが責任を持つことでもあるので、ユーザの負荷は増えるがシステムは安価且つ堅牢になる。どちらを選ぶかはもちろんユーザ次第だが、ノウハウを自社に溜めたいと思えば自分で作る道を選ぶだろう。

ベンダとしても、理不尽な要求をされることは減るし、顧客によって異なるフローの流儀を覚えなくてよいから横展開も楽になるし、その顧客にしか使えない開発者も不要になるし、むしろこちらを推し進めるのではないか。これによって顧客知識は顧客が正しく持ち、ベンダロックインも減り、双方満足、という世界も見えてくるのではないか。