RPAがブームになり、バックオフィス業務の自動化が各企業で進行しています。
その中でも、定型の作業だけでなく、人の判断を必要とするような複雑な業務についても自動化を実現できるRPA2.0が、次世代のRPAとして注目を集めています。

決まりきったPCの操作はロボットに任せてしまおうと考えるのは必然であり、それがRPAの推進を後押ししました。しかし、定型業務の自動化だけでは物足らない企業を中心に、業務担当者の経験や知識に依存していた業務に対しても臨機応変に対応できるRPA2.0が、多くの企業から支持されて来ています。
広範囲の業務に対しても自動化するためには、テンプレートに当てはめるだけではなく、AIなどを利用して様々なアプリケーションと連携して、自社の業務に最適なロボット開発をすることが、RPA2.0として求められています。

RPA2.0の特徴は以下の通りです。

①非定型な業務に対応できる
②適応出来る業務の範囲が広い
③現行の環境でそのまま使用できる
④ロボット同士の連携ができる
⑤メールデータなどの非構造化データを取り扱える
⑥複雑な条件分岐や、判断が行なえる
⑦いろんなアプリケーションと連携できる
⑧サーバでの集中監視が要らない
⑨最適な業務ごとのバックアップ体制が組める
⑩AIやIoTと連携できる
⑪拡張性がある　　・・・など

RPA2.0が世間に認知され導入が始まると、サービス向上や生産性アップで同業他社に打ち勝つために、自社に有利になるように業務に適したより高度なソフトウェアロボットを開発しようという機運が盛り上がり、ますます開発競争が激化していきます。
ソフトウェアロボットは、開発系のRPAツールを利用することでロボット開発の高度な知識がなくても、あらゆる企業や組織で割りと手軽に開発が出来るようになりました。
本来バックオフィス業務の効率化を目的にヒットしたRPAですが、デジタル労働者であるソフトウェアロボットに仕事を任せることで、あらゆる業務の作業効率と正確性が増すという期待で、フロント業務まで適用範囲を広げて開発が進んでいるようです。

企業の人材確保という観点で少子高齢化の問題を解決する最も有効な手段は、デジタル労働者であるソフトウェアロボットを有効活用することです。
65歳定年制をはじめとする継続雇用制度の導入で高齢者も労働力として期待されていますが、体力や健康の問題で長時間勤務が難しい人達でも、ロボットに仕事を代行させれば、担当者は、ロボットへの指示やアプトプットの確認など、比較的無理のない仕事で活躍できます。

また、会社内でしか作業できない仕事をロボットに任せることにより、育児に追われる社員でも在宅勤務が可能になるため、優秀な社員をつなぎとめることにも役立つでしょう。
そして、何より事業を拡大したいのに、人材不足でスタッフを補充できないという問題も、ロボットの増員で解決が可能です。

ほとんどの企業は、事業継続、あるいは事業拡大のために、多かれ少なかれ今後労働者としてソフトウェアロボットを活用していくことは間違いないでしょう。
むしろ、そうなると決まりきった仕事をロボットに任せるだけでなく、どれだけ多くの業務について、如何に効率的に作業できるロボットを開発していくかが、企業にとって生き残りの重要なポイントとなっていきます。

企業がソフトウェアロボットを活用していく時に重要なのは、ロボットはあくまでもツールとして導入するという姿勢です。
AIを搭載したロボットは人間の仕事を奪うという恐怖を与えるような風潮がありますが、ソフトウェアロボットは、現時点ではあくまでも業務を自動化するためのツールです。
よって、業務担当者が拒否反応を示さないように、ソフトウェアロボットは自分達の作業を楽にしてくれるツールだということを理解してもらい、業務を担当する現場の人達が自ら主体となって進めていくやり方が理想的です。

家庭でも、全自動洗濯機やお掃除ロボットは、主婦の家事を助けてくれる良いツールで、それにより時間的余裕が生まれ生活が豊かになってきました。今では、洗濯機のない時代が考えられないくらい一般家庭に普及しています。
それと同様に、業務担当者にとってもソフトウェアロボットは有益だという意識付けが必要です。

注意すべきは、業務改革という大義名分によって経営者がAIを搭載したロボットは万能だと誤解して、コンサルティング会社の提案のまま担当者を無視して、トップダウンでソフトウェアロボットを導入してしまう場合です。この場合、ソフトウェアロボットの中の動きはブラックボックス化され、何か障害があっても担当者にはわかりません。ロボットの開発を依頼した業者に頼まないと、業務は動かなくなり、最悪はそういった外部の会社に自社の重要業務の生命線を握られてしまうことにもなりかねません。

