RPA勉強＆LT会！RPALT vol.13で登壇してきました。
最初はちょっとしたデモをやろうと考えていたのですが、「スポンサー以外は製品紹介NG」との通達がありまして、ちょっとネタ方向に振ってしまいました。（とはいえ課題感としては自分の知る範囲で問題だと思っています。）
どちらかというと女性が活発に活動されているコミュニティーで、大破した戦車のスライドという大技をキメてきましたが、ドン引きされていないことを切に願いばかりです。
RPAに関するニュースも「作業時間を90％削減！」といった派手なニュースが躍る昨今ですが、自動化導入周りの話を聞いてみるに、それなりにトラブっている様子がうかがえます。ツールのバグとかはご愛嬌として、メンテナンスの考えがすっぽりと抜けてしまっているのが気になっていました。
ITのプロの方であればご承知の通り、プログラム、システムは大勢に長い間使われてナンボという世界です。起動回数が多いほどエンジニアの作業は報われるわけですし、世界規模で使われるものであれば多額の報酬さえも手に出来るというわけです。
国内でのRPAのマーケットの立ち上がりが、どうしても抜本的なシステムの刷新が困難な状況で、現場レベルでの作業改善といった文脈で行われる事が多いため、どうしても情報システム部門やエンジニアの関与が通常のシステム導入よりも手薄になりがちです。（例えば、受発注処理で紙・FAXの伝票をシステムに転記するとか、他システムのデータをExcel経由で連携するとか、そもそもであれば業界挙げてEDI導入するとか、基幹システム間のデータ連携をする必要がある所を、ユーザーサイドでRPAツールを入れて手作業を効率化するなど）
あまりシステム構築・運用の経験が薄いところで導入されたツールは、作って動かして短期的なメリットが出れば、そこで終いになりがちです。ITの人が持っているシステムのライフサイクルの考え方や保守・運用の考えが抜けがちになります。（抜けてなければ、Windows7のサポート期限切れが、こんなに問題にならないはず）
で、何とかダマシダマシ使い続けるのですね。
結果として、ビジネス情勢や連携システムなどの環境が変わったとたんに保守出来なくなってトラブルになるというケースが起こります。私の所にも今年に入ってから２，３件、かつてのVB4や古いPerlで書かれたアプリ(20年近く前！)を何とかならんかと持ち込まれたりします。会社員時代にも「これがコケたら会社が終わりかねない！」といった古いバージョンで作られているが、非常に重要なプログラムの改修・試験を担当した事があります。大抵ドキュメントは無いですし、ソースを読んで理解しろ、実機があるからそれでI/Oを試せとか乱暴な事を言われがちです。さらに関係者がつかまるうちはヒアリングすれば何とかなることも多いですが、外注しているケースだと担当者の退職といった悲劇も何度か経験しています。
「システムは長きに渡り使われるもの」という認識があれば、きちんと資料を残し、適切にバージョンアップに対応するなどのメンテナンスがされてしかるべきです。特に直接に業務に関係するものであれば、なおさらです。
私の場合には、特にインフラ側の業務自動化を担当することが多いですが、それでも数々のトラブルを経験しています。エンドユーザー側のPCデスクトップを中心とした自動化の話を聞いていると、いろいろと心配になる話を聞くことも多く、このLTのネタに帰着したという次第です。
次に機会がありましたら、ゴリゴリに技術周りの事をやりたいなと思いますw