二極化が進む企業の自動化推進

はじめに

「働き方改革」という言葉が世間の注目の的となり、仮想労働者・デジタルレイバーという言葉が定義され、RPA元年とも言われた2016年から早くも7年の月日が経ちました。

この業界にずっと身を置いてきた立場として、様々なクライアントからご相談も頂く中で最近特によく感じるのは「企業によって自動化推進の二極化が進んできたな」という事です。

これは、単純に予算や人が足りないという問題であればまだ良いのですが、問題はそこではなく、進もうとしている方向性にあります。

つまり二極化が進んでいる理由は、端的に言ってしまうと、自動化推進において「その組織がどの山を登ろうとしているのか？」という点にあります。

そもそも登るべき山を間違えている場合、人とリソースをどれだけ投下しても、本来目指すべき目的地に辿り着く事はなく、むしろ悪い方向にどんどん向かう一方になります。

この業界における力学上の問題もあり、この罠にはまってしまう企業も少なくないため、RPA元年と言われた2016年から7年が経ち、生成AIというピースも出てきた今、改めて自動化推進がどうあるべきかについて考えていきたいと思います。

二極化する企業の自動化推進

ではまず初めに、企業の自動化推進がどう二極化しているのかについてですが、その最も顕著な違いはRPAの捉え方にあります。

具体的には「RPA一辺倒で自動化を推進する企業」と「RPAはあくまで手段の一つと捉えて自動化を推進する企業」の二極化が進んでいます。

つまり、前者の企業は「自動化推進＝RPA」という形でRPAが全面に出ており、後者の企業はRPAはあくまで手段の一つとして、効率的な自動化推進の形、ガートナーの戦略的テクノロジのトップトレンドにもなった、HyperAutomationの世界観を目指している企業になります。

これは、リソースが潤沢にない小さい企業が前者、大手企業が後者という事ではなく、リープフロッグ的に既にHyperAutomationの世界観を意識して自動化を進めている小さい企業もあれば、大手でリソースを投下して大量にRPAのロボットを作り続けている企業もあります。

そして、どちらかというと一番問題なのは、RPAを主眼に自動化推進を続けている大手企業になります。

RPAとはそもそも何だったのか？

ここで改めて考えたいのは、「RPAとはそもそも何だったのか？」という話です。

RPAとは「Robotic Process Automation」の略であり、これは要するに何か特定のツールや技術の話ではなく、あくまで思想の話になります。

つまり、深刻化する労働力不足の解消や、つまらない労働を人間がしなくても良い社会の実現に向けて、これまで人間がやっていた業務を仮想労働者(デジタルレイバー)に担わせ、更に、仮想労働者のレベルを上げていき、その生産性を高めていく取り組みになります。

RPA元年と言われた当時は、仮想労働者を部下にして仕事を担わせていくといった世界観の話や、RPAのレベルを定型業務の自動化(クラス1)、部分的な非定型業務の自動化(クラス2)、意思決定も含む自律的な自動化(クラス3)に分けた進化論の話なども活発に議論されていました。

しかしいつの間にか、「RPA」と聞くと、多くの人の頭には、UiPathや WinActor, BizRoboといった、いわゆるツールのイメージが定着するようになってしまいました。

ここは一定マーケットを作るために仕方がなかったという面もありますが、「RPAを進めたければこのパッケージを買って下さい(この製品を買えばRPAが簡単に進められますよ)」というツールベンダーのマーケティングにも功罪があると思います。

本来であれば、組織の自動化環境をどう最適な形で作っていくかという戦略的な議論が企業内でなされるべき局面で、とりあえずRPAツール(パッケージ)を買って、目先の業務を自動化するロボットをどんどん作りましょうという、非常に単純化された話になってしまいました。

この流れの名残りもあり、未だに自動化推進を「UiPathやWinActorといったRPAツールでロボットを作る事」と捉えている企業が少なくない状態となっています。

その一方で、RPAツールの活用はあくまで自動化の手段の一つとして捉え、RPAツールの特性を見極めた上で、効率的な自動化環境の構築へと舵を切り、HyperAutomationの世界観を目指す企業との二極化が進んでいます。

