楽天の導入事例で見えたRPAは「ソフトウェア開発」というリアル

RPAベンダーのBlue Prismが都内でミニカンファレンスを開催した。これはBlue PrismのCTOや日本法人の代表が製品や戦略などについてプレゼンテーションを行い、その後、ユーザー事例として楽天株式会社、昭和リース株式会社、株式会社荏原製作所、双日株式会社などが登壇して、自社のRPA導入について解説を行い、最後にパートナーが登壇するというシングルトラック、半日のカンファレンスだ。

Blue PrismのCTOでCo-Founderのデイブ・モス氏

Blue Prismはイギリスに本社を置くRPA（Robotic Process Automation）ベンダーの最古参であり、RPAという言葉を作り出したと自負する企業である。特に単なるデスクトップアプリの自動化ではなく「Connected-RPA」というキャッチコピーで、他社とは差別化を図ろうとしている。基調講演ではBlue Prismの戦略や海外の事例、製品のコンセプトなどが紹介された。またデスクトップのスクリプティングをベースにした自動化とは差別化を行う意味で、サーバーサイドで稼働する自動化プロセス及び文書処理、メール処理などが紹介された。

Blue PrismのConnected-RPAの概要

しかしConnected-RPAの要素として「最善のテクノロジーへのアクセスを提供」「パートナーエコシステムとアプリストア」「柔軟で拡張可能なデジタルOS」というポイントだけでは抽象的で理解が難しい。その後に使われたスライドでは従来のデスクトップ自動化によるRPAとの比較が解説されたが、ここでも「ガバナンスとセキュリティ」「ドラッグ＆ドロップ」「シェアード」というキーワードが強調されたが、実体はよく見えないというのが正直なところだろう。

この辺りは、カンファレンスの参加者があらかじめBlue Prismのパートナーなどからある程度、説明を受けていたことも一因であろう。今回のカンファレンス自体が、紹介される導入事例などによって最終的な開業活動への一押しを行うために企画されたために、技術的な解説よりも効果などに興味を示す部門責任者が多かったからではと想定するが、本当のところはわからない。

ただ、いわゆる技術系のカンファレンスと比較すると、圧倒的にスーツ姿、それもビジネススーツを着た女性が多かったのが印象的であった。これはRPAがIT部門よりも、まず現業部門をターゲットとしていることに由来するのだろう。

従来のRPAとBlue Prismとの比較

その後に登壇したBlue Prismのチーフカスタマーアドボケイトであるジョン・ターコフ氏は、自身がBank of New York Mellon（BNY Mellon）でRPAを導入した経験を元に、いかに企業がRPAを導入するべきか、効果、適用範囲などについて解説した。ターコフ氏自身がBNY MellonでRPAの導入をリードしたということもあり、かなり具体的な内容となった。

チーフカスタマーアドボケイトのターコフ氏

2016年1月からベンダー選定を開始して、BNY Mellon最初のBotであるAlexが完成したのが3月、そして同年12月には本番環境に多くのBotを投入したというスピード感だ。ターコフ氏は銀行での経験を活かしてそのままBlue Prismに転職し、RPAを啓蒙する側に回ったという。ある意味自身のキャリアを賭けてこのテクノロジーを担う企業に転身しただけに、解説はチカラが入ったものとなった。

BNY MellonのRPA導入の経緯

またRPA導入例として口座解約の自動化、決済修正の自動化などを紹介し、具体的にどういう業務が自動化になじむのかを紹介した。

ターコフ氏が紹介した自動化のプロセス例

その後に最初のユーザー事例として登壇したのは、楽天株式会社の内藤しのぶ氏だ。

プレゼンテーションを行う楽天の内藤氏

楽天のRPA導入事例を紹介するのは、同社のインフォメーションサービス統括部シニアマネージャーである内藤氏である。ここで非常に興味深かったのは、楽天ではRPAを「ソフトウェア開発」プロジェクトとして位置付けられていることだろう。

具体的な進め方として、楽天の各事業部では個々にIT部門を擁しており、それぞれの事業ドメインに沿ったシステム開発がなされているということを紹介した。これは日本の企業によく見られる組織形態、つまり社内の一組織がIT部門の運用を担当し、開発は外部のIT子会社に依頼して複数の事業部門のめんどうを見るスタイルとは異なるものだ。現場のビジネスに近いところにIT部門が存在し、インフラからアプリケーションまで包括的に開発運用するというスタイルだ。

