RPAは本当に必要か？｜RPAはやはり魔法のツールではない
近頃RPA関連の記事を見ない日はありません。
それだけ多くの人が注目しているのかと思う一方で、「RPAの導入の前にすべきことがあるだろう」という思いもなくなりません。
そんな中で下記の記事を読みました。
記事の内容としては、前半はRPA大手のBlue Prism社のプレゼンテーションの内容紹介、後半はRPAユーザとしての楽天の取り組み紹介でした。
前半は割と普通の内容だったのですが、後半がとても興味深かったので、内容紹介をしてみたいと思います。
この記事の目次
RPAはデジタルレイバーではなく、ソフトウェア
よくRPAは、不足する人材を補完するために利用するものだと言われることがあります。RPAを使うことは、デジタルワーカーを雇うことと同じで、従来のシステム投資とは異なり、システム投資というよりも単純作業の労働者を雇用するということに近いという考え方です。RPAは人間と違って24時間休まず働くということで、デジタルレイバー（電子奴隷？）と呼ばれることもあります。
ところが、楽天の認識はそれとは違っていて、RPAの導入・活用はソフトウェア開発プロジェクトのような、「要件定義」「設計」「ロボット開発」「テスト」「リリース」「運用」という段取りで進められているようです。労働者の雇用ではなく、あくまでシステム開発・システム投資という見方です。
Blue Prismは以前のメディア向け説明会で「コーディングが不要」であり、専任のエンジニアでなくても簡単にロボットの開発が行えることを強調していた。しかし、楽天のようにインターネットをベースにビジネスを行っていて、かなりITリテラシーが高いと思われる企業でさえ、RPAは専任のデベロッパー、プロジェクトマネージャーなどを必要とするソフトウェア開発プロジェクトとして実行しているという事実は重要だ。
というように、プログラミングを社内の標準スキルにしようとする程の楽天ですら、RPA導入に際しては専用のプロジェクトチームを作って、ソフトウェア開発プロジェクトとして取り組んでいるのです。
結局RPAはプログラムロジックの塊である
このことは何を示しているのでしょうか。
現場主導でノンコーディングでデジタルレイバーが手に入るという触れ込みは眉に唾をつけて見る必要があるという事ではないでしょうか。
結局RPAもルールベースで動作を定義する以上、プログラムロジックの塊です。
RPA担当者は業務フローを解釈し、それをフローチャートにするなどし、RPAが解釈出来る表現に書き換えなければなりません。
やっていることはプログラム開発と同じです。
プログラムの開発にはコーディングはつきものですが、それよりもロジックの作成に時間を取られますし、スキルが必要になる部分です。
ノンコーディングという付加価値は、言ってみればオマケみたいなもので、キモはロジックの設計です。条件分岐やループ処理など制御が必要になります。
そして、業務プロセスというのは、ずっと同じとは限りません。環境の変化に応じて刻々と変わっていきます。
つまり設計されたロジックは変化に合わせたメンテナンスが必要です。人間ならば多少の変化は言われなくても柔軟に吸収する部分ではありますが、クラス１～２のRPAにはまだそのような柔軟さはありません。基本的に言われたこと以外出来ない馬鹿正直な電子奴隷です。
結局RPAはプログラムロジックの塊で、RPAの導入はシステム開発と同じであるという認識は合っていると思います。
RPAで効果が出てしまう組織にはどこか根本的な問題がある
RPAで効果が出る組織というのは、言ってみれば濡れた雑巾のように、業務フローをジャブジャブ絞る余地のあった組織と言えるのかも知れません。ITリテラシーが低く、人海戦術で人を投入することでしか対応が出来なかった組織とも言えます。
クラス１～２のRPAが出来るのはまだまだ単純労働です。複雑な判断や、微妙な条件の差異による振り分けなどは人手で行わなくてはなりません。つまりRPAに代行できる業務の範囲は限られます。
にもかかわらず、RPAで多大なる効果が出ているということは、裏を返すと、それだけの単純労働を人手で賄っていたということに他ならず、創意工夫・業務改善の敗北とも言えるでしょう。
少し穿った見方をすれば、組織によっては、システム投資よりも人件費の増額の方が受け入れられやすかったという面もあるのかもしれません。新しい取り組みよりも、「これまでのやり方の拡大」の方が予算が取りやすいということはしばしばあります。
いずれにせよ、昨今の「働き方改革ブーム」的には受けは良いのかもしれませんが、RPAで効果が出ているというのは、「今まで何してたん？」と、むしろ恥ずかしいことのようにも思えます。
RPAは魔法のツールではない
確かに、定型的業務量が圧倒的に多い組織にはRPAは適していると言えるでしょう。しかし、今のRPAに担えるのは、文字通りの定型業務です。
イレギュラーな処理にはほぼ対応出来ません。イレギュラーにも対応するとしたら、それもルールとしてレギュラー化する必要があります。
メンテナンスの手間は、処理が分岐すればするほど大変になります。継続的なメンテナンスは必ずついて回ります。作って終わりという訳にはいきません。そしてメンテナンスは訓練をしたスタッフが労働集約的に対応することになります。
RPAは、プログラミングという作業を、UIでラップしたものであり、作業内容としてはプログラミングとあまり変わりません。
メンテナンスするにしても、影響範囲の調査なども含めれば、それなりの工数が取られます。
そしてプログラミングの素養が身に付けば、そもそもRPAのような回りくどい方法ではなくて、ダイレクトにデータを操作できるVBAやGAS、その他スクリプト言語などで対応してしまった方が早いということになりえます。
結局、現状のRPAは、プログラミング言語の下位互換のようなものにしかすぎず、労働の質を劇的に変えるほどの魔法のツールではないと感じています。
ITと経営に関するお悩みはありませんか？
お一人で悩まれずに、些細なことだと思われることであっても、お気軽にご相談ください。
もちろん、お問い合わせメールへは無料で対応いたします。