つまり、進み方の進度の問題であれば良いのですが、そもそも進んでいる方向が違うため、軌道修正をしない限り、この二極化は更に広がっていく一方という事になります。

※「RPA」=「UiPathやWinActorといったRPAツール」というイメージがあまりにも定着してしまい、多くの方のイメージをここで再度書き換えるのは難しいため、以下RPAという言葉は「RPAツール」の意味で使います。

自動化推進においてRPAでロボットを作るのが最も筋が悪い理由

さて、ではRPA一辺倒で自動化を推進するのがなぜ問題なのか？というと、端的に言ってしまえば、RPAでの自動化は、自動化の手段として最も筋が悪いからです。

もう少し正しい言い方をすると、RPAでのGUI操作の自動化は最も筋が悪いという事になります。

RPAでの自動化というと、多くの場合は、人間がそれまでやっていたシステムの画面操作をRPAに覚えさせて実行させる(UI要素を操作させる)という形になると思います。しかし、基本的には、GUIの機械的な操作は本来最終手段であるべきです。

というのも、そもそもGUIは人間が使いやすいように設計されたUIであり、機械が触る物として想定されてはいないからです。

RPAで最も問題になるのが、RPAに操作させていたシステムのUIが変わる事で、システムのバージョンアップ等でUIが変わった場合はRPAは即時エラーになるため、その都度RPAの作り直しが必要になります。

社内システムであれば、画面変更やバージョンアップアップのタイミングが事前にわかる事も多く、事前に対処する事もできますが、SaaS全盛の今の時代において、社外システムの画面は、よりユーザーが使いやすいようにと、任意のタイミングでアップデートされるため、その都度RPAがエラーとなってしまいます。

社外システムが顕著ではありますが、いずれにしてもGUIを操作している以上、システムの画面変更とRPAの改修のイタチごっこになる状態を避けることはできません。

またGUIは、画面描画が遅れたり、そもそも画面が固まったりする事があるため、なかなかRPAの操作自体も安定しません。

RPAは一般的なシステム開発に比べ、開発のコストは安いけれども、運用保守のコストは高いといわれる理由はこのGUI操作にあります。

言ってしまえば、RPAでGUIを操作するロボットを大量に作るということは、いつ爆発するかわからない小さな時限爆弾を大量に仕込んでいるという事に近しい状態になります。

ではRPAが悪いのかというとそうではなく、あくまで道具は使い様なので、RPAというツールの特性を踏まえた上でどう扱っていくかが重要になるという事です。

ただ、原則として、RPAによるGUI操作は、システム改修の影響を常に受け続ける宿命にあるため、自動化の実現において積極的に活用したい手段ではありません。

つまり、避けられるのであれば基本的には避けたほうが良く、自動化の検討においては最終手段の位置付けになります。

基本方針として目指すべきは脱RPA

ここまでの議論を受けて、それでは「RPAは今すぐ全て廃止すべきじゃないか？」という話をされる方がたまにいらっしゃるのですが、それはあまりにも短絡的で、自動化に対する解像度が低いと言わざるを得ません。ここは大事な所なのでまた後で戻ってきたいと思います。

ただ、RPAの特性を踏まえた上で取るべきスタンスは、RPAを適材適所で上手く使いながらも、基本方針としては脱RPAを目指していくという事になります。

もっと具体的に言ってしまえば、組織の自動化推進において、RPAによるGUI操作をどれだけ最小化できるかが勝負になるという事です。

RPAによるGUI操作はあくまで最終手段であり、RPAでこれまでスコープにしてきた自動化領域において、優先的に検討すべき主要なオプションは、①API活用, ②DB接続, ③ETL活用, ④BI活用になります。

以下、順番に説明していきます。

①API活用

API活用はある種当たり前の話で、対向システムにAPIがあるなら、GUI操作ではなくちゃんとAPIを使いましょうという話です。

GUIが人間が操作するために作られたUIであるように、APIはシステム的に操作するために作られた仕組みであるため、自動化においての正しい入り口はそもそもこちらだという事です。

APIであれば画面変更の影響も受けない上に、バージョンアップの際も後方互換性が保たれている事が多いので、自動化の頑強性が大きく上がります。

