RPAは本当にゼロから開発が始められるのか ――事例から見るRPA現場開発の注意点について｜RPA Biz

RPAは本当にゼロから開発が始められるのか ――事例から見るRPA現場開発の注意点について

2019.03.27

　この数年間、嫌でも「RPA」という言葉が耳にはいるでしょう。年間XX万時間作成に成功などのニュースが相次ぐ。RPAは現在日本の「人手不足問題」や「働き方改革」の対策にとても相性が良いとこと以外、「開発が簡単」、「導入するハードルが低い」、「ゼロ経験でもすぐ開発できる」というイメージもあるため、多くの企業が導入しているか、しようとしている。では、RPAの開発は本当にとても「簡単」でしょうか。多くの企業の中、「現場開発」、すなわち現場の従業員が直接開発するという導入方法を選んでいる企業もたくさんあるが、すべてうまくできたでしょうか。今回はいくつかの事例を紹介しながら、現場直接開発よくある問題を説明する。

リカバリーに対する認識不足

　RPA開発する前に、欠かせないのはRPAの仕様設計、あるいは業務フローの設計だ。つまり、業務を選定し、この業務をいかにRPA化すること。当然、現場の従業員は業務の流れや細かい作法などに一番詳しいので、普通に考えれば、仕様の設計にはとても向いているでしょう。もちろんこれも正しいことだが、必ずしもそうとは限らない。

　ECサイト運用企業のA社は現場スタッフの開発とプロのエンジニアによる集中開発両方を展開している。当初の狙いとしては、現場が身近にある比較的に簡単な業務を開発し、プロのエンジニアはより複雑なものを開発することだった。現場開発案件中で、とても典型的なものがあった。業務の内容を簡単に説明すると、毎日（平日）対象顧客分のクーポンを作成し、配信を行うということで、流れは下記のようになる：

• クーポ発行システム上に発行申請を行う
• 作成したクーポコードに基づいて、配信対象ファイルを作成する
• 配信システム上に配信対象ファイルをアップロードし、配信サーバーに処理をしてもらう
• 翌日配信分の予約を行う

　この業務の作業内容は一見シンプルなので、開発も簡単ではないかと思い、現場スタッフがこの流れを洗い出し、自らRPAの設計を行った。また、この業務は現状手作業により平日のみ行っているが、土日や連休分の業務は休み明けにまとめて作業している。本来なら休日問わず、毎日作業するのが好ましいので、「RPAならできるのでは？」と思って、現在のフローを変えて、RPAによる毎日実行というフローに変えた。

　このように、現場のスタッフがすぐ開発着手にした。業務に詳しいので、開発仕様などにも柔軟に対応できた。例えば、今までは3日~5日分先配信分のクーポンを申請していたが、RPAは毎日稼働できると思い、毎日の朝に当時配信分を作成することにした。理由としては、3~5日分先のものを申請したら、作成と配信の日付が異なるので、RPAが開発や運用しにくいと思った。

　ところが、いざ開発完了し、検証実験にはいると、トラブルが発生した。ある土曜日にRPAが稼働しなかったので、月曜日に来たら、スタッフが慌てて手作業で土曜日分のクーポン作成しようとした。しかし、過去分のクーポンを作成する前例がないので、クーポン発行システムに問い合わせて、とても手間をかけて、ようやく作成できて、追加配信を行った。そして、現場のスタッフたちは当初リカバリーについて認識不足のことに気づいた。平日はスタッフがいるので大丈夫だが、RPAの動作は100％の保証がない以上、万が一休みの日にとまった場合今までよりかなり複雑なやり方でリカバリーしないといけなくなる。そして現場スタッフが慌てて集中開発を担当しているエンジニアチームに相談にした。エンジニアチームはリカバリーの難易度を考慮した上の対策は簡単で、今までと全く同じロジックで、休日配信せず、平日のみ行うことで開発し直した。これにより、リカバリーの手順や難易度は今まで通りで、過去分のクーポンを作成する必要ないため、大きく負担をかけずに済んだ。

　一見簡単なことだが、現場スタッフの開発経験が足りないため、いかに実現することのみを考えて、リカバリーの難易度などを考慮しなかった。実は現場で開発する前に、最初に上がった意見は今までと同じように休日RPA稼働しないようにしたかったが、日付の設定や実行項目特定などの部分に開発困難だと感じて、毎日稼働を選んだ。結果、一度開発したものが実装できず、開発し直しとなってしまった。

非効率的なRPA設計

　同じA社の別部署の現場スタッフがRPA開発にチャレンジをした。業務の内容は非常に簡単で、毎日特定のシステムにアクセスをし、そこから指定のパラメータを設定した上で、CSVファイルをダウンロードして、指定の共有フォルダに保存する。まさにRPAが最も得意な部分だといえるでしょう。

　RPA化がスムーズに進められるよう、現場スタッフが工夫をして、下記の「指示書」（イメージを作成した：

　「指示書」はExcelファイルとなり、作業に必要な情報は全て格納されている。RPAは実行時「指示書」を読み取り、内容を判断した上で作業を行う。しかし、この業務がダウンロードするCSVファイルには時効があるため、必ず規定時間にダウンロードしないといけない。多少のずれは許されるが、例えば10時ダウンロードする予定のファイルは14時にダウンロードすると意味がなくなる。また、週単位で「指示書」が作成されるため、同じファイルの中にある各行のデータの実行予定日も異なる。例として、3月10日ダウンロードするものもあれば、11日ダウンロードするものもある。

　この状況に基づいて、現場スタッフが設計したロボットはまず毎日実行し、その後日付は当日かと判断する、その後また作業時間を判断する。この二つの情報に満たしている場合はダウロードを実行するが、それ以外の場合はスキップして、次の行を見るこのように繰り返す。ロジック図は下記のようになる：

とても分かりやすくてシンプルな設計になっていますので、開発もうまくできた。実装するある問題が生じた。

　このロボットは作業時間の問題で、毎日複数回実行する必要がある。指示書は1週間分で1000行から2000行程度存在する。量がとても多く実行するには時間が必要だが、問題は10：00実行する予定のものは12：00までも終わらなく、規定時間を大幅に超過したため、意味なくなる。そして、またエンジニアチームに助けを求めた。

　このロボットが一番時間を無駄にしているのは作業日付と作業時間の判断の部分にある。すでに気づいたと思うが、現場スタッフが作ったロジックだと、仮に指示書に1000行あって、作業日付と作業時間の条件に満たしているものは10行だけだとしても、1000行を全部チェックすることになる。とても効率よりとは言えない。そして、エンジニアチームが指示書を読み取る際に条件付けで読み取る機能を付けた。要するに、RPA稼働する時点で、日付と時間が処理対象になるもののみを指示書から読み取ることだ。処理対象が10行の場合は10行のみを処理するため、効率は大幅によくなる。

　もちろんこの機能はA社がつかっているRPAソフトには標準装備されているわけではないが、経験のある開発者なら作れる。現場スタッフは経験が足りなく、効率よくないロボットを設計することになってしまった。

まとめ

　今回紹介した二つの案件は一見大したことがないかもしれないが、現場スタッフが開発時実際起きていることだった。業務に詳しい分、RPA開発経験が足りない場合似たようなことが起き兼ねない。現場開発する際にきちんと経験豊富な開発者にサポーターしてもらったほうがよいでしょう。