ICTコラム

第5回 RPA導入の推進体制と推進の手順

第4回では、民間企業と行政機関のRPA活用事例を紹介し、企業と行政機関がそれぞれどのようにRPAを活用しているかを解説しました。今回は、RPAを導入する際の推進体制と、推進の手順を具体的に解説いたします。

　RPAを導入する際の基本方針としてよく言われるのは、次のようなことだ。

　「RPAはスモールスタートで継続的に推進するべし」

　「導入してからがスタートなのだから、新入社員を育てるように、RPA(ロボット)を育てるべし」

　この基本方針は、RPAツールの長所と短所をよく踏まえたものとなっている。その理由は以下の通りである。

●RPAツールはノンプログラミングで利用でき、現場の業務担当者自身で自動化設定ができる。また変更も容易なため、試行錯誤しながら進めることができる。

●現場に埋もれている、RPAツールで自動化したい業務は、現場の業務担当者しか把握していない。したがって、大きな投資をして、システム部門や推進部門、外部ベンダーなどが外側から埋もれている業務を掘り起こして巻き取るよりも、内部から拡大していくほうがスムーズである。

●RPAツールの利用開始後、業務変更や自動化対象システムの変更が生じた場合、自動化シナリオの再チューニングが必要となる。再チューニングのような日々の微調整を行いやすいのも、内部の業務担当者にとってメリットである。

　以上の理由から、新人が配属される現場に育成責任者や育成指導者(トレーナー)を指定するのと同様に、新人ロボット(RPAツール)が使われる現場に、現場の業務を熟知するRPA推進者やRPA作成者を設置する、という基本方針が導かれるのである。

　各現場の推進者を効率的かつ横断的に支援するためには、「RPA推進部門」を設置する必要がある(図1参照)。RPA推進部門は、できればIT部門と分けるほうが望ましいだろう。IT部門はIT環境の安定運用を最優先に考える立場であるため、新しいITツールの活用においては、どうしてもブレーキ役にならざるを得ない。究極のブレーキ(安全)はRPAなどのITツールの追加利用は認めない、というものであるが、そのような結論に陥らないよう、アクセル役の推進部門とブレーキ役のIT部門を分け、両者の協議のもとに安全に利用を推進する体制を構築してもらいたい。

　なお、あくまでも主役は現場の業務担当者であり、推進部門やIT部門は現場のコーチ役やサポーターであることを意識してほしい。

　RP 導入における手順は、まずPoC(Proof of Concept)※により、RPAツールを実際に試してみて理解を深めたり、期待する効果が得られるか確認してみることが大事だ。次に、実際にいくつかの部署で本格利用(部分導入)しつつ、並行して全社導入計画や利用ルールなどを整理。準備が整ったら、全社への展開を始めるべきだ。特に初期導入段階が重要であり、ここを成功させれば、あとは水が高いところから低いところへと流れるように、RPAの推進力が生まれていく。そこで、RPAの初期導入段階について詳しく解説する(図2参照)。

　まず、初期段階の中で最も重要な第一歩が、「技術研修」である。技術研修は、IT部門や推進部門だけではなく、RPAの主役・主体となる現場の業務部門にこそ受けてもらいたい。技術研修を受けると、RPAによる自動化とはこういう仕組みだったのかと腑に落ち、自分の抱えている業務の中で、自動化できそうなものや、自動化したいものが思い浮かぶようになるからである。

　例えば、第四次産業革命時代の人材開発まで念頭に置いているある企業では、社員400名全員がRPA技術研修を受講したケースもある。ここまでいかなくても、少なくとも全社で10名以上、できれば各部署3名以上の受講をお勧めする。実際のところ、10名受講すると、2～3名はRPAツールが難しくて分からないと脱落し、2～3名はRPAツールによるモノづくりが面白いとのめり込む。こののめり込む2～3名を見つけ出し、各部署での推進役(伝道師や先遣隊とも言われる)を担ってもらうことがポイントとなる。この技術研修を通じて、従業員がRPAツールを使うのが面白い、自分でも早くやってみたい、という感想を持ってくれるようになれば、RPA導入の初期目標は半分達成したようなものである。

　RPAの基本が理解できたら、次は「自動化対象業務の選定(対象業務募集)」を行う。研修などの刺激により、自動化したい業務が浮かびやすい状態となっているので、このタイミングを逃さず、現場に埋もれている自動化できそうな業務を課題整理シートに書き出して整理する。推進部門はコーチとなり、RPAツールの技術で自動化できそうか、また自動化による費用対効果が出そうか、といった観点から側面支援してもらいたい。

　なお、この時、抜け漏れなく全業務を洗い出さなければと気負う必要はない。確かにシステム開発の場合は、後戻りして変更できない性質から、仕様凍結が最重要であったため、プロジェクト開始初期段階の調査・洗い出しが足りず、後から抜け漏れが出てきてしまうと、諦めなければならなかった。一方、RPAの場合は、現場の業務担当者自身で自動化シナリオのチューニングが可能であるため、自動化を進めることで新たな課題を見つけ、それをまた自動化する、というスパイラルアップが可能なのである。

　業務の洗い出しが完了したら、自動化シナリオを作ることになる。2～3日の研修を受講しただけでは、なかなか使いこなすところまではいかないので、推進組織から模倣可能なシナリオサンプルを提供するとか、現場で作り方のレクチャーをするとかして手厚くフォローし、現場の業務担当者が成功体験を味わえるように工夫してもらいたい。

　以上のプロセスを通じて、RPAツールを使いこなせたか、自社システムを動かせたか、業務からどの程度手離れできるようになったか(自動化できたか)、今後はどこまで広げられそうか、などの観点から評価を行う。評価もメンバーを集めて会議室で行うよりも、各推進担当者が自動化の成果発表会を設けて自動化における工夫を紹介しあったり、担当者間の自動化競争意識を生み出したりといった、現場を楽しく巻き込み続ける取り組みを行うほうが、その後の大きな成果につながってくる。

　次回はこのコラムの最終回として、RPAの導入・推進における注意点について解説する。

(次回へ続く)

※PoC(Proof of Concept)：日本語では「概念実証」と訳され、新しいプロジェクトが本当に実現可能かどうか、効果や効用、技術的な観点から検証する工程のこと。