■サイト内検索:


RPA Biz > RPA > RPAの運用・管理のために担当者が意識しておくこと

RPAの運用・管理のために担当者が意識しておくこと

2018.07.10

RPAによる業務の効率化は、ここ数年で飛躍的に普及しています。

今後もますます拡大していくことでしょう。

自社でもRPAを導入して業務の効率化を図ろう、と考えている方も多いと思います。

 

ですが、急速な拡大は大きなリスクも孕んでいるのが世の常であり、

RPAによる業務効率化も同様にリスクを伴っている、と私は考えています。

 

特に、RPAのロボットの管理・運用において社内での統制が取れていないと、せっかく業務の効率化のために作成されたシステムが有効に活用されず、宝の持ち腐れとなる可能性があります。

 


 システムの開発を外部に委託できればいいかもしれませんが、運用を外部に丸投げできる会社はごく一部でしょう。

それらの会社を除けば、RPAの基本的な管理・運用は先ず自社の現場担当者が担うこととなることがほとんどです。

 

 現場担当者になることで一から覚えようと前向きに考える人もいれば、面倒な業務が増えたと面倒に感じる人もいるでしょう。

 

担当者がどう思うかは人それぞれですが、確実に言えるのは、導入を決定した人、

あるいは現場担当者がRPAの構造を知らないと、導入は失敗に終わることとでしょう。

 

そうならないためにも、RPAに関する知識を身に着ける必要があると考えています。

 

以前、他の記事でも、RPAを導入したものの、管理体制の不備における、RPAの「野生化」として警鐘を鳴らしている記事がございました。

 

 

■参考記事

生保や銀行で急速に普及する事務作業「ロボット」 保守怠ると“野生化”の恐れもhttp://www.itmedia.co.jp/business/articles/1807/03/news023.html

 

 

この記事を拝見し、以前勤めていた会社のことを思い出しました。

 

以前の会社で事務処理の合間に現状の業務をマクロ・VBAを用いて業務効率化を進めてきましたが、

ほとんど個人で使用する為の開発しかしていませんでした。

 

他の社員が行っている業務の効率化のために開発したこともありますが、改修・管理はこちらで行っていました。

 

 

全員のPCMicrosoft Office(Excel)が入っていたにも関わらず、実際にマクロやVBAを使って業務の効率化を考えていた人はわずかでした。

私個人としても、開発する時のルール等は特に考えずに作成しており、管理・運用のドキュメントも作成していませんでした。

 

 

ですが、転職先が決まって後任に業務を引き継ぐとなった時に、今まで作成したVBAの成果物も引き継ぐこととなりました。

マクロどころかExcelの関数も満足に扱えない人へ引き継ぐこととなりましたが、

とりあえず最低限の仕様変更の仕方を伝えることしかできませんでした。

 

 

後任者も、開発に関する知識がなかったこともあり、「ソースコードを見ただけで眩暈がする」と嘆いていました。

とりあえず体裁上は引き継ぎを完了としましたが、そのような形での引継ぎであったため、

もしかしたら、今はシステムが有効活用されておらず作業効率の低下を招いている業務があるかもしれません。

 

せっかく作成したシステムを管理・運用を怠って過去の遺産とさせないために、

現場等で適切に管理・運用する能力があれば、社内のシステムを最大限活用できるわけです。

 

 

新たにRPAの導入を考えている方だけでなく、今後プログラミングやシステム開発といった、

ITに携わりたいという方への心得として、システムの管理・運用に必要なことを取りまとめました

 

すでにご存じの方には、自身の行動と照らし合わせて振り返ってみてもいいでしょう。

特に、丸ごとアウトソーシングするのが困難で、

システム開発を個人で行うことが多い中小企業の現場システム担当者の方は知っておいた方が良いと思います。

 

 

・ルールを設けて運用する

 大規模プロジェクト等、複数名で開発する場合であれば必ず行っていることですが、

もし、一人で開発、運用する場合でも、必ずルールを決めて開発を進めてください。

 

自分なりのローカルルールでも構いません。

 

 

ルールを決めずに開発した場合、開発した当初は自分で把握していても、時間が経って改めてソースコードを見た時に、

