IT開発とRPAのベストミックス

はじめに

みなさん、お久しぶりです。今回、Think ITで再度記事を執筆させていただきました。私は元々、エンタープライズ向けのIT開発、Webアプリやモバイルアプリ、金融や流通を中心に様々な業界でのシステム開発を経験してきました。これまで、昔ながらの日本式のウォータフォール型開発から、現在のトレンドでもあるアジャイル型開発にも挑み、何度も失敗を繰り返してきました。

マネージメントの側面では、日本国内の開発チームで請負側であったり発注側であったり、オフショアも中国、ベトナム、カンボジア、また、多国籍の開発チームを率いてプロジェクトを遂行するなど、幅広くやってきています。広く浅くではありますが、様々なIT開発や開発手法を経験し、試行錯誤を重ねてきました。

2年ほど前からはIT開発と少し距離をおき、UiPathでエンタープライズ向けのRPA導入支援に関する仕事に携わっています。また、最近話題の副業に関しても会社で新設された制度を活用して取り組んでいます。偶然ではありますが、UiPathや副業で久々にWebアプリケーション開発を行うことがあり、改めて現代のIT開発手法について考え直す機会がありました。

IT開発とRPA開発は、似たようで違ったり、近いようで遠かったりします。現在では、多くの事業会社がIT開発のみならず、RPAにも積極的に取り組まれていると認識していますが、企業の開発現場ではそれぞれ別のものとして取り組まれている方々が大多数ではないかと思います。

本稿では、RPA業界に身を置くものとして、IT開発プロジェクトをより確実に成功へ導くためにどのようなことができるか、RPAとIT開発のベストミックスは何かについて考えてみます。

昨今、DX(デジタルトランスフォーメーション)や働き方改革、業務改革という目的で、IT開発やRPAへの需要が非常に高まっていることを肌で感じています。加えて、現在、新型コロナウィルスの猛威により、我々の働き方も大きく変わろうとしています。この出来事は、一層のDX、働き方改革、業務改革を推し進める起爆剤ともなりうるでしょう。本稿の内容が、読者のみなさんにとってお役に立つと幸いです。

IT開発のトレンド

私は普段、RPA導入・開発の現場におり、ITという大きな領域の中で考えると、比較的プリミティブな方法での業務自動化に携わっています。例えば、Excelの明細データを基に、経費システムへ繰り返し経費登録する処理をソフトウェアのロボットで自動化して代行するといった内容です。

IT開発者の方からすると、RPAはローコード開発となるため、単純で簡単な業務の自動化に限られると思われていますが、最近は機械学習したモデルとRPAを組み合わせて高度な自動化も実現することもあります。

また、各業務ユーザにおける手元の処理の自動化を行うだけでも、大規模的に全社横断で行ったり、クラウド上で行うなど、いろいろと単純にことは進まず、学ぶべきことはとても多いです。

一方で、久しぶりにWebアプリケーションを作ろうと改めて最近のトレンドを調べると、「コンテナ」「マイクロサービス」「DevOps」…などなど、以前には存在しなかった用語がてんこ盛りでした。これらは以前からあった言葉ですが、いよいよ実用化や普及度が本格的に高まってきた来たのだとしみじみ感じています。

私が数年前にIT開発のプロジェクト・マネージャだった頃、オフショア先のベトナムの現地デベロッパーから、開発環境を分離するために使用していたDockerの良さをレクチャされましたが、そのときは結局自分では触らずじまいでした。

その頃、私自身は「Vagrant」という仮想環境をコード化して管理するツールを利用していましたが、今となっては運用・管理まで考えるとDockerを使用しなくてはなりません。当時も「Dockerにちゃんと取り組まなければ」と感じていましたが、これほどの市民権を得るとは想像もしませんでした。

私もトレンドに遅れまいと、今回新規にWebアプリケーションを開発する上で、以下の3つを踏まえた開発を行うことを目標としました。

• 「コンテナ」を使用して開発・運用
• 「マイクロサービス」をアーキテクチャとして採用
• 「DevOps」での開発とCI/CDの連携

結果としては、これら全てのキーワードを開発に取り入れて何とか実現でき、知識も少しは吸収できました。その知識とRPAで養った経験も合わせて、今後のIT開発の形、あるべき姿といったものが少し見えたように思ってます。

コンテナ、マイクロサービス、DevOpsといった昨今のトレンドとなる技術や開発手法を利用したIT開発を前提として、そこにRPAのテイストを加えた場合に、一体何ができるのか、また、どのような嬉しいことがあるのでしょうか。私の実体験をもとに紹介していきます。

最先端の金融に学ぶ

一部の読者の方は、コンテナ、マイクロサービス、DevOpsといったキーワードに対して、「海外でのIT開発のことだ」「国内でもWeb系サービス企業だけの話だ」と考えている方も多く、自社ではまだそんなやり方はしていない、という開発現場も多いのではないでしょうか。しかし、国内の事業会社においても、これら技術への適応が必要となることは必須であると考えます。