また画面描画のタイミングを合わせながらGUIを順番に操作を実施していく場合に比べて、APIは安定性も高い上に処理も速く、実装も非常にシンプルになるので、安定性や処理性能に加え、保守性も大きく向上します。

自動化の検討においては、対向システムが決まった段階で「これってAPI使えないんだっけ？」と確認するのがまず第一手になります。

最近のSaaSはAPIが提供されている事も多く、APIがあるにも関わらず、RPAでGUI操作を実装するというのはあまりにも非効率であると言えます。

APIが使える場合は、RPAでAPIをコールして自動化するという形でも良いですし、対象の自動化業務がAPIで閉じれる範囲なのであれば、iPaaSを使ってしまうというのも一つでしょう。

APIの仕様を意識せずとも、直感的に使えるコネクタが提供されている物も多いので、より簡単に実装できると思います。

システム操作をGUIではなくAPIで対応できると、開発と運用保守にかかる工数で言えば、ざっくり1/5～1/10ぐらいになります。

GUIファーストではなく、APIファーストへの移行が、自動化推進における必須事項になります。

②DB接続

続いてはDB接続です。

これも要するに、GUI操作を避けたいというモチベーションにおける、APIとは別の方法になりますが、結局システムの裏にいるのはデータベースなので、GUI経由で対象のデータを抽出するのではなく、SQLでデータベースから直接データを取得するという事になります。

特にこれは対象のデータ量が大きい場合やGUI操作での条件選択が多い場合に有効で、SQL文で条件を一度組んでしまえば、高速かつ安定的にデータを取得できます。

実装もAPIと同様に非常に簡素になり、ほとんどのRPAツールは、ODBCやJDBC接続でSQLでデータを取得する方法を標準で備えているので、APIと並んでこちらも有力なオプションになります。

ただ、各システムの管轄者の立場としては、基本的にDB接続はして欲しくないので、標準機能として提供されているAPIとは違い、アクセス権限を開放してもらえるかという事がDB接続における大きな論点になります。

不特定多数の人に公開するのはなかなか難しい側面はあるので、この辺りの技術をよくわかっている人達(CoE開発等)での利用に限定しながらも、自動化環境の構築としては、積極的にDB接続を活用していくのが良いと思います。

GUIでの複数の画面の操作やデータの結合などの諸々の処理がSQL一発で終わる事もあるので、APIと同様に、開発と運用保守が非常に容易になります。

また、こちらもAPI同様にシステムの画面変更の影響を受けないため、自動化の頑強性も大きく向上します。

Write系は厳しいと思いますが、参照のみであればそれほどシステムに負担をかける事もないので、積極的に検討したいオプションになります。

③ETL活用

続いてETL活用ですが、これはより組織的な取り組みの話になります。

例えば、特定のシステムの同じデータを使う業務が多く、そのデータを取得するために多くの人がRPAでのGUI操作を実装するのであれば、データを裏側から取っておいて、誰もが使える場所(共有ストレージ等)に置いておきましょうという事です。

ETLツールとしては、Infomatica, Asteria, DataSpiderなど色々とありますが、重要なのはツールではないので、場合によっては、バッチ処理のプログラムを個別で組んでしまっても良いと思います。

つまり、多くの人が業務で使いたいデータを、RPAのGUI経由で取得させるのではなく、共有フォルダ等にCSVなどの形式で置いておく形を取る事で、各自動化担当者はGUIを操作するRPAを開発して、個別にデータを取得する必要がなくなるという事です。

DB接続の所で、DBへのアクセス権を解放するのはなかなか難しいと言いましたが、ETLで用意するという形であれば、組織として統制が取れるので、どちらかといえばこちらの形が望ましいと思います。

自動化CoEの観点で言えば、ETLツールを使って、主要なデータへ容易にアクセスできる環境を作るというのは、効率的かつ頑強な自動化環境の構築に必須であると言えます。

④BI活用

続いてBI活用です。

RPAの自動化業務である種最もよくあるのが、特定のシステムからデータを取得して、Excelなどにデータを転記・整形して、参照用に関係者に展開するというものです。

しかし、これはそもそも基本的にはBIで対処すべき領域になります。わざわざ取得したデータをExcelに転記してまとめる必要はなく、BIでデータソースと繋いでレポートを作成し、関係者へ共有しておけば、必要なタイミングでいつでも最新のデータが参照できます。

