2018.08.16
今回のコラムでは、前回に引き続き、大規模なRPA導入プロジェクトにおける成功の鍵について述べていきたいと思います。
「組織体制」と「運営」の２つに分けて説明させていただきましたが、本コラムでは後者に焦点を当てています。
前回コラムを参照したい方は下記のリンクを参照してください。
（参考）前回コラム：大規模RPAプロジェクトの進め方 （3/4）
まず、おさらいになりますが、RPA導入プロジェクトをする上での成功の鍵として、
前回コラムからの再掲になりますが、以下のような要点が挙げられます。
本コラムでは、２の「運営」について詳述していきます。
RPAの技術自体が目新しいものなので、
多くの導入企業にとってRPAプロジェクトに対する経験値が未だ十分に足りていない事が多いと思います。
金融業界でまずRPA化の先鞭をつけた形となりましたが、その他の多くの業界では、未だPOCの段階であったり、
ようやく2018年になって開発体制の準備、実行フェーズに入ったところが大多数ではないでしょうか。
そのように不慣れなプロジェクトにおいて、人員リソースの最適配分は喫緊の命題となります。
もともとRPAに詳しい人材が未だ市場に十分にいない状況ですので、
開発工程のうちのどこかのプロセスがボトルネックとなり、
目標とする開発ロボット数や業務負荷低減時間に到達できずに苦労している企業も多いように見受けられます。
従って、特にRPA導入プロジェクトにおいては、
ボトルネックを探し出すためのプロジェクトマネジメント技術が求められることになります。
そのようなスキルは、正にPM/PMOにとって腕の見せ所の領域です。
特に大規模なRPA導入プロジェクトとなった場合、
それこそ数多のロボット案件・アイデアが浮上していくことになるので、それらを捌き、整理し、
管理するための高度な技術およびシェアリングの環境が待望されています。
その中の一つとなる有効な手法が「パイプラインの見える化」です。
（参考：パイプラインの管理）
パイプライン管理は、システム開発の用語というよりかは、
歴史的に営業であったりＲ＆Ｄの領域で発展してきたマネジメント手法です。
簡単に説明すると、営業にしろＲ＆Ｄにしろ、システム開発でも構いませんが、
特定の業務を個別プロセスに分解し、各プロセス上に現在どのくらいの案件があるのか可視化する手法です。
工場生産の現場で言うと、歩留まりを把握するのに近しい手法です。
何故、RPA導入プロジェクトの現場で「パイプライン管理」が重要になるのかというと、
それはRPAプロジェクトならではの特性に起因します。
RPAというものは、そもそも大型のシステム開発案件とは違い、
「システム開発するにはペイしない」細々とした業務の自動化が前提となります。
そもそも大きな業務負荷低減が見込める領域であれば、
RPAでなくて抜本的なスクラッチでのシステム開発を選ぶケースが圧倒的であり、多くの企業はそうしています。
つまり、企業にとってそれなりの業務負荷低減効果を狙うのであれば、
それこそ数多のロボットを生成する可能性が出てくるということです。
即ち、通常のシステム開発と比べ、RPAというものは、一つ一つは小粒な、
でも数だけは膨大なロボット開発案件の集合体となるわけです。
そこに、パイプライン管理の重要性が屹立してくることになります。
上記にあるチャートで、RPA導入プロジェクトにおけるパイプライン管理の事例を紹介していますが、
それでは例えば其処から何が読み取れるでしょうか。
この例で、まず目につくのは「業務フロー設計（To-Be）」が完了しているのに次の段階に移れていない案件が多く、
その割に次フェーズの「プログラム設計書作成」で仕掛中の案件が少ないことです。
これは、プログラム設計書作成の人的リソースが足りないが故に全体として動脈硬化が起きている現象を示しています。
つまり、この時点で「プログラム設計書作成」が明らかなボトルネックになっているということです。
このような極端な例は無いだろう、、、と思われる方も多いと思いますが、
不慣れなRPA導入のプロジェクトの場合、現実的に起こりうる事象です。
おそらくPMとしては、もちろん薄々は問題を理解していることなのですが、
いかんせんそのボトルネック工程を補填する人的リソースが見当たらず、打開策が取れない状態に陥っている、
そのようなことが現実的にRPAの開発現場では起きています。
このあたりの具体的な解決策については、
次のポイントである「教育」に大きく関与してくるところではあるので次節以降に譲りますが、
いずれにせよ重要なのは、このようなパイプライン管理をすることで「迅速に」ボトルネックを洗い出し、
打ち手を講じることができることです。
それにより、納期と目標が決められたプロジェクトを完遂し達成する確度を上げることができるのです。
次に、RPAプロジェクトにおける「教育」の重要性について語りたいと思います。
なぜRPAプロジェクトにおいて教育、つまりトレーニングが重要となるのか。
それは、RPAの持つ２つの特徴に起因します。
１つ目は「RPA人材の不足」、2つ目は、その割には「RPAの技術自体は差ほど難しくない」ということが挙げられます。
前述しました通り、RPAは比較的新しい技術領域であり、
そのプロジェクトに精通している人材の確保が難しい状況にあります。
従って、プロジェクトスタート時では十分なビジネスアナリスト／業務コンサルタントおよびエンジニア双方において十分な知見を有する人材を欠いたままスタートせざるを得ないケースもまま存在します。
このような状況でプロジェクトを運営せざるを得ない場合、大事なのは開発と同時に「教育」も進めていく事です。
RPAプロジェクトの場合、小型のロボット開発を積み重ねていく進め方になるので、
最初のリソース不足の段階では、少数の案件に着手し、後のフェーズで教育を経て人材を揃えていくやり方でも進めていく事ができます。
教育に焦点を当てる領域を特定する上で、前述したパイプライン管理が役立ちます。
定期的に、各工程の歩留まりをチェックすることで、
リソースが枯渇しそうなプロセスの人員を特に重点的に教育して増やしていく柔軟性が求められます。
一般的に、RPAのプロジェクトでは、プログラム設計書作成やRPA開発といった下流工程がボトルネックになりがちであり、
トレーニングをして人員体制を整えることが求められます。
上述した教育を促進させるために、KMの観点は非常に重要になります。
特にRPAのプロジェクトでは、ユーザー側の担当部署・担当者が多種多様に広がる可能性が高く、
またプロジェクトフェーズごとに人員体制を柔軟に変動させる必要があるため、
コアとなる知識・ノウハウを共有する工夫が開発の非効率を防ぐために必要です。
先進的な企業ではRPA専用の社内ポータルサイトを作り、ナレッジ共有に努めています。
ポータルサイトでなくとも、Slack等の社内SNSを活用していくのも有効です。
SNSを使えば、コミュニケーションの迅速化が図れ、ユーザーと、ビジネスアナリストおよびエンジニア間で、
仕様の確認や、RPAに合わせた業務フロー・ロジックの提案および承認といった、細々な点で開発スピードの向上が狙えます。
ただ、そのような大層な仕掛けがなくとも、
普通に共有フォルダを関係メンバーに公開するようなやり方でも、もちろん一向に構いません。
それでは、具体的にどのような情報コンテンツをナレッジシェアリングの対象とすべきでしょうか。
具体的な例として以下をご覧ください。
複数のステークホルダーが関与することになりますので、
それ毎に分けてコンテンツを用意することが見る側にとってもストレスなく使ってくれることに繋がります。
また、ユーザーサイドであったり、ビジネスアナリスト／業務コンサルタントに対しても、
RPAロボットの動き方を理解してもらうことは重要になりますので、
エンジニア以外にもRPAツールの紹介をする工夫がポイントとなります。
＜全体＞
＜対ユーザー部署＞
＜対ビジネスアナリスト／業務コンサルタント＞
＜対エンジニア＞
RPAプロジェクトの運営面でのポイントをお伝えしましたが、
最後にテスト環境の配慮を早い段階でしておくことの重要性をお伝えしたいと思います。
RPAでは、日々の定型業務の自動化がターゲットとなりますので、メール受信や、既存社内システム、
外部アプリケーションの操作をRPAでプログラミングしていくことになります。
また、ロボットと人間の間のやり取りの仕方として、特定共有フォルダに人間が必要ファイルをアップロードして、
ロボットが定期的にその共有フォルダを巡回、ファイルが合ったら処理を開始する、といった方法が取られることが多いです。
そのような、メール、社内システム、外部アプリケーション、共有フォルダといったものに対して、
テスト用と本番用を予め設計しておくことがスループットの向上につながります。
必ずしもテスト用と本番用の環境を別々にする必要はありませんが、
例えば、今でも社員が使っている共有フォルダやメーリングリスト、
およびシステム・アプリケーションのアカウントをテスト用で使うのは問題になりますので、
状況に応じて環境を分ける判断が必要です。
その場合、例えば、システムやアプリケーションのアカウントで起こりがちですが、
権限の設定がテスト用と本番用で齟齬があると障害の元となりますので、予め設計書で指示しておく必要があります。
また、このようなテスト用・本番用の環境設定は、RPA開発エンジニアの仕事という訳ではありません。
環境設定と言っても、大げさなものではなく通常業務で使うアプリ等の設定の話ですので、
このあたりの役回りは開発エンジニア以外の担当でも構いません。
RPAでは、一つ一つのロボット案件は小さいので、大規模システム開発と違い、
このあたりのテスト環境の整備がなおざりになりがちで、
いざ開発する段階になって「どうするんだっけ？」となることが散見されます。
予めプログラム設計書のフォーマットにテスト環境と本番環境を分けて記述できるように欄を設けるなど、
工夫をすべきだと考えます。
以上、今回の一連のコラムでは、
比較的大規模なRPAプロジェクトにおいて気を付けるべきポイントを組織体制と運営の側面から俯瞰してご紹介しました。
プロジェクトの要所は、会社およびRPA対象部署などによって変わってくるものではありますが、
今回でご紹介した点を咀嚼し、応用していただければと思います。
