ポイント1：本格展開でつまずくのは、RPAツールのせいではない

―立石さんはTISで、顧客企業の基幹システム導入支援といったバックオフィス自動化に長年携わり、2年前からRPA導入支援にも取り組んでいるとうかがいました。現在RPAの導入を検討しているユーザーに、何か特徴的な動きがありますか。

立石朱城氏（サービス事業統括本部 エンタープライズソリューション事業部 アプリケーションテクノロジーソリューション部副部長）：　私がRPAと関わるようになった2016年当時、国内のRPAはようやく普及しだした段階で、問い合わせのほとんどは「自分たちの職場でやってみたい」という業務部門からでした。その後RPAの知名度が上がり、この1年で経営企画やIT企画が主導するケースが目立って増えました。トップダウンのミッションとして、最初から全社展開を念頭にご相談いただく流れに変わってきたのです。

そうした中、PoC（概念検証）からテスト運用に入ったものの、導入規模を拡大するフェーズで壁にぶつかるケースも出てきています。「現状のロボットのお守りに精一杯で、拡大まで手が回らない」「Aというツールでうまくいかないので、Bのツールに変えたい」といった声もよく聞かれるようになりました。

サービス事業統括本部 エンタープライズソリューション事業部 アプリケーションテクノロジーソリューション部副部長 立石朱城氏

―橘木さんは、ほぼRPA専任で、さまざまな業種のユーザーを支援中と聞きました。トップの肝いりで進める全面展開でも、思うように広がらないケースがあるのでしょうか。

橘木直也氏（同部主査）：　はい、順調なユーザーばかりではありません。テストの途中でツールの変更を検討する以外に「RPAは導入効果が出ない」と、早々に見切りをつけてしまう企業もあります。

RPAは決して万能ではなく、ツールごとに若干の得手不得手もあるので、変更や断念が一概に間違いとは言えません。ただ正直に申し上げると、これまで耳にしたツールへの不満の大半は「それをロボットのせいにするのはどうか」という内容でした（笑）。

―たしかに、作業だけでなく、つまずいた責任までロボット任せでは酷な気もしますが･･･。ともあれ、テスト段階とは別のツールに変えて本格展開に入り、着実に活用を広げている企業も少なくないようです。

立石：　ええ。たしかに「デスクトップ型のRPAツールで先行的なテストをし、全社展開の検討まで進んだところで、より本格的なサーバー型に移行する」というステップアップは、大いにありえます。

デスクトップ型RPAはPC1台から手っ取り早く導入できる半面、導入規模を拡大させるにあたっては、単に同じツールをバラまくこととなるため、効果が出る企業は限定的と考えます。ですから、本格展開に移るタイミングでツールを含めた見直しをすること自体は自然で合理的だと思います。

―では、プロジェクト途中で行き詰まった場合、打開策としてツールを変えるのは有効でしょうか。

橘木：　何かうまくいかなかったことが、ツールを変えて克服できるケースはごく限られていると考えてよいでしょう。ほとんどの場合、RPAツールの変更は大規模展開が現実化したことに伴う「結果的なもの」です。

もし現状で「ロボットのお守りに精一杯」なのであれば、それはおそらく「情報システム的な発想」が足りないのが原因です。たとえばIT部門の協力を得てロボットの管理方法をルール化し、エラー修正の際に手間がかからない実装を工夫するといったように、ツールを変えるよりも先に使い方を見直し、推進チームのメンバーを充実させることが大切です。

サービス事業統括本部 エンタープライズソリューション事業部 アプリケーションテクノロジーソリューション部 主査　橘木直也氏

ポイント2：本格展開へ軌道に乗せる起爆剤

―ツールの向き不向きを考える以前に、全社展開に耐えられる仕組みとチームをつくるべきということですね。そのノウハウがない企業にとっては難しそうですが、どのように進めればよいですか。

橘木：　仕組みづくり、チームづくりのプロセスは、その会社のRPA導入プロジェクトが「IT部門」「現場（事業部門）」「トップダウン（経営企画部門など）」のどこから始まったかによって変わります。RPA推進に対する社内全体の機運を高めていき、この三者が一体で動く仕組みを備えるのが理想的なチームのあり方です。

たとえば、最近多くみられるトップダウンでRPAを全社展開する場合は、ロボット化に向いている業務を現場からいくつか探しあてるまでが最初のハードルとなります。導入推進担当者がアンケートへの記入を各部署へ依頼するのが一般的でしょうが、できれば社内に顔が広く、取り組みに共感をもってもらえる人をキーマンに立てて業務部門に出向いてもらい、ターゲットとなる業務の掘り起こしに対面で協力を仰ぐのが効果的です。

