2018.08.13
今回のコラムでは、比較的大規模にRPAの導入を検討しているケースにおけるプロジェクト進行の要点をまとめていきたいと思います。
大規模プロジェクトとなった場合、求められるRPA対象業務数（案件数）も膨大となり、
また関係してくる各部署ステークホルダーも複雑になります。
小さな目のプロジェクトであれば、まずは一部の部署だけでPOCを行って、
徐々に対象領域を増やしていく、、といった順序でも許容されますが、
大規模プロジェクトとなった場合、「●月まで●●案件のRPAプログラムを完成し、●●時間を削減せよ」
というような命題が既定としてあり、その目標を完遂するための効率的なプロジェクト運営が求められる傾向にあります。
基本的にRPAの開発プロジェクトも、他のシステム開発案件と同様の工程を経ます。
従って、このRPAプロジェクトを進める上での要諦も、通常のシステム開発プロジェクトと大きな差はありません。
ただ、いくつかのポイントについてはRPAならではの特徴が存在します。
一つは、RPAというものが早期の実行を要求される傾向にあることです。
他の大規模システムと違い、RPAというものは、そもそも今までローカルPCで行っていた単純作業を自動化させるのに特化したツールであり、
経営者側とすれば早期の実行による社員の業務負荷軽減を期待してしまうものです。
ＲＰＡは大規模システムのような高度で入り組んだシステム設計を必要とせず、
それよりも納期の速さが故にいかに簡略化してクイックに開発を進められるかが肝になります。
もちろん、要件定義やプログラム設計書レベルのものは必要ではありますが、
例えば、テスト仕様書等時間をかけてじっくり作って準備するよりかは、
ユーザーテストをして早めに修正点を洗い出し完成に持っていくような柔軟性が求められます。
もう一つの特徴は、RPAの案件というものは、開発予算が低めに抑えられる傾向にあり、
エンジニア人材の確保がボトルネックになりがちだということです。
RPAはもともと、システム要件とならないような細々とした多種多様な業務の自動化が求められる領域であり、
開発対象となる案件は一つ一つは簡易で小さなものであってもその数は膨大となる傾向にあります。
一案件で見るとそれによる人間の業務低減効果は限定的であり、一件一件低予算で開発をこなさなければ、
経済合理性が成り立たない状況になります。
従って、ＲＰＡのプロジェクトの場合、最初の時期は外部パートナー会社の協力を仰ぐことになりますが、
ゆくゆくはユーザー自社の社員で開発・運用をしていくことが求められるケースが多いです。
そうなると、社内エンジニアの「教育」という点が重要になってくるわけですが、このＲＰＡ、世の中に出回る多くのツールは、
そもそもの思想として現場担当者レベル（人事や経理など）でも自分達で「作れる」ことを目指し、
そのためのＵＩになってはいますが、その割には難しいのが、何と言いますか、絶妙なところです。
特に大規模RPAプロジェクトになると、オブジェクト指向に基づいたモジュール管理、統一ルールの徹底などが求められるため、
やはり社内リソースに任すにしてもＩＴ部門の様な専門のエンジニア職のほうが望ましいと言えます。
上記で述べた、エンジニアによる開発予算が抑えられがちであることとも関係していますが、
もう一つのＲＰＡの特徴として、人材、特にエンジニアの人材の確保がボトルネックとなる傾向が挙げられます。
ＲＰＡは比較的新しい技術であり、現在世の中には、UiPathやBluePrism、BizRoboやWinActorといったツールが出回っておりますが、
その扱いに熟練した技術者、エンジニアは、まだその需要に対して十分な供給を果たせていません。
エンジニアとしてもＲＰＡ開発ツールが複数存在するために、
「UiPathはできるけどBluePrismはできない。。。」
といったケースが出てきてしまい、ますます特定のツールに特化した技術者を確保するのが難しい状況にあります。
また、この人材の枯渇でいうと、To-Beの業務フローを書くビジネスアナリストにも同様のことは言えます。
ビジネスアナリストは厳密な意味ではエンジニアではありませんが、ことＲＰＡのプロジェクトの場合、
業務フロー設計者もＲＰＡロボットの知識が求められます。
これは考えてみれば当然で、ＲＰＡでは今までの通常の人的リソースとは全く異なった特徴を持つ「ロボット」に業務を肩代わりさせることになる訳であり、
つまり、その「ロボット」の動き方について専門の知識を十分持っていないとTo-Beのフローが書けないからです。
そのような「ＲＰＡのエンジニア知識」を有したビジネスアナリストは、残念ながら、現在まだ多くは育っておらず、
リソースの確保が課題となっています。
このビジネスアナリストのリソース問題は、ＲＰＡの対象が簡易な単純作業だけの段階であれば、顕在化しないと思います。
しかし、そのような小さな単純作業のＲＰＡ化フェーズが終わり、
より高度な、ロボットと人間の分担が入り組んだ複雑な業務フローを組むようなケースになってくると、
切実な問題として直面することになると思います。
次に、より具体的にＲＰＡを導入する際の個別工程について話していきたいと思います。
比較的大規模なプロジェクトにおけるRPA導入のステップと関係ロールを下記に記しました。
まず、こちらの各工程について簡単に説明したいと思います。
ＲＰＡでは先述したように、早期の実行が求められることもあり、
大きめのプロジェクトであっても通常のシステム開発よりも簡略化される傾向にあります。
参考： ＲＰＡ導入プロジェクトの工程
ここでは、ＲＰＡ対象となる業務をリストアップする、アイデアジェネレーションのフェーズになります。
この工程では、実業務をしているユーザー部門の担当者が主役となりますが、
ＲＰＡの知識が無いケースが殆どですので、事前にビジネスアナリストもしくは業務コンサルタントが入って、
ＲＰＡとはどのようなものか、どのような業務がＲＰＡに向いているのか事前に勉強会を開いておくことをお勧めします。
一旦、コツがつかめれば、現場担当者から能動的に様々なロボット化のアイデアが出て来ると思います。
ただ、それでもやはりアイデアが出てこない場合は、まず各現場部署に自身の業務の棚卸し（リスト化）をさせて、
そのリストをもとにビジネスアナリスト／業務コンサルタントとディスカッションセッションを設けても良いかもしれません。
あと、この工程で大事なことは、「ざっくり」で構いませんので、
月間業務量、頻度、定型作業の割合、使用アプリケーション等、「ＲＰＡ化との相性を測れる情報」も記載しておくことです。
その情報により、挙げられたリストの内どの業務からＲＰＡ化の手をつければいいのか判断ができます。
もちろん、最初に手をつけるべきは「簡単な割に削減効果の大きい業務」からになります。
今回のコラムでは、比較的大きなＲＰＡ開発プロジェクトの特徴と、
最初の「ＲＰＡ対象業務の選出の工程」について説明をさせていただきました。
次回のコラムでは、さらに他の工程の説明および、留意点を述べていきたいと思います。乞うご期待ください。
次のコラム：【必見】大規模RPAプロジェクトの進め方 （2/4）
また、2019年5月にはRPA導入無料相談会を実施いたします。
ご予約はこちら。
