失敗事例から学ぶRPA導入

RPA（Robotic Process Automation）は、いわゆる事務職の人々が担当しているデスクワークの一部などを、ソフトウェア型のロボットが代わりに実行するものです。現在はデスクワークのデジタル化が進み、アプリケーションを操作することが業務時間の多くを占めています。 このアプリケーションの操作のうち、反復性があり、手順が明確なものは、ソフトウェアによって自動的に実行することが可能なのです。

近年の日本企業は、働き方改革、人手不足、生産性の向上など、多くの課題を抱えています。RPAはこれらの課題を解決できるソリューションとして大きな注目を集めています。ソフトウェアロボットの作成にあたって、プログラミングの知識は不要である、という点も、RPAに注目が集まっている理由のひとつです。

一方で、注目を集めるあまり「企業においてRPA導入の意向が強すぎる」という状態にもなっています。RPAは決して万能のツールではありません。企業の状態によっては、人間が実施すべき業務は多くありますし、RPA化する以前に業務のやり方を改善すべきものもあるでしょう。

話題性の高さからRPAに過度の期待を持ち、目的が不明確なまま導入を推し進め、結果としてRPA導入のプロジェクトが失敗してしまう、というケースが多く見られるのが現状です。

失敗には共通するパターンがあります。ここではRPA導入の失敗にありがちなパターンをいくつか紹介します。

本来は手段であることが目的になってしまうと、物事はおうおうにして失敗します。

RPAは近年、大きな注目を集めるようになりました。RPAに関して目にする謳い文句などから、導入さえすればある程度業務効率化が実現できると思い、準備を怠ったり、RPAの導入段階で動き出すプロジェクトがしばしば見られます。会社の中でRPAに対する理解が進んでいないにもかかわらず、具体的な導入ツールまで決定しているケースさえあります。RPAを自社に導入することが目的になっているのです。これは手段と目的が入れ替わってしまっている典型的なパターンです。

RPAはあくまで、業務の一部を自動化するという「ソリューション」です。ソリューションとは課題を解決するためのツール、サービス、ノウハウです。つまり、自動化によってメリットが得られる業務を適切に選定しないと、RPAというソリューションを導入しても期待した効果は得られません。漠然とRPAを導入しても、効果は現れないのです。導入に際して発生する工数だけが膨らみ、結果逆効果なんてことにもなりかねません。

RPAを導入する前に、RPAとは何なのか、どのような業務に向いているのか、自社においてRPA化できる業務は何か、RPA化すべき業務は何か、といったことをひとつずつ検討する必要があります。業務の課題解決において、RPAが適切であるならばRPAを導入したほうが良いでしょうし、そうでなければ導入は見送るべきでしょう。

手段と目的が入れ替わることによる失敗を事前に防ぐための一例を挙げましょう。RPAの導入を目的としたプロジェクトを立ち上げるのではなく、業務効率の改善という広い視野を目的とするのです。目的を本質的な事柄に置き換えることで、RPAは業務効率の改善という「目的」を達成するための選択肢、つまり「手段」になります。

また、RPAを導入しないという結論に至ったとしても、自社の業務を分析することは決して無駄にはなりません。分析の結果、他の手段によって改善できると判明する可能性があります。まず初めにきちんと自社の業務の棚卸しを行い、可視化、分析することが重要であるのです。

この点を考慮しても、やはりRPAの導入ありきで業務改善のプロジェクトを開始するより、業務改善のプロジェクトにおける選択肢としてRPAを考慮することが望ましいでしょう。

KPI（Key Performance Indicator）とは、組織における目的達成の度合いを表す数字です。日本語では「重要業績評価指数」とも呼ばれます。ほとんどのプロジェクトにはKPIが設定され、いくつかのKPIをもとにプロジェクトの成果が評価されます。

RPA導入プロジェクトのKPIとしてしばしば設定されるのが「労働時間の削減」です。RPA導入に成功したプロジェクトを紹介しているニュース記事でも「どのくらい労働時間を削減したか」を強調しているケースが多く見られます。

