RPA（Robotic Process Automation）の導入を考える時、どうしても優先して注目してしまうのが、デジタル労働者であるソフトウェアロボットの作り易さです。
ロボットの作成には高度な知識が必要となり、とてもハードルが高いという懸念があるため、作り易そうなRPA ツールを第一優先にして選定する傾向があります。

プログラムレスということが特長で、UI（ユーザインターフェース）を用いて比較的簡単にロボット開発が行なえるRPA ツールは、多くの企業や組織で採用されています。
しかしながら、ロボットが停止したとしてもあまりインパクトが少ない業務であれば特に問題ないのですが、作成時の容易さよりも、ソフトウェアロボットを作成した後、どのように管理、運用していくかは、RPA にとって重要なポイントです。

企業として、IT ガバナンスは必要です。ソフトウェアロボットも例外ではありません。（ここでは「IT ガバナンス」は、財務会計に限定せず業務全般における内部統制のIT に関わる部分を指し、情報セキュリティのガバナンスも含んで説明していきます。）
RPA ツールによって、ロボットを簡単に作れるようになったからといって、今話題の「野良ロボット」のように管理できていないソフトウェアロボットが増えれば、セキュリティリスクは高まり、異常停止により業務に支障が出れば事業継続にも影響しかねません。

RPA は、雑用レベルの単純作業から次のステージのRPA2.0 へ進み、定型業務以外の複雑な業務に対しても広がりつつあります。 RPA が個々の単純なPC 操作の自動化から、重要な業務に対して適用されるようになると、その効果と共に重要性が増し、業務におけるRPA の依存度の割合も高くなります。それ故、その処理が停止した時のインパクトも大きくなります。

RPA ツールによって作られるソフトウェアロボットにも様々な種類がありますが、統制の観点で分ければ、サーバでソフトウェアロボットを集中管理し仮想PC 上でバックグラウンドで処理するタイプと、それぞれのPC 上で人の操作と同じように画面に表示してマウスやキーボード操作を行うタイプに分類されます。

バックグラウンドで処理できるサーバタイプは、マルチで並行処理できるため、高速な業務処理が期待できることと、集中管理が可能なことが利点ですが、PC 操作の処理内容が視覚的に見えないため、動きがブラックボックス化されてしまい、エラー時の対応が専門知識を持つものに依存するというリスクがあります。開発をベンダー任せにしている場合など、即時対応が難しくリカバリーにコストもかかります。

一方、個々のPC でフォアグラウンド処理するソフトウェアロボットは、画面上で自動操作されている動きが見えるので、異常時のエラー箇所が特定し易く、いざという時は、人が代わってオペレーションすれば対応できることが多いという安心感があります。但し、こちらの方式では、現場の業務担当が簡単にソフトウェアロボットが作成できるタイプが多いので、リスクとしては、「野良ロボット」を量産し易いという懸念があります。


但し、開発型のROBOWARE のように、バックグラウンドの処理でも、画面を見ながらのフォアグラウンドの処理でも、適正に合わせて両方の使い分けが可能なツールもあります。しかも、サーバがなくてもPC でジョブのリモート管理ができ、業務に合わせてカバナンスの目的でログ出力を追加するなど、複雑なコーディングもできます。

ソフトウェアロボットを作った人が、そのロボットを管理すれば良いのでは？と思われがちですが、IT ガバナンスの観点からすれば、それがベストであるとは言えません。
RPAツールでソフトウェアロボットの作成を現場の業務担当者が行なった場合、IT 部門と比較して決してシステム技術やセキュリティ対策のノウハウなどの知識が高いわけではないので、作ったソフトウェアロボットがセキュリティホールになる可能性さえあります。そのため、パスワードなどは、ロボットに入力させない方がよいという意見もあるくらいですが、いちいち担当者がパスワードを入力しているのでは、中途半端な自動化になってしまい、意味がありません。

では、開発を委託したIT ベンダーにセキュリティ面も含めてトータルな管理を任せられるかというと、コスト的にもかなり高額になり、業務の機密に関わる部分の漏洩リスクと、エラー時の対応が遅くなるという心配があります。更に社内にノウハウが残らないため、外部の会社に業務を握られてしまうという経営リスクにもなります。

