RPA開発のポイント ―RPAを一人で始めて会社を巻き込む

※本コラムは過去公開コンテンツの「RPAを一人で始めて、会社を巻き込むコツ」記事をリライトしたものです。

はじめに

RPA（Robotic Process Automation）がブームになって久しいが、まだ未導入で検討中、または製品選定中の企業もいるだろう。RPAは自動化による改善をこれまでにないほど身近なものにしたが、本稿では、RPAの導入を行う企業の担当者に向けて、当社がRPA導入支援サービスを提供する中でわかったRPA導入の勘所について紹介する。

RPAの概要や一般的な効果については、ネットや本で言及されているため、あえて割愛させていただいた。ここでは導入時に発生しやすい課題に対して、概念的な話ではなく、対応策と考え方について具体的に書くことを目的としている。

RPAは会社で取り組む

具体的な推進方法について記述する前に、まずはRPA推進のベースとなる考え方と本質について触れておきたい。筆者は、RPAは会社として取り組むべきだし、取り組む価値があると考えている。
その第一の理由だが、RPAベンダーはよく「RPAの開発は簡単」と説明するが、これは「（とりあえず作るのは）簡単」なのであって、何も考えなくて良いというわけではない。RPAを本気で導入しようと思ったら考えなければならないことは無数に存在する。

RPAはパソコンにインストールされ、現場のユーザーでも使うことができ、なおかつ開発が簡単と言われているので、その本質に反して軽く見られてしまう傾向がある。ではその本質はと言うと、RPAは従来のソフトウェアのように人が使うツールとして導入するものではなく、あくまで人間の業務を代行する新しい労働力としてとらえるのが正しい。

つまり、RPAは、「IT」「人」に次ぐ、「第三の経営資源」である。人材管理に人事部、ITに情報システム部門が存在するように、ITでも人でもないRPA（ロボット）には、RPA推進体制が必要になる。また、業務をRPAに代行させた後、人に何をやってもらうか、会社の経営方針とリンクした人材戦略を検討する必要も出てくるだろう。RPAの本質は、部や課の枠を超えている。よって会社として取り組むべきである。

第二に、RPAの推進には、現場発信のボトムアップ型と、社長からRPA推進の指示が下るトップダウン型が存在するが、結論から言うと「最終的にはトップダウンとボトムアップの両方が必要」と考える。その理由を示すために、もし極端にどちらか一方に偏った推進をした場合、どういう問題が出てくるかを考えたい。
まず、完全にボトムアップにした場合、以下の問題が発生する可能性が出てくる。

• 現場が自分たちでできる範囲で業務を自動化するため、現場最適な成果しか得られない
• 現場担当が空いた時間を使って、片手間で自動化する場合、成果が出るまで時間がかかる（RPAは現場にとっては、やらなくても現状維持になるため、本業を優先して後回しになる可能性がある）
• ナレッジの共有や自動化ルールの統制が取れないので運用時に問題が出る

逆に極端なトップダウンで推進した場合に発生する可能性がある問題は以下となる。

• KPIを達成することに囚われすぎると、現場が望まない自動化が行われ、最悪、現場でロボットが使われない、または逆に現場の仕事が増えて、見せかけの成果に終わる

つまり、RPA推進には会社の後ろ盾と、自動化して楽になりたい、もっと重要な仕事に集中したいという現場の想いの2つが必要だと考える。会社としてRPA推進の旗振りを行うことで、RPA導入の方針やゴールを設定しRPA推進体制をバックアップしつつ、現場もRPAの推進に深くかかわり現場の意見や要望を反映しながら推進していくことが、RPA導入効果を最大化する方法だといえる。

以上、2つの理由からここで言いたいのは、最終的には会社を巻き込んで会社として取り組むべきである点であるが、ただ、これを読んでいる読者の方が、RPA導入を考えている現場の一担当者であっても心配はいらない。現場から始めて最終的に会社を動かす方法をステップごとに後述していく。すべてを一人でやる必要は全くない。RPAの本当の価値を理解してもらえれば、いっしょに導入に取り組んでくれる仲間を増やしていくことは可能だ。RPAにはそれだけの魅力がある。

