RPA と IT Automation
この記事はUiPathブログ発信チャレンジ2021サマーの10日目の記事です。
どーもこんちわー(低血圧)、UiPath エバンジェリストの市川です。
今日はワクチン接種の話!
…ではなく、RPA と IT Automation(IT 業務の自動化)について、私見をまとめてみました。
RPA に向いてる業務
唐突ですが、皆様
RPA に向いてる業務って何?
…と聞かれたら、どう答えますか?
今のご時世、「RPA 業務」とかで検索すれば、いろいろ出てくるので、その辺を適当に紹介しとけばオッケーな気もします(脱力)。
実際に検索してみると…はい、以下のような図が見つかりました。出典はForrester って書いてあるし、きっとちゃんとした調査結果なんだろう(たぶん)。
なるほど経理・財務(Finance & Accounting: 36%)が多いのかぁ…「RPA で経理業務の自動化」ってよく聞くし、納得ですね!人事(HR: 7%)や購買(Procurement: 6%)もあるんだねーふんふんなるほど。
んで、この図を見てると、いくつか追加の疑問がわきます。
Q1. そもそもなんで英語の調査結果が見つかるのか。RPA は日本でしか流行ってないはずでは?(よく聞く話)…日本以外の国も RPA に関心を持っているのか?
Q2. 財務・経理なんて ERP のど真ん中ではないか。海外は ERP を標準機能ののまま活用し、業務を ERP に合わせているのではないか(Fit to Standard)?なぜ、財務・経理の業務に RPA なんてものが適用されているのか?
Q3. IT(15%)が大きな割合を占めてるけど、IT 業務を RPA で自動化してる例なんてあるのか。RPA は IT スキルが不足している事務員向けの技術で、IT の業務は熟練のエンジニアが API で連携させているから、RPA なんて不要なんじゃないの?
どれも面白そうで、興味はわきますが、全部、書いていくと長くなっちゃうので、今日は Q3. RPA で IT 業務の自動化について深掘っていきます(Q1. Q2. についても、ちょっと触れます)。
API 伝説(神話)
ちょっと昔話になりますけど、私は元々、ERP の API 連携的な仕事を長くやってました。API といえば、いまは Web API、REST(ful) API が主流ですが、昔はとにかくいろんな方式があったものです(CORBA、EJB、SOAP、etc...)。
企業システムを API で統合していく考え方は15年以上前からすでにあって、企業システムの API をインターネット上に公開し、企業を横断して B2B の業務プロセスを統合していく…みたいな壮大な構想もありました。そのときに API の名前が被らないようにする(名前空間を衝突させないようにする)技術なんてのも開発されました(UDDI)。いまでいう API エコノミーを先取りしてますよね!
でも、ほとんど実現しませんでした 🤗🤗🤗
理由はいくつかありますけど、たとえば以下のようなものではないでしょうか。
1.API の数が十分にそろってない。多くの業務システムにおいて、一部の特殊なもの(EDI とか)を除くとインターフェースの多くを占めるのは画面(GUI)です。画面でできることを、すべて API でもできるようにする業務システムは少ないです。そういう要件がないと、わざわざ作らないですよね。
2.API の仕様が複雑で、連携の難度が高い。紆余曲折あって、現在の API 仕様は極めて自由に決めることができます。API コールをする際に引数(パラメータ)を設定する場合も、それを URL に入れるのか、リクエストのヘッダに入れるのか、ボディに入れるのか。特に決まりはありません。リクエストの中身を multipart/form-data にするのか、Base64 エンコーディングして JSON に詰めるのか…も自由です。同じことをやるうえで様々な実現方法があり、API の利用者は仕様の理解と連携方法に頭を悩まします。
3.API が完全に外部化されていない。これはかなりややこしい話で、うまく説明する自信がないですが、、たとえば画面についていうと、いろんな人が触る可能性があるので、内部の仕組みを知らなくても操作できるように、間違った入力でとんでもないことにならないように、様々な工夫がされています(入力のバリデーション、画面遷移。表示されたものを選んでからボタンを押す、など)。一方で API についていうと…もちろん、よくよく考慮されて作られている API もありますが、内部の仕組みを知ってる人でないと、うまく使いこなせない API も少なくなかったように思います。
まぁ、いろいろと API の難点を書きましたが、もちろん API の良いところもあります。一番のポイントは高速、リアルタイム性というところだと思います。
大量データ処理とかは、API によって得意・不得意が分かれそうです。また、API 仕様は変更されにくいって聞きますけど…どうなんでしょうね?
API が万能ではない時代には、ファイル連携がシステム連携・統合の手段の王道でした。(厳密には違うけど)FTP みたいな方式ですね。API なんて理想論、現実には枯れた技術のファイル連携…みたいなコメントは、もう本当に何度も何度も聞かされました。
API の技術って、ここ10年くらいで、そんなに大きく変わってないように思いますけど、いまはどうしてるんでしょうね?
システム開発・運用の現場に RPA を適用する
ちょっと API の話が長すぎですね(スイマセン)😉…API に難があるのはわかったし、だからこそ RPA みたいなものが流行ったんだろうけど、さすがに IT の世界、システム開発・運用の現場では、すべてが API で統合されて、RPA の出番なんてないんじゃないの?…と思われるかもしれません。
実際はどうなんでしょうか。私もすべての現場を見てるわけではありませんが、API ですべてが連携されて、全自動で動いているシステム開発・運用の現場は、そう多くないのでは?🤔…と思います。
既に述べたように、長く業務システムではファイル連携が使われてきましたし、そもそもシステム開発・運用が全自動化されているのであれば、なぜ管理コンソールといった画面が存在するのでしょうか?
スキルがそこまで高くない人向け、という側面もあるかもしれません。また、予算が十分にない小規模なプロジェクトは、手作業での運用を許容してるのかもしれません。
そういったロングテール部分は、RPA に適していると指摘されてきました。
つまり、ERP にすべての業務を合わせて標準化するというのが理想論であるように、API ですべてを統合して多様なシステム群をリアルタイムに接続するのもまた理想論であり、理想と現実のギャップが存在するのは経理・財務や人事、購買だけでなく、IT の業務も例外ではないのです。スキルや予算、あるいは他の理由で残っているロングテールな手作業の部分は、RPA で自動化して、効果を出す余地が大いにあります。
UiPath IT Automation
私の勤めている UiPath では、RPA で IT 業務の自動化をするために様々な取り組みをしています。
一番、わかりやすいのは UiPath Test Suite だと思います。UiPath のコア機能に、テスト自動化のための専用機能を拡張した製品です。
一般的な業務アプリケーション(SAP とか)やモバイルアプリのテストを自動化できます。もちろん UiPath で作ったワークフローのテスト、つまり RPA 自体のテストも可能です。
もう少し広い意味で、システム移行や運用・監視といった IT 業務全般を自動化していく考え方(UiPath IT Automation)もあります。
海外では様々な業務システム、自社サービスの開発・運用に広く UiPath が利用されています。RPA は日本よりも海外のほうが市場として圧倒的に大きいので、日本での IT 業務への RPA 適用と比較すると、かなり差があるように思います。
日本では RPA というと、とにかく経理・財務とか人事とか、本社機能の事務作業の自動化というイメージが強いですが、IT 業務にも RPA を活用できる余地があることが、ご理解いただけますと幸いです。
最後に宣伝
普段は Web セミナーもやってます。次回は RPA で売上を増やした事例をお話しします。
Twitter もやってますので、お気軽にご連絡ください!