Step1 業務の棚卸し

「業務」という視点

これはあくまで私見ですが、「マクロ等を使った作業の自動化と、RPA（ロボットによる業務自動化）の違いは何か」と問われたときに、私は「作業単位（またはそれ未満の粒度）での自動化がマクロ等で、業務単位での自動化がRPA」です、と答えています。
この「業務」というのも捉えにくい部分ではありますし、RPAで「全てを自動化する」とも限らないのですが、実施するにあたっての視点としてはこの違いは大きいと考えています。

さて、「コンピューターに自動で処理をさせる」という概念自体は、もう何十年も前からありました。様々な場所で専用のシステムが開発・運用されています。ただし、これは大抵の場合、単位が「事業」という粒度（あるいは更に大きい「全社」規模）になりがちです。
あるいはExcelのマクロ等、前述のように「作業」単位の効率化・自動化も、10年以上前からあった概念です。

その上で、なぜ「RPA」なのか、という点が、この話の肝だと思います。これは、言い換えれば「業務単位の自動化」に価値がある、という話にも繋がります。

変化に対応でき、中間の無駄を無くせる

なぜ「業務」という単位に拘るのかについて、説明します。結論から言うと「事業単位だと柔軟性に欠け、作業単位だと無駄が無駄のまま残ることがある」からです。

：事業というレイヤー

まず「事業」について考えてみます。この「事業」は、当然、複数の業務が行われています。たとえば、「製品を作る」という事業では、「原材料の調達」「加工・組み立て」「検査」「出荷（物流への対応）」が業務としてありますし、間接業務で「製品の設計」や「安全対策」、「製造した製品の買い手を探す営業活動」、「人員確保のための人事業務」等も関わります。
この粒度で考えた場合に、これを1つのパッケージ化したシステムにしてしまうと、プロセスの一部に変更があった際、対応が困難になることがあります。たとえば「法令改正で検査の方法が変わった」とか、「原材料の調達先が変わり、発注のフォーマットが変わった」等です。

もちろんシステムを開発する上で、変化を前提に設計することはありますし、ビジネスの変更にあわせて修正を追加で行うことも可能です。しかし前者は想定できる範囲に限界がありますし、後者は要件の定義や開発作業に相応の期間が見込まれます。たとえば、社内の情報を統括するCRM（顧客管理）やBPM（ビジネスプロセス管理）、あるいはDWH（データウェアハウス）等の導入は最近では普遍的なことになっていますが、使用するソフトウェアが変更になった場合は、どうしても手間がかかってしまうのです。

そして。最近では前述のようなCRM等の「会社の基幹になるソフトウェア」にしても。あるいは、経理の一部や勤怠管理、社内システムの一部（例：社員用メールやグループウェア等）を、外部のサービスで賄うケースにしても。SaaS（Software as a Service）形式での提供を受けることが増えてきました。これらのサービスは一般的に、ブラウザや自動配信されるアプリケーションを通じてアクセスすることになるので、バージョンアップ等の手間が省ける反面、システムの仕様が「サービス提供側による一方的に」変化することも起き得ます。

ここまで書けばある程度、予測はつくかもしれませんが、上記のような「事業のプロセス変化や、依存するシステムの変化」に対して、「システムに直接連携して操作する」というアプローチのシステム開発では即座に（そして柔軟に）対応することは困難ですが、「人間が行う作業を代行させる」というアプローチのRPAツールを利用していれば、必要な部分だけ手直しすることで即座に対応できるのです。

：作業というレイヤー

次に「作業」というレイヤーで考えます。今度は逆に、「個々の作業が本当に必要なことなのか」という視点がないまま、惰性で続いてしまうことが起き得るからです。
顕著な例で言えば、Excelマクロ等で「昔の作業にあわせて作られたものを、修正できる人がいないので、一度マクロで出力してから新しいフォーマットに手直しする」等の無駄が発生したり。
あるいは、1つの業務という括りで見たときに、作業手順や方法論を工夫することで省略できることに気がつけない可能性があるからです。たとえば「従業員が毎月、自分のタイムカードをExcelに入力する」→「労務はタイムカードを目視で間違いがないか確認しつつ、給料計算ソフトに転記」という流れがあったとして。

作業レイヤーで見ると、「給料計算ソフトに転記」の部分だけをマクロで自動化する等は考えられますが、それ以外は難しそうに見えます。

しかし「勤怠時間をチェックして給料を計算する」という業務レベルでの目的を満たすのであれば、「事業」レイヤーの部分でも触れましたが、「オンラインの勤怠管理システムを導入する」ことで、タイムカードを使用する、Excelに転記する、という従来の流れそのものを廃止して、勤怠時間管理を大幅に省力化することができます。
作業レベルでの省力化では、上記のように「業務の目的を満たすために、方法そのものを変更する」という視点がどうしても発生しづらいため、無駄を省く・効率化するという観点では限界があるのです。

では、どうやって業務の棚卸しをするか

おそらく一番シンプルな考え方は、「目的」という粒度で整理することです。1つの事業を全体で見たときに、「□□が必要だから●●と××をする」「▲▲を可視化するために★★と◎◎を集計する」といった、複数作業によって得られる「目的」をリスト化するのが、「棚卸し」の第一ステップになります。

次に考えるべきことは、それぞれの業務の現状の可視化と、重要度の重み付けです。言い換えれば「どれくらいコストがかかっているか」です。
単純計算として、1人の従業員が毎日15分やっていて、それが20人、1ヶ月の勤務日数を20日とすれば、15分×20人×20日＝100時間が、その作業のコストになります。
RPAの対象として考えるべきは、上記のように「時間的コストが大きい」ものから順に見ていくと良いでしょう。極端な話、「月に1回だけ、管理職が15分かけてやっている作業」を自動化するのは、たとえ自動化が容易だとしても、あまりお勧めできません。それを自動化する作業にかかるコストや、ソフトウェアの費用等、諸々をみたときに、結局コストのほうが大きくなってしまう可能性が高いからです。

自動化の是非については主に次のステップ（アセスメント）で行いますが、対象として選定し、自動化の対象や業務改善を視野にいれるには、業務の棚卸しは必須となります。
是非とも「自分の仕事」だけに囚われず、事業全体の中における業務の位置づけ、という観点を忘れないで、自動化を進めていただけたら、と思います。