RPAの計画

（1）ゴールを決める

RPAのセミナーやネットの記事、他社事例を見て、RPAの可能性に気づき、自分の会社でも取り組むことを考えたときに、まず初めにやるべきことは「ゴールを決める」ことである。これを決めないユーザーが結構多い。「ゴールを決める」とは言い換えれば、「なぜRPAを導入するのか？」に答えることができる状態になることを指す。一般的に考えられるゴールは以下が挙げられる。

• 誰でもできる定型業務を減らし、もっと生産的な仕事に取り組めるようにするため
• 仕事量を維持したまま、人手不足を緩和する。またはさらに業務を拡大するため
• 残業を減らして早く帰るため
• ヒューマンエラーによるミスを減らすため
• パートナーやバイトが行っている定型業務をロボットに置き換え人件費を減らすため

どれか1つでも複数でもよいがRPA導入のゴールを設定しよう。もしこの段階でトップダウンの指示が出ておらず、担当者レベルやチーム、課単位で導入する段階であれば、いったんその単位でのゴールで構わない。ゴールはこの後、自動化するための業務選定の指針となる。
ゴールが決まれば、自動化対象の範囲が決まり、自動化対象業務もおのずと決まる（業務選定の方法は後述）。逆にゴールがないと、自動化するべき業務を選定するための指針がないので、場当たり的な対応になる。

さらに重要な点として、ゴールがないと自動化による成果が出たのか出ていないのかがわからない。ゴールによって目標の設定方法も、成果の測り方も変わるからだ。ここで設定するゴールはRPA推進におけるすべての指針となる。
「上司に言われたからとりあえずRPAをやる」状況だけは避けてほしい。もし上司の指示でRPAに取り組み始めたのなら上司に質問しよう。「RPA導入の目的は何ですか？」と。

（2）RPA製品の選定

ゴールが設定できたということは、RPAによって解決したい課題が明確になっているということなので、次にそれを解決する製品の情報収集を行う。製品選定の評価軸は「開発の難易度」と「小規模から大規模までスケールアップできるか？」、「RPAの操作記録技術」の3つだと考える。

①「開発の難易度」について

日本のルーティンワークには特色がある。
一般的にRPAが代行できる業務は次のとおりである。

• 定型業務（手順書どおり実施すればだいたい誰でもできる、判断が不要な業務）
• 繰り返し業務（定期または不定期に関わらず何度も発生する業務）
• 時間がかかる業務（月間当たりの総対応時間数が多く手間がかかっている業務）

いわばルーティンワークであるが、ここではもう一歩踏み込んで、日本のルーティンワークの特色を考慮した製品選定が必要であると考える。
現在、日本で残っているルーティンワークはシステム化するには費用対効果が出ないため、数十年にわたり、システムとシステムのはざまの業務を人がしわ寄せを吸収するように対応してきた業務となる。いわばこれまでシステム化されずに残ったラストワンマイルの領域である。よって、日本企業のルーティンワークは、必ずしも単純作業ではなく「複雑」しかし「少量」そして「多様」といえるだろう。

自動化業務候補の洗い出しの段階で、複雑なプロセス、しかし総対応時間はそれほど多くない業務が大量に出てくることを予想しておいたほうが良い。そうなると、ある程度の成果を出すには複数の業務の自動化を行う必要性が出てくる。そうなった場合、開発の難易度が高いものだと、成果が上がるまでに時間と開発費がかかってしまう。そのうち上司あるいは経営層は「まだ始まらないの？」「まだ終わらないの？」と聞いてくるだろう。（RPAは簡単と言われているからなおさらだ）

前述したとおり、RPA製品ベンダーはたいてい「開発は簡単でユーザーフレンドリー」と説明するため、難易度はユーザー自身が使ってみることをお勧めする。その場合、RPAで実際に自動化する人を想定して、実際に使ってみて難易度を測ったほうが良い。製品の中には期間限定で無償評価版をダウンロードできたり、10万円程度で有償評価できたりするものもある。後述の評価軸をもとに2製品程度に絞ったら、製品評価を行うとともに、自動化の実現性を実際に使ってみて確認することをお勧めする。

