働き方改革が進む中、注目を集めているRPA

皆さんは自分たちが日々行っている業務を、"RPAに代行させられるか"と考えたことはあるでしょうか？

RPA、すなわち、Robotic Process Automationは、仮想知的労働者（Digital Labor）とも言われ、ルールエンジン・機械学習・人工知能などを活用し、ホワイトカラー業務を効率化、自動化する仕組みです。現在、主に利用されているRPAは、人が行っているPCの操作手順をソフトウェアロボットが学習、代行し、「（一定のルールにもとづいた）定型作業の自動化」を実現するもので、「クラス1」と呼ばれています。さらに今後は、ディープラーニングによって例外対応や非定型業務に対応可能な「クラス2」、高度なAIによってプロセスの分析や改善なども自律的に行う「クラス3」の実用化が見込まれています。

働き方改革の必要性が叫ばれる中、多くの企業にとって「いかに定型業務や事務処理に費やされている労働時間を削減し、貴重な人材（および、その労働時間）をより生産性の高い業務へシフトさせるか」が重要な命題となっています。その解決策の1つとして注目が高まっているのが、RPAによる業務の自動化です。

たとえば、受注処理業務を例に挙げると、業種や企業によって異なりますが、

• メールなどで注文書を受け取る
• 注文内容を確認する
• 注文を受けた取引先の情報を顧客データベースで確認する
• 初めての取引であれば、取引基本契約書や見積書を送信する
• 在庫を照会する
• 受注伝票を作成する
• 注文確認のメールを送信する
• 倉庫などへ出荷指示をかける

といった作業が発生します。

これらの一連の流れがすべてシステム化されているケースもありますが、多くの企業では人が複数のシステムを操作しながら、データの確認、検証や入力、転記などの作業を行っているのではないでしょうか。RPAを活用することで、こうした一連の業務を自動化できる可能性があります。また、RPA活用に向けてあらためて業務の見直しをすることで、業務改革へつながります。そして、これは受注処理業務に限らず、多くの定型業務に当てはまるでしょう。

すべての業務にRPAが有効なわけではない

RPAを用いれば、既存のシステム環境に手を加えることなく一連の業務を自動化できるため、社員を煩雑な定型作業から解放し、より生産性の高い業務に集中させることが可能となります。また、処理時間の短縮、人的ミスの排除などの実現につながることも、企業にとって大きなメリットとなるでしょう。しかし、だからといって、すべての業務にRPAを適用すればいいというわけではありません。RPAはあくまでも「ルールにもとづいた、単純な作業の繰り返し」を得意としており、少なくとも現時点では、込み入った判断が必要な業務や、臨機応変な対応が求められる業務には向いていません。

たとえば、前述の受注処理業務で言えば、「初めての取引であれば、取引基本契約書や見積書を送信する」の部分が、「あらかじめ用意された取引基本契約書の必要項目に記入し、定められた基準で見積書を作成する」だけであればRPAによる自動化は可能です。また、人による内容の承認が必要という程度であれば、「メールを送信して、承認を待ってから続行する」といったフローを自動処理の中に組み込めばいいだけです。しかし、ルールとして記述できないような人の介在が必要なケースには適しません。たとえば、経験にもとづく審査などの判断を行わなければ取引基本契約書そのものが作成できないなどといった場合です。

それ以外にも、RPAの導入にあたってはコスト面などのさまざまな条件を照らし合わせつつ、「RPAによる自動化が本当に適しているか」などを十分に検討することが成功につながります。次章で企業全般におけるRPA導入の流れを紹介しましょう

RPA導入を進める際の具体的な流れ

