1．RPA導入の課題

近年，DX（デジタル・トランスフォーメーション）や，働き方改革[1]，労働人口の減少等の背景により，RPA（Robotic Process Automation）の普及が拡大傾向にある[2]．RPA導入の担当者や関係者は以下のような特徴を期待することが多い．

• RPAはローコード[3]，あるいはノーコード[4]（プログラミングの代わりにGUIや設定を通してシステムが開発できる）ツールであり，非エンジニアでも比較的容易に導入が可能である
• RPAのロボットにより，業務の自動化・効率化が成され，生産性が向上する

これらの特徴は誤りではない．しかし，RPAはこのような効果をただもたらしてくれる魔法の杖でもない．十分な検討を行わず，軽率にRPAの導入を実施しては，手痛い失敗に終わってしまうケースも起こり得る．実際にRPAを導入する過程で，筆者らは次のような知見を得た．RPAを利用する上での技術やルールをしっかりと確認した上で，まずは小規模に導入し，そこから徐々に拡大していくのが望ましい．

本稿では以下のような順序で，実際に筆者らがかかわったRPA導入の最初の挑戦と，そこから得られた知見を活かしたRPA展開事例について紹介していく．まず，第2章「最初に行われたRPA導入の挑戦」では最初に行われたRPA導入の事例について説明する．続く第3章「最初の挑戦から得られた知見」では第2章での挑戦から得られた5つの知見について解説していく．第4章「知見を踏まえて実施した2度目のRPAの展開」では第3章で解説した知見を元に行われた2度目のRPA導入事例について説明する．第5章「2度目のRPA展開の振り返り」では，第4章で述べたRPA導入事例で得られた気づきについて解説する．第6章「現状の課題と今後の展望」では，第4章と第5章で解説した導入により発生した課題や，今後さらにRPAの活用を広めていくために必要だと考えた内容について述べる．

2．最初に行われたRPA導入の挑戦

本章ではヤフー（株）のコーポレート部門で最初に行われたRPA導入の挑戦について説明する．筆者らはこのプロジェクトの途中から参加し，主に技術面の支援やマネジメント関連でかかわることとなった．

このRPA導入はトップダウン的に幹部らの意思決定により，大幅な工数削減を目的として実施された．当時，ITツールの活用や業務プロセスの見直しによる，大幅な業務効率化を目指した全社規模のプロジェクトが行われており，その影響によるものだ．そのため，このRPA導入では「RPAによりどれだけの工数が削減できるか」が重視され，KPIには「RPAにより何人月分の工数が削減できたか」という具体的な数字が設定された．そして，その数字をできるだけ大きくすることが求められた．

これにより，このRPA導入はRPA化可能な業務が多い領域を対象とした大規模なものとなった．実際の導入対象として，業務量の多いCS（カスタマーサポート）領域が選ばれ，領域全体に対して業務内容のヒアリングが実施された．また，コーポレート部門では初のRPA導入であったため，ヒアリングはコンサルティング会社の協力の下で行われた．そのヒアリング結果を元に，RPAに置き換えが可能な業務が洗い出され，その業務にかかっていた工数を合算した値として，対象領域の業務工数の約41%に相当する，約10,000時間／月分の業務削減がプロジェクトの目標として設定された．筆者らはこれをかなり大きな目標であると感じた．同時にプロジェクトの期限は1年と設定されていた．この目標達成のためには，短期間で大量のロボットを開発する必要があった．そのため，ロボットの開発は外部の開発ベンダに委託することとなり，目標の規模に比例して関係者の数も増大していった．

このRPA導入はさまざまな要因により上手くいかなかった．その要因に関して，以下のようであったと分析している．

