現在でも多くの業界で人手不足が深刻化しており、サービス業、特にIT業界の人材不足は深刻な状態が続いています。
最近はITエンジニアの有効求人倍率が8倍近くで推移し、IT系の会社はどこも人材採用に苦労しています。業界特有の人材流動性の高さもありますが、そこにつけいり高額の紹介料を求める人材紹介会社の存在もあります。
RPAをはじめとしたソリューションで、その辺りの課題に風穴を開ける事が出来そうな点をご紹介しています。
ITエンジニア不足が鮮明に
ITエンジニア不足は今始まったことではなく、私が知る限り常に人材不足状態です。労働市場全体の有効求人倍率も２倍近い状態ですが、IT関連人材に至ってはここ最近８倍の状況が続いています。
IT関連業界内での人材流動性はそこそこ高いのですが、流入が少なく、大企業の中間管理職などの一部に大量に人材が滞留しているのが日本全体の問題だと思います。
しかし、明らかに向いていない人がいるのも確かなので、日本の国際競争力を維持・向上していく為に、戦略的に人材を流動化する政策が必要なのだろうと私は思います。
RPAが起こしたIT業界の変化
RPAの話題になると、どうも業務を効率化して余った人員をリストラ・・・というイメージがありますが、IT業界にも大きなインパクトをもたらすのではないかと考えています。
プログラミングは不要に
これはRPAに限ったことではありませんが、クラウド化が進んだ事もあり最近はIT会社でもプログラムを記述するニーズが減ってきています。少なくなってきていると言うよりも、１からプログラムを記述する（通常スクラッチ開発と言います）事が不可能になりつつあるのです。
PCソフトでもOS自体がGUIになり、見た目、操作性を統一する意味でも、OS（基本ソフト）の開発元が用意したライブラリーと言う膨大な、ウインドウやボタン、チェックボックスなどの部品や通信関連などの機能がプログラムコード部品として予め準備されていて、これを自分独自のコードの中で呼ぶだけになっています。
クラウド環境になると更にプログラム開発する（出来る）部分が少なくなり、パラメータ設定だけで殆どの機能が出来てしまいます。
RPAになると、全くプログラムを記述する必要がなく、処理の流れをフロー図として書くだけでWindowsパソコンのあらゆるソフトウエアを自動化出来てしまいます。
追加開発を削減
また、RPAは日本のSI（システム・インテグレータ）の大きな収入源である追加開発を減らす方向になります。
パッケージソフトウエアに各ユーザ企業特有の機能を追加開発する機能として次のようなものがあります。
◆ 画面・レポート開発を削減
多くの日本企業では、管理職は実際の現場業務を殆ど知らない傾向があります。管理職は全て現場に聞かないとIT導入が出来ないため、必要な機能を現場に確認すると、現場としては少しでも仕事が楽になるように必要そうな画面やレポート全てを要望します。
しかし、RPAが自動でPC画面に向かって作業する事を前提にすると、多少使い難い画面でも、必要な項目が複数のレポートや画面に分散していても現場は気になりません。
◆ I/F開発を削減
もう一つよくある追加開発がシステムと別のシステムの間をデータ的につなぐI/F（インターフェース）と言われる機能の開発です。これもわざわざ柔軟性を失うプログラム開発をしなくても、RPAがシステム間をつなぐことができるため、不要になってくるものと思われます。
IT業界での自動化を加速
◆ コーディングの自動化
これもRPA以前から進んでいたことではありますが、RPAも実は裏でプログラムが生成されています。RPAのシナリオを作成する場合、業務フローを一段詳細化したプログラム・フローに近いものを作成しますが、このフローの部品をドラッグ・アンド・ドロップした時に、対応するプログラムブロックを挿入します。
これによってフローを作成すると最終的にはプログラムが裏で生成される仕組みなのです。通常のプログラム開発でも今後、この様なプログラム開発のスタイルが主流になっていくのかも知れません。
◆ テストの自動化
通常、大規模なシステム開発を行った場合の後の工程として、業務シナリオとあり得る業務パターンを網羅したデータを準備し、人手で全てのシナリオ＊データパターンのテストを行います。
これこそ正にRPA向きな作業です。データが準備され、あるべき動作シナリオに沿って正しく動くか繰り返し入力と出力をRPAが検査できます。
◆ ドキュメントの自動化
これまでの大規模システム開発ではウォーターフォールと言われる開発モデルで、先ず業務要件を確認して、基本設計、詳細設計と開発すべき機能に関するドキュメントが先行して完成します。
このやり方を今でも行っているのは日本だけだと思いますが、RPAの場合は業務ユーザーが自分の業務の流れをRPAシナリオとして作成し、そのフローをドキュメントとして抽出する事でドキュメントにすることが可能です。このほうが合理的だと思われます。
その他にもRPAでERPのアドオン開発を代替する事の利点が様々あります。
RPA導入では業務部門が主導権を握る
RPAでの業務自動化が主流になってくると、ITエンジニアでなくても良い時代になってきます。特にSI（システム・インテグレーター）に丸投げしてきたような大企業も、業務部門のユーザー自身が主導して導入できるのがRPAのため、高い費用を払ってSIの依頼する必要がなくなります。
将来的にはAI機械学習による更なる業務自動化が視野に入ってきています。AIを実業務に適用しようとすると、どうしても外部のSIやコンサルティング会社に丸投げでは不可能なところに行きつきます。
AIに学習データとして与えるには、自社の業務をよく理解した業務ユーザーが、取得可能なデータの業務的な意味合いを明確化し、データ間の因果・論理を整理する必要がありますが、殆どの会社にはAI学習に十分なデータがないのです。
データ自体がない訳ではありません。データはどこの会社に行っても、沢山保存されている事が殆どです。無いのは、AIに学習データとして与えて意味があるデータなのです。
データ間のビジネス的な因果・論理が明確になっていて、必要な、同期したタイミング・間隔、精度（粒度）のデータが必要なのであって、やはり、最初から目的を明確にしてAI学習を前提に蓄積したデータでないと意味をなさないようです。
その意味でも、従来のIT会社に丸投げ発注しか出来ないIT部門ではなく、業務部門が今後主導権を握って進めて行かざるを得ないのだと思います。
ITエンジニア自体・処理能力を増やす方法
オフショア開発を積極的に実施する
大規模なプログラム開発がどうしても必要な場合は、日本で日本人が行う必要もないような気がします。
但し、言語の問題があるため、ブリッジSEと言われるバイリンガルのエンジニアをオフショアとのコミュニケーションの間に入れる必要がありますので、それなりの開発規模が前提になります。
他の業界・職種からのスキルチェンジ
先にも書きましたが、RPAや最近のシステム開発ではプログラムを書く事はめっきり減ってきていますので、大学で情報工学や理系の学部を出たような人でなくても良いような気がしています。
システム的にはExcelマクロが書ければ十分なので、むしろ業務ユーザーに寄り添い、業務の流れをよく知る派遣社員などのほうが向いているのかも知れません。
まとめ
これらのように、ITエンジニアの業務（プログラム開発、テストなど）を軽減する面と、ITエンジニアの供給を増やす両面でRPAはITエンジニアの人手不足を軽減出来そうです。
そして、RPAの導入プロジェクト自体も業務ユーザーが主導するスタイルにならざるをえないと思われますので、これらの業務ユーザの業務をサポートするビジネスエンジニアに近いITエンジニアと、単なるプログラム開発ではなく、幅広いIT・業務知識を持つ専門性（スキル）が高いエンジニアに二分されていくのではないでしょうか。
