はじめに
UiPath Studioを用いてのRPA開発を行っております。
業務担当者と要件ヒアリングを実施して本番リリースするまで、認識合わせのための時間を多くいただいております。
業務担当者側では、自身の業務について熟知しておりますが、RPA化に伴いチェックポイントを落とし込めないケースが多々あると思いました。
過去の開発経験でチェックまたは説明したほうがよいポイントをナレッジとして残します。
この記事の対象者
- UiPath初学者
気をつけているポイント
入力値と取得値チェック
ロボでデータ入力を行うケースは多々あります。システムのデータ検索条件の入力・既存データ更新等で入力処理を行われると思いますが、「ロボでデータ入力 → 入力したデータ取得」の工程を入れるようにしています。
ロボでは決められたルールに沿って処理を行いますが、他システムでデータ入力を行う場合、システム毎に入力可能文字・入力可能文字数制限があります。
ロボで正しく入力したつもりですが、実は正しく入力できていないケースも起こり得るため、「ロボでデータ入力 → 入力したデータ取得」の工程を入れることにより正しく処理が行われたかの整合性チェックは重要となります。
| チェック対象 | チェック観点 |
|---|---|
| 文字数 | 入力した文字数が正しいかチェック(数字の場合、先頭に0がある場合システム側で省略されるケースもある) |
| データ入力 | 入力内容の整合性チェック(顧客情報の更新やステータスが正しいか確認する) |
ロボで入力値と取得値のチェックを入れていない場合、誤った情報のデータ更新を行われるケースがあります。その場合、インシデントに繋がるケースも多々あるため、入力値と取得値のチェックを入れることを強くオススメします。
メッセージチェック
ロボで特定ボタンを操作する場合、メッセージ表示されるケースがあります。
処理内容によっては特定の画面が表示された場合にそのまま処理を行うように作っている方もいらっしゃいますが、とても危険になります。
ロボで操作する場合、セレクターで操作するアイテムを設定するのですが、セレクター取得がid取得ではなくidxの場合、システム更新に伴い表示するボタン位置が異なるケースもあります。
その場合、本来データ更新のみを想定して作られているのですが、セレクター位置が削除処理を行うボタンの場合、データ削除として行われるケースがあります。
システム側で削除時に確認メッセージが表示または削除完了の旨もメッセージが表示された場合、ロボ側でメッセージチェック判定を入れていると想定外の削除処理を未然に防げるまたは想定外メッセージの場合にシステムエラーで落として原因分析を行えます。
メッセージチェックを入れていない場合、入れてみることをオススメします。
| 処理内容 | チェック観点 |
|---|---|
| 検索(SELECT) | 検索対象データが存在有無 , 検索件数が多い場合のメッセージ有無 |
| 登録(INSERT) | 登録時のポップアップメッセージ表示有無 , 想定通りのメッセージチェック |
| 更新(UPDATE) | 更新時のポップアップメッセージ表示有無 , 想定通りのメッセージチェック |
| 削除(DELETE) | 削除時のポップアップメッセージ表示有無 , 想定通りのメッセージチェック |
データ件数が10件程度の場合、処理内容によってはリカバリー可能ですが、
100件~1000件とデータが多くなるにつれてリカバリー対応は難しくなります。
データに対して処理が行われる場合はメッセージチェックを行うことを強くオススメします。
利用システムの負荷確認
社内システムまたは社外システムで確認観点は変わってきますが、ロボでは条件を満たす限り繰り替えし処理を行うことは可能です。
人の手で操作する場合、画面確認や入力内容を確認してシステムの更新処理を行います。
処理するデータによっては時間にばらつきがあり、ロボの場合、人と比べてはるかに早い時間で入力およびデータチェック処理が行われます。
そのため人の操作に比べて処理するスピードが早いのでシステムに対して負荷がかかります。
負荷がかかりすぎる場合、システムが落ちてしまうケースも起こり得るため、ロボで利用したいシステムが決まっている場合、負荷対策に関してシステム側とお話しする必要があります。
システム負荷軽減策の例として、「一定回数のシステム再起動、一定時間の待機処理」などあげられます。
ロボで操作するシステムが基幹システムの場合、システム停止による影響範囲は甚大になります。ロボで操作前には事前に相談を行い対応策の検討が必要になります。
処理するデータが一意になるか確認
処理するデータは検索方法によっては大量にデータが表示されるケースもあります。その場合、本当に処理を行いデータなのか判断がつきません。極力は表示されるデータが一意になる画面で操作するのが好ましいです。システム側で一意にならない場合、処理対象条件を細かく取り決めることにより限りなく想定した処理するデータに近づくことは可能です。
要件ヒアリングをしっかり行い業務内容に十分な理解を持ってから実装することを強くオススメします。
おわりに
今回は私自身がRPA開発時に気を付けているポイントを簡単にまとめました。
現時点で思いついたポイントをメモベースとしてまとめておりますが、今後気になった点がありましたら追加する予定です。今回の記事で誰かの参考になれば幸いです。