• 目標達成のため業務数にして約200件もの業務のロボットを開発しなければならず，東京や八戸，大分等の複数の拠点[5]で一斉にロボットの開発が行われたため，プロジェクト内での連携が取れなかった
• 期限内に目標を達成するためにはロボットを少しでも早く開発しなければならず，ロボットの要件や技術的な課題に関して明確に解決していないにもかかわらず見切り発車的にロボットを開発しなければならなかった
• コンサルティング会社や開発ベンダ，業務担当者間の連携が不十分で，適切な業務分析や情報共有が出来なかった
• コンサルティング会社の技術者も業務担当者も，社内のインフラ部分（システムの仕様やネットワーク，セキュリティに関するルール等）に明るくなかったため，技術的，あるいはルール的に実現不可能な仕様（表1）でロボットが設計されてしまうケースが多発した

最終的に，大量の中止案件と，作られたものの利用されないロボットを生み出す結果となり，実際に業務で利用されたロボットはごくわずかだった．

3．最初の挑戦から得られた知見

前章での経験からさまざまな知見が得られた．その中でも，「業務担当者が推進すること」，「技術的なインフラの確認」，「事前の社内規則との調整」，「スモールスタート」，「RPAにより自動化する業務の優先順位の設定」，これらは特に重要な知見であると考える．本章ではこの5つの知見について解説していく．

3.1　業務担当者主導での推進

1つ目は，RPAの導入は実際に業務を担当する人が中心となって進める方がよいということだ．RPAのロボットは「デジタルレイバー」と呼ばれることがある[6]．これは，RPAのロボットを人がもともと行っていた業務を代行してくれる労働者のように擬人化する考えに基づいている．つまり，RPAのロボットはもともと業務を行っていた人の分身である，と捉えることができる．業務担当者の分身を他人である技術者が作ることは困難である．業務について最も理解しているのは，その業務の担当者だ．そのため，業務の担当者を中心として導入の判断を行うことで失敗リスクを回避する可能性を高めることができる．担当者からのヒアリングの結果だけで担当者を抜きにしてRPAの導入を判断すると，導入開始後に思わぬ落とし穴が現れるリスクが高くなってしまう．

ここで述べている落とし穴の例として，RPA導入の担当者と業務の担当者が異なることから生じるヒアリング漏れが挙げられる．ヒアリングを行うRPA導入の担当者がRPAの導入に意欲的なのは当然だが，ヒアリングを受ける業務の担当者がRPAの導入に意欲的とは限らない．業務の担当者からすればヒアリングを受けることは「本来の業務とは無関係な面倒事であり，頼まれたから仕方がなく受けているもの」だった．このRPA導入を他人事と捉えてしまうモチベーションの低い状態は，ヒアリングによる業務要件の洗い出しの網羅性を低下させてしまう．また，同時にRPA導入の担当者はその業務について明るいわけではないため，ヒアリングの結果が十分なのかを判断できない．結果として，不十分な要件でロボットの開発がスタートしてしまうこととなり，実際にロボットの開発が完了してレビューを行う段階で，明らかになっていなかった要件が判明し，作業の手戻りが発生することになった．

3.2　技術的なインフラの確認

2つ目は，ロボットを動作させる技術的なインフラの確認が必要なことだ．RPAの製品によって，ロボットにはさまざまな仕様が存在する．たとえば，ロボットはサーバ上で動作するのか，作業者のクライアントPC上で動作するのか．また，ロボットはPCを直接操作して業務を行うのか，ロボット内に組み込まれたソフトウェア上で独立して動作するのか．利用する製品のロボットの仕様を，RPAの導入を行う前に確認しておかなければ，ロボットが期待に応えられないものになってしまうリスクが大きくなる．もしサーバ上で動作するロボットであるなら，ネットワーク的にそのサーバからロボットが利用するシステムにアクセスできるかを確認する必要がある．また，クライアント上で動作してPCを直接操作するロボットであるなら，処理時間が長いロボットを作ってしまうと，ロボットに業務を代行させて空いた時間ではその端末を操作できず，他の業務が止まってしまうことになる．