これは②DB接続と③ETL活用とも関連がある所なのですが、BIで直接、対向システムのデータベースを参照できるのであれば、GUI操作を回避できますし、BIで直接DBに接続させる事が難しいという場合は、ETL活用で共有フォルダなどに連携しておいたCSV等をBIで読み込むという形を取ることで、こちらもGUI操作を回避できます。

GUI操作の回避のメリットに加えて、BIを使うと、データの加工・整形処理の実装が非常に楽になるという利点もあります。

PowerQuery等を使った事がある人はわかると思いますが、BIはデータの加工・整形に必要な標準機能をライブラリのような形で備えていますが、RPAは基本的にはプログラム的に処理していく形になるため、BIと同じ処理をRPAでやろうとするとかなり骨が折れます。

BIであれば、型変換・名称変更・テーブル結合・不要列の削除など、数ステップ程度で終わるような処理も、RPAでやろうとすると個別にループを回す必要が出てきたりと一気に可読性が低くなる上に、処理も遅くなります。

いわゆるレポート作成的な業務の自動化検討の際は、まずはBI化できないかを検討するべきでしょう。

ここまでいくつかの例を紹介しましたが、いずれにしても、自動化検討においてRPAが1stオプションになる事はないという事です。

　

さて、ここまで自動化検討の際に、RPAが1stオプションにはならないという事を書いてきましたが、ではRPAは全て廃止すべきなのか？というとそう単純な話ではないという点について、言及しておきたいと思います。

基本的には、GUI操作を回避して、APIやDB接続で処理すべきというのは間違いないのですが、そもそもAPIを備えていたり、DB接続ができるシステムというのは現状それほど多くはありません。

例えばAPIに関して言えば、社内で利用しているシステムを棚卸してみると、APIを備えているのはおそらく1-2割程度、良くて3割という所ではないでしょうか。

自動化を検討する際は、APIを積極的に利用すべきではあるものの、まだまだAPIで処理できるシステムは多くないという事です。

これはサービス事業者の立場になって考えてみれば必然で、あくまでサービスを利用する大半はユーザー(人間)であるため、サービス事業者はGUIを優先して開発し、APIは必要に応じて、後から少しずつ整備していくという流れになります。

サービス事業者としては、そもそも多くのユーザーが使えないと意味がないので、GUIを先に整備するのは当然で、APIで対応出来る範囲は、GUIに比べて限られるという事は、特に業務系の領域では今後もしばらくは変わらないでしょう。

API等が利用できる所は積極的にAPIを利用して、極力RPAでのGUI操作は回避しつつも、GUI操作しか自動化の手段がないというケースにおいては、RPAの特性(メリデメ)を踏まえた上で、RPAで自動化を実装していくという形になります。

このように、一足飛びで脱RPAとはなりませんが、組織としては様々な自動化ソリューションを適材適所で組み合わせながら、中長期的には脱RPAを目指し、効率性と頑強性を備えた自動化環境を構築していくという事が重要になります。

RPA推進から本格的なAutomation推進へ移行するためにまずやるべき事

それでは、RPA一辺倒の状態から、本格的なAutomation推進へ移行するためにまずやるべき事をいくつかピックアップしたいと思います。

まず最初にまずやるべき事は「RPA推進/RPA-CoE」という組織名や活動名から「RPA」という言葉を外し、「Automation推進/Automation-CoE」という名称に変える事です。

名前に「RPA」という言葉が入っている以上、組織内のメンバーや会社の他の組織からも「ここはRPAをやる組織なんだな」という形で認知されてしまいます。結果的にRPAでロボットを作る事が目的になり、RPA一辺倒に進んでしまうという事です。

一方で、「RPA」という名前は全面に出さずに「Automation」という形に昇華させることで、要するに目的は自動化であり、RPAもその手段の一つでしかないという形で関係者の意識が変わります。

こうして、業務自動化検討の際に「RPAでできるかできないか？」の頭だったところを「どうすれば最も効率よく自動化できるか？」という意識へ切り替えていく事ができます。

今回は先に提示してしまいましたが、どうすれば最も効率よく自動化できるか？という問いを立てる事ができれば、RPAによるGUI操作は最終手段になるというのは自然と導き出される解になります。

