IT開発とRPAのベストミックス

連載 [第7回] :

2021年1月22日(金)

IT開発への業務ユーザの巻き込み

インターネット上のアプリケーションのホスティング会社Herokuのエンジニアが提唱したThe Twelve-Factor Appに基づく開発は、モダンなWebアプリケーション開発のスタンダードで、開発者の共通言語であると考えます。コンテナ化やマイクロサービスでの開発、運用を見据えた場合、この理念を遵守することが基本となります。

最近のWebアプリケーションであれば、フロントエンドとしてSPA(Single Page Application)や、さらに最新のPWA(Progressive Web Apps)をReactやVue.jsなどのフロントエンドのフレームで開発し、バックエンドはマイクロサービスで開発します。その際に、バックエンドとはRest APIで連携することにより、マイクロサービスの利点である疎結合が実現します。そのAPIにはRPAも接続され、業務ユーザの自動化処理と連携がされることが期待されます。

先ほどの例だと、最低限の画面機能はSPAで実現します。バックエンドは業務の基幹となる機能を提供し、具体的にはデータの永続化でトランザクションやマスタデータを管理します。前述の細々としたユーザの要望や過去の慣習で作成した本当に必要かどうかといった作業は、バックエンドのAPIを通してRPAで効率化というアーキテクチャが実現できます。各APIはフロントのSPAやRPA、その他システムから共通利用されます。

なお、決して「SPAで開発しなさい」というものではなく、従来ながらのMPA(Multi Page Application)と呼ばれるサーバ側でHTMLを作成する技術を利用することも否定しません。RPAであればWeb画面の自動化も可能ですが、拡張性や業務ユーザを巻き込むという点で、MPAで画面開発をする際もAPIを用意しておくことは得策です。

以前は、APIを提供した場合、Webサービスとして他システムやMobileアプリが対象でしたが、今後は業務ユーザも自身の自動化を目的に、APIのクライアントとして利用していくことが今後の然るべき姿ではないかと思います。

RPA時代のテスト自動化

ここでは、「DevOps」を念頭においたIT開発におけるテスト自動化について考えます。主に結合テスト以降のテスト自動化についてより詳しく考察していきます。

最初に、テスト自動化における単体テストについて振り返ります。xUnitに代表されるUnit Testで、アプリケーション開発全般においてUnit Testのテストコードを作成することは、アジャイル開発であれウォーターフォール開発であれIT開発においては一般化しています。技術の側面からも開発対象のプログラミング言語でテスト用のコードも作成するため、テストコードは期待通り動きます。基本的に「テストコードが上手く動かない」という問題は発生しません。加えて、一般的にテストファーストのアプローチも重要視され、日本国内においても市民権を得ています。

単体テストのコードは、開発中だけでなく、リリース以降、テストフェーズ終了後でもリファクタリングを行う勇気をくれるものです。特に、保守フェーズで他人が作ったものでもテストコードがあると修正箇所の確認の工数が大幅に下ることは過去何度も経験しています。反対に、まともな単体テストのコードがないプロジェクトでは、そのプログラムの振る舞いの解析に膨大な時間を要し、何度も苦労をしてきました。

次に結合テストについて考えます。Webアプリであれば、実際のブラウザでどう動くか、フロントとバックエンドの連携は期待通りの挙動か、サポートするOS/ブラウザの環境やバージョンもテストする必要性はあるかなど、やるべきことのプライオリティも高いです。当然、結合テストも自動化したいところですが、残念ながら未だに手動で行うことが多いです。中でも「Selumiue」などのOSSが最も使われているのではないでしょうか。

私としては、この領域はなかなか自動化が定着しない領域だと考えます。正直なところ、数年前にもいくつかこのようなツールはありましたが、お世辞にも継続的に使えるものではありませんでした。

しかし、昨今のRPAの台頭と、この領域への大規模な投資により、UI自動化は確実に進歩しました。この技術はテスト自動化にも使用するべきです。手前味噌ですが、UiPathでは「Test Suite」という製品を提供しており、コーディングの知識がなくても自動テストの作成が可能です。