それでは、RPA の専門チームを作成して管理運営を行なえばどうでしょうか？
ソフトウェアロボット開発の段階から、RPA ツールの使用方法を学び、作成したロボットを会社全体で統括して運用できるようにするわけです。この体制は、理想的ですが、システム部門は現場の業務に精通していないため、業務部門と、システム部門両方からメンバーを選出し構成することになります。大きな会社組織であれば可能かもしれませんが、自動化のために人をアサインするにはかなりコスト面の負担を覚悟しなければならなくなります。

但し、今後ロボットは加速して増えていくので、将来全社的にソフトウェアロボットに業務を任せる場合には、このRPA 専任チームが、ロボットに業務を代替してもらった人達が所属すべき職種となるかもしれません。このように、ロボットが仕事を奪うというよりは、ロボットを利用して仕事が高度化していくのです。

ソフトウェアロボットにおいて、理想的な管理はどのような方法で行なうのでしょうか？
RPA 専任チームもよいのですが、そのために人的コストをかけたのでは、自動化によってかなりコスト削減ができる仕組みが必要であり、スモールスタートから始める早期段階では、メリットどころかRPA によって経費が増大してしまいます。

そこで現実的なのが、ソフトウェアロボットを人として管理する方法です。
ソフトウェアロボットは、そのそも人の作業の代行をします。多くの企業や組織では、すでに所属する人に対して、ガバナンスの体制が出来上がっています。デジタル労働者であるソフトウェアロボットも同様に、人と同じようにID、パスワードを持ち管理するのです。

たとえば、営業部で働くソフトウェアロボットは、その業務を行う人のPC と同じWindowsID でログオンさせれば、営業部で認められた権限範囲で作業を行なえます。つまり、経理部など他部署の業務を動かしたり、そのファイルサーバのデータを読み書きすることはできません。
いずれにせよ、自動化したい業務を稼働していたPC でソフトウェアロボットを動かし、そのロボットは、そのPC で行なっていた人の持っていた権限以上の権限を与えなければ、その業務担当者に任せることができます。任された担当者も、もし、ソフトウェアロボットが他部署のファイルを暴走して壊すことができる権限を持っていたら、絶対そのロボットに責任を持ちたくないでしょう。

業務の処理内容に関しては、その業務を行う部門でハンドリングできますが、ソフトウェアロボットはソフトウェアであるため、システム部門の関与も必要になります。
IT ガバナンスはシステム部門が重要な役割を担い、すでに確立されている企業が多いでしょう。
ソフトウェアロボットはそこに組み込む管理対象のソフトウェアとして、当然ながらセキュリティや品質管理が求められますが、それに加えてファイルサーバに対するアクセス権限など、システムを守るために、人と同じ扱いで管理対象に組み入れるべきです。

業務部門だけでは解決しない障害が起これば、システム部門の介入を要請するわけですが、これは他の重要アプリケーションと同様に、システムのヘルプ担当に社内標準ツールとして、サポート対象に組み込んでもらう必要があります。RPA ツールが、様々なアプリケーションに連携するため、システム部門で管理しているOS などのバージョンアップや、パッチ情報の管理と同様に、使用したRPA ツールのバージョン管理も加え、影響があれば予防保守など事前に対処する仕組みが必要です。
システム部門がどこまでソフトウェアロボットの使用に関する権限を与えるかについては、ソフトウェアロボットを擬人化して考えれば、現状のIT ガバナンスの中で、各業務部門に対してシステムが持っている権限を参考に設定すればよいのです。
そう考えれば、ソフトウェアロボット用に新たに障害時のフローを作成するというよりは、現状の障害時の対策フローを基準にソフトウェアロボット特有の部分を考慮するようにアレンジして追加修正をする方が、IT ガバナンスのためにも比較的スムーズに適用できます。

