RPAのテストは難しい？ 必ず押さえたいポイント
RPAがよく止まるという悩みを抱える企業は多い。原因の1つは、行うべきテストができていないことにある。必要な情報や条件を整理することが難しいテストを、ユーザー部門や開発担当者がどう行えばよいのか――ポイントを解説する。
前回紹介した通り、RPAロボット（以下、ロボ）のトラブルは「テストの誤りや漏れ」が原因で起こることがある。この“誤りや漏れ”を回避するためには、テスト担当者を含む開発部門と現場のユーザー部門が、テスト実行の前段階でテストの目的やゴール、方針に関する共通認識を持つことが重要だ。さらに、リリース後のロボと、ロボを活用する現場の業務が最終的にどのような状態になることをゴールとするかも共有しておきたい。
この認識合わせのために重要なのが、テスト工程の第一段階である「テスト計画」だ。今回は、「RPAの品質を高めるテスト」をテーマとした記事の後編として、リリース後の本番でロボのトラブルを起こさないためのテスト計画について解説する。
テスト計画のフェーズでは、開発側と現場のユーザー部門が、プロジェクトをトラブルなく推進し、リリースを迎えるために必要な情報を決定する。それらの情報を可視化するための、アウトプット資料として「テスト計画書」が作成される。どのようなポイントがあるのか。
目指すべきターゲット品質について
RPAのテスト計画では、ロボ開発における「ターゲット品質」を定義し、そのターゲット品質を達成するための方法を決定する。以下の2つが重要なポイントだ。
1．対象となるロボの「ターゲット品質」を定義する
- 「RPA品質の指標」を決定し、可視化する
- 「ターゲット品質」を決定し、可視化する
2．「ターゲット品質」を達成するために必要な情報を整理する
- 「テストタイプ」を洗い出し、可視化する
- 「テストデータ」を洗い出し、可視化する
- 「環境差異から発生するリスク」を洗い出し、可視化する
以上の1、2に沿って、事例を交えながらRPAのテスト計画の流れを詳しく説明しよう。
対象となるロボの「ターゲット品質」を定義する
RPAのテスト計画では、ターゲット品質の定義が必要だ。これは、ロボがリリースされた時点で満たしているべき品質のレベルを指す。
「RPA品質の指標」を決定し、可視化する
ターゲット品質を定義するために、まずはユーザー部門と開発部門の両者がRPAの品質を評価する際の指標（以下、指標）を決定し、テスト計画書にまとめる。これを、テストの目的やゴールの共通認識として用いることで、認識違いによるリリース後のトラブルを防げる。
この際、ソフトウェア開発における品質評価の指標として用いられるISO/IEC 9126による、品質特性モデルという考え方を流用し、RPA開発の品質特性に合わせて指標を定義すると良い。品質特性ごとに指標を定義し、可視化することでターゲット品質を定義できる。
図1は、実際に品質特性モデルを用いて、「RPA品質の指標」を定義したものだ。
指標がユーザー部門と開発部門の認識共有にどう役立つのかを、図1の「信頼性」という品質特性を例に解説しよう。
リリース後のロボのトラブルとして発生しやすい「ロボが止まる」という事象がある。これは、何もロボ自体の不具合だけが原因で起こるものではない。ロボと連携をしていた外部システムのエラーや、ロボを操作するユーザーが間違った使い方をした場合にもロボは停止する。
図1の「信頼性」の品質特性において、指標となるのは「異常時に正しく停止し、（停止したことを）検知でき、再度業務を再開できること」であるが、ユーザー側がこの指標を「どのような場合もロボが止まらないこと」だと誤って認識していた場合、開発側といつまでも認識の合意を得られず、ロボをリリースできない。指標の可視化は、このような認識の齟齬（そご）を生まないためにも重要だ。
「ターゲット品質」を決定し、可視化する
次に、開発部門は具体的なプロジェクトのゴールを定めるために、ターゲット品質を決定する。具体的には、指標を元に単体テスト・結合テスト・受入テストなどのテスト工程（フェーズ）ごとにロボの品質がどうあるべきなのか、落とし込む（図2）。これもテスト計画書の一部として可視化しておく。
図2のターゲット品質を作成することで、開発部門はテスト工程ごとにロボが満たしていなくてはいけない品質レベルを確認できる。ロボ品質に課題が発覚した際には、どの工程における課題が残っているのかを把握できる。
さらにテスト計画の段階で、ロボをリリースした後の運用フェーズにおいてロボをどのような状態に作り上げていくかというゴールも明確化し、決定しておけると理想的だ。これがより良いロボ開発につながる。
業務のRPA化という取り組みは、ロボを現場の本番環境にリリースすることがゴールではない。ロボはリリースした後、実業務における稼働を繰り返しながら、変化する業務の内容や条件、ユーザーの使い勝手に合わせて改修を続け、現場のユーザー部門にとって常に理想の状態に近づけるように運用する。ロボは現場に出てから経験を積むことで、成長し、一人前となるのだ。この考え方は、会社全体としてRPA導入を成功させるためにも最も重要なポイントである。また、ロボ開発を人の育成に例えるRPA開発の基本となる考え方なので、理解しておいてほしい。
以上のように可視化した指標やターゲット品質は、単一のロボ開発プロジェクト内でのみ活用するのではなく、全社の共通的な考え方として用いることが望ましい。
「ターゲット品質」を達成するために必要な情報を整理する
冒頭で述べたように、対象となるロボのターゲット品質を定義するだけではなく、ターゲット品質を達成するために必要な情報を整理することも重要だ。以下では、その必要な情報のうち、特に漏れがちな「テストタイプ」「テストデータ」「環境差異から発生するリスク」の洗い出しと可視化について説明する。
「テストタイプ」を洗い出し、可視化する
RPAの開発では、RPA化の対象となる業務の内容や条件の変更、開発時に想定していないイレギュラーな業務パターンが後から発生することを踏まえて、さまざまなテストタイプを洗い出しておく必要がある。
例えば、RPA特有のテストタイプとして「リランテスト」がある。これは、想定外の業務パターンによりロボが停止した場合を踏まえ、一度停止したロボが再稼働できるかを確認するものだ。こうしたRPA特有のテストタイプを含め、テスト計画の段階で洗い出し、可視化しておきたい。
テストタイプの洗い出しは、ターゲット品質に対して必要なテストが網羅されているかという視点で行う。
図2に記したターゲット品質の一部を例にした場合、必要なテストタイプは図3の通り洗い出せる。
注意したいのは、洗い出された「テストタイプ」を必ずしも全てテストする必要はないということだ。先に定義したターゲット品質の重要度や業務への影響の大きさ、テストを実行する上でのリソースや時間的制約をもとに、優先的に実行するものを判断する。
例えば、エラー後のロボの再実行の可否を確認する「リランテスト」は、実業務への影響が大きいため優先的にテストを行うことが多い。影響度が小さい他のテストタイプは、リリース後にロボを運用しながら実行していくことも可能だ。これらの判断は、RPA化の対象となる業務の特性や、ロボと連携するシステムの特性などによっても変わってくる。
手順の中で、実行すると決定した「テストタイプ」も、「テスト計画書」として図4のように可視化しておく。
「テストデータ」を洗い出し、可視化する
テストデータの準備を漏れなく行うことにも留意したい。テスト実行の段階で必要なテストデータがそろっていないことに気付き、慌てて準備をしていては、スケジュールや人員調整の面でもテストを計画通りに推進できない。
RPAの「テストデータ」は、大きく「テスト実施データ」と「テスト実施アカウント」の2つに分けられる。経費精算業務の例で言うと、経費申請を行うための、精算データ（定期申請データやタクシー申請データなど）をテスト用に準備することが「テスト実施データ」の準備である。また、テスト実行の際にユーザー部門や開発部門の人が経費を申請できるよう、アカウントを準備することが「テスト実施アカウント」の準備だ。
洗い出しを漏れなく行う工夫として、「テストデータ」とひとくくりに考えるのではなく、このように分けて準備を進めることが望ましい。一般的なソフトウェア開発において「テストデータ」というと、「テスト実施データ」というイメージが強く、「テスト実施アカウント」が漏れがちになるため注意が必要だ。
ロボが業務でPCにログインしたり、ツールを実行したりする際は、個人のアカウントではなく、ロボが関連するシステムを触るための「ロボ専用アカウント」を使用するケースがある。その場合、テストでもロボ専用アカウントが必要だ。企業によってはアカウントを作成するための社内承認に時間がかかり、テストが遅れてしまうこともある。早めの準備や根回しをしたい。
このように、欲しいときにすぐ用意できないデータもあることを承知し、テスト計画時に、「テスト実施データ」と「テスト実施アカウント」のそれぞれを表形式で一覧化して、可視化する。そうすることで、データ不足によるテストの実施漏れが起こったり、プロジェクトが遅延したりする羽目に陥らなくて済む。
「環境差異から発生するリスク」を洗い出し、可視化する
テスト環境と本番環境との差異に対する考慮と対策も重要だ。テスト環境ではロボが問題なく動作していたとしても、本番環境で扱うデータが異なっていたり、ネットワークの通信速度が違ったりすれば、リリース後にロボがうまく動かないケースも発生する。こうした事象は、テスト環境のみでテストを行い、リリース後にいきなり本番環境でロボを動作させた場合に起こりやすい。
そのため、RPAプロジェクトにおいては、テスト環境のみでテストを進めた場合のリリース後のリスクを考慮した上で、既存業務に影響を与えない範囲で本番環境を利用し、ターゲット品質に対する品質のつくり込みを計画的に進めることが重要だ。
まずは、事前にテスト環境と本番環境との差異を洗い出し、差異によるリリース後のリスクについて認識を合わせる。次に、本番環境を利用したテストを行えるように計画を練る。本番環境でロボを動作させる際には、自動化フローの中で実際には業務システムを更新させないようにしたり、ファイルの作成や更新処理をさせないようにしたりといった配慮が必要だ。リスクとなる作業の直前で停止できるロボを用意するなど、個別の対策も重要になる。
テストで本番環境を利用するとなれば、先述したアカウントの申請やユーザーとの時間調整にも手間がかかるので早めの計画、準備がポイントだ。本番環境でテストを実施した後に不具合が出れば、ロボをチューニングする作業も発生する。あらかじめ、不具合が出た場合のチューニング期間を明示的に設けて、計画を立てるのもよいだろう。
テスト計画書には、「本番環境をどう切り分けて利用するのか」「チューニングのスケジュールはどうするのか」という内容とあわせて、リリースまでの本番環境の利用スケジュールと関係部署、担当者など記しておくとよい。このように環境差異によるリスクを把握、予測しておき、あらかじめスケジュールを引いて準備することでトラブルを回避できる。
ここまでで挙げた、テスト計画書で可視化すべき要素はあくまで一例だ。他にも、改修確認テストの方針など、記しておくべき要素は幾つかある。OCRやBPMなどの他システムとRPAを連携させる業務においては、新たに可視化すべきことも増える。
繰り返しとなるが、RPAプロジェクトにおいてポイントとなるのは、ユーザー部門側の品質保証への関わり方だ。開発部門のみでロボを開発し、ユーザー部門が受入テストによる確認のみを行っても、相互に認識の合った状態、品質でのロボの開発は行えない。
テスト担当者を含む開発部門と現場のユーザー部門が、テスト実行の前段階で、テストの目的やゴール、ゴールに向けた必要な情報を可視化し、共通認識を持ちながら進めることが重要だ。
さらに、ロボをリリースした後は、実業務における稼働を繰り返しながら、変化する業務の内容や条件、ユーザーの使い勝手に合わせて改修を続け、現場のユーザー部門にとって常に理想の状態に近づけるように“成長させていく”ということも共通認識として必ず持っておきたい。
このように、“トラブルを起こさない”ためのポイントを押さえ、RPAのテスト計画を進めることはもちろん、起きてしまった“トラブルを繰り返さない”ことも重要だ。そのため、ポイントを押さえたRPAテストの計画や申請、準備のフォーマットを用意しておきたい。また、日々失敗から学び、都度繰り返さないためにそれらのフォーマットを更新し、管理することも忘れてはならない。
著者紹介：西本浩平
SHIFT ビジネストランスフォーメーション事業本部 技術推進部 RPA推進グループ 兼 技術推進グループ
大手SIerをはじめ、金融、通信、EC関連企業など、さまざまな領域において複数のソフトウェア開発プロジェクトに参画。ソフトウェアの品質保証・テストの観点から、計画・設計、プロジェクト全体の体制構築、品質管理、PMO業務まで業務経験は多岐にわたる。現在は、金融機関のRPAプロジェクトの開発および品質保証業務に注力するとともに、大手通信系企業の品質標準プロセスの構築推進にも従事する。
企業紹介：SHIFT
ソフトウェアの品質保証・テストの専門企業として、金融機関や保険会社、大手流通系企業や自動車メーカーに至るまで、さまざまな領域における企業のITシステムやソフトウェアの品質向上を手掛ける。製造業の業務プロセスコンサルティングを前身とすることから、プロジェクトおよびプロダクトの品質向上を目指した業務プロセス改善には、独自のノウハウと数多くの実績を持つ。2017年ごろからは、RPAロボットの開発・運用に関するご相談が急激に増え、2018年にはRPA診断改修サービス「ROBOPIT!」の提供を開始。現在は専任部署を立ち上げ、RPA事業に取り組む。
Copyright © ITmedia, Inc. All Rights Reserved.