②「小規模から大規模までスケールアップできるか？」

RPAの導入は小さく始めて、すぐに小さな成果をあげられるものが良い。
「複雑」「少量」「多様」な業務を2つ3つ自動化するところから小さく始められるくらいのコスト感の製品を選ぶべきだ。もし、初期投資が高額だとすると、少量の業務を数十～数百、自動化しないと費用対効果が出ない可能性がある。これもまた、時間とコストがかかってしまう。

小規模からすぐに成果を上げるべきもう1つの理由として、自動化はシステム開発と異なり、作成しても、すぐに修正が必要になることが挙げられる。RPAは通常のシステムと異なり、環境変化の影響を受けやすい。RPAが操作する対象アプリケーションのバージョンアップや仕様変更、画面デザイン変更の影響を受け、修正が必要になる場合がある。自動化して終わりではなく、使い始めてから発生する保守が通常のシステム開発より多くなるのが特徴である。

よって、小さく始めてすぐに成果を上げ、使いながらまた改善することができるようなスモールスタートができるコスト感の製品を選定したほうが良い。
また、前述したとおり、RPAは会社全体で取り組むべきものであるため、最終的なスコープは全社展開を見据えたものになるだろう。大規模導入になった場合でも、RPAの運用管理ができる管理サーバーが用意されていることも製品選定のポイントとなる。

③「RPAの操作記録技術」

RPAはWindows上のアプリケーションを操作して人の代わりに業務を行うことができるが、RPAに業務を覚えさせる技術は一般的に次のようなものが挙げられる。

• オブジェクト認識（アプリケーションのソースを取り込んで操作対象オブジェクトを特定する）
• 画像認識（アプリケーションの画像をキャプチャして操作対象オブジェクトを特定する）
• キーボード操作やマウスのクリック操作を覚える（Tabキーを4回押して、そのあとにEnterキーを押す、など）
• 座標認識（ディスプレイ上の場所で、操作対象箇所を記録する）

主要なRPA製品は前述の操作記録技術をすべて実施することができる。仮に検討中のRPA製品が前述4つのうち、1つでもできないのであれば候補から外すことを検討しても良いだろう。
RPAで自動化をリリースした後の可用性（問題なく動き続けることができる信頼性）の高さは、高い順に「オブジェクト認識 ＞ 画像認識 ＞ キーボード/マウス操作記録 ＞ 座標認識」といえる。

オブジェクト認識はアプリケーションのソースが変わらない限り、オブジェクトを特定することができるが、画像認識はアプリケーションのデザインや解像度が変わると特定できなくなる。座標やキーボード/マウス操作記録はアプリケーションの状態は一切見ることがないため、アプリケーションのディスプレイ上の表示位置や状態が変わっただけで動かない。
よって、自動化する場合のセオリーは、信頼性の高い順にまずオブジェクト認識を試し、認識できない場合は画像、最終手段としてキーボード/マウス操作記録を試す（座標認識はめったに使わない）。よって、RPAの操作記録技術で最も信頼性が高いのはオブジェクト認識*1 である。

*1 この記事は2018年末時点のものであるため、現在の状況についてはお問い合わせください

製品選定で重要な点は、製品ごとにオブジェクト認識（ベンダーにより呼び名が異なる場合がある）でサポートされているアプリケーションの種類の多さに違いがある点である。よって、製品選定に際し、このオブジェクト認識かそれに準ずる操作記録技術があり、なおかつサポートするアプリケーションにどのようなものがあるかを把握しておこう。

操作記録技術がいかに充実しているかは運用後の可用性にかかわる重要なポイントだ。たとえば、画像認識で社外のWEBサイトの操作を自動化した場合、社外サイトのデザインは何の事前アナウンスもなく変更されるため、ある日突然動かなくなる可能性もある。デザイン変更が頻繁だと、リリース後の保守の手間がかかってしまうことになる。特に社外サイトの自動操作をする可能性があるなら、オブジェクト認識のサポートアプリケーションが多く、なるべく画像認識に頼らないですむ製品を選定すべきだ。

