「RPA （ロボティクス・プロセス・オートメーション）」のワナ
業務を効率化しようとしているのは、業務アプリケーション提供者側だけではありません。ユーザーも同様に、日々さまざまな業務改善の立案や実行、他社ツール導入などの努力を行っています。業務アプリケーションのユーザーの中には、RPA（ロボティクス・プロセス・オートメーション）と呼ばれる自動化ツールを導入している人も多いでしょう。
RPAとは、簡単に言えば（さらにウェブアプリケーションでの利用に限って言えば）、一定のルールで、画面の要所を自動でクリックしたり入力するツールのことです。
SmartHR導入企業における RPA 活用の例で言うと、SmartHR で年末調整管理を行おうとした場合、通常、従業員1人ひとりが別々のタイミングで提出する情報を個別に確認したうえで、各依頼ステータスを手動で変更する必要があります。
従業員が数十人であれば人力で対応可能ですが、数百人や数千人の従業員を抱える企業となると、限られた人数の業務担当者ではすべての画面操作を手作業で完遂することは難しくなります。そうした場合、RPAツールに「毎日特定の時間に新しい提出情報をチェックし、提出情報が特定の条件にマッチした場合のみステータスを変更させる」などの自動化をさせることで、業務担当者の負担を大きく減らすことができます。
例に挙げた「ステータスを変更させる」というアクションは、RPAツールが実際にSmartHR内の該当ボタン（ステータス変更ボタン）を操作することになります。RPAツールがどのように該当ボタンを判別しているか。大きく分けると、下記のパターンに分類されます。
- HTMLのアトリビュートやラベルで判別する
- 画面における要素の色情報で判別する
- 画面における要素の相対（または絶対）位置で判別する
※RPAツールは日々進化しており、これ以外のパターンもすでに存在しています。
つまり、ボタンのアトリビュート、ラベル、色、位置いずれかに変更があっただけで、RPAツールに設定していた判別ロジックが破綻する可能性があるということです。
業務アプリケーションの画面をデザイナーの職能で改善しようとした場合、必ずと言っていいほど上記の判別ロジックに抵触することになります。いくらデータモデルやルックアンドフィールの観点で妥当な画面設計ができたとしても、ユーザーがもともと享受できていたRPAの恩恵を予告なく破壊することは許されません。
画面の変更が必要な場合は、事前にユーザーへの周知をする必要があります。SmartHR では実際に何度かRPAをお使いのユーザーに向け、周知を行っています。
こういったお知らせを適切に行うためには、実際に画面へ変更をもたらすデザイナーがそのリスクをしっかり理解しておくべきです。
