住宅ローン業務の例に見る、RPAにおけるPoCのさまざまな落とし穴：RPA導入ガイド（7）

　RPA（Robotic Process Automation）とは何かという基本的なことから、導入するためのノウハウまでを解説する本連載「RPA導入ガイド」。前回はRPAソフトウェアの構成やPoC（Proof of Concept：概念実証）に向けた心構えについて解説しました。第7回となる今回はRPAのPoCの概要について解説します。

　RPAのPoCを進めていく過程ではさまざまな落とし穴が待ち受けています。本連載を参考にして事前に対策を講じておきましょう。

RPAのPoCでよくあるシステム構成

　前回、RPAソフトウェアの物理構成を紹介しました。おさらいすると、ロボットファイル、実行環境、開発環境、管理ツールの大きく4点から構成されます。システム構成という観点では次のように2つに分かれます。

図表1　「サーバによる集中管理」「サーバ、クライアント」

　2つのシステム構成の違いは、ロボットファイルを「デスクトップ側に持つか」「サーバ側に持つか」ということです。サーバによる集中管理では各デスクトップから仮想的にサーバのロボットファイルを呼び出して実行します。

　両者に対応している製品もありますし、いずれかのみの製品もあります。選択の基準はセキュリティポリシーや仮想環境の有無によります。

　システム構成の観点でそのまま説明を続けますと、以下がRPAのPoCでよくあるシステム構成です。

図表2　RPAのPoCでよくあるシステム構成

　RPA専用のサーバを立てて、そこに管理ツールがあることがRDAとの大きな違いです。

初動の留意点

　RPAは、ハードウェアとしては「サーバがあること」が、ソフトウェアとしては「管理ツールがあること」が、RDA（Robotic Desktop Automation）との違いです。それを踏まえて、作業上の留意点をまとめておきます。

　経験談からお話ししますと、1．に当てはまることですが、データベース製品の手配を失念していたことがあります。

　RPAソフトは、実行の際に取得するデータ処理を効率的に行うために、SQL ServerやOracleなどのデータベースソフトと連携するタイプが多いです。気持ちがRPAソフトだけに集中してしまうと、関連する必要な製品のチェックがおろそかになってしまうことがあります。

　さらに、PoC全体の観点からは、OCRなどの他の機器やソフトウェアとの組み合わせもあり得ますから、1．の（2）の視点でのチェックも重要です。

　2．の（1）のセキュリティポリシーは、情報システム部門が主導でないプロジェクトの場合には早めに確認を進めてください。

　3．は前回、筆者の失敗談を共有しました。

　上記の留意点がクリアできないとスケジュール通りに進められません。

金融機関に共通の「事情」

　さて、連載第1回でRPAの導入は金融機関が先行していることをお伝えしましたが、各行の本導入やPoCが進んでいる業務の1つが「個人向けローン」です。

　その前に金融機関に共通の「事情」を共有しておきます。金融機関は早い時期からFinTechを旗印にRPAの導入に取り組んできました。それとは別の事情もあります。次の円グラフは、幾つかの金融機関の事務センターで業務ウエートを調査した結果を集約したものです。多数の営業店での取引の裏付けとなる各種の処理を、「後方事務」と称して事務センターに集約しています。

図表3　ご参考　金融機関の事務センターの業務ウエート

　見ていただきたいのはデータ入力とデータ照合のウエートの大きさです。

　データ入力は、書類を見ながらシステムに入力、あるいはシステムAからシステムBへのコピーでの入力などです。データ照合は入力した結果が正しいか、別の担当者が書類やシステムを見ながら再確認する仕事です。これらの仕事であればRPAが大活躍しそうです。

　金融機関の事務センターの裏側を見ていただきましたが、多数の個人を相手にするサービスを提供している企業や団体であれば、金融機関でなくても同様な「事情」があるはずです。

PoC事例〜「住宅ローン」業務

　事情をご理解いただいたところで話をPoCに戻します。