RPA は、スモールスタートで段階的に、計画的に導入する方がよいと言われています。
産業用ロボットを工場に一斉導入する場合と同じように、数百台のソフトウェアロボットを導入して集中管理で業務を一挙に自動化する方法もありますが、それでは、障害時の対応がかなり大きなリスクとなります。

まずは業務担当者のPC にソフトウェアロボットを導入し、段階を経て業務を引き継ぐ方法が現実的です。いきなりバックグラウンドでの処理を行なってしまうと、正常に終了したと思っても、途中の過程の処理が間違っていないかどうかのチェックが難しくなります。そのため、ロボットによる自動化の操作も担当者と同じPC の画面に動きを表示させて、それぞれのステッ プが正常稼働しているかを確認し、実績が出てからバックグラウンドへ移行します。

業務担当者には、それぞれの担当者が所属する部署のアクセス権限があり、たとえば営業事務の人が、経理の業務データにアクセスできてはいけません。ソフトウェアロボットについても、Active Directory 等でファイルのアクセス管理をすべきなのは当然ですが、そもそも営業部から、経理部のソフトウェアロボットで実行指示ができてしまうと、セキュリティ上の脅威となりま す。RPA ツールによっては、ソフトウェアロボット同士の通信機能やリモート制御の機能がないものもありますが、リモート通信ができても、セキュリティ基準が違う他部署への実行指示が出来るようなソフトウェアロボット運用は絶対行なってはいけません。
この点について、例えばROBOWARE の場合、ソフトウェアロボットをリモートで動かすためには、相手先のPC のROBOWARE のロボットID を知っている必要があります。このロボットID は、厳格に管理され、第三者にコピーされないようにするためにパスコードによってレジストリに登録し、配布したロボットID のファイルは削除できます。レジストリに登録されたロボットID の情報は、コピーされても他のWindows OS では動きません。

通常のアプリケーション管理に加え、このようにソフトウェアロボットのリモート操作に対するセキュリティ対策は、RPA を導入する上でとても重要になります。
ROBOWARE のような開発型のツールであれば、ソフトウェアロボット開発時のコーディングに様々なセキュリティ対策の処理を組み込むことができますが、サーバ集中管理を行うRPA ツールの場合は、管理者が特権を持ってしまうため、そのRPA ツールが企業の業務分掌 におけるセキュリティポリシーの基準を満たせるかどうか事前に確認することが重要です。

RPA では、いろいろなアプリケーションを連携することが多いため、そのアプリを自動起動するためには、アプリ毎にID、パスワードが必要となります。そもそも、Windows OS でさえ、それを設定しなければ立ち上がりません。しかしながら、RPA ツールの自動入力の設定にID、パスワードを登録しておくとセキュリティ上とても危険だということが指摘されています。

たとえば、記録型RPA ツールは、手順としては画面上での操作をそのまま登録するため、IDやパスワードはテキストのまま記録されてしまいます。これでは、あまりに危険なため、少なくともパスワードは、セキュアなアクセス制御された場所にある暗号化されたファイルから、実行時にその都度入手する方法などへ変更しなければなりません。
これに対応するためには、企業の環境によりパスワード管理が汎用的ではないので別途スクリプト等でプログラミングしなければならない場合が多く、記録型RPA ツールの中にはパスワード入力の部分は自動化を推奨していない場合もあったりします。セキュアなパスワード設定の自動化ができないようなRPA ツールを選択するのは、人手の介入が必要となり中途半端な自動化でしかないため注意が必要となります。

その点、ROBOWARE のように開発型RPA ツールであれば、企業環境にあったコーディングが可能であるため、様々なアプリケーションを連携するような複雑な業務でも、ID やパスワードの情報をセキュアな環境から入手するような作り込みが行なえます。
これに付随して、たとえばリモートからの実行指示については、新たなパスコードのチェックを加えるなど、業務の重要度や、企業のセキュリティポリシーに合わせて、ソフトウェアロボット開発の段階でリスク対応計画に即したセキュリティ対策を組み込むことができます。