危険な面もあるロボットですが、ツールであることを前提に活用すれば、業務担当者の主導で導入することにより企業に大きく貢献します。自動車を運転するのと同様、優秀であるがゆえにソフトウェアロボットも使い方や運用方法を間違うとかなりリスクのあるツールであることを理解すべきです。
よって企業は、コストや、業務効率ばかり優先してトップダウンですべてをコンサルティング会社やRPAベンダー任せにするのではなく、危険でもあるが役立つツールとして業務を理解している現場の主導で、各担当も責任をもってソフトウェアロボットを導入することが、リスク管理をする上ではとても重要になります。

RPAが大ブームとなったおかげで、多くの企業でいろいろなRPAツールの導入が始まりました。
RPAへの期待が業務の自動化なのに、残念なことに多くのRPAツールはパターン化できる定型業務しか自動化できません。

RPAツールのGUI 機能により、自動化する仕組みを作るのは比較的簡単になりましたが、そのかわり自動化できる業務は限定されてしまいます。
これはRPAに限ったことではありませんが、開発容易性の向上は、適用できる範囲を制限されることとのトレードオフなので、すべての業務を自動化するには、やはり無理があります。

結果的に、RPAで自動化したい業務範囲と、RPAツールが提供できる自動化が可能な範囲の差が、 RPAを導入した企業の不満の原因になっているようです。
標準的なRPAツールは、分かりやすいGUI を使って、プログラミングなしで自動化の設定が 簡単に実現でき、その設定した内容はフローチャートのようにドキュメント化できます。
もちろん、こうしてビジュアルに設定できる方が、プログラミングが不得手な業務担当者としては抵抗なく業務自動化の設定ができます。
しかしながら、多くのRPAツールは、GUI によるマウス操作主体で設定できる自動化には限界があり、結果的に特定のスクリプト言語等を使用してカスタマイズしなければ、期待する業務の自動化ができないのが現状です。
ソフトウェアロボットは、パターン化できる決まりきった仕事しか自動化できないことを理解していればそれは仕方がないと諦めもつくのですが、定型のアルバイトでもできるレベルの業務であれば、コストや時間をかけてロボットを導入するメリットもかなり薄れてしまうのが実情のようです。

こうした問題が生まれた背景には、多くのRPAツールのベンダーが、他のツールと組み合わせて開発していたり、本来の機能とは別にかなり作り込んで構築したシステムを、さもRPAの成功事例のように記事広告にしているため、購入者がRPAツール単体でできることを拡大解釈して誤解したまま導入してしまうことも大きな要因となっているようです。

最近になって多くの企業がRPAの導入を始めたきっかけは、やはりメディア等で注目され、数多くの成功事例が世間で話題になってきたからでしょう。
実はPC の操作を自動化するツールは、数十年も前からありました。事実、RPAツールの多くはかなり以前から販売されていたもので、近年になってブームに乗っかりRPAというキーワードにアピール方法を変更してから、売れ始めたものがほとんどです。
よって、多くのRPAツールには特別先進的な機能の改良があったわけではなく、ブームが到来したおかげで売れていると言っても過言ではないでしょう。

ただ、企業の業務のロボット化の波は止められません。ここで後れをとれば、企業存亡の危機にもなりかねないからです。
多くの企業で、トップダウン的にRPAの導入が進められました。日本の大半の企業がそうであるように、とにかく失敗せず早く効果を得たいからと安心できるRPAツール、つまり実績のあるツール、メディアで多く目にするツール、そしてコンサルティング会社が推薦するツールが どんどん採用されました。

採用したツールが、期待通りの業務範囲で自社の業務自動化が実現できればよかったのですが、その多くがERPを導入したときと同じで、ソフトウェアの仕様に合わせてロボット化できるように業務フローを変更したり、一部分は自動化できず人による操作が残ったり、カスタマイズするために業者に依頼したり、あるいはプログラミング不要なはずなのに開発部分を加えたりしている企業がほとんどのようです。
こうなることは、RPAのツールベンダーからすれば当たり前で、むしろそれを前提に提案しているため、勝手に期待したユーザの進め方にも問題があるといえるでしょう。
RPAツールは、ソフトウェアロボットといえどもツールです。お掃除ロボットに洗濯を期待できないのと同様、自社で期待する業務が、そのツールの標準機能でどこまで自動化できるのかそれを購入前に見極めてツールを選定すべきです。
もちろん、予算にもよりますが、業務ごとに最適なツールを複数使い分け、他のアプリケーションと連携して使用するという考え方も有効な手段です。

