いったん整理しておこうと思い、筆をとりました。
RPAをビジネスとして考えたときに、今の時点で何が障壁となっているのか、どうしていくべきなのか、個人的な考えをだらだら書きます。
1．RPAの可能性がありすぎて迷走する
RPAの特徴は、
・エンジニアでなくてもある程度の自動化ができるツール（と世間では認知されている）
・基幹システムの入れ替えまでの一時しのぎとして、もしくは既存システムをラップする技術として導入しやすい
・Office関連の手作業を手軽に自動化する技術
と思ってます。
でも実際は、非エンジニアがRPAツールを使おうとしても無理と言って過言ではないと思います。
そう言い切った理由は、技術的にうんぬんというところではなく別の理由です。
単純に（特に中小企業の）社員さんはRPAを勉強する暇もロボットを作ってる暇もないからです。
かといって、RPAを運用する部署を作るのは、人件費がかかるため、金銭的コストの面では企業の重荷になってしまいます。
部署を作ることができるのは、資金的に余裕のある大手だけと考えて間違いないでしょう。
立場を変えて、ロボットを作る側（RPAベンダー）のことを考えたとき。
RPAならではの導入の手軽さ、開発スピードを生かしたいので、多少異常系は実装ができてなくてもまずは導入し、稼働していく中で完成度を高めていくのが主流と思われます。
となると、継続的に開発＝運用保守フェーズである、とエンドユーザーに認識されてしまうと、運用保守料金の中で開発ができるかというと、コスト的にも1ヵ月でできることは限られてしまいます。
開発費として月々もらえるかというと、そこはRPAが「手軽である」「非エンジニアでも触れるツール」として認知されていることがマイナスの方向に働いて、なかなか費用をいただけないことも多いです。
少ない運用保守費用で細く長く開発を継続していると「まだこの機能入ってないの？」となって、エンドユーザーの不満に繋がってしまうかもしれません。
RPAならではのお手軽感、スピード感も失われ、「だったら最初からシステム改修でよかったじゃん」と言われてしまいます。
個人的な結論として、導入後の運用はできればエンドユーザーにやってもらいたいです。
例えば、導入後の数ヵ月は運用保守要員を常駐させて、徐々にエンド企業の社員に保守をスライドさせていきたいですね。
2．RDAの運用保守はムリ
作るロボットにもよりますが、かなりキツいです。
単純なロボットの入れ替えなら良いですが、マクロ改修など、Excelファイルも含めて入れ替えとなると急に面倒になります。
例えば、Excelファイルに顧客マスタを持たせておいて、ロボットがそれを参照するとして、顧客マスタの項目修正、追加が入った場合。
入力されている顧客情報は新しいExcelファイルに転記しなければなりません。
上記の点も含めて、総じてロボットのバージョンパップ対応は想像以上に面倒です。
導入が面倒になってきたので、Inno Setupでインストーラを作ってますが、例えばExcel内の記入内容を転記するスクリプトをキックする仕組みにしておけば、多少は解放されるかもしれませんｗ
ってか、RPAが面倒くさいってどういうことっすかｗ
3．結局RPAで食えるのか？
現状、RPA開発に対する僕のイメージは、
開発・運用サイクルがめちゃくちゃ早いという点以外は、従来のシステム開発と同じ
↑に「非エンジニアでも触れるし、短期間でできるんでしょ？だから低コストでイケるよね？」というエンド側の期待が絡んで、収益を上げづらいものになってしまっている印象です。
RPAツールを作っているベンダーも、ライセンス料の叩き合いに飲み込まれて淘汰されていってます。
個人的には、従来のシステム開発と同じやり方で導入を進めるのはナンセンスかなーと思っていて、継続的にロボットの課題を挙げて、改修して、改善するサイクルをぐるぐる回せるやり方でプロジェクトが進められないと、RPAを入れる意味はないかなと思います。
あと、個人でもRPAを使った業務自動化を社内に呼びかけることができるきっかけとして作用している点はRPAの大きな功績だと思ってます。（一人は辛いけど）
上記のような、自動化を推進する人を支援する場（勉強会などのコミュニティ）、チャラ電Mitzさんが主催されているRPA Communityの取り組みはとても良いことだと思います。
原点に立ち返って、「RPAはお手軽なツールである」として、非エンジニアの人に普及させていく方向性は間違っていないのではないかと。
僕個人としては、↑のような普及活動に力を入れたいですし、RPAをはじめとする業務自動化に興味がある人を支援する活動をしていきたいですね。
0コメント