サーバー型RPAをやるくらいなら、システム開発をした方が良いのか？

デスクトップ型とサーバー型...。この２つのRPAは、原因も定かでない戦いを４年（くらい？）も続けていた。

はじめは局地戦が続いていたが、おれが志願するころには戦線が拡大し、日本に存在する5,000社以上の企業が戦火に巻き込まれていった。

おれは戦った（主にプロパガンダと）。
はじめは生まれ故郷の Blue Prism のためと信じて戦った。

だが、戦いは長引くばかりで終わりがなかった。
おれは疲れた。誰もかれもが疲れていた・・・

 *1

タ　イ　ト　ル　は　、　釣　り　で　す　。

　
　※ これ以降、サーバー型RPAという言葉は登場しません。

　　 誤解を招くことが多いからです。

　　 ・・・似たようなのは、出てきます。

RPAの分類

RPAの分類について、いろいろ意見はあると思いますが、

個人的には以下の２つに分類するのがスッキリするように

考えています。

EUC型RPA

• ユーザーが開発（自分で作れば早くて安くて思い通り）
• 自分または自部門の課題を解決するのが目的
• 巧緻より拙速（ドキュメントはできるだけ作らないで済ませたい・・・）
• 費用対効果より働き方改革

エンタープライズRPA

• 開発者はコストを考えて最適配置（オフショアも選択肢）
• どの課題解決を優先するかは全体を見て判断
• 拙速より巧緻（保守性を考え、所定のドキュメントを作成）
• 働き方改革より費用対効果

・・・異論はあると思います。

どちらかに分類しきれないスタイルもあると思います。

しかし、キレイに割り切れなくても、やはり分類は必要です。

「どうしても納得感がない・・・」という方は、お手数ですが、

コメントいただけますと幸いです。

エンタープライズRPA はマイナー 

さて、序盤から根拠なしで恐縮ですが、

日本で主流なのはEUC型RPAである・・・と考えています。

「RPA」でGoogle検索して出てくる日本語記事を読んだとき、

ほとんどの場合、EUC型RPAが適合すると思います。

エンタープライズRPAはマイナーです。

この記事の主題

この記事の主題は、そのマイナーなエンタープライズRPAに

対してしばしば行われる批判：

エ　ン　タ　ー　プ　ラ　イ　ズ　R　P　A　を　
や　る　く　ら　い　な　ら　、　シ　ス　テ　ム　
開　発　を　し　た　方　が　良　い　

への 反論 です。

エンタープライズRPAの投資回収速度は、システム開発のそれの3.6倍

実際に両方やって比較した事例を読み解く

いきなり結論から書きますが、タイトルにあるように、

エンタープライズRPAはシステム開発よりも効果が出ます。

それも3.6倍というハイスコアです。

この数字は、海外の調査結果から引用しています。

Robotic Process Automation at Telefónica O2

これは、LSE（ロンドン・スクール・オブ・エコノミクス）の

レスリー・ウィルコックス教授が共著者の論文ですね。

（氏は元々、アウトソーシングの権威です）

さて、どういう文脈で 3.6倍 という数字が使われているのでしょうか。

それは以下の通りとなります。

Telefónica O2 wanted to test whether the BPMS could achieve the same results as RPA. A
team was assigned to automate two processes with BPMS technology. One of the processes was identical to the RPA trial (SIM swaps) and one process was different but with similar attributes. The BPMS team successfully automated the two processes within three weeks, which was comparable to the RPA trial. However, when it came to the financials, RPA was the clear winner. Butterfield said, “Our projections showed that RPA for 10 automated processes would pay back in 10 months. In contrast, the BPMS was going to take up to three years to payback.”5 The three-year business cases estimated zero net financial benefits with BPMS and nearly £1 million with RPA. Regarding the last proof of concept question, “Will RPA provide enough of a return on investment?”, the answer was clearly yes.

The financial discrepancy between the business cases for BPMS and RPA was attributed to BPMS’s additional IT resources. BPMS projects required IT resources like developers and SCRUM teams, whereas process improvement staff members from Back Office executed RPA projects. The Head of Back Office would just reassign some people from a process improvement team to a process automation team with zero effect on the Back Office budget.

・・・要するに、

• SIMスワップという業務プロセスを Blue Prism（エンタープライズRPAの製品）とシステム開発（スクラッチではなく、BPMSという低コード開発プラットフォームを使用）を比較すると、両方とも最終的には同じことができる
• Blue Prism は10ヶ月で投資を回収できる
• システム開発は投資回収に３年かかる

という話です。

システム開発と同じレベルでドキュメントを作っても、

コーディング量や要員の前提スキルなどで差がつくのだと

解釈しています。

全てが 3.6倍になるわけではないが、3.6倍になる対象は多くある 

論文を読むとわかりますが、全ての業務プロセスが

エンタープライズRPA に向いているわけではなく、

したがって、何でもかんでも 3.6 倍の差が出るわけ

ではない・・・ということには注意が必要です。

ただ、論文はエンタープライズRPA に向いている業務

プロセスが多数あることも指摘しています。

個人の体験談

営業週報における数字の集計の自動化

外人の論文を引用するだけでは芸がないので、私個人の

体験も書きたいと思います。

私は4年前（2015年）、外資ITの営業をしていたのですが、

（外資ITの）営業というのは目標数字（Budget）という

ものがあり、それが達成できそうかどうか（Forecast）

・・・というのが本当に極めて重要です。

（なぜ重要か？・・・理由は長くなるので、割愛します）

さて、Forecastを計算するには、いまいまの商談をサマリする

必要がありますが、営業のロールによっては、困難を極めます。

なぜなら、SFA（Sales Force Automation: 案件管理）に商談の

