2018.08.15
今回のコラムでは、比較的大規模なＲＰＡ導入プロジェクトにおいて特に注意すべき点を述べていきたいと思います。
前回のコラムまでは、一般的な各開発工程における留意点を挙げさせていただきました。
（参考）前回コラム：大規模RPAプロジェクトの進め方 （2/4）
複数の部署に跨る大規模なＲＰＡ導入プロジェクトの場合、特に組織体制と運営手法が重要になってきます。
このあたり、幾つか要点をまとめてみました。
分散と集中とは、各工程のタスクを事業部等の個別部署に分散してお願いするのか、
コーポレートで中央管理するのかの切り分けの話になります。
もともと、RPAの思想として、ユーザーである現場部署が自らの力で自動化できることを謳ってはおりますが、
こと大規模なプロジェクトの場合は、開発工程に進むほど中央管理することが求められます。
（参考： ＲＰＡ導入プロジェクトの工程）
前回コラムで、上記の一般的な開発工程ステップをお見せしましたが、
理想論から言うと、最初の「対象業務選出」のところまではユーザーである現場部門主導で行い、
その後の現状業務分析(As-Is)以降は、コーポレートに所属するビジネスアナリストもしくは外部の業務コンサルタントが主導して現場ヒアリングをベースに策定していくのが望ましいと言えます。
これは、As-Isの分析資料や、To-Beの設計書というものが、
次の実開発フェーズに進むうえで標準化された仕様であることが望まれるからです。
個別現場部門にお願いする場合、フォーマットを規定したとしてもどうしても書き方の統一が難しく、
標準化されていないと開発チームが混乱をきたすリスクが高まります。
ただ、これはあくまで理想論であって、
中にはビジネスアナリスト／業務コンサルタントのようなリソースの十分な確保が困難である会社も多く存在すると思います。
その場合、百歩譲って、As-Isの現状業務分析のところはフォーマットを決めてユーザー側である現場担当者に任せることも可能です。
非常に単純な作業をＲＰＡ化するのであればTo-Beのところも任せられるケースもあります。
ただ、プログラム設計書作成とのころは、開発チームに標準化された仕様書を渡す最後の砦となりますので、
その工程だけはしっかりとセントラルで品質管理できるようなチーム体制は必須となります。
（参考：ＲＰＡプロジェクト体制例）
次にＲＰＡを推進していく上でのチーム体制についてですが、こちらについては、
もちろんリソースが許す範囲でのことになりますが、PM/PMOのみならず、
ビジネスアナリスト／業務コンサルタントおよびエンジニアまで含めて専任チームを組めることが理想です。
これは、おそらくどの企業にとってもＲＰＡというものが未だ馴染みがなく、独特の注意点を要するプロジェクトとなるため、
早めにナレッジを吸収しそして歩留まりを良くするためには専任チームのほうが効率的になるからです。
また、ユーザーとなる現場部門についても、このＲＰＡプロジェクトにおいて担当窓口となる人間は各部署で特定すべきです。
ここで特に言っておきたいことは、ＰＭ/PMOの役回りも、
可能であればその期間だけはＲＰＡにほぼ特化した形で業務を遂行できるように環境を整えてあげる事です。
このPM/PMOの役回りは、現状だと経営企画室やもしくはコーポレートのＩＴ部門が担うケースが多いですが、
今まで見たケースだと、どうも他業務との兼務で指示されることが多いようです。
もちろん、最初のPOCや、As-Isの業務分析あたりまでは、兼務であっても進めることはできると思います。
ただし、より開発に近づいたフェーズになると、より開発環境の標準化やリソースアロケーションといった点で、
漏れのない管理が必要となり、そのためにはPM/PMOがＲＰＡに特化した専任チームであることが望まれます。
システム開発の分野において、一概に「分業」が全て正しいという訳ではありませんが、
ことＲＰＡに関して言えば、リソースの有効活用という側面において、組織設計に織り込む必要があります。
現状、社内リソースにおいてＲＰＡの知見を十分有している社員は、
ビジネスアナリストおよびエンジニア双方において限定的である企業が多いと思います。
特にＲＰＡに最も精通しているエンジニアを如何に開発業務に注力させられるか、
そして意思疎通の齟齬による出戻りを如何に減らせるかがプロジェクト管理上、重要になります。
開発そのものではないのですが、エンジニアとの関係の深い工程としてプログラム設計書作成と、テストがあります。
一般のシステム開発であれば、ＳＥがその工程に携わる事も多いのですが、
ＲＰＡエンジニアが限られている現状を鑑みると彼らをその工程に全投入するのは賢いやり方とは言えません。
そこで、開発エンジニアとは別に、プログラム設計書作成とテストを行うチームを設立し分業させるのが有効です。
そのチームのメンバーには初期はＲＰＡエンジニア1~数名を入れるのもよいですが、
ゆくゆくはビジネスアナリストの人材を教育してできるようにさせる事が理想です。
（参考：分業体制にした場合のＲＰＡプロジェクト体制）
このプログラム設計書＆テストチームですが、
これはＲＰＡ開発を担当するエンジニアリソースの確保の観点からも重要ですが、もう一つ別の目的もあります。
ビジネスアナリスト／業務コンサルタント側にＲＰＡの動き方・仕様の視点を学ばせて、
To-Beの業務フロー設計のところに役立たせることが狙いとしてあります。
このＲＰＡというものは、通常の人間の作業員とは全く異なる「働き方」をするロボットです。
まとまった計算処理は早いですし、24時間働くこともできます。
しかし、あいまいな指示系統だとうまく動きませんし、
エクセル内の処理だけでしたらＶＢＡによるマクロのほうが早かったりします。
このユニークな「ＲＰＡロボット」の特徴をしっかり掴んだうえでTo-Beのフローを描いたほうが、
より実現性の高いものが出来、結果出戻りも少なくなることは自明です。
特に複雑な業務フローにおいてＲＰＡを導入する段になると、
人間スタッフとＲＰＡロボットとの協業、すみ分け、分担の仕方が、非常に重要になってきます。
その時に、しっかりとＲＰＡの仕様を理解したビジネスアナリスト／業務コンサルタントがいるかどうかが、導入成功の鍵を握ると言えます。
本コラムでは、大規模ＲＰＡ導入プロジェクトにおける成功の鍵を、「組織体制」の面から述べさせていただきました。
それぞれ導入企業によって既存人的リソースの状況も違うので一概には言えないところもありますが、
あとは応用の話になりますので、要点をうまく掴んでいただけたらと思います。
多くの会社は、最初のＲＰＡ導入業務として経理財務、人事総務、営業事務といったあたりから始めることが多いですが、
まず直面するのがＲＰＡならではの細々とした課題の解決と環境設定、そしてＲＰＡエンジニアのリソース不足です。
この点を如何に解消できるかがポイントとなりますが、それには、コーポレートの専任チームを組成することと、
ＲＰＡエンジニアを最大限開発にリソース投入できるようにするための人員配置が重要となります。
本コラムでは「組織体制」からの話となりましたが、
次回コラムでは「運営手法」の面から成功の鍵を探っていきたいと思います。
乞うご期待ください。