2020 年より、小学校でもプログラミングが必修科目になる予定です。
マイクロソフト、Google、Facebookはじめ名だたる有名企業の創業者の多くは、プログラミングやコンピュータサイエンスの分野に長けていました。
コードを書くプログラマーではなかったもののアップルの創業者だったスティーブ・ジョブズ氏も、オバマ前大統領と同じように、すべての国民がプログラミングを学ぶべきだと主張していました。プログラミングできる技能が、一般教養として求められる時代になりました。
なぜでしょうか？
AI、IoT が話題になり、ビッグデータの取り扱いやセキュリティが重要になってくるにしたがって、ロボット社会でコミュニケーションを図るには、業種を問わずプログラミングできる技能が必要だからです。

今後、ますます重要性を増し、拡大を続けるであろうソフトウェアロボットの導入にあたり、他人任せでは、会社で働く人達の将来が心配です。
プログラムコードの記述は開発の専門家に任せてもよいのですが、自動化するときの手順や、例外処理の対処方法、セキュリティや運用まで、プログラミングをする上での常識やノウハウを、経営者から一般の業務担当者まで関係者全員が取得していれば、その企業に合った理想的なロボットの開発が期待できます。

さらに、プログラミング不要ということで流行ったRPAですが、プログラミングすることを許容するだけで、適用出来る業務の範囲が広がり、人材不足の対応や、業務拡大のメリットを最大限に享受できる可能性が増えていきます。

海外とのコミュニケーションに、英語が重要であるように、今後ますます増え続けるソフトウェアロボットに指示を与え、報告を受け、共に業務を遂行する仲間としてコミュニケーションを図るためには、プログラミング技能を全社員が身に付けていくことが、どの業種の企業にとってもたいへん有効な手段となります。

ロボットというと、マンガに出てくるように賢くて何でもできる印象がありますが、ここでいうソフトウェアロボットとAI（人工知能）は同義語ではありません。
ソフトウェアロボットとは、PC をはじめとしたコンピュータをプログラムされた内容に従ってさも自律的に動かすソフトウェアのことで、ヒト型のハードウェアに搭載されるのではなく、PC 等に導入されてRPAを実現するデジタル労働者のことです。
AIは、人と同じような知能を有しているように見えるソフトウェアで、人型のロボット等のソフトウェアに組み入れられている場合もありますが、一般的にはロボットと連携していたとしても、まったく別物です。
ソフトウェアロボットが、手の操作にあたるキーボードやマウスなどを制御するのに対し、AIは脳で行われる判断などの処理を司るイメージです。

AIも適用範囲が限られているものが多く、話題のディープラーニングを活用している自律型のAIであったとしても、現時点ではまだ全ての行動や思考を自律して行える汎用人工知能（AGI: artificial general intelligence） のレベルにまでは、至っておりません。
レイ・カーツワイル氏によって有名になったシンギュラリティ（技術的特異点）に人類が到達出来た時には、万能に近いAIが出現するかもしれません。

コグニティブが前提となっている将来のRPA3.0 では、RPAに予め搭載されたAIが、ソフトウェアロボット自身に指示を出し、人の制御に頼らず自律して対応するRPAが期待されています。
その頃には、ソフトウェアロボットの生産や修正も、ロボット自身が行なっているかもしれません。

いずれにせよ、現段階のRPAは、自身で思考できるわけではなく、あらかじめプログラミングしたソフトウェアが指示通りに動くだけです。
それゆえ、RPA2.0では、RPAツールが、個別に業務に適したAIと連携する方法でソフトウェアロボットを開発して、今まで人の判断が必要だった部分についても自動化します。
この部分をよく理解して最適な組み合わせを構築するためにも、一般教養としてのプログラミング知識や、AIリテラシーの向上が、経営層から一般社員に至るまで求められ重要となって来ます。

