「ターゲット品質に対する認識」の誤りや漏れ

　RPAを活用する現場のユーザー部門と、開発部門の間で、ロボの「ターゲット品質」についての認識に誤りや漏れがあると、リリース後のトラブルにつながることがある。「ターゲット品質」とは何か。これは、対象ロボの「リリース時に目指す品質」のことだ。例えば、あるロボのターゲット品質を「ロボをメインで活用する経理部門がロボを操作した場合に、想定した通りの動作を行うこと」だと定義したとする。この場合、開発部門はロボがリリースされた時点で、経理部門がロボを操作する条件下のみ動作テストを行い、その他の部門の活用は想定外扱いとなる。

　ユーザー部門と開発部門でこの「ターゲット品質」の認識が異なっていると、想定外の条件下においてロボが止まった際に、ユーザー部門はロボが期待した品質を安定的に満たしていないと思い、トラブルとして判断してしまう。これが、リリース直前の受入テストなどで発覚した場合、ユーザー部門は予定通りに業務がまわらないことを恐れ、開発部門に改修を依頼する可能性もある。このような例は、他にも業務上想定していないデータやうるう年など特殊なデータを受け取った際にも発生し得る。

「テストタイプ・観点」の誤りや漏れ

　「テストタイプ・観点」の誤りや漏れが原因で、「一度停止してしまったロボを再実行できない」というトラブルが起こる場合がある。テストタイプとはテストの種類を目的別に整理したもので、テストの目的に応じて実施すべきテストタイプは異なる。テスト観点とは、対象のテストで何を確認するのかという目的を指すもので「ロボが特定のデータをきちんと入力できるか」「ロボがファイルの作成途中で止まった場合に再実行できるか」など、テストを行う際の着眼点である。

　リリース後にロボが止まった際、ユーザー部門がロボの再実行を試みてもうまく動作せず、業務が滞ってしまうことがある。原因として、テストを行う際に「ロボ停止後の再実行」の確認を行うテストタイプが誤っていたり、ある特定のタイミング・観点においてロボが止まった際の再実行の確認が漏れていたりすることが考えられる。

　具体的な例で言えば、ロボが何かのファイルを生成したり、システムのステータスを更新したりする処理を行う場合、ロボを再実行する手順を追加で想定することが重要だ。ファイル作成や更新処理の直後にロボが停止し、最初から再実行する際には、一度作成したファイルを削除したり、ステータスを元に戻してから再度実行したりしないと、ロボがうまく動作しないことが多い。この場合「一度作成したファイルを削除する」「ステータスを基に戻す」といった手順の想定が重要になる。

「テストケース」の誤りや漏れ

　テストケースは、「この状態でこの入力を行えば、この処理が行われてこの結果が期待される」といった内容を記載したもので、テスト作業はこの指示に従って行う。例えば、経費精算業務に使うシステムでは「タクシー代の申請がある場合に、定期代と合わせて精算されていることを、個人の給与明細画面で確認できること」のようなテストケースが考えられる。

　RPAプロジェクトにおける「テストケース」の誤りや漏れは、ヒューマンエラー以外にも、テストケースのレビュー不足や、更新・反映漏れなどで発生する場合がある。テストケースのレビューは、業務を一番良く知るユーザーが行うことが多い。しかし、RPAプロジェクトは短いサイクルで徐々に進めることが多く、ユーザーがレビューに十分な時間を確保できないまま、テストを実施するケースも珍しくない。

　また、要件や仕様変更などを適宜取り込む方針の場合、それらを細かくドキュメントに落とさない限り、テストケースの更新も漏れがちだ。場合によっては、テストケース自体の確からしさが疑われ、“作ったものを正とする”というような事態にも陥りかねない。その結果、リリース後にテストケースの誤った箇所や漏れた箇所でロボが停止してしまったり、誤動作を起こしたりして、トラブルになることがある。

「テストデータ」の誤りや漏れ

　テストデータとは、テストケースを実行するために必要なデータのことである。先ほどの経費精算業務に例えると、ユーザーの経費である定期代とタクシー代のデータがこれにあたる。テストデータは、テストを行う前に用意する。

