こんにちは。GCI本部の佐伯です。今回初めてエンジニアブログを投稿させて頂きます。
DXの推進が進むと共に「オフィスのルーチンワークを自動化したい」といった声が各ユーザー部門から挙がるようになりました。そんな時に活躍するのが今流行りのRPA（Robotic Process Automation）です。これまで人の手で行ってきたデータ入力業務やファイル操作などをソフトウェア型のロボットを利用して自動化してくれるツールのことで、その魅力はノーコードで「早く、簡単に作れる」ことにあります。
私はグループのDXを推進する立場から、日々ユーザー部門へのRPAの導入支援を行っていますが、その中でよく感じることがあります。「早く、簡単に作れる」といってもあくまでIT部門目線の話で、ユーザー部門にとってはまだハードルが高いということです。「自分でRPAツールを使ってみたけれど、なかなかうまく動かないので相談に乗ってほしい」という声を頂き、現場の方とお話しすると以下の点で苦労しているように思えました。紹介します。
現行業務の整理が出来ていない
RPAは通常のシステム開発同様、業務要件をしっかりと整理した上で開発を行わなければいけません。しかし、このようなIT部門の人からすると当たり前とされることでも、ユーザー部門の方にとってはそうではないケースがあります。ユーザー部門の方はRPAツールを使いこなせるかどうかの不安に目が行きがちで、日々行っている業務について改めて整理するということから目が離れてしまうことがあります。人の作業をそのままマシンが行うという性質上、業務マニュアルがある場合はそれをフロー作成のためのシナリオとして活用することができますが、業務マニュアルが確立していない場合はまずそこの整備から始めないといけません。同じ業務でも長年行われているうちに人によって手順が異なることや、イレギュラーな作業が行われている可能性があります。組織として業務をRPA化する上では、それらのバラつきを標準化することがとても重要になるのです。
またRPAはずっと使い続けることができるわけではありません。例えばWebブラウザを操作する業務をRPA化した場合ですと、サイト側の仕様が変わることである日突然動かなくなることもあります。そういった場合には、当日の業務は手作業で行うしかありません。その時に、かつて業務をアナログ作業で行っていた経験者が在籍しているかも分かりませんし、RPA導入後年月が経っていたら忘れてしまっている可能性もあります。業務要件をしっかりと取りまとめたうえで作成したマニュアルは開発のためだけではなく、リリース後のトラブル時対応手順としても大きな役割を果たすのです。
現行業務もあるためDX推進のための時間を確保するのが難しい
ユーザー部門の方は当然ながらご自身のメイン業務をお持ちです。DXを推進しなくてはという意識からテキストを買ってRPAの学習・開発を始める方も多いですが、それにかかる時間の分メイン業務を調整できる方ばかりではないと思います。限られた時間の中で不慣れなツールをマスターして開発するのは至難の業です。
また、ユーザー部門の方から「自分でRPAを作ってみたけれど、うまく動かないから見てほしい」と相談を受けることがありますが、実際にフローを見てみると、業務の順番で上から下にアクションが並んでおり、かなり煩雑な印象を受けることがあります。システムを設計する上で部品を共通化することが出来ていないのです。10個のデータをWebサービスからダウンロードするのに10本のフローは必要なく、データの情報を定義ファイルに持たせることが出来れば1本のフローで完結します。開発にかかる時間がこれだけで大幅に短縮されますが、このようなシステム設計・開発の考え方はRPAのテキストには載っていません。例えノーコードのRPA開発だとしても、設計思想は通常のシステム開発がベースとなっているのです。そういった点ではIT部門がお手伝いをさせて頂くことでより効率よく開発を進めることも可能です。
上手くいかない場合を想像するのが難しい
先ほども書きましたが、RPAは外的要因により異常終了する可能性も高く、サイトやミドルウェアに変更が加わった場合は突然動かなくなることもしばしばです。しかし、ユーザー部門で作成されたRPAではエラー時の挙動が考慮されていないこともありました。現行業務の正常系を自動化出来たところがゴールになってしまい、万が一のパターンを想定することが出来ていないケースや、エラーに対してどのようにハンドリングしていけばよいか分からないケースが存在します。これも部品の共通化同様、RPAのテキストにはエラーハンドリングの考え方までは載っていないことが原因の一つであると思われます。
RPAは慣れてくると人の目からどんどんと離れていくものです。自動でやってくれているだろうという決めつけの裏で実は処理が止まっていた場合、エラー通知を仕込んでいないRPAだと長時間検知できず大きな事故に繋がる可能性もあります。あらゆる角度から、発生しうる異常ケースを洗い出しリスク対策を取ることがRPAでは非常に重要なことです。
最後に
ここまで読んで頂き有難うございました。
ノーコードのRPAツールは、IT部門の支援が不要なように見えて、意外にも支援による価値をご提供する場があることを日々実感しております。ただ、ユーザー部門にも驚くほどシステムに精通している人や、我々では考えつかないような画期的な方法で課題を解決しているような例を見ることもあります。
引き続き、ユーザー部門とIT部門が一体となってDXを進めていくことができればと思います。