その理由は簡単です。それは、事業本体の競争力にも直結する問題だからです。特にグローバル金融大手でのIT活用は、その他の産業界より一歩も二歩も進んでいることは有名です。米JPモルガンでは、Web上で公開されている情報によると年間1兆円超もの金額が投入されているようです。彼らのライバルは金融業界の同業者というよりは、Google、AmazonといったいわゆるGAFAなどITの最先端企業のようで、実際にそのようにコメントもしています。

そのような企業が自己資金で行う株や債券、外貨の取引は、もはやIT装置産業と化しています。現代までの徹底的な効率化によりマネーゲーム化しており、IT化・自動化が高度に発達してきたという歴史があります。

数年前、短期間で繰り返し取引を行うHFT(高頻度取引)において、「あなたがまばたきしている間に数回のトレードが自動で終わっている」というものが話題になりました。そのときはLow Latency(低遅延)と言って、プログラムやネットワーク、ソフトウェア、ハードウェア全ての処理をいかに高速化するかを競い、時間の尺度としてはマイクロセカンドを競っていました。ちなみに直近ではピコセカンドとなっているようで、凄まじい進化です。

さらに、最近はFPGAという聞き慣れないテクノロジーも流行っているようです。これは「Field Programmable Gate Array」の略称で、ハードウェアであるCPU自体をプログラミング可能なものとして、ハードウェアレベルで業務への最適化が可能となる技術の適用も盛んに行われているようです。

私のお気に入りの話として『フラッシュ・ボーイズ 10億分の1秒の男たち』というマイケル・ルイスの著書で紹介されていたシカゴ証券取引所とニューヨーク証券取引所の話があります。アービトラージという取引手法では、特定の金融商品が複数の取引所で扱われている場合に、同じ商品で価格の差異があると、その価格差で儲けを生み出すことが可能です。要は「安いところで買って、高いところで売る」です。

ここで、他のトレーダーより多く儲けるためには、いかに早くその情報を取得し、売買を成功できるかが重要です。シカゴ証券取引所とニューヨーク証券取引所で電子的な取引をする際には、どの通信事業者も、いくつかの基地局の通信回線を経由する必要がありました。

2011年に、ある1人の天才が新しいアイディアを思いつきました。「シカゴ証券取引所からニューヨーク証券取引所まで、直線で回線を引けば良い」と。彼は会社を立ち上げ、出来得る限り、直線で両取引所を繋ぐための線を掘り、そこへ光ファイバ回線を通し、最短なルートを現実のものとしました。彼はその回線を利用する権利を複数の投資機関に売り、莫大な利益を上げたようです。

これはお金のためにやったことではありますが、金融業界の発展に貢献し、企業自身の競争力を上げたことは確かです。これにより、シカゴ証券取引所とニューヨーク証券取引所の価格差は、より早く自動で是正されているはずです。

また、少し話が変わりますが、ゴールドマン・サックスにおいては、トレーディングフロアのトレーダーはIT化の波により、500名から2名まで削減できたというニュースも話題になりました。

ここまで抜本的にビジネスが変わることは稀かも知れませんが、その他の業界や産業においても同じ道をたどっていくことはもはや必然と思われます。したがって、このような先端の業界のIT開発の手法を学ぶことで、今後のその他産業のIT開発も予想できるのではないでしょうか。

昔は株もブローカーへ電話をして注文を取次していました。我々の私生活でも、身近なところでは旅行の手配もインターネットでというのはもはや当たり前となっています。これもここ10年前くらいからのことで、最近ではレンタルビデオの利用も減り、オンラインの動画視聴が当たり前となるなど、これら不可逆的な変化は多々起こっていく一方です。

私自身もアプリケーション開発をしていた5年ほど前、ある人気レストランチェーンの予約アプリケーション開発で、前述のHFT(高頻度取引)といった次元でのレスポンスが求められたことがありました。結果として、食事にありつけるまで店頭で1〜2時間も待っていたものが、モバイル端末で予約をしてから来店すれば、すぐに食事にありつけるということを可能にし、神アプリとも称され、来店時にはほとんどの方に利用いただけるというDXの実現を経験できました。

GAFAといった最新のIT企業のみならず、金融業界をはじめとした事業会社、身近な会社でもIT技術者のニーズは高まる一方です。そのような企業でのIT開発の手法を学んでいくと、開発手法もアジャイル開発を採用し、コンテナ開発・運用を活用していることがわかりました。そのため開発サイクルも短く、早期でかつ継続的なリリースが可能となり、実用化されています。

このようなIT開発、ITへの投資が本業の結果を左右すると彼らは考えているようですが、ITでDXを実現しましょうという目的ではなく、企業としての生存競争に勝ち抜くためにこのような先進的な手法を取り入れています。したがって、傍からみるとDXを推進しているように見えるのだと思います。ただし、彼らとしては本業への投資としてのものです。

前置きが長くなりましたが、そこでのトレンドの大きな1つとして、Googleで開発、発展したコンテナ管理技の本格的な導入が開始され、マイクロサービスとしてのIT開発が標準化してきていると言えるでしょう。Kubernetesといったコンテナオーケストレーションツールや手法の技術革新において、アプリ開発者とインフラ技術者の仕事が分業化・効率化が実現可能となりました。DevOpsが実際に機能し、実用化されてきた時代となった感があります。

