"怠け心"こそ進歩の源泉?

【連載】

はじめてのRPA導入 - 真の有効活用の指針とは?

【第4回】"怠け心"こそ進歩の源泉?

[2018/09/28 09:00]金井盛隆 ブックマーク ブックマーク

  • ソリューション
  • ● 関連キーワード
  • RPA

ソリューション

前回は、RPAの部品化の必要性や、RPAが巨大化した場合の難点、さらには複数のRPAを束ねる外部の仕組み(ワークフローなど)の必要性について説明しました。

4回目となる今回は、RPAを適用すべき業務エリアをどのように選んだらいいのかについて考えてみましょう。

“正しく”怠けるということ

科学の発展について論じるときによく言われる言葉に、「科学は、怠ける気持ちがあるからこそ進歩する」というものがあります。ここで言われている「怠ける気持ち」とは、単なるサボりというよりは、「本質的でないものはなるべく機械に任せてしまいましょう」ということでしょう。つまり、「”正しく”怠けることで進歩する」というわけです。

では、これをRPAの世界で考えた場合、「正しく怠ける」とは、具体的にどのような状態を指すのでしょうか。

RPAの導入はなぜ失敗するのか?

まず、「RPAの導入はなぜ失敗するのか」というところから、順を追って考えてみましょう。プロジェクトが失敗する大きな理由の1つは、RPAのことだけを考えて、近視眼的に導入してしまっていることにあります。

英アーンスト・アンド・ヤング社(以下、EY社)の分析によると、RPA単体の初期導入プロジェクトは、実に30~50%が失敗に終わるようです。詳細はEY社の記事『Get ready for Robotic Process Automation』に譲りますが、主な理由として以下のものが挙げられています。

    失敗するRPAプロジェクトに見られる10の問題点
  1. プロジェクトをIT部門のみが主導している(ビジネス部門を巻き込めていない)
  2. PoCを、RPA導入のビジネスケースが不在のまま実施してしまう
  3. RPA導入後の体制が考慮されていない
  4. 継続的な改善が考慮されておらず、RPAの導入自体が目的化している
  5. RPAの対象業務が複雑すぎる
  6. RPAの開発手法が旧態依然としている (ビジネスが求めるスピード感を確保できない)
  7. RPAを作り込みすぎてしまう (あるいは、業務がRPAの対象として最適ではない)
  8. ITインフラが考慮されていない (ロボットの配布先の確保や、ITセキュリティ部門の巻き込みなど)
  9. RPAのみでROIを達成できると考えてしまう
  10. PoC実施時のスキルセットで本番用のRPAが作成できると考えてしまう

出典:”Get ready for Robotic Process Automation” by Chris Lamberton (June, 2017)/筆者による意訳

RPAは、今やIT業界のトレンドと言えます。それを絶対的な”善”と捉え、実行に移すことに疑問を差し挟む人は、あまりいないのかもしれません。しかし、そのようにして始まったプロジェクトが、知らず知らずのうちに破綻していくのです。プロジェクトの結果としてたくさんのロボットが完成し、出来上がったロボットの数そのものが成果であると錯覚してしまいます。このようなプロジェクトは、短期的には社内で高く評価されることがあるかもしれません。しかし、その評価は一時的なものです。往々にして、数多くのRPAが部門ごとに「勝手に」導入され、管理やメンテナンスの面で収拾がつかなくなり、当初想定したほどROIが出ない、といった事態が発生します。

昨今では、RPA市場の成熟に伴い、徐々にこのようなRPA単体プロジェクトの問題点が顕在化してきています。実際、筆者のところにはお客様からこの類の相談を持ちかけられることが多くなりました。

前回述べたとおり、RPA導入の際には、RPAを束ねる外部の仕組み(ワークフローなど)を合わせて検討すべきだと言えるでしょう。

RPAの導入に適した業務領域を知るには?

RPA導入を成功させるには、RPAを業務の「どこに導入するのか」も重要になります。RPAの導入に適した業務領域は、ボリュームゾーン( = 単純×大量)です。これは、単に業務量の多寡だけではなく、「数々の業務から共通項を見いだし、標準化することでボリュームゾーンに仕立てる」という意味合いも内包しています。

例えば、とある企業では、特定の端末から引き出された情報を突合する業務を、複数の部門で各々実施している、という重複がありました。個々の部門の負荷はそれほどではないとしても、これらを全てRPAの処理としてまとめて汎用化できれば、かなりのボリューム減を狙うことができます。

このようなボリュームゾーンを知るには、具体的にはどのようにしたらいいのでしょうか。ここでは2つのアプローチを考えてみましょう。

人間による業務分析

これは、人間が手動で現行業務プロセスを確認し、プロセスの見直しを適宜行いながら、RPAを導入できるボリュームゾーンを探る手法です。ここで重要なのは、導入効果を金額で試算することです。

人間による業務分析の良いところは、業務の意味合いを含めて総合的に分析を行えるところです。ボリュームゾーンを探るだけでなく、対象業務の重要性(RPAが本質的な業務の橋渡しをできているか)を探る意味でも、人間による業務分析は有効であると言えるでしょう。

この業務分析作業は、ユーザー企業が独自に実施することもできますし、外部のコンサルティング企業に委託して客観的に実施することもできます。

システムによる業務分析

業務分析のためのツールを活用して、定性的かつ定量的に業務分析を行うことも可能です。「従業員が、業務時間をどのように使っているのか」「どのアプリケーションのどの画面を使っているのか」「どのアプリケーションからどのアプリケーションへの画面切り替えが多いのか」などのさまざまな情報を、ユーザー単位/部門単位/企業単位で集計できます。

