2021年9月13日、RPA BANK はキーマンズネットに移管いたしました。
移管に関する FAQ やお問い合わせは RPA BANKをご利用いただいていた方へのお知らせ をご覧ください。
「幻滅期」。米国に本拠地を置く業界最大規模のICTアドバイザリ企業「ガートナー社」が特定の技術について曲線(「ハイプ・サイクル」)を使いながら、関心が高まり、やがて失望を経て、そして安定するまでを説明する際、失望を示す期間に造り出した用語である。知っている、聞いたことがあるという方も多いのではないだろうか。
2019年に入ってからも国内ではRPAを導入する企業が増え続けている最中、ガートナー社はRPAについてもこの「幻滅期」に突入していることを示している。
実際、「思ったような費用対効果が出ない」「繁忙期なのにロボットが停止した」といった課題を抱く声も聞かれるようになってきた。人手不足に伴い拠り所としてのロボットへの期待は高いだけに、成果が得られないことへの失望や懸念が起きていることも事実ではないだろうか。
こうした課題はなぜ起き、どのようにすれば回避できるのか。本記事では、50社以上のRPA導入運用支援プロジェクトにパートナーとして携わり、途中から助けを求められて参画することも少なくないというTIS株式会社の経験をもとに解決策を探りたい。同社サービス事業統括本部 経営管理サービスユニット アプリケーションテクノロジー部 主査 橘木直也氏と梅木康信氏の2名に話を聞いた。
―RPAの導入企業が増えるいっぽうで、課題を抱く声も聞こえるようになってきました。TIS社では数多くのRPA導入支援をしてきたとのことですが、プロジェクトにはどのようなスタンスで臨まれているのでしょうか。
梅木: まずは、パートナーとして目指すべきビジョンを明確に持つことです。私たち自身がRPA導入を通じて企業に何をもたらすのか定義しておくことが、成功裏にプロジェクトを進めるために欠かせないと考えています。
TISでは、パートナーとして目指すビジョンを「真のDigital Workforce」の実現と定義し、「人とコンピュータの接点」を最適化し、DX(デジタルトランスフォーメーション)を通じた「生産性の劇的な向上/革新」「新しい顧客体験」「従業員満足」を実現するためにRPA導入を支援しています。いきなり最終形に到達するものではなく、RPA導入企業のニーズに合わせて段階的に進めていき、ゴールである「真のDigital Workforce」の実現を目指すものだと定義しています。
―どのような段階を経て「真のDigital Workforce」に向かうのでしょうか。
梅木: 多くのプロジェクトに携わった経験をもとに、大きく3ステップに定義しました。
これらのステップが進むにつれて、RPAの知見だけでは解決できないものになっていきます。RPAで何を実現するのか、どのような段階で進めるのかを考えるうえで参考にしていただければと思います。
―思ったような成果につながらないなど、RPA導入後の問題を耳にすることも少なくありません。TISには問題を抱えてから声がかかるケースもあると思いますが、どのような例がありますか。
梅木: これまでに50社以上のパートナーとしてRPAの導入に携わってきた経験から、問題は6つに分類できます。具体的な例を交えてご紹介しましょう。
梅木: 本来は業務全体を整理して、費用対効果が高い部分からロボット化を進めるべきです。しかし、現場の個別判断に任せてRPA導入を行う場合、目の前で困っている業務からロボット化してしまいます。担当者は楽になるかもしれませんが、それは必ずしもロボット化に適した業務とは限らず、手で行うべき作業である可能性もあります。会社全体で見れば、統制やセキュリティなどのコストを含めて考えると、トータルの費用対効果が見合わないという判断になります。
橘木: 自分たちの業務を客観的に見るのは案外難しいことで、シンプルだと思っている業務もロボットにしてみれば複雑だったというケースもあります。
たとえば、経理で行うERPへの登録業務をロボット化したいという依頼を受けたことがありました。詳しく業務を分析してみると、一つひとつの作業はシンプルであるものの、パターンが何十種類もありました。すべてのパターンに合わせてロボット化するのは、作成だけでなくメンテナンスも大変。費用対効果が出ないと判断し、この業務へのRPA導入は中止すべきと提案したこともあります。
―こうした状況を回避するには、どうすればいいでしょうか。
橘木: 費用対効果の面では、全社で共通の作業から始めること。それから、繰り返しが多いというのが判断ポイントです。
とはいえ、ロボット化の対象候補は現場からボトムアップで吸い上げたほうがよいでしょう。よくRPA導入のきっかけとなるビジネスプロセスの見直しは、トップダウンで行われるものですが、簡単そうに見えて実は手間がかかっているという実態は、担当者でないと分からないためです。
梅木: 推進体制としては、まずは一つの部門で成果を出して、社内的にRPAのプロモーションをしながら進めることを提案しています。
そのうえで組織としては、ロボットの得手不得手を知っている担当者が会社全体に点在するような体制が望ましいですね。ロボット化に向いていないという判断とは逆に、ロボット化できないと思い込んでいる場合もあります。現場の担当者がRPAを理解しているかどうかが成功を左右します。
橘木: このとき、期待値をコントロールすることが大事です。全部ロボットに任せられる、あるいは任せるものという誤解も生じやすいので、設計段階で切り分けておくことが費用対効果にも影響します。
梅木: RPAの導入が始まった初期の頃から、野良ロボによる「誤実行が起きやすくなるリスク」や「同じようなロボットを量産してしまう」問題が指摘されていました。今ほど導入が進む前は、コンサルティングを行うパートナーを付けてプロジェクトを進めることが多かったため、対策を採る企業が多く、あまり問題にはなっていませんでした。ところが現在では、とにかく自分たちだけでもRPAを入れてみよう、という規模での導入も出てきたことで、配慮が不十分なまま運用を始めてしまい、野良ロボットが発生しやすくなってきています。
―なぜ、誤実行が発生しやすくなるのでしょうか。
橘木: 業務部門で開発を進める場合に、どのような経緯や思想で開発したかまで説明することなく横の人がコピーするからです。
たとえば経理担当者が作り始めると、業務の特性もあってかエラー対応も含めてよく考慮したロボットができあがります。それが社長の目に留まり、「総務もロボット化するように」と指示されて、経理のロボットをコピーして手を加えるとします。
すると、動作の前提条件や背景までは理解することができず、さらにリテラシーのない担当者ではパスワードの文字列を直接ロボットに記述してしまうような事態も発生します。これでは誤動作が発生しやすいロボットになってしまいますよね。
梅木: こうした劣化コピーを防ぐために、2部署以上でRPAを導入する場合にはロボットの情報把握だけでも最低限行うようにします。
全社レベルでロボットを管理する担当者を置き、企画段階で受付をする、内部統制の問題をチェックするといった管理を行うべきでしょう。企画部門と情報システム部が協力して担っている企業が多いです。各部門に「RPA大臣」を置いて、大臣の承認がないとリリースできないという取り組みしている企業もあります。
橘木: ロボットが本格的に活用されるようになると、人の手で管理するのでは非効率ですし、正しく稼働しているか、業務だけでなく監査上の問題で把握しておく必要が出てきます。そのため当社では、管理サーバーを入れてスケジュール、セキュリティの管理、稼働状況の把握などを行うことを推奨しています。
TISではロボットの制御や監視を行うためのさまざまなサーバー製品を取り扱えますが、その一つであるUiPath Orchestratorにおいては導入実績を高く評価され「UiPath Partner Awards」でパートナーアワードを受賞しました。この知見をさらに高めて、ロボット管理に関するサービスを充実させていきたいです。
梅木: ロボットを目の前で補助的に活用し、エラー発生時にはすぐ対応できるのであれば、さほど問題にならないこともあります。しかし、朝出社したら処理が終わっている状態を目指すのであれば、エラーのリトライも含めてシステマチックに対処できるロボットを開発する必要があり、それにはシステム構築の知見が求められます。
加えて、システムのように1回テストを実行したらOKとはいかないのがRPAで、10回中9回成功といった品質基準を決めておき、1回の失敗をどうリカバリーするか考える必要があります。RPA開発者はシステム化とRPA両方の知見を求められます。運用を行う情報システム部もRPAの知見が新たに必要です。
橘木: あまり業務に詳しくない派遣社員が開発したところ、ロボットの動作が不十分だったという話も聞きます。本場運用を見据えた開発が必要なのです。なかには他のベンダーが開発したロボットが不安定だという相談を受けて、見てみるとプログラムが非常に雑だったケースもありました。それをRPAの限界だと誤って認識してしまう可能性もあります。
梅木: RPAを使えるだけの人が、現行業務の手順書を受け取ってそのままロボット化するようなやり方では、RPA本来の価値が出ません。RPAの導入効果を最大化するには、業務改善から取り組む必要があります。たとえば、ロボットが効率よく動くように準備するための業務プロセスを加えるといった工夫が求められるのです。
梅木: RPAの真価を問われるのは、繁忙期です。そして、そういうシーズンには業務システムにも負荷がかかりやすくなります。システムのレスポンスが悪くてもエラーを回避できるロボットを開発したつもりでも、その予想を超える場合があるのです。そこまで見越した作りにしておくことが大切です。
橘木: エラーが起きづらいのはもちろん、エラー発生時にロボットを再び動かしてリカバリーできるようにしておきます。またゼロからやり直しではなく、途中から再実行できるような手順を考えておく必要も出てきます。ロボットをあてにして人を減らしているような場合、業務が回らなくなってしまう恐れもありますから、とても重要なことです。
梅木: 多くの企業では、導入トレーニングを受講しています。しかし、それだけでは勘所がつかめないためうまくいかず、トライアンドエラーでは導入に時間がかかってしまうという問題があります。また、最初だけ専門家にロボット作りを依頼して、その後は内製化しようとしても、勘所が伝わっていないと難しいのが実情です。
―TISでもロボットの内製化を推奨していますが、ここまで話をうかがった限り、必要な部分については外部のサービスを取り入れることも有用ですね。
梅木: RPAの導入自体は簡単ですが、一方で費用対効果の出る価値ある取り組みにするには内製化し、そこにはご説明したような問題が発生する恐れがあります。TISでは、基本トレーニングから管理統制基盤まで幅広く9つのサービスメニューを用意して、すべての問題に対応できるようにしています。
高品質なロボットを作るには、「(3)低品質/運用難」でお伝えしたように知見が求められます。ロボットの手本を作り、それをよく読み解くことで思想を引き継ぎ、社内に知見を持った人を増やしていきます。そうすることで、内製化による導入効果を最大化することができるのです。最初だけ開発を依頼して、後はそれを手本に自社で内製化を進めても構わないわけです。
ただし「(6)内製化が進まない」で紹介したように、勘所も引き継がれないと失敗します。TISから引き継ぐ場合、プログラムの背景や特殊なロジックが必要になった理由などを含む内容になっています。
橘木: 内製化がうまく機能しているか不安という場合もあるでしょうから、RPAアーキテクトが不定期にレビューを実施して、改善点を指摘する体制を取ることも可能です。
また、内製化でどうしても解決できない問題が発生することもあります。ロボットの動作環境は、それぞれの企業の環境に強く影響を受けるものです。例えば、Webシステムで使用しているブラウザ固有の動きが特殊で、イベントを捉えるのが難しいようなケースがあります。特定のERPやウイルス対策ソフトがトラブルになりやすいことも分かっています。TISは多数のプロジェクトで経験があるため、ナレッジを共有してベストプラクティスを迅速に適用できるのです。こうした箇所が発生してからサポートを依頼されることもありますね。
―これからRPAの開発を始める場合は、どのような進め方を推奨しますか。
橘木: 開発すべてを当社などの外部に任せても構いませんが、内製化するのであれば、当社には「ロボット開発サービス」があります。このサービスをメインに、TISがオンサイトで2つ程度のロボットを作り、それと並行して「オンサイト支援サービス」で情報システム部が作っていくことという方法もあります。これであれば、ロボット開発を外部から実際に業務を行う部門へと、徐々に開発の主体を移していけます。半年程度で、気づいたらプロが育っていったという状況が作れると思います。
RPAは自分たちでロボットを作れるのが醍醐味(だいごみ)の一つです。取り組みの段階に合わせてオンサイトとオフサイトのサービスを使い分け、内製化を進めてほしいですね。
―ありがとうございました。
Copyright © ITmedia, Inc. All Rights Reserved.
製品カタログや技術資料、導入事例など、IT導入の課題解決に役立つ資料を簡単に入手できます。