ソフトウェアロボットの導入効果として、顧客満足度の向上が挙げられます。
ロボットへの指示に間違いがなければ、ソフトウェアロボットは人間が操作するより早く的確に業務を遂行できます。
メディアで多く取り上げられた生命保険や宅配便の会社等で、チャットボットを利用したヘルプデスクのRPAの事例では、担当部門にロボットが導入され、実際のオペレータに交じってロボットが顧客に応対して、素早い対応と、オペレータの負荷軽減でかなり効果を上げています。
これは、顧客満足度の向上と同時に、応対に余裕ができたことによる担当部門の人達の満足度の向上の両方に効果が上がる良い例です。

通常顧客満足度を上げるためには、現場の担当者がハードワークを強いられ、担当部門の不満増大にもなりかねません。
この例では、弱いAIで代表されるルールエンジンを用いたチャットボットをRPAツールと連携して構築されています。以前より問題視されていたロボットが人間の仕事を奪うという心配は必要なく、このヘルプデスクの事例ではこれを導入することによって、現場の負荷軽減にも大きく貢献しているようです。
しかし、もし企業経営者の判断でこれをヘルプデスクごとアウトソーシングして、外部委託によってロボット化していたらどうでしょう。
人件費を中心としたコスト面の効率化はできるため、それなりの効果は見込めますが、ヘルプ業務でのノウハウは社内に蓄積できず、それが会社の発展にとってよいかどうかは判断が分かれるところです。
但し、このケースは、その業務を海外の人件費の安いBPO センターへアウトソーシングしてコスト削減する場合でも同じ事なので、必ずしもロボット化することが人の仕事を奪う原因とはいえません。けれども、RPAはもともとBPO センターの運営会社がコストメリットを出すために発展してきた歴史を知れば、ロボットが人の職場を脅かしているというのも事実ではあります。

RPAは、導入の仕方を間違わなければ、従来の顧客満足度を上げることができます。顧客満足度向上を優先すれば、コストと業務負荷を上げてしまうというトレードオフな関係ではなく、顧客満足度を上げながら、コストと業務負荷を下げ、社員の満足度も向上させることができるということが言えます。顧客も社員も経営者も三方満足する、これこそが、RPAのよい成功事例となります。

働き方改革を推進するためには、現在8 時間以上拘束されている定時の勤務時間について、ロボットに業務代行をさせることで、業務に費やす時間を短縮することが望まれます。
そのためには、制度の変更や在宅勤務ができるようにセキュリティ面で環境を整える必要などもあるでしょうが、そもそもロボットを導入すれば物理的に業務担当者は勤務時間の短縮が実現できるのでしょうか？

残念ながら、RPAを導入したおかげで、勤務時間が半分になりましたという事例はまだ聞こえて来ません。これは、会社全体で時短を目的とすることが、明確になっていないためでしょう。
どんなに業務効率がアップしても、企業の業務拡大を優先してしまっては、忙しいから増員したときと同じように、かえって仕事が増えてしまうかもしれません。

ここで重要なのは、ロボットを足らない人員の補充として採用するだけでなく、担当者の業務の一部の引継ぎ先として位置づけるということです。その際に、業務は引き継ぎますが、アルバイトを雇うときのように、責任は業務担当者に残すぐらいがよいでしょう。
そうすれば、ロボットをツールとして利用した担当者は、自分の仕事量が減って楽になるということで、そのまま業務で処理して出てきたアウトプットに責任を持ってくれます。そのように意識付けするには、業務担当者にロボット開発の時からメンバーとして参画してもらうことが重要です。
RPAツールによっては、PC 自動化をサーバからの指示で管理されているため、業務担当者の独断では動かせない場合もあります。管理方法は会社の方針によりますが、理想はシステム管理者に依存せず、担当者が利用しやすいソフトウェアロボットがよいでしょう。
たとえば、通勤ラッシュを避けるため、朝一にデータを集め処理しなければいけない業務は、ロボットに任せて出勤後に結果を確認できれば、時差出勤が可能になります。
緊急で夜中に見積作成が必要な場合や、インフルエンザで会社に出勤できないような場合など、ファイルサーバにアクセスするためにどうしても会社での仕事することが必要なケースでは、担当者からリモートでロボットに仕事を依頼できればどんなに楽でしょう。

そのために、導入するロボットは、PC が立ち上がっていなくても起動して、リモートで担当者自身が監視や制御ができることが理想です。
このあたりの機能があるかどうかも、RPAツールを選ぶときのポイントになります。

