#1RPAとはシステムなのか

このブログを書き始めた背景だが、だれかに見せるためではなく、

日々の思考のアウトプットとして書き始めるものである。

乱文となる箇所もでてくると思うがご容赦頂きたい。

 

筆者はRPA(Robotic Process Automation)というソフトウェアのビジネスに携わっている。幸運なことに様々なエバンジェリストの方々とお話する機会を得ることができ、かなり良質なインプットは得ているのだが、当方の能力不足によりアウトプットがキチンと出来ていない。

 

そこで思考の整理の為、ここに書き溜めていく。

RPAの言葉そのものについての説明などはwikiなので調べて頂きたい。

 

本題、「RPA=システム」なのか?

あるべき論ではRPAはシステムではないといわれる。

本当に果たしてそうなのか疑問に感じるところ点が多々ある。

 

「RPAの推進≠システム開発の推進」これは納得できる。

なぜなら、全てのシステム事案に対し、IT投資の上、費用対効果を出す、なんていうことは夢物語であるからだ。システム開発はコスト削減等の投資回収が前提である。

RPAではシステム投資ができないものでも救済される。

 

だからといって、「RPA≠システム」の理論は厳しい。

RPAそのものはシステムである、という考え方の方がしっくりくる。

ツールの特色を無視したとしても、実運用を考えれば「サーバ」や「開発者」は不可欠なキーワードであり、運用も保守もまた不可欠である。

これは一般的に考えればいわゆる「システム」である。

RPAのバズ化から2年程たったが、企業の声としてもRPA≒システムと感じている企業の方が増えてきていると実感している。

つまり、ブームからしばらくたった現在において納得感のある見方としては、

  • RPAはシステムである
  • 企業内においてロボットを生産するインフラである
  • このインフラをメンテナンスすべきはシステム担当である
  • システム開発よりは軽度に要件を実現可能とする

と感じている。

 

是非違う見方をお持ちの方がいればご意見を頂きたい。

 

よく導入のきっかけとなる「エンドユーザーコンピューティング(EUC)」の派生がある。ユーザーからの要望に応えられないシステムサイド、システムサイドの鈍さに耐えきれないユーザーサイドが折衷案としてRPAを求めるパターンだ。

筆者はこのケースで成功している企業を数社しかしらない。

それもまた、RPA=システムだからではないかと感じている。

システムは知見のある人間のもとで管理運用されるべきであり、ユーザーサイドはその恩恵だけを得るべき。この成功ケースは散見される。

システム担当の飯のタネとプライドは維持され、ユーザーは旨味だけを堪能できる。

失敗の末、この形に落ち着くのは、おそらく組織の機能にはまる形である必要があるからではないだろうか。

 

RPAを通して変化を嫌う日本社会の未来を憂うのであった。

 

次回は「RPA」とはいったい誰のものなのか?

企業規模、推進者の立ち位置によって異なるこの問いについて考えたい。