G033 横浜市とのRPAに係る調査研究結果
横浜市とイーセクター（現：シーイーシーカスタマサービス）は、2018年より横浜市と共同で「内部管理業務等の事務の効率化」におけるICT 活用（RPA）に関する調査研究を実施し、その報告書をWebページにて公開しております。
開発型RPAツールのROBOWAREを利用して検証を進めた結果、利用者側と開発者側が分かれていたことにより、ロボットによる処理手順を検討する際に、その組換えにより、より効率化が図れる部分を見出すことなどができました。
開発型RPAでPoCを実施したことにより、その開発において既存業務システムとの連携も実現でき、業務プロセス全体のさらなる効率化が可能であることも明らかにできました。
今回開発したものが他課での利用拡大に向けて流用可能な部分も多くあり、他業務に関しての RPA導入の際の開発期間の短縮や、将来的な組織変更や業務フローの変更時においても、柔軟かつ短期間での改修や保守が可能であることが想定される、という結果を得ることができました。
＊横浜市との「内部管理業務等の事務の効率化」におけるICT 活用（RPA）に関する調査研究報告書は、下記［関連］ページよりダウンロードできます。
[関連]
「内部管理業務等の事務の効率化」におけるICT活用（RPA）について（横浜市の掲載ページ）
ICT 活用（RPA）に関する調査研究報告書（シーイーシーカスタマサービスのダウンロード用ページ）
2019.04.15 横浜市とRPAの調査研究結果を公表（プレス）
2018.10.02 横浜市とRPAの調査研究の為の協定書を締結（プレス）
G032 データベースのような立場のフレームワーク
ROBOWAREは、ソフトウェアロボットです。
しかし、その実態は世の中で販売されているメジャーなデータベースソフトにある意味似ています。データベースソフトを購入しても、業務データは付いていません。客先のデータを入れて初めてデータベースとしての役割を果たします。
ROBOWAREも、インストールしただけでは、自動化したい業務はついていません。つまり、ソフトウェアロボットの枠組みだけの単なるフレームワークです。
データベースは、SQL文などを使用して通常プログラムからコーデイングして使用します。ROBOWAREも同様に、ロボットとしてどのように動かすかは、ROBOWARE用のAPIを使用して指示を与えます。
ソフトウェアロボットのROBOWAREは、今まで業務担当者が行なっていたマウスやキーボード操作などの動きと同様に、Ruby,Java,PHP,C#のいづれかのプログラム言語を使って、APIを通して好きなように動かせるます。特定のAPIへ渡すパラメータを生成するGUIのアナライザーも用意されています。
データベースから取り出したデータも、プログラム内でif文などを利用して、条件を付けて加工する場合などがありますが、ROBOWAREも、ROBOWAREに与える指示に条件を付けたい場合は、通常のif文などプログラム内で好きなように指定できます。これにより、プログラミングの知識があれば、今まで高度な専門技術が必要だと思われていたソフトウェアロボットの操作が比較的簡単に行なえます。わざわざ、RPAツールの専用スクールに通う必要がありません。
その証拠に、普段からプログラミングに慣れている方の多くは、ROBOWAREのマニュアルがあればAPIの指定方法が分かるので、半日程で簡単なPC操作のロボットを作成できてしまいます。
そういう意味では、ROBOWAREは、ソフトウェアロボットでありなががら、自動化システムの開発支援ツールであるともいえます。
それまで、APIを持ったアプリケーションは、プログラムで自動化できていたのですが、どうしても人が操作するGUIの部分は、自動化出来ずに諦められていました。今後は、クラウドアプリへのアクセスが多くなる傾向にあり、システム改修のたびに、このGUI操作の部分をどこまで自動化できるかが重要になります。新たにRPAツールを覚えるより、システム開発者にとっては、ROBOWAREの方が他のどんなツールよりも柔軟性と即効性を感じられるでしょう。
[関連]
G006 汎用プログラミング言語を使用するメリット
G025 プログラムを作ることの意味
G031 Rubyの実行形式変換
ROBOWAREでソフトウェアロボットを開発できるプログラム言語として、よく使用される言語にRuby（ルビー）があります。
Rubyは、まつもとゆきひろ氏により日本で開発されたスクリプト言語で、整数や文字列なども含めデータ型はすべてがオブジェクトであり、純粋なオブジェクト指向プログラミングが実現でき、他の言語より比較的ストレスなく簡単に習得できます。
通常Rubyはインタプリタ型の言語の為、コンパイルによって実行モジュールに変換しなくてよいため、ソースコードがそのままの状態でソースコードファイルとして保管、配置または配布することになります。
つまり、ソースコードが丸見えな状態ですので、簡単にコードの解析やリバースエンジニアリング、知的アルゴリズムの流出などのリスクを伴う可能性があります。
このリスクを回避するために、ROBOWAREで５は、有料のオプションを導入することにより、RBF_RubyExeコマンドで実行形式のファイル(バイナリー)に変換することができます。
これにより、Rubyのソースコードの解読を困難にさせることができ、OSの実行ファイルと同じアプリケーションとして取り扱う事が可能になります。
さらに一般的なアプリケーションの開発で実行ファイルを作成するには、コードファイルのコンパイルやリンクをする為に開発用のソフウェアであるコンパイラが必要となりますが、このオプションのコマンドはコンパイラを使用しないでRubyスクリプトを実行形式のアプリケーションファイルとして変換する事ができます。（Windows版とLinux版両方あります。）
変換対象となるRubyスクリプトファイルは、MainコードとなるRubyスクリプトファイルのみとなります。外部のライブラリファイルやモジュールファイル（require等で指定されるファイル）の変換には対応しておりません。
変換された実行ファイルは、CGIとしても利用することができます。
[関連]
G006 汎用プログラミング言語を使用するメリット
G030 RPAのセキュリティ
RPAの推進によって、業務処理が自動化され業務の生産性や処理の正確性が向上するなど、社内でもメリットが大きくクローズアップされます。一方で、デジタル労働者のソフトウェアロボットが増えるということは、それだけセキュリティリスクも高まります。それは、人を採用した場合のセキュリティリスクとは若干異なり、ソフトウェアに依存しているが故の情報セキュリティについてのリスクが懸念されます。
つまり、ソフトウェアロボットは、情報資産として取り扱われセキュリティの管理対象となります。
【ソフトウェアロボットに想定されるセキュリティリスク】
・マルウェア等に感染し、情報漏洩、システム改ざんの入り口に利用されるリスク
・第三者に悪用され不正アクセスの道具として利用されるリスク
・誤作動を起こす可能性(内部の欠陥、バグ等）のリスク
・内部者の故意、または指定ミスによる想定外の動きのリスク など
【情報セキュリティの３要素について】
①機密性の確保
・ソフトウェアロボットを使用できるライセンス権限を持った人しか取り扱いが出来ない状態にする
・情報漏洩対策、アクセス権限の管理、データの暗号化保管など
②完全性の確保
・ライセンス権限がない人から、ソフトウェアロボットを変更できない仕組みが必要
・許可なくプログラムソースにアクセスできないよう暗号化保存
・ウイルスに感染させない対処
③可用性の確保
・ソフトウェアロボットが必要とされるときに動くこと
・バックアップ／リストア―の仕組み
・冗長化の仕組み
ROBOWAREであれば、情報セキュリティについて、ご利用ユーザのセキュリティポリシーにあった情報セキュリティ対策が柔軟に適用できます。
その利点は、ソフトウェアロボットでありながら、通常のアプリ開発と同じようにソースプログラムの管理方法がそのまま適用でき、ライセンスIDに紐づいた実行許可の管理も行えます。
ポイントは、マシン室で管理をするサーバアプリとは違い、個別PCに導入されるアプリと同様に、情報資産台帳に記載し、承認されたアプリとして管理されるべきプロダクトに位置付けることです。
ソフトウェアロボットが導入されたら、企業として、IT統制と同様に情報セキュリティを考慮して運用することが必須となります。
[関連]
G012 ライセンスとセキュリティ
G029 RBF Managerの冗長化
ROBOWAREのために作成したプログラムの実行監視や管理ができるRBF Managerは、ジョブのスケジュール管理や実行後のログ確認など、重要な役割を持っております。
それ故、万が一にも故障などのトラブルがあっては、影響が大きいです。
ウォームスタンバイ方式では、メインのPCが稼働中の場合、もう1台のバックアップPCは待機中となります。
メインPCの故障時にバックアップPCへと切り替えたい場合、メインPCとバックアップPCとでデータの整合性を共有フォルダを使用して同期するように手順化し、バックアップPC側に同期されているジョブを用意しておいて、オペレータがそのジョブを起動します。
ホットスタンバイ方式では、別に用意した監視用PCが、故障を判断して自動的に切り替えます。故障や障害の条件判断、及び、自動切り替え内容は、メインPCでJobコマンドが実行される処理内容に依存されますので別途設計が必要です。
[関連]
G016 サーバに依存しない管理方法
G028 省人化と活人化
RPAが目指すところは、ソフトウェアロボットによる無人運転です。
現在RPAツールを採用した企業の多くは、デジタルレイバーであるソフトウェアロボットが、業務担当者のPC操作等を自動化する部分で活躍しています。つまり、省力化に貢献しているわけです。
しかしながら、RPA対象業務について、たとえ9割の作業が自動化出来ても、一部でも人の介入なしでは完了できない業務は 省力化はできても省人化にはなりません。
もともと省力化や、省人化という言葉は、自動車工場の生産ラインなどに代表されるFA(Factory Automation)などに関連して、使用されてきました。
ソフトウェアロボットを、産業用ロボットに置き換えれば、イメージし易くなります。
省人化の基本は、極力ムダな作業は省き、必要のない仕事は辞め、仕事の目標から見直し、仕事を組み立て直します。
つまり、RPAの世界では、ロボットでできることは、ロボットにやらせて、業務担当者はもっと付加価値の高い仕事に従事してもらうことを目指します。
そのためには、中途半端な業務範囲しか適用できないRPAツールを採用してしまうと、一時的に省力化はできても、省人化できないという結果になります。
省人化という言葉は、言葉自体に人減らしのイメージがあるため、多くの生産の現場では、活人化という言葉が使用されています。
こちらの方が、ロボットに出来ることはロボットに任せ、人を活かせる仕事にシフトさせるイメージがし易いので、これからRPAの分野でも流行っていくことでしょう。
人を活かすためのソフトウェアロボット開発が理解されれば、産業革命の歴史のように機械化されると労働者が解雇されるのでは？という心配と同様、RPAを推進すれば、自分の仕事がなくなるのでは？という懸念も払拭され、働き方改革の推進とともに、さらにやりがいのある仕事に従事できる職場環境を整えることができます。
[関連]
RPA概説⑦ 無人運転を実現するRPAのシステム開発 省力化と省人化
RPA概説⑦ 無人運転を実現するRPAのシステム開発 目指すべきは活人化
G027 アジャイル開発
RPAは、従来多くの企業で採用されているウォーターフォール型の開発手法に比べ、アジャイルソフトウェア開発(以降アジャイル開発）の方が向いています。
アジャイル開発とは、ソフトウェア開発を行う場合の手法で、素早く柔軟に開発できるということで近年特に注目されています。
アジャイル開発では、イテレーションと呼ばれる短い期間の単位を取り入れています。
イテレーションは、ソフトウェアを設計し、プログラムし、テストし、統合し、提供するための固定した長さの短いサイクルです。
プロトタイプに似ていますが、イテレーションは、最終的な製品の一部をきちんと動作するように作り出す点が違っています。この点で、ROBOWAREのRBFアナライザーやQuickROBOなどを利用して、開発者は現場の意見を聞き調整しながら迅速に開発することがポイントになってきます。
また、アジャイル開発では、たくさんのドキュメントを残すことよりも、プロジェクト関係者間で適宜直接顔を合わせて意思疎通を図るために頻繁にコミュニケーションをとることを推奨しています。この点が、仕様書、設計書、ワークフローなどのドキュメント作成に時間を取ることより、事務部門の現場と、システム側あるいは開発者の人が、お互いコミュニケーションをとり、より良いものを作成することの方がRPA構築にはかなり有効です。
今後、変化に対応し、迅速に開発しロボットを量産して、業務効率を劇的に向上させるためには、アジャイル開発の手法はますます重要になっていきます。
[関連]
RPA概説⑦ 無人運転を実現するRPAのシステム開発 アジャイルソフトウェア開発
G026 RBFアナライザー
RBFアナライザーとは、ROBOWAREで開発を行なう際に、RPA構築でいちばん厄介なマウスやキーボード操作をプログラムによって指示するために、APIの引数の値を生成する開発支援ツールです。
その際、コーデイングする開発言語を選んで、その言語に合った引数の値を生成してくれます。
テキストと、グラフィックパターン両方同じような手順で認識でき、認識できる対象が他のツールに比べて数多く柔軟にプログラムできます。
もちろん、対象物の座標を調べることもでき、色も判別します。
[関連]
ロボット作成の手引き③ ―RBFアナライザー編ー
RPA概説③ ソフトウェアロボットの作り方 ROBOWAREアナライザー
G025 プログラムを作ることの意味
ROBOWAREの場合、Ruby、PHP、Java、C#の内いづれかのプラグラムを作成し、通常のプログラムを実行する形式でROBOWAREに命令を与え、動かせることができます。
他のRPAツールの場合、そのツールの専用画面上で、シナリオを作ったり、ワークフローを定義したりして、スクリプトによってコーディングしたものを組み込む場合もその部品の一部として組み込みます。
つまり、多かれ少なかれ、それが簡単であろうとなかろうと、他のRPAツールで開発する場合は、そのツールの専用の設定画面を起動し、その設定方法を覚えなければロボット開発はできません。
一方、ROBOWAREの場合、ロボットを開発するには、つまりROBOWAREへの指示のプログラムの開発をするには、通常のプログラム開発と同じ手法で、使い慣れたテキストエディタを使い、Rubyとかをコーディングするだけです。クリックする画像などを特定しAPIの引数をジェネレートするRBFアナライザーなどを別途起動することはありますが、それは単なるコーディングの支援ツールなので作るプログラムによっては必須ではありません。
作ったブログラムをスケジュール登録できるRBF Managerもありますが、普通のプログラムと同様、コマンドラインから起動も、Windows標準のタスクスケジューラなどからでも起動できます。
RubyやPHPなどは、スクリプト言語なので、コンパイルさえいりません。
通常のプログラムを使用して、ROBOWAREに指示を与えることができるメリットは他にもあります。EXITポイント毎に記述するシステムではないため、変数のデータの引継ぎに苦慮する必要もなく、メソッドをライブラリ化することで、シンプルで見やすいプログラムができます。そして、そのライブラリを共有することで、ノウハウも蓄積され、開発効率も上がります。
また、外部ライブラリを使用することで、かなり高度な処理も可能です。
そして、様々なアプリケーションやAIなどと連携する場合に、そのシステムのAPIをROBOWARE用のプログラムから呼び出し、データをやり取りしたるすることが可能です。
あるいは既存の開発されたアプリケーションに、PCの自動操作などの処理を加えたい場合も、ROBOWAREへの指示のコーデイング部分を加えるだけで、新規に一から作り直す必要がありません。更に、ソース管理も従来のプラグラムと同様に行なえるため、IT統制やセキュリティポリシーへの対応についても特別な制度追加が必要ありません。よって、運用も楽です。
このことが、プログラミングを経験している人にとっては、とてもROBOWAREの開発が柔軟で、拡張性があって面白いと人気になっている理由のようです。
[関連]
G023 ソフトウェア開発者にとってのRPA
G020 ROBOWAREのロボット開発とは？
G006 汎用プログラミング言語を使用するメリット
G024 RPAツールの共存
ROBOWAREのユーザは、他のRPAツールを既に導入されてしまっているユーザが多いです。
なぜなら、開発系と呼ばれるツールは、ROBOWAREしかメジャーには存在せす、そのそも他のツールと手法が違うため競合するどころか、共存できるからです。
そもそもRPAツールを、プログラミング無しでRPAを構築できるツールだと位置付けている場合、ROBOWAREはその比較表にさえ入っていません。
多くの企業や組織は、目先の目的として、バックオフィス業務などの、大量データを扱うパターン化できる作業を自動化する目的で、RDA（ロボティック・デスクトップ・オートメーション）と呼ばれるPC単体にインストールし、サーバでは稼働しないし、オプションなしではスケジュール機能や、複数ロボットの統合監視・管理ができないツールを導入しています。これは、コスト的にも比較的安く導入できるのと、システム部門にあまり頼らずとも、現場の事務部門のみでも開発できそうだという思惑があるからです。
しかしながら、RDAツールを導入してしまった企業は特に、複雑な処理を行うには、プログラミング知識が必要であるし、IT統制、セキュリティ、野良ロボット対策などを考慮すると、そのRDAツールだけでは構築の限界が見えてしまうようです。
そんな中、もっとRPAの業務範囲を拡大して、ロボット代行による効果を得ようと考える先進的な企業は、ROBOWAREも導入して、RPA2.0を目指すようです。ROBOWAREを使えば、すでに構築したRDAツールのロボットでさえ、実行や監視対象として連携することができます。わざわざ、RDAツールのオプションなどのサーバ監視機能を購入しなくても、ROBOWAREで新たに作成るロボットと同様に、管理し、IT統制に組み入れることができます。つまり、せっかく作成したロボットを捨てることなく、共存できすのです。
もちろん、中には保守料金や管理面での問題で、段階的にROBOWAREで作成するロボットに置き換えを希望される企業もありますが、時期とタイミングいよって、良いツールへ乗り換えることはよくあることなので、まずは人気のある商品でRPAを試してみるという考えは決して無駄ではないと思われます。むしろ、せっかく購入したRDAツールにこだわりすぎて、IT統制やセキュリティがおろそかになってしまったり、量産しすきだロボット管理が問題になってしまってRPAの推進を辞めてしまう方が、損失は大きいと思われます。
多くの企業は、RDAツールといえども、RPA構築による効果を実感でき、それなりの成果を認めてはいるものの、それは、作業の一部を自動化できただけで、業務プロセス全体を自動化できたことにはなりません。
つまり、従来のRPAではパターン化できる定型業務しか自動化できないため、人の判断が必要な業務や、非構造化データを取り扱うような複雑な業務も自動化するRPA2.0を求める企業は、適材適所の選択として、柔軟で拡張性のあるロボット開発ができるROBOWAREを選択されるようです。
[関連]
G018 RDAとの違い
G008 RPA2.0に求められること
G007 RPAとRPA2.0
G023 ソフトウェア開発者にとってのRPA
RPAは、バックオフィスを中心とした業務担当者の主導で開発が進められることが多いです。
現場主導のRPA構築は、単純なPC操作であれば、多くのツールも存在し、現場担当者がプログミングなしで作成できるものも多いのでそんなに問題にはならないのですが、複雑な業務や、判断が必要な処理にはソフトウェア開発者の助けが必要になります。
それは、完全自動化をするためにセキュリティやIT統制の考慮も必要で、単なるプログラミング知識だけの問題ではなく、システム開発の経験と実績が重要になるからです。
システム開発といえば、従来であれば、どのような業務フローでどのようなアプリケーションが必要になるのかが明確になっている仕様書または設計書がある中で開発が進められますが、RPAはそのような手順を踏まずに、現場でフェーズごとに操作方法を適宜確認しながら開発が進んでいくことが多いです。
というのも、RPAの主たる目的が業務オペレーションの自動化をすることであり、つまりすでに行っている業務フローに従って手順を自動化していくことなので、これから作るアプリケーションというよりは、すでにある複数アプリケーションの連携操作などの処理が多く、その操作を少しづつ都度確認しながら開発する方が作成し易いからです。
このような理由から、RPAの開発は、アジャイル手法が向いていると言われています。
アジャイルとは、敏捷、素早いという意味で、RPA構築においては、現場の業務担当者とのコミュニケーションを図り、イテレーションと呼ばれる短い期間単位で、リリース可能な自動化の仕組みを提供します。
従来の、ウォーターフォール型のような開発手法では、最初の要件定義や設計の段階で重要なことが決定され、開発途中での仕様変更は難しかったのですが、アジャイル手法を取り入れることにより、仕様の決定を遅らせること、あるいは仕様変更を臨機応変に取り込むことができます。これにより、現場の業務担当者とフェーズごとに確認しながら開発できるので、リスクも少なく、スピーディな開発ができます。
つまり、アジャイル手法になじみがなかったシステム開発者にとっては、アジャイルソフトウェア開発手法のメリットを理解し、取り入れるところから始めることをお勧めします。
従来のソフトウェア開発との違いは、RPAの構築には、PC操作の作業手順が追加されることと、必要に応じて、アプリケーションを連携するということです。自動化といえば、開発したアプリケーションソフトをジョブスケジューラーに登録するなどして自動的に処理をおこなう仕組みを構築することが一般的だったのですが、RPAの構築ではそれ以外の人による手作業が必要だった部分についても、自動化の開発をすることが追加されます。
今までは、このPC操作部分はシステム開発が難しかったのですが、様々なRPAツールが出てきたおかげで、比較的簡単に開発をすることができるようになりました。
しかも、ROBOWAREであれば、プログラミングに精通したソフトウェア開発者の方は新たにRPAツールの使用方法を覚えなくても、マニュアルやサンプルスクリプトを利用することにより従来のプログラミングをするやり方で、APIや引数を使って簡単にロボット化の開発が行えます。
ソフトウェア開発者にとっては、RPAのPC操作部分についても開発できるようになれば、付加価値を会社に提供でき、自分のスキル向上にとってもメリットとなります。今後のロボット化需要を考慮に入れれば、RPA構築経験が、ソフトウェア開発者としてのキャリアアップにとても貢献します。
しかも、ROBOWAREであれば、リモートでの開発も可能なので、今後の在宅勤務や、サテライトオフィスでのシステム開発を可能にします。外部委託のソフトウェア開発会社にとっても、他社との差別化ができるスキルポイントとなり、会社の業績向上も期待できます。
[関連]
RPA概説⑦ 無人運転を実現するRPAのシステム開発 アジャイル開発とRPA
G020 ROBOWAREのロボット開発とは？
G019 誰がロボットを作成すべきか?
G021 OCR連携
RPAとOCRを連携したソリューションが、各社から多く発表されています。
ROBOWAREは、プログラミングによって開発できるため、特にOCRメーカーを限定しなくても、どのOCRソリューションとも連携出来ます。
このオプションは、パナソニック社の高精度OCR技術により、紙文書をシステムで可能なデータに変換します。
企業内にあるどの複合機からでも、スキャンした紙文書などのデータをOCR処理して、ROBOWAREによって自動的に指定したパソコンやサーバー上のフォルダに送信できるようになります。
従来、複合機のスキャン機能を活用した画像データの文字認識は、各社ごとに機能、操作・設定方法、認識率も異なり、またOCRソフトウェアを導入する場合は、それぞれの複合機に合わせて個別にライセンス購入が必要で構築コストも別途かかってしまいますが、複数メーカーの複合機のOCR変換を利用する企業にとっては、一元管理ができる有効な解決策となります。
エクセルやワード、PDFなど、手書き文字を様々な形式のファイルフォーマットに変換でき、できたファイルをROBOWAREによって、ファイルサーバやメールサーバ、文書管理システムなど用途に応じて自動的に送ることができます。
業務によっては、OCRで変換されたデータを複数のアプリケーションで連携して使用する場合などもROBOWAREで自動化できます。
（このソリューションに関するご相談はお気軽にお問合せください。）
[関連]
OCR連携RPAソリューション
手書き文書の自動登録処理（デモ動画⑧）
G020 ROBOWAREのロボット開発とは？
ロボット開発というと、素人には難しいというイメージがあります。
プロのプログラマーであっても、かなり高度な知識が必要で、C言語とかに詳しくないと無理だと思われています。
だからこそ、RPAツールが流行っているのですが、通常はロボット作成が難しいからこそ、GUI等で簡単にソフトウェアロボットを動かせるような仕組みとなっています。
それでは、ROBOWAREでソフトウェアロボットの開発をする場合は、どのように行なうのでしょうか？
実は、ROBOAWAREの場合、インストールさえすればROBOWAREというソフトウェアロボットが既に出来上がっているのです。但し、人型ロボットも指示しなければ、期待通り動かないのと同様、ROBOWAREもどのように動くのか指示をしない限り、勝手に動くわけではありません。（将来は、AIの発達で可能になるかもしれませんが・・・・）
こうしたことから、ROBOWAREはソフトウェアロボットですが、ロボットの枠組みという意味で、ソフトウェアフレームワークという呼び方もしています。
つまり、ソフトウェアロボットの開発をするということはすなわち、ROBOWAREへどんな動きをするかの指示を作成するということです。具体的には、その動きを伝えるのに、Ruby、PHP、Java、C#の中から好きな言語を選び、通常のプログラムを書く要領で簡単に指示ができます。その際、ロボット操作として難しい、マウスやキーボードの動き、アプリケーションとの連携など通常では複雑でコーディングが難しい部分を、APIを提供することにより、引数を渡すことで簡単に指定できるようになっております。この部分で開発型RPAツールと呼んでいますが、実際は、API提供型のソフトウェアロボットなのです。
2020年には、小学校でもプログラミングが義務化されるようですが、プログラミングさえ抵抗がなければ、APIでPC操作の自動化ぐらいは簡単に指定できるので、誰でもすぐにソフトウェアロボットを作成することが可能です。プログラミング知識がそのまま使えるので、ROBOWARE用には、特に教育研修に参加しなくてもマニュアルを見てサンプルを参考にすればソフトウェアロボットの作成が出来てしまいす。
この時、プログラミング経験者であれば、Ruby、PHP、Java,C#を使用したことがない人でもそんなに難しくないと思われますが、この時のポイントは、ROBOWAREのAPIへ渡す引数は、ハッシュ型を使用していることです。これは、連想配列ともよばれキーに対する値を指定できます。プログラミング言語によっては、このハッシュを使わないものがありますので、このハッシュの使い方を理解することが重要です。
ROBOWAREに対しての指示に汎用機言語（Ruby,PHP,Java,C#)が使用できることは、様々なメリットがあります。新たに覚えることが少なく、プログラムの書き方は、Web検索でたくさん参考情報が得られます。プログラミング言語を使用するので、共通するメソッドなどはライブラリに登録して共有し易く、リファクタリングなどの最適化で無駄のない開発が可能です。ソースやライブラリ管理は従来通り、ITガバナンスやセキュリティポリシーに沿って管理できます。複雑の処理を組み入れたりできるので、業務に合った最適なRPAが作成でき、将来のAIやIoTなどの連携も期待できます。
[関連]
G003 API
T018 ハッシュ
RPA概説③ ソフトウェアロボットの作り方
RPA概説⑦ 無人運転を実現するRPAのシステム開発 RPA開発における知識の蓄積
G019 誰がロボットを作成すべきか?
RPAツールのおかげで、誰でも簡単にソフトウェアロボットが作成できるという思いから、現場で苦労している業務担当自身に好きなように開発を委ねたいという会社も増えてきました。
これは、RDAタイプのツールを使えば、担当者のPCでGUIを使って割と簡単にロボットが作成できるという優れた技術のおかげのようです。
従来からRPAツールとして定評のある海外製品で大規模システムに対応した典型的なRPAツールでは、サーバ集約型のため、専任の開発者がソフトウェアロボットを作成して、仮想デスクトップやPCのバックグラウンドで
処理をさせてしまうケースもあります。というのも、金融系のように規制に厳しい会社はガバナンスを効かせるためにエンドユーザには開発させないという会社も多いからです。
確かに、現場の業務担当者に好きなだけロボットを作らせてしまったら、「野良ロボット」が生まれてしまい、管理しきれないとか、他の人に引き継げないという問題もあります。
エクセルのマクロの延長のように、業務を楽にするツールという点では、RDAタイプのツールは、業務の一部を自動化してくれるので大変便利ですが、RPA本来の目的である業務の完全自動化を
狙っている場合は、システム部門の介入なしでロボットを運用するのは、ITガバナンスやセキュリティのリスクが大きすぎます。
そうはいっても、従来のアプリケーション開発のように、開発部門にすべてを任せてしまったらRPAツールは、現場担当者でも開発できるという本来の特長を発揮出来ず、単なるシステム開発者の開発支援ツールになってしまいます。
実は、完全無人化を狙い、ITガバナンスを考慮すれば、それで良いのです。そうした、実例も多く、それが運用を継続するためには安心なのです。つまり、RPAツールは、自動化システムというシステム開発の支援ツールなのです。
とはいえ、従来のアプリ開発との違いは、業務担当者が行なってきた操作と同じように、ソフトウェアロボットにPCの操作をさせるので、業務担当者にも開発に携わってもらうことが、リスクを減らし、開発期間を短縮し、そして最良の品質のロボットを開発するためには一番重要です。
よって、重要なのはツール選びと業務担当者のみに任せるのではなく、ITガバナンスに精通したシステム部門からの協力も必ず得ることです。
ツール選びとは、たとえば、自動化のためのロボットの開発には、開発やシステム部門の人にROBOWAREを使用してもらい、プロトタイプの作成や、セットベース開発には、現場担当にも協力を得てQuickROBOを使用するのです。
QuickROBOであれば、操作手順を覚えこませるだけで、条件分岐やエラー対応などは設定できないためかえって安心です。この部分は、その会社のガバナンスやセキュリティポリシーに従う必要があるため、システム部門にROBOWAREでその処理を追加して、QuickROBOを呼び出すようにしてもらうのがベストです。
仕様が固まって、現場の業務担当と開発者がその操作の動きを合意できれば、業務担当者が作成したQuickROBOの部分も、ROBOWAREのコーディングに書き変えることもできます。そのままQuickROBOを組み込んでおけば、操作画面のレイアウト変更があった時など、現場による臨機応変な対応が必要な場合は、QuickROBOの分だけ修正してもらえるというメリットもあります。
[関連]
G018 RDAとの違い
RPA概説⑦ 無人運転を実現するRPAのシステム開発 RPA開発における知識の蓄積
G018 RDAとの違い
RPAに似て非なるものにRDA（ロボティック・デスクトップ・オートメーション）という分野があります。
多くのベンダーは、この分野でもRPAツールとして販売しており、厳密に区別するのは難しいのですが、一般的にRDAは、自動化させたいPCにツールをインストールしそのPCでソフトウェアロボットの開発を行います。一方、典型的なRPAツールは、開発したロボットをサーバから起動し、PCを固定せず並行してバックグラウンドにて自動化します。
最近では、RDAの機能に、ソフトウェアロボットを管理する仕組みを別に設けてオプション的に追加できるものが増えてきました。
ソフトウェアロボットの開発をしたいPCにソフトウェアをインストールするという部分においては、ROBOWAREもRDAに似ておりますが、ROBOWAREは、PCでもサーバでもインストールが可能です。そして、大きな違いが、RDAではできない複数のソフトウェアロボットを連携したり、管理したり、冗長化を構成したりできます。
典型的なRDAツールには、スケジュール実行の機能がないため、Windowsのタスクスケジューラなどに別途登録してはじめて定期的に実行ができます。
また、RDAは画面上でマウスやキーボード操作を人の代わりにフォアグラウンド処理を行うので、マウスやキーボードなどのデバイスを占有してしまい、並行処理はできません。その点、ROBOWAREは、デスクトップモードとサービスモードの両方がありますので、フォアグラウンドでもバックグラウンドでも両方の処理が選択可能です。プログラミング次第なので、デスクトップモードであっても、バックグラウンドで複数ファイルを読み込むことなどはもちろん柔軟にできますが、マウスやキーボードを占有しているので、デスクトップモードでのROBOWARE自身の複数同時稼働はできません。並行処理は、サービスモードで行います。
ROBOAWAREでは、RDAではできない他のソフトウェアロボットとの連携が可能です。家から、会社のROBOWAREを起動して、ネットワーク上社内からしかアクセスできないファイルサーバのデータを処理するようなことも可能です。
ROBOAWARE同士で、バックアップしたり冗長化も可能です。
RBF Managerはサーバでなくても、PCでも稼働できるため、RDAにないソフトウェアロボットの管理がマシン室でなくても遠隔地のサテライトオフィスからでも行えます。
その他、機能的には、多くのRDAはグラフィックパターンと座標で画面操作対象を特定しておりますが、ROBOWAREはそれに加えてテキスト認識もできます。ほとんどのRDAが、Windows環境でしか稼働しないのですが、ROBOWAREは、WindowsでもLinuxでも稼働します。
こうした細かい点は、製品ごとに優劣の差があるため一概に比較できませんが、RDSは業務の一部であるパターン化できるPC操作を自動化できるだけなので、価格は他のRPAツールに対して比較的安価で提供されています。
[関連]
T013 デスクトップモードとサービスモード
G017 RPA構築で失敗を避けるポイント
RPAを導入したものの、必ずしも満足されていない企業が多いです。
失敗を避けるためのポイントをまとめてみました。
① 達成目標を明確化できているか？
・手順の省力化だけで満足できるのか、業務の完全無人化を目指すのか等をはっきりさせます。
② マイルストーンを作成する
・いつまでにどの範囲まで実現するのか、大枠のスケジュールに沿った開発が必要です。
③ 業務範囲が明確になっているか？
・直近の業務ばかりに目が行くと、ツール選定にも影響します。
④プロジェクトメンバーの責任と役割が明確になっているか？
・RACI(レイシー)マトリクス等を使用し、項目ごとの役割分担を決める必要があります。
⑤ ガバナンスを考慮して構築されているか？
・IT部門が関与して、IT統制下に置かれたソフトウェアロボット開発になっている必要があります。
⑥ RDAとRPAを混同してツール選定していないか？
・RDA（ロボティック・デスクトップ・オートメーション）では、複数のロボット連携や管理ができません。
⑦ ベンダーへ依頼する作業範囲が明確になっているか？
・契約以降に期待通りの支援が受けられないというトラブルを避ける必要があります。
⑧ ロボット開発のし易さが第一優先になっていないか？
・ソフトウェアロボットが稼働した後の安定稼働が重要です。
⑨ RPAツール習得に特定のスキルが必要で属人化されていないか？
・採用したツールを取り扱える人が限定されてしまい特定の人に頼るリスクがあります。
⑩ RPAツールにスケーラビリティを確認したか？
・初期段階でうまくいっていても、業務範囲を拡大したら対応できないツールも多いです。
⑪ 障害時の対応方法、体制が確立されているか？
・ソフトウェアロボットを作成して終わりではありません。障害対応の体制づくりが重要です。
上記はほんの一例ですが、RPAの構築で後悔しないよう、適宜リスクのマネージメントが必要となります。
[関連]
G008 RPA2.0に求められること
RPA概説② RPA導入のために知っておきたい豆知識 RPA導入のためのポイント
G016 サーバに依存しない管理方法
RDA（ロボティック・デスクトップ・オートメーション）は別として、多くの一般的なRPAツールのソフトウェアロボットの管理方法は、サーバによる中央集中のスター型か、ツリー型が一般的です。
これは、組織と同様、中央で管理を一極集中したほうが楽だからです。
サーバのダウンは、いくらソフトウェア的に問題がないツールであっても、ハード障害も考慮しなければいけません。よって、クラスタリングなどの機能を追加し、サーバを二重化あるいは冗長化させる投資が必要です。さらにサーバが複数台になった場合、それに付随するソフトウェアも追加が必要です。つまり、サーバ費用とは別に、冗長化のためのソフトウェア費用も必要となり、当初の予定よりコストが増大します。さらに、冗長化方式が、ホットスタンバイなのか、コールドスタンバイなのかでも費用が違い、そのRPAツールが対応しているかどうかも調査が必要です。
これに対して、ROBOWAREは、グリッド型と呼ばれるグリッドコンピューティングによるネットワーク方式を採用しています。
この方式の利点は、サーバー／クライアントラインセンスの概念がなく、設定により選択可能なため、設定次第でPCのみで管理でき、冗長化がROBOWAREの設定だけでできることです。つまり、サーバを前提にしていないため、サーバ費用を抑えることができます。もちろん、サーバであっても稼働環境対象であればインストール可能です。そして、PCで管理ができるので、マシン室にサーバを置かなくても、サテライトオフィスや、在宅のリモート形式でも実行やJOBの監視、管理が可能となります。
冗長化は、管理するPCだけに依存するだけでなく、ROBOWAREを実行するPC側でも予備機として切り替える設定をあらかじめ用意しておくことも可能です。
[関連]
RPA概説⑤ RPA2.0を加速するソフトウェアロボット開発 冗長化とバックアップ
G015 RBF Manager
RBF Manager(RBM)とは、ROBOWAREで開発したプログラムを管理することができるソフトウェアです。
主にROBOWAREで作成されたJobコマンドを登録、実行などの管理ができ、それにより、スケジュールによる定期的な実行管理などが可能になります。
Jobコマンドとは、ROBOWARE用に実行できる手順書として開発されたプログラムのことです。
ここで便利なのは、プログラムの方でコーディングしていなくても、そのJobコマンドの実行時の開始と終了それぞれについて、メール通知するかどうかを指定できます。Job毎に、メールの送信元、送信先を変更もできるので、遠隔地でもジョブが実行されたかどうか確認できます。
Jobの実行状況は、RBMのJobコマンドリストビューの画面で確認できます。
実行時の状態や、終了時のコードが一覧で表示でき、たとえば開始日時など、項目名をクリックするだけでソートできます。
Jobコマンド実行画面では、指定日時や、月次実行などをスケジュールでき、時間サイクルや、週サイクルも指定可能です。 ROBOWAREは、100Jobまで同時実行が可能です。また、Windows再起動時でもJobを起動させるかどうかも設定できます。
RBMは管理するための機能なので、RBMが導入されていないPCでも、ROBOWAREのライセンスがありROBOWARE本体がインストールされていれば、そのPCでJobコマンドを実行してロボットを動かすことが可能です。
[関連]
ロボット作成の手引き② ―指定日時で実行編ー
RPA概説③ ソフトウェアロボットの作り方 Jobコマンドの新規登録
G014 活人化のススメ
産業用ロボットで自動化が進む生産の現場では、ロボットが人の代替を行うことを「活人化」という言葉でよく表現されています。
機械化を進め人件費を削減するために首切りや大量解雇の目的でロボットを導入するわけではない、ということを明確にするためにも、
ロボットによる「省人化」のことを「活人化」という言葉で表現されています。
人減らしのためではない、人にもっと高度な付加価値のある仕事に就いてもらうためにロボットを導入するための「活人化」です。
つまり、「省人化」はその仕事から人が作業する必要がなくなるので、ロボットによる人員削減という悪いイメージにならないためも「活人化」という言葉が使用されているようです。
RPAのソフトウェアロボットの導入も、目的は「活人化」にすべきです。
今後ますますAIやIoTが進化していけば、ソフトウェアロボットで代替できる業務範囲が広がっていきます。
労働人口の不足が問題視されている中で、ロボットでもできる仕事はロボットに任せ、人は人にしかできない仕事を創設していけば、さらに業績も上がり競争に打ち勝つ強い会社になるでしょう。
例えば、作業はロボットに任せ、ロボットの監視、管理を現場の業務担当者に任せるのです。
ROBOWAREを使って、業務進捗を自動的に把握できる仕組みや、異常にたいしてアラートを上げたり、通知する仕組みをつくれば、ロボットを量産することにより、今までの何倍もの業務量を少ない人数でこなすことができます。
さらに余裕ができた時間を使って、プラグラミングを習得しROBOWAREでのソフトウェアロボット作成に費やせば、ますます業績拡大に貢献できます。
現場をよく知っている業務担当者が、自分でロボットを作るノウハウがあれば、会社にとっても一番無駄のない効率的なロボット開発の体制が組めるでしょう。
[関連]
G013 ロボットに求められるもの
RPA概説⑦ 無人運転を実現するRPAのシステム開発 目指すべきは活人化
G013 ロボットに求められるもの
FA（Factory Automation）に代表される産業用ロボットをはじめ、ロボットは約半世紀ほど前から盛んに人類によって作られてきました。
FAの歴史をたどれば、RPAのソフトウェアロボットが何を求められているのかのヒントになります。
ROBOWAREのソフトウェアロボットも、長年ロボットの研究に携わってきた開発者が、様々な工場の現場の声を参考にしながら、
産業用ロボットとともに歩みながら、多くの自働化ニーズに対応できるソフトウェアロボットとしてデザインされ改良されてきています。
① グローバル化の価格競争から負けられない
② 安定した品質への要求拡大
③ 作業員の確保ができない
④ 人が入りづらい危険区域での作業
⑤ 経年劣化による保守・トラブルの増加
⑥ 生産ラインの24時間稼働への要求
⑦ 改善活動のためのデータ収集、データ活用への要求
⑧ 作業者の能力差による作業スピードの改善
⑨ 熟練工の減少による教育、ベテランのノウハウの継承 ・・・ など
生産工場での声は簡単に紹介できないほどたくさんありますが、どれもバックオフィス業務に置き換えても現在、あるいは今後出てきそうな課題ではありませんか？
オフィス業務でも、ロボットに求めるものは同じだと感じられれば、長年のFAのロボット化のノウハウが、RPAでも活かされるべき重要なポイントであることがわかります。
このことから、RPAのソフトウェアロボットも、スピィーディで、正確で、堅牢で、拡張性があり、多くの現場の要求にも応えられる汎用性のあるものが求められます。
そのためには、完全自動化が実現できる仕組みを構築できるRPAツールが必要です。
ROBOWAREは、工場での生産工程で培われてきたFAの自働化ノウハウを同じようにプログラミングで活かすことにより、RPAに無人運転を取り込むことができます。
[関連]
G011 ROBOWAREの生い立ち
RPA概説⑦ 無人運転を実現するRPAのシステム開発 FAに学ぶべきRPA
G012 ライセンスとセキュリティ
ソフトウェアロボットに付与するユーザーのライセンス管理がおざなりだと、アクセスしてはいけないPCでの誤操作や、悪意を持ったソフトウェアロボットの動きをさせてしまうリスクが生じます。
ソフトウェアロボットは、決められたPCしか動かないようにすることはもちろん、他のPCや遠隔からのリモート操作は、そのライセンスを使用できる人しか動かせないようになっていなくてはいけません。
このあたりの部分は、ROBOWAREは、ロボットID（ライセンスID)という考え方で、そのIDを知らない人は、いくらROBOWAREをコーディングしてもリモートで操作することはできません。
ROBOWAREのライセンスファイルには、ユニークなエンドユーザ固有のライセンスIDがあります。そのライセンスIDが同じでなければ、ROBOWARE間で通信できません。
また、通信経路(リレー)にライセンスIDが異なるRBFサーバを指定しても、リレーできません。
ROBOWAREは、複数のライセンスファイルを読み込ませることで複数のライセンスIDを登録することができます。複数のライセンスIDを登録することで、ROBOWARE同士が、読み込んだ同じライセンスIDでしか通信や制御できない制限をライセンスファイルで管理することができます。
正規のライセンスファイルでROBOWAREを動作させるには、ライセンスファイルを全てのWindows PCのライセンス格納フォルダに有効なライセンスファイルを配置しなければ動作しません。
複数のWindows PCに配布することで、お客様固有の有効なライセンスファイルが第三者に流失する可能性があります。そこでライセンスファイルの情報をWindowsのレジスリに登録することで、配布したライセンスファイルをライセンス格納フォルダから削除することができます。
レジストリに登録されたライセンスファイルの情報は、レジストリのコピーなどで持ち出しされても、他のWindows OSで使用することはできません。
[関連]
G002 ソフトウェアフレームワーク
G011 ROBOWAREの生い立ち
ROBOWAREの販売開始は 2016年9月12日ですが、その基本となるソフトウェアエンジンの原型は、約30年前の日本の高度経済成長期時代の生産製造工場の24H365D生産し続けるオートメーション化(無人生産工場)の開発から始まり、IT技術革新
の時代の流れ(グループウェア,SCM, ERP, ISP, ASP, SaaS, クラウドなど)からの運用現場のお客さまニーズより日々改良開発し続けて、安定した品質のIT無人運転化のソフトウェア製品としてリリースしたものです。
現在も成長しております。
RPAのパッケージとして販売しているROBOWAREは、弊社シーイーシーカスタマサービスの商標でOEM販売しているものですが、この元になったエンジンは特に無人運転の分野で他の形ですでに採用され導入されている実績もあります。
ROBOWAREのネーミングは、ロボットのソフトウェアを意味するRobotic Softwareの前後を残した造語で、つまり、ソフトウェアロボットを表しています。
2016年11月に、事業拡大と共にROBOWAREの特別サイト(roboware.jp)も開設いたしました。
本来、バックオフィス業務の自動化目的で作成されたわけではないのですが、複雑なシステム運用管理を自動化してきた実績とノウハウが、どのようなRPAのニーズにも対応できるため大変ご好評を頂き、現在では唯一RPA2.0を実現できる開発型RPAツールとして注目を頂いております。
これは、それまで高度なプログラミング知識を必要とした、マウスやキーボード操作などのロボットの動きが、ROBOWAREのAPIによりプログラミング経験者なら誰でも楽しく簡単に作成できるようになり、その結果、仕事の速度や正確性が増し、目に見えて業務効率が上がるので導入満足度が高まるからのようです。
多くのRPAツールは、ノンプログラミングを前提にしているため、適用できる業務の範囲に制限があり、障害時の対応が不得手なためケースによっては人が介入すべき処理が多く残ってしまいます。
それに対して、汎用プログラミング言語で開発できるROBOWAREは、システム開発の延長でRPAを構築できるため、あらゆる業務に対応し、バックオフィス業務においても運用管理の自動化で培った無人運転が実現でき、PCの前に人がいなくても大丈夫な運用が可能になります。
そして、ロボットとしてOSに近い部分からコントロールできるので、他のRPAツールで不可能なスクリーンロックされた状態からの解除や、別のPCのロボットと連携して、障害時に他のPCから稼働させるなど、柔軟で事業継続計画に適したソフトウェアロボットの開発ができます。
[関連]
G001 ソフトウェアロボット
G004 ROBOWAREの販売について
G010 AIとROBOWARE
RPAが話題になると決まってAIも話題になります。
AIとは人工知能のArtificial Intelligenceを指し、人型ロボットに搭載されているイメージなので、ロボットとAIをイコールで考えてしまう傾向にありますが別物です。
それゆえ、ROBOWAREにはAIは搭載されておりません。
ROBOWAREは、汎用的なソフトウェアロボットなので、その用途に合った様々なAIと連携をとることができます。
将来、AIも汎用的なAGI（Artificial General Intelligence：AGI）が実現すれば、ROBOWAREと一体となって、自分自身で自分の動きをプログラミングしてしまうほど賢く自律したソフトウェロボットが出現することも夢ではないかもしれませんが、現時点では、RPAの頭脳として業務に合ったAIを選び、手足としてのPC操作の部分をROBOWAREが担当するというのが現実的です。
AIといえば多くのデータを使って自律的に学習するディープラーニングを思い浮かべますが、業務で現実的なのは、人の判断に頼っていた多くのパターンを処理する部分を推論エンジンを搭載したAIのシステムに判断させる場合などが有効です。
これについては、Progress CorticonとROBOWAREを組み合わせたデモ動画 「チラシ同梱依頼業務を自動化」をご参照ください。
デモ動画⑥ 【音声付】
[関連]
RPA概説④ AI搭載を見据えたRPAの実装方法とは？
G009 テンプレート型と開発型の適用範囲
多くのRPAツールは、RPAの構築を簡単にするために、GUIにてPCの操作を記録して、ある程度のパターンをテンプレート化しワークフローやシナリオを作成するだけで自動化が設定できるようになっています。
ルールベースで指定できるような単純作業であったとしても、if文や、変数が登場する時点で、ある程度プログラミングと同等の知識が必要になります。
右の図の①は、プログラミングはもちろんエクセルのマクロ作成さえ苦手という方は、残念ながら出来たとしても単純作業の動きしか自動化設定ができません。ツールによっては、設定方法を理解するのにかなり時間を要するかもしれません。
この範疇は、エクセルのマクロもシーケンシャルな動きを記録するだけしか行わない人たちです。
②は、エクセルのマクロになじみがあり、場合によってはVBAもコーデイングできるレベルの人が構築する場合です。この人達が一番テンプレート型RPAツールの使用に向いています。但し、業務フローが単純でパターン化できる定型業務が主な適用範囲となります。
③点線の部分はテンプレート型に分類されるRPAツールであっても、スクリプトを組み込むことで、様々な処理に対応できます。しかしながら、スクリプトの適用できる部分が限定的で、スクリプトのコーデイングには、プログラミング知識が必要です。
一方、ROBOWAREに代表される開発型のRPAツールであれは、プログラミングできる知識レベルは必要ですが、単純作業から、複雑な業務まで広範囲にRPAの構築ができます。
しかも、APIを使ってコーデイングできるので、ロボット作成のための高度なプログラミング知識は必要ありません。
[関連]
RPA概説② RPA導入のために知っておきたい豆知識
G008 RPA2.0に求められること
RPA2.0を実践するために求められる事の一部を洗い出してみました。導入時の参考にしてください。
① 無人運転ができること
・PCの電源ONからOFFまで人の介入を必要としない
・キーボード操作、マウス操作
・画面上のグラフィックや文字の判別
・自動サインオン（ID,パスワードのセキュアな環境での入力）
・終了後の結果通知が自動メール可能
・業務の適用範囲が広いこと
② 環境に左右されず動作すること
・画面サイズ・解像度が変わっても、画面位置が変わっても（重なっても）正常に動作
・画面の色などの属性を判別できる
・様々なWebブラウザやアプリ画面に対応できる
・Windows、Linuxに対応できる
③ エラー時の対処を確実にできること
・DBのロールバック
・担当者へのエラー通知
・データ例外の対処
・業務エラー、システムエラー両方に対応
・複雑な条件判定も可能
④ 多種アプリケーション、特にシステム連携の自動化、意思決定の自動化と連携できること
・AIや、IoTにも連携
・アプリケーションの種類を限定しない
・WindowsのAPIを利用可能
⑤ ITガバナンスの配下に置けること
・権限外の人が作れない
・ID等により動作が制御できる
⑥ 人間の作業を軽減すること
・時間制限がなく働ける
・既存業務とまったく同じ動きができる
・ロボット用に業務フローの変更を必要としない
⑦ コスト削減できること
・人件費に対して大幅なコストメリットがあること
・維持費が少ないこと
・リカバリーコストが少ないこと
・バージョンアップ費用が少ないこと
⑧ スケジュール実行ができること
・週次、月次、日時指定ができる
・手動実行可能
⑨ 修正やカスタマイズが簡単なこと
・業務フローの変更に迅速に対応できる
・画面のレイアウト変更に対応できる
・変更管理がしやすい
⑩ リモート管理ができること
・遠隔地からの実行指示
・監視、ログ収集
・標的型攻撃に対策が打てること
・複数ロボットの管理ができること
⑪ ロボット同士の連携ができること
・ロボット同士の通信、データの受け渡し
⑫ 稼働環境の変化にバージョンアップ等で迅速に対応できること
・OSやWebブラウザのバージョンアップに追随
・各種連携アプリケーションのバージョンアップに対応
⑬ セキュリティ対策が取れること
・企業のセキュリティポリシーに合わせた対策が取れること
・ソースコードの管理がセキュアに実施できること
・ログ収集が業務レベル、システムレベル両方でできること
・知識ベースへログが渡せること
・サイバー攻撃対策がとれること
⑭ ロボットの適用範囲が明確であること
・使用制限、アクセス制限がかけれること
・管理責任が明確化できること
⑮ ライセンス管理が徹底されること
・コンプライアンス対応できること
⑯ 維持・運用が容易であること
・予防保守、ツールのバージョンアップの対応がしっかりできること
・ツールのサポート体制が信頼できること
⑰ 品質管理
・開発メーカーの品質管理がしっかりしていること
⑱ リスク対応計画に応じた設定ができること
・事業継続プランの配下に入ること
・冗長化、フェイルオーバーが可能なこと
・バックアップ／リカバリを自動設定できること
⑲ スケーラビリティがあること
・拡張性がある
・テクノロジーの進化に追随できる
⑳ 画面上操作（フォアグランド）と仮想PC（バックグラウンド）の両方で稼働できること
・確認、リカバリのし易さを優先するか、処理速度を優先するか選択可能
・柔軟性があること
㉑ インフラ投資がほとんど必要ないこと
・既存PCのみでも稼働できること
・ロボット通信用にネットワークインフラやサーバを特設する必要がない
㉒ 高度なロボット知識がなくても開発・運用ができること
・開発方法は、汎用的であること
・専用の教育や体制が必要無いこと
これらの内容を満たすためには、ROBOWAREが最適です。
[関連]
G007 RPAとRPA2.0
RPA概説⑤ RPA2.0を加速するソフトウェアロボット開発
G007 RPAとRPA2.0
RPA（Robotic Process Automation)は、ソフトウェアロボットが業務プロセスを自動化することを指します。
主にWebやオフィスツールなど複数アプリケーションの連携が必要な単純作業の定型業務をソフトウェアロボットが代行してくれます。
具体的な説明については、RPA概説①をご参照ください。
バックオフィス業務に代表されるホワイトカラーのルーチンワークを自動化出来るソフトウェアロボットは、人手不足解消、業務効率化や品質向上などを目的に多くの企業で採用されております。
これほどまでにRPAが流行しているのは、プログラミングなしにPC作成を自動化できるRPAツールのおかげで、オフィス業務を自動化することが身近になってきたためです。
ただ、プログラム開発せずにシナリオやフロー作成のみで行える業務処理には限りがあり、人間の経験に基づく判断や、臨機応変に対応すべき業務を自動化することは困難でした。
RPAツールの多くは条件分岐やエラー処理などの複雑な処理を組み入れることを得意としていません。それゆえ、パターン化できるデータ量が多い単純な繰り返し処理などで効果を発揮するものの、簡単にシステム化できる業務以外はほとんど自動化できないという問題が残りました。
つまりRPAの適用分野は、定型業務にほとんど限定されてしまうということです。
この問題に対して、次世代のRPA2.0は、AIやIoT、様々なアプリケーションと連携することで非定型業務の自動化を実現します。
そのためには、多種多様な条件分岐や、エラー発生時の処理など複雑な内容であっても対応できるソフトウェアロボットが必要です。
ROBOWAREは、開発型RPAツールなのでこのRPA2.0を実現できる数少ないソフトウェアロボットです。
多くのRPAツールは、自動化の設定をいかに楽にできるかを優先したため、フローやシナリオ作成などGUIによる開発方法を採用しています。この方式で、無理やり複雑な処理を組み込むとかなり膨大になってしまいかえって分かりづらくなってしまうという欠点があります。また、GUI化のために処理をパターン化しているため、使用できる機能に制限ができてしまいます。つまり、適用できる業務範囲が限られてしまうのが現状です。
具体的な説明については、RPA概説⑤をご参照ください。
従来のRPAで活躍している定型業務の中で、シーケンシャルなタスクとして自動化できるPCの単純オペレーションであれば、QuickROBOで実現できます。
複雑なオペレーションのRPA2.0に対応するには開発型のROBOWAREAが必要ですが、QuickROBOのジョブもROBOWAREから呼び出すこともできるので、両方の良い部分を組み合わせて構築すれば、とても効率的にロボット開発が行えます。
[関連]
G008 RPA2.0に求められること
RPA概説① RPAって知っていますか？
RPA概説⑤ RPA2.0を加速するソフトウェアロボット開発
G006 汎用プログラミング言語を使用するメリット
ROBOWAREは、ソフトウェアロボットですが、他のロボットと同様指示をしなければ動きません。
多くのロボットは、ロボットへの指示を簡単にするために、独自のGUIやスクリプトを採用しているものが多いです。
しかしながら、指示を簡単にすればするほど、できる動きが制限されるのと、そのRPAツールの専用の指定方法を覚えなければなりません。
一方、ROBOWAREは、Ruby、PHP、Java、C#の4種類のプログラミング言語を利用してどのように動かすのかを指示できます。
これにより、これらのプログラミング言語でシステム開発したことがある方は、そのままの知識で使用でき、ロボット独自の動きはAPIを追加で利用するだけです。
つまり、使い慣れたテキストエディタもそのまま使用して、たとえばRubyであれば、今までのRubyのプログラムと同様に.rbのファイルを作成し、サンプルを参考に編集して実行すればROBOWAREを動かすことができます。
ROBOWAREは、動かしたいPCに常駐して待機しているイメージになるので、ROBOWARE用に作成したRubyのプログラムを実行するだけで、指示通りに動きます。
ROBOWAREが、自分を動かすのにこうしたプログラミング言語を利用しているメリットは、多種多様な複雑な業務にも対応できるということです。
従来、ハイレベルなプログラミング技術が必要であったPC操作の動きも、ROBOWAREのAPIを使って、引数に情報を渡し、指示することができます。
ソフトウェアロボットのフレームワークとして、基本となる枠組みがすでにできているので、１からプログラム開発するよりは、圧倒的に少ないコーデイングで、楽に簡単に開発できます。
プログラミング経験がある人は、特段覚えることが少なくロボット開発が可能になります。
しかも、従来のプロクラム開発の手法がそのまま使えるので、既に作成していたユーティリティやコードもそのまま使用できます。
たとえばRubyGemsなどの公開ライブラリも含め、サードパーティのツールやオープンソースも使用できるため多種多様な処理をそのプログラムに組み込み、ソフトウェアロボットの動きに簡単に連動することができます。
また、ソースコードの運用やセキュリティ方針も他のプログラム同様の管理ができます。
かつて、プログラミング言語は数えきれない種類の方式が作成され使用されていましたが、現在ではほとんど使用されなくなった言語もあります。
そのため、4種類の言語を理解できるROBOWAREは、マルチリンガルと同様に自動化したい業務の特性に応じて臨機応変に対応できるだけではなく、今後発展が続くロボット開発の中で、使用できるスクリプトのライフサイクルの終焉を迎える時のリスクの軽減にもなります。
[関連]
G003 API
G005 QuickROBOが必要な理由
QuickROBOは、ROBOWAREのオプションツールです。
QuickROBOは、開発型ツールのROBOWAREとは違い、プログラミングが必要なく、PCの操作方法を記録するだけで、マウスやキーボード操作等が自動化できます。
とはいえ、業務操作の手順に精通しているのは、もちろん業務を担当している方で、プログラム開発の担当者ではありません。
そのために、操作がワンパターンの作業があったとしても、それを自動化するための打ち合わせの手間や、他の優先事項のため、結局自動化のシステム開発が進まず、手作業に頼っている業務がたくさん残ってしまっている企業が数多く存在しています。
多くのRPAツールがそうであるように、プログラムなしに自動化を簡単に実現できるツールは、どうしても自動化出来る作業範囲に制限が出ます。
そこでQuickROBOでは、割り切って機能を限定してPC操作の自動化のみに特化することで、短時間に簡単に自動化をできるツールを目指しました。こうなると、エラーが起こった時の処理など、複雑なことは自動化出来ないのですが、機能を限定したことによりプログラミング経験がない人でも、操作方法を覚えれば簡単にPC操作の自動化ができます。
必要に応じて、条件分岐や他のPCとの連携などは、システム開発者にお願いしてQuickROBOで作成したジョブをROBOWAREに組み込んでもらうことができます。ROBOWAREには、QuickROBO用の専用APIが用意されていますので、ROBOWAREのプログラムから、QuickROBOで作成したジョブを起動できるため、複数のジョブをタスクとしてつなげたり、特定条件に合った場合だけ実行したりするような処理が可能になります。
QuickROBOは、PC操作の自動化すべき業務を検討する場合おいて、簡単に作成できるので、テスト的にプロトタイプを作ることが容易になります。このことは、自動化する時のリスクを確認する上で重要です。どの部分を自動化して、どの部分を手作業に残すべきかを机上の考えだけで判断するよりかなり具体的に精査することができます。
そして、意外と繰り返し行われているPC操作の中には、エラーの対処を事前登録しておかなくても大丈夫な処理も多いです。QuickROBOでは、完全自動化を目指すのではなく、現在行っている業務の一部で、自動入力が可能そうな処理だけQuickROBOに行わせるというのも業務担当者には有効です。複数の特定サイトやエクスプローラーを起動したりする必要がある業務は、起動までの事前準備のみをQuickROBOに任せるだけでも、十分楽になります。オペミスも減りますし、QuickROBOを動かしながら、机上の事務作業を行う余裕ができます。
いままでは、これくらいのことはと自分でやろうと、わざわざ自動化の仕組みを作る手間を考えたら後回しになっていたPC処理も、覚えてしまえば他の人に頼らずQuickROBOで簡単に自動化できるので、やっぱり自動化してよかったと思う処理が増えるかもしれません。
[関連]
G004 ROBOWAREの販売について
「ROBOWARE」は、弊社シーイーシーカスタマサービスの登録商標です。（登録第5932207号）
開発元の製品名称である「Robowiser Framework」について、株式会社シーイーシーカスタマサービスは「ROBOWARE」の名称で販売する本製品につき、使用許諾権を保有しております。
ROBOWAREは、RPA(Robotics Process Automation ）をコンセプトとし、グリッドコンピューティングの実現とグリッドネットワーク上に配置したコンピュータをソフトウェアロボット化を目的としたコンピュータ制御に特化した人による運用手順を自動化支援するため、国内メーカーにより開発されたソフトウェアロボットのフレームワークAPIです。
ROBOWAREは、ソフトウェアロボットのフレームワークであるRBF Professionalと、ロボットを動かすためのジョブを統合管理するRBF Managerの2つで構成しています。
このほかに、オプションの操作記録型ツールのQuickROBOがあります。
ROBOWAREは、株式会社シーイーシーカスタマサービスが販売元となり、ROBOWAREパートナー が、販売・保守をしております。
ロボットの開発や導入の支援、他のツールと組み合わせたソリューション提案は、ROBOWAREパートナーを中心にご提供しております。
トライアルの申し込みや、導入のご相談は、ROBOWAREパートナーにお問い合わせ頂くか、CCSプロダクトサービス事業部の問い合わせページ経由にてお願いいたします。
[関連]
G003 API
ROBOWAREは、ソフトウェアロボットへの指示を簡単に行うために多くのAPI(Application Programming Interface)を実装しています。
ROBOWAREで使用しているAPIは、プログラミング言語で記述する場合にマウスやキーボード操作のようにロボット独特の動きの指示をROBOWAREへ簡単に行えるようにするためのインターフェースです。
通常プログラミング言語で使用するライブラリにあるクラスや関数などで提供されるソースコードの部品群に似ておりますが、ROBOWAREのAPIは、ROBOWAREが導入されていなければ実行できません。
ROBOWAREは、APIを利用することにより、簡単にロボットの動きを指示することが可能なので、高度なロボット開発の知識がなくても、比較的簡単にロボット開発が可能になります。
[関連]
T003 APIの種類
G002 ソフトウェアフレームワーク
G002 ソフトウェアフレームワーク
ROBOWAREは、ソフトウェアロボットを開発、実行するためのソフトウェアフレームワークです。
ソフトウェアロボットは、業務作業を自動化したいPCにROBOWAREをインストールするだけで簡単に導入できますが、人型ロボットと同様、ROBOWAREも予めどのように操作するかを設定しておかなければ動きません。
通常ロボットへの指示は、独自のテンプレートやスクリプトを使って行われますが、ROBOWAREは、複雑な業務にも対応できるように汎用的なプログラミング言語のRubyやPHPなどを利用して指示を与えることができます。
従来ロボットの開発は、高等な技術力がないと難しい分野でありますが、このフレームワークになっていることにより比較的簡単にソフトウェアロボットの作成が可能になります。
[関連]
G001 ソフトウェアロボット
G001 ソフトウェアロボット
ソフトウェアロボットとは、産業用ロボットや、人型ロボットのように、人間の代わりをするハードウェアを持ったロボットに対し、主にPCにインストールすることによりPC操作を自動化するためのソフトウェアを指します。
ソフトウェアロボットは、Digital labor(デジタル労働者）とも呼ばれ、人の操作に代わって、PC操作の自動化を実現します。
このソフトウェアロボットが、業務プロセスを自動化することをRPA(Robotic Process Automation)と呼ばれています。
ソフトウェアロボットは、産業用ロボットのように油を注入したり、長く保つために磨いたりする必要はなく経年劣化の心配はありません。（導入先のPCの保守は必要です）
産業用ロボットの多くが、肉体労働の代行をしてくれるのに対し、ソフトウェアロボットは、事務系のPCオペレーションなど頭脳労働に強いです。
ソフトウェアロボットのことを、「ソフトロボ」と略して表現している記事を見かけますが、Soft roboticsという柔らかい素材で作られた専門分野のロボットのことと紛らわしいため、シーイーシーカスタマサービスでは、RPAで活躍するデジタル労働者を「ソフトウェアロボット」という言葉で表現をさせていただいております。
[関連]
G002 ソフトウェアフレームワーク