RPA（Robotic Process Automation）に似た言葉として、RDA（Robotic Desktop Automation）というキーワードがあります。これは、個別のPC にインストールして、マウスやキーボード操作を簡単に自動化できるもので、その多くは低価格ですが、スケジュールの機能がなかったり、リモートからの起動や監視ができなかったりします。業務担当者が手軽に作成できるのはよいのですが、簡単だからとむやみに担当レベルでジョブを作成してしまうと、会社としては管理が煩雑になり困るという悩みもあります。

ロボットに人の代わりをしてもらうのであれば、業務担当ごとにロボットを配置して役割分担することが必要になります。そして、担当業務を分担して連携したり、作業終了後にアウトプットをデータ送信して、別の業務担当に渡して処理してもらうなど、人間で行なっているのと同じように連携して処理をすることができることが重要です。

標準的なRPAツールは、これをサーバで行なうものが多いのですが、集中管理するする場合の難点は、システム管理者がすべての業務を把握しているわけではないので、結局、不測の事態に対処する場合、今までよりも多くの人に介入してもらうか、業務権限の見直しをする必要性が発生してし まいます。

各部門のみ権限が与えられている業務は、その部門でしかソフトウェアロボットが動かないようにする配慮が必要です。そうでなければ、部門ごとのアクセス権限等にも影響します。

また、サーバで集中管理する方式であると、PC のバックグラウンドでしか処理できないものがあったりします。逆に、RDA のようなツールでは、バックグラウンド処理はできず、フロント処理のみなのでロボット稼働中はマウスとキーボードが使用できないものもあります。
業務内容によっては、画面を表示しながら実行した方が良い場合と、バックグラウンドで並行で高速処理したいものがあるので、両方が選択できることが望まれます。
さらにできれば、RDA のようにPC 単独でも担当者側で動かすことが出来ながら、サーバに依存せずPC レベルで監視ができ、他のロボットと連携してスケジュール実行ができる仕組みが理想です。
作成し易い優秀なRPAツールでも、ロボットが人間のように柔軟に対応できないツールは残念ながら、RPA2.0には向きません。

ソフトウェアロボットは、人間のように風邪をひいたり病気になることはありません。
但し、一切トラブルがないかというと、ソフトウェアロボットが入っているPC が故障したり、ウイルスに感染することで、ロボット自身が動けなくなる場合も想定されます。

こうした時、人間組織であれば基本は誰かが代わってその仕事をするバックアップ体制が整えられています。いつもA さんがしていた仕事を、Aさんの具合が悪いのでBさんが代わりに作業するような事は、一般的な企業であれば日常的に行なわれております。

ロボットに仕事を代行させる時も、この体制は必要です。AのPC に導入したロボットが起動できなければ、B のPC でも代行できるようにしておく、そして重要度によっては、人間による指示がなくても自動的に切り替わる仕組みが欲しいものです。
RPAツールのほとんどは、この部分をサーバの冗長化の仕組み等に依存しており、システム管理者がいなければリカバリーできないなどの弊害もあります。ましてや、RDA などのPC 単独で動くツールでは、ほとんど冗長化する機能を持っていません。

その点、RPA2.0に対応した開発ツールを使用すれば、想定されるリスクに応じた対策をプログラミングが可能なため、ホットスタンバイやコールドスタンバイなど、その業務に応じた冗長化をあらかじめ設定しておくことが可能になります。
ホットスタンバイまでは必要がない業務であっても、いざという時に備えて、2 体のロボットがお互いにバックアップとなるような仕組みなどは最低限用意しておくべきです。

多くのRPAツールが、自動でリカバリーする機能を搭載していないため、トラブル時の対応についてユーザ側で仕組みを構築しなければなりません。この部分はソフトウェアロボットを運用するときに重要なポイントとなります。
その際、選択したRPAツールによっては、機能不足により他のアプリと同じポリシーレベルのリスク回避基準での運用が無理な場合もあるため、あらかじめ購入前に確認が必要です。

同業他社との差別化が、今後のロボット化時代に生き残るためには重要です。
企業は、多様化する業務すべてに対して迅速に、そして柔軟に対応していく必要があります。
そのためにも、パッケージ化されたERP やCRM のように他社でも使用されているアプリケーションに業務を合わせるという考えではなく、他社に比べ圧倒的にハイレベルな効率化が可能になるその企業独自のソフトウェアロボットを開発することが望まれます。