続いて実施すべきは、自動化アーキテクチャの整理・可視化です。

どうすれば最も効率よく自動化できるかという視点で、社内で利用しているシステムと自動化ソリューションをマッピングして行きます。APIが使える箇所やDB接続ができる箇所、そもそもBIで処理してしまった方が良い箇所やETLでデータ連携したほうが良い箇所などをここで整理し、可視化していきます。

その中で、ここはどうしてもRPAに頼らざるを得ないという箇所も当然でてきますが、この自動化アーキテクチャの整理の過程でRPAでGUI操作させる箇所を最小化する事ができます。

ここで整理した自動化アーキテクチャをAutomationCoEの資産(アセット)とし、チーム内で共通認識化する事で、この業務の場合はこのパターンで自動化するのが最も効率が良いという意思決定を下す事ができるようになります。

RPAによるロボット開発は目的にはなり得ないので、業務自動化という目的において、RPAも含めた自動化ソリューションを適切な形で使いこなし、HyperAutomationの世界を目指していくという事が重要になります。

RPAでロボットを作るという取り組みのアクセルだけをどれだけ踏んでも、HyperAutomationの世界に到達する事はありません。登るべき山を間違えているので、むしろ遠ざかっていくというのが正しいと言えます。

今後更に進むべき方向性

それでは、HyperAutomationを意識したAutomation推進に移行できたとして、今後更に進むべき方向性について検討していきたいと思います。

この検討においては、RPAという概念が出てきた当初の話に立ち返るのが重要になります。

では、そもそもRPAはなんだったかというと、UiPathやWinActorといったツールの話ではなく、思想の話でした。

つまり、人間がやっていたオペレーションを仮想労働者・デジタルレイバーに担わせ、更にそのレベルを上げていく事で、対応可能な範囲を広げ、生産性も上げていくという思想そのものになります。

そもそもRPAで目指すべきなのは、RPAの進化論でも言及した、クラス3の自律的な自動化の領域、つまり、AIエージェントに該当する領域になります。

定型業務の自動化がメインだった時期が長く続きましたが、ここに生成AIというピースが出てきたので、ここから本格的なクラス3の世界に突入します。

生成AIはまだまだリアクティブな使われ方(聞かれたら応答する)が多く、言ってしまえば指示待ち人間のような状態であるとも言えます。

一方で、優秀な人材がどういう人材なのかというと、いわゆる指示待ち人間ではなく、自分から動いて提案できる人材、もっと言えば、相手の要望を一歩先回りして、相手が言語化できていない、気付いていないニーズをも満たせる人材であると言えます。

つまり、ここからDX推進やAutomation推進において勝負になるのは、どれだけ強いAIエージェントを作れるかという事になると思います。

これはそもそも、ユーザーが使いやすいIT環境を整えるという方向性ではなく、AIエージェントが自律的に必要な動きをした上で従業員をサポートしてくれる、特定領域によっては自ら意思決定しながら対応していくという世界観になります。

おそらくこれから最も強い企業は、部下のほとんどがAIエージェントだという企業になるのでないでしょうか。従業員は全員が経営者・企画担当者のような位置付けで、優秀な仮想労働者であるAIエージェントを使いながら業務を回していくという形になれば、人間を採用・育成・マネジメントをしながらオペレーションを回すという企業では到底太刀打ちできなくなります。

あとはどのくらいの時間軸でこのシフトが起こるかという事ですが、1年前の状況と今の状態を比較すると、想定以上に早く来る可能性があります。

先進的な企業は既に動き出していますが、AGIはいわゆるゼロイチの話ではないので、地に足のついたAutomationの推進を進めながらも、今からこちらの領域にも取り組んでおくというのも重要な意思決定になるのではないでしょうか。

益々重要になるソリューションアーキテクトの存在

ここまで、RPA一辺倒の状態からAutomation推進への昇華、そしてAIエージェントを作れるかが勝負になるという話を書いてきましたが、ここで益々重要になるのがソリューションアーキテクトというロールの存在です。

ここまでの議論を聞いて、なんとなく進むべき方向性がわかったとしても、これを具体的に手を動かすイメージまで落とし込めなければ話は前に進みません。