3.3　社内規則の調整

3つ目は，社内のルールやセキュリティに関する調整の重要性である．RPAにはシステム化された業務や人による手作業とは性質の異なるリスクが存在する．たとえば，RPAのロボットは利用するWebサイトの変化に弱いためそれにより誤作動が発生するリスクや，ロボットに業務を代行させた結果として業務内容がブラックボックス化してしまい，将来的に業務を理解している人間が居なくなってしまうリスクなどが考えられる．RPAは新しい概念であり，既存の社内のルール制定時に考慮されていなかったリスクが顕在化する可能性がある．RPAで業務を自動化する際にはこのようなリスクの存在を考慮し，どのように利用してよいかを事前に明確にしておくことが重要である．ロボットが誤作動を防ぐためにはどんなルールや統制が必要なのか，ロボットにどこまでの業務を代行させてよいのか．この調整を怠ると，ロボットが重大な事故を引き起こしてしまうリスクが高まってしまう．顧客情報を扱う業務をロボットに代行させた所，ロボットが誤作動を起こして顧客情報を消してしまった，というような事態も考えられる．

3.4　スモールスタートの重要性

4つ目は，スモールスタートの重要性である．始めて扱う技術があるプロジェクトでは最初から大きな規模で実施するべきではない．初めて扱う技術については未知の部分や実際に利用してみないと分からない部分が多いからだ．

また，前述した3.2節の技術的なインフラや，3.3節の社内規則に関して，万が一，十分に確認・調整が済んでいない状態で導入を進めてしまった場合，後々になってからこれらの点が指摘され，最悪の場合は導入が中止になってしまうことも考えられる．このようなリスクを最小限にするためにも，スモールスタートで始めることは有効である．

第2章で述べた最初のRPA導入の事例に関しては，最終的な目標を大きく立てたとしても，最初の一歩は小さく始めるべきだった．まずは小規模に，1つの業務に対して実務レベルでの導入を実施し，製品に関する理解を深めてから，徐々に拡大していく方法がよい．

3.5　RPAにより自動化を試みる業務の優先順位

5つ目は，RPAにより自動化を試みる案件には優先順位の設定が重要だということだ．3.4節の「スモールスタートの重要性」で述べたように，複数業務へのRPA導入を一度に行うのでなく，まずは小さめの1つの業務に対してRPAを導入するのがよい．この1つの業務を選定する際の優先順位は社内の規則や業務の内容によるリスクの小さい順に設定するべきだ．

業務をRPAのロボットにより自動化することは，3.3節「社内規則の調整」でも述べたようにさまざまなリスクが存在する．次に述べる理由から，これらのリスクが小さいものから導入していくべきだ．ロボットを開発する際にバグを完全に取り除くことは難しい．また，初めてRPAを導入する段階では，まだそのRPAの製品に関する理解が不十分である．そのため，実運用時に誤作動を起こす恐れがあり，そうなった場合でも被害を最小限に収めなくてはならない．「もしロボットが誤作動を起こしたら，どうなってしまうか」を意識して業務を選ぶ必要がある．このリスクが小さい業務の特徴については（表2）に記す．3.2節で述べた「技術的なインフラの確認」や，3.3節で述べた「社内規則の調整」を実施した上で，このリスクが小さな業務から手を付けるのがよい．

4．知見を踏まえて実施した2度目のRPAの展開

本章では第3章で解説した知見を元に，体制を刷新した上で行った2度目のRPA導入事例について説明する．この2度目の挑戦は，予算規模を縮小し，定量的な数値目標を設定せず，定性的な目標を掲げ，推進した．筆者らは，この2度目の導入ではプロジェクト開始時点から主要メンバとして参画した．

4.1　「普段使いのツール」を目指す方針

