1. TOP
  2. ブログ
  3. RPA導入ッ!!!成功した人、失敗した人

RPA導入ッ!!!成功した人、失敗した人

数年前から巷でよく聞かれるようになった「RPA」というキーワードは、いまや業務効率化の世界で聞かないことはまずない、常識のようなワードになってきました。
しかしながら、RPA導入・運営支援サービスを行うバーチャレクス・コンサルティング株式会社が実施した調査によれば、RPA導入済み企業において「運用上の課題や不安ごと/困りごと」が「かなりある」「多少はある」をあわせた割合は83%にも上ります。
今回は、私が勤めていた会社において経験したRPAの導入事例を、失敗した部署と成功した部署それぞれで紹介した上で成功要因/失敗要因について考察していきたいと思います。

失敗した部署:課長はやる気満々!

まずは失敗した事例をご紹介しましょう。
私が過去に所属していた部署Aでは、以前から業務の慢性的な遅滞が問題となっており、私の在籍中には自らVBAの専任者として業務の自動化に取り組んでいました。その結果生産性向上の成果を挙げてはいましたが、まだまだ遅滞の解消には至っていない状況でした。その後私が別担当に人事異動することになり、VBAの専任者がいなくなってしまい業務の自動化がスピードダウンするかに思われたとき、新しい課長がRPAの導入に意欲的に取り組みはじめたのです。私は非常に感心し、新しい担当での仕事をしつつ期待して観察していたのですが、導入当初から課長のやる気とは裏腹に不安なものを感じていました…。

社員の反応はイマイチ…

私が最も不安に感じたのは社員の反応でした。
元々業務自動化の専任チームがいたせいなのか、それとも人の入れ代わりが激しい部署だからなのか、部署Aの社員達は、実はあまり業務自動化ということに関心がなく、「誰かがやってくれたらいいんじゃないの?俺達の仕事じゃないでしょ?」という感覚が強かったのです。RPAは「マニュアルに載っていない仕事まで熟知した現場社員が、ボトムアップによる自動化を実現する」ということに適したツールです。現場の社員達の意識をいかにして業務の自動化に向けさせるか、現場の仕事をいかにして自動化しやすく整理するか、そこがキモといえます。部署AのRPA導入は、この時点で「成功のレール」から外れていたのかもしれません。

導入手法

部署Aの導入手法は以下のようになっていました。

1.RPA推進チームを結成

実業務を行う社員のうち、比較的経歴の長い社員を課長が選抜し、「RPA推進チーム」を結成しました。

2.ある一つの業務をサンプルとして、チームメンバー各自でRPAツールによる自動化を検討

次に、「RPA推進チーム」全員が各自でRPAツールの習熟も兼ねて一つの作業についてのRPA化に取り組み、その結果を互いに発表しあい、シナリオの作り方などについて検討しました。

3.検討した内容を活用し、他にRPA化できる作業を探し、RPA化を実施

そして、各自でその他の作業についてRPA化できるものを探し、各々自動化していく、という手法をとったのです。

いかがでしょう?手法としては悪くないように感じるのではないでしょうか?
しかし、結果的にこの方法はうまくいかなかったのです。

結果、現在

現在、部署AにおけるRPA化は完全にストップしている状態になっています。
課長が大々的に「RPAに取り組んでいます!成果も出ています!」とアピールしてしまった手前「やっぱりやめます」とも言い出せず、さりとてRPA推進チームを動かすこともできず、完全に進退窮まった、という印象です。

考察:何が悪かったのか?よかった点はあるか?

先程導入手法について「悪くはないように感じるのではないでしょうか?」と申し上げましたが、私の目から見ると「成功のレール」から外れる要因がいくつも見えてきます。

