見出し画像

社内RPA担当者はビジネスアナリストの役割を担っていく人材となる

「デジタル時代のプロセス変革リーダー
Process Visionary 著:山本正樹・大井悠」
昨年発刊されたこちらの書籍。テクノロジーをビジネスプロセスに落とし込む変革専門の人材を指しているのがビジネスアナリストだ。米国や欧米では既にビジネスアナリストの立場が確立され、各社で実際に仕事をしているらしい。彼らの仕事は事業戦略や現場の現状から課題を見出し、ソリューション候補を見つけ出す。関係部門とIT部門の間に立ち、要望の吸い上げ、プログラマやエンジニアと詳細を打ち合わせてゆく。

現在日本ではRPAが注目を浴び、銀行や役所を筆頭に多くの実績を上げている。現状ではRPAを取り入れている多くの企業がRPA専門チームを作っている、もしくはアウトソーシングに頼っている。社内で各部署にRPA担当者となる場合は専属要員ではなく、兼任であることが多い。今回は社内でRPAと業務の兼任をしている人はビジネスアナリストとほぼ同じ仕事が出来るということをお伝えしたい。

日本のDXは遅れている。RPA導入がなかなか進まないのも日本の業務工程がマニュアル化されておらず、RPAに落とし込みにくいなどの理由が挙げられてきた。ここに一石を投じたい。ただ単にITに関する知識不足なのではないか。元も子もないかもしれないが、他国を見ているとそう言わざるを得ない。私は事務の仕事をしながら自身の面倒な仕事を自動化したいと思っていた。そんな中偶然RPAを見つけ、部署で一人RPA担当者となった兼任者だ。ある程度RPAを開発出来るようになってから気付いたことがある。RPA以外のシステム改訂時など、情報システム部との打ち合わせがスムーズになったという点だ。CSVで取り込みが出来るよう依頼を掛けた時、私達はてっきりシステム上ボタンが設けられ、クリックするとファイルを選択するウィンドウが開くものだとばかり思っていた。しかしながら提案されたのはメールにCSVファイルを添付して送信する仕様だった。一瞬戸惑った時、担当者が「表面上変えるのが・・・」と言った瞬間に理解した。UIを変えるのに時間がかかりすぎると。メールを入口とすれば何も変える必要がない。こちらの業務としてもRPAにファイル添付とメール送信をするだけとなる。

全くITに詳しくない状態からRPA開発に携わるようになった人ならお分かりだと思う。私達はRPAを学ぶことでプログラマの大枠だけを理解した。その事でコードは理解出来なくとも業務プロセスの可視化、工程のフロー化、コーディングの前段階を理解することになった。工程のフロー化までいけばエンジニアには分かりやすい。条件分岐が複雑になればなるほどやりにくく、別の方法を模索してみる価値があるなども私達には理解出来る。つまり、今までいなかった現場とエンジニアを繋ぐ役割を既に実務として行っているのが現状だ。

ビジネスアナリスト人材を育成する目的で新たに採用を行う、外部に依頼する。それよりも内部人材にRPA教育を行い、各部署で兼任してもらう。当然時間は掛かる。現状の業務負荷そのままにのしかかる業務となるので負荷分散には協力をしなければならない。ただし、最初の1~2年で彼らが育てばその後引き継がれてゆく。そして何より彼らは現場業務に精通している。自動化以前に抜本的な業務改革が必要か否かの判断も出来る。内部人材でビジネスアナリストの役割を担うことは企業にとってメリットが大きい。

今までRPA内製化肯定派はあまりいなかったように思う。
日本の未来にはIT人材が不可欠であり、効率的に進めていくには知識を持った人材で少しでも業務を分担することが必要だ。IT人材という一括りで全ての業務を押し付けてしまうのではなく、現場、半IT人材、エンジニアとシステム化、自動化への流れをスムーズにすることが出来る。DX推進をおままごとではなく本物のDXへ推し進める手立てとなるだろう。

この記事が気に入ったらサポートをしてみませんか?