この際、ソフトウェア開発における品質評価の指標として用いられるISO/IEC 9126による、品質特性モデルという考え方を流用し、RPA開発の品質特性に合わせて指標を定義すると良い。品質特性ごとに指標を定義し、可視化することでターゲット品質を定義できる。

図1は、実際に品質特性モデルを用いて、「RPA品質の指標」を定義したものだ。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図1　RPAのテスト計画書 「RPA品質の指標」

　指標がユーザー部門と開発部門の認識共有にどう役立つのかを、図1の「信頼性」という品質特性を例に解説しよう。

　リリース後のロボのトラブルとして発生しやすい「ロボが止まる」という事象がある。これは、何もロボ自体の不具合だけが原因で起こるものではない。ロボと連携をしていた外部システムのエラーや、ロボを操作するユーザーが間違った使い方をした場合にもロボは停止する。

　図1の「信頼性」の品質特性において、指標となるのは「異常時に正しく停止し、（停止したことを）検知でき、再度業務を再開できること」であるが、ユーザー側がこの指標を「どのような場合もロボが止まらないこと」だと誤って認識していた場合、開発側といつまでも認識の合意を得られず、ロボをリリースできない。指標の可視化は、このような認識の齟齬（そご）を生まないためにも重要だ。

「ターゲット品質」を決定し、可視化する

　次に、開発部門は具体的なプロジェクトのゴールを定めるために、ターゲット品質を決定する。具体的には、指標を元に単体テスト・結合テスト・受入テストなどのテスト工程（フェーズ）ごとにロボの品質がどうあるべきなのか、落とし込む（図2）。これもテスト計画書の一部として可視化しておく。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図2　RPAのテスト計画書 「ターゲット品質」

　図2のターゲット品質を作成することで、開発部門はテスト工程ごとにロボが満たしていなくてはいけない品質レベルを確認できる。ロボ品質に課題が発覚した際には、どの工程における課題が残っているのかを把握できる。

　さらにテスト計画の段階で、ロボをリリースした後の運用フェーズにおいてロボをどのような状態に作り上げていくかというゴールも明確化し、決定しておけると理想的だ。これがより良いロボ開発につながる。

　業務のRPA化という取り組みは、ロボを現場の本番環境にリリースすることがゴールではない。ロボはリリースした後、実業務における稼働を繰り返しながら、変化する業務の内容や条件、ユーザーの使い勝手に合わせて改修を続け、現場のユーザー部門にとって常に理想の状態に近づけるように運用する。ロボは現場に出てから経験を積むことで、成長し、一人前となるのだ。この考え方は、会社全体としてRPA導入を成功させるためにも最も重要なポイントである。また、ロボ開発を人の育成に例えるRPA開発の基本となる考え方なので、理解しておいてほしい。

　以上のように可視化した指標やターゲット品質は、単一のロボ開発プロジェクト内でのみ活用するのではなく、全社の共通的な考え方として用いることが望ましい。

「ターゲット品質」を達成するために必要な情報を整理する

　冒頭で述べたように、対象となるロボのターゲット品質を定義するだけではなく、ターゲット品質を達成するために必要な情報を整理することも重要だ。以下では、その必要な情報のうち、特に漏れがちな「テストタイプ」「テストデータ」「環境差異から発生するリスク」の洗い出しと可視化について説明する。

「テストタイプ」を洗い出し、可視化する

　RPAの開発では、RPA化の対象となる業務の内容や条件の変更、開発時に想定していないイレギュラーな業務パターンが後から発生することを踏まえて、さまざまなテストタイプを洗い出しておく必要がある。

　例えば、RPA特有のテストタイプとして「リランテスト」がある。これは、想定外の業務パターンによりロボが停止した場合を踏まえ、一度停止したロボが再稼働できるかを確認するものだ。こうしたRPA特有のテストタイプを含め、テスト計画の段階で洗い出し、可視化しておきたい。

　テストタイプの洗い出しは、ターゲット品質に対して必要なテストが網羅されているかという視点で行う。

　図2に記したターゲット品質の一部を例にした場合、必要なテストタイプは図3の通り洗い出せる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図3　ターゲット品質対して洗い出した「テストタイプ」

　注意したいのは、洗い出された「テストタイプ」を必ずしも全てテストする必要はないということだ。先に定義したターゲット品質の重要度や業務への影響の大きさ、テストを実行する上でのリソースや時間的制約をもとに、優先的に実行するものを判断する。

　例えば、エラー後のロボの再実行の可否を確認する「リランテスト」は、実業務への影響が大きいため優先的にテストを行うことが多い。影響度が小さい他のテストタイプは、リリース後にロボを運用しながら実行していくことも可能だ。これらの判断は、RPA化の対象となる業務の特性や、ロボと連携するシステムの特性などによっても変わってくる。

　手順の中で、実行すると決定した「テストタイプ」も、「テスト計画書」として図4のように可視化しておく。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図4　RPAのテスト計画書「必要なテストタイプ一覧」

「テストデータ」を洗い出し、可視化する