まず、「RPA推進チーム」のメンバー選出方法です。
前述のとおり、RPAは現場社員からのボトムアップに適したツールです。では、ボトムアップを行うのはどのような現場社員でしょう?それはズバリ、「今の仕事が面倒だと感じている社員」と、「そもそも自動化することが好きな社員」です。部署Aでは課長が「実業務を行う社員のうち、比較的経歴の長い社員」を選出しました。課長からすれば「業務を熟知した信頼の置ける社員」という基準で選んだのでしょうが、残念ながら彼らは「今の仕事に順応した社員」であり、「そもそも自動化することに興味がない社員」でした。自分達は自動化しなくてもスイスイと仕事ができるのですから当たり前といえば当たり前かもしれませんね。そもそも「ボトムアップに適したツール」を「トップダウンで選んだ社員」に推進させるということ自体に矛盾があったように思います。「ボトムアップに適したツール」はやはり「ボトムアップで選ばれた社員」、すなわち挙手制で名乗り出た社員に任せるべきでした。

次に「各自でRPAツールの習熟も兼ねて、一つの作業についてのRPA化に取り組み」という点にも、失敗の要因があったと思います。詳しく書きませんでしたが、実はこの「一つの作業」というのも課長が自ら選出した作業だったのです。このことからも課長の並々ならぬ意欲が見て取れますが、RPAで大事なのは先ほどから取り上げている様に、あくまで「ボトムアップ」です。この「一つの作業」を選ぶのは推進メンバーに任せるべきでした。結果、この時課長が選んだ「一つの作業」は「VBAの操作をRPAにやらせる」というだけの、私から見れば「RPA化する価値のない作業」で、推進メンバーも「お題だからやるしかないか…」というモチベーションでやっていた、というのが実態でした。これでは次のステップで「各自でその他の作業についてRPA化できるものを探し、各々自動化していく」というところでやっとボトムアップにシフトしたところで、メンバーのモチベーションはガタガタで、とても「成功のレール」に戻すことなどできはしないでしょう。

成功した部署:担当者が自主的に動いた!

ここからはお待ちかねの、成功事例についてお話します。
私は部署Aから人事異動した後、部門全体の業務効率化を推進する担当に着任しました。
その担当において、かつて部署Aで一緒に仕事をした後輩から「システムへの商品登録作業をRPAしたいんですが…」という相談を受けたのです。
勿論私は喜んでこの相談に乗り、後輩と一緒に二人三脚でRPA化に取り組みました。
手法としては以下のように実施しました。

やりたい内容とその目的をじっくり聞く

まずは「ボトムアップ」を大切にし、「何をやりたいのか」「その目的は何か」ということをじっくりと聞くところから始めました。
結果、「商品登録をしたい」という内容でしたがその実態は、「決まった日に各店舗から受け取る、「特定商品の発注依頼」のベースを本部で一括登録したい」「各店舗では商品の個数を入力するだけで済むので業務負担が減らせる」ということだとわかりました。

やろうとしている業務を(簡単な)標準業務フローに落とし込む

次に「やるべき作業」を明確化し、何をRPAでやるべきか、何をRPA以外の手段で実施するべきか(例えば簡単なVBAと組み合わせるのか、人間に判断させるのか)を検討した上で、RPA化した場合にどのような順番で実施するのが効率がよいかを検討しました。

最小限の機能の実装から始める

そして「この部分は完全な単純作業」という部分を切り出し、「日付を指定して起動すれば1日分のベースを作る」というRPAシナリオを最初に作りました。この段階ではまだ10日分登録したければ10回操作する必要がありましたが、それでも1日分の登録作業は自動なのでかなり作業としては楽になりました。

アドバイスだけして担当者に任せる

あとは「機能の拡張」、すなわち10日分の処理も1回の操作で実施する機能を搭載するフェーズになるわけですが、ここはアドバイスだけして後輩に任せることにしました。これは計画して実行したわけではなく、単純に私自身が自分の業務に戻るためだったのですが、結果的にこれが後輩の自主性を高める結果になったのだと思います。
当然、ここまでやれば「10日分の作業を自動で連続実行する」というところまでやりたいのが人情です。しかしながらそのためには「予め用意されたリストから情報を読み取る」という機能が必要でした。「ファイルの場所を指定」「ファイル名を指定」「リストをどうやって読み取るのかを指定」と、なかなかハードルが上がってくるので、後輩には「こういうやり方があるよ」ということだけ伝え、「まぁそこまでやるのは難しいから、無理にやらなくてもいいと思うよ」と言って指導を終えました。
実際のところ、RPAによくある(必ずではないのであるかどうかは検討段階でチェックが必要です)「シナリオ自動生成機能」で記録できるのは「書き込む」「クリックする」などの「アウトプット」に属する範疇で、「リストを読み込む」「ファイルを取り込む」といった「インプット」に相当する部分は自分でアクションを引っ張ってきて一からシナリオを組む必要があります。これはちゃんと作ろうとするとかなりハードルが高く、やり方や基本的な概念については教えたものの後輩もそこまではしないだろうな、と思っていたのですが…。