「DX推進をやれ」「AIを使って業務を効率化しろ」とだけ、トップが声高に言っても、実際にHowがわかっている人間がいなければ何も進まないのと同じ話です。

ここの推進力の中核を担うのがソリューションアーキテクトという存在で、具体的な人材要件としては以下になります。

<ソリューションアーキテクトの人材要件>

• そもそもプログラミングができる(プロとしての開発経験がある)
• 開発だけでなく、運用保守の実経験がある
• RPAやBI, クラウド, API, SQLなどの技術スタックを理解しており、実際に使える
• AIのバックグラウンドがあり、自身で具体的な実装ができる
• 高いレベルのソフトスキルを保持している(ステークホルダーとの円滑なコミュニケーション能力, ロジカルシンキング, ファシリテーション, ドキュメンテーション能力等)

実態としては、こういった人材が市場になかなかいないというのが非常に悩ましいポイントになります。

いわゆるITコンサルタントは上流のコンセプトレベルまでは語れるものの、実際にプログラミングの経験はなかったり、手を動かす事はできないという人が多いのが実態になります。

従来型の大きなV字プロセスが、アジャイル型になっていく世界においては早期にプロトタイプ・デモを見せて関係者を巻き込んでいけるかが勝負になってくるので、パワーポイントで机上のコンセプトの話しかできない人の価値はどんどん下がっていきます。言ってしまえば、それっぽい話を言うだけなのであればChatGPTのほうが上手いので、ChatGPTによって最も価値が下がっていくのはこのレイヤーの人達であるとも言えます。

一方で、ソリューションアーキテクトは、プログラミングができてAIに詳しければ良いかというと当然不十分で、ビジネスオーナー・業務部門・IT部門・協力開発会社等の様々なステークホルダーとのコミュニケーション・調整能力が必要なため、プロのコンサルレベルのソフトスキルが必要になります。

論点や構造を整理する能力、関係者の期待値をコントロールしながらプロジェクトを進める能力、加えて、関係者の認識を共通化できるドキュメンテーション能力が必要になります。これはエンジニアとして優秀かどうかというより、ビジネススキルの面になります。

こういった人材は非常に市場価値が高く、どの企業からも求められているものの、特定の企業でこういった人材の育成パスがなかなかないというのが大きな課題になります。

つまり、ソフトスキルも高くテクノロジーもわかっているという人がそもそも稀有なので、育成できる人があまりおらず、ITコンサルティングファームで、ソフトスキルは高いが具体的な実装レベルまではよくわかっていないという側に偏るか、SIerやテック企業で、テクノロジーは詳しいが、各ステークホルダーの中心に立てるようなソフトスキルは持ち合わせていないというどちらかの状態が多くなってしまいます。

もちろん各スキルを分解してそれぞれを担える人でチームを編成するという形も一つですが、いずれにしてもディレクションできる人材は必要で、この人材は全員と会話できる必要があるため、結局のところ上記のソリューションアーキテクトに近い人材要件になります。

多くの企業では、このソリューションアーキテクトロールに該当する人がいないために、自動化推進がRPA一辺倒のような状態になってしまっています。

HyperAutomationの世界観の実現、またAIファーストな自動化の実現においては、このソリューションアーキテクトロールをどう確保していくか、またはチームでどう編成していくかという事が、自動化推進における最重要課題の一つであるとも言えます。

結局市民開発はどうなのか？

最後に、RPA元年と言われた2016年から、ずっと平行線のままのテーマについて触れておきたいと思います。

それは「結局市民開発はどうなのか？」という点についてです。

この話は単純で、誰でも簡単に開発できますという形で市民開発を推したい(ユーザーの母数を増やしたい)RPAベンダー側の主張と、誰でも簡単にできると言ったのに、実際にやってみると思ったより難しいじゃないかという企業側の期待値とのギャップの話になります。

結論としては、筋の良い人がしっかりと時間を投下すれば当然習得できるし、そうでないなら難しいという事になります。

ここは人によりけりのため定量化する事はできず、筋が良くて業務的な余裕もあり1ヶ月で習得できる人もいれば、筋があまり良くない上に、業務が忙しくて時間が取れず、1年経ってもほとんど習得できていないという人もいます。