データ自体は入っていますが、営業によって積算できる明細が

異なるからです。

SFA側で全ての営業に対して適切な積算を行い、ビュー・ダッシュ

ボードとして提供されていれば問題ありませんが、残念ながら

そうはなっていませんでした。

でも、SaaSなんてそんなもんじゃね？

したがって、私のForecastを計算するには、SaaSのSFAの画面を

何回もめくって数字を転記し、Excelで集計する必要があります。

こんな作業を業務時間中にやっていては仕事にならないので、

土曜日にやろうとしますが、やってみると半日は余裕、繁忙期

（明細が多い時期）には丸一日潰れます。

ふぁっきゅ（byキズ〇アイ）

APIで自動化すればいい・・・？ 

そこで、私はSaaSのREST APIを使って、集計を自動化しよう

と試みました。

私は元々がエンジニアなので、この程度のことは半日もあれば

できるはずです。REST API用のJavaのライブラリを使って、

200～300行程度のJavaプログラムを組むだけ・・・と思い

ましたが、実際は、あまりうまくいきませんでした。

苦戦の理由は以下です。

• APIのバリエーションが少ない①。画面での検索クエリのバリエーションと、APIのそれとの間にギャップがあった。重要なクエリをAPI経由で投げることができなかった
• APIのバリエーションが少ない②。API経由で明細を取ることは可能だが、明細のさらに明細を照会するAPIが無かった・・・しかし、それが必要やねん。。
• パフォーマンスが低い。APIはSQLのように結合問い合わせができないため、APIへのアクセスを大量にする必要があった。。なお、データセンターは北米にある模様（白目）

結局、APIでクエリしきれないところは、データの全量を

取ってきて、後でExcelを加工するオペレーションにしました。

パフォーマンスが低いから処理が結構、遅い・・・

結果、手作業よりは改善しましたが、

Excelでの加工は結構、面倒くさい・・・

自動化としては極めて、中途半端です。

RPAを使いたかった

Javaで完全自動化を目指せば良かった・・・わけ

じゃないですよね。

Java でロジックを作って、Excelにするところまで

やり切るのは大変です。

CSVファイル出力は比較的容易ですが、Excel はPOI

を使わないと難しいですし、

複数クラスを作ってJavaのプログラムを作ることを

考えると、Javadocも考えないと・・・単体テスト用

のクラスは？？・・・とてもじゃないけど大変です。

当時は手元にRPAツールが無かったので、上記のように

なりましたが、、後だしジャンケンのようで恐縮ですが、

ほぼ間違いなく、RPAツールを使っていれば、

もっと短い時間で完全な自動化ができたはずです。

しかも、JavaだのREST APIだのは意識することなく。

この辺りの感覚が、上記の論文の書きっぷりに大いに

共感するところです。

API は魔法のツールではない 

APIが公開されていれば、RPAではなくAPI連携したほうが良い

・・・という考え方が、有っても良いとは思います。

しかし、私自身の経験に照らし合わせると、なんとも

しらける机上の空論です。

APIというのは、UIほどには完備されないものです。

理由は簡単、SaaSの提供側や開発者にモチベーションが

無いからです。

誰が使うともわからないAPIを完備したところで、製品の

魅力にはつながりにくいです。

（一方で UIは、その機能を使うユーザーは必ず使います）

また、言い方は悪いかもしれませんが、

SaaS側のデータが自由自在にいつでもブッコ抜ける・・・

というのは、SaaS側にとって、あまりうれしいことでは

無いはずです。サブスクリプション・ビジネスですし。。

中には、ユーザーがシステムを活用できるように、

APIを積極的に提供しているシステムもあります。

ただ、それはそういう意図で作ったシステムだと

思います。どういうAPIがあるかは、システムを作る

ときの用途に強く依存しています。

なお、ここでは開発の話題だけに触れましたが、検討ポイント

は非機能要件も含めて、もっといろいろあると思います。

セキュリティ、可用性、拡張性・・・古いアーキテクチャの

API連携製品だと、意外とイマイチだったりするポイントです。

課金の話もありますよね。APIアクセスで課金しているSaaS

製品もあると思います。

EUC型RPA用の製品、エンタープライズRPA用の製品があるか

ちょっと話が変わりますが、

用途がEUC型RPA、エンタープライズRPAと２つあるのであれば、

それに特化した製品があるか・・・という疑問が浮かびます。

これについては根拠がなく、個人の感想を言うだけになりますが、

・・・たぶん、無い。どんなRPA製品でも、EUC型RPAに使う

ことができるし、エンタープライズRPAに使うこともできると思います。

ただ、「できる・できない」という議論は、多くの場合、

ほとんど意味がないとも思っています。

世の中、絶対に不可能なものよりも、やればできるけど、うーん

みたいなものの方が多いはずです。世界は白・黒の二色で塗り

つぶされているのではなく、見渡す限りの灰色です。

ただ、おそらく、製品によって向き・不向きはあると思います。

RPAをどっちの方向性で使うかを考え、それに向いた製品を

選ぶのが成功への近道ではないでしょうか。

まとめ

• EUC型RPA とエンタープライズRPA に分類した
• エンタープライズRPAがシステム開発よりも３倍以上、良いケースがある。そして、そんなケースが企業内にたくさんある
• RPAに幻想を抱きすぎてはいけないように、APIにも幻想を抱きすぎてはいけない。APIが普通に使いにくい場合もある
• 根拠のある議論が重要だ

API を使ったシステム開発が近道なのか、

RPAが近道なのか、

・・・一番の近道は、遠回りだったりもするので、

なかなか難しいですよね。

まだまだ、この旅の先は長いのか・・・

*1:民明書房「一般人の認識～RPA界のボトムズ～」p.59より