製品選定にあたり、製品ベンダーや販売代理店を呼んで製品説明や提案を受けることになると思うが、もし可能であれば、複数の製品を取り扱っている販売代理店を呼ぶと中立的な情報が収集できるだろう。また、その際はユーザーの推進体制によって、ライセンス販売だけでなく、導入支援やトレーニングなど、RPA導入に必要だと考えるサービスを提供しているかどうかも見ておくとよい。

（3）業務候補の選定

図1：RPA導入フェイズとフレームワーク

RPAを会社で初めて導入するのであれば、パイロット導入として自分の所属する課やRPA導入に賛同してくれている部署の現場担当者に協力してもらうことになるが、現場担当者がRPAについて知らない場合も多い。
そのため、相手のITリテラシーに応じたアナウンスをして、業務候補を出してもらう必要がある。このアナウンスで重要なことは、これから行う業務候補のヒアリングに必要な情報を伝えるだけでなく、RPAを理解してもらうことと、導入のゴール（目的）を現場の賛同が得られるメッセージとして共有することだ。また、すべての業務候補に対して一気に必要な情報を集めると、現場の負担も大きくなってしまうため、段階を踏みながら詳細な情報を収集していくこと方がいいだろう。
段階的な対象業務のリストアップ例を記載する。

①現場から手間もしくは面倒だと思っている、かつ手順書のある業務について上位○個をリストアップしてもらう。

最低限、以下の情報は収集しよう。この段階で細かい内容は聞かなくても問題ない。ある程度絞った後でヒアリングすればよい。

• 業務名と業務概要（○○業務。××から依頼が来たらAシステムを使って△△する業務）
• 実施回数/月間
• 作業時間/月間

②上位○個の業務のうち、さらに上位数個に絞り、以下の項目をヒアリングする

【RPAに適合しているか？】

• 単純で定型的な作業か？
• 同じ手順の繰り返しがあるか？
• 人の手作業によるミスの発生可能性が高いか？
• ピーク性のある業務か？
• RPA導入ゴールに則したものか？

【RPAに不適合か？】

• 人間の判断が必要な業務（非定型業務）か？
• OCR読み込み等、入力がデータ化されていない業務か？
  OCR製品と組み合わせれば自動化可能だが、RPA単体では自動化できない場合があるので初期導入では避ける

③ 上記の②と同じ席上で前述の適合性を満たす業務に対して、詳細な実施手順をヒアリングし自動化できるかどうか判断する

想定出席者は次のとおりである。

1. RPA開発担当者（RPA製品に精通していて自動化の判断ができる人）
2. RPA推進リーダー（全体の優先順位からRPA推進上の実施判断ができる人）
3. 現在、現場でRPA対象候補業務を手動で実施している担当者（その業務に一番詳しい人）
4. 現場部署のリーダー（現場作業のあるべき姿が言える人）

特に4の現場部署のリーダーだが、RPA推進を対象部署と連携して進める場合、窓口となる担当者を立ててもらうことをお勧めする。なぜならば、3の手順実施者は、業務には詳しいが要件定義できない可能性があるため、業務のあるべき姿を描けて、ある程度、発言権のある人に同席してもらう必要がある。自動化に際し、そのまま自動化するのではなく、無駄なプロセスや実はいらなかった手順を廃止するなどの判断が必要になるケースもある。また、1のRPA開発担当者については、開発体制を外部に委託する場合は、導入支援ベンダーの担当者となる。

また、ここで選定する業務は、導入期の最終フェイズである全社展開を見越した業務を選定したいところだ。全社へ拡大する時に、初期導入で自動化した業務をデモとして見せることで、より自動化のイメージを持ってもらうためである。よって、ここで選定する業務は、他の部署でも行っているような業務や利用者が多い業務、または業務内容がイメージしやすい、なるべく汎用的なものが良いだろう。

（4）効果予測

業務候補に対して自動化可否の判断を行い、ある程度絞れたら、自動化した場合に何時間削減でき、お金に換算するといくらになるのか？机上で効果を予測、算出する。これは自動化後の効果実績値との予実の差異を測るためと、導入後に成果としてどれくらいの導入効果が出たのか測る場合に利用する。

