MKI品質を目指して：RPAやってみた！Vol.3
RPA導入プロジェクト、いよいよ最終章へ！
前回までの『RPAやってみた！』では、私が新人のときに担当した、社内の定型業務自動化プロジェクトで実装したRPAのこと、そして、RPAについて全く知らない状態から、要件定義、実装、ソースレビューおよびプログラム修正までのプロセスを通して学んだ仕事の進め方や、気づきをご紹介しました。
今回は最終編ということで、作成したRPAが本当に期待する正しい動作をするか、確認するためのテストを行ったところからお話します。
Vol.1、Vol.2をご覧になっていない方は、是非こちらからご覧ください。
テスト仕様書を作成してみた
テストは作成したプログラムが期待通りに動作するか最終確認する場で、欠かせないフェーズです。テストを実施するためには、まずテスト項目を洗い出してテスト仕様書を作成します。テスト項目は、大きく分類すると以下のようになります。
・開発者やユーザが期待する動作（今回はアプリケーションが新規に受信した電文を保存するといった動作）
・エラーが発生した際の動作（電文を保存できなかったときの動作）
・性能面（プログラムの実行にかかる時間など）
ここからさらに、プログラムの内容全てを網羅する処理のパターンを洗い出し、それぞれについて細かいテスト項目を挙げてテスト仕様書に書いていきます。
例えば上に挙げた「アプリケーションが新規に受信した電文を保存する」動作では、保存の際につけるファイル名の命名規則や保存先が電文の書式ごとに異なるような要件であるため、全ての電文の書式のパターンについてテストをする必要があります。これにより、どの種類の電文を受信しても正しく保存できることが確認できます。また、要件の内容以外でも、作成したプログラムのひとつの処理も逃さずテスト項目に組み込むことが必要です。性能面では、例えば新規電文が100件あった場合、プログラムの開始から終了まで何分かかるのかといったテストもします。
とにかく「○○の場合、かつ○○の場合、このような結果が得られること」というような細かい内容を洗い出し、テスト項目を作ります。
書き終えたテスト仕様書は上司のレビューを受けます。１日かけて30件以上のテスト項目を洗い出し、細かく条件や実行結果を書き、書式もきれいに整え自信をもってレビューに臨んだ私でしたが、テスト項目に漏れがあったり、テスト条件や実行結果の粒度が荒かったりといったことを指摘されました。
例えば、期待する実行結果として「メールを送信する」という内容があったとします。その場合、ただ「メールが業務担当者に送信されること」と書くのではなくて、件名や実際に送信される文章なども盛り込む必要がありました。テスト仕様書は、プログラムの内容を全く知らない人がテストをしたとしても、確実に正しい実行結果が得られているかを確認できるものでなければなりません。レビューを経て、テスト項目はさらに10件追加され、各テスト内容も粒度の細かいものになりました。
テストをやってみた
テスト仕様書が作成できたところで、いよいよ実際にテストをしていきます。私は、RPAを実装しているときに全てのエラーや不安定な動作を解決してきたため、バグはきっとないだろう、テストはスムーズに終わるだろうと思っていました。
しかし、期待しない結果になるテスト項目が複数出てきたのです。私はバグがあるとは思っていなかったため、とてもショックでした。心あたりのあるエラーの原因を探しても解決せず、上司に相談しました。すると「テストはバグが無いことを確認するためにやるのではなくて、バグを出すために行うものですよ。」と言われました。コンピューターは正しい動きをしてくれますが、基のプログラムは人間が作るものなのでやはり完璧ではない。その潜んでいるバグを出しつくして、実際にユーザが使い始めてから問題を発生させないようにするためテストを行うということを学びました。
実際にエラーの原因は予想もしていなかった処理で発生していて、全ての処理のテストをする意味と、テストで全てのバグを見つける重要性を知りました。
もしテストを実施して一つもバグが出ない場合は、テスト項目に不備があると考えて、テスト仕様書の作成からやり直す必要があります。私はそれから、バグが発生したら「良かった！バグが出た！」と考えるようになりました。
また、テストは1回のみならずバグが無くなるまで2回、3回と繰り返します。1回目では問題が無いように見えたテスト項目が、2回目では期待した実行結果にならず不安定な動作であることが判明したり、要件の追加に関わるようなバグの発生もあったりしました。
「付加価値のある最高品質のものを創る」ため、テストでの品質の確認・向上はもちろん、ユーザビリティ（本当にユーザが使いやすい仕様になっているか）や、保守運用のしやすさといった点もテストを実施しながら見直します。
一通りのテスト項目をバグなく終えられると、やっと品質を担保することができます。
まさかこんなことが起きるとは
テストが終われば、開発チームが担当していた仕事も終了です。これで保守運用担当者に引継ぎをし、実際にRPAを使ってもらうことができるというところまで来ました。しかし…ある朝自動化した電文を受信するアプリケーションを開くと、これまで見たこともないポップアップが表示されたのです。
開発チームに不穏な空気が漂います。調べるとRPAの動作に関わる内容だと分かり、早速改修を始めます。Vol.1でもお話しましたが、RPAには「決められたこと以外はできない」というデメリットがあります。プログラムに組み込んでいないことが起きるとエラーが発生し、異常終了することがあるのです。そのためRPAの実装ではユーザに求められている処理だけでなく、エラー発生をくみ取る処理を盛り込むことが極めて重要です。エラーが発生したら保守運用担当者にメールを出すというような処理を入れておくことで、保守運用しやすいRPAになります。追加実装を終え、再度テストを行います。
さあ、今度こそ大丈夫だと思ったら…。ある日、自動化したアプリケーションがアップデートされていました。RPAを動かしてみると動きません。調べてみると、このアプリケーションは１年に１度アップデートされることが分かりました。今度はアプリケーションのどこに変更があったのかを全て洗い出し、バージョンアップしたアプリケーションに対応するRPAに改修していきます。
RPAは決まった手順の定型業務や事務作業など、繰り返し行うルーティンワークを自動化することで人手不足の改善、働き方改革の実現などに効果がありますが、定型業務だとしても“どれだけ単純か”“不定期に予想外のアクションが起きないか”を把握したうえで、本当に自動化した方が良いのか考える必要があります。なんでもかんでも自動化せずに、本当に自動化に向いている定型業務か、自動化するメリットとリスクを考えて、判断することも大切です。
おわりに～RPAはユーザのもとへ～
仕様の最終確認ということでユーザにRPAをお披露目しました。実際のRPAの動作を見せてRPAはどのような流れで処理を行うのか、運用時にユーザに気を付けてほしいことなどを伝えます。ユーザに合意をいただき、開発チームはほっと一安心しました。
山あり谷ありのプロジェクトでしたが、その後、マネジメント担当者を通してユーザから「RPAを作るために我々の業務や自動化するアプリケーションの詳細な仕様についてまで細かく調べて理解してくれたことに感動した」というメッセージをいただいたときは、「この仕事を頑張って良かったな」と社会人になってから１番、心から嬉しかったです。
プロジェクトを通してRPAについて沢山の知識を得たのはもちろんですが、技術者として、ユーザから伝えられた内容だけで判断したりその通りにシステムをつくるのではなく、ユーザ業務やそれに関連することを開発者自身で調べ尽くすこと、そしてとても解決できないような問題があったとしても、簡単に「できない」と言わず「どう実現するか」考え、ユーザに最高の価値を提供しようとする姿勢は決して疎かにしてはならないということが強く心に残りました。
3回にわたって私の経験や学び、気づきについてお話してきましたが、読者のみなさまにも印象に残るものがあれば幸いです。
【執筆者】
橋本
現在、新入社員に対する開発技術研修の企画／運営及び社内の開発技術力強化に向けた仕組み作りに従事。
池田
入社直後に社内プロジェクトでRPAの開発に従事。現在は、新入社員に対する開発技術研修等を担当。
※本記事は、三井情報Webサイトで掲載しているMKIナレッジを転載したものです。