リスクマネジメントに必要なのは、想定されるすべてのリスクを洗い出し、それに対しリスク対応計画を作成し、リスク発生に備えます。同様に、ソフトウェアロボット開発においても、自動化する業務で想定できるすべてのエラーケースを洗い出し、それが起こった時の対処を事前に設定しておくべきです。ソフトウェアであるソフトウェアロボットは、業務エラー、システムエラー両方に対し、原因がわからず異常終了しないように、可能な限り業務継続できるよう、通常のアプリケーション開発で行なっているのと同等以上の配慮が必要です。

RPA では、たとえばマウスクリックの対象にしていた画面について、アプリ側の都合で突然アイコンやバナーが変更された時などはたとえ人間であれば認知して対応できるような場合でも、ソフトウェアロボットは停止してしまいます。また、想定外のデータが入力されたときや、ファイルが見つからない場合もエラーになることが多く、対応が必要です。

RPA を導入しても、当然ながら事業継続マネジメントを考慮したソフトウェアロボットの運用が必要です。
ソフトウェアロボット自身が、他のロボットで代替がきくように、バックアップ／リカバリーができる仕組みはもちろんですが、障害時のフェイルオーバー等の仕組みも必要です。

多くのRPA ツールは、障害時、災害時など不測の事態に対して標準で対策できる仕組みが弱いため、導入前に確認することが重要です。
サーバ集中管理型は、その中央管理のサーバに問題が発生すると業務に対するインパクトが大きいため、通常は管理サーバ用のハードウェアを2 台以上複数使用し、クラスタリングして冗長化するなどの対策が必要になります。
PC 側でも障害は発生するかもしれません。ロボットA のPC がダウンしてしまった場合、ロボットB で作業をさせたいのに、ロボットB のPC に電源が入っていなかったため切り替えれなかったということでは意味がありません。
そういった対策として、ROBOWARE であれば、ソフトウェアロボット同士のバックアップができるため、サーバがなくても、PC レベルでもリカバリが可能です。また、バックアップ機のPC の電源が入っていなくても、ネットワーク越しで通信するので、Wake-on-LAN 機能を使用できる環境であれば、マジックパケットを送信して、リモートでWindows を立ち上げ、ソフトウェアロボットを動かすことができます。
さらに、人が介入するウォームスタンバイに加え、フェイルオーバー機能として災害時に自動切換えを行なうホットスタンバイも設定できます。

ソフトウェアロボットもソフトウェアですので、バージョンアップを伴います。RPA の目的である業務自動化においては、様々なアプリケーションが関連するので、そのアプリのバージョンアップにも対応が必要な場合があります。
Web ブラウザのバージョンアップや、Windows OS のバージョンアップなどについては、ソフトウェアロボットを止めないためにも、事前検証できるテスト用のPC があると安心ですが、最近ではセキュリティ対策として自動更新してしまうアプリケーションも多いため、そういったケースに即時対応できる環境が必要です。

GUI でスピィーディに作成できることも大切ですが、作成したソフトウェアロボットを修正し易いことも重要です。また、内容によっては、RPA ツール自身のバージョンアップを待たないと対応できない場合も想定されます。その点、海外製品であると日本語環境でのエンハンスのプライオリティが低くなってしまう恐れがあり、国産のツールの方が安心だと言われています。

ソフトウェアロボットの開発に使用している言語にも注意を払わなければいけません。多くのRPA ツールは、ノンコーディングで開発できることを特長としておりますが、複雑な分岐や特殊な処理は、スクリプト言語を使用しているものがほとんどです。ROBOWARE のように、Ruby やPHP など複数の汎用スクリプト言語を選択できるのであれば、影響は少ないのですが、通常はそのRPA ツールで特定しているスクリプトを使用します。
たとえば、古くから実績のあるRPA ツールで多く使用されているMicrosoft 社のVBScript の場合、脆弱性が懸念されており、Microsoft Edge ブラウザには対応しない方針で、Internet Explorer 11 でさえVBScript の利用は推奨されておらず、標準のドキュメントモードである“IE=11” モードでは動作しない状況です。
こうしたスクリプト言語に頼っている場合、自社のPC 環境を維持するシステム部門にも、脆弱性対策のためのバージョン追従方針等に影響がでます。