RPAの開発

（1）初期導入

①RPAシナリオ開発手順

業務が選定できたら、実際にRPA製品を使って自動化を行っていく。
開発プロセスはおおむね次のとおりである。

• 開発計画の策定（プロジェクト概要や目的、開発方針、スケジュールを策定する）
• 要件定義（自動化対象業務の要件を定義する）
• RPA設計（対象業務をRPAで自動化する場合の実現方法を設計する）
• 開発（RPA製品を使って開発する）
• テスト（開発した自動化シナリオをテストする）
• ユーザー操作説明（自動化実行方法や前提条件、注意事項を説明する）

＞ 内製のための実践研修 RPAイネーブルメントサービスはこちら

②RPAシナリオを自社開発するメリット

RPAの開発は外部ベンダーに発注することもできるが、自社で開発するメリットも多い。

1. カスタマイズ性
   自社で開発することで、企業の固有のニーズや要件に合わせてRPA開発をすすめることができる。
2. コスト節約
   自社開発ならば、外部のベンダーに依存することなく、必要な変更やアップデートを自分たちで行うことができ、コストを節約できる。
3. 開発者の育成
   自社で開発することで、自社の社員にRPA 技術についての深い理解と知識を蓄積できる。これは、将来的に新たに自動化する作業を見つけ出し、要件定義から開発までを効率的に行うための重要な知的資産となる。
4. セキュリティ
   開発を社内で行えば、データのセキュリティをより高いレベルでコントロールすることができる。
5. 独自性
   自社でRPA を開発することで、競合他社とは異なる業務フローを考え出すことができる。これにより、コスト削減に加え、収益力強化の面でも優位性を得られる可能性がある。

③RPAシナリオ開発時の注意ポイント

前述したが、RPA開発は簡単なパソコン操作で作れるレベルから、システム開発に近いレベルまである。また、とりあえずは動作するものであれば比較的、簡単に作れてしまう。しかし、ここでの重要なポイントは、リリース後のシステム運用・保守を見越した設計、開発を行うことができるかという点にある。
開発にあたり考慮すべき項目例は次のとおりである。

• RPAが使うユーザーIDはロボット用の共通のアカウントにするか？（できるか？）
• RPAを実行する環境はどうするか？（PCを用意するか？仮想環境にするか？）
• 変数やシナリオ名などの命名規約、変数への値の設定方法（セキュア情報/非セキュア情報の管理）
• エラーハンドリングの実装方針
• 共通操作の部品化（モジュール化）の開発方針
• 開発時に整備すべきドキュメントの種類と内容　など

できるなら導入初期の段階で、上記をまとめた開発規約やガイドラインも整備し、それらに則った実装を行うのが望ましい。ただ、この段階でそれらドキュメントに何を記載すべきかわからないのが通常であるため、RPA導入支援と運用設計が行える専門企業に依頼してしまう手もある。専門企業の協力を得ることで、導入に必要なガイドラインを早期に整備し、運用・保守後のトラブルを減らすことができる。

また、すぐに使える開発プロセスや開発ノウハウを吸収することができるため、自社でいろいろなことを一から始める必要がない。RPAが会社に定着までの間、そういった専門企業のサービスをうまく使うことも一つの選択肢である。

CAC RPA開発／サポートサービス

CACでは、RPA導入から運用・保守までの様々なフェーズでの支援サービスを行っています。プログラミングやシステム構築が可能な人材がいない、RPA開発者の育成体制が整っていない等の状況でも、内製化を目的とした施策をトータルでサポート可能ですのでぜひご検討下さい。
＞ CACのRPA開発／サポートサービスの詳細はこちら

（2）本格導入

①社内説明のコツ

RPAは使ってみて初めて気づくことも多く、システム導入とは似て非なるものである。初期導入で自動化の実現性と導入効果の実績値を測定し、導入上の課題とその対策の見通しが立ったら、次は対象エリアを拡大して会社全体を巻き込むフェイズになる。本格導入のプロセス自体は基本的に前述の業務候補の選定～開発～効果測定と同じ手順を行うが、本格導入時にもっとも難しい事の1つは、導入の前段階の「社内にRPAの本質と価値をわかってもらう」ことだといえるかもしれない。本当に良いものでもその価値を伝えることがとても難しい場合がある。
社内的にRPAによる業務効率化の効果を理解してもらうため、以下のような対応が必要だと言える。