そのソースコードが自分でも何をするためのプロジェクトかわからなくなってしまい、

最悪の場合一から作り直しになってしまいます。

 

 

これを防ぐために、個人で開発する時でも必ず自分なりのルールに基づいて開発をするようにしていきましょう。

もしルールを忘れてしまうようであれば、別途資料を作成しておくことも重要です。

 

 

・自作のプロジェクトの流れを説明できるようにする

当たり前のことと思いますが、意外とできていない方が多いように思います。

引き継がれたシステムは当時の担当者のルールの色が強くでています。

引き継ぎに関するドキュメントが丁寧に作られていたとしても、読むだけでも多くの時間を取られてしまいます。

 

個人で開発する場合、そのプロジェクトがどのような流れで遷移しているかを考えながら開発します。

その場合は、先ほどの「ルールを設けて運用する」ことが重要ですが、

今後社内の資産として適切に運用していきたいのであれば、どこかで必ず他の人に業務を引き継ぐ必要があります。

 

前任者は引き継ぐ時に、そのシステムがどのような流れを取っているかを説明する義務があります。

これができず、後任者が理解できなければそのシステムが適切に運用される可能性はかなり低くなるでしょう。

 

第三者へ説明するためのおすすめの方法としては、前述の、「ルールを設けて運用する」と合わせて、

開発と同時に第三者へ説明するためのドキュメントも作成してしまえば、

引き継ぎ時だけでなく、改修依頼等があった時も役に立つでしょう。

 

 

・プロジェクトの中身を定期的に見直し、必要に応じて改修する。

 開発が終了したプロジェクトを長期間放置してはいないでしょうか。

大規模なプロジェクトや他社が開発したプロジェクトの見直しは困難ですが、

自社開発した小規模のプロジェクトを見直すことは、非常に重要であると考えています。

 

 

 例えば、開発中に、必要な機能の中の一部がどうしても作成できなかった、あるいは妥協し、最終的に運用の仕方で解決してしまった機能というのがあったとします。

ユーザーが納得してくれれば会社としてはいいですが、エンジニア個人としては、非常に悔いの残る結果となります。

 

ですが、以前開発したプロジェクトのソースコードを改めて読み解くと、以前は妥協して作れなかった機能を実装したり、

煩雑化していたコードを改修して管理・運用しやすくなったというケースは多々あります。

 

 

たまたま、以前開発したVBAの改修の必要があったため、開発したプロジェクトのソースコードを一から見直したことがありました。

そのコードを読み解いていると、当時の自分が複雑な書き方をしていること箇所が多かった、と気づきました。

 

それらを改修することで、より理解し易く、管理しやすいプロジェクトとして回収することができました。

 

 

 特に私の場合、以前自ら作成したソースコードを読んで改修できる個所を発見できると、

「俺も成長したなあ」と日々の成長を感じながら改修作業をしています。

完全に自己満足の領域ですね(笑)

 

 

 上記いろいろと書きましたが、どれもすべて、仕事をするうえで当たり前のことじゃないか。と思う方も多いと思います。

まさにその通りで、システムの管理・運用といっても難しいことはほとんどなく、やり方さえ覚えてしまえば誰でもできるであろう業務なのです。

 

もし、それでもわからないという方がいましたら、まずはプログラミングをやってみることをお勧めします

プログラミング言語は数多くありますが、一番なじみやすい、という理由からVBAをやってみるといいでしょう。

 

業務用PCは一人一台がほぼ当たり前になっています。

また、WindowsPCを使用していれば表計算ソフトはほぼMicrosoft Office Excelでしょう。

 

VBAはMicrosoft Office ExcelPCに入っていれば誰でも学習することができます。

他の言語と違い、わざわざ開発環境を作成する必要はありません。

敷居が低いためか、VBAからプログラミングに興味を持つ方も多いです。

 

VBAをほんの少し学習するだけでも、プログラミングの構造やルールといったことは何となく理解することができます。

 

もし、システム管理の担当者になってしまった、と後ろ向きに考えているようであれば、

これを機に少し勉強してみてはいかがでしょうか。

きっと損はしないと思いますよ。

 

 

topへ
© RPA.biz