　先ほど図1を使って、RPAをどのような領域に適用するのか検討すべきという話をした。しかし図1はあくまで現実を抽象化したものであり、このようにきれいに整理されたグラフを描くことができて、候補業務を上からRPA化していけば良いなどという単純な話ではない。目標を達成するためには、どのようにRPA化の候補業務を抽出し、抽出された候補をどう選定していくかという問題が待っている。

　これは一筋縄ではいかない。そもそも社内の全業務を詳細に把握している人はいないからだ。最近の「働き方改革」ブームに合わせ、コンサルタントなどを雇って社内の業務量調査を行う企業も出てきているが、通常はその調査の範囲や深さは限定的だ。

　候補業務を抽出するためには、改めて大規模な社員インタビューをしたり、システムや個人PCの使用ログを分析したりといった調査活動が必要になるが、限界があるだろう。社員にメールや掲示板などを通じて候補業務を推薦してもらう企業もあるが、その場合も推薦を可能にする仕組みの構築と、「積極的にRPA化候補を探して業務効率化を進めよう」という意識の醸成が必要だ。

　また候補をふるいにかける際の基準には、さまざまな要素が考えられる。単純に考えれば、RPA化によって削減される業務時間が大きければ大きいほど良いということになるが、開発されたロボットのメンテナンスに大きなマンパワーや費用がかかるとしたら元も子もない。

　RPA化がもたらすメリットは業務時間の削減だけでなく、ミスをゼロにする、セキュリティを高度化する（個人情報をロボットにインプットさせることで人間が盗み見るリスクが減るなど）、深夜や早朝の時間帯に行われる業務から人間を解放するなど、さまざまだ。こうした多様なメリットをどう評価に組み込むべきだろうか。

　さらに難しいのは、プロジェクトの状況や社内の空気に合わせて、柔軟に選定する必要がある点だ。例えば社内に初めてRPAが導入される場合、「RPA化されると多くの時間が削減されるが、開発に長い時間がかかり、失敗する可能性も高い業務」と、「RPA化されてもそれほど効率化されるわけではないが、開発は短時間で済み、成功する可能性が高い業務」のどちらを採用すべきだろうか。

　RPAに限らず、新しく導入されるテクノロジーは、1度失望されたり「失敗」の烙印を押されたりすると、その後の協力を仰ぐことが難しくなる。この場合は、効果は小さくてもいわゆる「クイック・ウィン」（Quick Win）を狙える業務を対象にすべきだろう。

　とはいえ簡単な業務ばかりRPA化していると、「RPAはこの程度なのか」「本当に自動化すべき業務に取り組んでいるのか」と疑念を抱かせることにもなる。評価プロセスや評価基準の確立は必要だが、1度それを完成させて安心するのではなく、環境の変化に応じて、運用方法と見直しについて常に考えていなければならない。