　「テストデータ」の誤りや漏れは、特に「ロボが誤動作する」「ロボが停止する」というトラブルにつながるケースが多い。このケースでは、実業務への影響範囲が大きい場合があるため、注意が必要だ。

　例えば、金融機関や保険会社などにおいて、本番環境と同等のデータは氏名や住所などの個人情報を含むため、セキュリティの関係上、リリース前には使用できないことが多い。リリース前のテストでは、ユーザー部門と連携し、データの個人情報部分をマスキングしたり、開発に必要な項目のみ埋めて本番同等のデータと見せかけたりして、可能な限り本番環境に近いデータを用いる。しかし、実際に本番環境でロボを動作させようと試みたところ、「想定外にロボが誤った処理を行ってしまう」「逆にロボが停止してしまう」といった事象が起こり得る。

　その他にも、同時刻に複数のデータが存在する場合や、月またぎ、年またぎなど時間軸に関わるデータ処理などを想定してテストを行っていないと、ロボが想定外のデータを受け取ったと判断し、停止してしまう事象もある。

「テスト手順」の誤りや漏れ

　「テスト手順」の誤りや漏れもロボの誤作動や停止といった事象につながりやすい。業務システムの操作手順や、停止時の再実行手順が漏れやすい項目だ。

　RPAを導入するプロジェクトでは、実際にこれまでユーザー部門が使用してきた業務システムをRPAロボに連携して利用することが多い。そのため、開発部門はテストの際に業務システムを操作することになる。しかし、業務システムの操作には、業務の専門的な知見や慣れが必要な場合も多く、操作を誤るとロボトラブルの原因になる場合がある。

　例えば、同じテストを繰り返し行う場合、いったん業務システムに仮登録したデータを削除し、テスト前の状態に戻して再び同様のテストを行う。その手順の一つに誤りがあった場合には、繰り返しのテストを同一条件で行えず、結果的にロボトラブルが発生してしまう。

「環境差異の考慮」の誤りや漏れ

　「環境差異」とは、本番環境とテスト環境との差異を指している。RPAはロボが動く環境によって動作や安定性が変わるため、本番環境によるチューニングが不可欠だ。以下に「本番環境とテスト環境による差異」の例を挙げる。どれもRPAテストにおいて考慮が漏れがちなものばかりだ。

• 端末性能やシステム性能の差異
• 端末解像度の差異
• ネットワーク通信速度の差異
• フォルダ体系の差異
• 業務システムURLの差異
• EUCの環境設定の差異
• ネットワーク環境設定の差異（Proxy設定など）

　差異によるロボへの影響は、実際に本番環境で動作させてみないと確認ができない。差異に関する考慮が漏れ、いきなり実業務で動作させたために、ロボが止まったり、誤動作したりするといった失敗事例も発生している。テスト時に本番環境の端末や業務システムの準備ができず、こうした失敗につながることもある。

「改修後のテスト範囲」の誤りや漏れ

　バグ修正などの変更をプログラムに加えた際、改修した箇所以外に影響が出ていないかを確認するテストを行う。その際、「改修後のテスト範囲」の誤りや漏れが発生すると、修正後のロボの品質が以前より悪くなるなどの、トラブルが発生してしまうことがある。

　例えば、経費精算業務の定期代の精算方法に不具合があり、それを修正したとする。このとき、定期代の精算方法の修正がタクシー代の精算方法に影響を与えてしまった。このような状態で定期代の精算方法のみ改修後のテストを行い、本来はテスト範囲とすべきタクシー代の精算方法のテストが漏れ、リリース後にトラブルとなってしまう、というような失敗事例がある。ちなみに、ロボの改修後のテストは煩雑な作業が必要なため、ソフトウェアのテストと同様に自動化を検討する動きが多い。

　RPAプロジェクトのテストでは、失敗のリスクが幾つもある。どのようにリスクを回避すればよいのか――次回は本編で挙げた失敗をしないための、テストの計画と方法についてポイントを絞って紹介する。