まず，大きな方針としてRPAが「普段使いのツール」となることを目標とした．「普段使いのツール」とは，たとえばExcelやWordのような，多くの人が比較的容易に使えるツールのイメージだ．現実的には，RPAを使いこなすにはRPA自体に関する知識や，参照するシステムによってはHTMLやCSSといったWebに関する知識も必要となるため，本当にExcelのように誰でも使えるようになることは難しい．そのため，これはあくまで理想としての目標である．この方針は，前章で述べた「業務担当者主導での推進」の知見から作られている．「普段使いのツール」として業務を行っている担当者がRPAに習熟することで，自動化の是非の判断，RPAの効果的な利用方法の発見を，現場が主役となって進めていくことができる．このような理想の下に2度目のRPAの導入は進められた．

また，「普段使いのツール」として業務を行っている担当者がRPAに習熟することは，さまざまなメリットを生む．たとえば，RPA活用のスピード感がその1つだ．RPAのロボットの開発は，簡易なものであれば低コストで実装が可能である．たとえば，Excel上の表の内容をWebサイトのフォームに入力して登録ボタンを押す，という作業を繰り返す業務があった．RPAに習熟した者がこの業務を行うロボットを開発した際，最低限の実装であれば2時間程度で実際に動くものを作ることができた．現場主体でRPAを活用できれば，このスピード感を最大限に活かすことも可能になる．

もう1つのメリットとして，RPAのメンテナンスが適切に行えるようになるという点がある．RPAのロボットの意図せぬ挙動は，参照するWebサイトの仕様変更や，開発時点で想定から漏れていた業務の例外的な処理等に起因して発生することが多い．これらの課題は業務を行っている担当者が検知することになるため，業務担当者がRPAに習熟しており直接メンテナンスできるようになっていれば迅速に対応することが可能となる．

以下，「普段使いのツール」を目指す方針を実現するために行った2つの施策，「ボトムアップな導入の支援環境整備」の施策を4.2節で，「ルール・可用範囲の明確化」の施策を4.3節で，それぞれ述べる．導入したRPA群が完全に「普段使いのツール」となったわけではないが，実施した施策は4.4節で後述するように普及効果を上げた．

4.2　ボトムアップな導入を支援する環境作り

4.1節で述べた理想の下に現場主体でボトムアップにRPAの導入が可能な環境作りを行った．これは，専門の組織が他の組織から依頼を受けてRPAの開発を一手に担うような推進方法（図1）ではなく，各組織の業務を行う現場が独自にRPAの開発・運用を行っていくことを促す方法（図2）である．しかし，業務を行う現場は日々の業務で忙しく，新たにRPAを導入するだけのリソースが確保できないことが多い．業務を行う現場にRPA導入の主役となってもらうには，RPAの導入のためのハードルをできる限り下げる必要がある．そのため，RPAの導入のための環境作りとして，RPAの利用を開始する際の障害や疑問を取り除くためのさまざまな施策（表3）を行った．これらの施策は導入のハードルを下げると同時に，「少し興味がある」程度の人にもRPAに触れる機会を設けることができ，結果としてより広い領域にRPAを普及させていくことにも繋がった．

4.3　ルールと可用範囲の明確化

さらに，RPAの利用に関するルールを明確に定めた．社内のルール上に不明瞭な部分があっては，安心してRPAを利用することができない．そこで，CISO（Chief Information Security Officer 最高情報セキュリティ責任者）等のセキュリティに関する組織と協力してルールの明確化を進めた．たとえば，ロボットが想定外の事故を引き起こしてしまった際の影響範囲は小さくし，コントロール可能な範囲に収めたい．その場合，顧客情報のようなセキュアな情報を扱う業務をRPAのロボットに代行させてはならない，というルールを定義する，という具合だ．少なくとも導入初期の段階では，絶対に事故が起きてはいけない領域ではRPAの導入は控えるべきである．このようにリスクや影響範囲を小さくすることを中心に，主要なルールを最初に定義した．表4の種別がルールとなっている部分にこのルールの一例を示す．

