こんにちは。本連載を担当することになりましたペガジャパンの金井です。現在、RPA製品を中心とするソリューション・コンサルタントとして活動しています。

この連載では、筆者の過去2年間のRPA分野におけるプリセールス活動を基に、RPA導入において考慮すべき点やハマりやすい”落とし穴”などについて、特定の製品に偏らないかたちでご紹介していきます。RPAをこれから導入される方も、すでに導入中の方も、参考にしていただけると幸いです。

第1回となる今回は、RPAに期待を寄せるあまり生じ得るリスクについて説明します。

RPAは「流行りモノ」?

「流行りモノ」などと書くと、まるで短絡的で悪いもののようにも聞こえてしまいますが、実際RPAが流行していることは紛れもない事実です。

流行の理由としては、例えば「製品コンセプトが理解されやすく、キャッチーである」「AIとの関連で語られることが多い」「導入のハードルが低い」「働き方改革の1つの柱である長時間労働解消につながる」「人間を単純作業から解放する」「これまで実現したくてもできなかったことに対して、ある一定のブレークスルーをもたらしているように見える」などが挙げられます。

これらはいずれも、それ自体が悪いことではありません。しかし最近では、「RPAは”バンドエイド”である」、つまり「RPAは、一時的には有効だが、恒久的なソリューションにはなりにくい」という考え方が徐々に浸透してきています。それはなぜでしょうか。

RPA自体がレガシーと化すリスク

RPAだけを見ていると見失ってしまうものがあります。それは、業務全体の最適化をどのように実現するか、システム全体の将来像をどのように描くか、といった観点です。

実際、米ガートナーのアナリストは、「RPAの活用だけでは、デジタル改革の実現は不可能である」「RPA単体プロジェクトの30~50%が成果を上げられていない」という分析結果を発表しています。

筆者の経験に照らしてみても、ロボットのみの単体比較が先行し、本当の意味での業務改革が後回しになってしまう……というパターンが少なくなかったように思います。そうしたケースでは、担当者自身、中長期的な視点は重要であると理解しているものの、やはり、目先の課題や与えられたミッションを消化することだけに集中する傾向にあります。

それでは、「業務全体の最適化を後回しにしてしまう」とは、具体的にはどういう状態を指すのでしょうか。

例えば、本来は脱却しなければいけないエンドユーザー・コンピューティング(Excelマクロに象徴される煩雑/非効率な業務プロセス)をロボットによって自動化しても、業務が最適化されたことにはなりません。

あるいは、ロボットからレガシー・アプリケーションを操作することで、システムが最適化されたと思い込むケースも考えられます。本来であれば、レガシー・アプリケーションはさまざまな理由(稼動するOSのサポートが終了している、作成者がはるか昔に退職していてアプリケーション・ロジックがブラックボックス化されているなど)からリプレースされるべきもののはずです。

また、もともと無駄の多い作業をロボットに肩代わりさせることで、煩雑な業務から解放されたように感じることもあるでしょう。しかし、一見問題が解決したように見えても、今後、中長期的な観点で業務を最適化していく上で、この短期的なロボット導入が足かせになってしまうことがあるかもしれません。

安易にRPAを導入すると、現状の業務とシステムを上塗りして定着させてしまい、取り返しのつかない事態になる危険性に留意すべきです。

RPAは”魔法のツール”ではない

皆さんは今、なぜRPAを導入するのでしょうか。中長期的な視点に立ったとき、今のRPA導入はどのように位置づけられるでしょうか。RPAの導入そのものが、目的化してしまっていないでしょうか。ロボットはあくまで短期的な解決策(バンドエイド)であるという観点を忘れていないでしょうか。

RPAは業務最適化のための”魔法のツール”ではありません。その主たる用途は、突き詰めて考えると「APIを必要としないシステム連携」です。

RPAの主なユースケースとしては以下のようなものが考えられますが、これらは全てAPIを利用しないシステム連携だと言えます。

  1. 基幹システムのデータをフロントシステムにコピーする
    → 基幹システムとフロントシステムの間のシステム連携
  2. 株価調査など、Webから情報を収集する
    → 社外Webサイトとのシステム連携
  3. インターネットバンキングなどを操作する
    → 社外システムとのシステム連携
  4. 複数のシステムに格納されたデータ同士を照合(突合)する
    → 該当システム間のシステム連携
  5. 社内システム上のデータからExcelのレポートを作成する
    → 社内システムとExcelの間のシステム連携
  6. メーラーなどの社内アプリを操作する
    → メーラー、社内アプリに対するシステム連携


では、もしシステム連携のAPIが存在する場合、RPAを利用すべきでしょうか。それともAPIによるシステム連携を実施すべきでしょうか。例外はありますが、処理の実行効率、開発工数、保守性、コストなどの観点から考えると、一般的にはAPIを利用したほうがよいと言えます。

APIが存在する場合、システム連携にはAPIを活用すべき。RPAは、基本的にシステム連携のAPIが存在しない場合にのみ利用する

AIとRPAの関係性

AIを搭載したRPAが、あたかもSF映画に出てくるロボットのように自律的に動作することが「目指すべき将来像」のように語られることがあります。しかし、筆者はその考え方には懐疑的です。

もちろんこれは、AIそのものの可能性を否定するものではありません。AIは将来的に、人間を多くの単純作業から解放するものであることはほぼ間違いありません。

しかし、だからと言ってAIが必ずしもRPAに内包されなければいけないということにはなりません。AIは、人間とRPAの接点や、あるいは人間とRPAそれぞれの業務プロセスの中に存在してもいいはずです。AIは、むしろRPAの外に置かれることで、その真価を発揮するのではないでしょうか。

AIは業務プロセスの至る所に登場する。AIの共通化や再利用についても(RPAとは独立に)検討すべきだろう

* * *

連載の初回で言うことではないのかもしれませんが、RPAに過度な期待を抱くべきではありません。

RPAはあくまで”バンドエイド”であり、その用途はたかだか「システム連携」です。実際の業務は人間の介在(判断)なくして完結されません。RPAの流行に水を差すようではありますが、この考え方はRPAの真の有効活用を考える上で必要な観点だと筆者は考えます。

著者紹介


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

2012年11月より現職。ペガジャパンの親会社である米ペガシステムズ社が2016年4月にオープンスパン社を買収したことに伴い、同年6月よりRPAのプリセールス活動を開始。これまでの提案企業は50社を超え、導入検証、実プロジェクトでの実装経験もある。
小さい頃から大きな車を運転することが夢だったため、学生時代に大型免許を取得。しかし、現在に至るまで活用シーンはなし。趣味はビール、ラーメン(主に二郎系)、映画鑑賞。
前職は日本オラクル (2000年4月~2012年11月)。2児の父。