技術的な観点だけでは語れないRPAの効能

以下のツイートがLINEのオープンチャットで話題になってました。

僕もエンジニアなので、言わんとしてることは分かります。

RPAじゃなくても良いのに、ムリヤリRPA化して「削減時間こんだけ出たよ！どや！！」となってる報告事例がやたら多いのは、皆さん既知の通りです。

1000…3000…5000時間削減！！と削減時間をモリモリ盛った報告を聞くたびに、どうやって算出したの？と疑問になるのは無理もないし、RPA普及に逆効果な側面もあったかと思います。ベンダーの思惑が垣間見えます。

上記のようなマーケティング戦略で、ライセンスをバラまいて稼ごうとするベンダーがいるのも事実です。使い方はユーザー企業に任せます！！と言わんばかり。

ではRPAの存在は悪なのかというと、そうではありません。

冒頭の方がおっしゃった通り、技術的な部分に関してはRPAでなくても実現できると思います。Selenium, SikuliXなどの自動化ツールは何年も前からありますし、Pythonなどの言語でも自動化ツールは作れます。

UiPathやBluePrismなどのRPAツールを使わずともRPAシステムを構築する手法を紹介している本もあります。僕も拝読させてもらってます。

Pythonの本はこちら。

RPA = ユーザー主導でDX化を図るための手段

RPAはノンプログラミングとまではいきませんが、普通にプログラミングするよりはラクに業務自動化が実現できます。複雑なことでなければ数週間程度で1本のロボットが作れてしまいます。

この「手軽さ」がユーザー企業主体で業務自動化を進めることを可能にします。

ユーザー企業には自動化したい業務があって、その業務に詳しいのも当然ユーザー企業です。

従来のシステム開発では、要件はユーザー企業がまとめ、開発は外注エンジニアに依頼し、数か月から1年程度常駐してもらうことが大半でした。それはシステム開発に必要な知識（アプリ設計・開発、データベース設計・構築、インフラ構築など）が専門的で、非エンジニアでは対応できないからでした。

RPAの場合はシステム（＝業務に必要なデータを入れる箱）を作るのではなく、そのシステムにデータを入れたり抽出したり、抽出したデータを加工するような「操作」を対象に作ります。

その「操作」を作るために必要なスキルセットとしては、前述したようなデータベース、インフラ構築などの知識はほぼ不要（あるに越したことはないですが）ですし、アプリ開発のスキルもRPAの登場により、深いプログラミングの知識は必須ではなくなりました。

要するにDX化の敷居が下がったわけです。

であれば、ユーザー企業主導でDX化を進めようと考えるのは必然な気がします。RPAの登場は、ユーザー主導でDX化を図ろうと試みる非常に良いきっかけとして作用していると思います。ここが大きなポイントだと思っています。

これまでのシステム開発のように、業務整理・選定はユーザー側が、開発は開発ベンダー…と分担して行う開発スタイルが変わってきている。どっちも把握していれば生産性上がるよね、ってことですね。それだけスピードを要求する時代になってきているのかもしれません。

RPA開発ベンダーの今後

僕は開発ベンダー側の人間で、ユーザー企業からの受託開発案件を受ける立場です。

RPA界隈の案件についてご相談を受けるたびに思うのは、技術アドバイザー的な役割をしてくれる人のニーズが高まっているということです。

ユーザー企業側ですでにRPAツールの選定やキックオフはすでに終わっていて、開発を進めるにつれて課題が溜まり、自分たちでは解決できない状態になって初めて開発ベンダーに依頼がくる…といったパターンが増えてきている気がします。

アドバイザーは1人か2人程度でいいと言われることが多いです。

開発する人はユーザー側にすでにいて、その人たちのサポートをしてほしい、と。世間ではRPAが「早い、安い、うまい」と宣伝されていることもあり、潤沢な予算を確保してもらえないのかもしれません。

現場に技術アドバイザーが1人入ったとして、その人が当初の予定通りに単に技術アドバイスだけをしていれば良いかというとそうではありません。

おそらくBPRとロボット開発のつなぎの部分（ロボット化しやすいよう業務を削減、簡素化する作業など）もやるでしょうし、ロボット稼働後のサポートも対応しなければなりません。

僕が危惧しているのは、技術アドバイザーとして現場に入った人の作業負荷の増加です。

ユーザー企業側の人たちに悪気はなくても、「教えて！」から「作業お願いします！」になっていくのではないかと…。悪気のない丸投げ、ですね。

なので、技術アドバイザーのバックアップ体制を開発ベンダーが整えることが大事かと思います。

総括

RPAがきっかけとなって、ユーザー主導でDX化を図る事例が今後増えていくと思います。

そこでのエンジニアの役割は、ユーザー側の意見を咀嚼し、技術的な観点や今後の運用などを見据えた意見をきちんと伝えて律することだと思います。

ユーザーが勢いでプロジェクトを進めてしまいそうなときに「ちょっと待ってください」とはっきり言えるかどうか。

それができるためには、ユーザー側の業務をエンジニアがある程度把握していないと厳しいかもしれませんが、少なくとも「業務知識なんて興味ないし、コードが書ければそれでいい」と考えている人には対応できないと思います。

エンジニアにも業務知識が求められる動きはRPA界隈に限った話でなくなってくるかもしれません。

RPAを皮切りに、既存のシステム開発においてもユーザー主導になっていき、外資系企業や資金が潤沢な国内企業のように、ユーザー企業側にDX専門部署（情シスが担う？）が作られる動きになっていくような気がします。

そうなっていくと、業務知識をもったエンジニアであったり、ユーザー側への歩み寄り（単なる御用聞きではなく）ができるエンジニアのニーズが高まっていくと思います。

多重下請け構造でなかなか上流工程を任せてもらえない状況が続いている人は、早々に脱却し、ユーザーと直で話ができる現場で経験を積んだほうが良いかもしれません。

ユーザー企業側も、RPAをきっかけにこれまで以上に開発ベンダーと技術的な会話ができるようになってくると思います。

「この業務こんな感じでロボット化したんだけど、システムに組み込みたいんですよねー」みたいな会話ができると、開発ベンダー側もロボットという要件定義書が用意されている状態なので、話が早いでしょう。

技術的な観点だけではRPAの有用性をジャッジすることはできません。

ユーザー側のITに対する潜在的なニーズが浮き彫りになったというところが、RPAの大きな効能だと思っています。その期待に開発ベンダー側がどのような形で応えていくか。考えなければならない時期がきていると思います。