はじめに
ロボットを新規作成する場合、はじめに作成するロボットのタイプを選択する必要があります。
選択できるのは上の図にあるように ベーシックエンジンロボット(以降 BER)
か ロボット
のいずれか。
現行の BizRobo!では全てのロボット1が BER
から処理を開始し、そこから ロボット
を呼び出す構成なので、「とりあえず BER
でロボットを作り始めたけど、どういった基準で ロボット
に処理を切り出すべきかわからない」と戸惑う方が多いと思います。
本記事では ロボット
をより効率的・効果的に利用していくための参考として、2つのロボットの使い分けについて、その特徴と考え方を解説しようと思います。
本記事は、BizRobo! v11.4.0.3 時点の情報を基に解説します。
戸惑いの原因 ①:必要性
BizRobo! のソフトウェア的発展の歴史を振り返ると元々は BER
のみが機能として存在し、RPAという言葉の登場や用途の広がりに伴い ロボット
が後から追加されました。
それゆえ、BER
と ロボット
の間には重複機能も多く存在し、古くから使用しているユーザほど BER
への造詣が深く、ロボット
で作る必要あるの?という混乱も大きいと感じます。
表現を選ばずに言えば、ガラケーで満足しているユーザにスマホの魅力と可能性を熱く語ったところで
- 必要以上に難しくねぇ?こんなに機能使わんし。。
- バッテリーの持ちが悪くて、全然使い物にならないんですけど。
- 電話もメールもガラケーでできるし、スマホは不要。
と感じた感覚にも近いかもしれません。
ガラケーで事足りている人へ無理やりスマホの押し売りをすることは、システム的な効率性や効果性、信頼性やコストなど、様々な技術的必然性からは正当化できる部分があるとしても、利用者の使用要件やUX上の必然性とは別の話であり、「使っていただくことに価値がある」という考えをベースに置くと、技術の移行っていうのは時間がかかるし、一筋縄ではいかないなぁ、と感じます。
戸惑いの原因 ②:名称の遷移
今でこそ(v11.3 以降)名称が BER
、ロボット
で確定した感がありますが、ここに至るまでにはバージョンを追うごとに名称が変わり、利用者を戸惑わせてきた経緯があります。
名称の移り変わり
バージョン | BER | ロボット |
---|---|---|
v10.7以前 | ロボット | (DAステップ)2 |
v11.1 | Webオートメーションロボット | DesktopAutomationロボット |
v11.3以降 | ベーシックエンジンロボット | ロボット |
ご覧の通りです。利用している製品のバージョンによって同じ ロボット
という言葉の指す対象が入れ替わっているように見えます。
(実際には v10.7 以前で BER
+ロボット
が同一ファイルとして構成されていたものを「ロボット」と呼んでおり、 v11 にてファイルとして分割したうえで、v11.3 で再度 ロボット
という名称を緑のロボットへ返却したことにより、それ以外の部分について BER
と呼ぶようにしたという作り手目線では一貫した変更なのですが。。。)
利用者にとっては非常に分かりにくい変更であり、ゆえに BER
のことを DS
3、 緑 ロボット
のことを DA
4 と呼ぶことが慣習化されてしまいました。これについては現時点においては完全に間違った呼び方で、将来に向けてもミスリードを招く呼称なので、個人的には即刻使用の中止を呼び掛けたい衝動に駆られます。
少なくともオペ改チームが所属するプロダクト&サポート部内では、青いロボットはBER
、緑のロボットは ロボット
緑のロボット
新しい方のロボット
と呼んでおり、ロボットのタイプではなく、ロボットを作成する開発ソフトウェアの事を DS
、リモート端末のデスクトップ画面を操作する ロボット
の事を DASロボット
を呼んでいます。またロボットをサーバサイドではなく、端末サイドで画面を占有して動かす「行為」のことを Desktop Automation(DA)
と呼んでいます。
BER
と ロボット
の役割と範囲の違い
MC
からのロボット呼び出しと、それがどこでどのように連携して動作するかという観点からまとめた図が以下です。
現時点で BizRobo!としてリリースしている最新バージョンは v11.4 ですが、この時点では BER
はロボットで実行する処理の骨格として、ロボットで実装する ビジネスロジック(処理フロー) を担当し、ロボット
はフローの中で具体的に実行されるアプリケーション画面の操作(処理シーケンス) を担当します。
アプリケーション画面の操作(処理シーケンス) において、その対象アプリが Windows 用のデスクトップアプリである場合には ロボット
が DAS
を通じて端末をリモート操作することによりサーバ上で動作しているロボットと連携します。
既に確定している今後の流れとして、BER
を介すことなくMCから直接ロボット
を実行できるようになります。これによりビジネスロジックをあまり必要としない単純な処理については ロボット
のみ作成・登録すればよく、利便性は更に向上しますね。
BER
と ロボット
使い分け
あくまで考え方としてのガイドラインですが、以下のような視点で使い分けを考えてみるといいでしょう。
BER | ロボット | |
---|---|---|
アップサイド |
処理全体の制御 APIなど画面を伴わないIFの操作 小さなExcel票の操作 |
操作画面単位の制御 モダンなWEBの操作 デスクトップアプリの操作 大きなExcel表の操作 |
ダウンサイド |
モダンなWEBの操作 大きなExcel表の操作 |
入れ子になった条件分岐や繰り返しの制御 |
上記は RPA らしいアプリケーションの自動化・連携 の範囲で考えた場合の、v11.4 時点における単純な比較です。
コネクター
を使った機能性の向上や、Robot File System(RFS)
によるファイルレベルでの接続性・セキュリティの向上など、直近の追加機能や今後の発展性などを含む比較はしていません。あくまでそれぞれのロボットタイプの仕組み、役割に基づいた考え方です。
まとめ
限定された範囲での使用であれば BER
の方が現時点でも ロボット
より手軽で使いやすいのは確かですね。
ただそれは利用範囲を限定している(「モダンWebサイトは対象外」など)からこその簡易性でもあります。私の所属するオペ改の役割としては、製品をよりよくするための改善点を製品チームにフィードバックしたり、新たな使い方、工夫ができないかといった用途開拓を主な役割としており、ロボット
をもっと使いやすくするための提案は、今後も力を入れて継続していきます。
-
次のバージョンでは BER を介することなく直接 ロボットを
MC
から実行できるようになることが確定しています。 ↩ -
v11 にて
DesktopAutomationロボット
としてファイルが分割される以前は Desktop Automation ステップとして、BER
内にロボット
機能が内包されていました。 ↩ -
様々な文脈で利用される言葉であるためその点にも問題があるのですが、多くの場合
BER
の事がDSと呼ばれており「個別の操作端末を用意しなくてもサーバサイドで同時実行できるから」という理由が挙げられます。ですがDAS
に接続して動作する特定のロボット以外は、緑ロボット
でもBER
同様にサーバサイドで同時実行する仕組みであり、明らかに間違った認識です。 ↩ -
機能の成り立ちとしては外部端末を動的に操作する仕組みとして最初に実装されたこともあり、当初は
Device Automation
という名称がつけられ DAと呼ばれていました。PCやワークステーションに留まらず、携帯端末やIoTなど「あらゆるDeviceを操作対象とする」というビジョンから命名したものでしたが、v10.4 においてDesktop Automation
と名前を変えたのはビジョンよりも当時のトレンドであったPCの自動化にフォーカスして、マーケティング的な観点から「よりわかり易い名称に」という意図が働いたためです。それゆえに、Desktop Automation Service
を経由してリモートPCへアクセスするという機能全体から見たらほんの一部の役割が過剰にフィーチャーされ、間違った印象とともに定着してしまったのが現状のDAという言葉です。事実、ホストコンピュータのエミュレーションやLinuxなどのコンソール操作、Webシステムの操作や Excel の操作 など 緑ロボット
によりBER
と同様にサーバサイドで実行できる機能が「存在しない」かのように扱われる(実際は印象に残らず見落とされる)ことがあり、説明してもBER
との切り分けがうまくイメージできず、必要以上に ”DAはむずかしい” という言葉で結論づけられている印象です。 ↩