RPA開発、3つのベストプラクティス、テスト駆動開発が求められる理由：テストドリブン型のRPA開発のススメ（1）
RPAの品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する連載「テストドリブン型のRPA開発のススメ」。初回は、テストドリブン型の開発手法とRPAに適用した際のイメージ、RPA開発のベストプラクティスなどについて。
RPAの品質向上、運用コスト削減
近年、「働き方改革」の機運に伴い、オフィスにおける業務効率化のソリューションの一つとして、RPA（Robotic Process Automation）が大きな盛り上がりを見せています。読者の皆さんも、少なからずRPAの開発や運用に関わっているのではないでしょうか。その中には、既に業務改善や生産性向上といったRPAの導入成果を成し遂げている方もいるかと思います。
一方で、RPAに関する共通の課題として、「RPA開発」は「IT開発」と比べて比較的簡単だが、開発後の運用が大変という声をよく聞きます。要するに、「RPAは品質管理が難しい」という課題です。
筆者は、「UiPath」というRPA製品ベンダーの社員として、日々お客さまのRPAプロジェクトを支援しており、RPAにおける品質管理を重要な課題と認識しています。
RPAというと、「ロボット」という言葉に注目が集まりがちですが、業務の自動化処理自体についてはわれわれ、人間によって作られるものです。その業務の自動化処理の開発に当たっては、RPAのみならず利用可能なソフトウェアやツールを最大限に生かし、企業それぞれの環境やルール、制約がある中で、業務の自動実行を実現する仕組みを創造する創意工夫が必要となります。
単純なルーティーンワークの自動化といえども、未来永劫（えいごう）、問題を起こさず自動化できるものを開発することは容易ではありません。RPAといえども「いかに効率的に網羅性のあるテストを行うか」は今後のRPAのテーマであると考えます。
今回、「テストドリブン型のRPA開発」というテーマで、RPAの品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介したく、筆を取りました。
下記の通り、最初にテストドリブン型開発を紹介し、2回目でRPAへのテストドリブン型開発の適用について解説します。最後の3回目ではテストドリブン型のRPA開発を自動化し、継続的インテグレーションのプロセスを確立する事例を紹介します。
- 第1回：テストドリブン型開発とは
- 第2回：RPAへのテストドリブン型開発の実践
- 第3回：継続的インテグレーションのアイデア
本連載の読者対象は、RPAに関わりのある方、RPA導入予定の方です。紹介する開発手法を実践できるように、具体的な方法論に関する技術的な詳細も解説します。
RPAにおけるテスト
RPAを推進している各企業でのRPA開発は、さまざまな形態が存在します。筆者がお客さま先で見てきた中で、大きくカテゴライズしますと、主要なものは次の2つです。
- 業務ユーザーが自身で自分の業務の自動化を行うもの
- IT部門や経営企画部門が業務ユーザーから業務内容をヒアリングし、その業務の自動化を行うもの
IT部門や経営企画部門が主導してRPA開発を実施する場合でも、「自社のITエンジニアが開発するケース」「開発は外部へ委託するケース」「コンサルティング会社に要件定義だけではなく開発も委託するケース」など、その形態は多様です。
皆さんご存じの通り、RPA開発は、IT開発の有識者や経験者のみならず、IT開発のバックグラウンドがないビジネスサイドの業務ユーザーや、業務改善で参画しているコンサルティング会社のコンサルタントといったIT開発の専門家ではなくとも、RPAのテクノロジーを使用することで、業務自動化が実現できてしまいます。これはRPAであれば、ITさらにはコーディングの知識がなくても開発が可能であることの証左でもあります。
「いろいろな開発形態がある」ということは、開発した業務自動化処理の品質に対するアプローチも多種多様であることを示します。品質に関しては、RPAプロジェクトとして開発標準を準備し、「その標準に準拠しているか」「テストフェーズを設けて各種テストケースをパスするか」などを検査することで品質を向上させることは、IT開発と同様にRPA開発でも同じ考えとなります。特にRPAのテストに注目すると、代表的なアプローチは次の3つだと思います。
- そもそもテストは実行せず、一度最後まで動けばOKとし運用する。運用しながら、問題をつぶし品質を高めていく
- 網羅性のあるテストを単体テスト、機能テスト、UAT（ユーザー受け入れテスト）と各工程で実施し、運用開始前に品質を高める
- 最低限のテストを実施し、ある程の品質となってから、運用開始する。必要に応じて改善し品質を高めていく
本稿は「RPA開発におけるテストはどのようにすべきか」を語るものではありません。筆者自身は、「どのようにRPAを活用するか」という目的により、「どのようにテストをしていくか」も変わってくるものだと考えています。
今回紹介する、テストドリブン型開発（「TDD」「テスト駆動型開発」とも呼ばれます）とは、IT開発、特にWebアプリケーション開発において、利用され発展してきたものとなります。筆者自身、RPA開発に携わる中で、現在もテストの在り方を模索しておりますが、このテストドリブン型開発が、RPA開発とも相性が良く、いずれのアプローチへの取り込みも可能なものとなります。
RPA開発の特性
テストドリブンの紹介の前にもう少しだけ、RPAの特性を紹介します。
まず、開発に関するトピックとして、一般的なIT開発とRPA開発を比較してみます。一般的なIT開発では、コーディング（実装工程）における半分以上は自身のコーディングの手直しに費やされるといわれます。これはコーダーであれば誰もが経験していることですが、コーディングし立てのプログラムが、初回実行で最後まで動くことはほぼ皆無です。コーディングしては動作を検証し、自分自身がコーディングの過程で作った不具合であるバグをつぶしていく必要があります。この作業自体がコーディングにおける半分近くの時間を要するといわれます。
一方で、RPA開発に関してはいかがでしょうか。私自身の感覚としては、この数字は少し大きくなり、3分の2程度が自身の作成した自動化処理（RPAでは、「ワークフロー」と呼びます）の手直しに費やされる感覚です。自動化処理の内容や自動化対象のシステムによって、この割合は変動しますが、自動化処理を開発するより、手直しの時間の方が、IT開発におけるコーディングよりも、割合としては多いものとなります。従って、RPAの自動化の開発においては、精緻な見積もりはなかなか難しいものです。
IT開発は「飼い犬をしつける」ものだとすると、RPA開発は「猛獣をしつける」ものというイメージです。猛獣のしつけの方は、不確定要素が多いため、見積もりの予想が困難であるといった感覚です。
この違いの理由として、下記のようなRPAの特性が挙げられるのではないかと考えます。
- 環境、テストデータが、IT開発と比較して、きちんとされたものが用意されていない傾向が強い。RPAはIT化が未完了の領域がターゲットとなり、開発用の環境はなく、本番環境で開発しなければならない。それに加えて、テストデータの用意が困難というケースが多く、テストの品質、効率に影響を及ぼす
- 自動化対象アプリとの相性の良しあし。初めて自動化を行うアプリケーションや業務の場合、その自動化対象となるアプリとの相性が、開発途中でどうしてもうまくいかないケース。時間をかけると、安定的な自動化方法を見いだすこともあるが、それまでに時間を要する
- 環境変化。開発途中でも、OSやアプリケーションのバージョンアップ、パッチ適用による自動化時の振る舞いが変わり、開発した自動化処理の直しが入る
テストドリブン型のRPA開発による期待効果
今回紹介するテストドリブン型のRPA開発は、これらの苦痛を少し和らげてくれるものとなります。具体的な効果としては、大きく次の2つが期待できます。
- 開発時に取りあえず処理を流すことが容易にでき、開発効率が向上する
- 運用保守の工程での品質維持コストが削減する
この開発アプローチは、現在の開発手法が、ウオーターフォールであれ、アジャイルであれ、「なんちゃってアジャイル」（私がよく陥ってしまうものです）であれ、適用可能なものです。今回の記事の目的としては、現在の開発手法や体制に負荷の少ない形で、RPAでの業務自動化の品質を向上させるためのTips、方法論、実践方法を提供するものとなります。
ただし、テストドリブン型で用いるテストは、開発者自身が行う単体テストとなるので、これが全ての品質を保証するものではなく、QAテストは別途行う必要があります。
IT開発後の運用フェーズにおいては、DevOps、CI/CD（継続的インテグレーション／継続的デリバリー）といった持続的な開発運用手法があり、将来、RPAにおいてもそのような手法が確立されていくものと考えられます。こちらについても、テストドリブンと関連させ一例を最後に紹介します。
そもそもテストドリブンとは
Copyright © ITmedia, Inc. All Rights Reserved.