2018.05.31
UiPathには様々な型が存在しますが、その中でもよく使うのがstring型です。
このstring型はあらゆるテキストを格納できる箱で、ユーザーの入力テキストの読み込みや出力するときのテキストで多く使われます。
また、それらの入出力テキストだけではなくスクリーンスクレイピングやログの書き込みなどの際にも使用します。
これらの機能を使用する際に、string型の変数を使いやすくするためにあるのがメソッドです。
メソッドとは文字列を特定の文字で分けたり、特定の文字を消去したり、という機能をもったものです。
簡単に説明すると、それぞれの型（箱）ごとに付属の補助装置がいくつかついているようなものです。
この補助装置は型によって若干異なりますが、今回はこの中でも一番使用頻度の高い、
stirng型のメソッドついて見ていきたいと思います。
メソッドを具体的に見ていく前に、まずはメソッドの使い方についてみていきましょう。
メソッドの使い方はとても簡単です。
例としてContainsメソッドを使用したい時について見ていきます。
Containsメソッドを使用したい時は“test_str.Contains(“.”)”と入力するだけです。
変数名の後に“.（ドット）”を入力し、使用したいメソッドを入力します。
そのあとに、“()括弧”の中に引数というものを入れます。入れる引数はメソッドによって異なります。
引数を必要としないメソッドもあれば、引数が3つ、4つ必要なメソッドなど様々です。
引数の必要性などについてはメソッドを使用する際に適宜確認することをオススメします。(*1)
では実際にメソッドについてみていきましょう。
Containsメソッドはある文字があるかどうかを確認するメソッドです。
使い方は、”test_str.Contains(“.”)”というように使用します。
引数には検索したい文字列を入力してください。
このときに注意しておいて欲しいのは””（ダブルクオーテーション）を忘れないことです。
ダブルクオーテーションの中に検索したい文字を入力してください。
このメソッドは検索する文字があった場合はTrue、なかった場合はFalseを返します。
例）test_str=”taro”の場合、test_str.Contains(“t”)はTrueを返します。（taroはtを含んでいるので）
ToUpperメソッドとToLowerメソッドはとても似ています。
ToUpperメソッドは文字列をすべて大文字に変換し、ToLowerメソッドは文字列をすべて小文字に変換します。
使い方はtest_str.ToUpper()やtest_str.ToLowe()のように使用します。
このメソッドにおいて、引数は必要ありません。
また、初めから大文字であるものを大文字変換する際や、初めから小文字であるものを小文字に変換する際には変換されずにそのまま残ります。
例）test_str=”My name is MIKE”の時はtest_str.ToUpper()は”MY NAME IS MIKE”となります。
フォーマットメソッドは指定された形式のものを文字列に変換して別の文字列に挿入するものです。
使い方は、String.Format(“{0} 24″,”My age is”)のように使用します。
引数の1つ目には挿入したい文字列やファイルのパスなどをいれ、2つ目の引数にはもとの文字列などをいれてください。
また、{0}のような書式指定項目を入れることで挿入する場所を指定することができます。
簡単な例をあげると、String.Format(“Today’s temperature is {0}°C.”, 20.4)は”Today’s temperature is 20.4°C”と出力されます。
Replaceメソッドはファイルなどの中にある特定の文字列をすべて変更するときに使用します。
使い方は、test_str.Replace(“test”,”practice”)のように使用します。
1つ目の引数には変更したい文字列や文字、2つ目の引数には変更後の文字列や文字を入力してください。
もしも変更したい文字列が見つからなった場合は、もとの文字列を返すので注意してください。
また、大文字と小文字は区別するので注意が必要です。
例）test_str=”Yesterday was fine”の時、test_str(“fine”,”bad”)は”Yesterday was bad”と出力されます。
Splitメソッドは特定の文字でファイル内の文字列を分けるメソッドです。
使い方は、test_str.Split(“_”)のようにして使用します。
引数には区切りたい文字をいれてください。
返り値はstrring型の配列を返します。
例）test_str=”my_name_is_mike”の時、test_str.Split(“_”)は{“my”,”name”,”is”,”mike”}を返す
Substringメソッドは特定の場所以降の文字列を返すメソッドです。
使い方は、test_str(3)のように使用します。
引数には数字を入力します。この引数の数字の番号以降の文字列を返します。
また、test_str(3,5)のように引数をふたつにすることもできます。
1つ目の引数には始める場所を、2つ目の引数には文字数を入力してください。
しかしここで注意しなければいけないのは、文字列の初めの文字は0番目ということです。
引数の1つ目にいれる数字は注意が必要です。もちろん引数が一つの場合も同様です。
以下の例をみると上の注意の意味が分かると思います。
例）test_str=”12345678″の時、test_str.Substring(1,2)は”23″と出力されます。（1番目から2つ出力することだから）
Trimメソッドは前後の空白を削除してくれます。
使い方は、test_str.Trim()のように使用します。
このメソッドにおいて、引数は必要ありません。
またここで注意しなければいけないことは、文字列の中の空白は削除しないということです。
以下の例を見てください。
“□□□Hello□world□□”（□は半角スペース）のような場合です。
このような場合は”Hello□world”のように前後の空白だけが消去されて、Helloとworldの間の空白は消去されません。
Lengthメソッドは文字列の長さをはかるメソッドです。
使い方は、test_str.Length()のように使用します。
このメソッドの返り値は数字（int型）で返ってきます。（返り値は数字文字ではないので注意）
例）test_str=”12345678″の時は、test_str.Length()は8となります。
Insertメソッドはファイルや文字列に指定した文字を指定した場所に挿入することができるメソッドです。
使い方は、test_str.Insert(6,”now”)のように使用します。
ここで注意しなければいけないことは、6番目のSubstringメソッドでもでてきたように、文字列の初めは0番目であることです。
ですので、以下の例のようになります。
例）test_str=”12345678″の時、test_str.Insert(4,”t”)は”1234t5678″となります。（”t”は5番目に挿入される）
Removeメソッドは特定の場所から特定の場所までの文字を文字列から消去するというメソッドです。使い方は、test_str.Remove(2,20)のように使用します。
1つ目の引数にはどの場所から消去するのか、2つ目の引数には何文字を消去するのかを入力してください。
先ほどから注意しているので気づいているかもしれないですが、1つ目の引数に入れる数字については注意が必要です。
文字列の初めの文字は0番目です。6と9でも説明しているので合わせてご覧ください。
例）test_str=”12345678″の時、test_str.Remove(2,3)は”12678″と出力されます。
今回はよく使用するであろうstring型のメソッドについてまとめました。
しかし、これらだけを覚えていればいいわけではありません。
これら以外にも使用するときに適宜調べることをおすすめします。(*1)
もし、UiPath開発で不明点があれば弊社にお問い合わせください。
トータルサポートさせていただきます。
▽お問い合わせはこちら
https://rpa-biz.com/?page_id=88
2018.05.30
UiPathではいくつかの型が用意されています。
今回はまず、それぞれの型を紹介してそのあとに簡単なループや分岐を作っていきたいと思います。
データの型とはデータを収納しておく箱のようなものだと思ってください。
この箱には、果物をいれる箱と衣類をいれる箱のようにいれるものによっておおまかに箱が変わってきます。
例えば、単純な「２」というものでも、数字としての2なのか文字としての”2″なのか、で扱い方が変わってきます。
このために様々な型が存在しているのです。
まずはどんな型があるのか見ていきましょう。
| 型の名前 | 種類 | 例 |
| Integer | 数字 | 1,54,100032 |
| String | テキスト | “Hello”,”234″ |
| Boolean | 真偽値 | “True”or”False” |
| Generic | あらゆるもの | ——— |
| Array of | リスト | {1,2,3,4,5,6,7} |
上記のような型が存在しています。
Integer型、String型はそれぞれ数字、文字を格納するためのもので、さまざまな数字や文字を格納することができます。
Boolean型はtrue,falseの二つだけの種類しか格納することができない型となっています。
しかし、二つしか格納できないのでとてもとても見やすく、確認しやすい型となっています。
Generic型はUiPath特有の型で、どの型でも使用することができる型となっています。
しかし、この型の欠点としては、先ほどのBoolean型とは真逆に比較するときなどで分かりにくい型となっています。
最後に、Array型とは配列を作る型で他の型などと組み合わせて使うことができます。
配列は初めから使える大きさがきまっていて、追加で大きくしたりすることはできません。
これら以外にも少数を格納する、Double型や新しく大きさを追加することができるList型など非常に多くの型があるので、
それぞれ必要となったときに見ていくことをおすすめします。
ループとはその名の通り同じところを何回もまわっていくことです。
同じ操作を繰り返したいときや、完全に同じでなくても似たような操作を行うときに
これから説明するループ構文をもつアクティビティを使用すると楽になります。
ForEachアクティビティはループ構文をもつアクティビティの一つです。
このアクティビティはリストから要素をひとつずつ取り出して同じ操作を繰り返すものです。
test_listに{“one”,”two”,”three”,”four”,”five”}というstring型が格納されている場合、
For each (item in test_list) ではitemに”one”が初めに格納され、For each内のすべての操作が終わると、次は”two”がitemに入ります。
さらに、”three”,”four”と続いてitemに格納されていって最後に”five”が格納され、このFor eachアクティビティは終了します。
whileアクティビティもまた、ループ構文のひとつです。さらに、これに似たDo whileアクティビティというものもあります。
これらは似ているようで少し違います。
まずは同じ特徴について見ていきましょう。
whileアクティビティとDo whileアクティビティも、ある条件が成り立っている間に同じ操作を繰り返す、という特徴があります。
例えば、integer型のtempに0以上の数字が入っている間は繰り返すというものです。
このtempが初め4だったとするとこれは0以上であるのでこれらの中にある操作を行います。
この操作時に何らかの理由でtempが-1になったとします。
するとtempは0以上ではなくなったので次のループには入らずにこの構文は終わりになります。
この判定（今回ならtempが0以上かどうか）についてがwhileアクティビティとDo whileアクティビティとの違いです。
違いを端的に説明するとwhileアクティビティは先判定、Do whileアクティビティは後判定なのです。
つまり、判定するタイミングが違うのです。
whileアクティビティは操作を行う前に条件を判定し、Do whileアクティビティは操作を行った後に条件を判定するのです。
先ほどの例を使うと、tempがもともと-2である場合、whileアクティビティでは先判定なのでループの中に入らないのですが、
Do whileアクティビティでは先にループに入ってから判定を行います。
このようにループ構文にはいろいろな種類が存在し、それら一つ一つに特徴が存在しています。
それらをうまく使い分けることで流れをきれいに、さらに単純にフローを回すことができます。
分岐構文もその名の通り、ある地点で分かれ道になっているという構文です。
あるところで真偽によって道を分けたり、値がどのようになっているかどうかをうまく見ることができます。
一番わかりやすいのがこのifアクティビティです。
このifアクティビティはある変数や文を評価してTRUE（真）ならこちら側、FALSE（偽）ならこちら側、
と一つの道から二つの道に分岐していくアクティビティです。
例えば、tempに格納されている数字が100以上なら”おめでとう！”と表示して、
100未満なら”残念”と表示するフローもこのifアクティビティで書くことができます。
単純に２分岐ならば、このifアクティビティを使用するのがよいと思います。
switch文は単純な２分岐だけでなく、３分岐や4分岐、さらに多くの分岐をつくることも可能です。
しかしここで注意しなければいけないのは、この分岐での値は同じ重みでないといけないということです。
1の時はこの道、2の時はこの道、”three”のときはこの道とはできないということです。
数字であるならすべて数字、文字であるならすべて文字である必要があります。
例えば、switch(temp)とtempを評価して、case 1,case 2,case 3,case 10,その他,のように分けることができるということです。
このように分岐を使い分けることで適切な変数を適切な場所に持ってくることができます。
分岐はよく使うので、何回も使って覚えていくのがよいと思います。
データの型やループ・分岐の構文はUiPathを使う中で必須の知識となります。
これらの前提の知識をうまく活用しながらわかりやすい、そして高速なフローを作ってください。
また、これらはアルゴリズムやデータ構造とも関わってくるので、C言語やJavaなどのプログラミング言語を一度勉強して、
そのあとにもう一度見直すこともいいと思います。
もし、UiPath開発で不明点があれば弊社にお問い合わせください。
トータルサポートさせていただきます。
2018.05.29
今回はUiPathの入門として、まずは”Hello,world!”を出力していきたいと思います。
基本的にはやることは単純で分かりやすく、簡単です。
では始めて行きましょう！
[Blank]をクリックして空のプロジェクトを作成します。
そして[Name]にプロジェクト名を入力して、[Create]をクリックしてください。
今回は”hello_pro”と入力しましたが、実際に行う際にはどんな名前でも構いません。
次に、アクティビティパネルと呼ばれる、左上のパネルから[Flowchart]をドラッグしてください。
もしも見つからない場合は、左上の検索パネルに「Flowchart」と入力してください。
次にアクティビティパネルから[Message Box]を先ほどの[Flowchart]の中にドラッグします。
[Message Box] が見つからない場合は左上の検索パネルに「Message Box」と入力してください。
（注）UiPathでは大文字と小文字は区別しないですが、空白を認識します。
ですので、間違えて「messagebox」と入力しないようにしてください。
message boxなら検索することができます。
ドラッグすることができたら、次にスタートボタンから矢印を伸ばして[Message box]につないでください。
“Hello,world!”と入力してください。この時に””（引用符）をつけるのをわすれないようにしてください。
左上の小さいランボタンから実行することができます。
また、F5ボタンでも実行することができます。
正しくメッセージが表示されたでしょうか。
エラーが出た場合は引用符が二つはいっているかどうかなど、注意してみてください。
今回は初めの例として”Hello,world”を出力してみましたが、いかがだったでしょうか。
これから、フローチャートやシーケンスを使ってもう少し複雑な作業をしていくなかで、
メッセージを入力することは必須になるのでよく見て慣れておきましょう。
初めて使う方にはアクティビティを色々みていくのもいいことだと思います。
2018.05.29
一般社団法人日本RPA協会は、2016年7月20日に設立され、東京都港区赤坂1-12-32 アーク森ビルに所在しています。
協会の目的は、
「RPA市場の健全な発展と、日本における事業創造と雇用創造への支援
RPAの社会的な理解や価値の向上に向けた国内外関連企業間連携への支援
RPA市場における日本のプレゼンス向上」
とのことです。
代表理事にはRPAテクノロジーズ株式会社の代表取締役社長である大角暢之氏が就任しており、
専門理事にはコンサルティングファーム出身の方が就任しています。
具体的な活動内容としては、「行政・アカデミア分科会」といったセミナーを開催して、
公的な機関が「RPA行政支援プログラム」を推進できるような体制を目指すような土台作りなどを行っているようです。
そのほか、「RPAクリニック」といったRPAにかかわるセミナーを開くことで、
RPAの普及を推進する活動も行っているようです。
2018.05.28
今回はWebマーケティング（リスティング広告、アクセス解析、SEOなど）の領域におけるRPAの活用事例を紹介していきたいと思います。
著者は約5年間Webマーケティングに従事したことがあります。担当した領域は、リスティング広告、ディスプレイ広告、SNS、アクセス解析、SEOなど多岐にわたります。その時から非常に苦労したことは、多くの指標を管理しなくてはいけないことです。例えば、Google AdWordsなどでは、表示回数・クリック数・クリック率・コンバージョン・費用・CPA・・・少なくとも10以上の指標があり、それが媒体ごと（Yahoo! スポンサードサーチ）に分かれているため、たくさんの管理ツールを開きつつ、エクセルなどを活用しながら情報を整理していくわけです。さらには筆者のように広告代理店でWebコンサルタントとして働いている場合、顧客を幾つも抱えているため、アカウントの切り替えなどが必要になっていきます。ちなみに筆者は30～40の顧客を抱えていました。
このようにWebマーケティング施策では多くのツールを活用するため、管理することが複雑化し、情報を整理するだけで時間がかかります。また、次の施策を打つ際にも指標が多くあり過ぎて、混乱してしまうWebマーケティング担当者もいるかと思います。
管理の簡素化・効率化を支援してくれるツールが、今回紹介しますRPAです。RPAとは、Robotic Process Automation（ロボティックプロセスオートメーション）の略称です。基本的にPCでできる操作を自動化してくれます。今までも似たようなツールがありました。それは、エクセルのマクロです。例えば、皆さんの通勤手当や経費精算するエクセルにマクロが使用されているケースがあります。始発駅と到着駅を入れるだけで勝手に金額が表示されるなど。しかし、マクロですとエクセルの中でしか自動化できませんでした。
RPAでは、その範囲を超えてWeb上の情報なども自動で取得してくれるようになります。例えば、ベンチマークしている企業の検索順位を定期的に取得することやGoogle Analyticsの必要な指標だけ毎日取得してくるなど、今まで時間を要してエクセルなどに記入していたことは全てRPAが自動化してくれます。
それでは、幾つかRPA導入によってWebマーケティング業務の効率化・自動化できる事例を紹介していきましょう。
①各競合ECサイトの価格情報管理
これはECサイトに限ったことではありませんが、各競合ECサイトの価格情報を毎日取得し、自社商品の価格を変動させている話を聞いたことがあります。大手ECサイトでは、競合サイトと同じ商品を扱っているため、競合サイトの同商品価格情報を確認し、自社ECサイトでの販売価格をリアルタイムで変更しています。基本的には商品設計が大きく変わるわけではないため、ルーティーン作業として毎日行っているわけですが、当然ながら商品数が多いと非常に時間を要する作業です。
このようなケースでは、RPAは非常に効果を発揮します。確認したい箇所、ここでは価格情報を指定し、定期的にエクセルに落とし込む、もしくはメールを送信するなどしておけば、その分他の作業に時間を使うことができるようになります。
②Web広告の指標管理
筆者は今もある企業の広告を担当しているのですが、その企業ではGoogle AdWords・Yahoo!スポンサード・SNS広告（Facebook・Instagram）・Criteoを活用して広告施策を行っています。また、アクセス解析（Google Analytics）も行っています。その企業では、顧客情報を管理するデータベースはあるものの、これらの広告ツールと連携されていません。
その結果、毎週エクセルにGoogle AdWordsからクリック数・コンバージョン数・費用を取得し、エクセルに打ち込み、Yahoo!スポンサードを開き、クリック数・コンバージョン数・費用を取得し・・・など同じような作業を各管理画面から取得し、管理シートに打ち込んでいます。またこの企業は小売店のため、店舗が複数ありそれらの作業が完了するのが、約1~2時間かかります。
この場合においてもRPAは非常に効果を発揮します。時間を指定しておき、RPAが自動で、いままで人力で取得していたデータを人間よりも正確に、迅速に対応してくれます。さらに、小売店のように今後店舗が増えていき、店舗が100店舗を超えるなどなると、もはや人が様々な管理画面からデータを取得することは現実的ではなくなります。実際にリクルートでは約90の業務を自動化することに成功しています。例えば、データ入力などの定型作業や複数のソフトウェアで形式の異なるデータを表計算ソフトなどに打ち直す作業のほか、収集したデータからグラフ作成、レポート化することもRPAによって自動化されています。（出所：日本経済新聞「単純作業を７割削減、リクルートRPA導入拡大」（2018年4月6日付）
ここからはWebマーケティングに特化したRPAツールを2つ紹介していきたいと思います。
PRESCO Robo
B2Bビシネス向けにオウンドメディア運営やマーケティングオートメーションサービスなどの支援を行っている株式会社セグメントが2017年9月29日より提供しているWebマーケティング特化型のRPAツールです。主に広告代理店や自社マーケティング部門をターゲットとしています。ここでは、SEOについては、Google Analytics・GoogleやYahoo!の検索結果、広告はリスティング広告・ディスプレイ広告・SNS広告・外部広告プラットフォーム、さらには自社データベースをTableau Software社のプラットフォームを用いて自動で情報を取得し、レポートを作成します。また、レポートについては個別開発も可能です。（出所：PR TIMSのプレスリリース）
株式会社ミツエーリンクスのWebサイト運用RPA導入支援
ミツエーリンクスは、コンテンツやサイト制作、アプリケーション開発などを行っている企業です。ここでのRPA導入支援はおもにWebサイト運営の業務効率化です。例えば、ECサイトへ商品を登録する際には、管理番号・商品名・画像・説明文・価格などが必要になります。もちろん内容自体は自動化できませんが、決まったものを入力する作業は案外時間がかかります。それらの業務をRPAによって短縮化するほか、入力ミスなどもなくなります。
さいごに
IT選定に関与する担当者のアンケート（2017年5月調査）では、導入済みの企業が14.1%で、まだ普及していない企業が多いです。（出所：ガートナー ジャパン）今後はより多くの企業がRPAを導入していくと思われますが、これには課題があります。
それは、RPAではある条件を基に、作業を自動で行うものであるため、条件を整理する必要があるということです。案外これが難しいです。この領域は、BPR（ビジネスプロセス・リエンジニアリング）と呼ばれており、専門のコンサルタントがいるほど専門性の高い領域となっています。そのためRPA開発会社でも、業務の整理（標準化）を行うことができず、導入したい企業は業務の標準化で挫折してしまいます。
そのようなケースにならないために、RPAを導入したい場合には、自社の業務を見直し、場合によっては業務改善を支援しているコンサルティング会社、もしくはコンサルティングを含めたRPA開発のできる会社を選ぶことをおすすめします。従来のRPAは、条件を設定しなければいけませんが、AIを搭載したRPAツールも出てくると思います。それによって、情報収集という作業はほとんど自動化されるようになり、意思決定のみヒトが行うようになるでしょう。まずは作業効率のためにでもRPAを導入してみてはいかがでしょうか。
お問合せはこちら
2018.05.27
仮想知的労働者（デジタルレイバー）とは、ほぼRPAと同義です。
これらを敢えて切り離して考えようとした場合、
RPAは、「単純作業や定型作業をロボット化する」という概念を表し、
デジタルレイバーは「RPAでロボット化したロボットそのもの」を指すと言えるでしょう。
デジタルレイバーについては、以下のようなサイトでも詳しく解説しています。
2018.05.26
RPA2.0とは、いわゆる「RPA Class2」と同義のようです。
RPA ClassにはRPA Class1～RPA Class3まで存在します。
RPA Class1は、現行のRPAフェーズです。
開発者により設定された通りの挙動をするロボットを指します。
単純作業、定型業務といった、対象業務の範囲が狭いのが大きな課題となっています。
RPA Class2は、次世代のRPAフェーズです。
大量データ（ビッグデータ）の収集・分析（ディープラーニング）を行うことができるフェーズとなります。
一部、AI（人工知能）を活用することにより、現行水準よりもロボット化対象業務の幅が広がります。
EPA（Enhanced Process Automation）とも呼ばれます。
RPA Class3は、高度なAIにより、各種判断のロジックまでをも自動化するフェーズです。
CA（Cognitive Automation）とも呼ばれます。
数年後にはこのClass3まで到達するとの予測もありますが、現場のRPAエンジニアからすると眉唾物だとも考えています。
Class3まで来ると、一体どのようにロジックを組むのか、というのもエンジニアとして気になります。
RPA1.0 ＝ RPA Class1
RPA2.0 ＝ RPA Class2
RPA3.0 ＝ RPA Class3
という認識で良いようです。
2018.05.24
今回のコラムでは、前回コラムの内容を引き継ぎ、更にRPAの事例を紹介していきます。前回コラムの内容については下記リンクをご参照ください。
RPA対象業務の実例（２） ～ 経理財務、人事総務、営業事務、購買等における実導入事例のパターン（前編）
経理財務や人事総務、営業事務といった部署は、単に何かの処理だけをしていれば良い部門ではありません。都度、経営層等に対して各種指標のレポーティングが求められます。市販の業務システムを導入している企業であっても、このレポーティングの為の情報加工作業は手作業で行っているケースが散見されます。これは、偏に経営層が必要とする情報形式が企業によって異なり、市販システムのアウトプットフォーマットでは対応しきれないからです。また自社でスクラッチ開発したシステムでもあっても、宿命的に経営陣の変化によりレポート内容の変革が求められるものです。これを一々システム改変で対応していくような余裕のある企業は大企業であっても稀有かと思います。
必然、管理部門の現場担当者が毎月、もしくは毎四半期レベルでレポーティングの為の膨大な手作業が発生しています。このようなレポート資料としてパワーポイントが活用されていますが、定型情報の報告であればExcelでグラフを作り、それをパワーポイントに貼り付けるだけで済ますケースが多いようです。更に、このあたりの効率化およびレポート内容のビジュアル性向上のために、近年TableauのようなBIツールが取締役会等の経営会議で用いられるケースが増えてきているようです。これら一連のレポート作成業務は正にRPAの強い領域です。
営業活動の進捗／結果のレポーティング： セールスフォースのようなCRMツールでは、既にレポーティング機能は付いていますが、細かいカスタマイズ、途中段階での計算式の追加といった微に入り細に入ったレポート作成となるとどうしても手作業が発生してしまいます。また、セールスフォース情報をTableauで表現する際にも若干の仕込み作業が発生します。このあたりをRPAにより自動化することで、現場担当者の業務負荷の軽減だけでなく、経営陣にとってより迅速な状況把握が可能となります。
採用活動の進捗／結果のレポーティング： 人事部による中途や新卒の採用活動の進捗報告や、更に採用を確定した新入社員の略歴紹介を、経営会議で行っている企業は多いですが、そのレポート作成をRPA化します。社内の採用管理システムから都度情報を抽出し、所定のExcelフォーマットに落としてグラフ化する作業を自動化するといったアイデアが考えられます。
市況データのモニタリング： これは購買部や調達部が行っている業務になります。例えば主要購買品についてamazonやaskulといった外部サイトから最低価格をモニタリングしたり、または電気料金では、各電力会社から基本料金の単価であったり、燃料調整費および再エネ賦課金といった料金算定の基礎情報が公開されています。これらの市況データのモニタリングをRPAにより自動化します。
交通費チェック： 人事総務では、申請された通勤費をチェックするためにYahoo等の外部サイトで経路検索を行い、その金額が妥当かを検証しています。この業務をRPAにより自動化する場合は、予め社員が提出する申請フォーマットをExcelやワークフローシステムで規定する必要がありますが、それができれば、得られた出発地および到着地情報から金額を外部サイトで検出し、その情報を収集するといった作業をロボットに行わせることが可能になります。
Webマーケティング情報モニタリング： 社内にSEOやリスティング、更にSNSといったオウンドメディアの効果測定をしている部署がいる場合、これらWeb上の各種情報を担当者は都度定期的にモニタリングする必要があります。具体的にはGoogleアナリティクス等の複数の分析ツールを組み合わせてモニタリングをするのですが、その定期的な情報収集および異常値検出の際のアラート通知を自動化できます。これらはもちろんある程度は既存の分析ツール内で完結できるものですが、会社特有の細かい仕様については対応できないためRPAの出番となるケースが多いようです。
この紙書類における入力業務の効率化は、電子化が進んだ昨今おいても未だ管理部にとって永遠の課題であります。申請書のような社内向けの帳票や、これから入社してくる新入社員の履歴書といった分野なら比較的電子化は進めやすいですが、お客様からの注文書、サプライヤーからの請求書となると中々こちら側でコントロールが難しいのが実情です。これら紙からの情報をRPAで取り扱う際には、ワークフローシステムや定型Excelフォーマット添付によるメールでのやり取り等に切り替えることにより電子書類化を進めてしまうか、もしくはOCRの技術が必須となります。
社員からの申請書： こちらについては、真っ先にワークフローシステムの導入のほうを勧めています。そうすることで、紙からの入力業務を一気に無くすことができます。
新入社員の履歴書： 採用された社員が入社する際に、マイナンバーや生年月日、性別、所在地といった基礎情報を人事管理システムに入力しなければなりません。こちらについて会社側で決められたフォーマットに入力・メール提出をお願いできるのであれば、その業務をRPAによる自動化できる余地があります。
社員からの領収書（経費申請）： 毎月膨大な量になる、経費申請書に添付される領収書ですが、こちらの紙情報について自動で読み込むことは現在のOCR技術ではかなり難しいと思われます。領収書のフォーマットは各社によってかなりばらつきがあり、金額と日付、会社情報だけを抽出するにしてもOCRでさせるにはかなり難航します。このようなケースの場合、まずは基本情報を社員自らワークフローシステム等で入力させることをお勧めします。実物の紙領収書とその申請内容を照合する作業が残りますが、そちらについてはやはり人間によるチェックは不可欠です。チェック後、その電子申請された情報が正であることが保証されれば、あとはRPAによりその情報を自由に他のシステム入力や集計に使うことができます。
お客様からの注文書・サプライヤーからの見積／請求書： 購買部や経理部にとって、この社外からの紙書類の取り扱いは毎月骨の折れる作業となっています。巷にあるBPO事業者で主にこの領域をサービス対象にしている会社が多いのも、その業務負荷の裏返しとも言えます。これらの社外から来る紙帳票は、RPAやOCR技術にとって非常に難易度の高い領域として課題となっています。まずこれらの紙書類は各社により様式がバラバラ、OCRを使うにもその設定作業が困難を極める、といった理由が挙げられます。将来的に、教師データの増大によりAI技術を活用できれば現在の音声認識技術の発展のように、この紙帳票認識の技術も格段に向上することが期待できますが、今現在市販されているOCRツールにそこまでを求めることはできません。
このようなケースの場合、RPA化の方針としてあり得るのは、「主要なお客様・サプライヤー２～３社に絞り、その企業だけ対象とする」という取り組みです。OCRを適用する場合、仮に1社からの請求書であっても様々な入力パターンを検証する必要があります（購入数が少ないとき／多いときどのような表現になるのか、季節による表現の違いはあるか、等）。またOCRが設定できたとしても精度は100％ではないため、人間によるチェック業務は残ります。
このようにOCR設定は非常に負荷がかかる一方、精度も保証できないため、RPAのプロジェクトではどうしても敬遠されがちです。このような状況の打開策として、お勧めしているのが、主要なお客様・サプライヤーについて電子発注書／請求書の発行をお願いすることです。実際にこれら企業は、捺印の必要から紙書類の送付を行っていますが、実はその帳票作成自体はExcel等で行っていることが多いです。また、電力会社等の大手サプライヤーであればウェブサイト等からID・PASSを入力して利用明細をCSV形式で取得することができます。そのような電子書類の方が、わざわざ紙書類をOCRにかけるよりかよほど信頼性は増し、開発コストも低く済みます。この注文書・見積／請求書といった分野においては闇雲にOCRに突っ走るよりか、まずは一旦落ち着いて電子書類での入手ができないかを検討すべきです。
お客様からの契約書： 金融機関で始まったRPA化の波で脚光を浴びたのがこの契約書関連の入力業務です。この特にB2C事業における消費者からの契約書情報は捺印の必要性から電子化が進まない領域であり、膨大な手入力作業を金融機関側は行っています。また、姓名・住所など手書き文字の取り扱いが必要な領域でもあり、AIによるOCR技術もまずこの業務領域に狙いを定めて発展したと言っても過言ではないでしょう。手書き文字の場合、これはどうしてもOCRの対象になりますが、ここで唯一救いとなるのは「契約書は企業側がフォーマットを指定できる」ということです。この点が、前述した注文書・見積／請求書との大きな違いです。何千枚、何万枚と紙帳票を扱うのだとしてもそのフォーマットが1種類だけで且つ自社でその様式を決められるのあれば、自動化の光明が見えてきます。網掛けを無くすことや、一文字一文字記入欄を切り分けるなどOCRしやすいフォーマットに予め設計することが可能になります。何千枚、何万枚もある紙もそれが全て1種類のフォーマットであれば全て教師データとして扱え、むしろAI学習を容易にさせることができます。
一件地味に見えながら、実は現場担当者の時間を奪っているのが紙書類の印刷業務です。本来は全て、電子化しPC上で済ましてしまえれば何の問題もないのですが、実際の経理財務、人事総務といった業務では諸々の事情により印刷業務が発生しています。
請求書発行業務（＋仕訳入力）： 自社からお客様への請求書発行業務はB2Cであれば既に効率化されていますが、ことB2Bの業態であれば依然として経理社員が月末・月初に膨大な量を印刷出力している場合があります。これは捺印の必要性からの印刷であったり、今までの慣習から漠然と続いているケース等様々です。 請求書は取引先ごとに1枚ずつ発行するものであり、それぞれ各ページを開き印刷ボタンを押す業務は10～20件であれば問題ないですが、数百件～千件となると苦行以外の何物でもありません。この1件1件は軽いが重なると馬鹿にできない業務をRPAにより自動化します。印刷の仕方は、特定のプリンターに限定したり、特定の時間での印刷、もしくは実印刷まではしなくともプリンター内の予約フォルダに対象書類を登録しておくといった柔軟な方法が可能です。また、この請求書発行業務では、更に発展版として、その請求情報をもとに会計システムへの仕訳入力まで繋げることもRPAだと可能になります。
面接官向け応募者情報の印刷配布： 中途や新卒の採用において、面接官に対して人事部担当者は応募者の情報をまとめ、事前に伝える必要があります。このあたりの情報共有は人事採用システムを導入していれば、PC上で全て確認できるものですが、面接官によっては面接時にPCやタブレットの持ち込みを好まず、紙による情報提出することが慣習となっている企業もあります。このような場合、面接前日に採用面接用のカレンダーから明日の応募者の情報を抽出し、必要情報をロボットにより印刷しておくというアイデアが考えられます。
以上が、RPAで取り上げられる主な業務領域の事例となります。ここで出された例は、未だ一部であり、RPAはアイデアによって、更に広範囲な領域での適応が可能な技術です。外部コンサルタントからの知見を参考にしつつも、自社の現場担当者でもこのような事例を踏まえながら自分でアイデアを創出していく姿勢が求められます。
2018.05.23
今回のコラムでは、前回のコラムの内容から更に一歩踏み込んで、経理財務、人事総務、営業事務、購買等のバックオフィス業務におけるRPA実導入事例を類型化してご紹介します。前回コラムの内容については下記リンクをご参照ください。
リンク：RPA対象業務の実例（１） ～ 経理財務、人事総務、営業事務、購買等における各種書類媒体について
まず前回コラムのおさらいですが、RPA導入を考えるうえでの基本単位となる「入力」「加工」「出力」の流れですが、そこで扱われる媒体は主に以下になります。
これらの媒体を組み合わせて、RPAロボットによる「入力」と「出力」を定義してくわけですが、そのパターン数は膨大となります。ただ、実際にRPA導入プロジェクトの現場では、全てのパターンについて対象となるわけではなく、よく出てくる組合せというものが存在します。今回のコラムでは、それらRPA対象業務として主要なものを実例踏まえて述べていきます。
１．システムtoシステム（システム間連携）
経理や人事総務は日々膨大な数の申請を社内から受けています。これら申請情報を会計システムやネットバンキングに入力する作業に未だ手入力で行っているケースが存在します。特に、あるシステムから別のシステムへ情報を加工して入力する作業、いわゆる「システムtoシステム」の領域はRPAにとって一大分野です。これは各システムのベンダーが異なることもあり、そのシステム内での自動化・効率化は進められているものの自社とは関係のないシステムについての連携についてはどうしても後手に回ってしまっていることが理由として挙げられます。現場担当者はこのシステム間の仕様の齟齬を埋めるために手作業で情報加工をすることで、システム間の連携を成り立たせているわけです。このような「隙間業務」が実は経理や人事総務といった間接部門の人的リソースを圧迫しているケースが、今までのRPA導入前の業務分析で明らかになっています。それを埋め合わせるためにシステムの追加開発をするとなると多大な投資を覚悟する必要がありますが、RPAは費用対効果および導入スピードに優れており、正にこのようなケースで最も相性の良いソリューションと言えるでしょう。
それでは、具体的にどのような業務が実際にRPA化プロジェクトの対象となっているか見てみましょう。
稟議／決済申請→支払／仕訳入力業務： 事業部側の社員が挙げてくる見積書や請求書などの稟議／決済情報をネットバンキングに支払登録をしたり、会計システムに仕訳入力する業務です。稟議／決済申請の仕方は会社によって大きく異なります。比較的規模の大きい会社はしっかりとしたワークフローシステムが完備されており、そのワークフロー上の電子情報をRPAが取得するところから始まります。中小企業だと、まだこの申請フローがメールにExcel添付であったり、もしくは未だ紙で行っているところも存在します。その場合、まずはその申請フローを電子化するためにワークフローシステムの導入を検討する必要がありますが、それができれば今まで手入力であった経理業務の大幅な自動化が可能となります。
入出金情報→会計システム仕訳入力業務： 銀行口座からの入出金情報は経理財務部門が取り扱うべき主要な情報の一つです。月末後の月初数営業日内でまずチェックを行い、その入出金情報が、予め事業部等から申請された情報と合っているのかチェックを行い、問題がなければ勘定奉行などの会計システムに対して、科目情報を付記して入力／消込をしていきます。こちらについては、口座情報に出てくる振込元／先の名称が何を指しているか判別するためのマスタ情報を構築する必要があります。通常はExcelでこのマスタ情報を作っておき、RPAロボットはその情報を参照して、「この振込先／元の金額情報は●●の科目に相当する」といった判断をして会計システムに入力していきます。ただ、この業務については全ての入出金情報を事前にマスタ管理できない場合もあるので、ロボットで対応できなかった入出金情報については別途リストアップを行い、人間側である経理担当者に知らせて判断を仰ぐフローが必要になります。
社内システムへの申請／登録業務： これは経理財務や人事総務といった管理部門というよりか、事業部側の入力業務を効率化する使い方になります。多くの会社で事業部側は、ワークフローシステムを使って経理・人事総務関連の申請をしたり、セールスフォース等のCRMシステムに顧客情報の入力を行っていますが、システムの仕様によってはそのUI上の問題により、非常に入力に手間がかかっているケースが散見されます。現在の多くの業務システム上の登録作業はHTML形式の画面、つまり記入欄やボタンなどをクリック動作で作動させて入力させるUIとなっています。これは1件だけであれば問題ないのですが、それが500件、1000件となると、1件1件、セルに情報入力しボタンを選択し登録ボタンを押す、、といった作業は非常に苦痛を伴います。多くのシステムではそのような大量申請／登録用にCSVによるアップロード機能が付いていますが、一部のシステムではその対応ができていない事があります。そのような場合、例えばExcelに必要情報を現場で入力してしまい、その情報を基にRPAのほうでシステム入力をさせる打ち手が考えられます。
３．社員からの情報の集計／チェック業務
次にExcelやメールといったツールで挙げられてくる各種情報を取りまとめる業務について述べます。これはワークフローシステムを適用している業務であれば、システム内の機能でこのような集計／確認は行えるかと思いますが、特に中小企業の場合、このような細々とした申請全てがシステム化されている訳ではなく、定型フォーマットによるExcel帳票やメールでのやり取りが前提になっているケースも頻繁に見受けられます。
勤務表／勤怠申請の取りまとめ： これは人事総務の管轄になりますが、残業代の計算や深夜残業の抑制を講じる上で、各社員の勤務表のモニタリングは欠かせません。これを打刻時間から自動計算する勤怠管理システムを導入している場合は、集計業務は自動でしてくれますが、中小企業などExcel等で勤務表管理している場合、その集計業務が発生します。また、中堅以上の企業であっても、社員が基本的に裁量労働制であった場合、欠勤／遅刻／早退情報についてワークフローシステムを導入していないケースもあります。そのようなシステムでカバーしていない申請情報の取りまとめ、集計、モニタリングといった業務はRPA化の候補となります。
経費申請の取りまとめ： 経費申請は、各社のワークフローシステムやConcurのような専門アプリケーションで包括的に対応できる分野ではありますが、まだExcelフォーマットに記入し、原本添付の上、経理部に提出、といったフローを踏襲している会社が特に中小企業では多く存在します。そのようにシステムを利用していない企業にとって、月々の経費申請の金額推移の確認や、ルールを満たしているかのチェックは人力で行わざるを得ません。このあたりの作業をRPAにより自動化することができます。
小口現金出納帳の取りまとめ： 飲食店や小売店等の多店舗展開をしている業種では、レジの金銭管理とは別に、店舗内金庫等で管理している小口現金の管理も欠かせません。レジ金銭管理については、多店舗展開している業種ではシステム導入が比較的進んでいますが、それに比べて、小口現金についてはExcelによる出納帳管理を依然として行っているケースが多いのが実情では無いでしょうか。また小売店／飲食店のようなB2C事業でなくB2B事業であっても、全国主要都市に事務所展開をしているケースが多く、その場合の小口現金の管理も同様の傾向が見受けられます。そのような「Excel等の電子帳票で管理された情報を取りまとめる／異常値を検出する業務」というのはRPAの得意分野となります。
法人クレジットカード利用情報の取りまとめ： 営業等に法人クレジットカードを渡している企業の場合、経費申請業務の負荷は軽減しますが、その代わり、毎月法人カードの利用状況の集計作業が発生します。全ての項目について対応はできませんが、主要な取引先が予め限定されているのであれば、予めその情報をロボットに覚えさせておくことで会計システムに入力する科目情報を付記した集計も可能となります。
スケジュール調整（空き時間抽出）： 社内にある定型情報には各社員のスケジュールも含まれます。サイボウズやGoogle、Outlookといったアプリケーションにあるカレンダー機能を活用する作業になります。業務負荷の高い領域で言うと、人事の採用面接の日程・会議室調整業務や、秘書による取締等の日程管理業務が挙げられます。但し、このスケジュール調整業務にRPAを適用させる場合、「全部をRPAに任せることはできない」という割り切った考えを持つことが重要になります。例えば、採用面接官に対して空き時間を選んで面接日程と会議室を調整するといっても、各面接官のスケジュール入力の仕方は様々です。出張や客先訪問がある場合、その移動時間まで含めてスケジュール入力している面接官もいれば、そうでない方もいます。またカレンダー入力されていない暗黙のルールもあったりします。このような非定型で複雑な背景情報の考慮は正に人間が行うべき領域です。RPAでこのような業務領域を扱う場合は、単純に＆機械的に空き時間のみをリストアップして担当者に知らせるといった工程に限定すべきです。ただ、その全体の調整業務からすれば一部の工程であっても現場担当者の負担を軽減できるのであればRPA導入候補となりえると考えます。
今回のコラムでは、ここまでとします。後編となる次回では更に別のRPA事例紹介をしていきますので乞うご期待ください。
RPA対象業務の実例（３） ～ 経理財務、人事総務、営業事務、購買等における実導入事例のパターン（後編）
2018.05.22
今回のコラムでは、実際のプロジェクト事例から、具体的にどのような業務がRPA対象として導入が進められているのか紹介していきたいと思います。主な部門は、経理財務、人事総務、営業事務、購買等になりますが、基本的な適応対象業務のパターンも列挙していきますので、その考え方をしっかりと身に付ければ他部門であっても十分応用できる内容になるかと思います。
まず、RPAの導入を検討する上で、基本となる考え方があります。それは、業務の最小単位を「入力（インプット）」と「加工」と「出力（アウトプット）」の流れで抑える事です。これはRPAによる業務範囲を特定する上で非常に重要になります。なぜなら、RPAによる自動化に向いている業務は、これらの「入力」と「出力」がしっかりと定義されている作業であることが前提となるからです。つまり、０もしくは複雑で捉えどころない情報ソースから成果を出すような創造性の高い作業はRPAではできません。インプットとなる情報とそこから加工して出すべきアウトプットとなる成果物が比較的しっかりと定義づけされうる業務がRPAに向いています。これが所謂、「定型業務」と呼ばれるものになるわけですが、現在のRPAロボットにはAI技術の導入は未だこれからの段階でありますので、この「定型」度合いも他の人間の社員の方々が行っている業務に比べてより狭義で、厳密な意味での「定型」となります。こちらについては、別コラムでも取り上げた内容になりますので、詳細はそちらを参照ください。
RPA導入の進め方～事例から見るノウハウ・必要ステップ（２）： ２回目業務ヒアリング～ＲＰＡ機会の精査・深堀り
それでは、具体的にRPA対象業務となる入力（インプット）と出力（アウトプット）はどのような媒体を通して、行われるのでしょうか。現在各社で行われているRPAプロジェクトの実例を鑑みますと以下のようになるかと思います。
＜システム＞
勘定奉行等の会計システムやSAPに代表されるERP、セールスフォース等のCRM、その他にもSCMのシステム等、現在の企業運営には様々なITシステムが使われています。もともと大企業はオンプレミスを志向する傾向があったものの、近年は企業の規模に関わらずSaaSによるクラウド型を利用する企業が増えています。
ITシステムの趣旨としてそもそも自動化や効率化がありますが、実はこのシステムの周辺領域ではまだ人力による手作業が残っていることが多々あります。代表的な例としては、これらシステムにインプットデータとしてCSVを入力する際に、フォーマットをそのシステムの仕様に合わせて加工する業務等です。新たに拡張システムを開発すれば、問題は解決するのかもしれませんが、システムの追加開発は大きなコストが嵩み、費用対効果の面から決断が困難なケースが多いです。そのような時に、低コストで導入できるRPAはこれら「システム周辺領域」の自動化を進めるうえで非常に便利なツールであり、実際に利用が進んでいます。
また一点、このシステム上の作業をRPA化する上で注意事項があります。それは、自社開発システムとRPAツールの相性についてです。市販されているシステム／ソフトウェアについては、主要なRPAツールであればほぼ問題なく操作はできると思われますが、自社独自で開発したシステムについては、RPA導入前の調査段階で一度、動作確認をされることをお勧めします。システム上のどのボタンを押すのか、どのセルに値を入力するのかはRPAツール上のSelectorと呼ばれる機能を使うことになるのですが、自社で独自開発したシステムの場合、そのSelectorによるシステム画面の認識について、稀ではありますが不具合が生じる場合があります。自社特有システムでの作業をメインにRPA導入を考えられている企業様は、特に自社システムに会ったRPAは何なのかの視点を持ってツール選定を行うことが必要となります。
＜電子書類（Excel／CSV／PDF）＞
PC上の事務作業を語る上で、Excel等の電子書類の存在は欠かせないでしょう。RPAの事例を見てみても、ExcelやCSVといった電子帳票類を扱った業務が非常に多く存在します。これらに加え、お客様や外部のサプライヤーからいただくPDF書類も、テキスト認識ができるのであれば十分RPAによる作業対象となりえます。
まず、ExcelとRPAの関係については、少々その役割分担について知識が必要かと思います。皆様ご存知のことかと思いますがExcelはそれ自体、非常に優秀なツールです。Excel内の作業に限定されてしまいますが、マクロを使った作業の自動化もできますし、何よりも計算式のレパートリーが豊富であり、vlookup等を使った参照機能も充実しています。実際のRPA導入プロジェクトを進めている時にも、「この作業はExcel内のマクロや計算式の活用で対応させたほうが良い」というケースが出てきます。このような場合は、無理にRPAロボットにアルゴリズムを構築して作業させるよりも、専用のExcelマスタを作り、Excel内で終わらせるようにします。こういったRPAによるロボットと、Excel機能の役割分担の考え方が重要になってきます。
例えば、vlookupのような参照機能は、RPAロボットでも代用できますが、実際にそのアルゴリズム（forループやif分岐を多用するのですが）をRPA上に実装させようとすると非常に計算処理に時間がかかってしまう事例が報告されています。そのような場合は、無理にRPAにさせるのではなく、予め計算式を埋め込んだExcelのマスタファイルを準備しておき、RPAで入力情報となる値だけを外部から取って、そのマスタに貼り付け、あとの計算処理はExcel内で行わせる、といった分担になります。
次にPDFの扱い方です。RPAでPDFを扱うのは主に入力情報としてです。またRPAに特に向いているのは、画像認識されたPDFではなくて、テキスト認識が可能なPDFになります。お客様からの電子注文書や、サプライヤーからの電子請求書で送られてくるPDFは、一般的にこのテキスト認識ができるケースが多く、RPA対象として取り組まれることになります。もちろん、画像認識のPDFであってもOCR技術を使えば、RPA化できる可能性があります。ただ、それは「紙書類」の項で後程説明しますが、認識精度が100％ではなくRPA対象として優先度はどうしても落ちてしまう領域となります。
PDFからRPAへの入力情報を取得する方法ですが、これには幾つか方法があります。PDF自体が比較的シンプルな帳票形式であれば、お勧めするのは、そのPDFをまずはRPA上でテキスト認識させて、その後にそのテキスト情報をCSVに変換するやり方です。そうすることで表形式であるCSVにPDF情報を落とし込めることになり、「●列の●行目」といった形で取得先の情報の特定がしやすくなります。ただ、この方法はより複雑なフォーマットのPDFの場合には向かなくなります。その場合は、Acrobat等にあるPDFからExcelへの変換用のアプリケーションを使用します。具体的にはRPAロボットにそのAcrobatアプリケーションを起動させるフローになるのですが、そうすることで、PDFは何かしらかの形でExcelの表形式に変換され、RPAロボットが扱いやすいような形に加工されることになります。
＜メール＞
メールは、送り元から送り先、タイトル文からメール本文、そして添付書類等からなる電子情報の集合体です。実際にRPAの現場では、入力および出力の双方で使用される媒体となります。入力情報としては、内部および外部からのメール両方のケースがありえます。内部とは、社員からのメールであり、外部の場合はお客様やサプライヤー等からのメールが該当します。出力としてメールを使う場合も同様で、内部と外部向け双方での活用ができます。
RPAへの入力情報としてメールを扱う場合は、「フォーマットを定型化できるか」が鍵となります。人間が読み手であれば、ある程度の自由筆記形式のメールでも文脈から内容を読み取ることが可能ですが、現行のRPAはまだそこまで器用ではありません。まずそもそもメールの目的を判断させるために、特定のメールタイトル（例：タイトルの頭に【XXX】といった記号を入れるなど）や、特定のファイル名を付けた添付書類、もしくは特定のアドレスでの送付を指定するといった必要が出てきます。社内の社員からのメールであれば、まだ時間をかけてお願いすることで統一が図れますが、お客様やサプライヤーとなるとコントロールが難しいケースが散見されます。ただ、その外部からのメールであっても、例えば、予め決められた様式・名前のExcelフォーマットを添付することを徹底できるのであれば、RPAの対象として見なせるようになります。
しかし、やはり上記のようにメールのフォーマットを統一化するのは、理想として掲げられても、実現となるとなかなか骨の折れる作業になります。そのような場合は、メールでのやり取りではなく、Googleフォーム等のワークフローツールを使用してしまうことをお勧めします。これは特に社内からのメール対応になりますが、経理や人事総務に係わる諸々の申請についてはワークフローシステムの使用を決めてしまえれば、必然的に送られてくる情報形式は標準化されます。メール送付のルールを決めてモグラたたきのように統一化を進めるよりかは、「●●の申請の時は●●ワークフローを使ってください」としたほうが管理部側としてもコミュニケーションがとりやすいといった事情もあります。
次に、出力としてメールを使用する場合ですが、これは主な用途としてはアラートやエラー告知機能になります。既存のシステムでも、何かエラーが起こった時、異常値が検出されたときにメールで担当者に自動送信する機能がありますが、それと似たようなものをイメージしていただけたらと思います。例えば、Excelか何かのフォーマットで管理部に申請する業務があったとします。そのExcel書類の中身をRPAにより一次的に確認して、明らかな入力ミスや添付漏れがあった際に申請者に対して、再申請の依頼をメールで投げるなどの活用が考えられます。既存のワークフローシステムでも一部そのような機能はついていますが、より細かい内容の精査となるとRPAに実行させたほうが有効なケースも多いです。
ただ、このアラートやエラー告知は管理部内への通達であれば問題にはならないのですが、それが直接、社内の他部署や客先／サプライヤー等の外部関係者に行ってしまうことを気にされる現場担当者様は多いです。RPAは、あくまで決まりきった定型ルールに乗っ取ってでしか内容の精査はできません。「誰から送られてきたのか」とか「特例として認めなければいけない暗黙のルール」などを考慮しなければならない場合、ロボットにそのままアラート／エラー告知メールを先方に送らせるのは得策ではありません。このような場合、あくまで告知メールは経理財務、人事総務といった管理部内だけに留め、それを人間の担当者が見て吟味した後に改めて対象者にメール／電話するといった方法が取られることが多いようです。
＜ウェブサイト＞
インターネットを介しての外部サイトの使用もRPAでは一般的に行われています。ここでは、前述の「システム」の項で述べたSaaS型のクラウドシステムではなく、あくまで外部であるウェブサイトに焦点を当てていきたいと思います。ウェブサイトの例としては、購買や営業事務が市場トレンドをモニタリングするために外部サイトの情報を定期的に取得したりすることが挙げられます。外部ウェブサイトはRPAにとって出力先というよりかは、入力情報の取得先として扱われるのが多いのが実情です。
外部ウェブサイトをRPAで扱う場合、重要になるのが「そのサイトの様式が変更しないか」どうかです。RPAで、特定のサイトから情報を取得するため、そのサイトのデザインや画面遷移の方法が変わってしまったらそれだけでロボットは動かなくなります。従って、頻繁にデザインが変わるようなサイトはRPAには向いていないと言えます。また、RPAは主にHTMLベースのサイトに対応します。Flashを使用したサイトでは動作が上手くできませんので注意が必要となります。
＜紙書類＞
次にデジタル媒体ではなく、アナログ媒体となる紙書類について述べます。オフィスオートメーションの進化により、多くの紙書類が電子化されて久しいですが、現実の職場ではまだまだ紙の帳票を使った業務が残されているのが実情です。特に経理財務、人事総務、営業事務、購買といったバックオフィス業務では、領収書、請求書、契約書、申請書、履歴書、等など多くの紙書類に囲まれています。実際に、RPA導入する前の業務分析の段階で、定型業務でかつ非常に負荷が大きい業務として、この紙関係を扱った仕事は上位ランクの常連となっています。
従って、この紙関係の業務、特に紙書類からの手打ちによる「入力業務」を自動化することは、管理部門にとって永遠の夢でもありました。その中で、現在AI技術も活用され始めたOCR技術に業界の注目が集まっています。この日進月歩で向上しているOCR技術ですが、これは世の中にある各種OCRアプリケーションを試した人ならご理解いただけると思いますが、「まだ一部にしか使えない」というのが実情かと思います。特にRPAの現場では「フォーマットがこちら側で統一できる書類」のみが対象としたほうが無難です。OCRの精度を高めるには「OCRにとって読み込みやすいフォーマット」に手直しする必要があり、この事が可能な帳票業務についてのみRPA対象とされているのが現実には多いです。
例えば、サプライヤーからの請求書ですが、この書類様式をこちら側でコントロールできるかどうか、という話になります。それが難しい場合、せめてもということで主要サプライヤー２～３社の請求書に絞ってOCR対応させることもありますが、その限られた書類様式であったとしても、そのサプライヤーの請求書がOCRに対して気を使っていない場合（例えば網掛けをしていたり、文字の行間の幅が不均等であったりする）、途端にOCRの精度が落ちてしまいます。そのような現状を踏まえると、現在この紙帳票においてOCR対応が向いているのは、契約書や申請書などのこちら側でフォーマット指定ができる類の帳票になります。これらのネックとして手書きが発生することが挙げられますが、そちらについては現在AI技術を活用した技術が開発されつつあり、帳票内の手書きの場所を特定できれば読み取り精度向上も可能となります。また、現行で行われているRPAプロジェクトにおいてもこれらOCRを活用した紙書類関係の業務が対象となることはありますが、ただ、やはり精度が100％ではないため、仮に読み取りを自動化させたとしても人間による確認・チェック作業は厳然として残ります。この事を念頭に置いて、RPA導入後の業務設計を行う必要があります。
次に紙関係の業務で挙げられるのは、印刷などの「出力業務」です。これは例えば人事の採用面接において面接官に応募者情報を事前に印刷して配布しておく業務であったり、経理による自社からの請求書発行・捺印業務などが挙げられます。これはプリンター・複合機の仕様にも関わりますが、実はこの細々とした印刷業務が管理部門の社員の負荷を高めている事実が業務分析で発見されることは非常に多いです。これら出力業務をRPAにより自動化し、社員は印刷されたものを回収するだけにするアイデアは、経営層にはピンとこない話かもしれませんが現場スタッフにとっては非常に喜ばれる一手となります。
＜電話＞
電話によるコミュニケーションは今後も残っていくことと想定されますが、RPAにとっては一番扱いづらい領域です。AIによる音声認識技術の向上により、将来的には業務上の音声情報を電子化できる可能性が十分あり得ますが、これも紙書類でのOCR技術と同様、現時点ではRPAの現場では対象とはなりにくい領域となっています。
以上が、各媒体の説明と、RPAへの適合を検討する上での概要となります。次のコラムでは、より具体的にどのような業務にRPAが適合できるのか、主要なパターンを類型化してみたいと思います。乞うご期待ください。
RPA対象業務の実例（２） ～ 経理財務、人事総務、営業事務、購買等における実導入事例のパターン（前編）
2018.05.19
RPAはこのところ流行っているとはいえ、思想はシステムであるため、よくわからない用語も多くあるかと思います。
そこで、RPA用語をわかりやすく解説したページを下記のように一覧化しました。
→ ACTS（Accenture Connected Technology Solution）とは
→ Blue Prismとは
→ RDAとは
→ RPA資格とは
→ SIer（システムインテグレーター）とは
→ Webスクレイピングとは
→ アジャイル開発とは
→ アメリカ型RPAとは
→ ウォーターフォール開発とは
→ コンサルティングファームとは
→ 成功報酬型RPAとは
→ 中国・インド型RPAとは
→ マクロとは
→ ヨーロッパ型RPAとは
→ リモートデスクトップとは
→ レコーディングとは
2018.05.18
中小企業経理業務におけるRPAの活用事例
RPA（Robotic Process Automation）とは、ロボット（ソフトウェア）による業務自動化を実現することです。すなわち、ソフトウェアのロボットを開発し、様々な業務を自動で実行させることになります。パソコンがほぼすべてのオフィスに浸透した現代社会では、RPAはオフィスワークの効率向上、コスト削減の重要な手段になり、新たなオフィス革命となります。今まで「自動化」などは大企業が膨大な資金をかかって複雑なシステムを導入するイメージはありましたが、現在そのような状況は変わっています。本文では、中小企業2社について簡単にRPAを導入する事例を紹介していきます。
経理業務はオフィスワークの重要な一環として、毎月の業務負荷は大きい一方、Excel入力、会計システムなどの操作が多く、実際これらの作業はRPAとの相性がとても良い部分があります。例えば、仕訳作業は特定のExcelや会計システムにデータを転記することがメインの作業ですが、ルールと手順などが基本決まっていますし、ソフトウェア操作が得意なRPAと相性がとてもよいです。今回はA社、B社の「請求書照合・計上業務」と「入金・出金情報の会計システム入力業務」を紹介していきます。
請求書照合の業務はどの企業でも行うことです。沢山の中小企業と同じように、A社とB社は毎月数十時間をかけて行っていますが、会社の成長に伴い、作業量がどんどん増え、作業時間も必要な人員も増える一方でした。
まずA社の請求書照合業務の流れは以下の図１のようになります：
図 1 A社の請求書照合・計上業務
まず請求書は紙ベースになっていますので、取りまとめるために一旦エクセルに入力して、そして会計システムにインポートするためにフォーマットの編集やデータ加工をします。続きまして会計システムに取り込みます。そして、支払するために、インターネットバンキングに請求の情報を登録し、最後に振込を実行します。よくある業務の流れですが、すべての段階でも手で操作していることが現状になっています。件数が多くなる場合、一行一行入力、編集作業が非常に長くなります。
請求書情報の入力についてですが、情報入力は紙から行うため、完全自動化は難しいでしょう。OCRという方法もありますが、精度が問題になり、結局人間がチェックや修正することが必要となります。もう一つの選択肢として、入力代行（BPO）業者に依頼することもありますが、こちらについては量が極めて多くなる場合はおすすめします。そして、最後の振込実行段階は振込前の最終確認となりますので、人間が目視で確認したほうが好ましいです。この二つの段階以外はデータの編集、データを他のソフトウェアに入力の作業になりますので、RPAの出番です。いったん手で紙請求書をパソコンに入力した後、決まったルールでRPAがデータを編集し、会計システムに取り込みます。RPAは各種類のパスワードやIDを保存する機能もありますので、自動でインターネットバンキングにログインし、振り込み情報を登録することまでできます。そして、RPA化した後のA社の請求書照合・計上業務は図2となります：
図 2 A社の請求書照合・計上業務（RPA導入後）
RPAの導入により、半分以上の作業が自動化できます。しかも、夜中でもRPAが作業できるという強みがあるため、昼間請求書をエクセルに入力し、翌日出勤したら既に振込情報がインターネットバンキングに登録済になり、確認して実行するのみです。量が増えれば増えるほど効果が大きいです。
B社の請求書照合・計上業務はA社と極めて似ています（図3）。
図 3 B社の請求書照合・計上業務
違うところは営業が社内のOAシステムで稟議申請する段階があります。また、上長確認が間に入ります。RPA導入向けに分析すると、OAシステムに稟議申請しているということは請求書の情報は既にデータ化されています。しかし、現状書式が統一されていなく、精度も低いため、会計システムに入力する場合は紙請求書をベースで行っています。逆に言うと、社内で稟議申請の差戻ルールを厳密化し、申請データの信頼性を高められば、RPAが活かせるデータとして使えます。上長確認の段階も目視確認になりますが、順番調整が可能でしょう。そしてRPA導入した後の流れは以下となります。
図 4 B社の請求書照合・計上業務（RPA導入後予想）
こうして、営業の稟議申請の段階で情報の正確性を保障できれば、経理部門作業の大半がRPA化できます。RPAが社内OAシステムから営業が入力した稟議申請データを取得し、エクセルに入力すればその後の一連の業務は全部自動化可能となります。上長確認は振込直前に行えば、RPAの作業も中断されず、スムーズに行います。
次に、入出金情報を会計システムに入力する業務に関して述べます。大手企業などの会計システムは既に銀行システムとリンクして、自動化を実現しているかもしれませんが、中小企業の場合はまだ銀行サイトの入出金情報を目視して会計システムに手入力する場合が多いです。今回紹介するA社とB社も手入力になっていました。まずは業務流れから説明します（図5）：
図 5 A・B社の入金・出金情報の会計システム入力業務
まず、利用中のインターネットバンキングから入金・出金の履歴をダウンロードします。ファイルはPDFとCSV二種類あり、銀行の口座も複数あるため、各ファイルをダウンロードし、全てを一つのファイルにまとめる必要があります（エクセル編集・まとめ）。その後、B社の場合はまとめた入金・出金リストを見て、会計システムに手入力をすますが、A社はファイルの形式を変換、修正などをし、会計システムにインポートをします。会計システムに取り込んだら、最後結果の確認をします。
この流れを見て、作業の内容は複雑ではないが、特にB社の場合はすべて手入力のため、とても時間かかります。ここではRPAを導入すると流れは以下のようになります（図6）。
図 6 A・B社の入金・出金情報の会計システム入力業務（RPA導入後）
インターネットバンキングから情報をダウンロード、エクセル編集とまとめはすべてRPAがカバーできます。その後会計システムに入力する段階はインポート用のファイルを作成した後会計システムにインポートもできれば、前段階で編集したエクセルの入金出金情報を参照しながら会計システムに入力することもできます。勿論いずれの方法もRPA化可能です。こうして、二社とも最後の確認以外に、全ての段階で自動化を実現するため、大幅に時間短縮できました。
今回紹介したRPA候補となる経理業務は、複雑な業務ではありませんが、地味に時間かかり、現場担当者様の負担となっていた作業でした。人間作業とRPAを比較すると以下の表になります。
こうして、RPAのメリットが明らかです。特に、一つのロボットを導入するコストを一定であれば、作業の量が多ければ多いほど、RPAの単価コストが低くなります。それに対して、人間作業の場合その逆です。しかしRPAにも苦手な業務があります。例えば、今回紹介した一連の業務の中でもいくつかの段階はRPA化できませんでした。大きく以下の二つがあります：
①紙請求書のデータ化（OCRツールの精度向上が将来的に成れば、RPAと連携可能性有）
②最終確認（紙請求書とデータの照合）
①に関してはもはやOCR技術の進歩を待つしかないでしょう。②関して、場合によって技術的にRPA化が可能ですが、やはり支払計上など100％の精度が必要になるため、最後目視確認したほうがよいです。
今回はとても小さい業務を紹介しましたが、導入するととても効果的と考えられます。一気に全ての業務ではなく、このように業務の一部をRPA化することは社内の業務フローを大きく変更せずに済むため、ハードルは比較的に低くなりです。今回紹介した業務以外に、請求書発行業務などもRPA化対象として多くの企業が検討している領域ですが、そちらについては次回コラムにて紹介します。
2018.05.17
「10～20年後、日本の労働人口の約49％が、技術的には人工知能等で代替可能」。
株式会社野村総合研究所が2015年に発表したこの調査結果は、働く人々にとってかなり衝撃的なものでした。
あくまで試算だとは言われても、「自分の仕事がいずれロボットに奪われてしまうかもしれない。」という不安を感じた方は多いのではないでしょうか。
しかし、必ずしも「ロボットが人間の仕事を奪う」とは言い切れません。
そこでこの記事では、ロボットとの共存と、RPAによって変わるこれからの働き方についてお話したいと思います。
企業におけるRPA導入の目的の一つは労働力の確保です。
国立社会保障・人口問題研究所の発表によると、日本の総人口は2015年10月時点で約1億2709万5000人。そのうち、15歳～64歳までの生産年齢人口は約7728万2000人となっています。
しかし、少子高齢社会の影響により、この数字は今後急激に減少すると予測されており、2040年における生産年齢人口は約5977万7000人、2100年には約3073万7000人にまで減ってしまうと考えられています。
生産年齢人口が減るということは、当たり前ですが、働く人が減るということ。将来、多くの企業が人材不足に悩まされることは容易に想像できます。
RPAはこうした人材不足に備えて、人間の仕事の代行者として働き、少人数での業務運営を可能とするソフトウェアなのです。
では、RPAとは具体的にどのようなものなのでしょうか。
「RPA（Robotic Process Automation）」という言葉には広義と狭義2つの意味が存在しています。広義のRPAでは搭載された機能や適用対象となる作業の難易度に応じて3つのクラスが設定されており、そのうちの一番下のクラスが、狭義のRPAとなっています。
■クラス1 RPA（Robotic Process Automation）
これまで人間が行ってきた定型業務を的確にこなすソフトウェアロボットであり、複数アプリケーションの連携を必要とする単純作業が得意です。
人事・経理・総務・情報システムなどの間接部門（バックオフィス）の事務・管理業務、販売管理や経費処理、アプリケーションをまたがった入力処理などに向いていると言えます。
ただし、イレギュラーに対しては、あらかじめ設定された判定基準、対処方法によるもののみにしか対応することができません。そのため、導入時の設定やリスクの洗い出しを十分に行う必要があります。
■クラス2 EPA（Enhanced Process Automation）
構造化されていないデータの収集や分析が必要な業務を得意とします。イレギュラーに対しても柔軟に対応することができるため、セキュリティログの分析、様々な要因を加味した売上予測、Web のレコメンド広告など、多種のデータを基に分析を自動化する処理など、EPAの導入によって人材活用や経営戦略の幅は飛躍的に広がるでしょう。
■クラス3 CA（Cognitive Automation）
最もハイクラスのRPAであるCAは情報の整理や分析だけでなく、大量のデータを基に学習し、最良の意思決定まで行うことが可能な、自立度の高いソフトウェアロボットです。
ヘルプデスクや、季節や天候に左右される仕入れ管理、経済情勢を加味した経営判断など、人間の能力では不可能と思われる膨大なデータに基づく予測をする業務までも対応可能です。
以上のように、ハイクラスになるほど複雑で行動な作業を行わせることが可能ですが、それに比例する形で導入コストや、運用コストがかかってくるのもまた事実です。
現在の業務をすべて洗い出し、RPAに与える仕事量や、求める判断レベルを見極め、レベルにあったクラスを選択するべきだと言えます。
ここで、導入のハードルが最も低いクラス1のRPAについて、もう少し詳しく見ていこうと思います。
RPAが導入されると、具体的にどのようなことが可能になるのでしょうか。
会社の業務の中には「時間と手間はかかるが、内容は同じ作業の繰り返し」というものが少なからず存在し、こういう作業こそRPA導入に向いていると言えます。
今回は、よりイメージがつきやすいように、経理業務におけるRPA導入を例に、説明していきます。
まず、経理の月次業務の一つとして、業者から買掛の請求書データを受け取り、仕訳システムへの入力、起票した伝票のチェックと決裁を経て、振り込みのためのCSVデータを作成する、という一連の流れがあります。
これらをすべて人の手で行った場合、毎月膨大な量の伝票処理を強いられるだけでなく、入力間違いなどのヒューマンエラーによる再入力、再チェックが発生し、時間ロスや余計なストレスの発生に繋がる可能性があります。
また、請求書の集まるタイミングは月初めに集中することが多いため、局所的に業務量が増えてしまいます。
では、RPAが導入されるとどう変わるでしょうか。
仕訳システムへの入力やCSVデータの出力を自動で行うことが可能になることで、何百枚もの伝票を入力したり、ミスのためにやり直しが発生したりということが無くなります。
また、作業の大半がロボットに任せられるため、局所的な業務量の増加も無く、安定した業務量での作業が可能となります。
ただし、RPAにもできないことはもちろんあります。
例えば、工場のライン業務を行うロボットアームのような、専用のハードウェアをRPAは持ち合わせていません。
そのため、物を運んだり、組み立てたりというようなアナログ作業を行うことは不可能です。
また、構造化されていないデータの収集や分析は行うことができません。経理業務の例でいうと、振り込み作業前の決裁や、収支表をもとにした経営戦略の考察・決定等は人間が行う必要があります。
結論から言うと、「RPAが人間の仕事を奪う」というのは誤解です。
どんなに処理能力の高いRPAでも、人間によるメンテナンスや、業務指示などのサポート無しに動き続けることはできません。
そして、現場において最も強力なサポートができる人間というのが、実際にその業務を担当し、作業内容を熟知している社員なのです。
さらに、先ほど述べたように、データの分析を行うことや、考えることを必要とするクリエイティブな仕事に関しては、RPAが行うことはできません。
また、人との会話や柔軟な対応が必要となる対人コミュニケーションにおいても、RPAでは力不足です。
つまり、RPAにはデータ入力などのPC上でできる単純作業を任せ、社員である人間は知識や経験をもとにじっくりと考えて答えを出す必要のある仕事や、新プロジェクトなどの新しい業務の創造、関係者へのプレゼンなどの対人コミュニケーションに努めることが、ロボットとの共存を可能にする道だと言えます。
【その他のRPAと人間の共存例】
・バックオフィス業務全般をRPAに任せ、人材を顧客サポートに注力させることでサポートの質をより高める。
・RPAが売上数字の進捗情報を基幹システムから自動更新することで、営業担当者は事務作業にとらわれず、営業活動に専念する。
・人事業務における勤務時間計算、給与計算をRPAに任せ、自社に適切な人材の選別と登用に注力する
昨今、国を挙げて働き方改革への取り組みが盛んに行われていますが、RPAもこの働き方改革に寄与すると考えられます。
先ほどの経理業務の例のようにRPAによって大半の事務作業をロボットに委託することが可能になるため、人間が多くの時間を使って作業する必要がなくなり、業務時間の短縮に直結します。
その結果、
・残業が減り、終業後の自分の時間を満喫することができる
・有給休暇の取得がしやすくなる
・余計なストレスが減り、会社に対しての満足度が高くなる
などといった変化が生まれるようになり、社員一人ひとりがワークライフバランスのとれた職場へと成長していくことができます。
また、例えばこれまで派遣社員としてデータ入力作業等を行っていた方々は、RPAと合わせて派遣されることになるでしょう。
その場合、派遣社員の方の業務はこれまでのような入力作業ではなく、RPAの管理となります。
単純作業によるストレスから解放され、業務内容を熟知しているからこその視点で、ロボットに適切な指示を出し、改善を続けていく管理者へと変化してくわけです。
このように、RPAが人間の代行者となり、貢献してくれることで、人がより良い仕事、より働きやすい環境で働くことが可能になり、働き方の幅がさらに広がっていくでしょう。
2018.05.16
RPA（Robotic Process Automation-ロボットによる業務自動化）は、近年のBPOの最前線でよく聞かれるワードの一つです。これまで人間が行ってきた定型の作業や業務をPC内のロボットが仮想知的労働者（=Digital Labor）として代行することで、業務効率と品質の向上、コストダウンが期待できます。
ただひと口に「自動化」といっても、抽象的すぎてどんな業務にRPAを導入できるのかいまひとつ想像がつきにくいかもしれません。
今回は多くの企業で実際にRPAの導入が進められている業務のうち、経理財務業務でのRPA導入機会を実作業に近い形で探ってみましょう。
RPAが得意とするのは以下の特徴を持つ業務です。
・一定のルールを基に繰り返し作業が発生する
・業務プロセスが標準化されている
・高度な判断を要さない
・複数のシステム・データベースから取得したデータを利用する
・膨大なデータを取り扱うため人為的ミスが発生しやすい
経理財務業務では月次決算時等で複数のシステム、データベースからデータの取得／集計／入力を行うため、大きな業務負荷がかかりやすく、大部分を人力で行っていればヒューマンエラーが発生するリスクも抱えてしまいます。
そのため経理財務業務はRPA導入によるインパクトが最も高い業務であるといえます。
とりわけ定型業務が発生する経理財務分野において、以下の点でRPA導入が検討できます。
・経費精算業務
・請求書処理
・費用計上
・入金・売上計上
・固定資産管理
データを取得⇒加工・集計⇒出力のワークフローを辿る定型業務は、基本的にRPA導入を検討することができます。
導入前には客観的な業務の分解をする必要があり、一連の業務に係る一つ一つの作業の洗い出しを行い、ロボットで代行できる業務を探っていくところからスタートします。
どこからデータを取得し、どのように加工・集計し、最終的にどこに出力するのかに着目し、場合によってはワークフローの見直しを含めて検討する必要もあります。
この時忘れてはならないのは、ロボットを導入することで人間の実務時間がどれだけ削減できるかを念頭に検討を進めなければならないという事です。
業務効率の向上やコストダウンを図れるのは魅力的ですが、元からさほど負担になっていない人力による作業を、手当たり次第ロボットに代行させることはスマートではありません。
費用対効果の観点から、よりハイボリュームの業務からロボットを組み込んでいくことが重要であり、検討段階の指標として取り扱うデータの個数や実作業時間、工数を割り出していくことになります。
ここからは経理財務業務における実際の導入可能事例を挙げていきます。
今回は手作業が多く発生しがちな費用計上の業務のうち、購買業務フローの自動化を検討してみます。
【支払申請～振込～仕訳】
事業部が申請した支払申請内容を確認する業務の自動化を検討します。
社内申請管理システムを介した申請の場合、システム上をロボットが随時巡回することで、請求書の添付の有無や未入力項目を確認し、自動的に申請を差戻すフローを構築することが可能になります。また取引先マスタのようなものをあらかじめ作成しロボットが参照できるようにすることで、申請に必要な入力内容（取引先名・ID・プロジェクトコード・支払日など）をより細かくチェックすることができます。
添付の請求書内容と申請内容の照合については、請求書のフォーマットが統一されており、なおかつ電子データで取得できれば自動化の検討が可能ですが、多数ある取引先の請求書フォーマットを統一することは非現実的であり、また請求書自体紙ベースで発行されることが多いのも実情です。
この場合最終的なチェックは人力で行うことになりますが、申請の段階でロボットがエラーをはじいているため、従来よりもはるかに少ない労力で業務を遂行することができます。
後段の振込業務～仕訳計上時に申請管理システム上のデータを用いるため、申請のルールや差戻がしっかり機能するように厳密な定義づけをする必要があります。
≪マスタデータについて≫
マスタで管理するデータは以下のものが挙げられます。
（各業務でロボットが取得するデータを集約しておく）
▶取引先名
▶取引先ID（申請管理システム／支払リスト／マスタを紐付けるために必要）
▶取引先口座情報（ネットバンキングシステムへの入力時に必要）
※同一取引先で複数の口座を使い分ける必要がある場合は、それぞれにIDを付与する必要がある
▶勘定科目（会計システム入力時に必要）
▶支払頻度／過去支払実績（定期的に発生する支払先としてフラグを立てることで支払リスト作成時に未申請の場合はアラートを出すことができる）
▶担当者E-mailアドレス（アラートの通知先）
支払申請が承認されたものから随時会計システム上に買掛金を立てていきます。企業によっては後段の消込作業と同時に実行するなど、買掛金の計上タイミングが違ってくる可能性もあるかと思いますが、今回のケースの場合、申請管理システムで承認された時点を以って買掛金を計上することで、タイムリーな仕訳作業を行うことができます。具体的には、決裁者の承認をきっかけとしてロボットが起動し、申請データから金額情報を抽出し会計システムに反映するフローになります。どの支払案件も勘定科目が買掛金一本に絞れるならば、仕訳に必要なデータは申請管理システムのみを参照すればいいだけなので、容易に自動化ができるでしょう。
ただし正確なデータを管理システムから抽出するためには、申請データと請求書内容の一致が前提です。このため人間の目で都度確認し、情報の精度を担保する必要があります。
月次で支払申請を集計し、ネットバンキングサイトに入力するための一覧データを作成します。
ロボットが管理システムから申請データを取得することで、支払リストを自動で作成することができます。支払リストに支払金額／支払日／口座情報を出力し、リスト完成後CSVファイル化することで、そのままネットバンキングサイトに送信できるため、請求書1件1件を入力する手間が省けます。
また集計の際、コンスタントに支払が発生する支払先については、マスタ上で支払頻度などを入力しておくことで、本来あるべき支払情報が未申請になっている場合に、その項目を検出し担当者に自動メール送信などでアラートを通知することも可能です。
支払リスト作成時に注意することは、請求書によって支払内容が違う場合です。
たとえば企業ではなく個人に支払う場合、所得税の源泉徴収額を考慮する必要があります。請求金額のうち源泉徴収対象となる報酬については、10.21%(支払金額が100万円以下の場合)を乗じて源泉徴収額を算出し、支払リストへの入力金額は、その税額を差し引いて計上しなければなりません。また、交通費や宿泊費など業務に関わる費用については非源泉徴収対象として、報酬とは別に計上する必要があります。
このように個人に発生する支払いは、通常の取引先とは別のロジックでロボットを動作させる必要があるため、別途個人支払先マスタを作り管理することになります。また、申請管理システムから源泉対象額と非源泉対象額データをそれぞれ取得する必要があるため、専用の申請フォーマットを構築する点も考慮します。支払申請時の入力方法を変更することになるため、この点については申請者である各事業部へのコミュニケーション＆トレーニングで理解を得ることが肝要です。
支払リストが完成した段階で、CSVファイル（全銀ファイルフォーマットに準拠）を作成、ネットバンキングの外部ファイル送信機能を使い、自動で振込手続きを完了させます。（ロボットがネットバンキングサイトにアクセスできるようにロボット用のIDとパスワードを用意する）
最終的な振込内容に関しては必ず責任者が自分の目で確認し、正確性を担保することが重要です。
この支払情報の集計から振込までの業務は手作業メインで発生している事例が多く、自動化による削減度合いも非常に大きなものになります。
振込が完了した段階で勘定システムに仕訳データを入力し、前段で立てた買掛金の消込を実施します。
ここで必要なデータは、振込金額と勘定科目です。勘定科目についてはマスタ上で1つの支払先につき1つの科目で紐づけができれば容易に自動化を検討出来ます。
請求内容によってはより細かな仕訳が出てくる場合もあり、それら例外処理を含めてどのように自動化をするのか会計システム上の拡張機能と組み合わせて自動化の余地を探っていくことになります。
今回のコラムでは経理財務業務におけるRPA導入機会をご紹介しました。このほかにも人事/総務部門などのバックオフィスでの活用が進んでいます。
2018年現在RPAがカバーできる業務は高度な判断を要さない定型業務での活用にとどまっていますが、将来的にAI技術革新や取り扱い可能データの拡充（OCRでの紙媒体の読み取り技術の発展など）により、幅広い分野での自動化が期待されます。
こうした業務自動化の真の目的は、ロボットが人間にとって代わることではなく、人間が単調な作業から脱出しよりクリエイティブな業務にシフトできるようになることだと考えます。
少子高齢化による人的リソースの慢性的な不足を解消し、ワークライフバランスを実現しながら生産性高く労働に従事できる社会の実現にむけて、RPAは今後さらに注目を集めるでしょう。
2018.05.15
去る5/9～5/11、東京ビッグサイトにて「2018 Japan IT Week」が催行されました。
その中でも、「AI・業務自動化展」はRPAと関連性の高い企業がブースを開いており、大変興味深い内容となっておりました。
今回は、その「AI・業務自動化展」で筆者が回った企業と展示内容を少しずつですが紹介して行きたいと思います。
※あくまで筆者が気になった部分のみ抽出。資料や説明から類推して書いている部分もあります。
■RPAドクター！サービス
動かないロボットをリモート接続によってメンテナンスしてくれるサービスだそうです。
診断レポート ⇒ 1ロボット10万円
バグフィックス ⇒ 1万円／Hour
※フルリファクタリング ⇒ 1ロボット40万円～
※新規ロボット開発 ⇒ 50万円
※リリース後、5チケットの運用サポート付き。
1チケットで1バグ対応あり。
■ROBOPIT!
・ロボットの各種診断（ロボットの作りが良いか悪いか）
・ロボット改修
・改修後のサポート
の三段階でサービスを行う。
なお、SHIFT社はソフトウェアテストで業績を伸ばしている会社であり、
このところ堅調な株価を誇っている会社です。
■WinActorの代理販売
フル機能版ライセンス：908,000円／年
実行版ライセンス：248,000円／年
■ROBOWARE
独自のRPA開発ツールの提供。
非中央サーバー型のRPAであるとのことだが、詳しい仕様は不明。
基本パック：300万円
１ロボ追加購入：9万円
年間保守費用：120万円
１ロボの年間保守費用：4万円
今ならWinActor導入支援パック10時間分を無料進呈とのこと。
■Minorobo
独自のRPA開発ツールの提供。
フローチャートというより、タスクをどんどん積み上げていくようなイメージのUIです。
実際に動作を見させてもらいましたが、
個人的には3大RPAツールなどと比較すると、見づらいのかなあという印象でした。
PDF、OCR、リモートデスクトップは使用できないとのことです。
料金はフル機能版のライセンスが85万円／年、
実行のみが20万円／年となっています。
オプションとしてSIもあり、
OCRは現在、提携先を検討中のステータスとのことでした。
■WinActorの販売代理、BPOサービス
WinActorの料金体系はシステナ社と同じく以下のとおりである。
フル機能版ライセンス：908,000円／年
実行版ライセンス：248,000円／年
■Automation Anywhereの代理販売
Automation Anywhereは3大RPAツールの一つに数えられますが、
日本ではあまり普及していません。
その中にあって、日本でAutomation Anywhereを代理販売しているのは、
現時点でビット社と日立ソリューションズ社のみとのことでした。
費用は以下の通りとのこと。
エンタープライズプラン：コントロールルーム3台、ボットクリエーター10台、ボットランナー5台で1200万円／年
スモールスタートプラン：コントロールルーム1台、ボットクリエーター3台、ボットランナー1台で380万円／年
PoCプラン：コントロールルーム1台、ボットクリエーター3台、ボットランナー1台で13万円／月（ただし最低6ヶ月契約）
■OCRソリューション
「Tegaki」という手書きに強いクラウドOCRソフトや、東芝の「OCR2000i」というオンプレOCRを用いたソリューションを提案していました。
手書き文字は本来、通常のデジタル文字よりもOCRの認識率が低いとのことですが、
「Tegaki」では実に99.2%もの認識率を誇るとのことでした。
■UiPath導入に向けた業務調査からロボット開発、UiPathの研修サービス
研修は、UiPathの基礎／応用を6万円／人で研修してくれるサービスとのことです。
当社はRPAの中でもUiPathに力を入れている企業のようです。
なお、費用は以下の通りとのことです。
Bizrobo!：60万円／月（1年契約）
WinActor：フル機能版 65万円／年
実行用 17万円／年
UiPath：Robot 15万円～75万円（ライセンス利用形態による）
Studio 375,000円～625,000円（ライセンス利用形態による）
Orchestrator 250万円
Bizrobo!は思ったより高価だったので驚きました。
WinActorは前述2社より安価にて提供されているようです。
■「CELF」という独自RPAツールを使用した定額SIサービス
CELFというRPAツールの存在をここで知りました。
費用は概ねミニマム20万円～となっているようです。
■「Anyform OCR」というOCRソリューションの提供および「AutoMate」というRPAツールとの連携
AutoMateは米企業の製品であるが、三和コムテック社が販売しているとのことです。
Anyform OCRの特徴としては、帳票の仕様が可変的であっても対応できることが挙げられるようですが、
それ以外の特徴はあまり資料からは見出せませんでした。
■OCRクラウドサービス
クラウド型のOCRサービスを提供しているようです。
特徴としては、画像を自動回転し、撮影時の歪みや向きを調節できることや、
チェックディジット、バリデーションチェック、郵便番号等の情報付加といった辺りが挙げられるようです。
クラウドであるため、スキャナ等のシステムは不要となるようです。
費用は以下の通りです。
初期導入費用：120万円～
運用費用：40万円／月～（1年契約）
処理件数：2万件～
■独自RPAツール「Robo-Pat」サービスの提供
独自のRPAツールを提供しているようです。
筆者には特に目新しい機能などは見当たりませんでしたが、
セミナーでRobo-Patの差別化ポイントを講義していただけるようです。
費用は以下の通りです。
初期費用：0円
フル機能ロボ1ID：12万円／月
実行専用ロボ1ID：4万円／月
普及期だからということもあるでしょうが、
価格は圧倒的に3大RPAツールなどと比べて安価に抑えられているように感じます。
■AI-OCRソフト「FLAX SCANNER」の提供
ディープラーニング型のAI-OCRソフトを提供しています。
その結果、手書き文字も、前述の「Tegaki」と同じく認識精度99.2%だそうです。
AIを使っているとのことなので、徐々に精度は上がっていくのでしょうが、
そのための労力も気になるところです。
■ワンコインRPA「HeartCore Robo Desktop」サービスの提供
何といっても500円／250ステップという価格が圧倒的印象を抱かせる。
資料によれば、最低契約ステップ数は2500ステップから、
1ステップ＝1アクションとのことですが、それにしても安すぎると思われます。
採算度外視で開拓している以外の理由でこの値段で提供できている場合、
価格破壊といって差し支えないでしょう。
■AI-OCRソフト「AIRead」の提供
こちらもAI-OCRソフトとなっています。
費用は以下の通りです。
AIRead ETL Option：vOS単位 ライセンス120万円 年間保守24万円
AIRead ETL Option Subscription：vOS／月 ライセンス6万円
読み取り精度は99.6%の実績があるとか。
全体として、「既に作ったRPAロボットに対するサービス」が多いように感じられました。
また、まだ多くは知られていない独自のRPAツールを制作している会社も数多くあることが分かりました。
加えて、OCRに関わるサービスを提供している企業が、RPAというバズワードに対して積極的に売り込みに来ていることを実感もしました。
2018.05.15
現在日本国内の企業では「働き方改革」を推進すべく、生産性向上への取り組みが進んでいます。このような中で、定型業務を中心としたバックオフィス業務の効率化に取り組む企業が急激に増えています。
そこで今回のコラムでは、業務効率化の側面から注目されているRPA（Robotics Process Automation）と特に親和性の高いとされる、人事部門の業務にフォーカスし、RPAの導入シーンについて紹介します。
本題に入る前に、まずはRPAの得意領域について触れておきます。RPAを導入する際に検討することとして、まずは「RPAで何ができるか」ということについて把握しておく必要があります。ロボットと名がついている以上、何でもできるというイメージを持ちやすいですが、RPAでできることは定型業務になります。つまり、人間のように考えて判断するような業務はRPAでは対象範囲外であることに留意しなければなりません。
RPAの得意領域としては以下のようなものがあります。
RPAは判断業務ができないと申し上げましたが、まずは一度ご自身の業務を棚卸ししてみることをお勧めします。なぜなら実際に業務を可視化すると、意外に定型業務、いわゆるRPA化ができる業務が多いことに気づくからです。RPAを導入することによって、今まで行ってきた単純作業をロボットに任せ、人事担当者はコア業務に専念することができます。
以下では、上記のRPAの得意領域を踏まえ、私が今まで経験したRPA導入プロジェクトの中から、RPAとの親和性が特に高い人事業務の導入ケースを紹介します。
私は、今までのRPA導入プロジェクトの経験から、RPAを人事部門から導入すべきと考えます。人事部門ではRPAで効率化できる定型業務が多いからです。実際、私が過去に担当したクライアント企業様で業務棚卸しを行ったところ、人事部門での全業務の約6割が定型業務であることがわかりました。ここでは、そんな定型業務が多い人事部門の業務の中でも特にRPAで効率化できる可能性が高い事例について解説します。
※ここで紹介する業務内容や業務時間は、あくまで私の経験したプロジェクトから抜粋したものです。企業規模等により内容は異なりますので、あくまでも参考情報として掲載していることにご留意ください。
給与計算は各従業員の働いた分の賃金を計算する仕事ですが、給与額は毎月変動し、給与からも所得税、住民税を天引きする必要があり非常に複雑な上、正確さが求められる仕事です。
こうしたことから、最近では給与計算を社会保険労務士事務所等の外部企業にアウトソーシングする会社も増えていますが、その場合はアウトソーシング先とのコミュニケーションをしっかり取る必要があります。また、企業によっては、アウトソーサーの計算結果が信頼できず、最終的に人事部門で仮計算した給与の額と、アウトソーサーから返却された給与の額を確認する作業をしているケースがあります。最終的に人事部門が給与額に対して責任を持つ必要がある為、その気持ちは理解できます。しかし、これだとそもそもアウトソーシングしているのにもかかわらず、単純作業から解放されない状況が続くことになり、本末転倒になってしまいます。
ここで上記「定型業務に強いソフトウェアロボット「RPA」」で述べた、RPAの得意領域である照合作業を思い出してください。RPAを導入することで、アウトソーサーから返却された給与の計算結果の照合作業を自動化することができます。また、万が一給与の額が一致しない場合、担当者にアラートメールを通知するなどのプログラムを作成することも可能です。
ある企業では、この作業に年間50時間かかっていましたが、RPAを導入することで、30時間の削減効果が期待されることがわかりました。
入社や退職がある都度、人事部門の担当者は、人事マスタを更新します。このほか、入社や退職のタイミングでは多くの手続きがあり、やや似たようなものもあるため混乱しやすい面があり、人事部担当者はここで業務負荷を少しでも減らしたいことでしょう。
企業によって入社・退職の情報管理方法はさまざまですが、私の経験上、人事採用担当者が更新した入社・退職情報が一覧化されたExcelをマスタで管理し、その後、人事労務担当者が社内システムに従業員情報を転記する、というような作業を行っている企業が多いです。
ある企業では、この転記作業に年間15時間かかっていましたが、業務棚卸しを行った結果、年間10時間の削減効果が期待されることが判明しました。もともと作業時間としてはあまり多くはないのですが、入社・退職のタイミングは業務が繁忙する傾向にあり、業務平準化の効果も期待できることからRPA導入のメリットは大きいといえます。
こちらも企業によって運用方法はさまざまですが、ここでは私が過去に携わったRPA導入プロジェクトのクライアント企業様の事例を紹介します。そのクライアント企業様は、まず人事部門担当者が入社や退職、転勤がある従業員に対して、住所・通勤経路の変更届（Excel）をメールに添付し案内をします。その後従業員から返信があると、人事部門担当者はYahoo路線情報を活用し、従業員から申請された経路が最短距離＆最廉価であるかを確認します（条件が満たされない場合は申請者本人に申請が差し戻しされます）。
RPAでの業務自動化の方法として、あらかじめExcelファイルに対象者一覧の情報を入力しておくことで、その後RPAがその情報を認識し、対象者に自動でメールを送信する、ということができます。また、あらかじめ申請ルートの情報も上記Excelファイル内に保持しておくことで、Yahoo路線情報への情報転記からルート検索までを自動で行うことも可能です。申請された経路が最短距離＆最廉価であるかの確認は判断を伴うため、この作業はRPAではなく人間が行います。このように、一部の業務をRPAが行い、もう一部の業務を人間が行う、という役割分担を手軽にできるのもRPAの魅力の一つといえます。
こちらのクライアント企業様では、このルートチェック作業に年間30時間かけていましたが、業務棚卸しを行った結果、年間10時間の削減効果が期待されることが判明しました。他の業務と比べ削減効果としてはあまり高くありませんが、今まで行ってきた単純作業をRPAで自動化することによってその後の判断業務に集中することができるというメリットがあります。
採用担当者は、面接前日までに面接官のために面接資料を準備します。多くの場合企業の採用面接は一次面接、二次面接、最終面接と複数回面接を行うため、その都度面接資料を準備する必要があり（二次面接・最終面接では、前回の面接官からのフィードバック情報を資料に載せる必要がある）、実際に業務を棚卸しすると、意外とこちらの業務に工数がかかっていることがわかります。
私が携わったプロジェクトのクライアント企業様では、面接資料の準備だけで、年間790時間もかかっていることがわかりました。資料作成の方法を伺うと、採用管理システムから面接対象者の情報が含まれているCSVデータをダウンロードし、一定のExcelフォーマットに貼り付ける、というものでした。RPA導入で期待される削減効果を試算したところ、年間720時間でした。ある程度ルーティン化された作業でも、以前までは自動化の検討余地がなかったものも、RPAの出現によって自動化が現実のものとなっています。
いかがでしたでしょうか。今回はRPAの導入効果が期待できる「給与計算（アウトソーサーからの給与計算結果の照合作業）」、「入社・退職の手続き（社内システムのマスタ登録／変更）」、「通勤交通費申請（従業員からの定期券申請ルートチェック）」、「採用面接（面接の資料準備）」の4つの業務を紹介しました。
いずれにしても、RPA導入の検討にあたってはまず「RPAで何ができるかを知る」、「業務の棚卸し」を行うことから始めることをお勧めします。そうすることで、今までRPAについてクリアになっていなかった部分から解放されるはずです。
また、ここで紹介した業務以外でもRPAで自動化できる業務はたくさんあります。RPAの得意分野を参考にしつつ、RPAの導入機会を探ってみてください。
2018.05.14
業務効率化、生産性向上、働き方改革。この類のワードを仕事中や日常生活などで目や耳にする機会が増えてきたと感じる方は多いのではないでしょうか。（業務効率化、働き方改革の必要性などの概要は、当Webサイトの「業務改善/効率化」「働き方改革」カテゴリー内を参照いただければと思います。）
業務効率化などのためのRPA導入事例で、「仕事時間が6分の1に」「8割以上の工数削減」「事務作業削減効果最大5,000時間」等と書かれた記事を見ると、当社にはハードルが高い、大手上場企業の話だ、投資できる資金力がないなどと一瞬感じてしまうことがあると思います。
ここでは、RPA導入を前提とした方法も含め、コストを抑え今からできる業務効率化、生産性向上の具体的事例を紹介します。まずは、業務の棚卸・現状の課題と改善後の効果を明確するための管理方法を紹介します。次に業務別の具体的な改善方法案を紹介します。
①手書きしている業務
手書きをしている業務が課題になるケースが多いです。例えば、現金出納帳の手書き、売上請求書郵送時の封筒の宛名書きなどが考えられます。請求書を郵送するために封筒に宛名を手書き（宛名シールも同様）している場合は、手書きする時間がかかり、また他社の請求書の封入ミスなどによる事後処理時間が発生する可能性もあります。
②会計ソフトへ手入力している業務
会計ソフトへ手入力している業務も課題になるケースが多いです。例えば普通預金勘定の会計データを登録する際に、通帳を見ながら入力している、売上請求書の控え（紙）を見ながら、1件ずつ売掛金計上（売上計上）している、郵送されてきたクレジットカード利用明細を手元に置きながら未払金計上を入力しているなど、手入力している項目（勘定科目）は改善の余地があります。
③コピー＆ペーストが多い業務
クラウドベースの業務システム・社内基幹システム（SAP）などとExcelシートを往復しながらデータのコピー＆ペーストを繰り返す作業、決まったターム（日次、週次、月次）にWebサイトを巡回してデータを収集する業務なども単純な作業ですが、意外と時間がかかるものです。
上記3つの「手書きしている業務」「会計ソフトへ手入力している業務」「コピー＆ペーストが多い業務」をキーワードとして現状の業務の棚卸をし、それをリストアップすることで課題が明確化できます。
上記１．の課題の抽出と同様に重要なのが、業務完了に何分（何時間）かかっているのかを把握することです。各業務の作業時間を計測し、現状を把握することにより、作業削減時間のKPI（目標値）を設定することができます。そのKPI達成のために、さまざまな解決案を考えることになります。エクセルの関数である程度解決できるのか、新たな業務システム導入が費用対効果が高まるのか、現状のエクセルにRPAを組み合わせるのがいいのかなどの検討が可能になります。どの業務に何分かかっているのか把握していない経理担当者は意外と多いものです。現状を変えるためにも今日からストップウォッチを使い各業務時間の計測してみてはいかがでしょうか。
課題・業務時間の把握後は、改善策の実行と効果測定を行います。具体的な改善案は次の項目で記載します。効果測定については、実際の作業時間を計測するためストップウォッチを使用し、削減時間を測ります。当初設定したKPIの達成率を毎月確認し、さらなる改善案を考え、また実行します。この繰り返しを行うことで、経理・財務部門の業務効率化・生産性向上が期待できます。まずは経理・財務の担当者レベルで解決できる方法を考えましょう。
課題把握やKPI管理シートの参考様式を以下に掲載しますので参考にしてみてください。
①小口現金制度を廃止する
小口現金制度を廃止し、社員の立替金精算方式に変更する。ATMや銀行窓口で現金を引き出す時間や、現金取引の会計ソフトへの入力時間が削減されます。しかしながら、業種によっては小口現金を廃止することは現実的ではない場合もありますので、小口現金制度を廃止する方法は限定的な方法となりそうです。
②立替経費精算方式の採用
各役員・従業員が一旦経費の立替を行い、給与と一緒に立替金を精算する方法です。この方法によると現金の動きが少なく経理・財務部門の事務負担は軽減できます。立替経費精算の対象となる役員・従業員数が多い場合には、経費精算業務システムの導入も有効的です。
③仮払金方式の採用
毎月の経費精算金額が大きい役員・従業員がいる場合には、経費仮払金として一定額をその本人に振り込み、差額精算は給与振り込みと同時に行う方法です。
④多店舗展開等で各店や各事務所に現金出納帳がある場合
A)まず手書きの現金出納帳を採用している場合は、エクセルやGoogleのスプレッドシートの現金出納帳に切り替えを行いましょう。もちろん現金出納帳の様式は統一し標準化を図ることが重要です。
B)次に、会計ソフトに入力する時間を削減するため、現金出納帳のデータを会計ソフトにインポートできるような、インポートツールエクセルで作成します。ほとんどの会計ソフトには、仕訳や振替伝票のCSVデータをインポートするための形式が定められています。インポートツールといっても簡単な関数で作成できますので、会計ソフト会社のサポートや顧問会計事務所の協力があれば問題なく進めることができます。
C)最後に各店や各事務所で現金出納帳のデータをコピーしインポートツールにペーストするなどして、会計ソフトに一括でインポートします。店舗数や事務所数が多い場合は、コピー＆ペーストの単純作業も多くなりますので、このような場合はそのコピー＆ペーストの箇所と会計ソフトにインポートするための操作を一括してRPAで行うことにより、経理・財務部門ではほぼ何もしなくても現金勘定の残高を合わせることが可能になります。
①会計ソフトの預金取り込み機能を活用する
主要な会計ソフトにはインターネットバンキングの預金の入出金データを自動取り込みできる機能があります。その機能が標準的に備わっているソフトもあればオプションで別料金設定しているソフトもあります。まずは、自社で使用している会計ソフトにその機能が標準で備わっているのかオプションであるのか確認します。その機能あるのであればその機能を活用しましょう。しかしながら、標準で備わっている場合でも初期設定の煩雑さや、会計ソフト特有のユーザーインターフェースの使いにくさなどにより活用を断念している会社がある実態もあります。
②仕訳予約機能を活用する
こちらの機能も主要な会計ソフトに備わっている機能の一つになります。会計ソフト会社によって呼び名は異なりますが、毎月発生する定型的な仕訳をある一定日に自動起票（自動仕訳）してくれる機能です。初期設定さえすれば、登録した仕訳は毎月自動で計上されるため、仕訳入力の時間が削減できます。初期設定も比較的容易にできます。
③インポートツールを使用する
上記１．小口現金の④と似たような方法です。小口現金と同様にインポートツールを作成し、インターネットバンキングからダウンロードした、入出金明細のCSVデータをコピーし、インポートツールにペーストします。インポートツールには、入出金明細の摘要欄の文字列に応じたデータベースを作成しておきます。インポートツールはエクセルで作成するため、データベースの追加修正削除などが容易にできます。
ここにRPAを導入した場合、ロボットがインターネットバンキング等にログインし入出金データのダウンロードを行い、インポートツールにコピー＆ペーストをし、会計ソフトにインポートするところまでの自動化が可能になります。データベースに登録されていない取引は、仮払金や仮受金で仕訳計上されるようにしておけば、経理担当者は、イレギュラーな取引である仮払金や仮受金の仕訳を修正するのみで当月分の預金残高を確定させることができます。当月に仮払金や仮受金に振り分けられた仕訳もインポートツールのデータベースに登録することにより次回からは適正な仕訳として計上されることになります。
今回は、現金・預金にフォーカスしましたがそれ以外にも、売上請求関連、支払請求関連、クレジットカード関連、給与などについても、「手書き、手入力、コピー＆ペースト」のキーワードに当てはまる日々の業務はあると思いますので業務の棚卸と作業時間の現状把握から進めていきましょう。
2018.05.10
昨年2017年末からメガバンクを皮切りに大手企業がRPA導入を発表が続き、2018年はさながらRPA元年といった様相を呈しています。
しかし中小企業界隈におけるRPAの認知はまだ必ずしも高くはありません。
RPAは本来中小企業にこそ活用されるべきテクノロジーです。今後の就労人口の減少によって人材獲得が難しくなるのは大企業ではなく中小企業です。
また、大規模なシステム導入が難しい中小企業にとってRPAはコストパフォーマンスからいってもマッチします。確かに現状ではRPAバブルの中、大手コンサル会社による暴利な値付けがなされていますが、RPA自体は元来それほど高い難易度を要する技術ではありません。WEBサイトの制作やSEOにように、当初は暴利がまかり通るのでしょうが、時間の経過とともに寧ろ誰でも使える技術となっていく可能性があるのがRPAです。
今記事は現段階における中小企業にとってのRPAについて、中小企業の社長自身による極めて私的な雑記です。雑記だからこそ分かるリアルもあると思います。ご興味のある方は是非お読みください。
当社は社員100名未満の小売業というまさによくある中小企業でありながら、同時に社内の一部門としてコンサルティング部を有しこれまで多くの企業の業務標準化や改善を行ってきました。
コンサルティング部は外資系戦略ファーム出身の創業役員が率いており、社長である私は主に小売りの方を担当してきました。その為、私自身は考え方もスキルも典型的な中小企業オーナー社長であり、また周囲のお付き合いも同様の中小企業オーナー社長がほとんどです。そんな私の目から見るRPAの中小企業の認知とは、そして今後の導入にあたっての諸問題についてお話します。
尚、ここでいう中小企業は、社員数70～150名程度の規模のオーナー社長企業を想定しています。
自分自身もそうなのですが、まず抑えておきたいのは、中小企業オーナー社長とB2B界隈のビジネスマンのビジネス用語理解には大きな乖離があるということ。実はこれ、当社のコンサル部門の人間ともよくそのギャップで議論になります。正直、私たち中小企業オーナー社長はコンサルをはじめとしたB2Bビジネスマン程ビジネス用語なんて知りません。
ビジネスにまつわる用語はそれぞれ三つの群に分かれると考えています。三つをそれぞれ「ビジネス用語」、「トレンド用語」、「一般用語」と呼びます。
ビジネス用語とは、まさに界隈の方々しか知らない言葉、例えばBPRとかSAPとか。大手企業の経験もなく、普通に最初から社長として小売りやっていて一応日経新聞を流し読みしているレベルは、その言葉の意味は分かりません。
次にトレンド用語。もともとビジネス用語だったものが何かの拍子にこのトレンド用語へ移動してきます。例えばクラウドとかかな。正直定義までは分からないが知っている言葉。
最後に一般用語は、このトレンド用語から更に昇格して、誰もが知る言葉になったものです。最近ではAIとかですかね。ビジネスマンでなくとも聞いたことがある。
感覚的に言うと、ビジネス用語は日経新聞の記事には出ているが、春秋や社説には出ない。トレンド用語になると春秋や社説にも出てくる。一般用語になるとビジネス系以外のメディアでも目にするという感じですかね。
では、RPAは現時点でどの群に属しているのか？
私は、トレンド用語にようやく入ってきたところだと考えています。ただしまだ漸く入り口くぐったところ。そして、中小企業に浸透し始めるのはこのトレンド用語フェーズの後半になります。
実際、今年になって私の周囲の小売り、医療関係、不動産、飲食、自動車部品などの社長20名程度に聞いて回りましたが、RPAという言葉を知っていたのは一人を除いていませんでした。唯一の例外は元々大手企業で修業された二代目社長でした。
今後どれだけ浸透するか、ひとつは日経や経済誌といったメディアでの記事としての掲載頻度によります。そして、もうひとつ意外と重要だと思われるのは金融機関や税理士などの側からの情報提供です。しかし現状では地銀信金界隈の担当者、税理士の先生方のRPA認知もまだという状態です。そう考えると中小企業への浸透は今しばらく時間がかかるかもしれません。
とは言え、既に意識の高い中小企業のRPAへの投資ははじまっています。これらの導入効果が日の目を見るようになった時こそ、多くの中小企業がRPAの導入に踏み切る時になるでしょう。次項からはRPA導入における課題について心理的なハードルと物理的なハードルに分けて見ていきましょう。
中小オーナー企業の意思決定は、社長です。特に事業に直結しない管理系の案件は、社長決裁であることがほとんどです。中小企業へRPAを勧める場合、社長の説得は避けては通れません。
まず中小企業の社長は見えにくい投資が嫌いです。RPAはロボットといっても形があるものではありません。ソフトに、ましてや売上に直結するわけでもないものに投資するというのはそれだけでハードルとなります。
ただし、これはRPAがトレンド用語として浸透していない状態においてのハードル。ひとたびトレンド用語として人口に膾炙したら今度は、「RPAというのを最近よく聞くがわが社でも導入できないものか」となるのが、世の中小企業の社長の常です。
そしてここからが本当の心理的ハードル。それは、興味と不安のないまぜ状態です。
基本的には自分の範囲にあるものは自分で理解したいと思う中小企業の社長は一般的に分かりにくい横文字に対してとても強い興味を持つと同時に、強い警戒心を持っています。それが自分の理解を超えたものであれば猶更です。
古くは一太郎からはじまり勘定奉行や大蔵大臣、日本製のIT関連商品やシステムなどの多くが日本語名であるというのも、それが理由であると私は考えています。逆に多くの歴史ある企業が由緒ある日本行表記の会社名を捨て横文字にするのも、同じ心理からきていると考えられます。
加えて、中小企業の社長はソリューション営業を受けるのが苦手です。売り切りのパッケージを営業されるのならまだしも、自社の状況にあわせてRPAをどう活用するかひとつずつソリューション営業と詰めていくのは大きな苦痛を伴います。
良さそうなのだが、どうしても必要なものではない。いろんなことが出来るそうだが、具体的に何が出来るのかいまいち分からない。柔軟性の高いRPAだからこその悩みどころですが、このあたりをどれだけ平易に、具体的に、そして効果をアピールできるかは中小企業への導入、ひいては中小企業社長攻略のポイントになると考えられます。
無事に社長の承認も得て、具体的な導入について現場責任者と詳細を詰める段になりました。ここからが実は一番大きな課題です。
それは、中小企業の業務は標準化されていないということ。上場準備企業で業務フローを整えているというような中小企業ならまだしも、大多数の中小企業の業務は人に大きく依存しています。そして伝承もほぼ口伝。
RPAは決まった作業を代替する技術です。作業自体に何らかの決まりがなければそもそも代替が難しい。だったら導入にあたって業務を標準化すれば良いという意見があるかもしれません。しかし、基本的に業務標準化とRPA導入は異なる業務です。業務標準化はより上流のコンサル工程にあり、RPAの導入支援の営業やRPAの開発者が持つスキルとは異なります。
かくして、単純にRPA導入で済むと思っていた案件は、業務標準化という泥沼に入り、コストも時間も嵩んでいくことになります。そもそもスケールの違う大企業と比べコスト削減の面でのメリットがそれほど大きくない中小企業にとってこれは大変痛い状況です。
またRPA導入支援企業からしても、これでは採算が合わず営業を躊躇ってしまいます。
さて、ここまで中小企業のRPA導入について、若干悲観的に考えてきました。
しかし、冒頭にも述べたように、本来RPAは中小企業にこそ導入されるべきものであるという信念は変わりません。
最後に、極めて私的な雑記の締めくくりとして、極めて私的な売り込みをさせてください。
実は私がRPAという言葉を知ったのは昨年末。当社のコンサルティング部でいくつかの案件を受けていたのを知り、担当役員からその説明を受けたのがキッカケです。まあリアル中小企業の社長の実態としてご勘弁ください。
その後、年末年始の休みで、日経新聞や経済誌の新年特集号をなにげなく読んでいると、実は結構そこかしこにRPAという言葉があるではありませんか。よくよく調べてみると、これは我々のような中小企業の為にあるような技術ではないかと確信し、本年より私も肝いりで当社のRPA事業を拡充しています。
当社はもともと上流の業務受託をしていた為、社内に業務標準化を行うコンサルタント、RPAの営業、RPAの技術者を全て準備しています。
確かに、単なるRPAによる業務代替よりは面倒かもしれません。しかしこれからの就業人口減少社会において中小企業における業務標準化はRPA導入以上に重要なことです。
RPAという新しい技術に興味をいただいていただいた中小企業の社長様方には、これを機会に標準化、ロボットによる代替と一気に行うことを切にご提案いたします。
そして、私どもに、是非ご相談ください。
2018.05.09
今回のコラムでは、初期ヒアリングが終わり、対象部署の業務の全体像を掴んだ後に行われる２回目業務ヒアリングの要諦についてお伝えします。よく、「ヒアリングは１回で済ますことができないのか」と聞かれますが、今までの経験上で言うと、特にＲＰＡ導入プロジェクトにおいては最低２回のヒアリングが必要なるケースが多いです。そもそも１回目のヒアリングの目的は「業務の全体像を把握すること」と「ＲＰＡ化対象候補となりうる大枠の業務区分の抽出」にあります。２回目のヒアリングでは、「その絞った業務区分に対しより細かい業務フローの把握」と「ロボット化のロジックの妥当性検証」を行うことが目的となります。１回目のヒアリングでそこまで詳細な情報を得ようとすると、そもそも時間が足りませんし、また、ＲＰＡ対象となりえない業務に対して深堀して聞くことにもなりかねず、逆に非効率な結果となってしまいます。更に、１回目のヒアリングでは、経理財務や人事総務、営業事務などの業務を広範囲に見ている方、具体的に言うと部長や課長レベルの方が対象となるのに対し、２回目はより絞った業務について事細かな作業手順を伺うことになるので、現場で実際に作業をしている社員様がヒアリング対象となります。
RPA導入の進め方～事例から見るノウハウ・必要ステップ（１）： 最初の業務分析・棚卸
ＲＰＡ導入前の初回ヒアリングのノウハウについて知りたい方はこちら↓
RPA導入の進め方～事例から見るノウハウ・必要ステップ（１）
２回目の業務ヒアリングをする前に準備をしておくことがあります。それは、初回ヒアリングから、ＲＰＡ対象領域として選出した「業務項目のリスト」および「具体的にどのあたりがロボット化できそうかの初期仮説」をコンサルタント側で準備して、対象部署の方に共有しておきます。さらにヒアリング当日はビデオカメラを使っての動画撮影も行いますので、ＰＣおよびモニターの準備も依頼しておきます。
２回目ヒアリングの事前準備事項
・ＲＰＡ候補業務のリスト
・ＲＰＡ化対象領域の仮説
・当日動画撮影の為のセッティング依頼
動画撮影については、躊躇される方も多いですが、ＲＰＡに関しては、ＰＣ上で行っている操作が対象となります。その後の、実開発フェーズへのスムーズな移行を行う上でも、ＰＣ画面上で実際にどのような操作をしているのか、使用しているシステム／帳票はどのようなフォーマットのものなのかを把握しておくことは重要です。実際に、その場で画面操作を拝見しても細かい点までは抑えきれないため、予め録画してあとで見直しができるようにしておくことが、結局は現場側への再度の確認の手間が除かれ、結果、負担の軽減につながります。
ここで、具体的な２回目業務ヒアリングの内容に入る前に、コンサルタントに求められるスキルをについて述べたいと思います。現状、ＲＰＡの導入をリードするコンサルタントは、ＲＰＡ専門家というよりかは、ＢＰＲやＢＰＯといった通常の業務改善、アウトソーシングのプロジェクト経験をもったコンサルタントの方が多いと思います。その方たちはもちろん、業務の棚卸、精査については十分な知見を持っており、１回目のヒアリングではそれほど差し障りなくプロジェクト進行ができると思います。但し、２回目ヒアリングとなるとロボット化、つまりＲＰＡのプログラミング・アルゴリズムの知識が多分に求められます。これは、ＲＰＡというものは結局、世の中にあるＩＴシソリューションと同様、最終的にはプログラミングされたシステムで問題を解決する施策になるからです。
２回目ヒアリングでは、業務の詳細を伺いながら、「ＲＰＡ化するとこのようなアルゴリズムになり、したがって人間側は●●のような作業をしてサポートをする必要がある」といったようなことを提言していかなくてはいけません。そのためにはＲＰＡのプログラミングの素養が求められます。幸い、ＲＰＡに関しては、世の中に多くの開発ツールが出回っており、比較的簡単に低コストでプログラミングスキルを学ぶことができます。弊社で特に取り組んでいるUiPATHでは、チュートリアルも豊富で、１～２か月程度で概要を掴むことは可能です。コンサルタントの方々にまずおすすめしたいのは、自分自身でＲＰＡのプログラムを作ってみる事です。内容自体はExcelのマクロに近いので比較的早期に習熟することが可能かと思います。ＲＰＡでできることはシステムやExcel帳票の画面操作だけではなく、メールのやり取りから、Ｗｅｂサイトからの情報取得まで多岐にわたります。また、ロボットの起動のさせ方も、ローカルロボットからの手動でのキックもありますし、Windowsでのタスクスケジューラでの起動もあります。また指定フォルダやメーラーに対する巡回型ロボットを作る場合も制約条件があります。これらのことを踏まえた上で提言を行っていくには、何よりもＲＰＡのプログラミング知識が求められるのです。この知識が無いと、２回目業務ヒアリングを行い、ロボット化対象領域をより細かに抽出できたとしても、実際に開発段階になって蓋を開けてみると、ＲＰＡ化が不可能であったり、仮にＲＰＡ化できたとしても大きな業務変容を現場担当者に強いるために実現性の薄い結果となることが危惧されます。
それでは、いよいよ具体的な２回目業務ヒアリングの内容に移ります。ヒアリングでは先述したとおり、現場担当者様に具体的にＰＣ上での操作をモニターに映して頂き、業務の内容を検証します。業務詳細を追っていきながら、同時にロボット化のロジックを頭に思い浮かべなら質疑応答を繰り返していきます。具体的なヒアリング事項は以下になります。
２回目ヒアリング時の確認事項
・使用するシステム／ツールのフォーマット
・具体的な作業内容（情報の取得先、情報の転記・加工、アウトプットの形式）
・ＲＰＡ化対象のサブ業務区分（これは初回ヒアリングで聞いた業務の更に細かい区分単位で行います）
・サブ業務区分単位での業務量、ＲＰＡ化した際の削減％
「使用するシステム／ツールのフォーマット」
ＲＰＡ導入を検討する上で、ロボットが作業する対象となるシステムやExcel等帳票のフォーマットの確認は欠かせません。実際にロボットで作業を代替させる場合、明確なルールが求められます。例えば、経理の業務で請求書からの支払対応や勘定システムへの計上業務があります。ワークフローシステムでの稟議申請であったり請求書付きの決済申請が行われますが、その情報をネットバンキングでの支払登録をさせるには、支払先の口座番号等のマスタ情報を管理しておく必要があります。ワークフロー上での申請情報とその支払先マスタ情報をロボット側で紐づけさせるには企業単位でＩＤ管理をすることが求められます。今までは人間側での作業では「●●株式会社」であろうが「●●（株）」であろうが、凡そ見当がつくのでその紐づけ業務はファジーな感覚で作業できていたかもしれませんが、ロボットにさせるとなるとそのような曖昧なルールでは動きません。明確に紐づけをできるようにするには別途ＩＤの配布が必要になるのです。そのような視点を踏まえながら、現在使っているシステム／ツールのフォーマット確認およびロボット化する際での変更点についてコンサルタントは言及していきます。
「具体的な作業内容（情報の取得先、情報の転記・加工、アウトプットの形式）」
次に、より詳細な業務フローについて確認していく工程に入りますが、ポイントとなるのは「入力（インプット）」→「加工」→「出力（アウトプット）」の構造を頭の中に持ちながら、業務を分解していくことにあります。なぜなら、この３元素はＲＰＡロボットを作っていく上での基本単位となるからです。基本的に、インプット元となる明確な情報源が無いような作業はロボットには向きません。情報減がゼロ、もしくは有象無象の非定型情報から何かを生み出さなくてはいけないようなクリエイティビティの高い業務はＲＰＡというよりかＡＩの領域です。既存のＲＰＡではまだＡＩとの連携は本格化しておりませんので、現行のプロジェクトではそのような業務がＲＰＡ対象となることは先ず無いでしょう。また、入力情報だけで、アウトプットの無い様な作業はそもそも業務として存在しえません（価値を生まない）。皆様が日々行っている業務の多くも基本的には「入力」と「加工」「出力」のフレームワークに収まるかと思います。
業務ヒアリングをしていく上で、この３要素を頭に持っていると、抜け漏れを防ぐことができます。実際、現場担当者様からのヒアリングでは、自部署内だと自明の理であるために入力元となる情報源について差ほど言及せずに、説明を進めてしまわれるケースもよく散見されます。そのような際は、今一度振り返って聞きなおし、インプット元となる情報がどこから、誰からくるのか、その情報のフォーマット（申請ワークフロー、社員からの非定型メール、電話など）はどのような形式で手に入るのかを聞いていきます。
次に、対象業務を「サブ業務区分」（これは初回ヒアリングで聞いた業務の更に細かい区分単位）に分解していきます。例えば、先述した経理財務の「請求書からの支払対応」業務については、以下のように細分化できます。
|
サブ業務区分 |
担当 |
使用システム／ツール |
発生頻度 |
業務時間 |
ＲＰＡによる削減％ |
|
（請求書到着前の見積書段階での）稟議申請 |
事業部 |
WF |
– |
|
|
|
（請求書到着後の）決済申請 |
事業部 |
WF |
– |
|
|
|
申請内容と実請求書との照合 |
経理 |
WF |
月初 |
|
|
|
未提出請求書の洗い出し |
経理 |
エクセル |
月初 |
|
|
|
差戻し／追加申請の依頼 |
経理 |
WF |
月初 |
|
|
|
申請の修正／追加申請 |
事業部 |
WF |
– |
|
|
|
支払い用の専用帳票への転記 ／支払先単位ごとの金額小計の算出 |
経理 |
エクセル |
月１回 |
|
|
|
ネットバンキングへの仮登録／承認 |
経理 |
ネットバンキング |
月１回 |
|
|
このように細分化された業務区分において、業務量を聞いていきます。またその際に「●●の業務のところは▲▲のようなやり方でロボットによる自動化ができるが、その場合、業務量は何％減るか」といった質問も併せてしていきます。そうすることで、業務時間とＲＰＡによる削減％の情報を埋めて置き、これらがあると計算して最終的に削減時間見積もりを出せるようになります。
ただし、実際に多くの業務ヒアリングをしてきた経験から言うと、なかなかこのような細かいサブ業務区分レベルで業務量や削減％を詳述できる現場担当者様はなかなかおりません。業務時間の方は、As-Isの話なので、何とか答えられるとしても、ＲＰＡによる削減％はTo-Beの話になるので、この細かいレベルでの回答は難しいケースが殆どです。その場合は、無理に厳密に細かい区分に固執せずに、このサブ業務区分単位からもう少し広げた業務範囲で「凡そ業務時間はどの程度か」、「この業務のうちの●●といった工程がＲＰＡ化された場合凡そ何％くらい業務量が減るか」といったことを聞くのが有効です。厳密性は確かに前者に比べて落ちてしまうのですが、何よりも現場の負担は少なくて済み、スタックせずに速やかに次の開発フェーズへの移行に進むことができます。
経理財務や人事総務、営業事務といった現場担当者様との２回目ヒアリングの結果、次の開発フェーズにおける要件定義をしていく上での基礎資料を作成します。上記のサブ業務区分とのこころで示したような表形式のフォーマットで成果物とするケースもありますが、今回のコラムではより踏み込んで開発フェーズに役立てられるようなテンプレートをご紹介します。
このテンプレートの特徴としては、As-Isの業務内容と、ＲＰＡ導入後のTo-Beの業務変化点を明確に分けて叙述できることが挙げられます。特に、To-Beについてはできるだけ細かいイメージを盛り込んで現場担当者様との確認を行うべきです。開発フェーズになると具体的に「どの工程をどのようなロジックでロボットに作業させるか」の話になってきます。そのような話を詰める際に、上記のような基礎資料があると大変生産的に進めることができます。また上記のテンプレートは整理のしやすさから表形式にしておりますが、現場担当者様と最終的なTo-Beのイメージ摺合せをするときには、もう少しビジュアル性のあるものが良いかもしれません。こちらテンプレートで記述された内容をもとに、フローチャートをコンサルタントが作り、そちらをもって最終的な確認を取ったりすることもしています。
RPA対象業務の実例（１） ～ 経理財務、人事総務、営業事務、購買等における各種書類媒体について
2018.05.08
今回のシリーズでは、RPA導入を検討されている企業様に対して、必要となるアクション、各種成果物のイメージをお伝えしていこうと思います。まず、RPAの導入を進めるに際し、
・どの業務がロボット化の対象となるのか？
・具体的にどのくらいの業務量削減は見込めるのか？
・導入に際して、人間側の業務はどのような変更が強いられるのか？
このあたりの、ポイントを抑える事が開発開始前に重要となります。これらの点を踏まえずに闇雲に開発を進めても、「手間はかかったが大した効率化になっていない」とか「業務手順が大きく変わってしまい、現場の社員から不人気で使ってもらえない」といった現象が起きてしまいます。このような事態を避けるために、RPA導入前の業務整理・分析は欠かせません。
今回のブログでは、特にこの業務分析フェーズの最初の段階を扱いたいと思います。
また、この前工程の業務分析フェーズは、コンサルタントと経理、人事総務などの現場担当者とのヒアリングセッションを通じて行われます。これは、上記論点を明らかにするのが第一目標ではありますが、実は隠れた目的もあります。それは、コミュニケーションを通じて、現場担当者様に「プロジェクトの趣旨を理解してもらい、協力関係を築くこと」と「RPAに対する理解を深めてくれること」にあります。
RPAも大きな括りで言えば、BPR、つまり業務改善・効率化の一種です。このカイゼン活動を続けていくには、現場の協力が無ければ不可能であることは自明の理でしょう。実際にRPAによるロボットと共に協働していただくことになるのが、経理財務や人事総務、営業事務といった現場の方たちです。この現場の協力を得られるかどうかで、ほぼプロジェクトの成否の半分以上は決まると言えるでしょう。
これはプロジェクトの趣旨を分かりやすい言葉（キャッチフレーズ）にして伝えることから始まります。このタスクは社員に対して説明責任のある経営陣、トップからコミュニケーションをとるべきです。当たり前ですが、メッセージの受け手の印象は、「発言内容（＝コンテキスト）」、「発言者」、「タイミング・場所」で決まります。特に同じ内容であっても、誰からの発言かによって、社員はそのプロジェクトの本気度を測ります。トップの本気度の低さを見透かされるようなコミュニケーションでは、現場は動きません。
特に、業務改善や効率化の施策は、現場にとって人員削減の伏線のような捉え方をする類のものです。そういう趣旨ではなく、あくまで、今いる人間の社員の残業時間を減らし、定型のルーチン作業からなるべく解放し、本来すべき頭の使う業務に専念してもらうためのプロジェクトであることをしっかりと謳うべきです。近年よく標語として使われている「働き方改革」のコンセプトを踏まえるのも有効です。
そのようにトップからプロジェクトの趣旨・目的を伝えていただき、より具体的な業務整理・分析フェーズに入ったら、コンサルタントは再度同様の説明を現場の方一人ひとりに対してしていきます。このようなコミュニケーションは繰り返すことが大事です。トップからのメッセージ＋現場での分析フェーズでのコミュニケーションを繰り返すことで、協力体制を築いていきます。
経理財務や人事総務といった管理部門の方たちは、その専門分野のプロフェッショナル性で採用されており、RPAによるロボットについての知識はもちろん最初はお持ちではありません。意識の高い、一部の社員の中には、既に文献で調べていたり、もしかしたらご自身でいくつかのフリーツールで試されている方がいるかもしれませんが、多くの現場の社員の皆さまは初めて聞くことが多いと思います。
ここで大事なのは、「答えは現場が持っている」という姿勢です。実際、経理財務や人事では比較的、各会社で行っている業務内容、使用ツールにバラツキは少なく、コンサルタント側である程度RPAの適用領域の目途が立てやすい部門ではあります。ただ、それでもイメージとしては、60~70％程度は企業横断的な汎用的RPA、30~40％はその会社固有のRPAを開発することになるケースが多いです。必ず少なくとも２～３つの良いアイデアは現場担当者様から挙がってきます。この時に、「RPAでできること・できないこと」をしっかりと担当者様に伝え、一緒にロボット化のアイデアを考えていくという姿勢が非常に重要になってきます。
RPAの仕様、できる事・でき無い事を伝えるに際して、パワーポイント等による言葉で伝えるのも一般的で効果が見込める手法ですが、百聞は一見に如かず、簡単なデモをお見せするのをお勧めします。画面上で勝手にロボットが作業していく風景は、一般の社員の方たちからすると目新しく、興味を引くことでしょう。好奇心から会話も弾むと思います。その上で、冷徹に「できること」と「でないこと／苦手なこと」を伝えていくのが効果的です。
参考リンク； RPAで課題解決できることとは？
それでは、いよいよRPA導入に向けた業務分析に入ります。ですが、ここで重要なのは「いきなりRPA対象業務の深堀りは行わない」ということになります。急いては事を仕損じる。つまり、まずは通常のBPRの手法を用い、ヒアリングを通じて平易に現状業務を分解・整理していくことを優先します。まずは全体像を抑えてから細部に行く、これは客観性を担保しなければいけない業務コンサルにとって必須の姿勢です。
まず、プロジェクト進行上の効率化を考えて、既存にあるマニュアル、SOP、タスクリスト、フロー図等を現場担当者様より提出していただきます。上場企業であれば標準フローを定めたマニュアルやSOPを持っている可能性が高く、またそうでなくとも、経理部門等は月ごとのルーチン業務が多く、かつ月締めの関係で日ごとのマイルストーンはが重要になってきます。即ち、そのような業務においては、月ごとに「今月すべきこと」のタスクリストをしっかりと作っているケースが多く、そのような一覧表も業務理解に役立ちます。大事なのはまずは、対象部署の業務全体を網羅した資料を手にいれることです。経理財務や人事はある程度行っている業務は推測できるので、コンサルタント側でたたき台を作ってのディスカッションも可能ですが、総務となると各社によってかなり行っている業務がことなってきます。この場合は、やはり現状業務のリストは現場側で用意してもらうほうが望ましいでしょう。
実際にはこの初回ヒアリングでは、現場部署側の既存資料を使ったディスカッションを行うことが多いですが、コンサルタントは、次フェーズに必要となる「RPA用業務リスト」の成果物イメージを念頭に置きながらディスカッションをリードする必要があります。現場から出された既存資料は、それはそれで有用であり、ディスカッションの呼び水とはなりますが、RPA対象業務選出用のメッシュになっているわけではありません。また、業務時間等の情報が抜けていたりします。むしろ●営業日内にする、といったリードタイムの記載が多い印象でしょうか。従って、次フェーズでより詳細にRPAによるロボット化機会を探っていく上で、コンサルタント側で、新規に書き直す必要はどうしても出てきます。現場担当者に余裕がある際は、そのRPAプロジェクト用の業務リストに書き直してもらうことをお願いすることもできますが、実際はそのような余裕は現場担者様にはないのが実情のようです。一旦、既存資料だけを共有して、そこでヒアリングを１回行い、コンサルタント側でRPAプロジェクト用の業務リストに書き直した上で、ロボット化機会をより精査する２度目のセッションを行う、といった方法がとられます。
ヒアリングの際には、以下の点を特に重要視して聞きます。
■業務フロー上の５W1H
・Who：業務担当者
・What：何の業務を
・When：いつ
・Why：なぜ／何の目的のために
・Where：どこで
・How： どのシステム／ツールを使ってするのか
■業務の複雑性（ＲＰＡ導入の難易度）
・対象部署内における担当者ごとの手順のばらつき
・業務ルールの脆弱性、例外処理の多さ（フローの分岐の多さ）
・業務フローを標準化する際のリスク・ボトルネック
■業務量、リードタイム、発生タイミング
まずは、RPA対象の有無にかかわらず、広く浅く業務フローを聞きます。この際に重要なのは5W1Hの視点、間接業務であればWhere（作業場所）は事務所になるのはほぼ自明なので、特にWho（誰が）、What（何の業務を）、When（いつ）Why（なぜ）、How（どのシステム／ツールを使って）の４Ｗ１Ｈが重要になります。Whyについてはなおざりになりがちですが、これは「そもそもその業務がいるのか？代替できないか？」というBPRの視点を入れる上で非常に重要になります。RPAの目的は業務量削減にありますが、何もロボットだけに効果を限定する理由は、経営層にも現場にもありません。また、RPAを導入する段階になったときに、人間側の業務手順も変更しないといけないケースも出てきますが、その業務フローの変更の正当性・可否を判断する上でも、その業務の目的（Why）を聞いておくことは重要です。
また、Howの「どのシステム／ツールを使ってするのか」という視点も特にRPAのプロジェクトでは重要になってきます。なぜなら、ロボットはシステム／ツールの種類により可動性が強く依存されてしまうからです。経理の場合は、まず会計システムが挙げられますが、その他にも開発ソフトウェアの資産計上のために勤怠データの使用もでてきます。また、経費申請や通常の請求書の支払申請ではワークフローシステムが使われているでしょう。また、自社から顧客に対する請求書発行業務にもシステムが使われているケースもあります。人事では、勤怠システム以外でも、採用管理や、内部の人事評価でSaaS型のクラウドサービスを使っているでしょう。営業事務ではセールスフォース等のSFAを使った顧客情報入力業務や、営業進捗のレポーティング業務が挙げられます。これらシステムの周辺領域として、おそらく各社独自にExcelでの管理帳票を作られていると思います。このシステムtoシステム、もしくはシステムtoエクセルの領域が、ＲＰＡ導入の一大機会となりますので、特に注意が必要です。システムによってはＲＰＡが上手く作動しないものもあるので、何のシステムを使っているのかの情報は必須で取得します。
次に、対象業務の複雑性、ＲＰＡ導入する際の難易度についてヒアリングを通じて推し量ります。まず、現時点において社員側で作業の手順が異なっており、定型ルールが未だ定まっていないケースがあります。この場合、ＲＰＡの導入以前に、まずは人間側のフローを標準化する必要があります。これは経理部や人事総務部内の作業手順だけの問題であれば比較的容易に標準化できるものだと思います。ベストプラクティスをしていると思われる熟練者にヒアリングし、その方のフローを標準とする考え方が一般的です。
次に、業務ルールの脆弱性、例外処理の多さ（フローの分岐の多さ）を精査します。業務ルールが定まらない理由としては、経理財務や人事総務と言ったＲＰＡ対象部署以外の要因が働いていることが多いです。つまり、事業部側や取締役など上層部の方たちの業務手順・やり方がコントロールできず、それが故に例外処理が多数発生しているケースです。このような自部署以外の領域を標準化する話になると、変革の負荷は高くなります。この場合、後フェーズで分析する削減時間見積との見合いで社内協議する形となりますので、ＲＯＩ的な視点、費用対効果の観点を持つことが社内を動かすうえで重要となります。
上記のような業務の複雑性を聞いていくうえで、仮に業務フローを標準化する際にどのようリスクがあるのか、ボトルネックは何かを確認します。先述したように事業部側や上層部に業務の仕方の変更を迫る場合、これら外部の社員、取締役に負荷をかけることになるかもしれません。もしくは、何か新しいシステムを導入することになっており、そのシステムの仕様が決まらないうちは、どのような標準化がいいのか決まらない、といったケースもあります。その場合は、新システムの仕様決定というのはボトルネックとなり、それまではプロジェクトが進捗できないと言えます。
この「業務量、リードタイム、発生タイミング」については、５Ｗ１ＨのWhenにも通じる項目ですが、特にＲＰＡ導入検討において重要な点になりますので、改めて取り上げます。業務量は、ＦＴＥ（Full Time Equivalent）という言葉や、単に業務時間という言葉で表されます。ＦＴＥは例えば１人月＝1 FTEと換算し、対象業務がそのうちどの程度を占めているかを表します。ただ、一般的に現場では扱いにくいコンセプトですので、ここでは普通に●●時間といったような業務時間を使うことが多いです。この場合、一般的に毎月●●時間というように均すのが一般的です。例えば、週に３時間の業務量であった場合は、３時間×４週＝１２時間／月というようにします。また、四半期に１回の業務で６時間かかる場合は、６時間÷３か月＝２時間／月といような計算をします。
ここで大事なのは、この業務量の概念とリードタイムの概念とを混同しないことです。例えば、ある業務が月初から５営業日以内に終わらせるものだったとしたら、リードタイムは５営業日となりますが、業務量は必ずしも５人日とは限りません。５営業日の中で他業務もしている可能性は有りますし、また実は複数名でその業務を対応しているケースもあります。現場担当者様にヒアリングをする際には、その点をしっかり説明して回答して頂くことが求められます。
次に、発生タイミングについてですが、例えば毎日なのか、毎週なのか、各月か、半年に１回なのか、などを明らかにします。基本的にＲＰＡに向いているのは高頻度の単純作業です。半年に１回であったり、年１回であったりする業務は、そもそも次の発生時にルールが変わっている可能性も高く、ロボット化が難しかったりします。また、半年・年１回の業務だと月に均すと実はそれほど業務量がなかったりします。このように低頻度の業務はなかなかＲＰＡの対象とはならないのですが、但し、それが年度末であったり組織改編のタイミングであったりと、他業務の負荷も高く人員リソースがひっ迫してしまう時に発生する業務であればＲＰＡの対象として有望となりえます。これは月に均すと大した削減時間にはならないかもしれませんが、決算報告のタイミングが早くなったり、社員の負荷感の軽減・深夜残業の抑制等、時間削減以外のメリットが訴求できる可能性があります。その場合は、その点を注記しておくと良いと思います。
次のコラムでは、この初回ヒアリング終わったあと、２回目の精査ヒアリングの話に移ります。乞うご期待ください。
RPA導入の進め方～事例から見るノウハウ・必要ステップ（２）： ２回目業務ヒアリング～ＲＰＡ機会の精査・深堀り
2019年5月に東京ビッグサイトで開催される展示会への出展が決定しました。
期間中は、RPA導入に関する無料相談会を実施いたします。無料相談会のご予約はこちらまで。
2018.05.01
「コミュニティエディション」とはグローバル企業である「UiPath」が提供している、非営利団体向け製品です。
「UiPath」は”人の仕事は創造的で、刺激的であるべきだ”というキャッチフレーズをもとに、
RPA(Robotic Process Automation)を中心にビジネスの効率化や多くのプロセスを自動化しようとうたっている企業です。
「コミュニティエディション」は、その「UiPath」が小規模企業向けに無料で使用できる拡張可能なRPAツールです。
先ほども述べたように、「コミュニティエディション」はどの企業でも・誰でも無料で使用できるわけではありません。
今回はこの「コミュニティエディション」の利用規約などをまとめていきたいと思います。
まず初めに実際の利用規約です。
License Agreementへのリンク : 英語版
「コミュニティエディション」を無料で使用するには少なくとも以下の条件が必要です。
利用規約を参照したうえでご自身でもご確認ください。
‣売り上げが100万ドル以下または端末数が250台以下の小規模事業者である
‣教育機関や研究機関である
‣非営利法人である
つまり、非営利団体である小規模の事業者などを対象にした制度であることがわかります。
*利用規約は今後変更される可能性があるので正確な情報はご自身でお調べください。
「コミュニティエディション」は小規模の企業や個人でしか使用できないので、
一般の大企業では無料版のものを使用することはできません。
しかし有料版の「UiPath Studio trial」などの60日間の無料体験期間を体験することができます。
この無料体験後に、導入するかどうかの検討をして申し込むことが可能です。
またこの無料版では個人的な使用は認められているため、試験的に個人的なスキルの向上トレーニングなどは可能となっています。
ですので、大きな企業でも新入社員のトレーニングや評価のために使って、その後に有料版にうつることも可能です。
「コミュニティエディション」は小規模の企業向けの素晴らしいRPAツールであることだけではなくて、
無料で使用できないような企業などでも使い方によってはうまく使っていけるようなサービスです。
どちらにしても利用規約をしっかりと確認したうえで戦略的に使用していくことが望まれます。