RPAは、自動化が目的のため、現在使用しているアプリケーションを代替するものではありません。ロボット化により、従来の業務アプリケーション等を、担当者が行なっているいつもの順番の通りにそのまま自動実行をさせることができます。これにより、担当者は、自動化のために業務フローを変更する必要がなくなるのです。
RPA2.0では、あらゆるアプリケーション、あらゆるフォーマットのデータ、あらゆるセキュリティソフト等と連携することができます。
どのような業務にも対応できる理由は、たとえば開発型のRPAツールであるROBOWARE の場合、C言語のように機械語に近いプログラム言語を用いてソフトウエアロボットのフレームワークを作成しているため、CPU やメモリ、デバイスなどOS のカーネルに近い情報でも受け渡しを可能にしているからです。
但し、そのソフトウェアロボットへの指示は、フレームワーク上のAPI を利用して、Ruby などのスクリプト言語でコーディングきるので、高度なプログラミング知識がなくても、ロボットの開発ができます。

以前であれば、ロボットを作成するには機械語に近いプログラミング言語を用いて開発することが必要だったため、専門知識がないとかなりハードルが高かったのですが、今ではフレームワークによって誰でもなじみやすい言語でロボットの開発ができるようになり、それがRPA2.0の推進を大いに後押ししています。
プログラムなしで作成できる典型的なRPAツールでは、パターン化できる決まりきった仕事しかできなかったのですが、RubyやPHPなどの開発が楽なスクリプト言語でプログラミングするところまで許容することにより、様々な変化や多様性に対応できるRPAを実現できます。

他社の導入事例を参考にRPAを実施することは、リスク回避のためにもとても有効ですが、他社と同じレベルの自動化では、競争に負けてしまう可能性があります。
第4 次産業革命の要は、AIとIoT だと言われておりますが、RPA2.0は、その両方とを連携することにより、バックオフィス以外の業務でも適用範囲が各段に広がります。
PC 操作の自動化しかできないイメージであったRPAにおいて、IoT から得られるセンサーの情報をコントロールしてアラートを出したり、IoT からの情報をAIにつないで処理させたりすることで、今までできなかったような業務処理も実現可能になります。IoT の種類によっては、独自の管理コンソールを持っていますが、RPA2.0は、他のIoT やアプリケーションまで連携して統合管理をすることが可能になります。
バックオフィス業務で注目されているRPAですが、システムの運用管理の目的で、データセンターやマシン室でも、大いに活躍します。

たとえば話題のAI搭載のスピーカーと連動すれば、口と耳の代わりとなり、ロボットへの指示もマウスやキーボードではなく、声に代わるかもしれません。ロボット自身の監視も、異常があったら声や音で知らせてくれるでしょう。

RPAの当初の導入目的は、現状行なっている業務の自動化で充分でしょうが、RPA2.0のノウハウが溜まれば、いままで人間の能力では実現できなかったような業務まで自動化をすることが可能になります。そこまでの領域に到達してこそ、ソフトウェアロボットは多くの人が期待していた賢いロボットとして活躍する時代となるでしょう。

RPA2.0の次は、自律型AIによるコグニティブなRPAが期待されています。その頃には、AIを搭載したRPAが、自身でプログラミングしてロボットを量産し、ロボットをロボット自身が管理するロボット社会になるかもしれません。
そうなれば、業務は完全に人の手を離れ、担当者は業務の監視からも解放されます。
その頃には、ロボットをコントロールする能力がない人は、ロボットに管理されているかもしれません。その前に、ロボットに仕事を奪われているかもしれません。だからこそ、プログラミングの技能やAIリテラシーの向上が重要になります。

どんな世界になるかは、まだまだ想像でしかないですが、今後各企業でRPAが推進されることにより、ソフトウェアロボットの開発が盛んになり、稼働するロボットの数が増えていくことは間違いありません。
その際、ロボットはパターン化した定型業務しかできないというメディアの洗脳にまどわされることなく、自社の業務に合ったロボットを開発して有効利用できた企業が、数年後でも生き残っていけるでしょう。そうした企業は、そのロボット開発のノウハウと実績でロボットを他社へ提供することで、その業界のイニシアチブを取ってビジネスを拡大させているかもしれません。
この流れは、もう誰にも止められないところへ来ています。
そうであるならば、手をこまねいているのではなく、むしろ1 歩先を行く覚悟で、ソフトウェアロボットの開発にチャレンジしてはいかがでしょうか？