一方で、RPAの導入効果を感じられずに、多大な工数をかけて製品を見直す必要が出てくる企業もあるようだ。白土氏は、導入プロジェクトの各フェーズに「失敗につながる要因」があるとして、計画・検証フェーズ、部分導入フェーズ、全社導入フェーズで発生する課題を説明した。

　計画・検証フェーズにおいては、自動化の定義があいまいで業務候補が見つからない、初期費用をかけたくないが故に価格の安い製品に目を向けがち、個人業務の効率化にフォーカスしすぎて全社にスケールするための計画が立たず、導入効果が想定できないなどの課題が生じる。

　これらの課題は部分導入フェーズにおいて新たな課題を引き起こす。例えば、価格重視で入れた製品が自社の要件にマッチせず、開発やロボットのメンテナンスに工数がかかる、安価な故に管理機能が弱い製品を使用することで野良ロボットが発生する、個人の業務にフォーカスしすぎた結果ロボットやノウハウが俗人化する、RPA推進部門の人材が不足して体制やルール整備ができないといった状態に陥るという。

　全社展開フェーズにおいても、さまざまな問題が起こる。ロボットが個別最適になって既存運用からスケールできないといった課題の他、RPAの機能的な制限からガバナンスの確保や、多様な業務の自動化、AI-OCRなどとの連携が難しくなるといった問題が出てくるケースがあるという。

　「多くのコストと手間をかけてRPAを導入、運用したものの、手戻りが発生してしまうケースが少なからず存在します。中には、製品や運用の見直しの再構築をする企業もあります」（白土氏）

　導入プロジェクトの道半ばで手戻りが発生しないためには、導入初期からRPAの目的を明確化して、適切な実行計画を立て、それに見合った製品を選択することが重要だと白土氏は強調した。

　実際に同氏がRPA製品のリプレースと運用の構築を支援したユーザー企業の事例がある。その企業では、RPAを導入後、2年間で約100体のロボットを作成して、15の部署に展開していた。ある程度の効果を感じていたものの、さらなるスケールを意識した際に課題が噴出したという。

　同社においては、国内デスクトップ型を筆頭に幾つかの製品が乱立していた。デスクトップ型RPAなので基本的にロボットを一元的に管理する機能は備わっておらず、ロボットの管理は現場任せだったという。各部署で独自にプロジェクトが進んでいたために、部品の共有や情報交換ができておらず、スピーディーにスケールできない状況だった。

　運用やメンテナンスの工数がかかりすぎているという問題もあった。同社はロボット開発の7割を複数の外注先に依頼していたため、ロボットの品質がバラバラでエラーが起きやすく、エラーが起きた際も時間をかけて「どのような意図でロボットが作られているのか」といった解析をする必要があった。ロボット開発を外注任せにしていたことで、社内でナレッジが蓄積されないという問題もあった。

　こうした課題を受けて、同社はRPA全社展開のためには、管理統制の厳格化や開発・運用効率のアップ、RPAの内製化が必要だと痛感し、そのためにRPA製品の見直しと開発、運用体制の見直しに着手した。

リプレースで重視したポイント

　同社では、稼働中のRPAを一つずつ解析して、全てのロボットをAutomation Anywhereの「Automation 360」（A360）に置き換えた。導入前PoCで従来のRPA製品を使って外注先のSIerが作成したロボットと、A360で日立システムズのSEが作成したロボットを比較した際に、納期やロボットのアクション数を大幅に削減できたことが選定のポイントだった。

　リプレースを支援した白土氏は、当初の苦労について次のように語る。

　「同社においてはロボットを一元管理していなかったために、お客さまの本社や支社の担当者の方にヒアリングしながら『どこにどのようなロボットがあるのか』を棚卸しする必要がありました。複数のSIerに開発を依頼していたために実装もバラバラだったので、フローを構成するアクションを解析しながら、A360に置き換えました。驚いたのは、既存ロボットの多くが、標準機能でまかなえない機能をスクリプトで実現していたことです。A360ではこのスクリプトで実装していた機能を、標準機能を使って再現しました」

　白土氏は、幾つかのポイントを考慮してリプレースを進めたという。まずは、フローの視認性を高めることを重視した。

　既存のデスクトップ型RPAは、全工程に3時間ほどかかる重厚長大なロボットのアクションをフローチャート式で積み重ねるものだった。そのため、ビジュアルが重くて表示が遅く、ロボットの実装が把握しづらいという難点があったという。

　「リプレースに伴って、アクションの積み重ねをフローチャートではなく、リスト型で表示するようになりました。一画面で表示される情報が多いので可読性が高くなりました。その他、プロパティの設定もワンクリックで見られるようになったことが、開発を効率化する上で効きました」（白土氏）

　ロボットがデスクトップPC画面の要素を認識する際の方式にも考慮した。人間の動作をレコーディングして自動化のフローを作成した場合に、ロボットがデスクトップPC画面の要素を認識する方法は、主にHTML構文解析方式とオブジェクトID方式、画像認識方式、座標キーストローク方式の4つに分けられる。

　HTML構文解析方式とオブジェクトID方式は認識できるシステムが限られるものの安定性が高く、画像認識方式と座標キーストローク方式はさまざまなシステムの画面を認識できる一方で安定性が低い。そのため、まずは前者の2つの方式を試してみて、対象システムの画面を認識できない場合に後者の方式を選択するという流れが望ましい。

　だが白土氏が稼働中のロボットを確認したところ、実際にはかなりのフローが座標キーストローク方式と画像認識方式で実装されていた。

　「キーストローク方式は、画面のある入力項目にカーソルを当てる際に、TABキーを数回推すことで目的の場所まで移動するという方法をとりますが、入力欄が増えるとロボットが入力ミスを起こすなどのトラブルが起きます。画像認識方式を使った場合も、特定のボタンを見付ける際に別の類似ボタンと混同したり、画面構成が変わるたびにメンテナンスが必要になったりするという問題が発生します」（白土氏）

　A360へのリプレース後は、安定性の高いHTML方式やオブジェクト方式を使って安定性のあるロボットを構築できた。

　その他、自動化フローのセキュリティを確保することも重要だったという。業務を自動化する中では、ロボットが基幹システムなどにログインする処理が発生する。その際に、IDとPWをどのように扱うのかが安全性を左右することになる。

　「お客さまによっては、ログイン情報を記述したドキュメントに書いたログイン情報をロボットにコピーさせるという処理をしているケースがありますが、ドキュメントが漏えいする可能性もあり安全性が高い方法とは言えません。また、ロボットの自動化フローに平文でログイン情報を書いている場合もありますが、これもセキュリティ上のリスクが大きいと言えます」（白土氏）

　リプレース後は、A360の「クレデンシャルボルト」という機能を使って、IDやPWをロボット管理サーバ内に格納し、暗号化された状態でロボットに渡すことでログインを実行する方法を採用した。これによって、開発者や実行者にもログイン情報を知られることなく、自動化の処理を進められるようになった。

　上記のことを意識しながら運用中のロボットを全て移行したことで、ガバナンスの向上や、開発・運用効率のアップを実現できたという。

白土氏は、リプレースを進める中で「既存RPA製品の違いとA360の違いが見えてきた」として、上記のポイントを意識してRPA製品を選定することを推奨した。