業務システムの歴史から考える RPA の未来③（2010年代）
前回までの記事はこちら。
今回は 2010年代を振り返ります。
いよいよ RPA が登場！
これまでのあらすじ
- 1990年代までに、現在の業務システム、つまり企業向け（エンタープライズ）ITの基本的な構成要素はだいたい揃ってきていた
- 2000年代に突入し、業務システムの調達コストは（表向きは）大きく下がり、業務システムの乱立、短納期化、ITエンジニアの単価暴落を招いた
- しかし、実際に業務システムを作るのは決して簡単ではなく、業務システム開発プロジェクトは納期を達成できないことが多く、そのしわ寄せはITエンジニアに集約され、IT企業は合コンしたい企業ランキングの上位から陥落した
つまり、あの頃、オレがモテなかったのは、Javaのせいだったんだよ！
業務システムの歴史: 2010年代の振り返り
2010年代: クラウド時代
SOA
2000年代の後半から、SOA（サービス指向アーキテクチャ）
という禅問答言葉が業務システム界隈で流行りだしました。
いまだに良くわかんない言葉ではあるのですが、大きく
まとめると以下のようなことなんだろう・・・と理解してます。
- 業務システムの中身を分類して、それぞれの役割分担を明確にすることで、業務システムをわかりやすく、維持しやすくする。たとえば、画面（フロントエンド）の層とか、ワークフローの層とか、システム連携の層とか、ID管理の層とか・・・
- 前の記事でも説明した通り、業務システムはバラバラになる一方なので、これらを Web API で接続して、ひとつの業務システムを仮想的に成り立たせる
「いや、違うぞ。SOA というのはなぁ・・・」
という方、いらっしゃると思います。
すいません、私はそーゆー議論、もうたくさんです。
続きは、錦糸町の南口の立ち飲み屋でやってください。
あ、北口のホルモン屋もいい仕事してますよ。
新しい何かは産まれないと思いますが、気は晴れるはずです。
個人の見解ですが、前者（業務システムの中身を層別する）は、
それなりに価値があったと思います。巨大な業務システムを
わかりやすくする、という意味でも良かったですし、
以下のように、層ごとの特徴を捉えて業務システム全体の
戦略も考えやすくなったと思います。
ただ、後者（業務システムを Web API でつないで統合）は、
部分的な成功にとどまった印象があります。
前にこの記事でも書いたんですけど、
API って、そんなに万能ではないと思います。
純粋に API のバリエーションが問題になることもあるし、
それぞれの細分化された業務システムでデータの構造や
ライフサイクルの考え方が違ったりするので、
API で連携すればつながる、というのはいかにも机上で
自称アーキテクトが言いそうなこと現実的には、
なかなか難しいところもあります。
BPM
SOA が盛り上がり、そして主に意味不明なためしぼんでいく
中で、それに代わる概念っぽく現れたのが BPM（ビジネス
プロセスマネジメント）です。
BPM は前身の BPR（ビジネスプロセスリエンジニアリング）
を改善した手法として出てきました。
BPR は 1990年代に出現し、流行ったものです。
ハマーとチャンピ―って聞いたことあります？
・・・ない？
大丈夫！そんな旧石器時代の偉人の名前を知らなくても、
現代を生きていくことは可能です。
BPR も考え方は良かったんですけど、いざやろうとなると
大人数のコンサルが入ってきて、ひたすらお絵描きをし、
その絵を大会議室でつなぎ合わせて講評するという美術
展覧会が開かれてしまうため、莫大なお金がかかるよね、
ということで多くの企業がしり込みしてしまう結果になり
ました。
BPM は、BPR よりも小規模かつ高速に PDCA を回せる
ソリューション、という触れ込みでした。
ただ、業務システムそのものをターゲットにする BPR と
異なり、結局は業務システムの外側の営みなので、
その効果には限界があったと思います。
BPM は、いまでは高速開発ツールとか、LCD
（低コード開発）の分野で生きていると思います。
ワークフローとか画面とかを、GUI でペタペタやると
作れちゃう、みたいな話ですね。
前の記事で書いた通り、業務システムはバラバラに
なる一方なので、それらをつなぎ合わせる需要は高まる
ばかりです。
一方で、業務システムとしてパッケージ、SaaS を
導入しても、業務とのギャップは依然として発生するため、
そこを埋めるための仕組みが必要です。
そういった需要にこたえるための BPM の活用は、
いまでも盛んにおこなわれています。
・・・あれ、EUC と親和性があるな、と感じます。
実際、BPM ツールで EUC をやるアプローチも増えた
と感じてます。
デスクトップ上での EUC（VBAなど）と比較して、
成果物はサーバ側、場合によってはクラウド側に残るので
集中管理が可能ですし、クラウドなら技術的なアップデート
もされていくはず！
（一方で、廃止になるのが怖いですが・・・）
躍進するクラウドサービス
前の記事でも述べたように、2010 年代は
クラウドサービスが躍進しました。
クラウドは、業務システムのビジネスを大きく変えようと
しています。前の記事で業務システムの価格が下がった、と
書きましたが、それでも業務システムの構築で儲けられたのは、
基盤のマージンとか、その後の保守運用で元が取れたからですが、
クラウドに移行すると基盤のマージンは薄くなり、保守運用も
一部/全部、クラウドサービスから提供されることになります。
もしかすると、クラウドサービスが隆盛すると、業務システム
構築がますます儲からなくなって、採算ラインを割り込むのでは
・・・？という意見もあります。
ただ、やはりクラウドは基盤の話が中心の印象です。
業務システムの上物であるアプリの世界では、それほど
大きな革新は見られません。
マイクロサービス、サーバレスのような言葉も、
これまでのアプリの概念から大きく逸脱はしていません。
コンテナ化の技術とか、課金の形態などは異なりますが、
業務システムを構成するアプリケーションの基本的な
枠組みは、クラウドだけでは変わらない印象です。
2010年代の Blue Prism
Blue Prism の沿革（2010年代）
さて、Blue Prism の歴史も併せて、振り返っておきます。
2010年代はこんな感じです。
- 2012年: Pat Gearyが RPA（Robotic Process Automation）という言葉を発明する
- 2013年: 米国にオフィスを開設。Gartner Cool Vendor に選ばれる
- 2014年: 間接販売モデルがスタート。Ver 4.2 リリース
- 2016年: ロンドン証券取引所のAIM市場に上場
- 2017年: 日本オフィスを開設。Ver 6.0 リリース
- 2018年: ミュンヘン、パリ、シンガポールなど、グローバル展開の加速
- 2019年: Thoughtonomy を買収。Blue Prism World Tokyo 2019 を開催
ようやく RPA（ロボティックプロセスオートメーション）という
言葉が登場しました。
RPA はどういった場所に用いられてきたか
この連載でも再三、書いていますが、業務システムにおいては、
以下の需要がますます、高まっています。
- 業務システムはバラバラになる一方なので、それらをつなぎ合わせる必要がある
- 業務システムとしてパッケージ、SaaS を導入しても、業務とのギャップは依然として発生するため、そこを埋める必要がある
この２つの考え方は、重なり合いもあるのですが、
これらの需要をカバーするための仕組みが必要で、
そこに RPA が使われているのだと思います。
以下は RPA について調査したレポートからの抜粋です。
LSE（ロンドンスクールオブエコノミクス）の
レスリー・ウィルコックス教授と、
ミズーリ大学セントルイス校のマリー・ラシティ教授の
論文から抜粋しています。
（論文の全体はここから入手できます）
ここでもわかるように、ERP や CRM でカバーしきれなかった
ところを、マンパワーではなく RPA で・・・という現実が
あることがわかります。
（もちろん、あんまり右に行き過ぎると RPA の対象範囲外ですが。。）
なぜ RPA なのか
この記事でも書いてますが、2010年代初頭から、
こういった領域は BPM などを使って、EUC ライクに
システム化を進めていました。
しかし、 API の下りでも書いたように、BPM では
細かいところまで手が届かず、本格的なシステム開発に
近い工数と時間がかかってしまい、採算が取れず
マンパワーでカバーしている領域が多くありました。
そこで、より細かい自動化を行っても採算が取れる
RPA が注目され始めたわけです。
以下は、同じ論文の記述を絵にしたものです。
細かい自動化は、RPA（Blue Prism）の方が、
圧倒的に採算性に優れています。
（3.6倍！）
RPA の真の位置づけ
ただ、非常に重要なことなのでハッキリさせておく
必要があるのですが、
画面操作を自動化する、従来よりも採算性の優れた自動化ツール
・・・というだけでは RPA とは呼べない、と考えています。
Blue Prism の歴史にも書いたように、上記だけであれば、
2000年代でも達成は可能でした。
2010年代になって出てきた RPA とは、単なる画面自動化
技術だけを指しているわけではありません。
個人の意見になってしまいますが、RPA とは、
- 画面自動化技術を用いて人間の操作をなぞるように自動化を行う
- 人間と同じようにユーザーIDを持ち、専用の（仮想）端末上で動作する
- 専用の（仮想）端末上では、必要なときに必要な時間だけ稼働し、稼働が終了すれば全ての情報は（仮想）端末から消え去り、後続の自動化処理に（仮想）端末を明け渡す
という特徴を満たさなくてはならない、私はそう考えます。
一言で言うと、RPA に自律性が必要です。
こんな感じです。
なぜ、こんな特徴が必要なのか。
理由は、そうでないと、投資対効果がちゃんと出ないからです。
RPA で投資対効果を得るためには
画面自動化だけ出来れば良い、というケースだと、
個人の PC 上で動かすことでも達成は可能です。
では、個人が個人の PC で、個人の手間がかかっている
業務を自動化したとしましょう。
何時間かが削減でき、効果は上がるでしょうか。
・・・多くの場合、効果は上がらない可能性があります。
たとえば、８時間＋１時間の残業をしている人が、
RPA で２時間分の自動化を行ったら、その人は残業が
なくなり、さらに１時間分を高付加価値な業務に
割り当てられるでしょうか。
私も以前は、それが「可能だ」と考えていました。
しかし、最近、多くの RPA 組織のリーダーと会話させて
いただいて「やはり難しいケースが多いのかもしれない」
と思うように至りました。
結局、現場レベルで工数削減をしても、他の業務や
何やかやに忙殺され、組織全体、会社全体としては
何も変わっていない。
日本はジョブデスクリプションが不明確で、出来る人に
仕事が集中してしまいがちです。現場だけでの自動化は、
現場で小さな凹凸が発生するだけで、大きな視点で見ると
変わらないのではないでしょうか。
あなたの会社がRPAを導入したとする。
— Enterprise Blue Ocean ◮ (@EnterpriseOcean) September 21, 2019
もちろん従業員にRPAツールを配って
削減時間を積み上げるやり方だ。
アンケートを取ってExcelで
削減時間を集計したら、
20,000時間削減！
スゴイじゃん！
で、会社は、業務は、
どう変わったんだ？
何も変わってない。昨日と同じ今日。
削減時間はどこへ？？
RPA を使って、きちんと投資対効果を出すためには、
業務を、組織を、会社を変えていく必要がある。
そのためには、先ほどの RPA 専用の（仮想）端末に
自動化した仕事を寄せる。そこできちんと削減時間を
見ていき、定型業務の繰り返しから解放された従業員
に高付加価値業務を担当していただくために、戦略的
な転換を行っていく。
ここまでやって、はじめて本当の RPA の真価が引き出せる。
だからこそ、これが本当の RPA の定義だと私は考えます。
主な出来事
- Anne Thomas Manes が記事「SOA is dead」を公開（2009）
- Phil Gilbert の BPM 2010 Conference での基調講演「The Next Decade of BPM」（2010）
- AWS 東京リージョン開設（2011）
- Pat Gearyが RPA（Robotic Process Automation）という言葉を発明する（2012）
まとめ
- 2010年代初頭に、SOA、BPM が流行。一定の効果を収める
- 2010年代はクラウドが躍進。業務システム構築のビジネスに変化
- 2010年代に RPA が登場。ただ、RPA＝画面自動化ツールでは、最終的な投資対効果は大きく望めない。自律した RPA こそ、真の RPA の価値を発揮する
10年近く前、2010年代の初めに、Phil Gilbert の
The Next Decade of BPM を見たことを思い出しました。
（資料はこちらから）
240:5:1 の図。
米国企業では、240人の業務ユーザーがいたら、
5人の情シスがいて、1人の常駐プログラマがいる、
という比率の話です。
240人のデジタル化、システム化要望を、5人では
到底受けきれないし、1人のプログラマはもっと無理。
こんな世界をどうすれば良いか・・・という問いかけ
でした。
いまなら、RPA によって用意された自動化専用の
（仮想）端末、つまりデジタル従業員がそれを担う
と思います。
世界は確実に、前に進んでいますね☆