ですが、RPAの導入と運用にはコストがかかります。仮に1ヶ月あたり100人日の労働時間を削減したとしても、RPAツールの継続的な運用に80人日を費やしているのであれば、実際に削減できている労働時間は20人日です。これを成功とみなすか失敗とみなすかは場合によって異なるでしょうが、少なくとも検討に値する数値ではあるでしょう。

このように、労働時間の削減だけでなく、コストパフォーマンスもRPA導入プロジェクトのKPIとして考慮したほうが、より正確にRPA導入の効果を測定することができます。

また、RPA化のメリットは多面的に存在します。例えば、RPAの導入によって業務の一部が適切に自動化されたなら、従業員はより重要な業務（コア業務）へ集中するための時間を確保できます。従業員がコア業務に集中した結果、コア業務のクオリティが向上、会社の利益への貢献度が向上したのなら、その点もKPIとして考慮すべきでしょう。

コア業務のクオリティを数値として表現する方法はさまざまです。顧客満足度、新規案件の開拓件数、企画立案の頻度といった指標が改善に向かったならば、RPAの導入は成功したと判断できます。逆に労働時間が削減できたとしても、生産性に係るような他のKPIが悪化したのであれば、RPAの導入は失敗したと判断すべきでしょう。

以上のように、RPA導入の効果を正しく測定するためには、複数のKPIを設定して総合的、且つ定量的に判断する必要があります。単純に労働時間の削減だけをKPIに設定してしまうと、労働時間の削減というメリットを他のデメリットが上回ってしまっても気づくことができず、気づけば失敗に終わってしまった、ということになりかねません。

失敗は次の成功を導くための検討材料となります。失敗を分析する手がかりを得るためにも、複数のKPIを事前に設定しておくことが重要なのです。

RPAが得意とする業務は「手順が明確な業務」かつ「反復性がある業務」です。RPAを導入する前に、どの業務をRPA化するのか検討する必要があります。ソフトウェアロボットは決められた手順に従って確実に業務をこなしますが、決められていない手順には対応できません。

RPA化の前準備としてよく行われる手段は、業務担当者へのヒアリングです。現場において単調な繰り返しの業務があるかどうか、その業務がどのくらい他の業務を圧迫しているか、といった生の声を集めることができます。RPA化の影響を直接受けるのは現場の従業員ですから、事前のヒアリングは必須といえるでしょう。

ヒアリングの弱点は、どうしてもヒアリングの対象者を絞る必要があるということと、業務担当者の主観が大きく影響する、ということです。実際にはRPA化できる業務を「RPA化できない」と証言したり、実際にはRPA化が難しい業務を「RPA化できる」と証言したりする可能性があります。また、業務に詳しい専門家でないと集めた意見を分析することが難しい、という点もヒアリングの弱点です。 時間がかかる上に「誰がヒアリングしたか」と「誰にヒアリングしたか」で大きく結果が変わってしまうリスクがあります。

こういったヒアリングの弱点を補うものとして、RPA導入支援ツール「D-Analyzer（ディーアナライザー）」のように、従業員が業務に用いるPCの操作履歴を分析し、RPA化できる業務を発見する手法もあります。ヒアリングよりも短期間でコストを抑えて、網羅的な情報収集が可能です。データ分析によって客観的な根拠が得られるため、現場主導の導入準備ができます。

更に昨今では「プロセスマイニング」という手法も注目を集めています。プロセスマイニングはERPなど複数システムの蓄積されたイベントログを分析し、様々なプロセスにおける課題を抽出するものです。分析にはビッグデータが必要となり、導入コストも大きいのがポイントです。

しかしながら「D-Analyzer」やプロセスマイニングのようなデータ分析も、業務改善において万能ではありません。当たり前ですが、データに含まれないことは発見できません。例えば、一般的に従業員のモチベーションをデータから推測することは困難でしょう。業務効率化の実現には広い視点でのアプローチが必要であり、会社にとって、そして従業員にとってどのようなメリットがあるかを考える上で、分析ツールやRPAツールは一手段であるということを忘れてはいけません。

とはいえ、RPAの導入にあたっては「どの業務がRPA化できるのか」「どの業務をRPA化するか」という事前の判断が必要不可欠です。この準備が不十分だと、RPAの導入は遅々として進まなくなり、最終的にRPA導入のプロジェクトそのものが失敗に終わる可能性が高くなります。