　個人ローンの代表選手である「住宅ローン」の事例で解説を進めます。経験されている方も多いと思いますが、住宅ローンは、申込者の立場で言えば、申込書の他にさまざま書類を記入・作成します。提出する証明書類なども多岐にわたります。申し込む側もたくさんの書類作成で大変ですが、金融機関もその裏返しでつらい一面を有しています。

　「多数の書類に基づくデータ入力」「データと書類の一致」「自社システムと他社システムの相互利用による多岐にわたるデータのコピー」などで、多数のオペレーターを動員しています。

図表4　住宅ローン審査業務の概要

　PoCは、図表4の▼や▲印のシステムの1つまたは2つなどに絞って行われます。結果として、必ずと言っていいほど、数十％の効率化やそれを超える効率化または生産性向上が可能となります。

　PoCの報告書では以下のようなチャートがたびたび使われます。

図表5　PoCの検証結果イメージ

　効率化や生産性向上が検証できるとPoCに携わるメンバーとしては喜ばしいことですが、この効果の数値をうのみにしていいのでしょうか。

効果を見抜く視点　その1「全体の業務」

　連載第6回のロボットマークと連載第3回のオペレーションフロー（図表4）を思い出してください。

連載第6回の図表3　ロボットマークを描く（再掲）

連載第3回の図表4　オペレーションフロー表の例（再掲）

　PoCで効率化や生産性向上を検証できた業務は、住宅ローンの例でいえばたくさんある業務プロセスの中のごく一部です。

　人の数を例にとれば、全体の業務を100人で担当しているとしたら、PoCで検証したのは数人〜10人程度のプロセスです。

　業務プロセスの一部でもデータ入力や照合を中心に固めていることから、確かにすごい効果を発揮してくれます。

　上記2つの図を見ていただくと分かるように、「全体の業務」という観点ではRPA適用の位置付けは一部に限られますから、業務全体として数十％の効率化になることはなかなかありません。

効果を見抜く視点　その2「効果の組み合わせ」

　RPAの導入効果を考えるときに重要な視点を4つ紹介しておきます。効果は以下の組み合わせから生まれるものです。

• （1）RPAソフトウェアそのものの効果
• （2）ロボットファイルの設計による効果
• （3）システム全体としての効果
• （4）導入活動による効果

　例でいえば、（4）の導入活動で業務分析を行って最も効果の上がる部分に絞って検証しているということ、（3）の視点ではOCRと組み合わせたシステムなどの方が効果に貢献しています。

　住宅ローンの例に限ったことではありませんが、実のところ導入効果を語るときは、（4）→（3）→（2）→（1）の順に、導入効果の占めるウエートが高いのです。

PoCで大切にしたい2つのこと

さまざまな技術とツールを上手に組み合わせる

　RPAが契機となって、業務の効率化や生産性向上に取り組むのは素晴らしいことです。しかし、業務全体を鑑みると、OCR、AI、BPMS、身近なところではExcelのマクロとVBAなどのさまざまな技術とツールが適用可能です。これらを上手に組み合わせて導入を進めていけば、業務全体で前例のない効率化や生産性向上を図ることも不可能ではありません。

　PoCをやって気付くことの1つに「マクロが意外にも使える」ことがあります。RPAの前さばきとしてデータをそろえるなどで活用し、RPAの仕事を単純化できるようにして一層高い成果を挙げる取り組みもあります。

RPA以外にも目を向ける

　RPAのPoCは、PoCを行う企業や団体の方々とは別に、コンサルタント、製品ベンダー、ITベンダーなどの外部パートナーと共に進められます。理由は適用する業務の規模が大きくなることや、システムとして難易度が上がることによります。

　RPAだけではなく、その他の技術もイメージしながらPoCを進めていただくと、後に続く本導入に向けて効果的です。本導入が始まってしまうと余裕を持って考えるのもなかなか難しいことです。PoCのときに広い視野でプロジェクトを見て、必要な修正を検討してください。

次回は、PoCを受けての全体計画の修正と、その後に続く本導入・構築の入り口

　次回はPoCを受けての全体計画の修正とその後に続く本導入・構築の入り口を中心に解説を進めます。「どこまで内製化するか、できるのか」も論点の1つです。