世の中は数年前からRPA(ロボティック・プロセス・オートメーション)が非常に注目を集めています。当ブログではVBScriptやVBAといった「枯れた」技術ばかり取り上げていますが、たまには目新しい話題にも触れておこうと思います。
始めに
このブログにアクセスされた方のなかには、RPAの導入を検討している最中の方もいるかも知れません。
RPAでどこどこの会社や自治体が何千人分の業務を自動化したとか、耳障りの良いニュースも多いですが、日常的に社内の事務作業を自動化したり効率化させている社内SEの立場から言えば、RPAしか自動化、効率化する選択肢がない業務は非常に少ないです。
よって、今回はRPAの各セールスポイントに対して、IT技術者としての実感を列挙していこうと思います。
まずはRPAとは？という部分をおさらいしましょう。
RPAの基本的な特徴
RPAの特徴としては、パソコンのマウスやキーボードで人が操作する動きをすべて記録させ、自由に呼び出せます。
また、クリックなどのマウス操作は位置を座標として指示し実行させることも出来ますし、操作対象アプリケーションのウィンドウやボタンなどをオブジェクトとしてシステム的に識別して、ターゲットの座標に関係無く実行させることも出来ます。
アプリケーションのテキストボックスに指定した文字を入力させることも出来ますし、特定のテキストボックスに入っている文字列をいくつかの方法で取得することも出来ます。
また、RPAで指示された一連の処理内で、条件分岐をさせることも出来ますし、繰り返し処理を入れることも出来ます。さらに変数なども使用可能です。
精度の問題はありますが、OCR機能も持っており、本来テキストデータとして扱えない画像データから文字データを判別して取得することも可能です。
また、プログラミングができる場合は、特定のプログラミング言語を用いて、RPAの機能を補完するようなオリジナルの処理も作れます。
これらの機能を駆使することで、人間がパソコンで行っていたすべての作業をRPAに置き換えることが可能になりました。
次にRPAのセールスポイントを見てみましょう。
どんな定型作業を自動化出来る
まずは一番のセールスポイントである「定型作業の自動化」ですが、前述しましたがRPAでしか自動化に対応できないケースというのは非常に少ないです。
例えばMS OfficeのVBAでも、作業を自動化するための様々な機能をプログラミングで作成することが出来ます。
- データベースに接続してデータを取得する
- 集計した表を印刷しやすいように体裁を整える
- CSVファイル等の外部ファイルにデータを出力する
- 宛先リストなどを元にメールを送信する
- インターネット上のウェブサイトからデータを取得する
- Windowsをシャットダウンしたり、別のソフトを起動する
- ASPサービス等が提供しているシステム連携用APIを実行する
‥など。
RPAの活用例などを見ていても、上記のようなVBAなどの機能で実装できるレベルでの自動化が多いです。
例えば、横浜市が共同実験と称してNTTデータの「WinActor」を導入して、大きな効果をあげたというレポートが公開されています。
この横浜市が公開している報告書を見るとわかりますが、RPAで自動化した作業もVBAレベルで実装できる程度のものばかりです。そもそも元の作業自体もどうなの？？という内容ですし、世の中を賑わすRPAの効果の実態として興味深く読ませてもらいました。
横浜市の例でもそうですが、企業のパソコンであれば、Officeも大抵はインストールされているでしょうし、VBAでも自動化出来る作業をわざわざ高い投資をして、RPAで構築しなくても…っと思ってしまいます。
VBAはプログラミング言語であり、プログラミングの知識が必要になります。RPAとはそこが違うと思われている方も居るかと思いますが、その辺りは別項で解説します。
本当にRPAじゃないと自動化出来ない作業例
ほとんどの事務作業はRPAを使わなくても自動化出来ると書きましたが、RPAじゃないとどうしようも出来ないケースはあります。
他システム連携機能が弱いパッケージ製品とのシステム連携
RPAの特徴が活かされるケースと言えば、異なるシステム間を跨いだシステム連携です。
近年の傾向としては、各社内業務に合わせてシステムをスクラッチで作るのではなく、基幹系システムであればSAPなどのERPを、顧客管理システムであればSalesforceの様なCRMといったように出来合いのシステムを業務毎に選択して利用するという形態が増えてきました。
その結果、ベンダーの異なるシステムが社内に乱立し、そのシステム間のデータを同期させる様なシステム連携を人力で行わざるを得ない状況に陥るケースも発生します。
▪️人力連携例
- 自社の基幹システム内に持っている顧客データが追加される度にCRM内の顧客登録画面から手動で登録
- ECサイトで受注した受注データを自社の基幹システムの受注画面から手動で登録
大企業のユーザーをターゲットにしたパッケージのシステムであれば、他システム連携を行うための機能があらかじめ実装されており、提供されているAPIやデータのインポートやエクスポート機能を駆使して別のシステムと連携出来るケースも多いですが、中小企業をターゲットにした安価なパッケージのシステムの場合、上記の様な他システム連携で利用できる機能が無かったり、存在はしていても使いづらかったりします。
また、システム連携用の機能が提供されていても、例えばAPIですと、そのAPIを何らかのプログラミング言語で呼び出す処理を作る必要があります。データのインポートやエクスポートによる連携でも、出力したり取り込み対象のCSVファイルの定義をシステム間で統一したり、インポートするファイルを作成する処理や、エクスポートするファイルを取り組む処理を別システム側で作る必要があり、やはりプログラミング等のシステム開発関連の知識や技術が必要になります。
この様に、
- 利用しているシステムにシステム連携用の機能が提供されていない。
- システム連携を実装するための知識や技術がない。
といった理由でシステム間の連携を人手を介して実施している様なケースであれば(特に前者)、その人が実施している作業をまるっとRPAに置き換えることが出来ます。
この辺りはRPAでしか対応できないケースです。
プログラミング知識が無くても簡単に自動化出来る
これも大きなセールスポイントです。
RPAでは、パソコンで人が実施する作業を記録させたり手順を登録して、それを実行し続けます。
その作業の記録や登録をする際には、プログラミングの様に、プログラムの文字列をひたすら画面に入力していくものではなく、RPAソフト上のシナリオ(作業手順)作成画面内で、マウスとキーボードを操作しRPAソフトが提供している各機能を選択して作業手順を順番に作っていきます。
別のもので例えるなら、当ブログの記事でも時々出てくるSQLとMS Accessのクエリーの関係に似ています。
データベースは基本的にSQLを使って操作しますが、このSQLは文字列で指定します。プログラミング言語のひとつです。所謂「CUI」の世界です。
かたやクエリーは内部的にはSQLを生成していますが、マウスでドラッグandドロップしながら作ります。所謂「GUI」での操作になり、データベースを扱う敷居を大きく下げてくれますが、使いこなそうとする場合は、データベースの知識も求められてきます。
RPAの販促活動や営業活動では、製品紹介のデモンストレーションを受けることもありますが、シナリオ作成を馴れたデモンストレーターが実施すると、なんだかとっても簡単に見えてきて、プログラミング経験やシステム開発の知識がない人が「これなら自分にもできそうだ」と感じます。
ただ、製品のデモンストレーターが即興で作るシナリオは当然簡単な内容ですし、実際の業務を切り出してシナリオを作るとなると、チョチョイと操作するだけでは作れません。
実際に業務を切り出してシナリオを作るには、単純にパソコン内で人が実施している作業を順次実行させるだけではなく、特定の条件毎に作業内容を分岐させる必要があったり、ひとつ前の作業に戻ってそれを特定回数繰り返すことが必要になったりします。
プログラミングでいう「アルゴリズム」です。
プログラミング経験がない人がRPAを習得しようとして最初に躓くのが、シナリオを作る際に、条件分岐や繰り返し構文といったアルゴリズム的な発想を必要とされるところです。
例えば前項で紹介した他システム連携をRPAで実装する場合の実装例で考えてみましょう。
- 基幹システムに追加または更新された顧客データを、都度基幹システムが定期的にCSVファイルに出力する処理があるとします。※出力するデータに区分などを設け、追加分が更新分かを区別出来るようにしておく。
- RPAでは定期的にシナリオが実行され、CSVファイルが出力しているかをチェックし、出力されていたら、そのCSVファイルを全行取り込みます。※RPAが持っているCSVファイルの取り込み機能を実行。
- 読み込んだCSVデータをRPA内部で保持しつつ、RPAはCRMのログイン画面を呼び出し、決められた認証情報を元にログインします。
- CRMは顧客の新規登録画面と顧客検索及び顧客情報変更画面はメニュー画面内の別ボタンで分離しており、新規登録画面はメニューから直接遷移、顧客情報変更画面はメニューから顧客検索画面に遷移した後、顧客を検索してから顧客情報変更画面に遷移できるものとします。
- 【条件分岐】RPAで内部的に保持しているCSVデータを一行目からチェックし、追加行か更新行かを判定し、追加行なら顧客の新規登録画面に遷移して対象行のデータを画面内の入力項目にセットする処理を実行し登録ボタン押下。更新行なら顧客検索画面に遷移し、顧客を検索した後顧客情報変更画面に遷移し対象行のデータを画面内の入力項目にセットし更新ボタンを押下。
- 【繰り返し構文】メニュー画面に戻り、RPAの内部的に保持しているCSVデータを次の行に移動させ、最終行の処理が終わるまで、項番5と6の処理を繰り返す。
いかがでしたでしょうか？
いざRPAでシナリオを実装しようとすると、条件分岐やら繰り返し構文といった制御構文も使うことになり、アルゴリズムの知識も必要になることが理解して頂けたかと思います。
確かにノンプログラミングでRPAのシナリオは作れますが、アルゴリズムに関する基本的な知識は必要です。
RPAはプログラミングスキルが無くても作業の自動化が出来る有益なツールではありますが、「誰でも簡単に」は間違いなので、導入する場合は自社内にRPAを習得出来る能力のある人材が居るかどうかをしっかり確認してから進めるようにしてほしいです。
既存の社内システムに手を加えずに自動化出来る
どこの会社でも業務で使用するシステムがあり、そのシステムを使用して行う各作業をより効率化、自動化させようとした場合、以前の選択肢としては、そのシステムがパッケージの場合、別のより良い製品に移行したり、そのシステムがスクラッチで作られたものであれば、システム開発会社がシステム改修を施すというものでした。
近年RPAが広まったことで、「既存システムを変えないままRPAで効率化、自動化をする」という選択肢が生まれました。
システムを改修したり、新しいパッケージのシステムを導入するとなった場合、ある程度の大きな費用が発生し、システム会社との調整や社内調整などの手間も掛かります。
RPAを駆使することで、システム改修やシステムの入れ換えを行うことなく業務の効率化や自動化が出来るのであれば、充分なメリットだと言えますが、デメリットも存在します。
業務システムを新しく導入する場合、一般的には最新のクライアント環境(使用するPCのOSやブラウザのバージョン)で動かすことを想定して作られますし、サーバー環境(サーバOSや各ミドルウェアのバージョン)もベンダーのサポートが長く受けれるようになるべく新しい世代のものを使います。
システムの導入から時間が経ち、クライアントのOSやブラウザの世代が2世代や3世代ぐらい進んでくると、それに合わせてサーバ環境も古くなってきて、「そろそろシステムもリプレースしないと…」といった空気になり、ユーザー側で溜め込んでいるシステム改善要望も新システムの機能要件に加えながら、システムリプレースプロジェクトがスタートします。
RPAがあれば現行のシステムを見直すことなく、非効率な作業や不完全なシステム間の連携を解消出来ます。
そうすると、古いシステムをリプレースするのではなく、RPAで補修をしながら使い続ける選択肢が出てきます。
その場合、古いシステムが延命され、非効率な業務フローがRPAに踏襲され生き延びていく可能性が高いです。
システムのリプレースはある種の「デトックス」だと考えています。
システムを長年使い続けることで、業務が変わりシステムの足りない機能を補完するために、いびつな手作業が発生したり、導入初期には問題なかったシステムのレスポンスもデータが大幅に増加したり、ユーザーが増加したことでどんどん悪化してきたり、システムを使用するクライアントの環境が新しくなっていき、互換性の確保が怪しくなり、動かない端末が出てきたりと、色々と問題が出てくる様になります。
スクラッチで作ったシステムであれば、定期的にシステム改修を実施しながら都度問題を解消していきますが、どこかで根本的な部分を見直さないと問題が解消できないタイミングが来ます。
システムのリプレースとなれば、問題部分を根本から解消するために、既存の業務を見直して、システムの仕様に合わせて作られた非効率な人的業務は、既存の業務が効率化されるような機能にシステムの仕様を再設計し、システムのレスポンスは今後数年データが増え続けて、クライアントが増え続けても耐えることが出来るように設計が見直されます。新しくなったクライアントの環境に合わせてシステムの動作環境も設定されます。サーバ側の実行環境も新しいOSやミドルで動くように構築され、ベンダーのサポート終了に悩まされることも当分無くなります。
[システムを作る]→[運用しながら改善する]→[システムが陳腐化する]→[リプレイスする]
これが業務システムを運用する場合の健全なサイクルだと考えます。RPAが加わることでこのサイクルが壊れ、以下のようになります。
[システムを作る]→[運用しながら改善する]→[システムが陳腐化する]→[RPAで補完する]→[RPAで補完する]→[RPAで補完する]→・・・・・
最終的には元のシステムの上に、RPAが何層にもわたって補完した処理を形成し、人が行う作業もRPAが補完する前提の手順で構築され、複雑に入り組みすぎて元のシステムのリプレイスが非常に困難になる恐れがでてきます。
よって、既存のシステムに手を加えずに業務の効率化、自動化が行えるということは、目先の問題解消には大いに役立つかと思いますが、節度を持った利用が望ましいと思います。
RPAのデメリットに関するネットの嘘
今回RPAのデメリットについてもネットで検索してみましたが、検索上位にくる記事では、大抵以下のような内容でした。
- 業務がブラックボックス化する
- 業務が停止する恐れがある
- セキュリティホールになる
- 野良ロボットが発生する
ただ、これらのデメリットは、順調に導入できた前提で、それ以降に発生する可能性のある問題ですし、ちゃんとロボットを管理して業務内容を管理できれば発生しないとも言えます。
要はメリットばかりアピールしても信憑性に欠けるので、一見それっぽい無難なデメリットを提示して、本当のデメリットを隠蔽している様にも感じます。勘繰り過ぎかも知れませんが…。
まとめ
RPA自体は人間のパソコン上での作業のほとんどをエミュレートしてくれて、適切に利用すれば非常に便利なツールであることには変わりはありません。
しかし、RPAを使わなくても作業の効率化や自動化を行える選択肢は色々と存在します。
効率化や自動化対象の業務が存在した場合、その業務自体を無くすか簡略化出来ないか？既存の業務システムを改修することは出来ないか？その場合は作業コストと改修費用のバランスはどうか？その業務に適合したパッケージのシステムを導入してはどうか？VBAなどで簡易ツールを作ることで対応できないか？VBAのツールで対応した場合に懸念はあるか？RPAで対応する場合は一時的な対応とするか、永続的にRPAに処理をさせるのか？と言うように、複数の選択肢を並列で列挙して、RPAで対応することが最良の選択であると根拠を持って説明出来るとこまで精査をした上で適用していくような慎重さが必要だと考えます。
くれぐれも「せっかくRPAを導入したから、どんな業務もRPAに置き換えていこう」という発想で、スクラッチ開発やVBAでの内製といった様々な手段の検討をしないまま盲目的にRPAで業務を自動化していくことが無いよう注意が必要です。
IT業界でも様々なブームは過去にも起こっています。以前はブロックチェーン、ビックデータ、サーバのクラウド化、ASP…など。
そのなかでも昨今のRPAブームは大規模であり、メディアに取りざたされる機会も多く、一般社会もAIと混同したり、情報を発信する側も敢えてAIと混同するようなミスリードを誘う内容のアピールをしているのも目につきます。
AIはまだまだ発展途上ですが、すでに人類の様々な分野で活用されており、今後も大きな可能性を秘めている技術です。
かたやRPAはただ定型作業を自動化するためのツールでしか無いので、まったく別ものの技術です。
ビックウェーブに乗ってみたくなる気持ちも理解は出来ますが、IT技術者やITに関わるお仕事をされている方々には、何卒冷静に、論理的に、この大きな波を見定めてもらいたいと切に願います。
ではでは、今回も読んで頂きありがとうございました。
関連記事
やっぱりプログラミングも勉強してみようと思ったあなたはこの記事をどうぞ↓
