このレポートは、株式会社エル・ティー・エスのLTSコラムに2018年3月に掲載されたものを移設したものです。
RPAはとても便利なツールですが、数多くある業務自動化の選択肢の一つであり、他にも効果的な自動化ソリューションは存在します。これらのソリューションの中でとりわけRPAが注目される理由には、日本のITが抱える根深い問題があるように思います。このレポートでは、RPAブームの背景にある日本のITの課題について概説します。
なお、本レポート内の提言・意見については、著者の私見であることをあらかじめお断りいたします。
本レポートのPDFデータをページ下部よりダウンロードいただけます。
>>失敗しないRPA導入 第1回：試験導入始め方から本格導入、高度な業務自動化に向けて（前編）
>>失敗しないRPA導入 第2回：試験導入始め方から本格導入、高度な業務自動化に向けて（後編）
RPAは自動化ソリューションの一部でしかない
RPAは業務を自動化するソリューションの一つです。一般的に業務の自動化で使われるソリューションを図で示していますが、RPAだけではなく目的に応じて様々なソリューションがあります。
※2 補足：「判断の自動化」と「工程の自動化」は密接に絡んでおり完全に分類することは難しいため、「主に」という枕言葉をつけている
処理工程自動化ツールであるBPMS（Business Process Management System）やワークフロー、RPAといったツールでも大抵は何らかのルールエンジンを搭載しているので、ここで「判断の自動化」に記載した「ルールエンジン」はBRMS（Business Rule Management System）のようなルールマネジメント専用のツールを指しています。
またAIについては便宜的に「判断の自動化」に載せていますが、AIは要素技術ですので図に載せた全てのツールで活用することが可能です。産業用ロボットの制御にもAIは活用されており、コミュニケーションロボットの代表格である「Pepper」の対話学習にもAIは活用されています。RPAもAIを活用した次の世代が議論されています。
これらのソリューションはそれぞれに活用シーンが異なるため、目的と状況に応じて各種のソリューションをバランスよく活用することが大切です。ですが、工程の自動化において情報システム化と、RPAのような人的操作の自動化のどちらを優先すべきかと言われたら、まず情報システム化を検討し、それで対応できない業務についてはRPAを検討するべきだと考えます。
確かにRPAはシステム化に比べれば迅速性やコストの低さという観点からは便利なツールです。一方で人がデスクトップ上で行っている作業を自動化するツールという特性上、セキュリティや内部統制、プロセス管理の観点からは（少なくとも今のところは）情報システムと比較すると脆弱な仕組みであることも事実です。またRPAはあくまでも現行の仕事のやり方を局所的に自動化するものに過ぎず、業務の抜本的な見直しには向かないツールです。ですから当初からRPA活用を前提としてしまうと、無駄な業務や属人化された業務、非効率な仕事の進め方が見過ごされてしまう危険性も内包しています。
このようなことを考慮すると状況が許す限りはシステム化を含めた抜本的なプロセスの在り方の検討を優先し、その上でシステム化対象から漏れる箇所にしっかり統制を効かせながらRPAを活用するというのが原則だと考えます。
RPAが注目される背景
上述したような事情がありつつも、なぜ各種の自動化ソリューションでとりわけRPAが注目されるのでしょうか。「働き方改革や人手不足による業務効率化や生産性向上が必要とされているため」という説明がされることも多いですが、業務効率化や生産性向上は企業にとって過去から課題であり続けてきましたし、業務を自動化するソリューションはRPAの他にも数多くあります。
RPAが得意とする作業は、エクセルやシステム間での情報の入力や転記、いわゆる“コピー&ペースト”です。また、ウェブサイトなどから特定の情報を抽出してエクセルなどへ整理する情報収集業務でも活用されます。RPAが実施可能な処理は技術的にはシステム化で完全に対応可能で、RPAでなければできないものではありません。このような処理がシステム化の対象とならない理由は、以下のようなものが考えられます。
- 重要情報を扱うといったセキュリティ上の理由で意図的にシステムを分離している
- インターフェースの対象となるシステムが外部（他社）のシステムである
- 二つのシステムの管理者が異なり、費用や管理の面で合意形成できずインターフェースを構築できない
- システム化にかかるコストを回収できるほどの処理ボリュームがない
- IT部門が既存システムを改修したり、新規開発したりする余力を確保できない
- 業務上の要求が頻繁に変わる、もしくは変わる可能性があり、システム化しても十分に活用されるか不明
このうち１についてはセキュリティ確保という意図的な目的があるため、システム化しない理由が成り立ちます。また２のように外部のサイトから情報収集を行う業務のような場合、相手のシステムに結合させることは難しいため、このような目的でのRPAの活用は理にかなっていると考えます。
しかしそのほかの理由は、RPAによる自動化の対象となる業務はコストや組織的な理由に起因しています。RPAが活用される背景として、上述のような理由が大半を占め、別の側面から見ると「社内のステークホルダーをしっかり巻き込み」「効率的で」「柔軟な」システムの開発や改修ができれば、RPAの活躍余地はなくならないにしても減る可能性があります。システム化を差し置いて、RPAが特別注目されるということは、このようなIT全体の最適化が遅れているということの裏返しだという仮説も成り立ちます。
日本のITの課題
実際に日本は諸外国に比べITのコスト効率は低く、ITの仕組み（アーキテクチャ）は柔軟性を欠く構造となっているように感じます。ここでいうコスト効率とは、IT投資の絶対額ではなく、同じコストを投資して得られる成果が乏しいということを指しています。全業界平均売上比1%程度のIT投資である日本に比べて、欧米企業はその数倍の3~4%になることも珍しくなく、絶対額は諸外国の方が上です※3。理由として考えられるものを、RPAが活用される背景とも照らしながら以下に挙げて解説します。
1. ベンダー依存
日本企業が諸外国、特に米国に比べてベンダーへのIT人材依存度が高いことは有名です。IPA（独立行政法人情報処理推進機構）が2017年に行った調査※4によると、日本では約100万人のIT人材の3/4にあたる約75万人がベンダー側に所属するのに対して、米国では419万人のうち、実に6.5割にあたる274万人のIT人材がユーザー企業側に所属することが分かっています。
ベンダーの要員に払う費用には人件費だけでなくベンダーの販管費や利益も含まれ、ベンダーのリスク用のバッファや人員の学習コスト（お客様のビジネスプロセスや現行システムに習熟するまでの時間）に対してもお金を払うため、ベンダー依存はITコストを高止まりさせます。当然ながら、ベンダー側にITコストを最適化させる積極的な動機はなく、ベンダー側の理由で習熟した人が入れ替わってしまったりする上、構築した新たなプロセスやシステムのノウハウが自社内に残らないために、IT企画や保守をベンダーに依存せざるを得ず、それがまたさらにベンダー依存を招く悪循環を引き起こします。
2. ビジネスアナリシス（業務分析）とプロジェクトマネジメント力の欠如
1980年代から、常にITプロジェクトの失敗要因※5の上位は技術的な問題ではなく業務側からの要求の曖昧さや矛盾、頻繁な変更という業務要因が多くを占めます。また業務要因と並んで指摘されるのがプロジェクトマネジメントの欠如です。この傾向は数十年変わっていません。ITプロジェクトの成功には自社の経営目標と現状のビジネスプロセスを熟知し、適切な要求を定義できる人材や、一定の権限や社内人脈を持って適切な社内コミュニケーションとプロジェクトマネジメントを推進する人材が必要になります。
しかし、今のITをとりまく環境において自社で全てのIT人材を賄うことは現実的でないこともあります。特定のソリューションの専門家は内部で育てるより外部に頼った方が効率的な場合もあり、業務分析やプロジェクトマネジメントに必要な人材も、大きな取り組みの際に必要となる十分な数の要員を常に抱えておくことは難しいのが現実です。ですが、上述したような基幹となる一定数のIT人材が取り組みの中心にいて、はじめて外部の人材も有効に活用することが可能になります。そうなれば今よりもITプロジェクトは効果的に運営されるようになり、必然的にITコストも下がることになります。
3. カオス化したアーキテクチャ
アーキテクチャが過度に複雑化する最大の要因は組織のサイロ化で、部門ごとに同じような目的にも関わらず異なるシステムを別々に導入してしまい、単純に無駄なコストを払うばかりか、保守運用を請け負うIT部門も仕様の異なるシステムを管理するために多大なコストを払うことになります。
複雑化し、機能重複だらけのシステムアーキテクチャはそれ自体がITコスト増を招きますが、問題はそれだけではありません。あちらこちらに乱立したシステムのインターフェースを全て自動化するには限界があるため、システムからシステムへの情報の移行を人手（マニュアル）で行う必要が生じ、これがRPAの活躍余地になるのです。
このようなマニュアルインターフェースによる情報移行の一例が、顧客や製品の基本情報、いわゆる「マスタ」のメンテナンスです。導入した社内のシステム（主にパッケージソフトウェア）のそれぞれに存在する「従業員マスタ」や「顧客マスタ」のマスタ間の整合性をとるだけで大変な作業となります。
近年はこれらの分散するマスタデータの整合性を確保する「MDM（マスターデータマネジメント）」という考え方も出てきました。本来の「システム内で汎用的に使われる情報を一元管理することで管理コストを減らす」というマスタデータの思想よりも、分散・整合管理を前提とした管理手法が必要になっているのが、企業システムの現状となっています。
アーキテクチャ設計の哲学の一つに「正規化」があります。同じものは重複して持つのでなく、可能な限り一元的に管理してアーキテクチャ全体で活用するという考え方です。しかし多くの会社ではそのようにはなっていません。お恥ずかしながら弊社も基幹システムと勤怠システムのそれぞれに案件マスタがあり、同じデータを人力でシステム間の転記を行っており、次のシステム更改に向けた論点の一つとなっています。
多くの企業を見ていると、アーキテクチャのカオス化する一つの要因にパッケージソフトウェアへの依存があると感じます。確かにパッケージソフトウェアはスクラッチ開発と違い、ゼロから物を考える必要がないため迅速、低コストなシステム開発に寄与します。一方で社内に複数のパッケージソフトウェアがあることはこのようなマスタの重複をはじめ、無駄な機能や情報の重複を引き起こします。もちろんパッケージソフトウェアに過度な改修を行うと、システムの更新や機能変更の際に大きな改修費がかかり、結局コスト増に招くことになります。
このような企業内のシステムの構成を最適化する考え方を「エンタープライズアーキテクチャ（＝EA）」と呼びますが、現状のカオス化したアーキテクチャを見直すにはEAに基づいて現行のシステム構成を可視化し、より最適なシステム構成の在り方に再構成していく活動が必要になります。
このような活動を行うには、各システムのユーザーとなる業務部門をはじめ多くの関係者を巻き込む必要があり、強いリーダーシップが不可欠です。ここまで述べたようなベンダー依存やビジネスプロセスへの理解不足に悩むIT部門では、そのような活動を推進することが難しいのが現実です。
4. 柔軟性の低いソリューションの採用
RPAが活用される背景には、業務システムで自動化した際にすぐに業務要求が変わってしまい改修が必要になってしまうために、システム化のコストに見合わないと判断されることが多いことも関係しています。このような業務は常に一定の割合で発生するため、そこにRPAを利用するのは合理的だとは思います。
業務要求が頻繁に変わる領域としては、各部門や製品・サービス別の売上を集計する事業管理や、ユーザーからの問い合わせやサポート依頼に対応するユーザーサポート業務などが挙げられます。このような業務は集計軸が変わってしまったり、新たな製品やサービスが常に追加されるため、それらに柔軟に対応するためにはシステム化して頻繁に改修するのではなく、エクセルやアクセスといったツールを使って管理している会社も多いようです。
もっとも、RPA以外のシステム化ソリューションがみな柔軟性を欠くというわけではありません。売上管理といった事業管理帳票であればBIツールと呼ばれるソリューション群を使えば、データーベースから一定の自由度を持って情報を取得し帳票にまとめることができます。またユーザーサポートの業務であれば、業務フローの記述手法を使って処理を定義することで迅速に進捗管理や複数担当者（部門）間の業務指示をやりとりするシステムを組み上げることができるBPMS（Business Process Management Suite/System）や超高速開発ツールと言われるツール群があります。
これらのツールはもともと開発コストと期間を減らし、柔軟な仕様変更に対応するために開発されてきた経緯があります。最近は非常に安く提供されるツールも増えてきましたし、一部にオープンソースのツールも出てきています。
冒頭に述べたようにRPAというツールの持つ脆弱性を考えると、このようなツールを活用することも選択肢ではありますが、日本におけるこれらのツールの市場はあまり大きくはありません。
5. その他の理由
その他にもITがうまく活用されずユーザーがRPAなどに着目するのにはさまざまな背景があります。ある会社の事例では、営業担当者は受注した案件をエクセルの帳票に記入し、営業事務担当者に渡し、営業事務担当者はこのエクセルをシステムに入力するという業務を行っています。このようなエクセルからシステムに情報を「コピー＆ペースト」して入力する仕事はRPA化の対象となる業務の典型例です。
しかし、よく考えれば営業担当者が直接案件情報をシステムに入力すれば済む話です。なぜこのような仕組みになっているか営業事務の担当者に聞いたところ「システムのユーザビリティが悪く、営業が頻繁に間違った入力をしてしまいトラブルになるので、営業事務担当者が代替している」とのことでした。
このケースではシステムを使いやすいものにして営業担当者に入力を任せることができれば、営業事務担当者の仕事は丸ごと不要になる上、受注処理のリードタイムも大幅に削減できます。もちろん、システムを改修するまでの一時期を乗り切るためにRPAを使うのは正解と言えるとは思いますが、実際には現行の仕組みのままRPAだけを導入してしまい、業務の在り方そのものにはメスが入らなないケースの方が多いように思います（また１～４で述べたように簡単なシステム改修でも時間やコストがかかりすぎてしまうことも要因の一つでしょう）。
最適なシステムアーキテクチャが設計されていればRPAはいらない？
ここまでRPAを念頭において日本のIT課題を振り返ってきました。「なぜ今、RPAなのか」と言われると、業務の電子化が急速に進む一方で、その狭間でしっかりステークホルダーを巻き込むことができず、効率性と柔軟性に劣るシステムアーキテクチャとなってしまっていることが背景として見てとれます。結果システムとシステム、システムと業務の隙間に膨大な自動化ができない電子的なインターフェースが存在し、それがRPAの活躍余地となっています。
あるアパレル大手の会社ではEPRなどの複数のパッケージが混在したシステムアーキテクチャとなっていましたが、これを見直し、経理・財務などの基幹となる部分にはパッケージソフトウェアを使う一方、商品管理などの要求が頻繁に変わる業務システムには開発支援ツールを使ったスクラッチ開発を組み合わせる適材適所なアーキテクチャに切り替えました。外部ベンダーへのブラックボックス化を排除し、使われない無駄な機能の排除や機能重複の削減を行ったこの取り組みの効果は驚くべきもので、開発費で8割以上、運用費でも6割以上のコスト削減を達成したそうです。また、このような改革により単なるコスト削減だけではなく業務部門からの変更要求に迅速に対応することも可能になったそうです。このような広い視野での自動化の取り組みを推進する立場であれば、その着目はRPAのみにとどまることはなく、多くのソリューションをバランスよく考えることができるようになると考えられます。
大切なのは二つの手段の両立
もちろんRPAよりシステム化を優先するには限度があります。システム機能や情報エンティティの重複を完全に排除した“完璧なシステムアーキテクチャ”を作ることは不可能と言って良いでしょう。かつては「論理的には可能」ということでそういうことを目指したプロジェクトもありましたが、そのほとんどは失敗に終わっています。複雑な業務の構造を完璧に読み解き、論理的に整合されたアーキテクチャを組むことが極めて難しい上、そのような複雑なアーキテクチャは時間をかけて設計している間に外部環境が変わり、意味をなさないものになってしまうからです。現在のような変化が早い環境では完璧を求めるよりも「だいたいこんな感じ」で迅速にシステムを稼動させ、細かいことは後から整合性を確保していく方が合理的と言われます。
またそのような“完璧な”アーキテクチャでは、システムの一部に何かトラブルが生じた際に連鎖的にアーキテクチャを構成する全てのシステムに影響を及ぼし業務の継続性に重大な事態を引き起こしてしまうため、現在のシステムアーキテクチャの設計ではシステム間の連携を意図的に切り離す“疎結合” （対義語は“密結合”）とする考え方も推奨されています。
このようなことを考えるとシステムアーキテクチャにおける完璧な最適性はある種の夢の世界であり、ある程度の不完全性は意図的に許容することが必要だと言えます。
そうである以上、要求から漏れた自動化余地のある箇所にRPAのような操作自動化ツールを活躍する余地は残ります。したがってRPAが有用なツールであることは間違いなく、このレポートの意図はRPAの活用を否定することではありません。
大切なのは最適なアーキテクチャを模索する努力とRPAを使って迅速に効率化を成し遂げることは両立できる手段であり、あくまでも前者の努力があって初めて、後者も本当に活用できるという認識を持つことです。例えるならば生活習慣病のようなもので、このような疾病はあくまでも食事の改善や適度な運動など長期的な生活改善が“主”ですが、その過程で症状を抑えるために一時的に投薬などが必要な局面もあります。RPAは良く効く薬だとは思いますが、日々の生活改善を怠っても良いというものではありません。
RPAが使える局面
内製力を高め、システムの全体アーキテクチャを最適化すればするほどRPAの活躍余地は減ります。その中でも以下のようなケースについてはRPAを活用する余地は残ります。
- システム化やアーキテクチャの見直しが進むまでの一時的措置
- （ITコストを下げても）システム化ではROIが出ない
- すぐに業務が変わり現時点で要求が確立できない
- よく知る業務を自動化することでユーザーのITリテラシを上げる
個人的にはRPAを活用した業務自動化の考え方はシステム化の要求を確立する際のステップとよく似ていると感じます。あるアウトプットを前提として、インプットとなる情報を整理し、それらのインプットをどのようなアルゴリズム（処理フロー）で加工するのかしっかりツールに対して設定していくからです。このような作業はITに不慣れなユーザーの基本的なデジタルリテラシを高める上では有用だと感じます。
RPAは使えるツールですが、本来行うべきは最適なシステムアーキテクチャを構築することと、そのようなことを可能にするIT人材の育成に励むことが主で、RPAはその隙間を埋めるためのツールだということも理解して活用してほしいと考えます。