ロボット化の向き不向きには、大きく2つの要素が関係してきます。1つは業務そのものの性質、つまり「業務の総時間」と「ロボット化できる割合」のかけ算で、どれだけの時間削減が見込めるかという問題です。

もう1つは、ターゲットとなる業務部門の「熱意」です。まだRPAというものになじみがない段階で、もし最初の挑戦が失敗に終わっても、効率化への強い意欲が現場にあれば“灯”が消えず、すぐに次を試すことができます。

―どのような業務をロボット化するかによっても、社内の関心は変わるかもしれませんね。

橘木：　やはり、社内的に通りがよく象徴的な成功事例が出ると、そこからが強いです。テスト段階における第1号のロボット化はおそらく、小さな作業で堅実に実績を出すと思いますが、導入２例目か３例目あたりで、ぜひ勝負に出てほしいと思います。

この段階で「年間数百時間単位」の人的リソース創出につながるロボット化が達成できれば社内にインパクトが与えられ、理解と浸透のスピードも速まります。単一部署の作業単体で数百時間の効果が難しければ、複数の部署で共通している作業をロボット化して横展開し、その合計をアピールするのがよいと思います。

ポイント3：「経営」「現場」「IT」のスクラムで、強いチームと仕組みをつくる

―トップダウンの観点から、全社展開に向けたチームや仕組みが生まれていく流れは分かりました。残る2つの部門から全社展開を目指す場合も、また異なったプロセスがあるということですか。

立石：　そうですね。ただいずれのルートをとるにしても、ロボットを全社展開させるフェーズでポイントとなるのは

• きちんとしたルールに則って安定的に運用したい「IT」
• 自分たちの目の前の業務を効率化させたい「現場」
• 全社的な導入効果を最大化したい「経営」

というそれぞれの利害が交錯していることです。これは部署を超えた連携という以上に、いずれも重要な3要素のバランスをとらなくてはならない点に難しさがあります。

社内の力だけで関係者をとりまとめるのは難しい場面もあるかと思います。社外の第三者であるわれわれを説明や説得に加えるなど、関係各所の間を取り持つ役回りで活用いただくことも、全社展開の促進を図る上では有効だと思います。

―部門をまたぐ問題としては「現場とIT部門の役割分担」が、よく話題に上りますね。

立石：　そうですね。両者の間で決めておくべきポイントがいくつかあります。ロボット化の対象業務の知識は当然現場がいちばん詳しく、運用のルールづくりはIT部門が得意とするところですが、ある程度のITリテラシーを要するロボットの実装やメンテナンスをどちらで担当するかは、導入した各社の実情によって変わります。

もし現場レベルで業務改善へのモチベーションが高ければ、ロボット化の「ターゲット選定」から「設計」「実装」「保守」にいたるまで、すべて事業部門が担う形が採れます。現場主導というRPA本来のコンセプトに忠実なパターンで、この場合IT部門は禁止事項などの「ルールを策定して周知」する、あるいは最初に「ツールの操作方法を指導」するといったサポートに回ることとなります。

反対に、業務改革への貢献に意欲的なIT部門がRPAを「社内営業」したいというケースもあり、この場合はルール策定や教育のほか、実装や保守もIT部門で引き受けることが考えられます。ロボット化する作業内容を把握するため、業務の観察やスタッフへのヒアリングに出向くIT担当者も珍しくありません。ただ、当事者意識を持ってもらうためにも、効率化したい業務の流れをフローチャートなどにまとめるのは、現場の担当者に任せたほうがよいかもしれません。

橘木：　業務部門のITリテラシーを正しく把握している企業は意外に多くないようで、RPAを運用する役割分担の検証に入ってから「ここまでできるのか」とIT部門が驚くこともあれば、その逆もありました。

テクノロジーをどこまでかみ砕いて提案すれば自社の現場に受け入れられるか、IT部門が正しい状況を把握するチャンスという意味でも、RPAの全社展開は重要な意義を持っているのではないでしょうか。

―ありがとうございます。このあと引き続き、IT部門・事業部門と経営サイドとの関係についても聞かせていただきます。

優れたRPA推進担当者への第一歩。知っておきたい3つのポイント――導入担当者にTISが伝えたいこと【後編】