2018.06.22
今回の記事では、実際にRPAを導入することで現場の業務がどのように変化するかを具体例を交えてご説明したいと思います。
読者の方は、RPAが導入された後の業務がどのように変わると考えているでしょうか。
ロボットが完全に業務を独り立ちで実行し、もともとの業務担当の方が不要になり、
人の目によるチェックが全くない状況をイメージしているでしょうか。
確かにRPAに業務が置き換わることで、作業自体の質（速さと正確性）は増しますし、
ロボットが稼働できる時間は、人間が稼働できる時間と比べると大幅に増加します。
ところが、完全に業務から人が自由になるか、といったら実はそうではありません。
では、具体的な大手金融サービスのバックオフィスにおける業務のRPA化の実例を、
導入前と導入後の業務プロセスの変更に着目しながら記載していきたいと思います。
また、業務の変更前、変更後の記述のみではなく、
実際にどのようにRPAの導入が進むかのイメージが湧くように、
時系列を追って解説していきたいと思います。
RPAの導入の“いの一番”は業務選定になります。
そもそもRPA化に向いている業務とそうでない業務を見極める必要があります。
この記事の読者であれば、具体的にRPA化に向いている業務については一定以上の理解があると思いますので、
ポイントとなる点のみを強調します。
一番大事なのは、その業務をRPA化した場合に、短期間で費用対効果が上がるかという点です。
特にRPAのロボット開発を自社で行わない場合（外部ベンダーに委託する場合）、
開発にかかるコストの面で言えば、自社開発に比べ高くなる傾向があります。
また一度、RPA化を行ったとはいえ、ソフトウェアのライセンス料は毎年かかりますし、
業務プロセスを変更したことによるメンテナンス費用も当然発生します。
すなわち、これらの費用の支払いに見合った改善効果（時間短縮）がなければ、
基本的にRPAの導入は不要（コストに見合わない）ということになります。
ただし一方で、現場で働いている人たちには、RPA化が向いている業務などわからないという問題もあります。
この際には、一度実際にRPA化を行った業務のデモなどを見せて、
具体的なイメージ（実感）を持ってもらうことが非常に有効的だと考えられます。
今回のケースではこれらの条件を満たした業務として、
官公庁発表データの速報値取得（守秘義務の観点から特定のページをお伝えできませんが実際に発生している業務になります）という業務が選定されました。
この業務は、
「指定の時間になった時、インターネットに公開される政府発表の速報値をダウンロードして、指定のディレクトリにアップロードしておく」
という単純作業の業務です。
（毎日実行する必要があるが、指定の時間に出ていない場合もあるため、
公開されていない場合は何度も同じページにアクセスして確認する必要がある）
この業務が選定された理由は大きく2点ありました。
1 点目は、この業務が非常にシンプルな業務であって、
業務を遂行する上でアクセスの必要なシステムが一つのみであり、
開発にかかる工数が極小であるという点です。
2点目は、
「部署内におけるRPAを盛り上げるにあたって、
部署内で一番メジャーな業務（新人が必ず行うため、全員が経験する）であるため、
部署内でのRPA化に向けての業務洗い出しのきっかけづくりになる」
という点です。
それでは上記の業務が、業務ヒアリングおよびRPAの設計・開発を通じて、
具体的にどのようなプロセスに置き換わっていったのかを見ていきましょう。
まず最初に紹介するプロセスは、
現場担当の人が自分たちの業務を紹介したときの口頭での業務ステップになります。
上記の1から5のステップを聞いて、RPAの設計ができるでしょうか。
実はこれだけの情報ではRPAのロボットを作成することができません。
この情報をもとに更にヒアリングを実施し、ロボットの設計に落としていく必要があります。
例えば、上記の内容だけですと、「速報値のページがない場合にどうすればよいのか」であるとか、
「当日の速報値を保存するときの内容はどのような内容か（フォーマットは？）」といった点がわからず、
RPAのロボットを設計するための基本的な情報が足りません。
また、実際にヒアリングを進めていくと、
「ファイルサーバーへアクセスするには、特定のツール（ファイルサーバアクセスツール）が事前に起動されている必要がある」とか、
「インターネットにアクセスする際にはCitrixと呼ばれる仮想ブラウザツールを利用する必要がある」といった、
クライアント環境に起因した特別な条件が出てきました。
ヒアリングを実施した後の現在の業務フローは以下のようになりました。
いかがでしょう。違いを感じることができたでしょうか。
業務担当へのヒアリングにより、そもそもいつロボットが起動するべきなのかに加えて、
PCでの操作内容が明確になったことで、RPAのロボットに覚えさせることができる粒度まで業務プロセスを具体的にすることができました。
さて、いよいよ次はこれをRPA化後にどのようなプロセスになったのかを書き出したいと思います。
上記が最終的にRPA化を行った際の業務のプロセスです。
実際には、1-10まではロボットが実行してくれるため、人間の介在は不要となり、
人間が政府の速報値のページにアクセスをするという手間は完全になくなります。
ところが、完全にロボットだけで自立をさせることはできません。
アクセス先のページががダウンしているようなこともあれば、ファイルサーバへのアクセスが失敗することもあります。
そういったことも含めて、RPA化を導入した後であってもロボットが正常に動作していること、
または正常に動作したことを、やはり最後は人間が確認できるようにしていることが大事になります。
今回のケースではロボットが処理した結果（失敗・成功）をメールで通知するという手段でロボットが正常に動作したのかどうかを確認するという設計になりましたが、
「処理結果をファイルに残す」「処理結果を紙に印刷させる」といった別の手段で人間が業務完了を確認できるようにするということも考えられる方法です。
今回の記事はいかがでしたでしょうか。
「RPA化する=人間が不要」とならないと冒頭で宣言したことが、
具体例から感じ取ることができたでしょうか。
この記事を読んだ皆様が、この記事を通じて業務のRPA化に対して、より理解を深めていただければ幸いです。