ルールと同様に技術的な可用範囲を明確に定めた．インフラ等の技術的な面でも，不明瞭な部分があっては安心してRPAを利用することができない．そのため，情報システム部等の社内インフラに関する組織と協力して，技術的な可用範囲の明確化を進めた．たとえば，ロボットが意図せぬ挙動で暴走してしまった際に，社外にまで影響を広げたくない．その場合，ロボットが利用してよいWebシステムを社内システムと，契約しているSaaS製品に限定する，という可用範囲を定義する，という具合だ．この可用範囲もルールと同様にリスクや影響範囲を小さくすることを中心として定義した．表4の種別が可用範囲となっている部分にその一例を示す．

4.4　2度目のRPAでの普及状況

このような方針と施策は短期間で爆発的な効果を生むことはできなかったが，代わりに長期的に多くのRPAユーザを生み出すことに成功した．現在では約200名のRPA利用者と約200台のロボットが活躍している．また，コーポレート部門から始まった普及だったが，今ではさまざまな部門で利用されている．図3，4にロボット台数と利用者の増加傾向を示す．横軸は年月を，縦軸はロボット台数と利用者数を示す．図5，6にロボット台数と利用者の所属部門別割合を円グラフで示す．青色の領域は最初に行われたRPA導入の適用対象であったコーポレート部門を，赤・緑・紫の領域は他の部門の割合を示す．

5．2度目のRPA展開の振り返り

本章では，前章で解説した2度目のRPA展開を振り返って得られた気づきについて述べる．

5.1　全社的なRPA利用の統括の影響

2度目のRPA展開では全社的なルールやインフラに関してすり合わせた上で実施されたため，全社的なRPAの利用に影響を与えることとなった．今回のプロジェクトが開始される前からRPAを独自に導入している部門が存在しており，それらに関しても今回のプロジェクトで定めたルールやインフラに合わせる必要が発生した．これには2つの良い面と，1つの悪い面のそれぞれが存在した．

1つ目の良い面は，契約やライセンス管理の集約だ．各部署で独自にRPAを利用している場合，その部署が独自にRPAのプロダクトの契約やライセンス管理を行う必要があった．しかし，今回の導入によりRPAプロダクトの契約やライセンス管理を，RPA導入支援を行う組織で一括管理し，各利用者にアカウントを提供する仕組みが出来上がった．これにより，各部署が個別で管理する必要が無くなり，契約の締結やライセンス管理といった作業のコストを無くすことができた．

2つ目の良い面は，サポートの充実である．各部署が独自にRPAを利用している場合，RPAを使える人間のリソースがロボットの開発と運用のみに割かれてしまいがちで，他の利用者を育成したり，サポートしたりすることに課題を抱えているケースが多かった．RPAのロボットを開発・メンテナンスできる人間が部署内に1人しかおらず，その人が異動となった際にロボットを利用できなくなる，という事例も発生していた．これに対して今回の導入により，RPAを学習するためのコンテンツや技術的なサポートを提供するRPA導入支援を行う組織が部署外に出来たため，部署内でこれらのサポートを行うことが不要になった．

悪い面は，今回定めたルールやインフラと既存のRPAの利用に食い違いが発生したことだ．最初のRPA導入のプロジェクトが発足するより前から，社内には独自にRPAを導入している組織が存在していた．この独自に行われていた導入は全社的なルールがない状態で実施されたため，今回のルールでは利用が許可できないような使われ方をされているケースが存在していた．そのため，今回のルールを定めるにあたって，すでに業務を行っているRPAのロボットとのすり合わせや，場合によってはルールの例外として取り扱うためのリスク受容が必要となった．ただし，これは逆の見方をすれば，社内に存在していた潜在的なリスクを炙り出すことに成功したとも考えられるため，一概に悪い面しかなかったというわけではない．

5.2　RPAのロボット開発者への適性