　テストデータの準備を漏れなく行うことにも留意したい。テスト実行の段階で必要なテストデータがそろっていないことに気付き、慌てて準備をしていては、スケジュールや人員調整の面でもテストを計画通りに推進できない。

　RPAの「テストデータ」は、大きく「テスト実施データ」と「テスト実施アカウント」の2つに分けられる。経費精算業務の例で言うと、経費申請を行うための、精算データ（定期申請データやタクシー申請データなど）をテスト用に準備することが「テスト実施データ」の準備である。また、テスト実行の際にユーザー部門や開発部門の人が経費を申請できるよう、アカウントを準備することが「テスト実施アカウント」の準備だ。

　洗い出しを漏れなく行う工夫として、「テストデータ」とひとくくりに考えるのではなく、このように分けて準備を進めることが望ましい。一般的なソフトウェア開発において「テストデータ」というと、「テスト実施データ」というイメージが強く、「テスト実施アカウント」が漏れがちになるため注意が必要だ。

　ロボが業務でPCにログインしたり、ツールを実行したりする際は、個人のアカウントではなく、ロボが関連するシステムを触るための「ロボ専用アカウント」を使用するケースがある。その場合、テストでもロボ専用アカウントが必要だ。企業によってはアカウントを作成するための社内承認に時間がかかり、テストが遅れてしまうこともある。早めの準備や根回しをしたい。

　このように、欲しいときにすぐ用意できないデータもあることを承知し、テスト計画時に、「テスト実施データ」と「テスト実施アカウント」のそれぞれを表形式で一覧化して、可視化する。そうすることで、データ不足によるテストの実施漏れが起こったり、プロジェクトが遅延したりする羽目に陥らなくて済む。

「環境差異から発生するリスク」を洗い出し、可視化する

　テスト環境と本番環境との差異に対する考慮と対策も重要だ。テスト環境ではロボが問題なく動作していたとしても、本番環境で扱うデータが異なっていたり、ネットワークの通信速度が違ったりすれば、リリース後にロボがうまく動かないケースも発生する。こうした事象は、テスト環境のみでテストを行い、リリース後にいきなり本番環境でロボを動作させた場合に起こりやすい。

　そのため、RPAプロジェクトにおいては、テスト環境のみでテストを進めた場合のリリース後のリスクを考慮した上で、既存業務に影響を与えない範囲で本番環境を利用し、ターゲット品質に対する品質のつくり込みを計画的に進めることが重要だ。

　まずは、事前にテスト環境と本番環境との差異を洗い出し、差異によるリリース後のリスクについて認識を合わせる。次に、本番環境を利用したテストを行えるように計画を練る。本番環境でロボを動作させる際には、自動化フローの中で実際には業務システムを更新させないようにしたり、ファイルの作成や更新処理をさせないようにしたりといった配慮が必要だ。リスクとなる作業の直前で停止できるロボを用意するなど、個別の対策も重要になる。

　テストで本番環境を利用するとなれば、先述したアカウントの申請やユーザーとの時間調整にも手間がかかるので早めの計画、準備がポイントだ。本番環境でテストを実施した後に不具合が出れば、ロボをチューニングする作業も発生する。あらかじめ、不具合が出た場合のチューニング期間を明示的に設けて、計画を立てるのもよいだろう。

　テスト計画書には、「本番環境をどう切り分けて利用するのか」「チューニングのスケジュールはどうするのか」という内容とあわせて、リリースまでの本番環境の利用スケジュールと関係部署、担当者など記しておくとよい。このように環境差異によるリスクを把握、予測しておき、あらかじめスケジュールを引いて準備することでトラブルを回避できる。

　ここまでで挙げた、テスト計画書で可視化すべき要素はあくまで一例だ。他にも、改修確認テストの方針など、記しておくべき要素は幾つかある。OCRやBPMなどの他システムとRPAを連携させる業務においては、新たに可視化すべきことも増える。

　繰り返しとなるが、RPAプロジェクトにおいてポイントとなるのは、ユーザー部門側の品質保証への関わり方だ。開発部門のみでロボを開発し、ユーザー部門が受入テストによる確認のみを行っても、相互に認識の合った状態、品質でのロボの開発は行えない。

テスト担当者を含む開発部門と現場のユーザー部門が、テスト実行の前段階で、テストの目的やゴール、ゴールに向けた必要な情報を可視化し、共通認識を持ちながら進めることが重要だ。

さらに、ロボをリリースした後は、実業務における稼働を繰り返しながら、変化する業務の内容や条件、ユーザーの使い勝手に合わせて改修を続け、現場のユーザー部門にとって常に理想の状態に近づけるように“成長させていく”ということも共通認識として必ず持っておきたい。

　このように、“トラブルを起こさない”ためのポイントを押さえ、RPAのテスト計画を進めることはもちろん、起きてしまった“トラブルを繰り返さない”ことも重要だ。そのため、ポイントを押さえたRPAテストの計画や申請、準備のフォーマットを用意しておきたい。また、日々失敗から学び、都度繰り返さないためにそれらのフォーマットを更新し、管理することも忘れてはならない。