Webアプリケーションのブラウザを使用したUIテストはもちろん、API呼び出しやデスクトップアプリに関しても安定的な自動化が可能です。そのため、手動で行うテストの再現はほぼ可能と言っても過言ではありません。したがって、前述の通り人が行うという点で、UATにも適合できます。

CI/CDでのテスト自動化の活用

ここからは、DevOpsにおけるCI/CDの領域について考えます。CI/CDとは、Continuous Integration(継続的インテグレーション)、Continuous Delivery(継続的デリバリー)、または、Continuous Deployment(継続的デプロイメント)が相対する日本語です。

下図は、今回、私が提唱する今後のCI/CDを表したものです。

開発者によるコードのリポジトリへの登録からリリースまで、一貫して自動化されています。ただし、自動化することが全てではなく、適材適所で人によるチェックを設けることは引き続き重要です。ここでは、CI/CDツールの「Jenkins」をCI/CDの管理ツールとして使用した例を説明します。

開発者はソースコードをコミットし、リポジトリへプッシュします。これをトリガーとしてJenkinsが呼び出されます。

まず、Jenkinsは、UnitTestが自動実行され、全ての単体テストをパスするか確認します。次に、開発中のアプリケーションがビルドされ、テスト環境などの検証用の環境へデプロイされます。その後、テスト環境のアプリケーションに結合テストが自動実行されます。UiPathを使用した場合はJenkinsと連動し、結合テスト用のテストケースが自動実行されます。

結合テストに問題がなければ、さらにユーザが作成したUATのテストケースに従ってUATが自動実行されます。最後に、これまでの全てのプロセスに問題がなければ、本番環境へアプリを自動でデプロイします。

本番環境へのリリース以降、業務ユーザはそのアプリケーションを業務利用する一方で、ルーティンワークに関しては、APIを通してRPAによる自動化が可能となります。

この図は、前述した通りBizの業務ユーザがRPAを使用して対象の業務アプリケーションへAPI連携し、自身の業務の自動化も行われていることを示しています。加えて、実施できると良いものとしては、UATに関してもITスキルのある業務ユーザ自身がUAT自動化のテストケースを作成することです。UATの責任は業務ユーザが負うことに代わりありませんが、UATのテストケースも自身で作成することでその責任範囲はより明確化されます。

また、ポイントとしてコンテナ開発にすることで環境のスクラップ&ビルドが簡単にできます。この例ではステージング環境の構成時にデータもスクラップ&ビルドで初期化してしまいます。これにより、結合テスト、UATの自動化されたテストケースは、今テスト環境のデータがどうなっているかといったテスト自動化の際のつまづきポイントは考慮不要で、テストケースを作成できるという非常に大きいメリットが享受されます。

このように、自動化テストツールやRPAの発展により、CI/CDでできることが従来よりもより高度に、より安定化されると考えます。今までDevOpsとして業務ユーザ、ないしはユーザはあまり考えられていませんでしたが、エンタープライズのITという点では、このBizDevOpsの考えや役割分担もITの競争力を向上させるためには重要です。

アフターデベロップメントの場合

既にIT開発は終わっているが、開発時にちゃんとCI/CDをやっていなかったから、もう手遅れだと考えるのは誤りです。保守運用に負担がなければ特にお勧めするものではないですが、保守運用に苦労しているという場合は非常に有用です。よくある事例としては開発は別のチームや別のベンダーが実施し、保守フェーズ以降から担当になり、内容がよくわからないといったケースでCI/CDの概念は機能します。

私もとあるプロジェクトで仕様も曖昧、コードもハチャメチャというシステムの改修に携わった際に、後付けで結合テストとして一部単体レベルのテストも含める形でテスト自動化のプロセスを構築しました。これにより、必要とされた改修箇所の整合性の担保や、新規のテスト自動化という点で大きな恩恵が得られプロジェクトを完遂できた経験があります。