“ツールありき”でRPAを考えるのではほとんど何も身につかない

──今後RPAはどのように進化していくと見ていますか。

大石：　まずロボットの使い方やロボットとの関係性が変わってくるはずです。現在は、多くのベンダーやコンサルティングファームなどが、RPAを新しい商材と捉えて1つのシステムとして提供し、導入や運用サポートをしています。この場合、顧客はあくまでシステム利用者であり、RPAそのものと業務は分断した状態ですね。

それが、やがてRPA無くしては業務が進まないほど浸透していくと、業務とRPAというのは不可分な存在となりほぼ一体化するでしょう。そして業務を構成する粒度が大きい場合にはAIとの連携も進み、ロボットと言うよりは主要システムそのもののようになることでしょう。元Google本社副社長をつとめられた村上憲郎さんは、人間の相棒としての「バトラー（執事）」のような存在になるとおっしゃっています。ここまで来ると、あまりに当たり前となったRPAという言葉自体がなくなるのかもしれませんね。本来、RPAツールがどれかということは重要ではないという理解が進んで、サービス的に何ができるのかで選ぶようになるでしょう。

この点について少し踏み込んで説明すると、「これからは英語の時代だ。英語を習わなければ」という論調は多く聞きますよね。私もこの意見には総論賛成です。しかし、「じゃぁ、英語を習おうか」となったとき、いきなり英会話学校のパンフレットを持ち出して、どこの学校がいいのか議論をしているとしたら明らかにおかしいですよね？

RPAという言葉やRPAツールそのものにこだわって議論するのもまったく同じで、その先のRPAで何がしたいのかという目的がない人にとっては、どの学校に行っても、つまりどのようなRPAツールを使おうとも身につくものは多くないのだと思います。

もちろん、英語にしても趣味で学んでいるのであればそれでも問題はないのですが、仕事として限られた時間と予算の中で結果を出さなければならないとするのであれば、まず考えるべきは

• 英語を学ぶ目的と期待する効果
• そもそもの英語の利用シーン
• いつまでにどの程度のスキルが必要か。

ということだと思います。これをRPAに当てはめてみてもまったく同じなわけです。目的も無しにツールを選ぶというのは失敗の原因になりかねないということがおわかりいただけるのではないでしょうか。

RPAの未来は、業務とRPAとが不可分な存在になる

──これからRPAの導入を進める際のポイントはどこにあるのでしょうか。

大石：　基本的に個人ではなく組織としての活動となりますので、目的と期待効果は組織で共有すべきです。ただ、その示し方がROIに紐づくような〇〇時間の削減というものだけでは不十分と思いますし、〇〇時間削減した時間を、具体的に何に振り分け、どの様な成果を上げる（業務KPI）かといった表現にならないところが、まだまだブームとしての危うさかと思っています。

ただ、RPAブーム以前のイシュードリブンの時代とは違い、RPAを生かすためのイシュー探しという雰囲気の中では、なかなかブームの波にあらがうのもタフなことかなと思います。

RPAエンジニアリングとしては、この問題についてもユーザー様自らがRPAの先を見つけられるような頭と情報の整理を支援するプログラムを外部のパートナーとともに開発し、WIRM（ウィルム）という方法論にまとめました。パイロット段階ですので、事例としてご協力いただける有志のお客様を探している状況ではあります。

※収益性：（売上ーコスト） / 投下資源 ※知的生産性：分母（時間投入資源）は一定で、分子（業務成果の質）を向上させる生産性

私が目指すのもRPAを仕事の現場に浸透させることです。「RPAブームもあったよね」で終わるようなことは絶対に避けたいですね。

──そうした未来に向けたRPAエンジニアリングの使命はどこにあると考えますか。

大石：　まずはとにかく、RPAを使う人にどのようなものか興味を抱いてもらい、理解してもらい、そして使ってもらってメリットを感じてもらうことが重要だと思っています。例えばユーザー企業の情報システム部門で、RPAを紹介したところ“ロボットでシステム管理もできるんじゃないかな？”と積極的にRPAを活用するようになることもあります。

このように、現場で使いながら良さを実感してもらえるような活動を拡大していくことが我々の使命であると肝に銘じています。iPhoneだって、始めに機能ありきではなく、それを使う人々が育ててきたことで今の姿になってきていますよね。

そうした前提のうえで、RPAエンジニアの育成・派遣と各種RPAソリューションの保守運用まで含めてワンストップで提供するというコアビジネスを進めていきます。ここで我々のこだわりを主張させていただくと、 「RPAエンジニア」というのは、いわゆる「システムエンジニア」とは別の領域の専門家となります。

本来は紛らわしいので言葉を変えるべきなのですが、私どもが定義するRPAエンジニアというのは「RPAツールを使えるSE」ではありません。それは、RPAが社会に根付く過程で新しく生まれる職種だと捉えています。結果的にSEがその役割を負うこともあり得るでしょうけれど、フルスタックのスキルとしては、対象業務の知識も必須となってきます。

それは単に業務フローを知っているという意味ではなく、その手順が何のために存在しており、前後のプロセスにどういう影響を与えるかといったところまでを判断・設計できるスキルです。つまり、RPAエンジニアとなり得る人材のメインターゲットは、実際に業務を行っている業務部門の方々なのです。

我々としては、そうした業務に精通した方々、非エンジニアの方々に、業務遂行のための新しいスキルを身に着けてもらうという意図で「RPAエンジニア」という言葉を使っています。

RPAを導入するということは、ITプロジェクトではなく、ビジネスプロジェクトなのだということをロンドン・スクール・オブ・エコノミクス教授レスリー・ウィルコックス氏はおっしゃっており、私も同意見です。ただし、ビジネス部門が中心になり実施すべきとは言っても、そもそも業務自体が担当業務部門のみの関与で回っているわけではありません。時にはその基盤を支えるIT部門の力を借りる部分もあるでしょう。

要は、役割分担が必要なのですが、その範囲と分岐点を明確に示せていない点に課題があると見ています。RPAエンジニアが少ない現状では、RPAにおいてもITや外部のベンダーが積極的に関与せざるを得ず、境界線自体をあいまいにしてしまっているというのが現実なのです。こうした課題解決に少しでも貢献することが、RPAエンジニアリングの大きな使命の1つであると認識しています。

まだRPAはどの製品でもソフトウェアとして完璧ではない部分があるので、それに起因したトラブルに対する回避方法やナレッジも提供していますし、より広くRPAを使ってもらうためのコンテンツの充実もパートナーとともに進めています。

そうした活動が一定の目標に達した暁には、RPAを用いたまったく新しい事業の創出も手がけていきたいです。企業内の仕事にとどまらず、日本の社会全体をもっと便利にもっと快適にできる鍵の一つがRPA──つまりロボットであると私は信じています。

──本日はありがとうございました。