RPAとは「Robotic Process Automation」の略で、PCで実施している事務作業を自動化するソフトウェアです。既存の事務業務を効率化させ、生産性を向上させることが可能で、国内においても2010年代後半ごろから普及してきました。
実際、スターティアレイズホールディングス株式会社が2023年に実施した「RPAの活⽤」実態調査【スターティアレイズ調べ】によると、RPAを「現在導入している」企業は14.16%、「導入はしていないが検討している」企業は5.51%で、約2割の国内企業がRPAの導入・活用を前向きに行っています。一方で、「ロボを作成できる人が限られている」、「費用対効果が測れない」、「RPAが社内で横展開できない」、「エラーで止まっても対応できない」等の課題も挙げられています。
本記事の筆者は、ITコンサルとしてシステム導入を構想段階から進めた他、RPAエンジニアとして実際に開発を経験したことがあります。RPA導入プロジェクトにおいて、経験した課題・トラブルや先輩エンジニアからいただいたアドバイス等、コンサル・エンジニア両面から経験した実例を基に、RPA導入における課題を解決するために必要なポイントを経験ベースでご説明できればと考えております。
本記事では、RPA導入の流れを①業務の棚卸、②要件定義・設計、③開発、④リリースと定義し、フェーズごとにポイントをご説明していきます。
もちろん、全てのプロジェクトにおいてこの流れで進めるわけではなく、プロジェクトの規模やスケジュール感、目的等によって、工程を減らしたり増やしたりすることがありますので、あくまで一例としてご認識ください。
下記図は、RPA導入を成功させるために重要となる、各フェーズにおけるポイントです。次章では、このポイントの詳細をご説明していきます。
RPAを導入する際は、まずRPA化候補業務の棚卸を行います。業務の棚卸では、業務の概要をヒアリングし、RPA化に適した業務であるかを判断します。
プロジェクトによりますが、RPAを導入する目的としては、「人の手による作業時間を減らすこと」、「ヒューマンエラーを無くすこと」等が良くあるでしょう。
これらの目的が、候補業務をRPA化することによって達成されるかを判断します。
業務の棚卸で重要なことは「RPA化の目的が達成されるかを評価する」ことです。RPA化すること自体を目的としてしまった場合、元々業務頻度が少なかったためRPA化後も時間削減にはつながらなかったり、例外パターンが多数存在するためRPA実行後に手作業による修正が必須となってしまったりします。
これらを防止するため、事前にRPA化の目的を言語化し、業務の棚卸にてその目的が達成されるか否かを採点すると良いでしょう。
下記図は、業務の棚卸の例です。こちらでは正確性および開発容易性の観点から「経費精算業務」をRPA化する業務として承認しています。(一例のため簡略化しておりますが、実際には、基準を設けて評価項目ごとに得点を付けるとなお良いでしょう。)
業務の棚卸を行い、RPA化する業務が決まった後は、要件定義・設計を行います。要件定義では、詳細な業務内容をヒアリングし、どのような要件でRPA化するかを定義します。そして、その内容を設計書として文書化します。
ヒアリングする際は、実際に業務担当の方にPC画面を見せてもらい、普段と同じように業務を進めていただくと良いでしょう。その中で詳細な業務やデータの流れを確認していきます。
要件定義では、業務・データの流れを明確化することが重要です。流れが不明確である場合、開発を進める中で、必要な処理の実装が漏れてしまったり、システムに必要なデータが不足していたりすることで、開発に手戻りが発生してしまう可能性があります。
流れを明確化し、RPA化範囲を定義することで業務担当者と開発者間で認識の齟齬なくスムーズ開発を進めることができます。
流れを整理する際は、下記図のようなフロー図を作成すると良いでしょう。
業務の流れを示すためには、一つの処理毎にオブジェクトを設置し、判断が必要な場合はオブジェクトを分岐させます。そして、どのオブジェクトからどのオブジェクトまでをRPA化させるかを示すと良いでしょう。
また、データの流れを示すためには、データの入出力を行うオブジェクトから、システムまで矢印を伸ばすと把握しやすくなります。
詳細なフロー図の作成方法は、「業務改善を効果的に実施する方法とは」の「業務フロー図の作成方法」をご参照ください。
設計では、要件定義で定義された内容を設計書として文書化します。一般的なシステム導入時と比較すると、RPA導入における設計書は簡易的なものになることもありますが、最低限、処理の流れ、データの流れ、入出力ファイル、エラー発生時の対応等は設計書に盛り込むと良いでしょう。
設計書は、誰が見てもその内容を把握できる必要があります。RPA導入後、業務の変更やシステムの仕様の変更、エラーの発生等により、RPAの修正が必要になった場合、設計書を基に修正することになります。この際、設計書の内容が曖昧であり、また、開発者が既に離任していた場合、RPAのソースを0から確認し、検証を行いながら修正する必要があるため、大変非効率になります。
設計書で処理の流れを定義する際は、下記図のようにまとめると良いでしょう。システムへの操作では、どの画面でどのボタンをクリックするかまで、できる限り詳細に記入する必要があります。
要件定義・設計では、現状の業務をそのままRPA化することに固執せず、RPA化の目的に応じて柔軟に業務を変更することが重要です。例えば、現状の処理を人の判断に依存して実施している場合、その判断基準をマスターに落とし、RPAが処理する場合はそのマスターを参照することで、より効率的かつ正確性の高いRPAを実装することができます。
RPA化の目的に応じて、「どうすれば業務時間が削減されるか」「どうすれエラーが減るか」等、業務改善を行う意識で要件定義・設計を進めると良いでしょう。
業務改善の考え方については、「業務改善を効果的に実施する方法とは」の「問題・課題の抽出と分析」をご参照ください。
続いては、作成した設計書に沿って開発を進めていきます。まずは、具体的な開発手法の前に、プロジェクト管理の視点において、開発フェーズにおけるポイントをご説明いたします。
実際に開発着手する前に、スケジュールを立てることが重要です。(理想としては、業務の棚卸フェーズが完了した段階でスケジュールを立てるべきですが、今回は一例として開発フェーズでスケジュールを立てることとします。)
経験の浅いRPAエンジニアの場合、一つ一つの処理を検証しながら開発を進めていくことになるため、具体的にいつまでに開発できるか予測することが難しくなってしまうことがあります。しかし、スケジュールを曖昧なまま開発を進めてしまうと、いつまでにどの処理を開発しなければならないのか、また、どこの処理の開発に時間がかかっているのか把握できず、遅延が発生し、対策を立てるのも難しくなってしまいます。
そのような事態を防止するため、設計書の処理定義を基に、処理の工程を区切り、開発難易度を推測したうえでスケジュールを立てると良いでしょう。例えば、先ほどの経費精算業務の場合、No.1~4までは単純な画面操作であるため開発は容易ですが、No.5~6は申請内容と領収書を比較する必要があるため多少難しくなります。最後に、No.7は画面を閉じるだけなので容易に開発ができます。それを踏まえ、下記のようにスケジュールを立ててみます。
根拠を持ってスケジュールを立てることによって、もし予定と実績に乖離が生じた場合は、その原因を振り返りスケジュール立ての精度を上げることができます。
続いて、実際の開発手法に関連したポイントをご説明します。
できる限りシンプルな処理で開発することが重要です。もし、複雑な処理になってしまう場合、開発に時間がかかるだけでなく、エラーが多発する等、運用・保守面でも悪影響が発生してしまいます。これは、当然なような気もするかもしれませんが、経験の浅いRPAエンジニアは特に複雑な仕様にしてしまいがちです。
その理由としては「RPAでできること」の理解が追い付いていないためです。RPAツールであるUiPathを用いて、PowerPointをカラー印刷する処理を例としてご説明します。
UiPathには、「項目を選択」というアクティビティがあります。このアクティビティでは、プルダウンの中の項目を直接選択できます。今回の例では、このアクティビティでプルダウンの「カラー」選択するのが最もシンプルな仕様です。
しかし、もしこのアクティビティの存在を知らない場合、恐らく「クリック」アクティビティでプルダウンをクリックしてから、表示された「カラー」項目を再度クリックすることになるでしょう。その場合、2つのアクションが必要になるのに加え、プルダウンをクリックしてから項目が表示されるまでラグが発生し、「カラー」項目をクリックできずエラーとなってしまう可能性があります。
このように、RPAの各アクションで何ができるかを把握していれば、より処理をシンプルにできます。各RPAツールを提供する企業のHP等でアクティビティの説明をしているはずなので、事前に確認しておくと良いでしょう。
開発が完了したら、テストを行います。まずは一つ一つの処理が正常に動作するか確認します。例えば、「ボタンをクリックする」「文字を入力する」等単体の動きを確認します。
単体の処理に問題がなければ、一連の流れをテストします。その際、まずはダミー用のデータで確認したうえで、可能であれば本番用データでも確認すると良いでしょう。
最後に、耐久性を確認するために、大量データの処理や長時間稼働させてもエラーが発生しないか確認します。
テストをする際は事前にコードレビューを実施すると良いでしょう。コードレビューを行う目的は、可読性・安定性・メンテナンス性を高めるためです。また、可読性が低いテスト時にエラーが発生した際、どこでエラーが発生しているのか読み解くことができず、そもそものテストの質が落ちてしまいます。
コードレビューをする方法としては、所属する企業やプロジェクトで指定の規定があれば、その規定に従ってレビューをします。もし、既定が無い場合、RPAツールベンダーが規定を公開している場合もあるので、それを確認すると良いでしょう。以下は、UiPath株式会社が公開している「コードレビューチェックリスト」の抜粋になります。
また、開発時から定期的にこのチェックリストを見直すとなお良いでしょう。また、可読性に関しては、開発する中で、第三者目線で、「他の人がこのコードを読んだら理解できるか?」と意識すると良いでしょう。
テストは網羅的に実施することが重要です。設計書を基に、テスト仕様書を作成するとなお良いでしょう。先ほどの経費精算業務の例の場合、作成した処理の一覧の横にチェックリストを作成し、一つ一つの処理が動作するかチェックします。加えて、全てのパターンを網羅する必要があるので、例えば、No.6の「承認、もしくは差し戻し」の場合、承認するパターンだけでなく、差し戻しを行うパターンまで確認する必要があります。
テストが完了したらついにRPAのリリースを行います。リリース自体は、RPAツールの仕組みやプロジェクトのルールに沿って実施するだけですが、重要なのはリリース後にRPAを放置しないことです。
RPAを開発し、「後はユーザーにおまかせ」としてしまうとRPAの実行時間が長く、以前と業務時間があまり変わらない、もしくはエラーが発生し、リカバリーに負荷がかかっている、といった事態が発生してしまう可能性があります。
それを防止するためには、効果測定とメンテナンスを実施する必要があります。
RPAの実行時間はどれぐらいか、エラーは何件発生しているかを計測します。そして、RPA化前に掛かっていた業務時間、エラー頻度と定量的に比較を実施し、RPA化による効果を測定します。さらに、測定した効果とRPA導入にかかった費用(ライセンス費や人件費等)を比較して、費用対効果を計測します。
もし、費用対効果が良くなかった場合は、開発プロセスを見直す、RPAツールやライセンスを見直す等の対策が必要になります。
仮にRPA化によって効果が出ていたとしても、そのまま放置すると動かなくなってしまう場合もあります。例えば、ブラウザーを利用する処理の場合、そのブラウザーのレイアウトやURLが変わるとRPAが上手く認識できず、エラーとなってしまう可能性があります。
そのため、RPAのログを定期的に確認し、エラーが発生していないかチェックする必要があります。(エラーが発生した場合、メール通知する処理を実装しておくとなお良いでしょう。)
RPAの一番の特徴は、複雑なプログラミングが不要であり、エンジニア経験が無くとも簡単に開発できることです。一方で、簡単に開発できるからこそ、RPAに適しているか否かを考慮せず安易に開発を始めたり、設計を曖昧なままにしておいたりして、当初期待していた効果を得られないことがあります。
この事態を防止するために最も大切なことは、「何のためにRPAを導入するか」をプロジェクト内で常に共有することです。目的を共有することによって、たとえRPAの経験が少なくとも、この業務をRPA化して意味があるのか、この設計で良いのか、といった疑問が思い浮かび、行動できるようになります。
まずはこのことを念頭に入れたうえで、ご説明させていただいたポイントを参考にしながら、RPA導入を進めていくと良いかと思います。
また、弊社では本記事以外にもRPAやシステム導入に関連した記事を複数掲載しておりますので、ご興味がございましたら、是非ご参照ください。
当社はITコンサルタントとして、RPAを始めとしたITツールの導入を、対象業務の選定/業務設計からシステム導入までトータルサポートしております。
詳しくはこちらをご覧ください。
【参考】
アーツアンドクラフツ Consulting & Solution事業部/アナリスト
2020年神奈川大学経営部卒業