RPA怪談

ここに記載した事例は、企業の特定を避けるため、本質が変わらない程度に、脚色しています

1. 気になる御社に、熱烈アタック

オンラインの、ショッピングサイトを、運営している、Nさんは、毎日、競合ショップの、値段をチェックしていました。
ある日、ネットのRPAの記事を見て、これだ！と、ひらめきました。そう、スクレイピングで、ショップを巡回すれば、簡単に、値段のチェックができます。

Nさんは、RPAツールを導入し、見よう見まねで、スクレイピングを、自動化しました。

ところが。

ある日、とあるWebサイトの構成が変わり、スクレイピングに失敗しました。ところが、Nさんが使用したサンプルコードは、うまくいかない時、間髪をいれず、リトライするようになっていて・・・

「あれ、今日はうまくいってないや？」
何度もリトライして、機能不全になっていた、RPAツールを、停止して、Nさんはガッカリしました。

数週間後。

「競合会社の、Webサイトに、DoS攻撃を仕掛けた」容疑で、警察に呼び出しを受けた、Nさん。
会社も巻き込んだ、大騒ぎになったそうです。

教訓

エラー処理は、きちんとしましょう。特に、リトライすべきかは、エラー内容によって、考慮が必要です。わからなければ、リトライは禁物です。
トライ＆エラーとは、いいますが、動作をきちんと把握していない、サンプルを、本番運用しては、いけません！

2. 「やはり、最後の敵は同じ人間だったな」（『新世紀エヴァンゲリオン』より、冬月コウゾウの台詞）

R社では、従来、人材派遣会社から、派遣されてきた、社員に、経理作業の、多くの部分を、依頼していました。

ある日、偉い人が、言いました。「派遣社員から、RPAに、置き換えたら、安くなるのでは？」

さっそく、コンサルティング会社や、SI会社が呼ばれ、一大プロジェクトとして、経理の業務の、自動化が行われました。

4月。新たなRPAシステムの、カットオーバーです。
5月、6月と、順調に動き、4半期の計算も、問題なく動きました。

また、ステージング環境を使い、昨年度のデータを入れたところ、正しく動いています。

「これはいい、大幅に人件費が削減できるぞ」

経営陣は大満足です。

そして翌年の3月。

経理部門の、上から下まで、真っ青になりました。期末決算の数字が、どうにもおかしいのです。
あわてて社内総出で、臨時のアルバイトも使い、手計算でなんとか仕上げましたが、かかったコストは目も当てられません。

「どうしてこうなった？」
当然、検証が行われました。心躍る春も、ゴールデンウイークも、消し飛ばして。

そして、わかったことは。
コンサルティング会社が、経理を担っていた派遣社員から、ヒアリングした作業の中に。
何人かの、担当者が、無理矢理、帳尻をあわせていた部分があり、それに気がついた、チェック担当の、派遣社員が、そこを修正していたのです。
ところが、ヒアリングは、チェック担当には、きちんと行われなかったのです。何しろ、作業さえ移植すれば、RPAは、動くと思われていたので。

「修正してもらっていたなんて、知らなかった」と、唯一、連絡がとれた、元・派遣社員は、言いました。
それが本当なのか、サボタージュだったのかは、誰にもわかりません。何しろ、もう、ヒアリングした他の派遣社員たちが、どこで何をしているか。把握している人は、関係者にいないのですから。

教訓

ヒアリングベースだけでなく、特に金銭や法令に関する業務は、きちんと整合性をチェックしましょう
「RPA導入後に、解雇される人」が、積極的かつ、親切に、RPA導入に協力してくれる、という考えは、捨てましょう

3. 最後まで読めなかった手紙

K社では、定期的に、顧客に、メールマガジンの配信を、行っていました。

内容のチェックは、いつも、厳密にレビューされてましたが、あるとき、BCCで送るべき、リストを、CCに設定してしまい、顧客のメールアドレスが、漏洩するという、事故を起こしてしまったのです。

これでは、大問題だと、社内で、対策を講じることになりました。

そして、メールの送信を、RPAで行うことで、送信先設定の、ミスを抑止する、ということになりました。

ところが。

最初の数回は、うまくいきました。

ところが、あるとき。特別ニュースも含む、特大号のメールを、送ったところ、多くの顧客から、「メール本文の、後半が消えている」という、連絡が殺到しました。
調べてみると、送信したメールが、すべて、そうなってしまっていたのです。

「なぜ？？？」担当者は、頭を抱えました。

同じメールを、試験環境で送ると、現象が再現します。

結果的には、RPAソフトウェアの、文章を記録する機能に、文字数制限があり、メールの後半が、そこでカットされてしまっていた、ことがわかりました。
ロボットは処理を間違えませんが、それはあくまで仕様の範囲でのこと、ということが、見落とされていたのです。

教訓

RPAのテストでは、最大値（文章であれば、想定される、最大の文字数。数字であれば、上限、など）を使うことを、必ずやりましょう。
使用するソフトウェアの、制限事項は、できればきちんと、把握しておきましょう。
レビュープロセスの、順番によっては、防げない事故があります。最初の、CCでのメール送信ミスも、含めて。

4. 「ロボットお断り」を、ロボットは、無視します

人材採用をしている、P氏は、ふと、RPAの可能性に、開眼しました。
「SNSで、特定の仕事や、業務内容、技術について、投稿している人を、リスト化すれば、お誘いをかけやすのでは！」

数日後

今まで築きあげてきた、SNSの人脈も、投稿データも、アカウント凍結で、失って。
おいしそうな料理や、楽しい仲間とともに、明るい笑顔で写真に写っていた、面影は、今のP氏には、ありません。

教訓
Webサイトによっては、RPAでの、スクレイピングや、投稿を、禁止していたり、制限を設けているサイトが、あります。
特に、SNSや、株価情報などのサイト、あるいは通信販売のサイトは、禁止されていることが、多いので、事前に、よく確認しましょう。

アカウント凍結だけで、済むとは、限りません。場合によっては、民事訴訟の、対象になる可能性すら、あります。

5. ワタシハロボット

RPAの、ソフトウェアは、基本的には、設定したとおりに、動きます。
言い換えれば、あらかじめ登録した、作業以外は、行わないものと、思われがちです。

「ロボットは」ですよ？

RPAの、ベストプラクティスとして、ロボットが使用する、ユーザーIDを、作成することが、推奨されています。

このID、実は、運用上、結構、いろいろな権限が、付与されるケースが、あるのですよね。
たとえば、ヘタな一般社員より、多くの社内システムに、アクセス権限があったり。
Windowsの、管理者モードでの、動作が許されていたり。

そして、RPA運用チームには、そのロボットの、IDとパスワードを、見られる立場の人が、いるのです。

ロボットが、不正な操作をしている、疑いがある、というので情シスが調査したら、ロボットのIDを使用した、人間によるものだった

という事件。気がついたから、よかったものの、意外と、盲点になりがちです。

教訓

可能であれば、ロボット用のIDは、一般のPCからは使用できないようにする
ロボット用の、IDでの作業も、定期的に監査する
ワークフローによって、複数の、サイト・機能を使う場合、できれば、個別にIDを払い出し、なんでもできるIDを作らない
ロボット用の、認証情報に、アクセスできる人を、最低限に絞る

最後に

RPAを、使っての、事故や、ヒヤリハットは、結構、いろいろな場所で、起きているようです。
皆さんも、慎重な運用と、安全な側に倒す開発で、ご安全に！