ただ、誰でも簡単にできるのではあれば、RPAエンジニアという職種は存在しないわけですが、未だにRPAエンジニアの求人が出ている事が、誰でも簡単にできるわけではないという事の証左になっているのではないかと思います。

市民開発を考える上で、まず前提として押さえておく必要があるのは、RPAベンダーとしてはRPA開発者の母数を増やしたいインセンティブがあるという事です。

これはRPAベンダーとして当然のスタンスで、RPAベンダーの売上はライセンスであるため、RPAライセンスを買ってくれる人が増える事、つまり、市民開発によってユーザーが増えるのが一番有難いからです。

営業マンにその商品を買うべきかを相談してはいけないのと同じように、RPAベンダーに市民開発をやるべきかどうかの真意を聞くのはそもそも間違っています。

では、RPAツールのライセンスが売上ではない、コンサルティングファームの人達の目線はどうかというと、基本的に市民開発をお薦めすることはまずありません。特定のツール活用にインセンティブがない客観的な立場としては、市民開発はやめておいたほうが良い、少なくとも安易に手を出すべきではないというのが大方の総意となっています。

ちなみに、RPAベンダー側としても、内心としては市民開発はやめた方が良いと思っている方も少なくなく、ビジネスモデル上のジレンマを抱えている方も多いのが実態です。

では、なぜ市民開発はやめておいたほうが良いのかと言うと、その理由は端的に2つで、「市民開発には先がない」という点と、「RPA一辺倒が加速するから」という点になります。

市民開発には先がない理由

市民開発をやるかどうかの検討において、ほとんどのケースでは「業務ユーザーでもRPAが簡単に作れるのか？」という事が論点にされています。

しかし、論点にすべきはそこではなく、ここで真に問うべきは「最終的にどこを目指すのか？」という事になります。

これも、目指すべきはRPA一辺倒ではなく、Automation推進(HyperAutomationの世界観)であるという事を考えれば見えてきます。

つまり、技術スタックとしてRPAを習得するというだけでは当然不十分で、APIやSQLが使える事に加え, BIやクラウド、更には生成AIのような新しい技術を常にキャッチアップして身に付けていく必要があるという事です。

今後、更に新しい技術もどんどん出てくるため、身に付けた技術の賞味期限は益々短くなっていきます。

要するに市民開発における問題は、RPAの習得に苦労している市民開発者に、こういった新しい技術領域の習得を継続的に課していけるかどうか、そのイメージができているかという事です。

「RPAはなんとか苦労して作ってもらえるようになったけど、APIやSQLに加えて、BIやクラウド, ましてやAIなどの新しい技術を習得してもらうイメージは正直湧かない・・」というのであれば、市民開発には先がないと言わざるを得ないでしょう。

そもそも市民開発という言葉に問題があり、結局はプロレベルの人材を育成できるかどうかという事がポイントになります。

IT部門にしかテクノロジーのわかっている人材がいないとなかなかDXが進まないため、業務部門でもDXを推進できる人材を育成するという方針は、選択肢として非常に重要だと思います。

しかし、これは幅広の市民開発で進めるのではなく、選抜型の戦略人材として育成するアプローチを取るべきであり、育成のロードマップとしては、RPAだけでなく、その他の自動化ソリューション(BIやETL, クラウド等)に加え, AIも含めた各種技術領域の習得を最初からスコープに入れておく必要があります。

これは要するに、市民開発ではなく、プロを育成するという事です。

とりあえずライセンスを配ってみて、興味のある人にRPAをまず作ってもらうというのは楽なのですが、「RPAを学んでもらった後どうするんですか？」という問いに明確な回答が出せないのであれば、安易な市民開発はやめておいたほうが良いでしょう。

そもそもエンジニアの生産性は非線形なので、市民開発者が3日間かけて悩んでいたことをプロのエンジニアが数分で解決してしまうという事はよくあります。
関わっている母数が増える事は、押しなべて良いということではなく、重要なのは各人の習熟度の深さになります。

そもそも業務部門の人達が注力すべきはその本業であるため、ITで何ができるのかは理解しつつも、自分で作れる必要は必ずしもありません。

