はじめに
この記事は、RPA Advent Calendar 2024の15日目の記事です。
寒いですが、頑張っていきましょう。
なお立場上、本件の事象に当てはまる方とそうでない方もいます。
あくまでも「客先に常駐することが多いプロ開発者」の視点で見ていただけると幸いです。
実は...
昔、以下のような記事を投稿しました。
おかげさまで、多くの方に見ていただけてとても幸いです。
ありがとうございます。
この記事では、追加でつまづきがちな点を挙げていこうかと思います。
追加で説明する点
今回は以下2点について取り上げたいと思います。
①検証と本番等環境に関係なく、システムの文字どころか画面要素が取得できない
②対象のシステムでエラーがあったとしても、そこで中止してよいのか
①検証と本番等環境に関係なく、システムの文字どころか画面要素が取得できない
RPAでは、文字の取得や画像の取得も可能ですが中にはそれすらも受け付けづらいシステムが存在します。
実は過去、ボタン取得や一部要素の文字列取得に苦戦したシステムがありました。(某金融系のシステム)
ボタン要素の取得どころか、テキスト取得もままならない...
そんな時に自分は全体の文字列を取得(Get Full Textアクティビティ)して、文字から位置を特定してみるなどで回避しました。
ただ正直無理そうな場合はユーザーに「(このシステムで自動化するのは)無理です！」といって回避するしかないようです。
時には、別の方法を模索するほうが良さそうです。
②対象のシステムでエラーがあったとしても、そこで中止してよいのか
対象のシステムでエラーが出れば基本は中止するという選択肢になると思いますが、ユーザーにとっては特に問題ないことかもしれません。
これはヒアリングが不十分で起きたミス？といいますか認識不足で起きたものですが、自分はある実行内容に際しエラー=中止なのかと思っていたら実はそのミスは業務上カバー可能なものであり、ロボットの後続実行に影響がないと判明。結局改修が発生したため、もっと早くに気づけていたらこの改修は発生しなかったと思います。稼働時間は無限でないため非常にもったいないです。
つまり、そのシステムでエラーが出たとしても無意識に中止すべきでなく、 「これは本当に止めるべきエラーなのか」、「ここで発生するエラーは、業務内で確認できるもののためロボットの動きに影響はないのか」 という点で常に疑問を持ちながらヒアリングや要件定義をまとめていくことが大事だと気付きました。
与えられた情報つまりユーザーから受領する手順書の内容に疑問を持ち、実際に検証環境でわかる範囲まで進め、本当に問題ないことなのかそうでないのかを確認するのが無難と思います。
まとめ
上記は、今年の業務中に起きたつまづきや気づきに関することです。
①ですが、RPAとの相性が悪めのシステムも存在しますし、無理して続行することは難しいのであれば手順変更やその作業のみスキップして可能な範囲だけ実行するという形で申し出るという選択も一つだと思います。
また、②ですが要件定義の難しさを改めて知ることになった良い経験だと思っています。
「ユーザーの手順書を完全に鵜呑みにするのでなく、RPAで想定する動きとともにどうするのがベストな選択か」 という点は皆様にも役立てることのできる点ではないでしょうか。
最後までお読みいただきありがとうございました。