RPA導入の場合、プログラム開発ではないので正確にはDevOpsとは言わないかも知れませんが、少なくともシナリオ開発とRPA業務運用がお互いに協調して進める必要があります。
これによって、ビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速に業務ユーザーに届け続けることが出来るものとなるのです。
RPA はDevOpsで進める
DevOpsという言葉は、システム系の人以外にはあまり馴染みがない用語かも知れませんが、システム開発の段階から開発担当と運用担当が協力・連携して進めるべきと言う考え方です。
ウィキペディアによれば下記のように説明されており、
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。 開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。
Wikipediaより引用
2009年位から言われるようになり、このDevOpsと言う用語自体は最近よく耳にするようになってきています。元々、ソフトウエア開発の担当者と保守担当者は「ソフトウエアを通してビジネス価値を安定的に提供する」共通の目的を持っているはずなのです。
しかし、開発担当者はユーザーが求める機能を迅速に開発することで価値を提供しようとし、保守担当者は開発されたシステムが安定的に稼働することでビジネス価値を提供しようとする、方法の違いがあるため、従来はあまり協調する事がありませんでした。
RPA導入の場合、シナリオを開発して終わりにならず、その後のメンテナンスが大きなウエイトを占めますので、このDevOpsの概念はRPA導入において非常に重要ではないかと考えています。
RPAシナリオ開発と運用が協調すべき理由
RPAは導入して終わらない
RPAの導入は主にシナリオと言われる業務フローを一段詳細化した、プログラムフローに近いものとして作成しますが、一言でいうとRPAの場合、
業務運用に密接に関連しているため、シナリオ開発と運用を完全に分ける事が出来ない
と言えます。
一旦作成したRPAシナリオであっても、そのまま動作し続ける事はまれで、その実行状態を監視しメンテナンスしていく必要があります。
RPAは元々システム化し難い「柔らかい業務」をその対象とする事が多いため、取引先が増えたり、新商品の発売、キャンペーン・プロモーションなどの業務都合や自動化対象としていたシステムの仕様が変更になったりと様々な理由でメンテナンスが必要になったりもします。
また、業務の自動化・効率化にはこれで完璧と言えるような終わりは無く、継続的な運用・保守から更なる改善活動につなげていくことが重要となると言う理由もあります。
ビジネス価値に着眼している
上記の通り、DevOpsはビジネス価値に着眼しています。ソフトウエア開発と運用はそのアプローチ（手段）は異なっていますが、結局は同じ
ビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける
と言う共通の目標・目的を持っていて、どちらか片方だけではダメなのです。
RPAでも同様に、一旦シナリオを開発・リリースしたら終わりではなく、ロボットの新人に引き続いだ業務がうまく実行されているか、もっと良い業務のやり方は無いのか、教えていなかった例外処理が発生していないか、など継続的なケアが求められます。
この様に、「ビジネス価値の最大化」を中心に考えると、どの様にRPAロボットを使ってうまく業務を進めるべきなのか、シナリオ作成と保守は切り離せない点をご理解頂けるかと思います。
DevOpsの考え方を体制に組み込む
RPA導入のみを外部委託は出来ない
上記の様な点を考慮すると、どんなにRPA導入プロジェクトの経験が多いベンダーであっても、会社全体の業務を整理し、RPAを導入する部分だけを切り出し委託する事が出来ないと言う結論に至るかと思います。
RPAは業務運用そのものであり、RPAの保守・運用も一緒に委託する、イコール自社の業務そのものをそのベンダーに委託する事になります。
ERP等の基幹システムの保守・運用を導入したベンダーに丸投げしている企業が多くありますが、RPAで自動化する業務はどこの会社でもほぼ変わらない間接業務だけではなく、自社のコア業務を含む場合が多くあります。
もしくは、競合に対する優位性を決定する最重要な業務も含まれるかも知れません。
体制に組み込む
やはり、RPA導入の場合はプロジェクトの当初から、稼働後の運用を見越した体制を組んで、DevOpsとして開発・運用一体となって進めるべきなのだと思います。
特にRPAの場合、巨大なサーバー型システム開発と違って、１つのシナリオを開発してはリリースして使ってみる、いわゆるアジャイルアプローチのイメージが強くなります。
作成・テストが済んだRPAシナリオを本番リリースし、業務ユーザー、メンテナンス担当がその事項状況を確認しながら、次のシナリオ作成に取り掛かる。正に「開発」と「保守」が連携、一体で進めるべきものなのです。
RPAシナリオ開発はアジャイルで
ウォーターフォール開発ではない
ウォーターフォール開発モデルでは、プロジェクトの最初に開発すべき機能全体を最適化した状態で定義します。そして、水の流れが逆戻りしないのと同様に「決して逆戻りせず」設計・開発・テストと順次進めていくシステム開発の手法です。
元々はビル建設などのハード設計・開発プロジェクトに使われてきた手法ですが、大規模なシステム開発にも向いており、日本のSIでは今でもこのウォーターフォール開発モデルを主に使っています。
しかし、ここで注意して頂きたいのが、RPA導入において本当にプロジェクト当初から開発すべき機能を全て定義できるか、と言う点です。やはり、パイロット導入をして初めてRPAとはどの様なもので、向く業務向かない業務やどの程度の効率化効果を期待できるのか、感覚として理解できるのです。
そして、作成したRPAシナリオをテストしある程度満足のいくところまで自動化出来ると感じたシナリオから実際の業務に適用して様子を見ます。プロジェクト全体で作成する予定のシナリオ（全てを定義できたとして）の完成度を上げて一斉にリリースするような事は通常しません。
やはり明らかにウォーターフォール開発モデルではないのです。
アジャイル開発モデルとは
DevOpsに似た概念にアジャイル開発と言うものがあります。よくDevOpsと一緒に語られる事が多いシステム系の用語ですが、こちらは運用の事は言っておらず、ソフトウエア開発の進め方の事を言っています。
ウィキペディアによれば、
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称
Wikipediaより引用
開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1つの機能を開発する（⇒反復型開発）ことで、リスクを最小化します。そして、この反復のサイクルを継続して行うことで、1つずつ機能を追加的に開発してゆくのです。
各反復（イテレーション）が終了するごとに、機能追加された新しいソフトウェアをリリースすることを目指す、正にRPAを導入する場合の開発・リリースモデルそのものです。
まとめ
ご説明してきました通り、DevOpsと言う用語自体はソフトウエア開発・保守が連携・一体となって進めるべき、と言う概念的なものですが、RPAにおいても全く同様の事が言えるのではないかと考えています。
なぜなら、RPAもシナリオを作成し、一斉にリリース（切り替え）て終わりではなく、シナリオ作成が出来次第順次実運用に入り、稼働状況の様子を見ながら小改善を常に繰返す、業務改善の手法に近いのです。
それは正にDevOpsの考え方そのものであり、RPA導入・運用にも共通するところが多いのではないでしょうか。
