RPAの推進に必須なRPAOpsという考え方

はじめに

みなさんはRPA使ってますか?

労働力不足にも関わらず、残業時間の削減が求められる日本において、RPAは働き方改革の特効薬として注目され、急速に広まりました。

RPAの普及速度はスマホ並みとのデータもあり、また、米国Gartner社は2020年度の企業や組織にとって重要なインパクトを持つ「戦略的テクノロジ・トレンドのトップ10」の第1位に「ハイパーオートメーション」を挙げました。このトレンドはRPAから始まっており、今後更に加速していく自動化の流れの中で、自動化を使いこなす企業とそうでない企業には圧倒的な生産性の差が生まれるため、今の段階からRPAにしっかり取り組んでおく事は企業戦略上必須と言えるでしょう。

一方、RPAに取り組んでみたものの、「ロボットが思ったよりよくこける・・」「属人化・ブラックボックス化していて直せない・・」といった、当初想定していなかった課題に直面した方々も多いのではないでしょうか。そして、ある程度推進した段階においては、「やたらと複雑な条件分岐が必要な業務があり、ロボットは開発したもののなかなか安定しない・・」「業務自体が非効率な気がするけれど、そのまま自動化して良かったのだろうか・・」といった新たな課題に直接するようになります。今回はこうした課題を紐解くために、RPAの推進に必須となるRPAOpsという考え方について紹介して行きたいと思います。

RPAOpsとは?

RPAOpsとは、RPAの推進に必須となるコンセプトをわかりやすく説明するために今回作った造語で、DevOpsやMLOpsに代表される一連のライフサイクルをシームレスに繋げる概念(xOps)をRPAにあてはめたものです。RPAの推進には3つの要素、「業務設計」「開発」「運用保守」が必須であり、その連携をどれだけ密にしてサイクルを回せるかがRPAの推進の成否を分ける鍵となります。

RPAの推進が上手く行っていないプロジェクトは、必ずこのいずれかの要素が欠けています。特に「RPA=ロボット開発」という印象がどうしても強く、開発に注力するプロジェクトが多いですが、RPAの生命線は運用保守であり、自動化の効果を最大化するために必須なのは業務設計です。「業務設計」「開発」「運用保守」の3つの要素が密に連携して初めて、RPAは真の効果を発揮します。
以下、RPAの推進におけるよくある失敗事例を紹介して行きます。

ユーザー部門での推進でよくある失敗事例

ユーザー部門での推進でよくある失敗事例は、業務設計と運用保守を考えずに開発だけ実施するケースです。

「RPAは簡単に作れる」「すぐに効果が出る」と聞いて、目の前の業務のロボット化に取り組みますが、業務プロセスが非効率なままロボット化されるため、複雑な条件分岐や例外条件などの影響で開発が必要以上に長期化します。様々な苦労を経て、一旦動くロボットが作れたとしても喜びは束の間で、運用を開始してみると、開発時に考慮できていなかった業務ロジックや開発時には出なかったシステムのポップアップやレスポンスの遅延など、想定外の要因でエラーが多発します。焦って直そうと思うものの、開発のルールを制定していないため、既にロボットは属人化・ブラックボックス化しており、そのロボットの開発者にしか直せない状態になっています。その開発者がいる間は、なんとか繰り返しの改修で凌げますが、このタイミングでも属人化・ブラックボックス化は容赦なく進みます。既にロボットは引き継げる状態ではないため、その開発者が異動する事になった場合、そのロボットも動かなくなり、そして誰も直せないため廃棄する事になるでしょう。これは、いわゆる「エクセルマクロ問題」と同様の問題であり、安定的にロボットを稼働させるためには、開発の段階から開発のルールを制定して属人化・ブラックボックス化を防ぎ、また、運用保守の体制とルールを整えておく事が重要となります。

システム部門での推進でよくある失敗事例

システム部門での推進でよくある失敗事例は、開発と運用保守は手厚いものの業務設計の観点がないケースです。