RPAはローコード，あるいはノーコードなツールであり，プログラミング不要で導入が可能だが，これはしばしば「簡単」あるいは「誰でもできる」と勘違いされがちである．実際には，Webサイトの仕組みや，プログラミングで登場する概念について理解しているかどうかによって，RPAを利用するための難易度は大きく異なる．たとえば，元エンジニアの経歴を持つ企画担当者は，標準学習時間が2週間のロボット開発者向けの研修を2日程度で完了させるようなこともあった．一方で，業務部門のRPA担当者では，変数や文字列といったプログラミングで登場するような独自の概念がなかなか理解できず，苦戦するケースもあった．

このような視点から考えると，RPAのロボット開発への適性を持つ人材がどのような人材なのかが見えてくる．まず，最も適性を持つのがエンジニア出身の人材や，プログラミングの経験がある人材だ．RPAのロボットの開発者は，プログラムのソースコードを書くことはないが，実質的には姿を変えたプログラムを作っているようなものである．そのため，プログラムで扱う変数やループ処理，アルゴリズムといった概念を理解していれば，RPAを学習する際に大きなアドバンテージとなる．次に適性を持つ人材はExcel等のツールを使いこなすことができる業務担当者だ．Excelで複雑な表計算を行う際に利用する計算や関数の概念は，ものごとをロジカルに考え，筋道を立てて結果を導き出す能力を必要とすることが多い．このような能力もRPAのロボットを開発する際の手助けになる．逆にこのようなITに関する理解やスキルが不足している場合，RPAを使いこなすには苦戦を強いられると思われる．

5.3　RPAへの適性とニーズのある領域とのギャップ

RPAを利用したいというニーズがある領域と，5.2節で述べたRPAのロボット開発者への適性を持つ人材にギャップがあることも，今回のプロジェクトで得られた気づきの1つだ．他社に比べると，筆者らの所属するヤフー（株）には全般的に新しいことをやってみようという文化があると感じている．今回のRPAの展開は大々的な告知なしで進められたプロジェクトだったが，4.4節で前述したように半年で100アカウント近くユーザが増加していることがそれを物語っている．しかし，RPAの需要が高いのは主に定型業務を多く抱える業務部門や企画部門だ．このような領域では，弊社であってもITリテラシーが特別高いわけではない．5.2節で述べたRPAへの適性もそうだが，自動化することのリスクや運用フェーズ以降に必要となる作業を想像できず，導入が中途半端になってしまうようなケースも発生してしまった．だからこそ，今回のRPA展開でユーザをサポートしていく際に，ITリテラシーや理解への目線を合わせて並走していくことが特に重要であった．

6．現状の課題と今後の展望

本章では，第5章で解説した2度目のRPAの展開で見えてきた新たな課題と，今後の展望について述べる．

6.1　RPAの具体的な効果の不明瞭さ

ボトムアップにRPAを展開していった結果，具体的なRPAの効果が見えにくいという課題が発生した．ここで述べている効果とは，RPAのロボットの生産性である．たとえば，ロボットが何人分の働きをしているのか，ロボットのおかげでどれだけの工数が削減できたか，といったものだ．最初に達成すべき効果目標を設定して進める方法で導入していれば，事前に効果の試算を行い，達成・未達成によりどれだけの効果が出たのかを明確に出すことができる．しかし，2度目のRPAの展開では，事前に目標を定めるのではなく，さまざまな業務領域が個別に活動を行っているため，全体での規模感や効果を正確に掴むことができなかった．

また，RPAのロボットに行わせる業務の種類も，効果を明確にすることを難しくしている．筆者らはRPAのロボットに行わせるのに適した業務には大きく分けて2種類あると考えている．1つ目は，すでに人が手作業で行っている業務で，2つ目はRPAのロボットにより新たに行うことが可能になった業務だ．

