RPAと向き合った：RPAやってみた！Vol.2
はじめに
前回の『RPAやってみた！Vol.1：新人の私が初めてプロジェクトを担当した』では、RPAについての簡単な説明と、私が新人のときに担当した、社内の定型業務の自動化プロジェクトで実装したRPAの紹介、そして、その業務での体験談についてお話ししました。
「RPAってなに？」というRPAについて全く知らない状態から、要件定義を行い、RPAを実装するまでのプロセスで経験した仕事の進め方の話や、業務を通して得た気づきなどもご紹介しました。
今回は続編ということで、一通りRPAの実装を完了した後、RPAの保守運用担当者に、実装したプログラムをレビューしてもらったときのことをお話します。
作ったRPAをレビューしてもらった
紆余曲折と沢山の学びを経て、なんとかRPA実装は完了しました。
ユーザにもRPAの動きを確認してもらい、大きな問題もなく開発チームはホッと一安心。続けて、RPAの保守運用を担当する方（これまで実際に稼働するRPAを沢山見てきたいわばRPAの“プロ”）に、実装したプログラムをレビューしてもらうことになりました。開発チームは実装が完了したので気分はルンルンです。
しかし、レビューの結果は、予想外のものとなりました。20項目以上の大きな修正が発生したのです。実装フェーズはもう終盤だと思っていた開発チームは驚きました。
レビューの内容を聞くと、RPAのプログラムの構造に関する技術的な知識や、RPAを作るときのお作法、インターネットでなんとなく検索してもヒットしないコアな開発フレームワークの機能など、経験豊富な方ならではの情報が満載でした。RPAについて知識も開発経験もない人間だけで、実際に運用していくRPAを作ることはとても難しかったのです。読者の皆様、どんなレビューをされたのか、気になりますか？技術的な内容になりますが、簡単にご紹介します。
（１） RPAの構造化
プログラミングやシステム開発の経験がある方はイメージがつくかと思いますが、プログラムはファイルに対して文字を記述し作成します。レビュー前、私たちは、RPAの全ての処理を１つのファイルに記述していました。しかし、RPAは実行する際非常に多くのメモリを使います。もちろん、ファイルサイズも非常に大きいです。こうした重たい処理が原因で、RPAが期待通りに動作しなかったり、ファイル自体が壊れてプログラムの修正内容がうまく保存されていなかったりといった問題がありました。
こういった問題に対処するべく、プログラムを構造化しました。これまでは以下の図のようにA、B、C、D、Eという５つの処理を１つにまとめて記述していましたが、それぞれ別の、1つずつの処理として切り分けをしました。Cの処理が必要なときだけCの処理を呼び出し、それ以外の時は使わないというプログラムの作り（構造）にしたところ、各プログラムのファイルサイズが小さくなり、期待通りにプログラムが動くようになりました。
（２）デフォルトの設定ではいけない
RPAはまるで人間が操作するように、画面上のボタンのクリックや、Ctrl＋C（コピー）やCtrl＋S（保存）などのキーボード操作も行うことができます。そして開発フレームワークにはGUI（画面操作）で簡単にRPAを作成することができる機能があります。例えば、「録画」という機能を使って、いつも定型業務で行う「○○アプリケーションのアイコンをダブルクリックしてアプリケーションを起動」「起動したら入力ボックスに文字を入れる」「画面上のログインボタンをクリック」といった画面操作を手で行うと、自動で同じ動きをするRPAを作成することができます。とても便利だと思った私は、よくその機能を使っていました。
しかし、レビューをしてもらったところ、RPAの一つひとつの動作について細かい設定を全くしていなかったことに気づきました。例えば、アプリケーションの起動時間。仮に5秒かかるとして、RPAが次の処理に進まないように5秒の待機時間を設ける必要があります。また、RPAにクリックさせるときの位置なども細かく設定する必要がありました。便利な機能を使うことが悪いというわけではないですが、便利な機能を使って効率よく開発しつつも、1番安定する動作を見つけて細かい設定をするひと手間が重要です。
RPAは画面操作で簡単に作成できるため、プログラミングの知識があまりない人でも簡単に開発できると思っていましたが、プログラムの技術がないと安定した動作をする、実際に運用できるレベルの確実なものを作ることができないということに気づきました。
たくさんの修正に驚いた開発チームでしたが、 “その道のプロ”から技術的な知識やRPAのお作法を伝授してもらい、RPAの深い面を知ってとてもわくわくしていました。（難しいことに悩み、理解できるとより楽しくなるという技術屋の特徴です。）
そして、次は作ったRPAを修正していくことになりました。
品質の高いRPAに作り直す
他にも色々なアドバイスを受け修正を始めました。プログラムの構成から変更する大幅な修正だったため、漏れがないよう修正項目を全て洗い出し、順番に直していきます。途中、修正したRPAがたまに期待しない動作をすることがありました。困った私は上司に「レビューしていただいて修正するように言われた部分がうまくいかない」と相談しました。すると上司は、「RPAにとても詳しい方からアドバイスしてもらったけれども、実際に動作が安定した、品質の高いRPAを作るのは私たちですよ。」と言われ、はっとしました。RPAに詳しい人のレビューだからと自分で考えもせず言われたことを鵜呑みにしていたことに気づきました。この経験を通して、自分の目で確認することの重要性と技術者として大切な仕事への取り組み方に気が付きました。
また、自分の意見を発信することも重要です。周りの人と意見が食い違うことになっても、自分の意見を言う。もし間違っていたらそれでもいいのです。お互いの意見を提案し合うことで、それぞれの意見の良いところを取り入れた、より良い解決策が生まれたり、他の良い提案が出てきたりと、品質の高い仕事をすることができます。また、ただ言われるままに仕事をするよりも、考えることや悩むことはとても疲れますが、自分の考えを持った方が仕事は何倍も楽しくなります。
時間がない
プログラムの作成は、意外とスムーズには進みません。RPAでは簡単な画面操作処理でもエラーが出たり、成功したと思ってもそれは不安定な処理で、必ず成功する処理とは言えず使う機能を変更しなければならなかったりとトラブルだらけでした。慣れない仕事や初めて経験する仕事は、時間の管理がとても難しいです。３０分で終わると思っていた仕事が、実際には１時間以上かかることもありました。
仕事を進めるときは、いつまでに何を完了するというスケジュールを立てますが、思ったように仕事が進まず、進捗が遅れて焦りました。また、別業務の割り込みの仕事が来ることもあるためスケジュールには余裕がない状態が続きました。遅れた分はどう取り戻すのか、今やっている仕事の進め方は本当に効率的なのか、仕事の優先順位はどうかなど、常に考えることを知りました。
また、分からないことがあるときには自分で調査しますが、その時間をコントロールすることも必要です。いつまでも分からないことに時間をかけるのではなく、上司や先輩に教えてもらったり、他にできる仕事から進めたりする判断をしなくてはなりません。ここでの注意ポイントは、教えてもらった内容を鵜呑みにしないことです。
また、会議を設定することは効率化の面で良し悪しの意見がありますが、RPAの開発では、毎朝15分程度、進捗状況と報告/相談、問題点などを共有していました。相談したい内容は全てメモ程度にまとめ、重要なものから議題に上げるなどの工夫をすることで、一気に時間の充実度が上げることも学びました。
さてプログラムの方は、一通りの修正が完了し、次は正しい動作をするかのテストを行うこととなりました。そのテスト実施時も、予想外のことが起きました。
・・・続く
【執筆者】
橋本
現在、新入社員に対する開発技術研修の企画／運営及び社内の開発技術力強化に向けた仕組み作りに従事。
池田
入社直後に社内プロジェクトでRPAの開発に従事。現在は、新入社員に対する開発技術研修等を担当。
※本記事は、三井情報Webサイトで掲載しているMKIナレッジを転載したものです。