スマートフォンは使えれば良いのであって、スマートフォンを全員が作れるようになる必要はないからです。

「最終的にどこを目指すのか？」という事から、必要な人材要件を逆算で考えれば、幅広の市民開発を進めるのではなく、選抜型の人材育成で少数精鋭のプロを育成していくという形に帰着するのではないでしょうか。

市民開発でRPA一辺倒が加速する理由

市民開発のもう一つの問題は、「RPA一辺倒が加速する」という点です。

市民開発によって、RPA一辺倒が加速する理由には2つの側面があります。

まず、1つ目は市民開発者の側面です。

これは先ほども記載した通りですが、基本的には市民開発者が使えるのはRPAのみという状態になります。つまり、武器がRPAしかないので、業務自動化の検討において、打ち手がほぼRPAになります。

本来であれば、APIやSQLで処理すべき所、またはBIで可視化したり、ETLでデータ連携したほうが良い所も、基本的にRPAのGUIで力技で自動化しようとしてしまいます。

RPAという武器しか持っていない以上、こうなるのは当然仕方ないのですが、結果的にシステムのGUIを操作するロボットがどんどん増えるため、自動化の効率性と頑強性が低く、なかなか安定しない上に、常にシステム変更の影響を受けてしまうといった状態になります。

このように最終的にどこを目指すのかという事を踏まえた育成ではなく、RPAだけを幅広に教えてしまった場合、RPA一辺倒の状態がどんどん加速するという事態になります。

2つ目は自動化CoE(推進組織)の側面です。

よくあるケースとして、RPA-CoEとして手の付けやすいところからRPAでの自動化を進めて一定の成果を出した後、次にどうしようかという検討のフェーズに差し掛かります。

ここで本来注力すべきは、ソリューションの高度化及び、対象業務範囲の拡張の視点になります。

ソリューションに関しては既に述べてきた通り、RPA-CoEをAutomation-CoEに昇華させ、新しい技術領域を取り入れながら、自動化のレベルを上げていく、つまり、HyperAutomationの世界を目指していくという活動になります。

どうすればGUI操作を回避した効率的かつ頑強な自動化環境が作れるか、どうすれば仮想労働者のレベルを上げ、AIエージェントの実現に近づけるかなど、様々な論点を挙げながら、議論や各技術の習得を進めていく必要があります。

もう一つは対象業務範囲の拡張の視点です。これまではバックオフィスの業務自動化が中心だったけれど、フロントオフィスの領域へも自動化範囲を広げていけないか、個別業務の自動化ではなく、業務の集約化・標準化と組み合わせて部署横断業務の自動化を実現できないか、最もインパクトのある全社共通業務を自動化できないか、など、業務領域としても検討を進めていくべき論点は多くあります。

しかし、本来であればこうしたソリューションと業務の両視点での進化を図るべき場面で、RPA-CoEはそのままで市民開発へと舵を切ってしまうというケースがあります。

つまり、ソリューション・業務のレベルを上げていくために使うべきCoE組織の工数を市民開発者の育成や開発サポートに割り振ってしまうため、全体としての自動化レベルは低いまま、関係者の母数だけが増えてしまうという事です。

RPA以外の自動化ソリューションの利活用・整備が進んでいないため、依然として、組織としての武器はRPAでのGUI操作がメインのままCoE開発と市民開発を進めるため、RPA一辺倒の状態が更に加速するという事になります。

ここまでをまとめると、進めるべきは、RPA一辺倒の状態での幅広の市民開発の促進ではなく、HyperAutomationの世界観の実現を目指した自動化レベルの向上と、内製化を目指すのであれば、最終目的地を意識した選抜型人材(プロ人材)の育成になります。

どういった自動化の未来を描くのか、そしてその未来の実現のために、限られたリソースの選択と集中をどのように進めるのかという事がやはり重要になります。

まとめ

RPA元年と言われた2016年から早くも7年が経ち、生成AIという技術が出てきたこともあり、今後更にAutomation推進の潮目が変わり加速するフェーズに入る事になると思います。

各企業が思い描く自動化の姿の違いによって、既に二極化の芽がかなり見え始めているので、改めて今後の自社の自動化推進についてディスカッションする機会の一助になれば幸いです。