結果、現在

前述の話から1ヶ月ほどして、後輩から再び相談がありました。
曰く、「連続処理させてるんですが、うまくいかない場所があって…」とのこと。
「え!?」と思いました。プログラミング知識ゼロの後輩が、プログラミング的な考え方が必要な「連続処理」「データリスト読み込み」といったアルゴリズムを構築していたのです。その中のちょっとした部分がよくなくて処理がうまく進まず、その相談を持ちかけられたわけですが、基本的な内容は完璧でした。彼は私から与えられたヒントを頼りに、自ら考え、調べ、実践し、トライアンドエラーを繰り返して「答え」にほぼ辿り着いていたのです。
後輩の成長を目の当たりにした私の感動と興奮がお分かりいただけるでしょうか(笑)。
彼は現在、さらに先へ進み、RPAツールの中のスクリプトという、プログラミングをして「かゆいところに手が届く」アクションを作る機能にまで手を伸ばし、さらなる自動化・RPA化のために自発的な開発を行っています。

考察:何がよかったのか?改善点はあるか?

手前味噌で恐縮ですが、やはり後輩の自主性を尊重したところに勝因があるかな、と思いました。まずそもそも、自らRPA化する業務を見つけ、相談してきたという自主性の高い後輩を指導できた点が大きかったです。また、私はこれとは別にVBAの勉強会やセミナーなども開いておりまして、プログラミングの指導も行ってきました。その経験から、「ヒントだけ与えてあとは考えさせる」という指導をモットーにしてきたので、この事例でも「何をやるべきだと思う?」「最小限の機能はどれだろうか?」「どうやったらRPAがうまく動くだろうか?」と問いかけ、後輩からアイディアが浮かんでくるのを待ちました。
これも一種の「ボトムアップ」というわけですが、結果、自ら取り組みを始めた彼は、ヒントを頼りに自ら考え、試し、自発的にRPAシナリオを作成する、立派な「RPA人材」へと成長したのです。

まとめ

いかがでしょうか。
RPAを推進する時にとにかく必要なのは、1にも2にも「ボトムアップ」と「自主性」だということが、この記事を通じて私がお伝えしたかったことです。
会社という組織はとかくトップダウンで物事を進めがちで、そこに「社員の個性」や「一個人の意見」というものは考慮されないことがままあると思います。
RPAは、単純な「業務の自動化」のみならず、自動化を推進していく中での「業務プロセスの最適化(BPR)」や、「自律的な人材の育成」にもつながっていく、非常に強力なツールです。
しかしそれも、社員を信じ、「ボトムアップ」を推奨し、その成果を承認するという体制あってこそです。
これを機に社内にボトムアップの風を吹かせてみませんか?
そして是非この強力なツールの強みを最大限に引き出し、御社の業績を飛躍的に向上させる武器にしてください!

建設・土木業界向け 5分でわかるCAD・BIM・CIMの ホワイトペーパー配布中!

CAD・BIM・CIMの
❶データ活用方法
❷主要ソフトウェア
❸カスタマイズ
❹プログラミング
についてまとめたホワイトペーパーを配布中

    ホワイトペーパーフォームバナー

    【DL可能な資料タイトル】

    • ・プログラムによる建築/土木設計のQCD(品質/コスト/期間)向上
    • ・BIM/CIMの導入から活用までの手引書
    • ・大手ゼネコンBIM活用事例と建設業界のDXについて
    • ・デジタルツイン白書
    • ・建設業/製造業におけるデジタルツインの実現性と施設管理への応用

    詳細はこちら>>>

    PAGE TOP