もともとはITが及ばない部分で人間が実行している冗長な作業を、ソフトウェアのスクリプティングで自動化するというのがRPAの発想だ。先日、インタビューを行ったRPAテクノロジーズの代表、大角氏もRPAは「IT投資ではなくデジタルな人材に対する投資」であり、人を雇っていたのをソフトウェアによる人材～デジタルワーカーを雇うことで代替すると解説していた。つまり仕事をこなす人材として、ロボットは疲れることも休む必要もないが、ちゃんと教育する必要があるというのが本質だろう。

参考：バズワードと化したRPAの本質をリーディング企業に訊いた

一方楽天の場合は、代替する人材という発想というよりもあくまでもソフトウェア開発プロジェクトとしてスタートしたと言える。これは楽天という企業自体がITについてのリテラシーが高く、開発を担当するエンジニアも豊富に存在することが背景にあると思われる。このため事業の効率化を目指して、RPA導入に対して横断的なプロジェクトを設定して調査から開始したという。

楽天のRPAプロジェクトのスケジュール概略

RPAツールに関してもBlue Prism以外にも検討を行っており、シングルサインオンが可能か、デバッグは容易か、コードの再利用性などについて検討を重ねた結果、Blue Prismに決定したという。

楽天によるRPAツール比較

この比較表からもわかるように、楽天はあくまでもソフトウェアとして評価し、使いこなそうとしているのがわかる。それがより明らかなのは、RPAツール開発モデルというチャートだろう。

楽天のRPAツール開発モデル

ここではRPA開発のために「要件定義」「設計」「ロボット開発」「テスト」「リリース」「運用」というフェーズが明確に定義されており、開発のモデルも現場に丸投げするのではなく中央に存在するコーポレート情報技術部主体で行うCoEモデル（CoEはCircle of Excellence）と、各部門が開発を担当するFederationモデルの2つに分けて開発が試行されたという。

特にプロジェクトチームの構造も当初の業務分析担当のアナリスト、開発とプラットフォームを担当するグループ、それに情報技術部からのサポートと言う形態から、試行錯誤の末に改善されているという。

当初のRPAチームの構成。様々な不具合に遭遇したという

ここで重要なのは、ベンダー側がいかに「開発不要、コーディング不要」を宣伝しても、実質はソフトウェアとして実行されるRPAは開発プロセスからは逃げることはできず、楽天のようにソフトウェア開発プロジェクトと割り切ってスタートするべきという示唆だろう。

また開発の目的も「作業時間の削減」というわかりやすいものではなく、楽天としては敢えてその数値はKPIに盛り込まず、初年度で100ロボットという数値をKPIとして成功の度合いを測ったという。これはビジネスに対する直接的な効果測定を諦めて、RPAの導入ありきのプロジェクトと言っても過言ではないだろう。しかし現場ではその効果を体感しているとして、まずは現場を助けることを最優先してその効果測定は後回し、というのが実態だと思われる。

楽天のRPA導入のKPIはロボットの数

Blue Prismは以前のメディア向け説明会で「コーディングが不要」であり、専任のエンジニアでなくても簡単にロボットの開発が行えることを強調していた。しかし、楽天のようにインターネットをベースにビジネスを行っていて、かなりITリテラシーが高いと思われる企業でさえ、RPAは専任のデベロッパー、プロジェクトマネージャーなどを必要とするソフトウェア開発プロジェクトとして実行しているという事実は重要だ。

RPAは、ITのはざまにあって手間が掛かる業務を自動化するものとは言え、現場の作業を自動化することを主として、何もかもをスクリプティングでカバーせずに例外処理は人に委ねるという割り切りが大事だ。それは、楽天のようにRPAをソフトウェア開発プロジェクトとみなして、IT部門が積極的に関わる場合でも変わらない。

かつてIBMは、Lotus Notesをエンドユーザーコンピューティングのためのプラットフォームとして拡販した。その後、現場で作られたアプリケーションが保守も修正もできないまま放置されてしまった過去を思えば、楽天のアプローチはきわめて妥当と言える。ベンダーの宣伝文句に乗せられた現場主導の安易なRPA導入は、リスクが大きいということを感じさせた楽天のユーザー事例となった。