RPAは注目を集めているぶん、寄せられる期待も大きく、コストパフォーマンスの最大化を求めていきなり大幅な改善を図ろうとしてしまいがちです。ですが、先述したようにRPAを導入する前には入念な準備が必要です。大規模な業務を適切にRPA化するとなると、それだけ準備の時間は長くなり、多くの費用がかかります。

準備のために長い時間と多くの費用を費やしていると、経営陣は「いつになったらRPA化の効果が現れるのか」といって業を煮やし始めます。また、従業員も「準備に協力しているのに業務効率が良くならない」といってRPA導入プロジェクトに対して非協力的になってしまいます。

したがって、大規模な業務をいきなりRPA化するのではなく、まずはごく簡単で小規模な業務からRPA化を始め、小さくても目に見える成果をこまめに出していくほうが良いでしょう。部署単位やプロジェクト単位など、スモールスタートで始めてみることで、経営陣には成果をコンスタントに提示できますし、従業員には「少しずつRPA化していくことで業務効率が改善されていく」という見通しを示すことができます。

大規模な全体業務を分析することで小規模な業務に分解し、少しずつRPA化していく、という方針を採用するのも良いでしょう。最終的には大規模な業務をRPA化することにつながります。また、小規模な業務を少しずつ分析していくことで、大規模な業務のうち、どの業務がボトルネックになっているのかが見えてきます。RPA化をきっかけとして、業務全体の「見える化」を実現できるのです。

「見える化」によって、経営陣はボトルネックになっている業務に対して費用を投下する、という判断を下すための手がかりを得られます。また、従業員は「見える化」によって明らかになったボトルネックの業務を、どのように改善できるか考える手がかりを得られます。

どのようなプロジェクトにも言えることですが、ステークホルダーから協力的な姿勢を取り付けることは必要不可欠です。RPA導入プロジェクトも同様に、経営陣や従業員といったステークホルダーから協力的な姿勢を得られるように努めなければ、RPAの導入に失敗してしまう可能性が高くなります。長期的にはメリットが得られるとしても、ある程度短期的なスパンで目に見える成果が得られないと、人間は不安を抱いてしまうのです。

RPAによる業務効率の改善がある程度うまくいくようになると「すべての業務をRPA化してしまおう」という意見が社内から出るようになります。ですが、既に社内に存在するサービスやツールを利用すれば済んでしまう業務をわざわざRPA化する必要はありません。

例えば、経費精算の処理をRPA化しようという意見があったとします。どのように経費精算が処理されているのか分析した結果、経費の精算をしたい社員が経理担当者へ依頼メールを送信し、受信したメールの情報をもとに経理担当者が勘定システムへ経費精算の入力を実施していることがわかったとします。業務プロセスは明確で反復性があります。したがって、RPA化することは可能です。

ですがこのような場合は、社員・経理担当者・勘定システムをつなぐワークフローを搭載したソフトウェアを活用したほうが効果的でしょう。経費申請には人による承認のフローが必要ですし、それを除くとRPA化の範囲が狭すぎます。申請から通知、承認といった流れを包括したワークフローシステムを利用したほうが、汎用性も高く、トータルでは効率的になります。

「失敗パターン1」でも述べましたが、あくまでRPAは課題を解決するための一つの手段です。他の解決手段を採用したほうが効果的な場合もあります。向き不向きを見極めたうえで、RPAの導入を決定するべきでしょう。

RPAの導入に失敗するパターンをいくつかご紹介しました。改めて失敗の例を整理しましょう。

上記のパターンはあくまで失敗例の一部です。

実のところ、ご紹介した失敗のパターンは、まったく別種のプロジェクトにも共通するパターンです。RPAは大きく注目を集めているぶん、十分な理解が進むより先に導入の意向が強くなりがちであり、結果として多くの失敗事例が生まれているのです。

まずはRPAの導入に失敗しないために、さまざまな失敗のパターンをよく調べることが重要です。また、失敗のパターンを知っておけば、仮に失敗したとしても次の成功へつなげるための検討材料を素早く得ることができます。

本記事が、RPAを導入するかどうか検討する際の一助となれば幸いです。