RPA導入で必ず起こる、テストの問題とは

RPA導入で必ずぶつかる壁として「テスト」がある。いい加減にしたり、従来のシステムと同じ要領で行ったりすると、思わぬロボトラブルにつながってしまう。テスト時によくある7つの失敗事例とその原因を紹介する。

[西本 浩平，SHIFT]

　RPA導入のピークが終わり、知見がたまってきたように思える昨今だが、多くの企業で「ロボが止まる」「ロボが誤った動きをして業務が滞る」といった品質に対する悩みや課題の声を耳にする。SHIFTはこうした悩みに対し、開発や品質保証・テストを支援する立場でプロジェクトに参画してきた。

　前回は、品質に対する悩みや課題に対し、「RPAのロボをどうやって作成するか」という切り口で開発のあるべき姿やポイントを紹介した。次のテーマとして、ロボの品質を高めるために抑えておくべきテストのコツを解説する。

　RPAプロジェクトを成功させる上でテストは重要な工程だ。いい加減に行ったり、従来のシステムと同じ要領で行ったりすると、思わぬトラブルにつながってしまう。今回はテスト時によくある失敗事例を原因とともに紹介し、次回は、失敗をしないためのテストの計画と方法についてポイントを絞って説明する。

RPAのテストはどうして失敗するのか

　第3回で解説したように、ロボのトラブルは「ロボが止まる」「ロボが誤動作する」「ロボ停止に気付けない」「ロボを再実行できない」の4つに大別できる。テストの目的は、これらのロボトラブルの原因を見つけ、本番での発生を未然に防止することだ。

　しかし、実際には多くのプロジェクトで「テストの誤りや漏れ」が原因でリリース後の本番にロボトラブルが発生している。その結果、テスト担当者を含む開発部門は現場のユーザー部門から「なぜテストで見つからなかったのか」「テスト時には確認していなかったのか」などと、トラブルの要因を追及されることになる。なぜ、テスト工程を経たにもかかわらず、このようなトラブルが発生してしまうのか。その原因を、“誤りや漏れ”が発生する項目別にまとめた（表1）。

表1 「テストの誤りや漏れ」の項目と原因

　今回はロボの機能に関わる「機能観点」に焦点を当てているが、ロボのトラブルはこれ以外にもセキュリティや端末の動作のし易さ、性能といった「非機能観点」も含め、幾つかの要因がある。以降では、表1の項目1〜7に沿って、それぞれ事例を交えて詳しく紹介しよう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

著者紹介：西本浩平

SHIFT ビジネストランスフォーメーション事業本部 技術推進部 RPA推進グループ 兼 技術推進グループ

大手SIerをはじめ、金融、通信、EC関連企業など、さまざまな領域において複数のソフトウェア開発プロジェクトに参画。ソフトウェアの品質保証・テストの観点から、計画・設計、プロジェクト全体の体制構築、品質管理、PMO業務まで業務経験は多岐にわたる。現在は、金融機関のRPAプロジェクトの開発および品質保証業務に注力するとともに、大手通信系企業の品質標準プロセスの構築推進にも従事する。

企業紹介：SHIFT

ソフトウェアの品質保証・テストの専門企業として、金融機関や保険会社、大手流通系企業や自動車メーカーに至るまで、さまざまな領域における企業のITシステムやソフトウェアの品質向上を手掛ける。製造業の業務プロセスコンサルティングを前身とすることから、プロジェクトおよびプロダクトの品質向上を目指した業務プロセス改善には、独自のノウハウと数多くの実績を持つ。2017年ごろからは、RPAロボットの開発・運用に関するご相談が急激に増え、2018年にはRPA診断改修サービス「ROBOPIT!」の提供を開始。現在は専任部署を立ち上げ、RPA事業に取り組む。