【投稿者】ぬこうなぎ
社内、または顧客に向けたRPAシステム導入の際に考慮するべきこと、事前に把握しておいた方が良いことやRPA化の検討・開発時に感じたことを記載します。
RPAとは
まず、RPA（ロボティック・プロセス・オートメーション）とは、人が行っていた定型業務をソフトウェアロボットに代行させ、自動化する技術です。たとえば、Excelへのデータ入力、Webサイトからの情報収集、帳票の作成など、繰り返し行う単純作業を自動化することで、作業時間の短縮とミス削減を実現できます。
導入のしやすさも魅力で、既存の業務フローを大きく変えることなく導入可能です。プログラミング知識が不要なツールも多く、現場主導での活用が進んでいます。
代表的なRPAツールには以下のようなものがあります：
- UiPath：直感的な操作性と拡張性の高さで世界的に人気
- Automation Anywhere：クラウドにも対応し、大企業での実績多数
- BizRobo!：日本語対応に優れ、日本市場に強み
- WinActor：Windowsアプリとの連携性が高く、国内企業に広く普及
尚、筆者はUiPathを主に使用しているため、後述する内容もそれに準じます。
RPAの導入コストは低い
RPAは、従来のシステム開発に比べて圧倒的に短期間かつ低コストで導入できるのが大きなメリットです。プログラムの専門知識がなくても、画面操作の記録や設定のみで業務フローを自動化できるため、PoC（概念実証）から本番運用までが非常にスピーディーです。また、既存のシステムを改修することなくそのまま使える点も、初期コスト削減に寄与します。
RPAの運用には厳正なルールが必要
RPAを安定して活用するためには、ロボットの設定や管理体制だけでなく、RPAが処理する元データの取り扱いルールを整備することが非常に重要です。
たとえば、Excelで入力フォーマットが変更されていたり、ファイル名が不規則であったりすると、RPAは想定どおりに動作せず、エラーや停止の原因になります。
実際に顧客向けに開発したRPAシステムでは、テストでは問題無かったはずなのに、納品後・本運用後でエラーが頻発するという事例がいくつも確認されましたが、上記内容が主な原因となっておりました。
そのため、以下のようなルールを整えておくことを推奨します：
- 入力ファイルのフォーマットやシート構成の固定化
- ファイル名・保存場所の命名規則の統一
- 空欄・記号・文字コードなどの入力ガイドラインの作成
- データ入力時のチェック体制や支援ツールの導入
開発時はノーコードよりローコードを意識した方が良い
ノーコード開発は導入ハードルが低く便利ですが、複雑な業務フローや拡張性を考えると、ローコード開発の方が効率的であると考えます。
ローコードでは、基本的な操作はGUIで行いながら、必要に応じてスクリプトやAPI連携を組み込むことが可能です。これにより、複雑な処理や他システムとの連携、エラー時の柔軟な対応ができるようになります。また、UiPathのシステム自体はVBかC#どちらか選択して開発可能のため、ローコード開発を意識するのであれば言語的な知識の習得にも繋がります。
RPAを長期的・組織的に活用していくためには、ローコードによる柔軟性の確保が望ましいでしょう。
RPA導入に適した業務内容
RPAが効果を発揮するのは、以下のような条件に合致する業務です：
- 手順が決まっていてルールが明確
- 作業内容にほとんど変化がない
- 一定の頻度で繰り返し実行される
- データ量が多く、手作業だとミスが発生しやすい
具体例としては、次のような業務が挙げられます：
- 毎月の帳票出力や報告書作成
- 社内システムへの定型データ入力
- メールやPDFからの情報抽出と記録
顧客に提供済みのRPAシステムは、これらの業務内容に該当するものが大半です。
RPAではなくシステム開発を検討した方が良い業務内容
すべての業務がRPAに適しているわけではありません。以下のような業務には、RPAではなくシステム開発や業務システムの再設計を検討する方が望ましい場合があります：
- 業務ロジックが頻繁に変わる
- 条件分岐や判断処理が複雑
- 業務全体を最適化・統合したい
- 他のシステムと高いレベルで連携が必要
こうしたケースでは、RPAでの対応がかえってメンテナンス負荷を増やしてしまうこともあります。長期的な視点での効率や拡張性を考慮し、適材適所で技術選定を行うことが重要です。
まとめ
RPAは、業務効率化の有力な手段でありながら、導入や運用には事前のルール整備や業務選定が重要であり、業務内容・データ環境・将来性まで見据えた設計が必要だと考えます。
また、先述の通りRPAはノーコード開発も可能のため、やろうと思えば誰でも開発できます。では、我々のようなシステムエンジニアがRPA開発を行う意味を考えた場合に、一般的な開発知識では補えない可読性、保守性、拡張性といったものを考慮して開発を進める必要があるのではないでしょうか。
そのためにも、プログラミング知識やAPIといった専門性のある知識や技術を利用し、開発者にもエンドユーザーにも扱いやすいシステムを提供することが、システムエンジニアとしての矜持ではないかと私は考えます。