(1）RPA適用業務の洗い出し

PCを用いた業務で非効率だと感じている点などを洗い出し、自動化したい作業、自動化できそうな作業の候補をリストアップします。それだけでは掘り起こせない課題を見出すためには、PC操作ログを分析することで、各ユーザーが多大な時間や手間を要している作業、自動化できそうな作業を見出していくという手法なども検討すべきでしょう。

(2）候補となった業務の分析・評価

BPM製品を活用、業務の棚卸しや要素分解を行うことで、業務プロセスの可視化を行います。その可視化にもとづき、

• ルールが定義でき、変更が少ないか
• 処理パターンが多すぎないか
• RPA作成のコストに見合うか

などの条件に見合うものを選定し、さらに現在の負担の度合いなどに応じて優先度などを定めていきます。また、その分析にもとづき、

• ルールが固定化されているものであればシステム構築を行う
• システム間のデータの転記が主体であればデータ連携（ETL）ツールを活用する

など、ほかの手段も視野に入れて検討を行います。

(3）RPAの管理体制と製品の選定

RPA製品は「PC操作などの自動化」という最終的な目的は共通するものの、各々にアプローチや特長が千差万別なため、製品選定の際にはまず「どういう使い方をするか」という要件を明確にする必要があります。どのような業務に適用するのかという点はもちろんのこと、誰が主体となってRPAの作成や運用を行うのかも鑑みる必要があります。RPAの管理には主に以下の2つのパターンが考えられます。

• 分散型＝ソフトウェアロボットの作成や運用は各々の業務部門が行い、情報システム部門やRPA管理専任チームなどが全体的な使われ方をチェックする。
• 集中型＝業務部門が提示した要件定義に応じて、情報システム部門やRPA管理専任チームがロボットの作成、運用、さらには複数の部門にまたがった標準化までを一括して担う。

昨今では全社的な取り組みとしてRPA導入を進めるケースが増えており、その際には集中型を選ぶべきだと言われています。ただ、RPAを適用すべき業務が当面は少ない、RPAの（部門をまたがった）横展開はできそうにないという場合には、比較的容易に導入を進められる分散型が適しています。

そして、この管理の仕方に応じて、RPA製品を選んでいくことになります。RPA製品の稼働形態は主にPC単位でロボットを実行、管理する「デスクトップ型」、サーバ側にロボットの実行、管理を集約する「サーバ型」に分かれており、当然ながら、分散型管理であればデスクトップ型、集中型管理であればサーバ型の製品が原則としては適しています。

ただし、これは基本的な分類であり、双方の特長を併せ持った製品も存在します。たとえば、NTTアドバンステクノロジの『WinActor』は、もともと個々のクライアントOS上で動作する製品でしたが、昨年9月にはサーバOS上で動作可能なサーバ対応型を追加しました。

そのほか、多くのRPA製品では、PCの操作をそのまま記録し、それらをGUI上で編集することで、ノンプログラミングで簡単にロボットの作成や設定が可能です。しかし、「どれだけ簡単に作成、編集できるか」「どれだけ複雑なことができるか」は各々の製品によって異なります。RPA製品の選定時には、ユーザー自らがロボットを作成、管理するのか、それとも情報システム部門やRPA管理専任チームが作成、管理するのかを念頭に置きつつ、こうしたロボット作成・設定機能も細かく検証していく必要があるでしょう。

情報システム部門における業務の自動化はすでに実現されている？

前章では企業全般におけるRPA導入の流れを概説的に紹介しましたが、定型業務に追われているのは、何も業務部門や管理部門だけではありません。ここまで読まれた情報システム部門の方はどのように感じられたでしょうか？システム運用管理の分野においては、以前からRBA（Run Book Automation）、もしくはジョブスケジューリング、オーケストレーションといった自動化を行うための機能を備えた製品はめずらしくないこともあって、「自分たち自身の業務はすでに一定の自動化はできている」という方も少なくありません。しかし、情報システム部門の業務は運用管理だけにとどまるものではなく、これまでの記事でも言及してきたとおり、役割の転換が求められる中で、既存の業務についてはなるべく負荷がかからないような体制を構築しておくことが不可欠です。

たとえば、ユーザー・アカウントの管理業務について考えてみましょう。社員が入社、退職するたびに、情報システム部門が各種業務システムやファイルサーバ、クラウドサービスなどへの登録、削除作業を行うのは、仮にシングルサインオンなどの仕組みを導入していたとしても、それなりに煩雑な作業となります。しかも、この時、情報システム部門が承諾の可否などの判断を行っているわけではなく、人事部門などからの申請に応じて、単純に登録作業や権限設定などを行っているのではないでしょうか。

そこでRPAを活用することで、メールでの申請、あるいは人事システムへの登録などをトリガーとして自動的に作業を実行させることが可能となります。

このように、人の判断が介在しておらず、あらかじめ決められたルールにもとづいて行われている業務は情報システム部門にも多く存在するはずです。しかも、今後はRPAがクラス2、クラス3へと進化していくことで、その適用範囲は広がっていきます。"RPAに代行させられるか"という目線で、改めて自分たちの業務を見つめ直してみてはいかがでしょうか。