2018.08.14
今回のコラムでは、前回に引き続き、大型ＲＰＡプロジェクトを行う際の工程詳細について述べていきたいと思います。
前回では、ＲＰＡ開発プロジェクトならではの特徴と、最初の工程となる「対象業務選出」について簡単に説明させていただきました。
（参考）前回コラム：大規模RPAプロジェクトの進め方 （1/4）
本コラムでは、それ以外の工程についてまずは順を追って説明していきたいと思います。
参考： ＲＰＡ導入プロジェクトの工程
「現状業務分析」では、選出されたＲＰＡ化候補業務について深掘りしていきます。
具体的には、現状の作業フローや、発生頻度、リードタイム、業務量等を精査していくことになります。
このフェーズでは、社内のビジネスアナリスト、外部リソースであれば業務コンサルタントが活躍するフェーズになります。
もちろん、実業務を日々行っている現場担当者も知識レベルではできうることではありますが、
フローの書き方など不慣れなところもあるので、ビジネスアナリスト等が担うケースが多いです。
ただ、こちらのAs-Isと呼ばれる現状の業務分析フェーズですが、あまりにも簡易な作業が対象となる場合、
飛ばしてしまい、次の「業務フロー設計（To-Be）」に飛んでしまうケースもしばしばあります。
例えば、社内システム上の一部入力操作のみをＲＰＡ化しようとするような単純なケース場合、
To-Beとなるロボットのフローも容易に想像がつきます。
このAs-Isの業務分析は、あくまで次のTo-Beを描くための基礎情報として使うものであり、
To-Beが容易に描けるのであれば、わざわざAs-Isに時間をかける必要はありません。
ＰＭとしてはこのあたりの柔軟性をもって各案件に接することが求められます。
一方、人間とロボットの入り混じった、かなり複雑な一連の業務をＲＰＡ化しようとする場合、
例えば、消費者からの申請書を受け取り、それをシステム入力、さらに上司によるチェック工程が入る、
といった業務となると、やはりAs-Isからしっかりと精査したほうが良いです。
上記のような業務となると、ＯＣＲといったＲＰＡとは異なる別ツールの導入を併せて検討することになり、
また人間とロボットの分担もしっかりと整理する必要があります。
また、そのように複雑な、いくつか作業が繋がってできる業務の場合は、
ロボットを入れることで業務フロー自体が大きく変わる可能性も高いです。
（例えば、人間による都度システム入力から、ロボットによる夜間のバッチ入力に変わる、等）
そのようなケースの場合は、やはり手を抜かず、まずは現状の整理から一歩一歩進めていく必要があります。
こちらのTo-Beの業務フロー設計では、ＲＰＡロボット導入後の業務フローを描くことになります。
ここではより分解して述べると、以下に分かれます。
3-1. 対象業務のTo-Be業務フロー全体の設計
3-2. 個別システム/IFの画面遷移・操作設計
3-1.は、工程2のAs-Isの業務分析のところでも述べた事と同様で、
対象業務がかなり単純であれば敢えてする必要はありません。
この工程が必要となるのは、人間とロボットが複雑に連携するような業務に対してです。
アウトプットのイメージとしては、通常の業務フロー図にロボットの領域が加わったものになります。
3-2.については、これはほぼどのような対象業務であっても必要になってきます。
会計システム、Ｗｅｂサイト、またはExcelの管理帳票といった、
ＲＰＡロボットが触ることになるインターフェースの画面操作、遷移の指示書となります。
この指示書のイメージですが、各画面の画像を切り取ったものが遷移順に並び、横に補足説明が書いてあるようなものです。
使用されるドキュメントはExcel/PowerPoint/Word等、様々ですが、
こちらの資料を基に、次の工程4.であるプログラム設計書が書かれることになります。
To-Beの仕様が決まったら、次はいよいよプログラムに落とし込む準備に入ります。
工程3までの業務フローでは、まだ「人間側」の設計書であり、「ロボット向け」の設計書とはなっていません。
前工程で決められたTo-Be業務フローをロボットのロジックに合わせて書き直す必要があります。
簡単な例で言うと、forループやif分岐、データテーブル／コレクションと呼ばれる表形式のデータセットの作成、
入力、抽出の仕方などを具体的にイメージしたフローに直すのです。
また、この工程で、次に必要となる開発／テスト環境の設計も行う必要があります。
実は、ＲＰＡ開発プロジェクトの現場では、この工程がボトルネックになることが多いです。
何故でしょうか。
通常のこのプログラミング設計書の作成はエンジニアの領域であり、システムに詳しい専門職が担当すべき工程です。
しかし、前コラムで述べたように、ＲＰＡ開発エンジニア自体が枯渇している状況になると、
このプログラム設計書作成にリソースを宛がうことが難しくなるのです。
そうなると、この工程4を飛ばして、
To-Beの業務フローができたらそのままRPAエンジニアに開発依頼をしてしまう誘惑が擡げてきます。
しかし、それは後々の不具合の種となり、非常に危険な行為となりますのでお勧めできません。
このプログラム設計書作成のプロセスは、高度なＲＰＡプログラミング技術は要しません。
しかし、開発に使用するRPAツールの最低限の知識は求められます。
UiPathであれば、UiPathの仕様、BluePrismであればBluePrismの各機能の基礎知識が求められます。
ツール間でそれほど違いはないのですが、やはり、そのあたりを踏まえているのと踏まえていないのとでは、
その後の開発者にとってやり易さが変わります。
特に、RPA開発エンジニアが枯渇している昨今の現状においては、ビジネスアナリスト、
外部だと業務コンサルタントと呼ばれている人たちが、この領域まで手掛ける必要もあると考えるべきでしょう。
プログラミング設計書ができたら、RPAエンジニアによる開発に進みます。
この工程はＲＰＡの世界の中では開発とは呼ばずに「設定」と呼ぶケースもあります。
ここで注意する点としては、実際に業務行う現場環境と開発／テスト環境への配慮が挙げられます。
何度も言っていますが、ＲＰＡは、最終的に現場の業務担当者の代わりにロボットが行うソリューションです。
つまり、現場環境で動作できる事が必須要件となります。
しかし、実際にＲＰＡを開発するエンジニア部隊が必ずしも業務担当者と同じシステム環境にいるとは限りません。
そもそも、開発をアウトソースやオフショア等別環境で行う場合、ネットワーク環境も違いますし、
端末（ローカルＰＣ）作動型のＲＰＡを作るのであればＰＣ自体の設定も異なります。
このあたりは、何回か開発をすれば小慣れてくると思いますが、最初は特に出戻りが無いように注意が必要です。
この開発工程については、自社で行わずに、外部のベンダーの活用を検討している企業も多いと思います。
それ自体は、否定はしませんが、ＲＰＡのプログラムは、
そもそも、一旦開発した後もちょっとした改修が頻繁に発生するものです。
小さな修正・メンテナンスレベルまで外注しているとコスト面での負担が増えることになりますので、
大なり小なり社内リソースでプログラミングできる体制があったほうが望ましいと言えます。
この際に、前工程のプログラム設計書作成において「設計書フォーマットの標準化」が為されていると、
各段に効率が上がりますので、ベンダーや社内開発チームなど複数の開発チームが存在する場合であっても、
設計書フォーマットは統一化することを心がけてください。
開発が終わったら、テスト段階に入ります。
これは開発者自身で行うべき単体テストのレベルから、現場担当者が検証すべきユーザーテストまで渡ります。
ここでも重要なのは、先述したように、テスト環境と、実際に動かす現場環境が合っているかどうか気を付けながら進めることになります。
また、納期重視でクイックな開発がＲＰＡは求められますので、自然と、テスト段階での微修正が発生してしまいがちです。
その場合、やはりクイックにテスト後直せるように事前にコミュケーションをとっておくことも重要です。
今回のコラムでは、比較的大きなＲＰＡ開発プロジェクトにおいて、
各工程の説明および、留意点を述べさせていただきました。
次回コラムでは、いよいよ、
開発プロジェクトを効率よく進めるために特にＲＰＡならではで気を付けるべきことを挙げていきたいと思います。
乞うご期待ください。
