誤解だらけのRPA

::: note alert
この記事には毒が含まれています。摂取量にご注意ください。
:::

# はじめに

    Q: RPAって何ですか？
    A: パソコンの自動操作するやつ

みたいな **勘違い** が世間に蔓延してるので、順序立てて説明する記事を書こうと思いました。

あ、私は「パソコンの自動操作するやつ」みたいな回答は大っ嫌いで、特にITのプロフェッショナルであるべき立場の人がそれを言ってたら、容赦なくマサカリ投げ込みます💛

# 1. RPAとは何か
## 1.1 法的な定義はないのです
この問いには、ちょっと難しい要素はあって、別に「RPA is 何？」に、法的・公的な、いわば強制力のある定義があるわけではありません。

たとえば、食品なんかだと、[JISの規格](https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/shokuhin/jigyousya/shokuhin_kikaku/index.html)とか、[公正競争規約](https://www.caa.go.jp/policies/policy/representation/fair_labeling/fair_competition_code/industries/)とかあったりして、安直に品名を名乗れないケースがあります。

たとえば、私が愛してやまないカレーに関しては、
> カレー粉（純カレー、生カレー又はカレーパウダーともいう。）」とは、香辛料（カルダモン、メース、ナツメグ、クミン、ターメリック、コリアンダー等）を製粉混合したものをいい、「カレールウ」とは、カレー粉に小麦粉類、油脂及び調味料等を加えて製造したものをいう。ただし、調理済みのものを除く。

みたいな定義があるわけです。（[「カレー業における景品類の提供の制限に関する公正競争規約」※PDF](https://www.jfftc.org/rule_kiyaku/pdf_kiyaku_keihin/K004.pdf) より）

ですので、上記に当てはまらないものを「カレー粉です」とか言って売ると、その時点でアウトということになります。

しかしながら、最初に書いたように、「RPA」には、このような公的な（そして強制力のある）定義は今のところ、ありません。

つまり、極論してしまえば、パソコンのソフトどころか、「そこらへんに生えていた草」だろうが、「なんか転がってたきれいな石」だろうが、気分次第で「RPA製品」みたいな品目をつけて発表・販売することはできちゃいます。
買った側が「思ってたRPAと違う」と文句を言ったところで、「これはRPAである。私がそう判断した」と逃げちゃうことも、可能ではあります。（もちろん信用その他を失う可能性はありますヨ）


## 1.2 とはいえ「本来の」定義はあります
とまあ、「RPAを称するのは自由」ではあるのですが。

とはいえ、RPAも別に、無からいきなり湧き出た言葉ではなくて、提唱者がきちんといます。
最初に「RPA」という用語を用いたのは、Blue PrismのAlastair Bathgateです。そして「RPAとは何か」という点について、それより前からあった、デスクトップアプリ等の自動操作との違いとして、
> デジタルレイバー（Digital Labor）として機能すること

という点がコンセプトとして挙げられています。Laborは労働者・労働力みたいな意味です。
ではDigital Laborとは何かといえば、「DigitalではないLabor（＝人間の労働者）と同じように管理ができること」になります。

言うまでもないことですが、一般的に労働者は、多かれ少なかれ会社に管理されています。
この場合の「管理」は必ずしもネガティブな意味ではなくて、単純に安全のための保護だったり、成果の可視化だったりします。

つまり、単純な「自動化ソフト」と比較して、

- ITリソースの利用の許可や制限を、人間のユーザーと同じようにできる
- 全体的な作業のフローの中に、人間のユーザーと同じように入り込める
- 費用対効果（つまり人間で言えば雇用コスト、ソフトウェアで言えば導入コスト）で比較できる

みたいな部分まで網羅することで、まさに「ロボット」（RPAのRはRoboticです）としての意味合いを具体化したわけです。

というのが、RPAという言葉の生い立ちになります。

## 1.3 では「自動化するソフト」という言葉は正しいのか

**私は** 正しくないと考えています。前述のように、**既存の単なる自動化ソフトとの違い** を明確にした、もともとのコンセプトがあるからです。

言葉というのは時代の流れによって変わっていくものですし、技術の発展でも意味合いが深化、あるいは変化することはあります。
技術的な進歩によって、RPAに求められる要素が「増える」ことは、将来的にも十分、起きうることです。

ですが、マーケティング的な理由で、あるいは技術的にそこまで作れない等の、言ってしまえば **ズルい** ベンダーが、性能・機能的には全然足りない、「単なる自動化ソフトでしかない」製品を「RPAです」と言って売るのは、少なくとも誠実ではないと言わざるを得ません。

**まあ、マーケティングという観点でいえば、本来の語意にあわせた機能性を持つ他社製品を、機能で劣る自社製品と同じフィールドに引きずり落とすために、あえて同じカテゴライズを使うっていうのは有効なのかもしれません**　が、ユーザー側がそれに、わざわざ迎合する理由は本来はないのです。

だから、 *「RPAってただの自動化ソフトでしょ？」* とか *「RPAってデスクトップマクロだよね？」* みたいな勘違いが生じるのは仕方ないとしても、**それは違うよ**って話はきちんとしたい、ということです。

:::note alert
RPAを理解してるつもり~~らしい~~自称上級者でも、こんなレベルの人はいるので、見かけたらそっと離れましょう。あと自称コンサルとかにもよく居ます。
何ならITエンジニア（らしき人）でも、雑な理解でこんな感じになってたりします。~~知らないのは仕方ないけど、知らないものを知らないままdisったり軽視するバカにはマサカリ投げときましょう。~~
:::

# 2. RPAソフトにはどんな機能があるか

では、最近の **「ちゃんとした」** RPAソフトには、上記のような「デジタルレイバーとして機能するために」どんな機能があるか、というのを、ざっくり紹介します。
もちろん、一部はオプション機能だったりはしますが。

「どんな機能があるか」という点は、裏を返せば、少なくとも「これくらいできないと、RPAソフトを名乗るのおかしくない？」という要素でもあるわけです。

:::note alert
つまり、**「RPAはこんなことができるんだよ」** というのと、**「これくらいの機能はなきゃRPA名乗るな」** ってのがこの記事の趣旨になります。
:::

## 2.1 ユーザー・権限の管理
これはRPAに指示を出す人を管理する部分です。
人間だけの組織でも、それを「上下関係」ととらえるか「単なる指揮系統」とみるかは別としても、指示をする人や、指示を受ける人、あるいは指示を出す権限、みたいなものは、ほぼ必ずあります。それがないと組織が立ち行かなくなるからです。

RPAでも、自動化の機能を作る（実装する）人、それを使う人、管理する人など、役割は様々です。
運用していく上で、「この人はロボットを動かしても良いけど、動作を変えてはいけない」みたいなことは、往々にして生じるでしょう。

なので、RPAを使用するユーザーの管理や、それに紐づいた権限の管理は必須になります。

## 2.2 資格情報の管理

パソコンでの業務を自動化する際、「何かのシステムにID・パスワードを入力してログインする」という利用形態は、しばしば発生します。

ですが、これは多くの場合、使い方を誤ると、セキュリティ的なリスクを含むことは言うまでもありません。

たとえば、RPAで作成した自動化のフローに、IDとパスワードまで記載されていると、その動作をチェックする人や、偶然、動作しているのを見た人なども、認証情報を「知れて」しまいます。これは非常に危険なことです。

その辺の問題を最小化するため、RPAソフトウェア側で、認証情報は一元管理する機能が提供されています。

::: note warn
提供されていないのは、開発側が「提供する能力がない」か、あるいは「そんなの管理できないほどタコな運用しかできない」ユーザーを想定しているか、でしょーか。どっちにしてもダメでしょ、それ。
:::

必要なロボットが、（2.1で書いたように権限がある場合に）認証情報を取得し、使用する、という手順を踏むことで、想定外のユーザーが「ロボット用のIDやパスワードを使いまわせてしまう」のを防ぐわけですね。

これは他にも利点があって、たとえば、業務システムが「開発用のダミー環境」と「本番用の環境」にわかれている場合、RPAの自動化フローを作る人は、前者のID・パスワードを使ってテストします。
動作に問題がなければ、本番環境に作成した自動化フローを持っていくわけですが、RPAソフトウェアが「本番環境側には本番環境用の認証情報」を持っていれば、開発ユーザーはその差異を意識する必要がありません。
つまり、開発ユーザーは本番環境用の認証情報にアクセスすることなく、本番環境でも動くロボットを作成できることになります。
これは、特定の人が（ともすれば不必要なほど）多くの認証情報を知れてしまう、というセキュリティ的なリスクの軽減ができます。

## 2.3 アセットの管理

アセット（Asset）は資源とか資産とかいう意味合いで、IT関連だと、情報等の話にも用いられます。
これを、自動化を実行するロボットに、状況に応じて割り当てる機能です。

たとえば、2.2 にも記載したように、開発環境と本番環境がわかれているときに。
アクセスURLや、選択すべき項目など、状況によって変わるけど、業務プロセスそのものは同じ、なんてことは普通に起きうるのです。
そのために、「開発環境のときに使うデータの一覧」「本番環境のときに使うデータの一覧」みたいなものを持たせておけば、開発環境から本番環境に移動するとき、わざわざ書き換えが不要になるし、書き換えミスによる事故も防げます、ってことです。

## 2.4 OSへのログイン

**最低限のIT管理をしている会社なら** 、OSのユーザーは社員ごとに割り当てているはずです。何か問題、あるいはセキュリティ事故等があったときに「誰が使っていたか」は非常に重要な要素です。

::: note warn
というか、それすら管理できてない会社は、RPAとかいう前に、別の部分をきちんとしろって話なのです。が。
:::

さて、RPAソフトウェアが「Digital Labor」として動作するには、RPAソフトウェアに割り当てられたOSのユーザーでログインして操作する、というのが、ある意味、必須な要素になります。
だって **他人のユーザーでログインして作業するとかありえないっしょ？** っていうのは常識ですよね？

PCの操作をしていて、何かイレギュラーがあった場合、というのは。
たとえば **「オンラインバンクにログインして本来と違う金額を振込した」みたいなヤバげなインシデント** があった場合ですよ。
「誰が操作していたか」って、めっちゃ重要なわけです。その時に **「RPAソフトがやっていた」か「人間がRPAソフトのフリしてやってた」かを確認できない** って、端的に、**組織としてめちゃくそヤバい**よね？ってことです。（本当に起きたらどーするのかしら）

もちろん、最近ではRPAの使われ方として、人間と協調する（Attended Robotとか言われるやつ）こともあり、その場合は不要ですが。でもまあ、RPAをRPAとして本格的に使うなら、基本的には上記の機能が必須になります。
あ、物理的にPCに電源を入れるのは、流石に物理のキーを押す機能とか必要になるので、ソフトウェア単体で完結するのは難しいにせよ。（Wake on LANみたいな話はややこしくなるので割愛）

## 2.5 自動で順次、タスクを実行できる

「自動で」と書くと語弊がちょっとあるかもしれませんが、要するに「指示を出されたら、割り当てられたパソコンで自動的に動く」ってことです。
わざわざ人間が物理的なパソコンに行って実行ボタン押さなきゃいけないようなら、それって「ボタン押してる人が仕事してるだけ」で、DigitalなLaborじゃないよね？

いやまあ、朝1で起動すれば必要なこと適宜やってくれる、ぐらいなら、人間のLaborでもそういう人は多々いるので、別に変らないと思いますが。
指示を出すだけで動いてくれなくて、物理的に何かしないと動き出さない労働者って、~~ぶっちゃけ役立たず~~ちょっと困ると思うんです。

あと、「今やってる作業が終わったら次はこれやっといてね」みたいな管理も、~~単細胞で使えない人でなければ~~人間の労働者はナチュラルにやってくれます。
そういうのもRPAソフトウェアが管理して、作業を順次やっていく（何なら重要度による割り込みとかもこなす）ぐらいは、きちんと対応できてほしいですよね？って話です。

:::note warn
ま、人間でもロボットでも、キャパシティを超えたタスクを投げれば破綻するので、管理者（管理職）がきちんとしていなければ、機能の持ち腐れになります。
:::


## 2.6 監査できる

RPAソフトウェアが「いつ」「どんな作業をしたのか」を一元的に管理できることは重要です。だって、誰が何やったかわからないって、それめっちゃ困るわけで。
あと「作業に成功したかどうか」も含めて、一元的に管理して、監査（あるいはレビューとか、確認とか、言い方は何でもよいのですが）できないと、特に金銭管理等が絡む自動化は不安が残るでしょう。

これは単純に「ログを出力できれば良い」みたいな話**ではなくて**、記録の改ざんが現実的には困難であることや、その「監査する」作業も誰でもできるわけではなく、しかるべき権限の人だけができる、といった要素まで含みます。

わかりやすい例を挙げれば、オンラインバンキングの振込を自動化してBotにやらせているケースで、「誰に振り込んだか」みたいな情報を、監査機能で誰彼関係なく見れてしまったら、それって個人情報その他の管理として非常にヤバいわけです。
なので「監査ってログ見ればよいんでしょ？」みたいな簡単な話ではなくて、きちんと独立した機能として必要になります。

## 2.7 業務フローの更新・変更管理

製品によってプロセスとかワークフローとかBotとか色々言い方はありますが。
RPAソフトウェアの実行部分は、要するに「自動化のために作った動作の定義」みたいなモノに従う形で動作します。プログラムみたいなものですね。

これらは、言ってしまえば、人間が作業する場合に使う「手順書」とか「業務指示」みたいなものに該当します。
それを「いつ変更したのか」とか「誰が変更したのか」を確認できたり、場合によっては「新しい手順が間違ってるから巻き戻す」みたいな管理ができないと、そのうち「何をやってるかわからなくなる」みたいな事態につながりやすくなります。




## 2.8 実行状況の可視化

これはむしろ「Digital Laborだからこそできる」ことなのですが、実行状況の可視化というのがあります。
「ロボットが、どんな業務を、どれくらいの頻度・回数で、どれくらい時間をかけてやっていたか」みたいな情報を可視化できる、というモノです。

人間だろうとロボットだろうと、組織として雇用・維持するにはコストがかかるので、成果がそれに見合っているか、確認できることは重要です。
もしコストに成果が見合っていなければ、追加でタスクを振るとか、既存の業務に必要な時間を短くなるよう~~調教~~教育するとか、クビにするとか、色々な選択肢が出てくるからです。

# 最後に

**だからRPAソフトと、単なる自動化ツールは違う**って、いい加減に理解しやがれ！

って2日に1回ぐらい毒づいてる気がするので、この記事を書きました。
もーちょっと世の中の理解が進むとよいなーと思います。~~あとRPA自称してるけど性能がダメダメなソフトは、そろそろ退場してほしい。RPAという概念や、ちゃんと真面目に取り組んでる製品への冒涜じゃん。~~