①決裁者への説明

この時点でまだ会社として「RPA推進GO」が出ていない場合、上長や経営層に初期導入の成果をもとに全社RPA推進の企画を上げることになる。基本的には以下について企画としてまとめる。

• RPAについて理解してもらう（初期導入で自動化した業務をデモとして見せる）
• RPAの導入効果とゴールを示す（初期導入の成果とともに、全社導入で期待される導入効果を示す）
• 初期導入で分かった課題と対策
• 推進体制や予算など必要なもの、人、お金、お願い事項　など
  ※推進体制については、後述（4）RPAの運用を参照

企画書の書き方や進め方は各企業のカルチャーや慣習によるものと考えるが、RPAそれ自体は、会社をより良くする改善活動であるため、理解させる・指示するスタンスというよりは、「RPAの良さや、もたらされるメリットを分かってもらって仲間を増やす」気持ちで取り組むと賛同を得やすく、会社の「横」へ、そして「上」へ広げやすいと感じる。
最終的に会社を動かして全社的な取り組みまでもっていくためには、段階を踏みながら、相手に合った方法でプロジェクト実績を積み上げ、あなたと一緒にRPAに取り組んでくれる仲間を増やしていこう。

＞ CAC RPAセミナーオンデマンド　自分で改善！草の根導入でRPA自社開発を立ち上げる

②勉強会・説明会の代行利用

場合によっては、RPAベンダーや販売代理店に頼めば、社内勉強会や説明を行ってくれる場合もある。主要なRPAベンダーであれば、RPA市場の先頭集団を走っている身として、世界で何が起きているか、熱をもって話してくれるはずだ。決裁者や社内のキーマンには、しかるべきベンダーの要職者から直接、説明してもらえると、RPAを取り巻く世間の潮流を感じて、心に火が付く可能性がある。

または社内の関係者をRPA関連のセミナーに連れ出し、他社事例の講演を聞くのも手である。その場合、RPAベンダーやRPAコミュニティ主催のカンファレンスをお勧めする。業界の主要企業が数年前からRPAに取り組み、すでに成果を上げている事例を目の当たりにすることで、無視できない流れであることを身をもって体感してもらえるはずだ。

RPAの運用

RPAは開発しただけでは有効に活用することはできず、運用体制やルールを定めることが重要になる。
RPAの運用計画を立てる際には、作業の範囲や目的を明確にし、作業の優先順位を決定することが有効と言える。また、RPAの導入により生じる問題を解決するためには、適切な保守体制や運用管理体制を整備することが必要である。

その上で、作業内容の定期的な見直しと更新、そしてRPAの性能を最大限に引き出すための教育やトレーニングが効果的なRPA運用には不可欠となる。

（1）運用してからが本番

実際は「3.RPAの開発」でRPAを業務で使い始めたときから、同時並行的にRPAの運用が開始される。RPAは自動化してリリースしてからが本番である。RPAの失敗事例の大半は計画、開発時ではなく運用後に多く発生している（図2参照） 。

図2：失敗事例の件数

そのため、運用上のトラブルを回避するためにも、運用体制の確立と導入の標準化やルール整備は重要であると考えたほうが良い。
RPAの運用では「計画」、「開発」、「運用」のRPAライフサイクルを回しながら、管理していく（図3参照） 。さらに、これら3つのフェイズに紐づいた各ガイドラインを整備し、ルール化して統制管理を行うことが必要である。

図3：RPAライフサイクルとガイドライン

（2）RPAの運用体制

RPAの運用体制だが、図3の「RPA推進部門」および「RPA開発担当」は、情報システム部門と経営企画部門が連携またはミックスした新組織として行うケースが多い。RPAはITでも人でもないが、システム開発やIT運用管理の手法と同じ部分もあるため、社内展開の際の統制やルール作りに際し、情報システム部門の協力が不可欠だと考える。

