（1）ゴールを決める
RPAのセミナーやネットの記事、他社事例を見て、RPAの可能性に気づき、自分の会社でも取り組むことを考えたときに、まず初めにやるべきことは「ゴールを決める」ことである。これを決めないユーザーが結構多い。「ゴールを決める」とは言い換えれば、「なぜRPAを導入するのか？」に答えることができる状態になることを指す。一般的に考えられるゴールは以下が挙げられる。
- 誰でもできる定型業務を減らし、もっと生産的な仕事に取り組めるようにするため
- 仕事量を維持したまま、人不足を緩和する。またはさらに業務を拡大するため
- 残業を減らして早く帰るため
- ヒューマンエラーによるミスを減らすため
- パートナーやバイトが行っている定型業務をロボットに置き換え人件費を減らすため
どれか1つでも複数でもよいがRPA導入のゴールを設定しよう。もしこの段階でトップダウンの指示が出ておらず、担当者レベルやチーム、課単位で導入する段階であれば、いったんその単位でのゴールで構わない。ゴールはこの後、自動化するための業務選定の指針となる。
ゴールが決まれば、自動化対象エリアが決まり、自動化対象業務もおのずと決まる(業務選定の方法は後述)。逆にゴールがないと、自動化するべき業務を選定するための指針がないので、最悪、場当たり的な対応になる。さらに重要な点として、ゴールがないと自動化による成果が出たのか出てないのかがわからない。ゴールによって目標の設定方法も、成果の測り方も変わるからだ。ここで設定するゴールはRPA推進におけるすべての指針となる。
「上司に言われたからとりあえずRPAをやる」状況だけは避けてほしい。もし上司の指示でRPAに取り組み始めたのなら上司に質問しよう。「RPA導入の目的は何ですか？」と。
（2）RPA製品の選定
ゴールが設定できたということは、RPAによって解決したい課題が明確になっているということなので、次にそれを解決する製品の情報収集を行う。2018年現在では、60-70ほどの製品・関連サービスが存在するが、製品選定の評価軸は「開発の難易度」と「小規模から大規模までスケールアップできるか？」、「RPAの操作記録技術」の3つだと考える。
①「開発の難易度」について
日本のルーティンワークの特色
一般的にRPAが代行できる業務は次のとおりである。
- 定型業務(手順書どおり実施すればだいたい誰でもできる、判断が不要な業務)
- 繰り返し業務(定期または不定期に関わらず何度も発生する業務)
- 時間がかかる業務(月間当たりの総対応時間数が多く手間がかかっている業務)
いわばルーティンワークであるが、ここではもう一歩踏み込んで、日本のルーティンワークの特色を考慮した製品選定が必要であると考える。
現在、日本で残っているルーティンワークはシステム化するには費用対効果が出ないため、数十年にわたり、システムとシステムのはざまの業務を人がしわ寄せを吸収するように対応してきた業務となる。いわばこれまでシステム化されずに残ったラストワンマイルの領域である。よって、日本企業のルーティンワークは、必ずしも単純作業ではなく「複雑」しかし「少量」そして「多様」といえるだろう。
自動化業務候補の洗い出しの段階で、複雑なプロセス、しかし総対応時間はそれほど多くない業務が大量に出てくることを予想しておいたほうが良い。そうなると、ある程度の成果を出すには複数の業務の自動化を行う必要性が出てくる。そうなった場合、開発の難易度が高いものだと、成果が上がるまでに時間と開発費がかかってしまう。そのうち上司あるいは経営層は「まだ終わらないの？」と聞いてくるだろう。(RPAは簡単と言われているからなおさらだ)
前述したとおり、RPAのベンダーはたいてい「開発は簡単でユーザーフレンドリー」と説明するため、難易度はユーザー自身が試しに使ってみることをお勧めする。その場合、RPAで実際に自動化する人を想定して、実際に使ってみて難易度を測ったほうが良い。製品の中には期間限定で無償評価版をダウンロードできたり、10万円程度で有償評価できたりするものもある。後述の評価軸をもとに2製品程度に絞ったら、製品評価を行うとともに、自動化の実現性を確認することをお勧めする。
②「小規模から大規模までスケールアップできるか？」
RPAの導入は小さく始めて、すぐに小さな成果をあげられるものが良い。
「複雑」「少量」「多様」な業務を2,3自動化するところから小さく始められるくらいのコスト感の製品を選ぶべきだ。もし、初期投資が高額だとすると、少量の業務を数十～数百以上自動化しないと費用対効果が出ない可能性がある。これもまた、時間とコストがかかってしまう。
小規模からすぐに成果を上げるべきもう1つの理由として、自動化はシステム開発と異なり、作成したものがすぐに陳腐化する傾向にあることが挙げられる。RPAは通常のシステムと異なり、環境変化の影響を受けやすい。RPAが操作する対象アプリケーションのバージョンアップや仕様変更、画面デザイン変更の影響を受け、修正が必要になる場合がある。また、自動化して終わりではなく、使い始めてから発生する保守が通常のシステム開発より多くなるのが特徴である。
よって、小さく始めてすぐに成果を上げ、使いながらまた改善することができるようなスモールスタートができるコスト感の製品を選定したほうが良い。
また、前述したとおり、RPAは会社全体で取り組むべきものであるため、最終的なスコープは全社展開を見据えたものになるだろう。そうなった場合、大規模導入になった場合であっても、RPAの運用管理ができる管理サーバーが用意されていることも選定のポイントとなる。
③「RPAの操作記録技術」
RPAはWindows上のアプリケーションを操作して人の代わりに業務を行うことができるが、RPAに業務を覚えさせる技術は一般的に次のようなものが挙げられる。
- オブジェクト認識(アプリケーションのソースを取り込んで操作対象オブジェクトを特定する)
- 画像認識(アプリケーションの画像をキャプチャして操作対象オブジェクトを特定する)
- キーボード操作やマウスのクリック操作を覚える(Tabキーを4回押して、そのあとにEnterキーを押す、など)
- 座標認識(ディスプレイ上の場所で、操作対象箇所を記録する)
主要なRPA製品は前述の操作記録技術をすべて実施することができる。(仮に検討中のRPA製品が前述4つのうち、1つでもできないのであれば候補から外すことを検討しても良いだろう)
RPAで自動化をリリースした後の可用性(問題なく動き続けることができる信頼性)の高さは、高い順に「オブジェクト認識 ＞ 画像認識 ＞ キーボード/マウス操作記録、座標認識」といえる。
オブジェクト認識はアプリケーションのソースが変わらない限り、オブジェクトを特定することができるが、画像認識はアプリケーションのデザインや解像度が変わると特定できなくなる。座標やキーボード/マウス操作記録はアプリケーションの状態は一切見ることがないため、アプリケーションのディスプレイ上の表示位置や状態が変わっただけで動かない。よって、自動化する場合のセオリーは、信頼性の高い順にまずオブジェクト認識を試し、認識できない場合は画像、最終手段としてキーボード/マウス操作記録を試す(座標認識はめったに使わない)。よって、2018年末時点のRPAの操作記録技術で最も信頼性が高いのはオブジェクト認識である。
製品選定で重要な点は、製品ごとにオブジェクト認識(ベンダーにより呼び名が異なる場合がある)でサポートされているアプリケーションの種類の多さに違いがある点である。よって、製品選定に際し、このオブジェクト認識かそれに準ずる操作記録技術があり、なおかつサポートするアプリケーションにどのようなものがあるかを把握しておこう。
操作記録技術がいかに充実しているかは運用後の可用性にかかわる重要なポイントだ。画像認識だと、たとえば、社外のWEBサイトの操作を自動化した場合、社外サイトのデザインは何の事前アナウンスもなく変更されるため、ある日突然動かなくなる可能性もある。デザイン変更が頻繁だと、リリース後の保守の手間がかかってしまうことになる。特に社外サイトの自動操作をする可能性があるなら、オブジェクト認識のサポートアプリケーションが多く、なるべく画像認識に頼らないですむ製品を選定すべきだ。
製品選定にあたり、ベンダーや販売代理店を呼んで製品説明や提案を受けることになると思うが、もし可能であれば、複数の製品を取り扱っている代理店を呼ぶと中立的な情報が収集できるだろう。また、その際はユーザーの推進体制によって、ライセンス販売だけでなく、導入支援やトレーニングなど、RPA導入に必要だと考えるサービスを提供しているかどうかも見ておくとよい。
自社開発サポートも、開発をお任せ頂いても
RPA開発・保守サービス
UiPath、WinActorの開発・保守・サポートのための【RPA開発／サポートサービス】。15時間からの時間制サービスになっており、自社開発（内製化）するお客様は開発サポートデスクとしてご利用できます。