当然、コンテナやマイクロサービスの利用はDevOpsだけでなく、拡張性に優れている点、稼働環境を柔軟に変えられる点も大きいです。ひと昔前は新規サービスを立ち上げるにはハードウェア一式を慎重に見積もり、その上でのみ稼働させなければなりませんでした。性能拡張のためにハードウェアを追加することは、とても簡単にできることではなかったのです。

しかしながら、今やコンテナやクラウドの普及により、この障壁は一切なくなりました。さらに付け加えると、ファイナンスの観点として、ランニング費用に関しても、例えばAWSが高ければ容易にGCPへ移行することが簡単にできる時代となりました。場合によっては、オンプレの方が安ければ、オンプレに回帰し、そこでコンテナ化を進めるということも可能で、実際にそのような事象も発生しています。

IT開発とRPAのベストミックス

2019年後半、RPAはIT業界でバズワードとなり、盛んに話題となっていました。その頃と比較して、昨今のRPAのブームは少し落ち着いたのではないかと感じます。以前、「RPAはB級グルメである」としたWeb記事がありましたが、IT開発を本流のメインディッシュと捉えると、なんとなくしっくりくる言葉です。とは言え、IT開発で本流のメインディッシュばかり開発してしまうと、いくら短期でのデリバリを目指すと言えども、なかなかタイムリーに現場の業務部門の効率化は進みません。現場は今この瞬間困っており、疲弊していることが多いです。

メインディッシュを作るには、準備に膨大な時間を要しますが、B級グルメ的に気軽に美味しく食べられるように、一時的でも業務を改善、効率化できると現場では非常に助かるものです(B級グルメでも準備が大変だということは認識しています)。

事業会社においてDXは引き続き非常に期待されており、かつ2025年の崖もあり、IT投資は現在も活発に行われています。AIに関しては過度なブームは過ぎ、誤って認識されていたC3POやドラえもん的なものではないということが理解されてきたようです。やはり、IT開発における主要な投資領域は自社の基幹システムであることは事実ですが、ビジネスサイドである業務ユーザや経営層からは、働き方改革としてRPAが現在も非常に期待されていることも事実です。

自社事業での競争力を持たせるためのIT投資とは何かを今一度考えてみると、その1つの解としてはIT開発とRPAのベストミックスではないかと考えます。

IT開発において、業務ユーザから「本当に必要なのか」という機能の開発リクエストを受けることは多いです。少なくとも開発リクエストをくれた業務ユーザの役に立つことは明白ですが、企業としてIT投資の視点で見ると「本当は必要ない」ということも多いのが現状です。

かねてより、業務ユーザとの関係性構築を目的としたり、それほどの負担とはならないはずという判断でやりすぎたりして、プロジェクトの失敗や遅延の原因となるケースも散見されます。私自身も、かつて何度もこのような本筋でない箇所での開発の沼地にハマってしまい、とてつもない苦労を経験してきました。

IT開発において、本当に求められるものは何か。それは業務に必要なデータのトランザクション管理、マスタ管理をいかに正確に、早く行うかが最重要事項ではないでしょうか。1人のユーザが1年に数回見るといった帳票は、当然これよりプライオリティが下がります。また、システム本来のあるべき姿としても、原理原則に沿えばそのような要望はシステム側で取り込むべきものではありません。要望受入時はコストやプロジェクトへの影響は少ないようで、後々振り返ると結構インパクトがあったということは多々あります。これは皆さんも経験していることでしょう。

だからと言って、ユーザからの要望は無視しろということではありません。では、このような要望をどのようにハンドリングするべきでしょうか。

その答えにRPAがあると私は考えています。IT開発では、画面のみでなくAPIも合わせて開発して提供可能とします。正しくはフロントエンドとバックエンドとして、APIを前提としたアーキテクチャを採用します。業務ユーザは普段ブラウザの画面からWebアプリとしてそのシステムを使用します。システム側でAPIを提供することで、帳票を自動で作成しメール送信したいといった場合、APIを通して必要なデータを取得し、業務ユーザにRPAで自動化をしてもらいます。

API連携は、RPAの進化で専門的な知識をほとんど必要とせずに実装できてしまいます。なお、現時点ではRest APIで実装することが良いのではないかと考えます。未だにSOAPなどに出くわすこともありますが、その時点における最も標準的な実装方法を選択することで、IT開発側の開発者の実装・管理コストを減らします。昔ながらの実装方式を残してしまうと、新たな開発者が来ても、その知識がなければ大きな負荷となりえます。これからは人材の流動化も見据える必要があります。

ここまでをまとめると、IT開発の肝は本流となるトランザクションやマスタの機能を開発し、APIも用意しておくことです。RPAはそれを使って効率的な自動化、業務簡略化を目指すものとなります。RPAではUIの自動化も当然可能ですが、API連携は開発コストも低く抑えられ、安定性も優れています。