また、経営企画部門はRPA自動化対象部門となるバックオフィスとの連携や統制、全社横断的な改善活動を行う際に必要となる。さらに、RPAの特徴として「RPA利用部門」がこのライフサイクルに大きくかかわることになる。

「RPA推進部門」は、リリース後も「RPA利用部門」からRPAが想定通りに動いているか、実際に使われているか、改善事項はないか、定期的にフィードバックを受けて管理していく。この情報システム部門と経営企画部門が連携またはミックスしたRPA推進体制は、自動化して業務改善したいRPA利用部門に対して、自動化の機会をヒアリングしながらあくまで冷静に導入のゴールに沿った業務選定を行い（計画）、運用保守を考慮した設計・実装（開発）およびリリース後の効果測定、RPAの監視・管理（運用）を行う。RPAの特徴として、特に保守の頻度は通常のシステムより多くなると想定しておいたほうが良い。よって、できるなら、「計画」「開発」「運用」の各担当者は分けることをお勧めする。

（3）RPAの運用のポイントまとめ

RPAの運用を効果的に行うためのポイントは以下の通りだ。

1. プロセスの定期的な監視と更新
   RPAは定期的な監視と更新が必要となる。システムの変更やアップデートにより、RPAのプロセスが正常に機能しなくなる可能性があるため、定期的にシステムの変更を確認し、必要に応じてRPAのプロセスを更新することが重要になる。
2. エラーハンドリング
   RPAは自動化されているものの、エラーが発生した場合には人間の介入が必要となる。エラーが発生した際の対応策を事前に準備しておくことが望ましい。
3. 記録
   RPAのプロセスは複雑であるため、動作等の記録が重要となる。プロセスの詳細、変更履歴、エラーの対応策などを記録しておくことで、問題が発生した際の対応をスムーズに行うことができる。
4. トレーニングと教育
   RPAの保守を担当するスタッフは、RPAのツールやプロセスについて十分な知識を持っている必要がある。アップデートされる製品情報に対応するためにも、定期的なトレーニングや教育を行い、スキルを維持・向上させることが重要である。
5. パフォーマンスの監視
   RPAのパフォーマンスを定期的に監視し、問題が発生していないか確認することも必要になる。パフォーマンスが低下している場合、原因を特定し、適切な対策を講じていけるようにしたい。

最後に

これまでRPAを小規模にはじめて会社規模まで拡大する方法について、ステップごとにポイントを絞り述べてきた。今後RPAは、普及期から拡大期を経て、当たり前の労働力になっていく過程で、AIなどほかのテクノロジーと連携しながらさらに仕事の幅を広げていくだろう。
その中で、筆者が考えるRPAがもたらす最も大きなインパクトは、「人の価値観が変わること」ではないかと捉えている。

RPAは人より「正確に」「早く」「安く」仕事を行うことができる。これらは今まで人間が会社や顧客から受けていた評価軸でもある。RPAが人間以上に「正確に」「早く」「安く」仕事を行うと、人はもっと人間らしい仕事を期待され、そのアウトプットで評価されるようになる。人によってはとても戸惑うかもしれない。
なぜならば、従来型の仕事は半ば人間性や自分らしさを抑えて機械的にこなすことが期待された仕事であり、大半の企業はそういった仕事に従事する従業員を管理・統制するために最適化された階層型の組織構造によって成り立っているからだ。RPAによって価値観や評価軸が変われば、人の仕事のやり方も変わらざるを得なくなり、組織も最適化する必要性が出てくるものと思われる。そしてこれが筆者がRPAは会社で取り組むべきだと考える理由の1つでもある。

RPAは「働き方改革」に直接的に効くソリューションであるため注目を集めている。筆者は「働き方改革」の本質は「人間性を取り戻す事」であると考える。人は今後、RPA（ロボット）と向き合うことで、人間性や自分らしさと向き合うことになるだろう。
RPAは普及期から拡大期を経て現在に至っているが、これから始めるのに遅いということはないし、既に導入している企業もRPAでできることはまだまだ多いだろう。本稿が、これからRPA導入に漕ぎ出す皆様、漕ぎ続ける皆様にとっての一助となることを切に願う。