1つ目のすでに人が手作業で行っている業務については効果を求めるのは難しくない．RPAの導入前後でその業務にかかる時間がどれだけ変化したかを計測すればよい．これまで人手で3時間かかっていた業務が，ロボットを活用することにより1時間で終わるようになったのなら，2時間分の工数削減の効果が出ていると言える．

2つ目のRPAのロボットにより新たに行うことが可能になった業務は，効果を求めるのが難しい．たとえば，業務として行いたいが，処理する件数が膨大で人手では処理しきれず，これまで行われていなかったような作業があった．これは「これまで行われていなかった業務」だ．この業務をRPAのロボットによる自動化によって「実施が可能な業務」にすることができた．しかし，これまで行われていなかった業務であるため，ロボットがどのような効果をもたらしているか，どの程度の価値を生み出しているかを算出することは難しかった．そもそも行われていなかった業務であるため，業務としては必須ではなく，本質的な価値はそれほど高くなかったかもしれない．そのため，単純に人手でやっていた場合の時間を仮定して仮の削減効果を考えてしまうと，本質以上の効果を生み出していることになりかねない．実際にここで述べた業務をロボットで自動化した際に，効果が月に26,000時間となった．通常のロボットの効果を平均すると100時間未満であることを踏まえれば，この数字を同列に扱うのは難しい．

6.2　外部委託活用の検討

また，最初の導入での経験から，ヤフーのRPA推進担当者が外部の開発ベンダやコンサルティング会社を利用することに慎重になりすぎている面があると感じている．最初の導入では，社内にRPAに関する知見がない状態で，大規模かつ並列にものごとを進めてしまったのが，主な原因である．2度目のRPA導入を実施した後では，それなりに社内にRPAそのものやプロダクトに関する理解度が深まりつつあるため，今後は適切に内製と外製を使い分けられるような体制の構築にも挑戦していきたい．

現在は試験的に，要件定義を社内で実施し，ロボットの実際の開発を外部の開発ベンダに委託する，という体制を，比較的小さい案件で実施してみている．要件定義を社内で実施することにより，どんなロボットを作る必要があるのかを社内の業務担当者が意識的に考える必要があるため，ロボットの開発を行わなくても他人事にはならない．また，その要件定義を開発ベンダに伝える際に，改めて内容を言語化するなど，開発ベンダ側からの視点からの意見を得たりすることで，社内のみで進めるより，品質の高いロボットを作ることができると考えている．このように，RPAを導入する上でより良い体制を組めるよう，今後はさまざまな方法を試していきたい．

6.3　全社的なマインドの育成

最後に，全社的にいわゆるDX的な「改善」のマインドを育てていく必要があると考えている．現場主導でRPAを導入する際に重要になるのは，ただ盲目的に日々の業務を行うだけでなく「こうすればより効率的に業務を行える」とか「こうすれば業務のミスを減らすことができる」といった「改善」の気づきだ．RPA自体はただの道具であり，ただ使い方を学んだだけでは何かが起きることはない．「RPAをここに使えば今より改善できる」というように，「どこでRPAが使えるか」を気づくことができて初めてRPAの導入が進み，効果が生まれる．この「改善」のマインドを如何に育てていくかが今後は重要になると考えている．

7．RPA導入を検討している方への提言

最初のRPA導入の挑戦と，そこから得られた知見，その知見を元にした2度目のRPA展開の方法と，今後さらにRPAを社内に普及させていく上での課題と展望について論じた．RPAを初めて導入する際には，いきなり大きな効果を出そうとし，大規模に実施するのではなく，まずは小規模にリスクが低い所から，業務担当者がしっかりとかかわる形で進めていき，十分にRPAに関する理解が深まってから広く展開していく方法が効果的である．

RPAはまだ比較的目新しいツールであり，便利な魔法の杖のように誤解されていることも少なくない．本稿が今後RPAを新たに導入する読者の参考になれば幸いである．