システム部門での推進だけに、開発ルールの策定や運用保守のルール策定はしっかりと実施するため、ロボットが開発できない、動かないと言ったような事象はあまり起きません。エラーが起きた際にロボットが属人化・ブラックボックス化していて直せないといった事もないでしょう。
これだけ見ると一見良さそうに思えますが、業務設計の観点が大きく抜け落ちている事が問題になります。ロボット自体は開発・運用されるようになりますが、業務設計の観点がないため、非効率なロボットや似たようなロボット、そもそも不要であるロボットなどが量産されるようになります。
運用保守においても業務設計の観点がないため、エラーが起きた際は、その根本原因がそもそもの業務設計にあったとしても、業務設計を見直すのではなく、ロボットの側の改修で対応しようとしてしまいます。しかし、根本原因が解消されていないため、なかなかエラーは収まらず、その度にロボットの改修を繰り返す事で、ロボットが肥大化・複雑化していきます。こうしたロボットは「手のかかるロボット」として運用保守の工数を継続的に逼迫させてしまうため、RPAの推進におけるボトルネックとなって行きます。運用保守チームでの解決に閉じて、無理にロボットの改修で対応しようとせずに、業務設計の観点から業務自体を見直し、業務もロボットもシンプルな状態を保つ事が重要となります。

また、システム部門での推進の多くは、ユーザからの要望ベースでの開発のため、ユーザがRPAと聞いて想起できる範囲での自動化に留まり、自動化のレベルはなかなか向上して行きません。ある程度ロボットを開発した所で、「単純作業はもうほとんど自動化したから・・」とユーザーから開発要望が出てこなくなる、いわゆる「案件枯渇問題」に直面します。開発と運用保守だけを手厚くするのではなく、業務設計の観点を持ちながらユーザーにしっかりと寄り添い、ユーザーのRPAに対する理解度や活用レベルを引き上げていく事も重要となります。


RPA推進成熟度モデル

RPAの推進には大きく5つのステージがあり、それを成熟度モデルとして可視化したものが以下の図になります。

RPA導入(PoC)の段階であるステージ1から、RPAに対する理解と対応が必要な項目が徐々に整理されて行き、開発基盤を強化するステージ2、運用保守基盤を強化するステージ3へと進んで行きます。多くのRPAプロジェクトがステージ1と2で留まっていますが、ステージ3まで進むと、ロボットがある程度安定的に稼働し始めます。そこから、自動化の効果を大きくするために、改めて業務視点に立ち返り、業務設計の強化を進めるステージ4に入ります。業務の集約化や標準化、簡素化を通じて、自動化の効果は高まりますが、あくまで現行の業務プロセス(AsIs)をベースとした業務の再設計となります。そしてそこから、自動化の効果を最大化させるために「自動化を前提とした業務設計」を行うステージ5に入ります。ステージ5では、ステージ4のような現行の業務プロセスをベースとした業務設計ではなく、業務の目的に立ち返った上で、RPAやAIを駆使した自動化を前提とした業務設計(高度自動化業務設計)を行い、自動化の効果を最大化させます。

これは自動車に例えてみるとわかりやすく、RPAが時速300キロを出せる車だとした場合、RPAの効果を最も高めるためにすべき事は何でしょうか。更にスピードが出るように改造する事でしょうか、細かいハンドル操作やブレーキングの性能を上げる事でしょうか。
正解は高速道路を作る事です。これがステージ5に相当します。どれだけ性能の良い車でも、複雑に入り組んだ道路や人が歩くのも大変なけもの道ではその性能を発揮する事ができないのと同様に、複雑な業務にRPAをそのまま適用しようとする事は、このような道に無理矢理自動車を走らせるようなものであり、RPAが持つ本来の効果を享受する事は出来ません。
RPAは人間には出せない速度を出す事ができ、疲れ知らずで1日中走り続ける事が出来ます。その効果を最大化するために目を向けるべきはRPAではなく、RPAが走る道(業務プロセス)になります。

RPAの推進においては、RPAを導入するPoCの段階、そして開発・運用保守のルールを策定するステージを経た上で、自動化の効果を最大化するために改めて業務視点に立ち返る事が重要になります。

まとめ

いかがでしたでしょうか。
RPAの推進に必須となる要素とその連携を表すRPAOpsという考え方、そしてRPAの推進レベルを成熟度モデルという形で紹介しました。
少しでもRPAの推進に従事されている方々の参考になれば幸いです。

成熟度モデルではステージ5まで紹介しましたが、この先には自動化の自動化というステージが待っているので、こちらもまた時期を見て書きたいと思います。