業務、作業の自動化に潜む落とし穴

仕様書が無いのは会社のリスク

私の勤務する国際物流の会社には何人ものRPA職人がいる。

それにしてもその職人たちの好奇心は本当に旺盛(笑)

その職人たちの好奇心と向上心からどんどんと新たな自動化ロボットが生まれているわけです。

周りのみんなも本当に助かっていると思います。

でもふと考えます。

「この人やめたらどうなる？」

そうなんです。その人がやめた後、突然動かなくなったらそれは会社のリスクなんです。

リスク回避の決定打

結論

最初に言ってしまうと、リスク回避の決定打は無いと思います。

出来ること

• 仕様書を作っておく。
• プログラミングができる人材を増やす。
• ITやシステムと連携する。
• 部署内でロボットを管理する。
• 業務フローを作っておく。

このくらいでしょうか。

とは言え、プロでは無いので、VBA、PowerShell、など複数のアプリケーションや言語を組み合わせて動く様なものは、仕様書があったとしても第三者が改修するのはかなり困難ですね。

UiPathの様にビジュアル的に可視化されたアプリケーションで、尚且つそれ単体で動くものなら、仕様書を元に改修する事もできると思います。

私の場合、作り手の責任として、最低限以下の二つは残す様にしています。

• 業務フロー
• 仕様書

ちょっとした会話の中から生まれるロボットたち

「ってゆーかさー、こう言う事って自動化出来ちゃわないもんかね〜」

なんて事を雑談の中で聞いてしまうと、思うや否やプロトタイプを作って見たくなってしまうのがプログラミング大好きな人たちのサガ。

まさにこう言うところから凄いものが出来てくるのだけれど、この事が先述の仕様書の事に大きく関係する。

仕様書が先か？作るのが先か？

本来、アプリケーションは仕様書を元に作るものだと思いますが、RPAの場合少し事情が異なりますよね。

多くの場合、自然発生的に生まれたものを膨らまして形にする事が多く、結果的に仕様書の無いロボットが量産されてしまいます。

因みに、私の職場で決まっているRPA作成のフローはこんな流れです。↓↓↓

• 作業者にインタビュー
• 業務フローを作成
• 上長に確認
• 仕様書を作成
• 実際のRPA製作に着手

でも、実際はなかなかこの通りにいきません。

でも、せめてプロトタイプの段階、まだあまり時間をかけていない段階で一度チーム内で必要性や方向性の確認をするべきでしょうね。

そして、絶対この段階で上長も入れるべきだと私は思います。

例え、その上長がプログラミングについての理解が無くても、そうする事でリスクに対する理解は深まりますから。

業務フローは本当に大事

『喉もと過ぎれば熱さ忘れる。』

またまた出てくるこの言葉。

そうなんです。

動かなくなった時、誰ももうその作業が出来なくなっているのです。

そして、突然RPAが不具合を起こして、動かなくなったら…

手順と注意点は、まだその作業が存在するうちに記録に残しておくべきですよね。