業務分析ツールのなかには、RPAの導入ポイントを具体的に示してくれたり、RPAの導入効果を金額換算で示してくれたりするものもあります。

業務分析ツールの画面例。業務改善ポイントと業務改善効果(金額)が示されている

システム的な分析を行うことのメリットとしては、次のようなものがあります。

A. 定量的な分析結果が出る(RPA導入効果を数字で試算しやすい)
B. 人間による業務分析では気づくことのできない知見が得られる

Bの具体例を1つご紹介しましょう。とある企業で、システム的な業務分析により、毎週水曜の昼過ぎの時間帯に、なぜか社員がメールを一斉に参照していることが明らかになりました。このため、毎週水曜の生産性が若干下がっているようでした。調べてみると、毎週水曜のこの時間帯に人事から一斉メールが全社員宛てに送信されていることがわかりました。社員はそのメールを読んでいたようです。日中同時刻に、一斉に業務が中断されるのは非効率であるため、この企業ではメールの送信時刻を夜の時間帯にずらすことで、業務への影響を最小限にとどめることに成功しました。こうした”気づき”は、人間による業務分析(通常は業務単位で実施されます)だけではなかなか得られません。

人間による業務分析と、システムによる業務分析は、どちらか一方をやればいいというものではなく、互いに補完し合う関係にあると言えるでしょう。

ロボットの定義内容が簡単であればあるほど、メンテナンスコストが低く抑えられるという観点も重要となります。業務分析の結果をRPAの定義内容に落とし込む際の考慮点として、忘れないようにしたいものです。

RPAプロジェクト成功のための必要条件

RPA導入にはコストがかかります。作成コストもかかりますし、メンテナンスコストもかかります。手当たり次第にRPAを導入しても、無駄な高速道路と同じで、有意なメリットは得られません。前述のとおり、RPAの導入にあたってはボリュームゾーンや重要な業務を狙うべきです。

また、RPA導入前に業務プロセスの見直しを行うことも重要です。本連載の第1回でも述べたとおり、安易にRPAを導入すると、現状の業務とシステムを上塗りして定着させてしまい、取り返しのつかない事態になる危険性があります。

そうしたリスクを回避するには、プロジェクトの統制確保が重要です。各部門が勝手気ままにRPAを導入したり、業務プロセスの見直しをせず拙速にRPAを導入したりする状況を発生させてはいけません。

RPAプロジェクト成功のための必要条件は、次の3つです。

- RPAに適した業務領域を選ぶこと
- 業務プロセスの見直しを行うこと
- プロジェクトのガバナンスを確保すること

プロジェクトのガバナンスが確保されれば、作るだけ作って放置される”野良ロボ”の削減にもおのずとつながります。

* * *

RPAの導入を真に意味のあるものにするには、「正しく怠ける発想」を持つ必要があります。「正しく怠ける」とは、真に導入効果が得られる業務領域を選択し、無駄なロボットは作らないということです。

言われてみれば当たり前のことですが、実際にこれができている企業は意外と多くありません。筆者は、RPA導入を検討している企業から、セールスの初期段階において、「とりあえず、まずは思いついた業務領域からRPAを導入してみて、様子を見てから今後の展開を決める」ということを、必ずと言っていいほど言われます。多少なりとも業務分析をした結果、RPAの対象業務領域を選んだということであればいいのですが、どうやら「安易なRPA導入」に陥っているケースが大半のように見受けられます。

1人で怠けていたら悪者ですが、周りの皆も一緒に”正しく”怠けさせられたらヒーローです。この発想を、ぜひ頭の片隅に置いてみてください。

著者紹介


ペガジャパン株式会社
シニア ソリューション コンサルタント
金井 盛隆 (Moritaka Kanai)

2012年11月より現職。ペガジャパンの親会社である米ペガシステムズ社が2016年4月にオープンスパン社を買収したことに伴い、同年6月よりRPAのプリセールス活動を開始。これまでの提案企業は50社を超え、導入検証、実プロジェクトでの実装経験もある。
2018年9月12日、虎ノ門ヒルズでペガジャパン毎年恒例のイベント『Customer Engagement Summit Tokyo』を実施(ご来場いただいた方、ありがとうございました。当社ソリューション コンサルタントによるデモは好評でした。デモの様子はこちら。プロフィール写真はその時に撮影したものです)。
前職は日本オラクル (2000年4月~2012年11月)。2児の父。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします
4070
2
【連載】はじめてのRPA導入 - 真の有効活用の指針とは? [4] "怠け心"こそ進歩の源泉?
前回は、RPAの部品化の必要性や、RPAが巨大化した場合の難点、さらには複数のRPAを束ねる外部の仕組み(ワークフローなど)の必要性について説明しました。4回目となる今回は、RPAを適用すべき業務エリアをどのように選んだらいいのかについて考えてみましょう。
https://news.mynavi.jp/itsearch/assets_c/2018/09/0927RPA_001I-thumb-600xauto-21851.jpg
前回は、RPAの部品化の必要性や、RPAが巨大化した場合の難点、さらには複数のRPAを束ねる外部の仕組み(ワークフローなど)の必要性について説明しました。4回目となる今回は、RPAを適用すべき業務エリアをどのように選んだらいいのかについて考えてみましょう。

会員登録(無料)

注目の特集/連載
AI人材に必要なもの
DMM.make AKIBAから生まれたスタートアップたち
はじめてのRPA導入
教えてカナコさん! これならわかるAI入門
RPA入門
PowerShell Core入門
Swagger 3.0 入門
徹底研究! ハイブリッドクラウド
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

ページの先頭に戻る