RPAプロジェクトの目的

RPAでは、様々な業務が対象になってきますが、いずれの業務でも、手作業の効率化や作業ミスによるリスクの低減を目的にすることが多くなります。

対象業務ごとのアプローチ

一方、業務量や業務のタイプに応じて、目的を達成するアプローチは様々で、対象業務によって推進方法変えたり、２つの異なるアプローチを組み合わせて行うこともあります。実際にDeNAにおけるRPA活用は「PJ*主導型」と「EUC型」の二刀流で進めています。二刀流にすることであらゆる定型的な業務の自動化を推進し、従業員が思考や判断などが必要とされるクリエイティブな非定型業務に専念できる環境構築を目指しています。
* PJ = プロジェクト

アプローチごとの特徴

PJ主導型のアプローチでは、BPRに長けたメンバーが中心となって推進することが多いです。現状の業務を把握した上で投資対効果を判断し、ロボ化に着手することになります。PJ主導型で採用されるRPAの多くは、多機能で開発難易度の高い製品が多く、開発者にITリテラシーが必要なため、工数削減効果の低い業務は対象外になります。
一つひとつ業務量はそれほど多くないが、様々な種類の業務があるケースがあります。こういった多品種少量の業務自動化まで業務の自動化範囲を拡大しようとすると、事業部のユーザ自身がロボ化できるEUC型RPAの併用が有効になります。

PJ主導型におけるロボ化の考え方

DeNAのPJ主導型RPAでは、ロボ化する対象のユーザ部門毎（例：経理や人事など）にロボ化の候補業務を調査表に記入してもらい、ロボ化する際の効果や難易度をPJ側で見積もります。事前に、ユーザ部門の方にロボが動作する様子の動画を見せるなどして、RPAができることのイメージを相手に持ってもらうと、調査がスムーズになります。
効果は、ロボ化によりどのくらいの工数が削減されるのか、どのくらい長く利用できるかによって評価します。頻繁に業務プロセスが変更になったり、利用するシステムに変更がある場合は、稼働した後のロボの改修コストが多くかかるため、注意する必要があります。DeNAでは1年以内に変更がある場合は、変更後に開発着手する方針としています。
難易度は、既に開発実績のあるシステムを参照（IN）したり入力（OUT）する場合、そのシステムでRPAが動作するかの検証が不要であったり、既存ロボの部品を流用できる可能性があるため、難易度を低く評価します。逆に初めてRPAで操作するシステムは、動作するかどうかの検証や専用のRPAアカウントをそのシステムに用意するなどの調整が必要になるため、難易度は高くなります。また、ロボ化する業務シナリオの長さによっても、作成工数が変わっていきます。これらの観点を総合的に勘案して、難易度を評価します。

効果と難易度を評価した上で、効果が高く、難易度の低い領域から着手することで、RPAプロジェクトの成果を早くあげることができます。いきなり難易度の高い領域に着手すると、なかなか成果をだせず、プロジェクトメンバーの士気の低下や社内におけるRPAプロジェクトのプレゼンス低下などの恐れがあるのでお勧めしません。
この進め方をしていくと、効果が低い領域の業務（＝業務量の少ない業務）の手作業が改善されず残ります。そこで「EUC型」を併用して、ユーザ自身で自動化できる手段を提供するのです。

次回（第3回）は、「EUC型RPAの特徴」について解説していきます。

大脇 智洋(DeNAのRPAマスター)　株式会社ディー・エヌ・エー　IT戦略部 部長

新卒でSIerに入社し、システムの開発・運用を経験。
2006年より会計系コンサルファームにて、J-SOX導入支援や業務改革などのプロジェクトに従事。2012年よりDeNAにて、グローバル経営管理基盤の統一、「Slack」の全社展開、「RPA」を活用した業務改善のプロジェクトなどを担当。RPA関連のイベントにおいてユーザー企業の立場から事例紹介する活動も行っている。