RPAツールは比較的自由度が高いロジック構築ツールである。さまざまなアプリケーションに対して、様々な自動化処理を行うことができる。ある程度の数のコマンドも用意されているため、使おうと思えばプログラミングツールの代わりにRPAツールを使って同じことを行うことも可能である。しかし、そのような使い方はできるものの、実運用では行うべきなのだろうか。どれくらいのステップ数のフローなら作るべきなのだろうか。この記事ではそんな疑問を検証していく。
Contents
RPAでハンドルするのは “ITシステム/人との隙間” ステップ
ロボティック・プロセス・オートメーション (Robotic Process Automation : RPA) はプログラマでなくてもローコードでロジックを組んでいくことで画面操作を含めた自動化を行うことができるツールである。プログラマやSEによってシステム化された仕組みの隙間で発生する手作業を自動化するためのつなぎツールとして使われるのが本来想定されている使い方である。
しかし、現実には、RPAを使ってシステム開発まがいのことが行われていることもある。また、その手軽さからどんどんロボットにアクションを考えなしに追加していくと、あっという間に画面からはみ出るほどのステップ数のロボットになってしまう。画面からはみ出るほどのステップは、たとえばオートメーション・エニウェアのAutomation 360にてリスト形式で表示をさせたときは、通常の解像度だと約20ステップ程で画面いっぱいになる。ちなみに、筆者が聞いたことがある、RPAで作成した最長のステップ数はなんと5,000ステップにも及ぶ。
ステップ数が多すぎると何が起こる！？
5,000ステップともなると、おそらく小規模なアプリケーションと同等の機能があるものをRPAで作ってしまっているレベルではないだろうか。先にも触れたように比較的自由度が高いロジック構築ツールであるため、アプリケーションを作ることもできてしまう。しかし、本来の用途かというと決してそうではない。以下に挙げるようなデメリットが出てくる可能性がある。
- プログラマでないと、しかも作った本人でないと分からないくらいロジックが複雑になる。
- ロジック全体の見通しが全く効かなくなり、少しロジックを修正すると別の場所でエラーが出たりと、少しの修正も難しくなる。
- システム側で仕様が変更になった時に対応が難しくなる。
- 同じような操作をする場所が複数個所あり、メンテナンスがしづらくなる。
- RPAツールによってはこのような多くのステップを想定しておらず、速度が遅くなったりエラーが起こりやすくなったりする。
プログラマでないメンバーが理解でき、全体のロジックが見通せる程度の長さを考えると、RPAで作成するステップ数の目安としては、できれば100ステップ未満、せいぜい200には抑えたいところである。
ステップ数を増やし過ぎないための回避策
ステップ数を増やさないためには、いくつか工夫をすることができる。以下では、その内容を見て行こう。
共通部品化/サブロボット化
ステップ数を抑えることは、RPAは短い操作しかできないということでは必ずしもない。1つのアプローチとしては、1つの大きな操作を複数のロボットに小分けにすることである。ロボットの中で重複した処理は、外に切り出して複数回そのモジュールを呼ぶようにしたほうが良い。プログラミングで言うといわゆる「サブルーチン」のような考え方である。
共通部品としては、ロボットファイル、パッケージ (コマンド) ファイルとして切り出す方法がある。ロボットであればプログラマでなくても組めるかもしれない。ただし、共通部品となると、作成スキルはより高度なものが要求される。パッケージについては、プログラマがJavaや.NET Frameworkなど、プログラミング言語を使って作成することが多いだろう。
1ロボット/1目的
ロボットをサブロボット部品として切り出す際は、物事を単純化するために、1ロボットの単位は、1つの操作/目的の単位で切り出すことがお勧めである。また、他のロボットとの依存関係は持たない単位にすることも重要である。ロボットを複数に分けるということは、今度はどのロボットに何が含まれているのか、そして依存関係がどうなのかという管理が大変になってくる可能性があるため、管理の煩雑性を減らすための工夫が必要となる。
プログラマが作成するプログラムとの使い分け
また、部品として使う外部プログラムも、ロボットやロボットのパッケージ以外の選択肢もあり得る。JavaやC/C++などで書かれた本格的なプログラムで、すでに実績のあるソフトウェア (商用パッケージ/フリーソフト)を組み合わせて使うことも検討すべきであろう。5,000ステップのRPAをメンテナンスするのであれば、すでに実績のあるソフトウェアを組み合わせたほうが全体のメンテナンスコストは下がる場合がある。
まとめ~RPA開発者はプログラマではないことを前提とする
RPAの使いどころは、従来のSIやプログラミングとは明確に異なることは意識する必要がある。プログラマでなくてもある程度使いこなせるというRPAの利点を生かす運用を行うことをお勧めする。そのためには、RPAのベストプラクティスをしっかり取り入れて実践することが不可欠となるだろう。