RPAの中級者レベルとは、どこからどこまで？

今日は「RPAはどこから中級者レベルと呼べるのか？どこからが上級者レベルなのか？」ということについて考えたいと思います。書きながら考えていくので、結論はブレていくかもしれません。

まずRPAレベルの全体を考えると、初級は「デスクトップ自動化の正常系が問題なく使えるようになる」レベルまでじゃないかと思います。RPA（プロセスオートメーション）とRDA（デスクトップオートメーション）を分けて考えると、「RDAの正常系」が初級者とします。RPAとRDAの関係性は下図の通りです。

中級者は「RDAの運用レベルまで考えた実装ができる」レベルか、もうちょっと進んで「RPAの思想を持ってスケジュール実行できる」レベルまででしょう。ここまでくるとほぼRPA（業務の自動化）と言っていいんじゃないかと思います。

上級者は「完全自動化して多数のロボを中央管理する」レベルですね。いわゆるサーバー型のRPAの開発・運用です。さらに大企業レベルで何千体・何万体というロボを管理するレベルになると僕がわかる範囲ではありません。きっと、もっと多くの知識が必要なことは間違いありません。

今回のテーマは「中級者レベル」です。「RDAの運用レベルまで考える」とどうなるかを考えましょう。複数の自動化フロー（シナリオ）を実行するので、開発画面ではなく実行用の画面から実行しますね。ちなみに、開発画面からフローを実行している人も多いようです。常にデバッグモードで実行していますね。中級者レベルではこれはナシとします。

RDAの実行用の画面からフローを実行すると、まず「中身なんだったけ？」問題が発生します。作ったときは覚えていても、数週間経っただけで中身を忘れていて「動かすのが怖い」という状態になるでしょう。そのまま動かして大事なファイルを上書きして壊してしまうかも。メモしていたとしても、メモを探して読むのは面倒。あると思います。

対話型アクションを使いこなす

よって、RDAフローを作るときに「将来の自分またはメンバーが久しぶりに動かしても大丈夫なようにする」というテクが必要になってきます。具体的には対話型メッセージを出す方法があります。「これからこういうことやるけど、ＯＫ？」と出してやれば、ワンクッションおけます。ダメなら［Cancel］を押すと止まるようにしておけばいいですね。

対話型のフローを上手く使う、というテクニックも中級者レベルかもしれませんね。メッセージボックスだけでなく入力ボックス、ファイル選択ボックス、カスタムダイアログなどを駆使すれば、より柔軟なフローが作れますし、想定される例外にも人の頭を使って対応できるようになります。

エラー時の対応を作り込んでおく

もう1つは「エラーの時の対応をちゃんと作っておく」ということです。「エラーが発生しても絶対に大事なファイルは壊さないようにする」「変なデータをシステムに書き込んでしまわないようにする」としておけば、「中身は忘れたけど大丈夫」という安心感があるから、実行しやすいですね。このためには正常系の開発の倍の労力がかかりますが。

共通化する

複数のフローを作るようになると「同じ処理を別のフローでも作った」ということが発生します。同じような作業を自動化するので当たり前です。この時「フローを共通化したい」というニーズが生まれます。共通化、部品化も中級者レベルでは必要ということです。

共通化、部品化するということは、部品化するフローをブラックボックス化するということですから、そのフロー内で発生したエラーは部品を使う側から見えなくなりがちです。「エラーが発生しました」しかわからない。だから、エラー処理もより厳密に必要となってきます。

エラーが発生したときに止まる、そして原因がわかる、ということはフローを多数開発する上で重要になってきます。エラーについては色々な種類があり、「止まる」だけじゃなく「正常系フローに復帰する」というパターンもあるので、別途考えます。「例外」と「異常」はまた別ですし。

テスト・デバッグを行う

共通化で言うと、「内部的に正しい動作をするかどうか」に加えて「外部から使った（コールした）ときに正しい動作をするか」も確認しないといけませんね。ということは、「テスト環境」も作る必要があります。この「テスト」「デバッグ」も中級者レベルに入るでしょう。

定数を設定ファイルにする

他にも変更が発生したときに、いちいち開発画面を開いてプログラムを変更するのは手間です。変更が発生しそうな箇所はあらかじめプログラムの外に出しておくことで工数削減できます。変更が多いのは「サービスのURL」とか「ファイルのパス」などの変数、いわゆる「定数」です。

「定数」を外部に置くことで、プログラムを変更することなしに他の環境（パソコン）でも動かすことができるようになります。ドキュメントフォルダーなどはWindowsのログインユーザーによってパスが変わりますから、そういうパスを設定ファイルとして置いておくわけです。

定数は設定ファイル（ExcelやCSV、テキスト）などに格納しておき、プログラム内から呼び出すのが一般的なテクニックですので、これも中級者レベルに入るでしょう。もちろん、この設定ファイル読み込み（書き出し）処理も共通化するわけで、だんだんフローは複雑になってきます。

複雑さを回避するプログラミングテクニック

複雑さを回避するために、変数の処理などはまとめて行いたくなってきます。データテーブルやPADならカスタムオブジェクト、外部とのやり取りならJSONを使うなどが視野に入ります。高速に大量の処理を行えるようになりますし、（勉強は必要ですが）フローはシンプルになります。

少し複雑なフローになってくると「状態管理」が必要になってきます。作業は単純に2つに条件分岐するだけじゃないので、「Aパターン」「Bパターン」「Cパターン」…となり、これを条件分岐だけで書くととんでもなくネストするので「フラグで制御しよう」というアイデアも必要です。

設計図を描き起こす

共通処理やフラグ制御などをフローに組み込んでいくと、頭で考えられるレベルを超えてきます。天才は別ですが。パターンが増えてきて、ストレートだった正常系の処理とは話が変ってきます。こうなるとフロー図を書く必要が出てきます。これも中級者レベルじゃないでしょうか。

まとめると、中級者レベルで必要な項目は下図のようになりますね。

ここまで、書きながら考えているので、まだこれが正解かどうかわかりませんが、ここくらいまで行くと、RDAのフローを多数動かせるようになるでしょう。

スケジュール実行もできるでしょう。ただし、スケジュール実行するには「専用パソコンを用意するか」「止まったときどうやってエラーを知るか」など別問題も解決しないといけなくなります。

スケジュール実行とは「対話型のフローは実行できない」ということでもあります。対話型で人の頭を使って回避していた例外には、機械的な回避方法を使わないといけません。こうなると考えるべきレベルが1つ上がってきますね。

「スケジュール実行」はやっぱり上級者レベルなのかもしれませんね。環境構築も必要になりますし、運用を考えないと。自分のパソコン内で自分の必要なときに実行しているレベルとは、業務の構成から変ってきますね。ここから先は別途考えたいと思います。では。

追記：個人レベルの自動化でできる範囲の最大値が中級レベルってことで、そこから先は会社レベルですね。たとえばチームで開発するとなるとソースや成果物（プログラム実体）のバージョン管理問題も出てきます。だんだん自動化とは違う領域の話が多くなってくる印象です。