RPA ツールは、比較的簡単に定型業務の自動化ができることで普及したため、業務担当者による開発の試みが多くの企業で行なわれました。
しかしながら、プログラミング知識が無くては複雑なエラー処理に対処できず困る上に、安易に現場でロボットを量産すると、「野良ロボット」が生まれてしまう問題もありました。

IT の統制を考慮した場合、業務担当の個人レベルでのソフトウェアロボット作成は控えた方が良いでしょう。各部門で、組織に基づいた権限をソフトウェアロボットにも与え、社員同様コンプライアンスなども配慮してロボットの作成が必要です。ソフトウェアロボットはソフトウェアですから、セキュリティポリシーに従い管理できるようにソフトウェアロボットを作成します。たとえば、各タスクの重要なポイントでは、業務処理のログを別途出力し、システムのエラーも収集して、ログ管理システムに繋げる仕組みも必要でしょう。
そうなれば、システム部門からの支援も必要です。企業規模によっては、ソフトウェアロボットの開発をする人と運用の担当は分けて進める場合もありますが、多くのRPA ツールはサーバ集中管理型なので、システムに精通した人がRPA 専任でソフトウェアロボットの開発をすることが期待されます。
結果、システムに精通してIT ガバナンスをよく理解している人が、業務担当者と連携して作成する形が現実的であると言えます。業務担当が一番業務のオペレーションを分かっているのですが、業務フローやマニュアルがしっかり作成されている場合は、それを元に業務担当とは別の人がソフトウェアロボットを開発することも可能です。

たとえば、ROBOWARE であれば、オプションのQuickROBO が操作記録型で自動化できるので、業務操作部分のみ現場で作成して、エラー処理やセキュリティ対策、アプリ連携などはシステム側で開発するという連携が可能です。

それでは、誰がソフトウェアロボットに責任を持つべきでしょうか？
業務をロボットに代行してもらうのですから、業務によってはアウトプットされたデータ等を確認する作業があるはずです。通常は、その確認を行なっていた今までの担当者が、ソフトウェアロボットを監督し、その業務担当部門が業務遂行について責任を持つべきです。

一方、ソフトウェアであるソフトウェアロボットには、バージョンアップや、障害対応などシステムの一部として管理すべき内容があります。業務寄りの部分は、業務部門に管理を任せ、ソフトウェアの維持という点では、システムの運用部門が、適宜開発部門の協力を得ながら全社的に管理した方が効率が望ましいです。

今後、企業にとってソフトウェアロボットの開発は日を追うごとに加速し、ますます過熱気味に拡大していくことでしょう。RPA による業務自動化対応に遅れをとっては、他社に先を越され、企業にとって存亡の危機となりかねません。
初期段階からIT ガバナンスを意識してRPA を導入した会社と、そうでない会社は、RPA 適用範囲が増えれば増えるほどその差は歴然となることでしょう。IT の統制がとれていない会社は、ソフトウェアロボット量産によって事業継続におけるリスクがとてつもなく増大することになります。

アニメ映画のようにロボットが暴走してしまうというようなことは考え難いですが、悪意を持った第三者にリモートで制御され、予期しない動きや、あるいは知らない間に機密情報を流出してしまったりということも考えられます。
現実的に起こりそうなのは、順調に自動化が進みソフトウェアロボットにより人員削減され、業務担当の大部分が会社からいなくなった後、忘れたころにソフトウェアロボットが異常停止してしまう場合です。こうした状況は、大規模な業務改革とコスト削減を狙い、RPA ベンダーや、 コンサルティングファーム等の提案をトップダウンでそのまま採用してしまった場合に想定でき、社内人員だけではリカバリできない場合は最悪な事態となるでしょう。
巷ではロボットやAI が仕事を奪うことが心配されていますが、正確にはロボットが仕事を奪うのではなく、ロボットをコントロールする人間が仕事を奪うのです。そのことを理解し、外部からの提案にすべてを依存するのではなく、ソフトウェアロボットに関するリテラシーを高め、そして社内にノウハウを溜め、ソフトウェアロボットを開発していくことが重要です。