2018.08.31
よくお客様からの質問で「プログラミングができない人でもRPAの操作を覚えることはできますか？」と聞かれることがあります。
結論から言うと、あくまで私見ですが、やはり多少のプログラミングの勉強をしてから、
もしくはある程度プログラミングの基礎知識のある方が行うほうがより生産的になると思われます。
RPAのツールであるUIPATHやWinActorなどはワークフローという概念を使って、
プログラミングの知識のない人でも簡単に自動化ツールを作成できるように設計されています。
これらのRPAツールは、そもそものコンセプトとして、プログラム言語の入力をしないでも実装ができることを謳っています。
確かに、クリックするだけやダウンロードするだけなど、本当に簡単な業務であれば可能ですが、
実際にRPA化しようとする業務は、そこまで簡単なプロセスだけで構成されているわけではありません。
というのもRPA化の対象となる業務というものは、単一の簡単な作業だけで終わるものでなく、
幾つかの工程が連結して一つの業務になっているからです。
例として、webサイトからデータを取得し、加工してからエクセルへ書き込む業務アプリのアルゴリズムについて考えてみましょう。
一般的なプロセスの流れは以下になります。
1. Webブラウザを起動する。
2. 対象のURLを入力してWebサイトを開く。
3. データが表示されているページへ遷移する。
4. 取得対象のデータを指定し、取得する。
5. Webブラウザを終了する。
6. エクセルへ書き込みをするためのデータ加工をする。
7. エクセルを開く。
8. エクセルの対象セルに書き込む。
9. エクセルを保存して閉じる。
上記、簡単にではありますが、アルゴリズムを挙げてみました。冗長な点がありますが無視します。
プログラミング経験者は、ここで、どうすれば実現できるかをイメージできるかと思います。
上記に挙げたこれらの各工程ですが、それぞれ単一の動作（＝ 業務アプリのアルゴリズムの一手順）だけであれば、
プログラミング初心者であっても容易に自動化することはできるかもしれません。
しかし、それでは業務自体は終わってませんよね？
工程の一部だけを自動化しただけであれば、残りの工程については、
人間による手作業で行わなければならず、自動化の恩恵を十分に享受することはできません。
この例でいうと、webサイトから情報を取得し、
エクセルに書き込むまでが一つのまとまった業務であり、それらの連結を意識する必要があります。
ここで、上記の工程を全て自動化する場合にやること、気を付けるべきことについて述べていきたいと思います。
あくまで一例ですが、具体的にどうすれば実現できるか、UIPATHを例に考えてみましょう。
1. Webブラウザを起動する。
2. 対象のURLを入力してWebサイトを開く。
3. データが表示されているページへ遷移する。
→ この1~3.の工程については、OpenBrowserアクティビティに対象ページのURLを設定することで実装できます。
4. 取得対象のデータを指定し、取得する。
→ Data Scrapingでwebページのスクレイピングをしてデータを取得します。
5. Webブラウザを終了する。
→ Close Applicationアクティビティでブラウザを終了します。
6. エクセルへ書き込みをするためのデータ加工をする。
→ データテーブルの構造など、書き込みできる形式に変換や、計算などをします。
7. エクセルを開く
→ Excel application scopeアクティビティに対象エクセルのPathを設定します。
8. エクセルの対象セルに書き込む。
→ Write RangeアクティビティやWrite Cellアクティビティなどを利用して書き込みます。
→ また、書き込みたいデータが複数ある場合は、For Eachアクティビティなど、ループを利用して書き込みます。
9. エクセルを保存して閉じる。
→Close Workbookアクティビティでエクセルを閉じます。
上記では、簡易的に最小限の必要アクティビティを列挙しましたが、実際のRPA開発の現場では、
エラー発生時の振る舞いについても考慮し、実装しなければなりません。
例えば、Webサイトが改変されて、必要情報の位置が変化したとき、対象エクセルファイルが指定フォルダに無かった場合、
取得した値が計算できないものであるとき（0での割り算、「円」等の文字が入っている）等、
エラーの種類には様々なケースが想定されますが、それらが起こった時の対処方法も考える必要があります。
また、汎用化を考えたとき、変数や、配列、関数やサブルーチンなどの知識も必要になるでしょう。
例えば、汎用化を考えた場合、ＵＲＬ等の個別情報をUiPATH内に直に書き込むよりか、
エクセル等の外部ファイル（設定ファイル）に値を持たせて、何か変更があった場合は、
そのファイルを書き換えて対応する手法が一般的であったりします。
また、サブルーチンも汎用化するときによく使われる手法です。
一つのプログラムファイル（UiPATHだとXamlファイル）内に全て打ち込むのではなく、
汎用的で他プログラムにも使えそうな機能については、サブルーチンとして切り出します。
UiPATHだとこのサブルーチンはワークフローという名称で扱われるものになります。
このようなサブルーチンとなる機能としては、例えば、
「読み込んだデータをPDFで出力する」とか「年号を西暦に変換する」、「PDFを読み込んでExcel化する」といったものが挙げられます。
プログラミングの基本に順次・分岐・反復というのがありますが、上記業務アプリにも必要な知識となります。
順次というのは「上から順番に下まで処理する」ということで、プログラミングの基本フローとなります。
分岐というのは条件分岐のことです。
これは通常「if」を用いて扱われるものです。
業務処理をする上で、幾つか場合分けをする必要があるとき、
例えばWebから取得した情報が一定の値以上の時とそれ未満のときで出力ファイルを分けるなど、
条件によって処理を分けたい時に使われます。
反復というのは、配列やデータテーブルなど、データの塊を処理するときによく使われるものです。
「for」や「while」といった文が使われます。
例えば、取得したデータテーブルにおいて、一行一行値を取り出していくときなどに「For Each」文等が使われます。
このように、ひとつの業務を自動化するには、少なからずプログラミングの知識が必要になります。
従って、まったくの未経験の状態でトライするよりかは、
ある程度基礎知識を身に着けた上で取り組まれるのが望ましいと言えます。
ただ、プログラミングの概念自体は単純ですので、
少し勉強すればだれでも簡単な業務アプリは作れるでしょうし、RPAツールはそのような設計になっています。
つまり、RPAツールというものは、実は、多少なりともプログラミングの経験者を対象としているわけです。
多くの巷間のRPAツールは「誰でもできる」ということを謳っていますが、
その言葉をそのまま信じてプログラミング未経験者である総務担当や経理担当の者がトライして挫折するケースをよく耳にします。
やはり、私としては、いきなりＲＰＡに取り組まれるよりかは、まずはプログラムの基礎勉強をしてから望むことを推奨します。
そのほうが、実際にＲＰＡツールに手を触れた時の理解も進むと思われます。
こういった自動化技術の広まりによって、人的ミスの撲滅や、人件費削減など、一見メリットに思える一方で、
AIやIoTの発展によって、ユビキタスネットワーク化が進み、人間の仕事がなくなるのでは、とまで言われています。
結構ネガティブと捉えがちですが、ポジティブに考えれば、定型的な業務はロボットで自動化し、
空いた手をクリエイティブな業務に活かすことで、社会も、会社も、労働者も一緒に成長することができるのではないでしょうか。
これを機に、ユビキタスネットワークの世界に飛び込んでみてはいかがですか？？？
2018.08.30
前編はこちら
前編では、Excelの自動化の基本や簡単なデータテーブルの扱い方について見ていきました。
今回はExcelに実際の関数を書き込んでみたり、
Excelファイルをバックグラウンドで操作したり、していきたいと思います。
UiPath Academy「レッスン9」を参考にして、二つの合計値を求める問題を例に見ていきたいと思います。
今回はどのように考えて、ワークフローを構築していくかについても詳しく見ていきます。
まずは上記のような簡単なExcelファイルを用意します。
各行のCの列にAとBの合計値を書いていく問題を考えてみます。
この問題を三つの方法で解いていきたいと思います。
この方法が一番直感的に、すぐ思いつく方法でないでしょうか。
私たち人間が、一つ一つのセルを見て数字を見て（読み込んで）足していくのはとても大変な作業です。
これを機械ではとても簡単に高速で行ってくれます。
簡単なワークフローを文字に起こすと順序としてはこうなります。
各行に対して、
Aのセルの数字は何か見る
↓
Bのセルの数字は何か見る
↓
CのセルにAの数字をBの数字にを足したものを書き込む
このようなワークフローを人間も行うでしょう。
では、順序が分かったところで実際にUiPathを使って自動化していきましょう。
手順0）
まず、大枠は必ず「Excel application scope」アクティビティを使いましょう。
これによって今後のExcelの状況がリアルタイムで確認可能です。
そして、使用するExcelファイルのパス名を入力してください。
（相対パスを書く場合は現在のワークスペースからの相対パスを書いてください）
手順1）
まずは、Excelファイルをデータテーブルに置き換えます。
前編でもご紹介したように、データテーブルの方が簡素で操作しやすいので、
一度Excelのファイルをすべて読み込んでそれをデータテーブルに写します。
この際に使うアクティビティは「Read Range」アクティビティです。
すべてを転写するので、開始位置は空白で大丈夫です。
この時に注意しなければいけないのは、AddHedderのチェックボックスです。
ここにチェックを入れてしまうと、初めの一行目がヘッダーとして認識されてしまうので注意してください。
手順2）
上で書いたワークフローの通りにいくと、Aのパスを見る動作に移りたいところですが、
その前に、各行でという枠組みを忘れないようにしましょう。
各行でということで同じ作業を何回も繰り返すので、forループをつくりたいところです。
ということで、今回は「For each row」アクティビティを使用します。
「For each row」は上のように使い、このような場合はrowという変数はDataRow型となっています。
DataRow型とはデータテーブルの任意の行のデータのみをもつデータ型です。
簡単にいうとこのような感じです。
注意しなければいけないのは、「For each」アクティビティとの違いです。
「For each」アクティビティは取り出す変数の型を必ず決めないといけないのに対して、
「For each row」アクティビティは取り出す変数の型がDataRow型と決まっています。
データテーブルを扱うにおいては後者の方が使いやすいでしょう。
手順3）
では、変換したデータテーブルから値を読み取りたいところですが、
その前に注意しないといけないことがあります。
データテーブルの行のインデックスは0から始まる
データテーブルの行は、Excelファイルの一行目から始まるのとは違い、
ひとつずれた0行目から始まります。
これを解消するために新しいインデックスを追う変数をつくりましょう。
これには、「Assign」アクティビティを用いて、新しい変数rowIndexを
rowIndex = inputsTable.Rows.IndexOf(row)+1
としましょう。(inputsTableは手順1で生成したデータテーブルの変数名です)
これで”行のインデックスに1足したもの”を新しいインデックスにすることができて、
rowIndexは1,2,3,4,…のように進んでいくことができます。
手順4）
やっと、データテーブルから値を読み込むことができます。
「Get Row Item」を使用します。
A列目のものから取り出してみましょう。
プロパティのColumnIndexに0と入力して、Outputに変数名を入れましょう。
0と入力したのは、0列目ということです。（列も1から始まらないので注意してください）
同様にB列目についてもおこなってください。（ColumnIndexを1と変えるだけです）
手順5）
最後に、読み込んだAとBの値を足したものをExcelファイルに書き込みます。
「Write Cell」アクティビティを使用します。
書き込む場所は、
“C”+rowIndex.ToString
のようにします。
ここで手順3でつくった変数が役に立ちます。
これで、C1,C2,C3,…のようにセルに書き込むことができます。
書き込むのはもちろん、A+Bの値です。
これで終了です。
この方法は一番やりやすいですが、いくつか注意点があったので間違えないようにしてください。
この方法では、Excelアプリを使わずにバックグラウンドで計算をして
その結果をExcelファイルに書き込みます。
基本的には先ほどと同じなのですが、いくつか変わる点などありますので
その相違点を確認しながら見ていきましょう。
まずは、大まかなワークフローを書き出してみます。以下のようになります。
Excelファイルをデータテーブルに変える
↓
データテーブル上で足し算をすべて行う（足し算方法略）
↓
データテーブルをすべてExcelファイルに書き出す
＊足し算の内容などは先ほどと同様なので省略しました。
先ほどは足し算をしたらすぐにExcelファイルに書き込んでいましたが、
今回はすべての計算を終えてからExcelファイルに書き込んでいます。
やり方が変わったといっても本質的には同じです。順番が変わっただけです。
実際にやり方を見ていきましょう。
Excelファイルを「Read Range」アクティビティで読み込むまでは同じです。
その後、「Excel application scope」を今回は使用しません。
「Add data column」アクティビティを使用します。
このアクティビティには、追加する列の名前と型を入力することで
データテーブルに新しい列を追加することができます。
次に先ほど、手順5で行ったことを「Assign」アクティビティを使用して行います。
row(2) = Integer.Parse(valueA) + Integer.Parse(valueB)
のように記述します。
Integer.Parse（値）というのは値をInt型に変換するものです。
今回は直接データテーブルに書き込むので「Assign」アクティビティを使用します。
最後に、「Write Range」を使用してExcelファイルに書き込めば終了です。
スタート位置を指定しなければ初めからとなります。
この方法は、今までのものよりも単純にワークフローを組むことができます。
Excelファイルの行の大きさ（何行あるか）を求める
↓
すべての行に対して関数を書き込む
たったこれだけです。
今までの計算のところがただ関数に変わっただけなので本質はこれも変わりません。
行の大きさ（何行あるか）は、「inputsTable.Rows.Count」で求めることができます。
よって、C1～C(行の大きさ)まで関数を書き込めば終わりです。
もちろん、書き込む際には「Write Cell」を用いて、
“=SUM(A1,B1)”
のように書きます。
今回は、三種類の方法で合計値をExcelファイルに書き込んでみました。
一つ目は、基本的な方法で足し算ができ次第ファイルに書き込んでいく形式でした。
二つ目は、すべての計算を終えてから一気にファイルに書き込んでいく形式でした。
三つ目は、関数をそのままファイルに書き込んでいく形式でした。
どの方法が確実にいいと言う訳ではありませんが、それぞれの特徴をよく見て
場面ごとに使い分けられればいいのではないでしょうか。
2018.08.29
UiPathではいくつかの自動化のツールが存在しますが、
今回はその中でもExcelを用いて自動化をいくつかやっていこうと思います。
自動化を始める前に、まずは環境構築が必要です。
といっても、そんなに難しいことではありませんので見ていきましょう。
UiPathにはExcelの自動化を補助するアクティビティは元から入ってはいません。
ですが、すぐに追加することができます。
みなさんもアクティビティなどをワークフローに追加したりするのに使っている、
アクティビティパネルをご覧ください。（デフォルトでは左側にあります。）
アクティビティパネルの上側にある「Manage Packages」をクリックしてください。
その後、Availableから「UiPath.Excel.Activitis」をインストールしてください。
これでUiPath内の環境構築は終わりました。
今からExcelの自動化を行うのですが、この際にExcelアプリを使う必要があるかどうかを見ていきます。
実は、Excelの自動化と言ってもExcelアプリをインストールすることなしに自動化することもできます。
この場合は、すべてのワークフローがバックグラウンドで実行されてExcelを開く必要がありません。
ですので、Excelアプリのインストールなしに全てのワークフローを行うことができるのです。
しかし、どのようにセルの値が変わっているかどうかなどをリアルタイムで確認することはできません。
Excelアプリを使った利点としては、リアルタイムで現在の状況を見ながらデバッグすることができる点です。
デバッグはExcelアプリを使って自動化を行ったほうがやりやすいのかなと思います。
やり方などについては後程具体的に見ていくことにしていきたいと思います。
これからのデータはExcelワークブック、もしくはデータテーブルというものを用いて扱っていきます。
これらにはどのような違いがあるのかを見ていきます。
＜Excelワークブック（Excelファイル）＞
エクセルファイルへの参照型であって、あらゆるタイプのデータテーブルを格納できます。
書式設定やシート、レイアウトや結合セル、複数のデータテーブルなどの情報を持つことができて、
多様なデータを扱うことができます。
＜データテーブル＞
データテーブルは一番単純なタイプの表形式のデータです。
行と列で構成された単純なデータ型を持ちます。
途中で抽出した表形式のデータをデータテーブルに格納しておくことが多いです。
まずはこちらのRPA_bizページのホームにある記事の名前とリンク先を
Excelファイルに保存することを行いたいと思います。
1.データスクレイピングからデータをデータテーブルに保存する
ここに関しては、今回のExcelの自動化についてとは少し範囲が違うので詳しくは説明しませんが、
リボンにある「Data Scraping」からウェブページ上の情報を抽出してください。
今回は二ページ目までを読み込むことにしました。
これをデータテーブルに書き出してください。
（プロパティの「Output」にデータテーブル名を書き込むだけで可能です。）
現在のワークフローはこのようになっていると思います。
2.抽出したデータテーブルを新しいExcelファイルに保存する
さて、ここからが今回の本題です。
まずは「Excel application scope」アクティビティを用意してください。
このアクティビティは非常に重要です。
これからのExcelファイルの自動化においては必ずと言っていいほど、このアクティビティを使用します。
「Excel application scope」アクティビティはシーケンスのように、コンテナの役割を果たします。
このアクティビティ内にこれから使用するExcelのアクティビティを格納してください。
Excelファイルに対する操作を行うアクティビティは
このアクティビティ内でないと機能しないアクティビティばかりなので注意してください。
では実際に使っていきます。
一番上の「Workbook path」には 使用したいワークブックのパスを入力します。
初期設定は現在のプロジェクトの場所を開きますので、
手動でパスを手入力する場合は現在のプロジェクトからの相対パスを入力してください。
動的なパスを入力する場合などはご注意してください。
また、右の「…」をクリックすることで実際にファイルを操作しながら、パスを指定することができます。
次に、プロパティ欄の「Visible」のチェック欄です。
ここにチェックをすることでこれからのワークフローがExcelアプリを通じて実行されます。
（これにはExcelアプリのインストールが必要です）
また、ここにチェックをいれないことでバックグラウンドでこれからのワークフローを行うことが可能です。
今回はチェックを入れて行いたいと思います。
さらに、ワークパスには”test_file”と入力しました。
もしも、指定のExcelファイルがない場合は自動的に新規作成して保存してくれます。
今回はプロジェクトがあるフォルダにファイルを新規作成するので”test_file”とするだけにします。
3.シートにデータテーブルを書き込みむ
シート内に書き込むためには「Write Range」アクティビティを使用します。
このアクティビティは開始位置を決定して、それ以降にデータテーブルを書き込むアクティビティです。
似たものに「Read Cell」アクティビティがありますが、これは一つのセルを書き込むためのものです。
プロパティ欄の「Add Header」のチェックをすることで初めの行ににラベルを追加することが可能です。
最後に保存が完了したことを知らせるメッセージを表示させて終了です。
以下のようなワークフローになっていると思います。
実行してみると無事にExcelファイルに書き込めていることがわかると思います。
次に、今作成した”test_file”を簡単にカスタマイズしていきたいと思います。
具体的には、名前ごとにソートしてみたり、セルを追加したり、読み取ったりを行っていきたいと思います。
・名前順にソート
ソートするには「Sort Table」アクティビティを使用します。
この際に注意が必要なのは、Excelで事前にテーブルをつくる必要があることです。
（テーブルの作り方は、範囲をしていして、挿入の中のテーブルボタンを押すだけです。）
・最後にデータを追加
「Append Range」を使用することによってシートの末尾にデータを追加することができます。
ここで注意しなければならないのは、追加できるのはデータテーブルのみであることです。
データテーブルを手動で自作する場合は、「Build Data Table」アクティビティを使用して作成してくだいさい。
・データテーブルを文字列に変換
「Output Data Table」を使用することによって、データテーブルを文字列に変換することができます。
プロパティの「Input」に読み取るデータテーブルを入れて、「Output」に文字列を格納する変数を入れます。
・Excelのすべてのセルを抽出する
「Read Range」を使用することでExcel内のすべてのセルを抽出することができます。
何も指定しなければ、すべてのセルを抽出します。
他にもいくつかのアクティビティが存在しますので、UiPathの Excel Activity Packについて
を見ながら使用することをおすすめします。
ウェブページから抽出したデータテーブルをExcelファイルに写して、
簡単なデータの取り扱いを行いました。
後編に行うのは、実際のExcelファイルに関数を書き込んだり、
Excelファイルを開かずにバックグラウンドで作業することを行います。
後編はこちら
2018.08.28
今回のコラムでは、人材派遣会社によるRPA研修の動向について紹介したいと思います。
最近では、RPAの普及に伴い、様々な企業がRPA研修を開催していますが、
研修を開催する目的としては、大きく以下の２つに分かれます。
このうち、「RPAエキスパートになるためのキャリア育成」に関しては、
現在人材派遣会社による研修が活発に行われています。
人材派遣会社がRPAの研修ビジネスに参入する背景としては、2015年９月末に施行した、改正労働者派遣法の影響があります。
これは、派遣労働者が同じ職場で働ける期間が一律３年までとなり、
３年を超えた場合は派遣労働者の雇用主である派遣会社が派遣先の企業に直接雇うよう依頼するなどの措置が義務づけられるものです。
こうしたことから、人材派遣会社は、スキルを高めて企業に選ばれる労働者に育て上げたいという考えを持っているのでしょう。
以下では、現在RPA研修を開講している人材派遣会社の動向を紹介します。
現在RPA研修を開講している会社は3社のようです。
ヒューマンホールディングス傘下のヒューマンリソシアは１日完結型のＲＰＡの研修講座を東京、大阪、名古屋を中心に行っています。
ヒューマンリソシアは自社の派遣労働者向けに習熟度に応じて初級、中級、上級の３講座を開講しています。
研修では株式会社NTTデータのRPAツール「WinActor」を使用します。
初級コース：初級コースでは、WinActorに初めて触れる方を対象に、基本的な機能の説明とともに、
簡単なシナリオ作成を通じてWinActorの使い方の理解を深めます。
ヒューマンリソシアのWebサイトには特に記載が無かったのですが、一定水準のExcelの使用経験がある方が良いでしょう。
研修時間は7時間×1日。受講料は30,000円/人（税抜）となっています。
中級コース：中級コースでは、WinActorの基本操作および簡単なシナリオ作成が出来る方を対象に、
実践的な例題によるシナリオ作成・講師による解説を通じ、効果的なシナリオ作成を実現するための知識を養います。
研修時間は各7時間×2日となっています。受講料は50,000円/人（税抜）です。
上級コース：上級コースでは、決められた手順情報からシナリオ作成が自立的にできる方を対象に、
中級までに把握したWinActorの各機能を活用し、実践的にシナリオを作成することで、
自立して作業ができる方を育成します。
研修時間は7時間×1日。受講料は中級と同じく50,000円/人（税抜）です。
上記のほか、全国各地域でセミナーも実施しているようです。
7月～8月：RPAタッチ&トライセミナー（名古屋）
7月～8月：失敗しないためのRPA導入セミナー＆ハンズオン
8月：失敗しないためのRPA導入セミナー＆ハンズオン（大阪）
8月：RPAタッチ&トライセミナー（広島）
8月：RPAタッチ&トライセミナー（福岡）
8月：RPAタッチ&トライセミナー（仙台）
8月：失敗しないためのRPA導入セミナー&ハンズオン（東京）
9月：基幹システム×RPA連携活用セミナー（長野）
研修の詳細はヒューマンリソシアWebサイトをご覧ください。
https://resocia.jp/corporate/solution/rpa/traning/index.html
パーソルプロセス＆テクノロジーは、2017年4月にRPA事業の専門組織を立ち上げ、
コンサルティング、システム開発、導入、運用、トレーニングまでをワンストップで提供する、
「RPAトータルソリューション」サービスを展開しています。
グループ内へはもちろんのこと、これまで数百体を超えるロボットを、顧客の業務に導入した実績があり、
これらのノウハウや知見を活かし、RPAの専門人材育成のための独自プログラムを開発。
市場ニーズの高いRPA技術者の育成強化を実施しています。
パーソルプロセス＆テクノロジーでは「働き方改革×RPAセミナー（検討編/導入編）」、
「WinActor研修（基礎編/応用編）」、「UiPath研修（基礎編/応用編）」を開講しています。
働き方改革×RPAセミナー
こちらのセミナーはRPA【検討編】と【導入編】の2段階式セミナーとなっており、
RPAの導入段階に応じた内容を提供します。
東京での開催となっており、どちらも受講料は無料です。
検討編：「RPAについてまだよくわからない」「RPAツールの違いがよくわからない」という方に向けて、
RPAの概要やRPAツールの特徴について説明します。
RPAについて興味を持っている企業経営者、役員、または部署のマネージャーが対象となっています。
＜内容＞
1部：働き方改革になぜRPAが必要か 15:00～15:40
RPAを導入するそもそもの目的である「働き方改革」に着目しながらRPAの概要を説明。
2部：RPAツールデモと導入事例 15:50～16:30
RPAツールの特徴をデモ動画とともに説明し、最後に実際の導入事例を紹介。
3部：RPA導入相談会 16:30～17:00
導入編：「事例をもっと見たい」「実際の導入の流れを知りたい」という方に向けて、
RPAの事例やRPA導入のステップ・ポイントをご紹介します。
具体的な対象者は、RPAの導入を実際に検討している企業の経営者、役員、または部署のマネージャーになります。
＜内容＞
1部：RPAで実現する現場の働き方改革 15:00～15:40
現場でRPAが機能するための導入プロセスについて解説。
2部：RPA導入成功のポイントと導入事例 15:50～16:30
RPA導入に失敗しないためのポイントと導入事例を紹介。
3部：RPA導入相談会 16:30～17:00
WinActor研修
WinActor研修では基礎編と応用編があります。
基礎編（1日間）：基礎編はWinActorを初めて触る方向けの研修です。
実際にパソコンを使い、その基本的な操作方法と、実際のロボットの作成方法を習得できます。
NTT-AT社の公式チュートリアルに加え、独自の演習問題を用いて、
WinActor上でのプログラミングの基本スキル（変数・分岐・繰り返し）を習得できます。
東京での開催で受講料は40,000円/人（税抜）です。
＜内容＞
中級編（1日間）：中級編は研修の基礎編（または公式チュートリアル初級、中級）を習得済みの方向けの研修です。
独自の演習問題を用いて、実践的に各種データの処理方法を習得できます。
複数の演習問題を解くことにより、WinActorにおける変数・分岐・繰り返しの処理を応用し、
ワークフローを自動化する方法の理解を深めます。
東京での開催で受講料は50,000円/人（税抜）です。
＜内容＞
UiPath研修
UiPath研修も基礎編と応用編の2種類があります。
基礎編（1日間）：このハンズオン研修では、RPAに興味がある方、
または何らかのプログラム経験がある方（例：MS Excelのマクロ、MS Access等）を対象に、
UiPathを使って簡単なロボットを作成することができる基本的な知識と操作を習得することができます。
東京または大阪での開講で受講料は60,000円/人（税抜）です。
＜内容＞
・イントロダクション
－RPAとは
－UiPathの概要
－主要機能の紹介
・ハンズオン研修
－基本操作
－プロジェクト作成
－シーケンス
－フローチャート
－レコーディング
－Excel操作
－Datatable
・演習
－実践問題
－アクティビティ紹介
応用編（2日間）：このハンズオン研修では、RPAのアカデミーを受講済みの方または基礎研修を受講済みの方、
もしくは何らかのプログラム開発経験がある方（例：JAVA、C、.NET 等）を対象に、
保守性が高く、改変に強いロボットが作成できる開発技術を身につけることができます。
2日間の研修で受講料は100,000円/人（税抜）です。
＜内容＞
・応用研修(1日目)
－データ操作手法
－外部ファイルの使用
－他ロボットの呼出
－レコーディング
－セレクタの改修(変数・ワイルドカード・ランチャー)
－Data Scraping
－画像取得
－エラーハンドリング手法
・応用研修(2日目)
－実践演習
－開発標準紹介
－アクティビティ紹介
研修の詳細はパーソルプロセス＆テクノロジー株式会社Webサイトをご覧ください。
https://www.persol-pt.co.jp/eventseminar/list/rpa/
パソナは希望するスタッフに、RPAの導入技術を教える研修を行っています。
RPAエキスパート育成講座 Starterコース
RPAの概念、業務調査についての基本的な考え方、RPAツールで自動化出来ることを実際に操作し、学ぶコースです。
講座で使用するRPAツールはWinActorです。
こちらの研修を通じて、以下の成果を得ることができます。
料金は６時間で１万800円。
研修を経て導入技術者になった派遣スタッフは現在100人いるそうで、１年間で受講者を3000人まで増やす計画だそうです。
研修詳細はパソナWebサイトをご覧ください。
https://www.pasona.co.jp/careerup/rpa/starter.html
2018.08.27
今回のコラムでは、私が参画したRPA導入プロジェクトの経験をもとに、
RPA導入における運用保守の仕組みを検討する際の確認ポイントを紹介したいと思います。
はじめに、ロボット構築における全体の流れを紹介します。
まずはロボット化の事前準備として、どの業務に対して自動化を行うかを洗い出します。
対象業務プロセスの選定にあたっては作業時間や業務の処理量、人数等、様々なアイデアがありますので、
実際に対象業務プロセス選定を行う前に一定の基準を決めておくことをお勧めします。
（１）で洗い出した業務内容（社内システムやツールの画面コピー等）を業務マニュアルや業務フローにまとめます。
各ドキュメントの位置づけとしては、業務フローは自動化後の業務全体の流れの把握用、
業務マニュアルは業務の詳細を確認するためのものになります。
ユーザ部門は、業務内容のドキュメント化が完了したら、保守チームにロボット化の申請を出します。
保守チームはユーザ部門から提出されたロボット化の申請内容を確認し、ロボット化の可否について判断します。
ロボット作成にあたっては、どんな業務でも自動化できるわけではないため、
保守チームはここで一定の申請内容のチェックを行います。
確認内容としては、業務担当者名/対象業務名/対象業務の処理件数/インプット先のツール、
システム名/アウトプット先のツール、システム名/作業時間/作業頻度等があります。
これらの項目のチェックを円滑に行うためにも、ロボット作成前用のチェックリストを作成することをお勧めします。
（３）の申請が通ると、次はロボット作成に入ります。
ロボット作成においては、RPAスキルの有無に応じて、ユーザ部門で行う場合と保守チームで行う場合があります。
後者の場合、保守チームはユーザ部門に対してロボット作成の所要日数をあらかじめ案内します。
ユーザ部門は申請した業務がロボット化されるまでは従来通り手作業での業務を継続します。
保守チームは、保守チームまたはユーザ部門でのロボット作成が完了した後、ロボットのリリース（稼働）前に、
ロボットの内容の最終確認を行います。
リリースの判断を行うにあたってチェックする項目としては、
ロボット化対象業務名/作成したロボットの仕様（処理頻度/処理スケジュール/合計処理時間/RPAツール名（複数導入している場合））/検証結果（検証環境/検証時に発生したエラー）等があります。
これらの項目のチェックを円滑に行うためにも、リリース前確認用のチェックリストを作成することをお勧めします。
保守チームはロボットを稼働させるために、サーバ上にロボットデータをアップロード（リリース）します。
ロボットは手動で起動される場合と自動で起動される場合がありますが、自動で起動される場合は、
サーバ上にロボットデータをアップロードする際にスケジュールを設定します。
なお、ロボットが複数ある場合は、ロボットの管理台帳の作成を行うこともありますが、
ロボットのリリースのタイミングで、ロボットの管理台帳を更新します。
（6）でロボットがリリースされると、ロボットの起動ができるようになります。
手動で起動されるロボットはユーザ部門によって手動で、自動で起動されるものは設定したスケジュールでロボットが実行されます。
RPAの本格運用が始まると、保守チームの役割が大きくなります。
保守チームは、ユーザからのRPAに関する問い合わせの対応やロボットの障害対応、新規ロボットの作成、
さらにロボットリリース前のチェック等を主に行います。以下で詳細を紹介します。
ロボットの稼働が始まると、何らかの理由でロボットの改修が必要になったり、
新たにロボットの作成が必要になる場合等があります。
ヘルプデスクでは、このような問い合わせに対しての受付窓口の機能を果たします。
また、ヘルプデスクでは、ユーザ部門からの問い合わせ内容を社内ナレッジとして蓄積することで、
社内RPAスキルの向上に貢献します。
ヘルプデスクの具体的な業務内容としては以下のようなことがあります。
稼働していたロボットが何らかの影響によって不具合となった場合に、保守チームが原因を調査します。
よくある事例としては、例えば外部Webサイトからあるデータをインプットするロボットがあげられます。
RPAでは、外部Webサイトからあるデータを取得する際、
あらかじめ外部Webサイト内のどの位置からそのデータを取得するか、位置情報（座標）を設定するのですが、
設定後に外部Webサイトの構成が変更になる（取得するデータの座標が以前と異なる）と、
うまくデータが取得できなくなる、といった事象が発生します。
こうした事象が発生した場合は、保守チームがロボットのどの作業に対して障害が発生しているかを特定した上で、
該当部分を修正することになります。
RPAが社内に浸透すると、ユーザ部門からユーザが行っている業務に対するロボット化の要望が出てきます。
保守チームはこうした要望の受付窓口としても機能します。
また、業務担当者から自動化の申請があっても、業務によっては自動化できるものとできないものがあるため、
そうした判断を行うのも、保守チームが実施します。
人事異動や組織改編に伴って業務内容が変更される際等、ロボットの内容もそれに合わせて変える必要が出てきます。
保守チームは、ユーザ部門からあがってきたこれらの要望にも対応します。
◎ロボットのリリース作業
業務の自動化にあたっては、何でも自動化をしてしまうと会社にとってリスクとなることがあります。
そのため、ロボットのリリースをする前にリリースチェックの工程を設け、ロボットの内容を最終チェックし、
会社にとって適正なロボットか（不正なロボットではないか）の見極めをします。
ロボット作成/リリース可否の判断には以下の観点が必要となります。
ロボットの実行作業が高負荷である場合、社内システム等の運行に影響が出る可能性があります。
この場合、結果として顧客対応に遅延が生じてしまうこと等の事象が発生することが懸念されるため、
こうした業務のロボット化はリスクが高いと言えます。
特に金額や顧客情報等を扱う業務に関しては、
たとえロボットでの業務自動化を行ったとしても最終的に人間の目によるチェックは継続して行うべきでしょう。
ロボットは、設定した命令に対して正確に処理を行いますが、もちろんミスも起こりえます。
対象顧客へ誤った情報を発信してしまうと会社の信用問題にもつながりますので、自動化のリスクが高いと言えます。
いかがでしたでしょうか。
今回のコラムでは、RPA導入後の運用保守の仕組みを検討する際の確認ポイントを紹介しました。
今後もRPAプロジェクトの経験を通じて得た知見を紹介していきますので、RPA導入時の参考にしていただければ幸いです。
2018.08.24
今回はシトリックスによる自動化について、実際にUiPathを用いて試していきたいと思います。
まず初めに、簡単にシトリックス環境とは何なのかについて紹介します。
この場合、シトリックス環境におけるデスクトップの仮想化の話がメインになってきます。
デスクトップの仮想化とは、オペレーティングシステム（OS）やアプリケーションの業務を
サーバー側に集約することによって操作側の単純化をはかるものです。
このような環境ではOSやアプリケーションは完全に利用環境から分離させられて
サーバー上にあるため、利用者側は画面を表示させるためのディスプレイと
それを操作するマウス・キーボードなどさえあれば仮想的に遠隔地のデスクトップを操作できます。
この際に、重要なのは利用者はサーバーから受け取った画像を受け取って操作するということです。
今回はこの辺りまで知っといていただければ、これからの話を理解できると思います。
まだよくわからない方やもっと詳しく知りたい方は
シトリックス環境に関する詳しい説明とシトリックス環境を導入することによるメリットデメリット
について以下の記事で紹介していますので、よろしければご覧ください。
UiPathでシトリックスの自動化をおこなうにあたって、注意しないといけないことは非常に多いです。
そもそも、シトリックス環境ではサーバー上で動いているインターフェイスを画像化し
それをユーザーが認識し、仮想的に遠隔地のインターフェイスを操作します。
ここで、ユーザー側に存在するのは画像一点だけで個々の要素とその状態について
ユーザー側が知ることはできません。
よって、ユーザー側ではUiPathのセレクタやベーシックレコーディングといったツールを用いて
OSを通じたインターフェイスに直接アクセスして操作することはできません。
なので、”レコーディング機能でアクションを自動的に記録してそれを再生する”という
UiPathにおける一般的な自動化の方法を使用することはできないのです。
セレクタに関しても同様のことです。
インターフェイスに直接アクセスできないのでセレクタを用いた自動化もできません。
（2018年8月現在。今後のアップデートにより可能となる可能性あり。）
このような状況では、自動化を行う際に
我々がロボットに対して、我々人間が行うような操作を手取り足取り教える必要があります。
では具体的にUiPathのアクティビティを使用して、シトリックスの自動化をおこなっていきましょう。
今回ご紹介するのは、ログイン画面などの動的な画面での対処方法と
デスクトップ上のアプリの起動についてです。
この二つの例を見ていきながら、UiPathでの自動化の注意点を確認していきましょう。
この例を用いて紹介したい注意点は、アクションのタイミングをどのように識別するかです。
これは、特定の状態になるのを待つとも言えます。
何度もお話ししていますが、シトリックス環境下では画像のみがサーバーから送信されるので
個々の要素の状態について把握することはできません。
では、どのように特定の状態になることを識別するのでしょうか。
これは実は簡単で、人間が識別するのと同様のことをロボットにもやらせればいいのです。
つまり、人間がその状態のアプリケーションを視覚的にどのように評価するのかを
ロボットに教えてあげればいいのです。
例えば、ウェブページの読み込みが終わったことを我々はどのように視覚的に評価しているでしょうか。
それは簡単で、読み込み中のマークが消えてファビコン（注1）が表示されることです。
注1）
ファビコンは、ウェブサイトのシンボルマークとして、ウェブ上にのっているアイコン（下図）のこと。
今回の場合は、ロボットにファビコンのイメージを指定し、記憶しておいて、
現在の状況を逐一、画像認識により検査してもらい、
ファビコンが表示された時に読み込みが終わったと判断させればいいのです。
では、実際にUiPathを用いて認識させてみましょう。
今回のように、ある特定のイメージを指定して認識させる場合は
「Find Imageアクティビティ」を使用します。
使い方はとてもシンプルで、指定するイメージを選択マーキーで指定するだけです。
これにより、「指定されたイメージが検出される」または「タイムアウトする」
のどちらかが起これば、フローが停止し次に移ります。
このときにデバッグもかねて、「Highlightアクティビティ」を使用するといいでしょう。
「Highlightアクティビティ」のエレメント欄に
先ほどの「Find Imageアクティビティ」で検出した要素の変数を渡しておきましょう。
そうすると、このようにどこを検出したか分かりやすくなります。
このように、特定の状態を判断させるには
我々が実際にどのようにして状態を識別しているかをロボットに教えることが重要になってきます。
ログインページに移行できたところで、次に入力について見ていきましょう。
ここでもいくつか注意点があります。
先ほどと同様に我々が普段識別しているような方法で入力します。
ログインページからIDとPASSを入力する際にどこに入力するかは、
文字列を見てここにIDを入力、ここにPASSに入力、といった具合にしていくでしょう。
これをロボットに教えます。
クリックするときには「Click Imageアクティビティ」か「Click Textアクティビティ」
のどちらかを使用します。
この二つのアクティビティにはそれぞれ欠点があります。
特徴と欠点を以下にまとめておきます。
・「Click Imageアクティビティ」・・・”信頼性は高いが画像の変化に敏感”
動作が早いが、テーマが変化したり、
テキストの大きさが変わったりなどのように状態が変化すると停止することがある。
・「Click Textアクティビティ」・・・”OCRを使用し、画像に変化があっても対応できる”
画像認識にOCRを使用するが、一文字でも誤認識があるとすべて正常に動作しなくなる可能性がある。
このようにそれぞれにはそれぞれの欠点が存在します。
よって、多くの場合はクリックするのを最小限にしてキーボードを使った操作を推奨します。
例えば、このようなログイン画面があったと仮定します。
ここには、まずEMAIL ADDRESSを認識してその欄にメールアドレスを入力します。
このあとにPASSWORDを探すのではなく、[tabキー]を押すことで次の入力欄に移ることが可能です。
これがキーボードによる操作です。
初めのEMAIL ADDRESS入力欄に
“temp@temp.co.jp[tab]my_password[tab][tab][enter]“
とする（[tab]はtabキーを押すコマンドを選択してください）ことで簡単にログインすることができます。
このようにキーボード入力にすることで簡単にエラーが起こりにくいワークフローをつくることができます。
ここではデスクトップ上のアプリの起動を例にして、キーボードの有用性を考えたいと思います。
普通のレコーディングでは、デスクトップアプリをダブルクリックすることでアプリを起動しますが、
ここでもキーボードによる自動化を推奨します。
先ほどの「Click Imageアクティビティ」を使ってダブルクリックするとします。
この場合ではバックグラウンドの実行状態や背景の変更など
少しでも状態が変わっていると機能しなくなります。
エラーを少なくするのは、Windowsのショートカットキーを使用します。
まずは、アプリのプロパティからショートカットを設定します。
ここでは他のショートカットと干渉しないために複雑なものにするのがいいでしょう。
そして、「Send Hotkeyアクティビティ」を使用します。
このアクティビティはUI 要素にキーボードショートカットを送信するものです。
キーボードを使用することで、簡単にデスクトップ内アプリを起動することができました。
1．サーバーから送られてくる画像のみで識別するためセレクタやレコーディングは使用できない
2．ある特定の状態になることをどのように確認するのかが非常に重要
3．クリックではちょっとした変化で対応しなくなるので普遍的なキーボード操作を使用する
このようにいつもなら簡単に自動化出来ていてたものでも、
シトリックス環境においてはすこし難しくなっていきます。
しかし、UiPathにはそれをアシストするようなアクティビティがいくつも用意されているので
そちらの使用方法などをしっかりと理解しておいてシトリックス環境の自動化に役立てましょう。
2018.08.23
地方自治体BPOを受託する企業はおおよそ300社ぐらいです。
しかし、私の情報は古く、年々増えているとも言われています。
それはなぜかというと自治体BPOは参入障壁の低く新規参入がしやすく、
中小のBPO業者がこぞって自治体BPOに参入するからです。
そして、参入障壁が低いため、運営能力を著しく欠く業者の存在を許し、
そのような業者によって優良業者が自治体BPOから撤退するなどにより、
民間BPOと比べて、生産性の低い民間委託となってしまっています。
生産性が低いのであれば、増員でカバーできるのですが、生産性以外の問題もかなり生じます。
今回は、受託側について記述していきたいと思います。
【前回記事】
自治体BPOで運営能力が大きく欠ける業者がなぜ存在するかというと、
その理由の多くは入札制度にあります。
入札制度とは、自治体が民間委託する際に、一般から公募する制度です。
道路工事や建築工事などの入札で業者が談合したなどと話題になったことがありますが、その制度です。
なお、自治体BPOでは入札の談合という問題が起きたということは聞いたことはありません。
入札制度は、一般競争入札、企画競争入札、指名競争入札、公募と４つほどに分けられます。
さらに細かく分類すると一般競争入札の中で、自動落札方式と総合評価方式があります。
自治体BPOは一般競争入札で執り行われることが多いのですが、それが問題の要因となっています。
自動落札方式とは、単純に安い金額で入札した業者が落札できる制度のことです。
総合評価方式とは、金額以外の要素である運営能力を企画書などで加味し、
最終的に金額と企画書の点数で決める制度です。
企画競争入札は企画だけの勝負になります。
建築物、例えば新国立競技場のデザインのコンペにあたり、企画さえ良ければ予算はかなり付けられます。
一般競争入札の場合、単純に安い金額で入札すればいいだけでなく、
最低落札価格にも注意しなければいけません。
分かりやすく言うと、「〇〇業務を上限1,000万円で募集します」とあれば、
公表されない最低落札価格が設定されており、
BPO業者は落札最低価格がいくらぐらいか読もうとします。
仮に落札最低価格が800万円に設定されていれば、800万円を下回らない限り、
800万円に近い金額を提示したBPO業者が選ばれます。
以前なら上限に近い金額でも落札出来ていたのですが、
ここ数年はBPO業者のダンピング化が始まっており、最低落札価格を下回るBPO業者が増えてきました。
どんなに素晴らしい会社でも1円でも800万円を下回っても失格になりますし、
1円でも1位の会社に負けていれば、落札できません。
能力がなくても、やる気がなくても落札できてしまう、それが自治体BPOの恐ろしいところです。
総合評価方式であれば、企画書を作成させ、運営能力も含めて、
BPO業者を選定することが可能ではあります。
しかし、多くの自治体BPOは一般競争入札であり、
業務運営能力の皆無な業者が落札することも多くあります。
BPO業者の成り立ちとして、派遣会社を母体としている業者、
コールセンター（マーケティング）を母体にしている業者、
事業会社を母体としている業者、以上の3つに分類することができます。
派遣系の業者はあまり自治体BPOには参入しません。
業務的に同じことをやっていても、
利益が民間BPOと比べると大きく落ちるからだと言われています。
受付などの業務で派遣は見掛けることは多いのですが、業務委託という形は少ないと聞いています。
派遣会社を母体としている業者でも、大規模な自治体で、
かつ総合評価や指名競争入札などある程度利益が見込めるような案件であれば、
参入してくることが多いようです。
また稀に行われる指名競争入札などで参入してくるケースもあります。
また、業務委託契約ではなく、労働者派遣契約で自治体BPOを契約しようとします。
労働者派遣契約だと契約金額そのものが大きく変わり、
また業務委託だと自治体BPOのノウハウがある程度必要になりますが、
労働者派遣契約だと派遣社員の教育は自治体でやってくれるので、
労務管理をするだけでよいため、手間もかからず、利益も大きく見込めるものとなります。
コールセンター系でもアウトバウンドを主戦場とするテレマ系の業者は、
かなり自治体BPOに参入する傾向は強いです。
バブル崩壊後、財政的に厳しく税金などの徴収率をあげるために、
徴収業務に特化したコールセンターを10数年前にある自治体が民間委託として構築し、
税金などの徴収率の回復に成功しました。
その成功により、この10数年で徴収業務の民間委託が全国の自治体では標準化されていきました。
併せて、貸金業法の改正により、サラ金が取り立てを厳しくできなくなったため、
サービサー関連のコールセンターで従事していた人達が自治体BPOに流れてきたというのもあるかと思います。
ただし、コールセンター系は自治体BPOでも事務系などには参入しないことの方が多いです。
事業会社を母体としている業者の参入は目を見張るものがあります。
大手企業が自分たちの業務の委託先として、
BPO専門の子会社などのグループ会社を設立していきました。
企業買収もかなり多かったとは聞いています。
その大手企業のグループ内専門のBPOを行っている業者が業務の拡大を考え始めると、
大手企業の取引先にまず進出し、その後、自治体BPOに参入してきます。
私も何社か相談されたことがありますが、大手企業の人事的な問題もあるそうです。
自治体向けアンケートでは、自治体BPOを導入する目的は、
「民間ノウハウを利用する」などと書かれていることがあります。
残念なことにBPO業者で自治体向けのノウハウを蓄積できているところは少ないようです。
BPO業者の社員が個人でノウハウを蓄積していることを稀に見かける程度です。
コールセンター系はコール業務についてはノウハウはありますが、自治体業務を知らないため、
自治体BPO業務としてのノウハウはごく僅かしか蓄積されていません。
なぜそのように蓄積されないことになるかというと、
自治体BPOは民間BPOと比べても利益が少なく、
利益が少ない所には社内で優秀と言われる人材を置かない。
更には、社員の稼働率を上げるために、複数案件を担当させるなどが日常茶飯事で行われており、
社員がノウハウを蓄積し辛い環境になっているためです。
民間BPOをやっている業者は、エース級の人材は当然、
更にミドルクラスの人材も自治体BPOの担当としてアサインしません。
社員でも能力的に懐疑的な社員に担当させることが多く、
BPO業者の何社かはそのような組織構造にしていると言っています。
詳細はお伝え出来ませんが、そのような社内で問題ある社員を管理しきれず、
民間だと契約破棄になるような事件が多々発生しているような状態です。
ノウハウがない事業者に決まり、ノウハウも能力もない社員が担当する。
そのような現場をいくつも見てきましたが、かなり悲惨な状態でした。
業務内容にもよりますが、KPI（重要業績評価指標）を民間と比べると、
生産性は20～50％ぐらいです。
そもそもKPIの設定すらされていないことが多く、
成果が出ようが出まいが、許されてしまうのが自治体BPOです。
BPO業者は自治体を軽視してしまうのです。
自治体BPOは基本的に人的BPOです。
入札し、落札が決まれば、その業務で働くスタッフを採用します。
7/31に発表された有効求人倍率は1.62倍です。
http://www.jil.go.jp/kokunai/statistics/timeseries/html/g0301.html
既にバブル期を超えており、人事や採用の担当をされていらっしゃる方は、
採用活動が厳しくなってきていることをご存知かと思います。
数年前なら媒体広告を打てば、かなりの応募が来ましたが、現在では半分以下です。
ダイバーシティということで人材の掘り起こしをしてきましたが、
もはや枯渇している状態です。
更に地方自治体では大都市圏に人が流れてしまっており、地方ほど採用活動に苦労をします。
特に自治体BPOでは配置予定人数を揃えるだけでも苦労します。
数年前までなら能力の高い求職者がいたので、そういう人を採用し、
自治体BPOの現場の中心に置くだけで成功したようなこともあります。
それが派遣会社を母体とするBPO業者であれば配置予定人数を難なく揃えることが出来るかと思います。
自治体BPOでは1年や3年などの年単位の委託になるので、
スタッフは有期労働契約者となり、無期労働契約ではない点も採用活動に苦戦する理由です。
このあたりでも派遣会社を母体としているBPO業者は、
自治体BPOが終了後もすぐに派遣先を提供できるので、
優秀な人材には無期労働契約を提示したりしています。
そのように苦労して採用したスタッフも管理能力不足の社員が担当し、
ブラックBPO化し、離職率100％という最悪な環境を作り出してしまいます。
採用で苦労し、その苦労して採用した人材が退職してしまうような企業は、
ブラック企業だと言えます。
雇用情勢を鑑みれば、この数年でブラック企業が淘汰されていくと言われています。
BPO業者も含め、企業はこの数年でコーチングなどの育成手法、
評価なども含めた人材マネジメントの切り替えを求められているように思われます。
また、ノウハウがないBPO業者がよくするのは、
自分達が受託する前のBPO業者の管理下で働いていたスタッフの採用をしたりします。
ノウハウもなく、管理能力がないBPO業者にとって自治体BPOを成功させるには、
以前からその業務を担当しているスタッフを採用するという方法は一番簡単な方法です。
BPO業者にとって採用コストを節約し、スタッフにとっては同環境で労働が継続され、
自治体担当者にとっては前年と同じような民間委託が継続できるので、
3者にとって良い結果が生まれるというわけです。
私の経験上、前年度以上の結果を望まない限りは、この手法は成功します。
ただし民間と比べて生産性50％以下という現場を改善しようとするとその自治体BPOはほぼ失敗します。
書けない部分も多いのですが、地方自治体の職員の方は民間業者を知らず、
最終的に苦労しています。
複数の業者からヒアリングするなどして、
発注主としてどのような仕様書にした方が良いのかと事前準備をした方が良いかと思います。
【次回記事】
2018.08.22
この記事では、RPA導入に向けて2017年末から検討し、
2018年春に導入、運用を始めた一連の経緯から発生した問題点とその解決策を、
RPA導入責任者としての目線で生々しくお伝えしていきます。
ぜひ何か一つでもヒントになって頂ければ幸いです。
【前回記事】
*当社
・SynchRoidのサーバータイプを導入
なぜRPAを導入するのか、なぜRPAが必要なのか、どういった事を期待するのか、
数年先にどうなっていたいのか。
等、この根本的な部分がぶれてはその先進んだとしても、必ずどこかでトラブルが起きます。
当社では、以下の内容で各メンバーの理解を得ました。
● モチベーションを保てない、ルーティンワークを解消したい
● 負荷を軽減することで、慢性的な残業を解消したい
● 若手を下手な理由で辞めさせない
● 業務を標準化したい
ポイントは、“恰好つけない”“うそをつかない(自分に嘘をつかない)”“会社の現状・現実に沿った内容にする” 等です。
内容によっては自社の現状を切り刻むことになったり、誰かの気を害することもあるでしょうが、
痛みが伴う改善もあります。
導入責任者としては最初の踏ん張りどこです。
また、もう一つの解決策として、会社におけるRPA運用の“概念”を経営者から発信してもらうということもあります。
当社ではRPA５カ条を掲げ、経営層から発信してもらう事でRPAが進めやすくなりました。
1. RPAの活用は働き方改革とのデュアルアプローチで進める
2. RPAはインプットの置換でありコストダウンとイコールではない
3. RPAは万能ではない
4. RPAは人員削減のための道具ではない
5. RPAを使えることが新たなビジネスチャンスにつながる
等を掲げました。
この5箇条はネット記事で見かけたものを少し当社用にアレンジしたものとなります。
例えば、RPAロボット化候補業務のヒアリングを行っていた時に、
担当者「このエクセルシートにデータを入力して、保存して、このフォルダに置いたら後はマクロがやってくれます。」
私 「そのマクロは何をやっているのですか？マクロで処理された後はどうなるのですか？」
担当者「それは分かりません、、、」
といったやり取りが多々発生します。
私としては、そのマクロがやっている部分もRPA化できるのか、
業務ステップの効率化につながることができるのかを検討しなくてはならないため、
マクロがどのような事をやっているのか、マクロの仕様を含めて確認をしたかったのですが、
上記のやり取りになり、しかも“誰が作ったかわからない”マクロも残念ながら存在します。
現在、多くの企業でマクロが大活躍していると思いますが、現在マクロ関連で発生していることは、
そのまま意識しなければRPAでも同様に発生してしまいます。
そこで、当社ではそうならないように、下記項目が含まれるシートを作成し、RPAの意味、RPA化する理由、
ひいては業務の意味を継承していくことにしました。
●業務の概要・担当者
●ロボットのフロー図・RPAロボット制作者
●部位ごとの処理内容説明
●動作時の注意事項
●何をインプットするのか
●何がアウトプットされるのか
数多く作られることになるRPAロボットに対し、一つ一つこういった内容を作っていくことは非常に大変ですが、
これを怠ると世に言われる“野良ロボット”が氾濫することになってしまいます。
ここも担当者は踏ん張りどころです。
当社が採用したRPA(SynchRoid)の管理システム(Management Console)は、
残念ながらあまり直感的に扱えるツールではありませんでした。
*これはデモ採用時には気づけない部分です。
しかし、これを使わなければ(使いこなさなければ)ならないため、
システムの制約を十分に理解したうえで、これらを定義していく必要があります。
●RPAロボット
・ロボット名
・保存するフォルダ名、またその構成（業務ごと？部門ごと？）
●ユーザー
・ユーザー名
・ユーザーグループ名（構成）*部門間移動が多い会社なのかどうか
① 自分の会社は、業務内容が固定的か、流動的か、従業員の入れ替わり、部門間移動が多いかどうかを、
自部門だけでなく会社全体を考えて、正確に把握する。
② 管理システム側の制約を正確に把握する。
・検索できるか（検索は日本語・アルファベットどちらもOKか？）
・検索範囲（すべて？ロボット名？フォルダ名のみ？等）
・ロボット名の付け方に制約はないか？（”-”や”_”が使えないとか）
・フォルダ構成は何層までいけるのか
・ユーザーグループは何層まで？
③ ３０ほどRPAロボット候補業務をみて、これをきれいに並べるにはどうすればよいかを考える
*当社では、RPAロボットを管理表で管理しています。
そこで各ロボットに採番しており、それをロボット名につけています。
これらをきれいにしないと、利用者側が迷い、結果としてRPA担当者側への問い合わせが増えていきます。
なお、作りながらルールを固めていくというやり方もあると思いますが、私としては初期段階で７割方固めた方が、
作る方としても楽になっていくと思います。
当社はエンジニア会社ではないため、社内にプログラミングの素養があるものはほとんどいません。
PCに明るいものが情報システム部門に数名いるという環境ですと、RPAを導入しても、
ロボットが出来上がらず、宝の持ち腐れとなってしまいます。
そのため、当社ではRPAベンダーが提供する教育プログラムや、技術者の常駐サービスを利用しました。
(中小企業にとっては決して安い費用ではないのですが、
エンジニアがいない会社であれば、ロボット作りの加速のために必要と思います。)
当初、試験導入の１か月の間、出来上がったRPAプログラムはわずか数件でしたが、
エンジニア常駐サービスを利用することで各段に制作スピードが上がりました。
またその際、以下対応をおすすめします。
・質問を事前に(ある程度)まとめる
・技術者とのやり取りを一つ一つ、メモをしRPA作成者で共有する
なお、常駐サービスにおいて確認した方が良い項目は下記をおすすめします。
・会社独自で稼働しているツール（基幹システムやグループウェア等）を用いるもの
・業界ルールによる制約が関係するもの（固いセキュリティはRPAの障害になります）
・客先のEDIサイトでの情報取得方法等
特に、基幹システムやグループウェア、客先EDIサイトなど業務に直結するもの、
セキュリティ上の制約については、RPAそのものに影響しますので、
こういった内容は技術者の力にしっかりと頼る必要があります。
話題のRPAを導入するとなれば、経営層が知りたいことはただ一つ、“費用対効果”です。
まずはKPIの設定ですが、当社ではわかりやすい数字を適当に掲げました。
〇千時間／年の削減！とかです。
RPA導入責任者としては、難しいところですが、あえて難しく考えないことをお勧めします。
なぜなら誰もがRPA初体験のため答えを知りませんし、結果は後からついてくるものです。
また、効果は時間だけに現れるものでもありません。
ですので、えいや！で決めた数字で良いのです。
（集めたRPA作成リクエスト業務の作業時間を積算すれば意外とそれにはまっていたりしているものです）
また成果報告についてですが、ここでもRPA担当者は、
RPA開発における苦労を理解されないまま、効果の説明を求められます。
また、相手はRPAを正確に把握していなかったり、システム等に明るくない方もいたりしています。
そういった相手へRPAの成果報告は大変ですが、ポイントを押さえれば少しは楽になります。
そこで、私のおすすめ事前準備内容をお伝えします。
＊なお、RPAサーバー内で完結するRPAの場合、“動き”がなく、
RPAに詳しくない人が見たら何が何だか分かりません。
そのため、PCをリモートで操作する系のRPAロボットの動画の方がよりインパクト強く伝えられると思います。
初期段階での報告にはとても効果を発揮します。
また突然の声掛けにも、動画を撮影しておけば安心です。
（RPAって作ってしまえば簡単に動かせると思っている人も多いです。
そこで事前準備が必要でうんぬんと説明するとRPAに対してネガティブな感情を与えてしまいかねません）
＊これは説明不要ですね。
● 業務担当者の声
＊シンプルに「楽になった」だけでなく、「ミスがなくなった」「心理的負荷が軽減された」等、
メンタルにつながる効果はこういった声を媒体にして伝えていきたいです。
他にも多数ありますが、ここでは以上とさせて頂きます。
ここまで読んでいただきありがとうございました。
2018.08.21
＊この記事は「【UiPath】アクティビティパッケージまとめ 1/2」の続きです。
UiPathに標準では搭載されていないアクティビティは、後々インストールすることが可能です。
それをまとめたアクティビティパックについて詳細を見ていきます。
これからは実際に他のアプリケーションとの連携についてなどを紹介していきます。
このアクティビティパックにはその名の通り、マイクロソフト社のExcelの自動化のために用意されたものです。
マイクロソフトのExcel が ご自身のパソコン にインストールされていない場合でも、
システムの中で分類されたアクティビティを実行することができます。
もちろんアプリケーションと連携することも可能ですが、
その場合はアクティビティを実行する パソコン にアプリケーションのインストールが必要です。
＜主に含まれているアクティビティ＞
・「Write CSV」
指定した DataTable を CSV ファイルに上書きします。
・「Read CSV」
指定した CSV ファイルからすべてのエントリを読み取ります。
・「Append To CSV」
指定した DataTable を CSV ファイルに追加し、ファイルが存在しない場合は作成します。
・「Get Table Range」
指定したスプレッドシートから Excel テーブルの範囲を抽出します。
・「Sort Table」
列の値に基づいてテーブルを並べ替えます。
テーブルは昇順または降順にのみ並べ替えることができます。
数字や文字列の大小によってソートされます。(昇順の場合、1<2 , A<B)
・「Set Range Color」
Color 変数を使用して、指定したセルまたはセル範囲の色を変更します。
・「Read Cell」
Excel セルの値を読み取って変数に格納します。
・「Write Cell」
指定したスプレッドシートセルまたは範囲に値を書き込みます。
シートが存在しない場合は、SheetName の値を使用して新規のシートが作成されます。
値が存在する場合は、上書きされます。
このパッケージには、セル、列、行、または範囲からの情報の読み取りや、
他のスプレッドシートまたはブックへの書き込みなどだけではなく、
さらに数式の抽出ができるアクティビティがあります。
また、データを並び替えたり、色分けしたり、追加情報を追加したりすることもできます。
＜注＞Microsoft Excel 95 固有の古い Excel バイナリファイル形式 (.xsl) はサポートされていません
このアクティビティパックには、メールの自動化についてのアクティビティが含まれています。
メールについて自動化を行うならこのアクティビティパックをインストールするべきです。
＜主に含まれているアクティビティ＞
・「Set Mail Message」
指定したフォルダーにメールメッセージを保存します。
フォルダーが存在しない場合は作成されます。
フォルダーを指定しない場合は、プロジェクトフォルダーにダウンロードが保存されます。
指定したフォルダーにあるファイルのうち、メッセージと同じ名前を持つものは上書きされます。
・「Get POP3 Mail Message」「Get IMAP Mail Message」
指定されたサーバーからPOP3やIMAPのメールを取得します。
・「Get Outlook Mail Messages」「Get Exchange Mail Messages」
OutlookやExchangeのメールアプリケーションからメールを取得します。
・「Move Outlook Mail Message」「Move Exchange Mail Messages」
OutlookやExchangeのメールアプリケーションにおいて、フォルダを他に移します。
・「Send Outlook Mail Message」「Send Exchange Mail Messages」
OutlookやExchangeのメールアプリケーションにおいて、メールを送信します。
このように、UiPath ではOutlook と Exchange の操作に特化したアクティビティがそろっています。
メールの取得や送信だけではなく、フォルダの変更や保存なども行うことができます。
このアクティビティパックには、
PDFから文字列などを抽出することができるアクティビティなどが含まれています。
アドビ社のPDFでもマイクロソフト社のXPSでも両ファイルからデータを抽出することができます。
＜主に含まれているアクティビティ＞
・「Read PDF Text」「Read XSL Text」
指定した PDF ファイルからすべての文字を読み取り、文字列変数に格納します。
・「Read PDF With OCR」「Read XSL With OCR」
OCRの技術を利用して指定した PDF ファイルからすべての文字を読み取り、
文字列変数に格納します。
このようにPDFとXSLの両方で対応しています。
また、抽出の方法としてOCRを用いたアクティビティも存在します。
UiPathに特有のGoogle OCRやMicrosoft OCRなどを指定するためには、
単にアクティビティの本体にエンジンをドロップするだけです。
このアクティビティパックは少しだけ今までのものとは違います。
このアクティビティパックのアクティビティを使用することで、
任意のワークフローの中で直接、Pythonのスクリプトやメソッドなどを呼び出すことができます。
呼び出したコードに入力パラメーターを渡すことも、
アクティビティにより生成された出力データを取得することもできます。
＜主に含まれているアクティビティ＞
・「Python Scope」
Python アクティビティのスコープを提供し、指定した Python 環境を初期化するコンテナーです。
つまり、このアクティビティ内ではPythonのオブジェクトなどが利用可能であるということです。
Python Scope アクティビティが終了すると、
その時点までに読み込まれていた Python オブジェクトがすべて削除されます。
バージョンについてもプロパティで変更可能です。
・「Get Python Object」
Python オブジェクト内などで他のPythonアクティビティから得られた変数を、
選択したワークフロー内で使用できる .NET の型として取得します。
Python Scope内でのみ使用することができます。
・「Invoke Python Method」
ワークフロー内で指定したPythonのメソッドを、
Pythonのスクリプトから直接に実行します。
先に下で説明する「Load Python Script」を使用する必要があります。
Python Scope内でのみ使用することができます。
・「Load Python Script」
Pythonのコードをこれから使用できるようにPython.Object型に変えます。
Python Scope内でのみ使用することができます。
・「Run Python Script」
Python コードを実行できるようにします。
アクティビティの中でコードを直接入力することも、
コードのファイルパスを指定することもできます。
Python Scope内でのみ使用することができます。
このようにすべてのアクティビティはPython Scopeの中でのみ使用することができます。
Python のスクリプトやメソッドをワークフローから直接実行できることができます。
アクティビティパックにはそれぞれ用途によって
分類させられていることが分かったのではないでしょうか。
それぞれ使用する用途によってインストールするかどうかをご自身で見極めてください。
2018.08.20
UiPathは、様々なアクティビティやレコードなどを使用して作業の自動化を行うことができるように開発された
RPAツールの一つです。
このUiPathには初めからインストールされているアクティビティ以外にも、アクティビティを追加することができます。
その際に、インストールするのがアクティビティパッケージです。
今回はそのアクティビティパッケージの用途に分けた使い方をまとめていこうと思います。
アクティビティパッケージとはパッケージ化された様々なアクティビティのことを指します。
分かりやすく言うと、様々なアクティビティが一つの袋に集められているようなものです。
UiPathの場合にはその袋が用途ごとに別けてまとめられています。
ですので、必要なアクティビティのみをインストールして使用することが可能です。
様々なアクティビティがある中で自身の必要なアクティビティを確認して初期設定を行うことをおすすめします。
そのために今回はアクティビティパッケージを一つずつ中身を確認して、初期設定に役立てていただけたらと思います。
どのようなパッケージがあるかどうかを見る前に、
パッケージのインストール・アンインストール方法を確認しておきましょう。
ここでは、現在の自身の環境でどのアクティビティパッケージをインストールしているかどうか
確認できますので便利です。
1.UiPath Studioを起動する
2. 左側にあるアクティビティ一覧から「Manage Packages」と書かれるアイコンをクリック
これで新しいウィンドウにパッケージマネージャーを開くことができます。
（ショートカットキーとしてCtrl+Pも用意されています。）
3. 左のInstalledの下矢印をクリック
ここで現在ご自身の環境でどのパッケージがインストールされているのかがわかります。
（ここでInstalledに表示されているのが、現在ご自身の環境でインストールされているパッケージです。）
また、ここでは必要がなくなった・間違えてインストールしてしまったパッケージをアンインストールすることもできます。
その場合は、Uninstallをクリックすればアンインストールできます。
4. 新しくインストールしたい場合は「Available」からインストールしたいパッケージをインストールします。
（すでにインストール済みのものにはチェックマークがついています）
このように自身の環境確認とインストールとアンインストールの手順を確認したところで、
実際にアクティビティパッケージについて見ていきましょう。
この、コアアクティビティパックには、ユーザーインターフェイス(UI)の自動化の作成に必要な
基本的なアクティビティがすべて含まれています。
基本的にこのパッケージはインストールしておくことをおすすめします。
＜主に含まれているアクティビティ＞
・「Get Text」
指定したUI要素（＊注1）からテキストを読み込みます。
＊注1
UI要素：ウィンドウ、チェックボックス、テキストフィールドのようなGUIを総称してUI要素と呼びます。
・「Type Into」
指定したUI要素にテキストなどを送信します
・「Hover」
指定した UI 要素の上にカーソルを置きます (UI 要素の上でホバーします)。
・「Click」「Double Click」
指定したをUI要素をクリック、ダブルクリックします。
・「Get OCR Text」
OCR の技術であるスクリーンスクレイピングを使用する際に、
指定した UI 要素から文字列とその情報を抽出します。
このアクティビティは、スクリーンスクレイピングの実行時にコンテナーと一緒に自動的に生成することもできます。
既定では、Google OCR エンジンが使用されます。
・「Hover OCR Text」
OCR の技術であるスクリーンスクレイピングを使用する際に、指定した UI 要素の中で指定の文字列を検索し、
文字列の上にカーソルを置きます (文字列の上でホバーします)。
既定では、Google OCR エンジンが使用されます。
ここまで具体的なアクティビティを見て気づかれた方もいるかもしれませんが、
このアクティブパックによって、簡単なキーボードやマウスの自動化だけではなくて、
OCRや画像認識の技術を使っての、画像およびテキストの自動化を実行することが可能となります。
また、情報を抽出してデータテーブルを作ったり、
PC上のディレクトリやファイルを直接操作して必要な操作を自動化することもできます。
このアクティビティにはGoogleやMicrosoft、さらにIBMといったAPIを使用して
情報を取り出すときに役に立ちます。
このアクティビティパックには様々なAPI操作における自動化を助けるアクティビティが入っています。
＜主に含まれているアクティビティ＞
・「Google Text Analysis」
Googleのテキストついて機能することができるアクティビティです。
指定したてテキストについて、言語、長さなどを取り出すことができます。
さらに、テキストが肯定的か否定的かどうかも分かることができます。
注）このアクティビティが機能する言語は、英語とスペイン語さらに日本語の3か国語だけです。
・「IBM Watson Text Analysis」「Microsoft Text Analysis」
これらも指定したテキストを解析するのに使うアクティビティです。
上の「Google Text Translate」と違うところは、解析するテキストの種類が異なるだけです。
・「Google Text Translate」
Googleのテキストを他の言語に翻訳することができるアクティビティです。
このようにこのアクティビティパックにはテキストを別の言語に翻訳するだけではなくて、
感情やキーフレーズを抜き出すこと可能です。
他にも発生している可能性のあるエラーや使用されている言語の解析なども可能です。
このアクティビティパックには、
データベースに接続してトランザクションやクエリなどを自動かすることができます
＜主に含まれているアクティビティ＞
・「Connect」「Disconnect」
これらのアクティビティは、データベースに接続することや、
接続を切断することを実行するアクティビティです。
「Connect」で接続し、「Disconnect」で切断することができます。
・「Start Transaction」
このアクティビティはデータベースに接続し、複数のアクションを実行してから切断できるようにすることが可能です。
データベースに接続し、データベースで複数のトランザクションを実行できるシーケンスを持っています。
UseTransaction という変数 が True に設定されている場合、
含まれている操作は単一のトランザクションで実行され、それらのどれもが失敗しなかった場合は最後に適用されます。
同様のUseTransaction 変数が False に設定されている場合、
すべての操作は個別に実行されます。
このアクティビティが終了すると、データベースへの接続が終了します。
このアクティビティパックにはデータベースと接続とその切断やトランザクションの分割などを行うことができます。
2018.08.17
RPAツールは基本的に高額なものが多く、
エンタープライズ向けだと年間数百万円以上かかり小規模でも年間数十万円といった価格帯です。
なので中小企業やベンチャーでは価格がネックとなり導入に踏み切れないケースも多くあります。
そのため無料のRPAツールは多くの企業で求められており、
Google検索でも「RPA」と一緒に「無料」「フリー」などのワードが非常に多く検索されています。
みなさんはWorkFusionというRPAツールご存知でしょうか。
このツールはなんと無料で提供されています。
UiPathのCommunity Editionのように小規模事業者のみなどの制約はなく商用で堂々とRPAを無料で使うことが可能です。
今回はそのWorkFusionの特徴・メリット・デメリットなどを解説していきます。
「無料より怖いものはない」という言葉がある通り、
日本ではまだあまり浸透していないWorkFusionを無料という理由だけで使用するにはかなり不安がありますし、
すこし高くても有名なWinActorやUiPathを選ばざるを得ないのが現状かと思います。
まずはその不安を取り払う為に、なぜ無料で提供しているのかを解説します。
WorkFusionは2012年マサチューセッツ工科大学発祥の比較的歴史の浅い企業です。
さらにWorkFusionの提供するRPAツール「RPA Express」は2017年にリリースされたばかりで、
まだリリースから1年ほどしか経っていません。
しかし、本拠地のアメリカではすでにRPAのBIG3といわれる、
Automation Anywhere, Blue Prism, UiPathのポジションに最も近い存在とも言われるほどユーザ数を急激に伸ばしています。
全世界でのユーザ数は現在3万以上と発表されおり、単に無料というだけではこれほどの利用はされないはずです。
WorkFusionはRPA×AIを前提として捉えており、
現在普及しているRPAは既存の技術のみしか使用していないので廉価版として無料で提供しています。
廉価版といえど他のUiPathなどと管理機能など含め引けをとらない機能を有しています。
これに加えて上位版が用意されており、こちらが年間１５０ドルで提供されています。
上位版を購入するとOCRや機械学習を活用した機能が使用できるようになります。
つまりWorkFusionはフリーミアムのビジネスモデルで収益を得ているので、
無料の機能を安心して使用することができます。
機能面の特徴
RPA Expressの開発画面
自動化の対象となるシステムのインターフェースをどのように認識するかはRPAツールの個性がでるところです。
WorkFusionはAIを活用したイメージ認識技術に強みを持っている企業なので、
今まで画像のマッチングで場所を特定するイメージ認識が中心でした。
しかしどれほど優れたイメージ認識でもユーザインタフェースは変化が多いので稼働が不安定になることが多いのも事実です。
WorkFusionは2018年5月のメジャーアップデートにイメージ認識に加えて、
システムの構造解析をして場所を特定するいわゆるオブジェクト認識が可能になりました。
オブジェクト認識にも種類がいくつかありますがウェブの場合Xpathによる指定方式を採用しています。
すこし、技術的な知識が必要ではありますが本格的につくりこめばUiPathやBizRobo!と同レベルの安定性をもったロボット開発も可能です。
RPAツールはInternet Explorerにしか対応していなかったり、独自ブラウザしか使用できないといったものが多いです。
拡張機能としてChromeなどが使えるといったツールもあります。
しかしWorkFusionはデフォルトでChrome, Fire Fox, Internet Explorerをサポートしている為、
特定のブラウザでの操作が必要な場合WorkFusionは非常に相性が良いです。
通常RPAの管理機能を導入しようすると安くても２００万円以上はしますが、
WorkFusionではControll Towerという管理機能までもが無料で使用できます。
しかし、無料版だと他のデバイスとの連携がとれないため実質社内のRPA全体管理に活用するのは難しいですが、
スケジュール稼働などの機能は無料版で使用することができます。
有償版を購入する他のデバイスと連携がとれるようになります。
有償版は日本円で約１８０万円程度なのでこれでも十分に安いです。
本格的のアメリカでのシェア拡大に注力している為か、日本での販売代理店は現状ありません。
導入や活用をサポートできる企業も限られています。
すべて英語のコンテンツですが、Automation Academyという無料のe-ラーニングサイトと、
WorkFusion ForumというFAQサイトがあります。
言うまでもありませんが、無料で使えるというのは非常に大きなメリットです。
RPA活用において、ツールに費用をかけるよりも、
ツールを活用して自動化していくことにお金や人材を投資することが成功のカギです。
したがってツールの費用を最小限に抑えることは決して消極的ではなく合理的な選択といえるでしょう。
WorkFusionはまだまだ発展途上のRPAツールでありながらユーザ数を急激に伸ばし、機能の拡充も早いスピードで進んでいます。
もともと高い技術力を持った企業でありRPA×AIを前提として開発を進めているので、
近い将来RPAのBIG3を上回るハイスペックなRPAツールに成長する可能性を秘めています。
やはり細かい使い勝手ではUiPathなどに劣ります。具体的な例をあげれば、
などなど多いですが、無料ということを考えれば致し方無いのかもしれません。
まず、WorkFusionは日本でほとんど展開していない為ソフトウェアはじめマニュアルやe-ラーニングなどすべてが英語です。
さらに今後日本展開といった噂もないので日本語化される見込みも低いです。
また、レコーディングやコマンドのドラッグアンドドロップなど業務部門でも基本的な自動化だけなら使いやすいです。
しかし、作りこもうとすると手打ちでのXpath指定などが必要になるので業務部門だけでRPA活用するといったイメージだと導入は厳しく、
エンジニア中心での活用または、その中間で業務部門とエンジニアが連携して進めていく形になります。
一方で、コードベースで開発できる機能もあるのでエンジニアにとっては相性がよいかもしれません。
WorkFusionの導入に向いている企業は
といったものにあてはまる企業だといえます。
2018.08.16
今回のコラムでは、前回に引き続き、大規模なRPA導入プロジェクトにおける成功の鍵について述べていきたいと思います。
「組織体制」と「運営」の２つに分けて説明させていただきましたが、本コラムでは後者に焦点を当てています。
前回コラムを参照したい方は下記のリンクを参照してください。
（参考）前回コラム：大規模RPAプロジェクトの進め方 （3/4）
まず、おさらいになりますが、RPA導入プロジェクトをする上での成功の鍵として、
前回コラムからの再掲になりますが、以下のような要点が挙げられます。
本コラムでは、２の「運営」について詳述していきます。
RPAの技術自体が目新しいものなので、
多くの導入企業にとってRPAプロジェクトに対する経験値が未だ十分に足りていない事が多いと思います。
金融業界でまずRPA化の先鞭をつけた形となりましたが、その他の多くの業界では、未だPOCの段階であったり、
ようやく2018年になって開発体制の準備、実行フェーズに入ったところが大多数ではないでしょうか。
そのように不慣れなプロジェクトにおいて、人員リソースの最適配分は喫緊の命題となります。
もともとRPAに詳しい人材が未だ市場に十分にいない状況ですので、
開発工程のうちのどこかのプロセスがボトルネックとなり、
目標とする開発ロボット数や業務負荷低減時間に到達できずに苦労している企業も多いように見受けられます。
従って、特にRPA導入プロジェクトにおいては、
ボトルネックを探し出すためのプロジェクトマネジメント技術が求められることになります。
そのようなスキルは、正にPM/PMOにとって腕の見せ所の領域です。
特に大規模なRPA導入プロジェクトとなった場合、
それこそ数多のロボット案件・アイデアが浮上していくことになるので、それらを捌き、整理し、
管理するための高度な技術およびシェアリングの環境が待望されています。
その中の一つとなる有効な手法が「パイプラインの見える化」です。
（参考：パイプラインの管理）
パイプライン管理は、システム開発の用語というよりかは、
歴史的に営業であったりＲ＆Ｄの領域で発展してきたマネジメント手法です。
簡単に説明すると、営業にしろＲ＆Ｄにしろ、システム開発でも構いませんが、
特定の業務を個別プロセスに分解し、各プロセス上に現在どのくらいの案件があるのか可視化する手法です。
工場生産の現場で言うと、歩留まりを把握するのに近しい手法です。
何故、RPA導入プロジェクトの現場で「パイプライン管理」が重要になるのかというと、
それはRPAプロジェクトならではの特性に起因します。
RPAというものは、そもそも大型のシステム開発案件とは違い、
「システム開発するにはペイしない」細々とした業務の自動化が前提となります。
そもそも大きな業務負荷低減が見込める領域であれば、
RPAでなくて抜本的なスクラッチでのシステム開発を選ぶケースが圧倒的であり、多くの企業はそうしています。
つまり、企業にとってそれなりの業務負荷低減効果を狙うのであれば、
それこそ数多のロボットを生成する可能性が出てくるということです。
即ち、通常のシステム開発と比べ、RPAというものは、一つ一つは小粒な、
でも数だけは膨大なロボット開発案件の集合体となるわけです。
そこに、パイプライン管理の重要性が屹立してくることになります。
上記にあるチャートで、RPA導入プロジェクトにおけるパイプライン管理の事例を紹介していますが、
それでは例えば其処から何が読み取れるでしょうか。
この例で、まず目につくのは「業務フロー設計（To-Be）」が完了しているのに次の段階に移れていない案件が多く、
その割に次フェーズの「プログラム設計書作成」で仕掛中の案件が少ないことです。
これは、プログラム設計書作成の人的リソースが足りないが故に全体として動脈硬化が起きている現象を示しています。
つまり、この時点で「プログラム設計書作成」が明らかなボトルネックになっているということです。
このような極端な例は無いだろう、、、と思われる方も多いと思いますが、
不慣れなRPA導入のプロジェクトの場合、現実的に起こりうる事象です。
おそらくPMとしては、もちろん薄々は問題を理解していることなのですが、
いかんせんそのボトルネック工程を補填する人的リソースが見当たらず、打開策が取れない状態に陥っている、
そのようなことが現実的にRPAの開発現場では起きています。
このあたりの具体的な解決策については、
次のポイントである「教育」に大きく関与してくるところではあるので次節以降に譲りますが、
いずれにせよ重要なのは、このようなパイプライン管理をすることで「迅速に」ボトルネックを洗い出し、
打ち手を講じることができることです。
それにより、納期と目標が決められたプロジェクトを完遂し達成する確度を上げることができるのです。
次に、RPAプロジェクトにおける「教育」の重要性について語りたいと思います。
なぜRPAプロジェクトにおいて教育、つまりトレーニングが重要となるのか。
それは、RPAの持つ２つの特徴に起因します。
１つ目は「RPA人材の不足」、2つ目は、その割には「RPAの技術自体は差ほど難しくない」ということが挙げられます。
前述しました通り、RPAは比較的新しい技術領域であり、
そのプロジェクトに精通している人材の確保が難しい状況にあります。
従って、プロジェクトスタート時では十分なビジネスアナリスト／業務コンサルタントおよびエンジニア双方において十分な知見を有する人材を欠いたままスタートせざるを得ないケースもまま存在します。
このような状況でプロジェクトを運営せざるを得ない場合、大事なのは開発と同時に「教育」も進めていく事です。
RPAプロジェクトの場合、小型のロボット開発を積み重ねていく進め方になるので、
最初のリソース不足の段階では、少数の案件に着手し、後のフェーズで教育を経て人材を揃えていくやり方でも進めていく事ができます。
教育に焦点を当てる領域を特定する上で、前述したパイプライン管理が役立ちます。
定期的に、各工程の歩留まりをチェックすることで、
リソースが枯渇しそうなプロセスの人員を特に重点的に教育して増やしていく柔軟性が求められます。
一般的に、RPAのプロジェクトでは、プログラム設計書作成やRPA開発といった下流工程がボトルネックになりがちであり、
トレーニングをして人員体制を整えることが求められます。
上述した教育を促進させるために、KMの観点は非常に重要になります。
特にRPAのプロジェクトでは、ユーザー側の担当部署・担当者が多種多様に広がる可能性が高く、
またプロジェクトフェーズごとに人員体制を柔軟に変動させる必要があるため、
コアとなる知識・ノウハウを共有する工夫が開発の非効率を防ぐために必要です。
先進的な企業ではRPA専用の社内ポータルサイトを作り、ナレッジ共有に努めています。
ポータルサイトでなくとも、Slack等の社内SNSを活用していくのも有効です。
SNSを使えば、コミュニケーションの迅速化が図れ、ユーザーと、ビジネスアナリストおよびエンジニア間で、
仕様の確認や、RPAに合わせた業務フロー・ロジックの提案および承認といった、細々な点で開発スピードの向上が狙えます。
ただ、そのような大層な仕掛けがなくとも、
普通に共有フォルダを関係メンバーに公開するようなやり方でも、もちろん一向に構いません。
それでは、具体的にどのような情報コンテンツをナレッジシェアリングの対象とすべきでしょうか。
具体的な例として以下をご覧ください。
複数のステークホルダーが関与することになりますので、
それ毎に分けてコンテンツを用意することが見る側にとってもストレスなく使ってくれることに繋がります。
また、ユーザーサイドであったり、ビジネスアナリスト／業務コンサルタントに対しても、
RPAロボットの動き方を理解してもらうことは重要になりますので、
エンジニア以外にもRPAツールの紹介をする工夫がポイントとなります。
＜全体＞
＜対ユーザー部署＞
＜対ビジネスアナリスト／業務コンサルタント＞
＜対エンジニア＞
RPAプロジェクトの運営面でのポイントをお伝えしましたが、
最後にテスト環境の配慮を早い段階でしておくことの重要性をお伝えしたいと思います。
RPAでは、日々の定型業務の自動化がターゲットとなりますので、メール受信や、既存社内システム、
外部アプリケーションの操作をRPAでプログラミングしていくことになります。
また、ロボットと人間の間のやり取りの仕方として、特定共有フォルダに人間が必要ファイルをアップロードして、
ロボットが定期的にその共有フォルダを巡回、ファイルが合ったら処理を開始する、といった方法が取られることが多いです。
そのような、メール、社内システム、外部アプリケーション、共有フォルダといったものに対して、
テスト用と本番用を予め設計しておくことがスループットの向上につながります。
必ずしもテスト用と本番用の環境を別々にする必要はありませんが、
例えば、今でも社員が使っている共有フォルダやメーリングリスト、
およびシステム・アプリケーションのアカウントをテスト用で使うのは問題になりますので、
状況に応じて環境を分ける判断が必要です。
その場合、例えば、システムやアプリケーションのアカウントで起こりがちですが、
権限の設定がテスト用と本番用で齟齬があると障害の元となりますので、予め設計書で指示しておく必要があります。
また、このようなテスト用・本番用の環境設定は、RPA開発エンジニアの仕事という訳ではありません。
環境設定と言っても、大げさなものではなく通常業務で使うアプリ等の設定の話ですので、
このあたりの役回りは開発エンジニア以外の担当でも構いません。
RPAでは、一つ一つのロボット案件は小さいので、大規模システム開発と違い、
このあたりのテスト環境の整備がなおざりになりがちで、
いざ開発する段階になって「どうするんだっけ？」となることが散見されます。
予めプログラム設計書のフォーマットにテスト環境と本番環境を分けて記述できるように欄を設けるなど、
工夫をすべきだと考えます。
以上、今回の一連のコラムでは、
比較的大規模なRPAプロジェクトにおいて気を付けるべきポイントを組織体制と運営の側面から俯瞰してご紹介しました。
プロジェクトの要所は、会社およびRPA対象部署などによって変わってくるものではありますが、
今回でご紹介した点を咀嚼し、応用していただければと思います。
2018.08.15
今回のコラムでは、比較的大規模なＲＰＡ導入プロジェクトにおいて特に注意すべき点を述べていきたいと思います。
前回のコラムまでは、一般的な各開発工程における留意点を挙げさせていただきました。
（参考）前回コラム：大規模RPAプロジェクトの進め方 （2/4）
複数の部署に跨る大規模なＲＰＡ導入プロジェクトの場合、特に組織体制と運営手法が重要になってきます。
このあたり、幾つか要点をまとめてみました。
分散と集中とは、各工程のタスクを事業部等の個別部署に分散してお願いするのか、
コーポレートで中央管理するのかの切り分けの話になります。
もともと、RPAの思想として、ユーザーである現場部署が自らの力で自動化できることを謳ってはおりますが、
こと大規模なプロジェクトの場合は、開発工程に進むほど中央管理することが求められます。
（参考： ＲＰＡ導入プロジェクトの工程）
前回コラムで、上記の一般的な開発工程ステップをお見せしましたが、
理想論から言うと、最初の「対象業務選出」のところまではユーザーである現場部門主導で行い、
その後の現状業務分析(As-Is)以降は、コーポレートに所属するビジネスアナリストもしくは外部の業務コンサルタントが主導して現場ヒアリングをベースに策定していくのが望ましいと言えます。
これは、As-Isの分析資料や、To-Beの設計書というものが、
次の実開発フェーズに進むうえで標準化された仕様であることが望まれるからです。
個別現場部門にお願いする場合、フォーマットを規定したとしてもどうしても書き方の統一が難しく、
標準化されていないと開発チームが混乱をきたすリスクが高まります。
ただ、これはあくまで理想論であって、
中にはビジネスアナリスト／業務コンサルタントのようなリソースの十分な確保が困難である会社も多く存在すると思います。
その場合、百歩譲って、As-Isの現状業務分析のところはフォーマットを決めてユーザー側である現場担当者に任せることも可能です。
非常に単純な作業をＲＰＡ化するのであればTo-Beのところも任せられるケースもあります。
ただ、プログラム設計書作成とのころは、開発チームに標準化された仕様書を渡す最後の砦となりますので、
その工程だけはしっかりとセントラルで品質管理できるようなチーム体制は必須となります。
（参考：ＲＰＡプロジェクト体制例）
次にＲＰＡを推進していく上でのチーム体制についてですが、こちらについては、
もちろんリソースが許す範囲でのことになりますが、PM/PMOのみならず、
ビジネスアナリスト／業務コンサルタントおよびエンジニアまで含めて専任チームを組めることが理想です。
これは、おそらくどの企業にとってもＲＰＡというものが未だ馴染みがなく、独特の注意点を要するプロジェクトとなるため、
早めにナレッジを吸収しそして歩留まりを良くするためには専任チームのほうが効率的になるからです。
また、ユーザーとなる現場部門についても、このＲＰＡプロジェクトにおいて担当窓口となる人間は各部署で特定すべきです。
ここで特に言っておきたいことは、ＰＭ/PMOの役回りも、
可能であればその期間だけはＲＰＡにほぼ特化した形で業務を遂行できるように環境を整えてあげる事です。
このPM/PMOの役回りは、現状だと経営企画室やもしくはコーポレートのＩＴ部門が担うケースが多いですが、
今まで見たケースだと、どうも他業務との兼務で指示されることが多いようです。
もちろん、最初のPOCや、As-Isの業務分析あたりまでは、兼務であっても進めることはできると思います。
ただし、より開発に近づいたフェーズになると、より開発環境の標準化やリソースアロケーションといった点で、
漏れのない管理が必要となり、そのためにはPM/PMOがＲＰＡに特化した専任チームであることが望まれます。
システム開発の分野において、一概に「分業」が全て正しいという訳ではありませんが、
ことＲＰＡに関して言えば、リソースの有効活用という側面において、組織設計に織り込む必要があります。
現状、社内リソースにおいてＲＰＡの知見を十分有している社員は、
ビジネスアナリストおよびエンジニア双方において限定的である企業が多いと思います。
特にＲＰＡに最も精通しているエンジニアを如何に開発業務に注力させられるか、
そして意思疎通の齟齬による出戻りを如何に減らせるかがプロジェクト管理上、重要になります。
開発そのものではないのですが、エンジニアとの関係の深い工程としてプログラム設計書作成と、テストがあります。
一般のシステム開発であれば、ＳＥがその工程に携わる事も多いのですが、
ＲＰＡエンジニアが限られている現状を鑑みると彼らをその工程に全投入するのは賢いやり方とは言えません。
そこで、開発エンジニアとは別に、プログラム設計書作成とテストを行うチームを設立し分業させるのが有効です。
そのチームのメンバーには初期はＲＰＡエンジニア1~数名を入れるのもよいですが、
ゆくゆくはビジネスアナリストの人材を教育してできるようにさせる事が理想です。
（参考：分業体制にした場合のＲＰＡプロジェクト体制）
このプログラム設計書＆テストチームですが、
これはＲＰＡ開発を担当するエンジニアリソースの確保の観点からも重要ですが、もう一つ別の目的もあります。
ビジネスアナリスト／業務コンサルタント側にＲＰＡの動き方・仕様の視点を学ばせて、
To-Beの業務フロー設計のところに役立たせることが狙いとしてあります。
このＲＰＡというものは、通常の人間の作業員とは全く異なる「働き方」をするロボットです。
まとまった計算処理は早いですし、24時間働くこともできます。
しかし、あいまいな指示系統だとうまく動きませんし、
エクセル内の処理だけでしたらＶＢＡによるマクロのほうが早かったりします。
このユニークな「ＲＰＡロボット」の特徴をしっかり掴んだうえでTo-Beのフローを描いたほうが、
より実現性の高いものが出来、結果出戻りも少なくなることは自明です。
特に複雑な業務フローにおいてＲＰＡを導入する段になると、
人間スタッフとＲＰＡロボットとの協業、すみ分け、分担の仕方が、非常に重要になってきます。
その時に、しっかりとＲＰＡの仕様を理解したビジネスアナリスト／業務コンサルタントがいるかどうかが、導入成功の鍵を握ると言えます。
本コラムでは、大規模ＲＰＡ導入プロジェクトにおける成功の鍵を、「組織体制」の面から述べさせていただきました。
それぞれ導入企業によって既存人的リソースの状況も違うので一概には言えないところもありますが、
あとは応用の話になりますので、要点をうまく掴んでいただけたらと思います。
多くの会社は、最初のＲＰＡ導入業務として経理財務、人事総務、営業事務といったあたりから始めることが多いですが、
まず直面するのがＲＰＡならではの細々とした課題の解決と環境設定、そしてＲＰＡエンジニアのリソース不足です。
この点を如何に解消できるかがポイントとなりますが、それには、コーポレートの専任チームを組成することと、
ＲＰＡエンジニアを最大限開発にリソース投入できるようにするための人員配置が重要となります。
本コラムでは「組織体制」からの話となりましたが、
次回コラムでは「運営手法」の面から成功の鍵を探っていきたいと思います。
乞うご期待ください。
2018.08.14
今回のコラムでは、前回に引き続き、大型ＲＰＡプロジェクトを行う際の工程詳細について述べていきたいと思います。
前回では、ＲＰＡ開発プロジェクトならではの特徴と、最初の工程となる「対象業務選出」について簡単に説明させていただきました。
（参考）前回コラム：大規模RPAプロジェクトの進め方 （1/4）
本コラムでは、それ以外の工程についてまずは順を追って説明していきたいと思います。
参考： ＲＰＡ導入プロジェクトの工程
「現状業務分析」では、選出されたＲＰＡ化候補業務について深掘りしていきます。
具体的には、現状の作業フローや、発生頻度、リードタイム、業務量等を精査していくことになります。
このフェーズでは、社内のビジネスアナリスト、外部リソースであれば業務コンサルタントが活躍するフェーズになります。
もちろん、実業務を日々行っている現場担当者も知識レベルではできうることではありますが、
フローの書き方など不慣れなところもあるので、ビジネスアナリスト等が担うケースが多いです。
ただ、こちらのAs-Isと呼ばれる現状の業務分析フェーズですが、あまりにも簡易な作業が対象となる場合、
飛ばしてしまい、次の「業務フロー設計（To-Be）」に飛んでしまうケースもしばしばあります。
例えば、社内システム上の一部入力操作のみをＲＰＡ化しようとするような単純なケース場合、
To-Beとなるロボットのフローも容易に想像がつきます。
このAs-Isの業務分析は、あくまで次のTo-Beを描くための基礎情報として使うものであり、
To-Beが容易に描けるのであれば、わざわざAs-Isに時間をかける必要はありません。
ＰＭとしてはこのあたりの柔軟性をもって各案件に接することが求められます。
一方、人間とロボットの入り混じった、かなり複雑な一連の業務をＲＰＡ化しようとする場合、
例えば、消費者からの申請書を受け取り、それをシステム入力、さらに上司によるチェック工程が入る、
といった業務となると、やはりAs-Isからしっかりと精査したほうが良いです。
上記のような業務となると、ＯＣＲといったＲＰＡとは異なる別ツールの導入を併せて検討することになり、
また人間とロボットの分担もしっかりと整理する必要があります。
また、そのように複雑な、いくつか作業が繋がってできる業務の場合は、
ロボットを入れることで業務フロー自体が大きく変わる可能性も高いです。
（例えば、人間による都度システム入力から、ロボットによる夜間のバッチ入力に変わる、等）
そのようなケースの場合は、やはり手を抜かず、まずは現状の整理から一歩一歩進めていく必要があります。
こちらのTo-Beの業務フロー設計では、ＲＰＡロボット導入後の業務フローを描くことになります。
ここではより分解して述べると、以下に分かれます。
3-1. 対象業務のTo-Be業務フロー全体の設計
3-2. 個別システム/IFの画面遷移・操作設計
3-1.は、工程2のAs-Isの業務分析のところでも述べた事と同様で、
対象業務がかなり単純であれば敢えてする必要はありません。
この工程が必要となるのは、人間とロボットが複雑に連携するような業務に対してです。
アウトプットのイメージとしては、通常の業務フロー図にロボットの領域が加わったものになります。
3-2.については、これはほぼどのような対象業務であっても必要になってきます。
会計システム、Ｗｅｂサイト、またはExcelの管理帳票といった、
ＲＰＡロボットが触ることになるインターフェースの画面操作、遷移の指示書となります。
この指示書のイメージですが、各画面の画像を切り取ったものが遷移順に並び、横に補足説明が書いてあるようなものです。
使用されるドキュメントはExcel/PowerPoint/Word等、様々ですが、
こちらの資料を基に、次の工程4.であるプログラム設計書が書かれることになります。
To-Beの仕様が決まったら、次はいよいよプログラムに落とし込む準備に入ります。
工程3までの業務フローでは、まだ「人間側」の設計書であり、「ロボット向け」の設計書とはなっていません。
前工程で決められたTo-Be業務フローをロボットのロジックに合わせて書き直す必要があります。
簡単な例で言うと、forループやif分岐、データテーブル／コレクションと呼ばれる表形式のデータセットの作成、
入力、抽出の仕方などを具体的にイメージしたフローに直すのです。
また、この工程で、次に必要となる開発／テスト環境の設計も行う必要があります。
実は、ＲＰＡ開発プロジェクトの現場では、この工程がボトルネックになることが多いです。
何故でしょうか。
通常のこのプログラミング設計書の作成はエンジニアの領域であり、システムに詳しい専門職が担当すべき工程です。
しかし、前コラムで述べたように、ＲＰＡ開発エンジニア自体が枯渇している状況になると、
このプログラム設計書作成にリソースを宛がうことが難しくなるのです。
そうなると、この工程4を飛ばして、
To-Beの業務フローができたらそのままRPAエンジニアに開発依頼をしてしまう誘惑が擡げてきます。
しかし、それは後々の不具合の種となり、非常に危険な行為となりますのでお勧めできません。
このプログラム設計書作成のプロセスは、高度なＲＰＡプログラミング技術は要しません。
しかし、開発に使用するRPAツールの最低限の知識は求められます。
UiPathであれば、UiPathの仕様、BluePrismであればBluePrismの各機能の基礎知識が求められます。
ツール間でそれほど違いはないのですが、やはり、そのあたりを踏まえているのと踏まえていないのとでは、
その後の開発者にとってやり易さが変わります。
特に、RPA開発エンジニアが枯渇している昨今の現状においては、ビジネスアナリスト、
外部だと業務コンサルタントと呼ばれている人たちが、この領域まで手掛ける必要もあると考えるべきでしょう。
プログラミング設計書ができたら、RPAエンジニアによる開発に進みます。
この工程はＲＰＡの世界の中では開発とは呼ばずに「設定」と呼ぶケースもあります。
ここで注意する点としては、実際に業務行う現場環境と開発／テスト環境への配慮が挙げられます。
何度も言っていますが、ＲＰＡは、最終的に現場の業務担当者の代わりにロボットが行うソリューションです。
つまり、現場環境で動作できる事が必須要件となります。
しかし、実際にＲＰＡを開発するエンジニア部隊が必ずしも業務担当者と同じシステム環境にいるとは限りません。
そもそも、開発をアウトソースやオフショア等別環境で行う場合、ネットワーク環境も違いますし、
端末（ローカルＰＣ）作動型のＲＰＡを作るのであればＰＣ自体の設定も異なります。
このあたりは、何回か開発をすれば小慣れてくると思いますが、最初は特に出戻りが無いように注意が必要です。
この開発工程については、自社で行わずに、外部のベンダーの活用を検討している企業も多いと思います。
それ自体は、否定はしませんが、ＲＰＡのプログラムは、
そもそも、一旦開発した後もちょっとした改修が頻繁に発生するものです。
小さな修正・メンテナンスレベルまで外注しているとコスト面での負担が増えることになりますので、
大なり小なり社内リソースでプログラミングできる体制があったほうが望ましいと言えます。
この際に、前工程のプログラム設計書作成において「設計書フォーマットの標準化」が為されていると、
各段に効率が上がりますので、ベンダーや社内開発チームなど複数の開発チームが存在する場合であっても、
設計書フォーマットは統一化することを心がけてください。
開発が終わったら、テスト段階に入ります。
これは開発者自身で行うべき単体テストのレベルから、現場担当者が検証すべきユーザーテストまで渡ります。
ここでも重要なのは、先述したように、テスト環境と、実際に動かす現場環境が合っているかどうか気を付けながら進めることになります。
また、納期重視でクイックな開発がＲＰＡは求められますので、自然と、テスト段階での微修正が発生してしまいがちです。
その場合、やはりクイックにテスト後直せるように事前にコミュケーションをとっておくことも重要です。
今回のコラムでは、比較的大きなＲＰＡ開発プロジェクトにおいて、
各工程の説明および、留意点を述べさせていただきました。
次回コラムでは、いよいよ、
開発プロジェクトを効率よく進めるために特にＲＰＡならではで気を付けるべきことを挙げていきたいと思います。
乞うご期待ください。
2018.08.13
今回のコラムでは、比較的大規模にRPAの導入を検討しているケースにおけるプロジェクト進行の要点をまとめていきたいと思います。
大規模プロジェクトとなった場合、求められるRPA対象業務数（案件数）も膨大となり、
また関係してくる各部署ステークホルダーも複雑になります。
小さな目のプロジェクトであれば、まずは一部の部署だけでPOCを行って、
徐々に対象領域を増やしていく、、といった順序でも許容されますが、
大規模プロジェクトとなった場合、「●月まで●●案件のRPAプログラムを完成し、●●時間を削減せよ」
というような命題が既定としてあり、その目標を完遂するための効率的なプロジェクト運営が求められる傾向にあります。
基本的にRPAの開発プロジェクトも、他のシステム開発案件と同様の工程を経ます。
従って、このRPAプロジェクトを進める上での要諦も、通常のシステム開発プロジェクトと大きな差はありません。
ただ、いくつかのポイントについてはRPAならではの特徴が存在します。
一つは、RPAというものが早期の実行を要求される傾向にあることです。
他の大規模システムと違い、RPAというものは、そもそも今までローカルPCで行っていた単純作業を自動化させるのに特化したツールであり、
経営者側とすれば早期の実行による社員の業務負荷軽減を期待してしまうものです。
ＲＰＡは大規模システムのような高度で入り組んだシステム設計を必要とせず、
それよりも納期の速さが故にいかに簡略化してクイックに開発を進められるかが肝になります。
もちろん、要件定義やプログラム設計書レベルのものは必要ではありますが、
例えば、テスト仕様書等時間をかけてじっくり作って準備するよりかは、
ユーザーテストをして早めに修正点を洗い出し完成に持っていくような柔軟性が求められます。
もう一つの特徴は、RPAの案件というものは、開発予算が低めに抑えられる傾向にあり、
エンジニア人材の確保がボトルネックになりがちだということです。
RPAはもともと、システム要件とならないような細々とした多種多様な業務の自動化が求められる領域であり、
開発対象となる案件は一つ一つは簡易で小さなものであってもその数は膨大となる傾向にあります。
一案件で見るとそれによる人間の業務低減効果は限定的であり、一件一件低予算で開発をこなさなければ、
経済合理性が成り立たない状況になります。
従って、ＲＰＡのプロジェクトの場合、最初の時期は外部パートナー会社の協力を仰ぐことになりますが、
ゆくゆくはユーザー自社の社員で開発・運用をしていくことが求められるケースが多いです。
そうなると、社内エンジニアの「教育」という点が重要になってくるわけですが、このＲＰＡ、世の中に出回る多くのツールは、
そもそもの思想として現場担当者レベル（人事や経理など）でも自分達で「作れる」ことを目指し、
そのためのＵＩになってはいますが、その割には難しいのが、何と言いますか、絶妙なところです。
特に大規模RPAプロジェクトになると、オブジェクト指向に基づいたモジュール管理、統一ルールの徹底などが求められるため、
やはり社内リソースに任すにしてもＩＴ部門の様な専門のエンジニア職のほうが望ましいと言えます。
上記で述べた、エンジニアによる開発予算が抑えられがちであることとも関係していますが、
もう一つのＲＰＡの特徴として、人材、特にエンジニアの人材の確保がボトルネックとなる傾向が挙げられます。
ＲＰＡは比較的新しい技術であり、現在世の中には、UiPathやBluePrism、BizRoboやWinActorといったツールが出回っておりますが、
その扱いに熟練した技術者、エンジニアは、まだその需要に対して十分な供給を果たせていません。
エンジニアとしてもＲＰＡ開発ツールが複数存在するために、
「UiPathはできるけどBluePrismはできない。。。」
といったケースが出てきてしまい、ますます特定のツールに特化した技術者を確保するのが難しい状況にあります。
また、この人材の枯渇でいうと、To-Beの業務フローを書くビジネスアナリストにも同様のことは言えます。
ビジネスアナリストは厳密な意味ではエンジニアではありませんが、ことＲＰＡのプロジェクトの場合、
業務フロー設計者もＲＰＡロボットの知識が求められます。
これは考えてみれば当然で、ＲＰＡでは今までの通常の人的リソースとは全く異なった特徴を持つ「ロボット」に業務を肩代わりさせることになる訳であり、
つまり、その「ロボット」の動き方について専門の知識を十分持っていないとTo-Beのフローが書けないからです。
そのような「ＲＰＡのエンジニア知識」を有したビジネスアナリストは、残念ながら、現在まだ多くは育っておらず、
リソースの確保が課題となっています。
このビジネスアナリストのリソース問題は、ＲＰＡの対象が簡易な単純作業だけの段階であれば、顕在化しないと思います。
しかし、そのような小さな単純作業のＲＰＡ化フェーズが終わり、
より高度な、ロボットと人間の分担が入り組んだ複雑な業務フローを組むようなケースになってくると、
切実な問題として直面することになると思います。
次に、より具体的にＲＰＡを導入する際の個別工程について話していきたいと思います。
比較的大規模なプロジェクトにおけるRPA導入のステップと関係ロールを下記に記しました。
まず、こちらの各工程について簡単に説明したいと思います。
ＲＰＡでは先述したように、早期の実行が求められることもあり、
大きめのプロジェクトであっても通常のシステム開発よりも簡略化される傾向にあります。
参考： ＲＰＡ導入プロジェクトの工程
ここでは、ＲＰＡ対象となる業務をリストアップする、アイデアジェネレーションのフェーズになります。
この工程では、実業務をしているユーザー部門の担当者が主役となりますが、
ＲＰＡの知識が無いケースが殆どですので、事前にビジネスアナリストもしくは業務コンサルタントが入って、
ＲＰＡとはどのようなものか、どのような業務がＲＰＡに向いているのか事前に勉強会を開いておくことをお勧めします。
一旦、コツがつかめれば、現場担当者から能動的に様々なロボット化のアイデアが出て来ると思います。
ただ、それでもやはりアイデアが出てこない場合は、まず各現場部署に自身の業務の棚卸し（リスト化）をさせて、
そのリストをもとにビジネスアナリスト／業務コンサルタントとディスカッションセッションを設けても良いかもしれません。
あと、この工程で大事なことは、「ざっくり」で構いませんので、
月間業務量、頻度、定型作業の割合、使用アプリケーション等、「ＲＰＡ化との相性を測れる情報」も記載しておくことです。
その情報により、挙げられたリストの内どの業務からＲＰＡ化の手をつければいいのか判断ができます。
もちろん、最初に手をつけるべきは「簡単な割に削減効果の大きい業務」からになります。
今回のコラムでは、比較的大きなＲＰＡ開発プロジェクトの特徴と、
最初の「ＲＰＡ対象業務の選出の工程」について説明をさせていただきました。
次回のコラムでは、さらに他の工程の説明および、留意点を述べていきたいと思います。乞うご期待ください。
次のコラム：【必見】大規模RPAプロジェクトの進め方 （2/4）
また、2019年5月にはRPA導入無料相談会を実施いたします。
ご予約はこちら。
2018.08.10
経済産業省が2015年にBPO（アウトソーシング）サービスに関する資料を公表していますが、
それによると日本におけるBPO市場規模は、1,600,000百万円となっています。
業務別の市場規規模は以下のとおりとなっています。
コンタクトセンター 360,000百万円：コールセンター
ヘルプデスク 126,240百万円：問い合わせ対応
フルフィルメント 30,400百万円：EC販売、在庫管理、ピッキング
人事 80,000百万円：給与計算、社会保険手続き
福利厚生 36,800百万円：福利厚生業務
総務 12,480百万円：備品管理、文書管理
経理 41,280百万円：記帳代行、支払管理、債権債務管理
購買・調達 3,520百万円：購買調達
営業 68,800百万円：営業代行
コア部門単純業務 564,800百万円：企業のコア部門が行う業務
業界固有業務 62,400百万円：特定業界の独自業務
その他 213,280百万円：包括的なサービスなど
市場規模は2022年までの年間平均成長率は3%前後という調査結果もあります。
また日本はアメリカに比べ、コア業務への集中を意図したBPO等の活用が遅れているため、
日本でのBPO市場は拡大を続ける見込みです。
なぜBPOサービスの必要性が高まっているかというと、働き方が変わったからということに尽きると思います。
これまでの、一人当たりのアウトプット量を最大化させる、高度成長期の製造業のような働き方から、
クリエイティビティが求められる働き方に変化しつつあります。
2014年に経済産業省から「サービス産業の高付加価値化に関する研究会の報告書」が公表されました。
この報告書が作成された背景として次の記載があります。
“我が国のサービス産業は、GDPの約7割を占め、雇用の面からも大きなウェイトを占めており、経済全体に与える影響が高まっています。我が国経済の再生やデフレ脱却のためには、サービス産業の生産性向上・高付加価値化が必要です。日本再興戦略(平成25年6月閣議決定)においても、「付加価値の高いサービス産業の創出を図る」との方針が示されています。”
また、サービス産業の生産性向上・高付加価値化の実現に向けた主な検討事項の一つとして、
「ビジネス支援サービスの活用促進」が掲げられています。
その調査報告コメントとして次の記述がありました。
“企業においては、BPO サービス等の外部リソース（ビジネス支援サービス）を戦略的に活用することで、当該業務のコスト削減のみならず、ビジネスプロセス全体の見直し等につながると言われている。実際、ビジネス支援サービスを利用したサービス事業者の多くは、経営資源のコア業務への集中、コスト削減、業務の効率化といった生産性・付加価値向上の効果を得ている。ビジネス支援サービスは、それ自体が成長の期待できる一つのサービス産業であるとともに、他の産業の生産性への波及効果も大きく、これを促進していくことはサービス産業の高生産性・高付加価値化のための重要な手段の一つと考えられる。”
事業を進める上では様々な「やるべきこと」が出てきますが、時間は有限です。
BPOサービスによって優先順位を明確化し、「しないこと」を積極的に決めることが重要です。
経理財務業務にBPOを導入する目的は、
「経営資源（人的リソース）をコア業務に集中させる」
「コスト削減」
「業務プロセスの標準化」
「社員退職などに対する業務継続性の確保」
などがあります。
どの目的も重要ですが、BPO導入の際は、どの目的を最重要目的とするのかを明確に決めておくことが大切です。
「経営資源（人的リソース）をコア業務に集中させる」という目的の場合、
経理財務部門におけるコア業務、ノンコア業務の分類は概ね以下のように区分できると思います。
現状の業務ではノンコア業務をこなすことで手一杯で、
コア業務を行えない又はコア業務を習得するための時間がないなどの課題がある場合、
BPOを導入することでコア業務に集中できたり、コア業務を習得するための時間が確保できます。
これによって、経営判断を行うために必要な情報を管理会計で整備する、
原価管理を適切に行うための原価計算制度を構築する、
企業価値をあげるためのファイナンスなどのノウハウが社内に蓄積するため、
他社との競争優位性が高められることが期待できます。
人材不足は他の業種同様、経理財務部門にとっても生じています。
経理財務部員が1人程度の中小企業、経理財務部員育成途中の新興上場企業、大企業の子会社で経理財務部員が少数の会社などの会社で、
ベテラン人員が退職すると、経理財務部門は混乱し、在職者に過度の負担がかかることになります。
特に中小企業などは、業務が標準化されておらず、マニュアルも十分に整備されていないブラックボックス化状態であることが多いです。
十分な引継ぎを受けないまま、在職者によってさらなるブラックボックス化が図られ、
ルーティンワークに飽き、他の会社に転職を考えるようになる悪循環が生まれます。
退職者の穴埋めで社員を採用する場合、ある程度の経理財務知識がある社員を採用するには、
多額のコストがかかることが多いです。
このような課題を解決するソリューションの一つにBPOがあります。
BPOを導入するために業務の標準化を図り、マニュアルを整備する、
そしてノンコア業務であるルーティンワークはBPOすることで、経理財務部員がコア業務に注力できる環境が整います。
コア業務に注力できれば、本人のスキルアップや、やりがいにつながり、
経理財務部門の悪循環から解放されることが期待できます。
経理財務部門で発生する不正行為の一つに現金預金の横領があります。
横領事件で逮捕されることが多いのは、「経理」として働いていた人です。
ニュースになる横領事件では、億単位の金額が横領されていることが多いですが、
その金額がすべて返済されることは少ないようです。
横領被害は会社にとって大きな損失になり、取引先や利害関係者への信頼にも影響することになります。
大企業などでは、経理財務部門の職員が複数人いるため、
「複数の人が業務を行っている」
「一定期間で配置転換がある」
「上司の適正なチェックが入る」
「経理（会計記帳など）と財務（現預金の入出金）が分離されている」
などの環境があるため、比較的横領などの不正は発生しにくいです。
一方で中小企業などの経理財務部門は1人で経理と財務を兼任しているケースが多いため、
他の人の目が届かず、チェック機能が働かないことがあります。
このような環境下では、横領などの不正が発生しやすくなります。
このように不正が発生しやすい環境から不正が発生しにくい環境にする場合にもBPOは有用であると考えます。
例えば、経理（会計記帳など）は経理職員が行い、その承認は顧問の会計事務所に依頼します。
一方財務は、BPO会社職員が行い、その承認はBPO会社職員の上席者が行うことにより、
経理と財務が分かれさらに承認者も異なるので統制が働き、不正が発生しにくい環境になります。
このように不正防止策の一つとしてもBPOは活用できます。
上記のように、BPOを経理財務部門における課題解決や不正防止策とし活用しつつ、
コア業務に注力することによって、他社との競争優位性を高めたり、
経営効率を上げていくことが大きく期待できます。
2018.08.09
今までのコラムでは、中小企業経理業務のRPA活用事例を紹介しましたが、今回は異なる視点でRPAの活用を見ていきたいと思います。
業界や具体的な業務にかかわらず、RPAが最も得意な業務は大まかに二つ共通の特徴があります。
すなわち、
①大量に繰り返される作業
②ルールが明確化されている作業
です。
更に、365日×24時間稼働可能、人間より精度が高くコストが低いなどのメリットも挙げられます。
経理業務の中に、RPA導入にとても向いている業務がたくさんあるのことを既に過去のコラムで紹介しました。
経理業務をRPA化すれば、費用対効果は抜群であることは言うまでもないでしょう。
では、「せっかくRPA導入するのであれば、経理以外の業務もRPA化すればよいのではないか？」という考えも自然に出てくるはずです。
そして、今回は人事業務のRPA活用事例を見ていきましょう。
企業Aは国内の総合ITグループです。
業務範囲はECサイト、金融、保険など様々で、従業員数5,000人以上の規模になります。
このような規模にもなると、たとえとてもシンプルな業務であっても毎月大量に単純・定型作業が発生することは想像しやすいですね。
例えば、「異動情報登録」という作業は月に2,000～3,000件発生しています。
この「異動情報登録」業務は自然、A社のRPA導入対象業務となります。
では、まずこの業務から見ていきましょう。
A社は従業員が多いため、毎月人事異動が頻繁に発生しています。
特に毎年3月や9月は集中的に発生するため、異動情報をシステムに登録するだけで人事部門は大量なリソースを割かれます。
業務内容を簡単にいうと、以下の図1のようになります：
まず、毎月各部門から異動情報が人事部あてに届きます（人事稟議などもありますが、本業務では考慮しません）。
人事部が各部門からの情報を全てまとめて、その後一項目ずつ人事システムに入力します。
これがこの業務のすべての内容です。
業務の内容はとてもシンプルで、イメージしやすいでしょう。
ただし、量が多くなると、とてもハードな作業になります。
従業員のスキルによって、一件の登録は5分～10分かかります。
A社の場合、月に2,000件あると計算すると、毎月優に300時間を超える作業時間が発生するでしょう。
この業務をRPA化すると、300時間が10時間以内になると予想されます。
RPA化すると、業務の流れは以下の図2のようになります：
各部門がもともと人事部あてに送信していた異動情報を共有フォルダーに入れることになります。
そして人事部の代わりに、RPAが毎日決まった時間で共有フォルダーの中のファイル（エクセルファイル）をチェックし、
それに基づいて、自動的に人事システムにログインして、一行一行、項目を入力していきます。
もちろん、処理できないイレギュラーな事態が発生することも想定します。
例えば情報が間違っていることや、そもそも必要な情報がそろっていないなどがあると考えられます。
この場合、RPAが自動でイレギュラーの情報を保存しておき、処理が終わった後に人事部の担当者にメールを送信します。
このプロセスはすべてRPAが実行するので、人間による関与は全く必要ありません。
人事部の担当者がRPAからの通知メールを受け取った後、イレギュラーになっている項目をチェックし、
手入力が必要か該当部署に再度確認する必要があるかなどを見て、それぞれ実行します。
処理時間はおよそ10時間以内で終わるでしょう。
もちろん、実際RPAを導入する際には色々と細かい点に注意しなければなりません。
例えば、元々人間が入力していた時は、各部署からの異動情報の書式は少しずれても大した問題にはなりません。
情報さえ合っていれば人がそれを認識し、修正することが簡単にできます。
ただし、RPAとなると、この人間にとって簡単なことができないのです。
そこで、フォーマットに合わせた書式を使ったり、RPAが読みやすいフォーマットを作ったりすることが必要です。
ここで、もう一つの疑問があります。
A社の人事システムに「まとめてインポート」のよう機能はないでしょうか？
あるとしたらなぜ使わないでしょうか？
実際のところ、A社が使っている人事システムは「まとめてインポート」機能はあります。
ただし、この機能を使うには非常に複雑なマクロが含まれるフォーマットを作る必要がありますし、
インポートする際にうまくいかない場合が多発します。
システムを変える考え方ももちろんありますが、コストの問題があるだけでなく、
この膨大なシステムを変えること自体が極めて難しいでしょう。
こういう状況では、RPAによりロボットが人の代わりに作業することが最も現実的な選択肢になるでしょう。
「契約更新業務」というのは文字通り、A社の契約社員とアルバイト従業員の契約期間を更新するたびに発生する業務のことです。
「兼務発令」はA社の従業員が自分自身のメイン業務以外、他の業務も兼務する場合発生する業務のことです。
本来であれば別業務だが、ここで一緒に紹介する理由はこの二つの業務の基本フローは極めて似ているからです。図3をご覧ください：
この二つの業務がすることは同じフローで表現できます。
さらに、よく見ると、図1と酷似していませんか？
実は、上で紹介した「異動情報登録」ともほぼ同じ流れになります。
まず各部署から契約更新の情報や兼務発令の情報を人事部がまとめて、
その後同じ人事システムに入力するのです。
ここまで来れば、RPA化の基本的な考え方もイメージつくでしょう：
こちらも「異動情報登録業務」と同じ流れになります。
まず、各部署が契約更新と兼務発令の情報が記載されているエクセルファイルを共有フォルダーにアップします。
そして、RPAが指定された時間にフォルダーからエクセルファイルの情報を読み取り、これらの情報を人事システムに入力します。
処理が全て完了したら処理結果やイレギュラー情報をメールで人事部の担当者に送信をします。
最後に、担当者はRPAが処理し切れなかった項目を手作業でカバーします。
ここで、RPAの一つの大きいメリットをお伝えいたします。
それは、ロボットの「再利用」です。
業務フローが共通しており、操作対象となるシステムも同じため、ロボットの設計図もほぼ変わりません。
そのため、例えば「異動情報登録業務」のロボットをまず開発したら、
その次の「契約更新」と「兼務発令」業務の開発がより簡単になります。
なぜなら、「異動情報登録業務」ロボットの「パーツ」を改造すれば、
「契約更新」と「兼務発令」のロボットにも使えるからです。
改造するポイントとしては、例えば、入力する項目、ボタンの位置、アクセスするページなどがあります。
もちろん、各業務に対してそれなりの工夫は必要ですが、ゼロから開発するよりは簡単になります。
ここの「簡単」はコストが低くなることと、時間の短縮を意味する場合が多いです。
今回は三つの人事業務を中心にRPAの運用を紹介しました。
ポイントとしてはまず、単純な業務でも大企業にとって大きい削減効果があります。
また、類似する業務を多くRPA化すればするほど、1業務当たりの導入コストが低くなり、さらに費用対効果が高くなります。
本文のA社のように、異なる業務で開発済のロボット「パーツ」を再利用することができるからです。
A社の場合は最初からこの3つの業務をRPA化前提で導入し、
その後「パーツ」が活用できることに気づきましたが、もちろん、まず1業務をRPA化し、
他に類似した業務を社内で探すこともできるでしょう。
この場合、ロボットの「パーツ」が様々な部門と業務で活かせるようになると思います。
2018.08.08
RPA（Robotic Process Automation-ロボットによる業務自動化）は、近年のBPOの最前線でよく聞かれるワードの一つです。
これまで人間が行ってきた定型の作業や業務をPC内のロボットが仮想知的労働者（=Digital Labor）として代行することで、
業務効率と品質の向上、コストダウンが期待できます。
ただひと口に「自動化」といっても、
抽象的すぎてどんな業務にRPAを導入できるのかいまひとつ想像がつきにくいかもしれません。
今回は多くの企業で実際にRPAの導入が進められている業務のうち、
経理財務業務でのRPA導入機会を前回に引き続いてご紹介させていただきます。
■前回記事
今回はこれまた手作業が多く発生しがちな「請求書発行～入金消込業務フロー」の自動化を検討してみます。
この部分は債権管理の観点において重要な業務ですが、その実多くの手作業が発生し、
ヒューマンエラーのリスクを抱えている会社様もいらっしゃるのではないでしょうか。
この手のヒューマンエラーは会計上の問題だけでなく、顧客からの信用問題に直結するため、
業務の正確性が多分に求められます。
また請求書の性質上、作業が月末／月初に集中し業務の偏りが発生しやすいため、
現状のフローの中だけでは業務効率化が難しい部分でもあります。
このような【請求書発行～入金消込】業務はRPAを駆使して、効率化してしまいましょう！
各部署から日々発行される請求書。
1件1件には大した労力がかかりませんが、期日前になって申請が集中し、
その分一時的な労働力がつぎ込まれていることが多いのが事実。
その業務を効率的かつ正確に処理するには、自社の請求書発行の仕組みとそれに適合するロボットの開発が肝要です。
【請求書発行システムを利用している場合】
手軽かつ安価な業務効率化の手段として活用されることの多いクラウド型請求書システム。
導入を進めている企業様も多いのではないでしょうか。
近年の請求書発行システムは、作成から送付まで安価で手広いサービスをウリにしているところが多く非常に便利です。
サービスの内容は各社とも様々。
中にはWEBバンキングや会計ソフトとの連携が可能なアプリケーションも存在しますが、
高価であったり、対応ソフトが限られていたり（全ワークフローを同系列のシステムに組み替える必要があるなど）するため、
今回は請求書発行～送付まで対応した一般的なクラウドサービスの利用を想定します。
各社員が販売明細書や売上報告書を基に顧客宛ての請求書を発行します。
多くのアプリケーションでは請求書が発行された段階で送付手続きが進行するため、
非常にスムーズに請求書を作成／送付することができるでしょう。
後段でロボットが参照し、そのデータを基に入力／照合を進めていくため、
請求書フォーマットはある程度統一されたものを使用できるように、あらかじめ各部署ですり合わせが必要です。
また、入力時も金額差異などが発生しないように、細心の注意を払って入力を進めていきましょう。
【紙ベースの請求書を発行している場合】
中小企業の中には請求書を紙ベースで発行し、直接顧客のもとへ発送しているところも多いでしょう。
自動化を検討する際は「Excelで請求書を作成し、電子ファイルで送付する」という手段が考えられます。
Excelで作成すれば、各請求書をロボットが確認し後段の作業に必要なデータを抽出しやすく、
また電子ファイル送付なら、自動メールをロボットにプログラムしておけば、簡単に発行～送付までを効率化できます。
具体的には、まずフォルダを作成し、そこに当月分の請求書をまとめて保管しておきます。
次にロボットが決められた日時にそのフォルダを巡回するように設定し、請求書内容を確認。
顧客IDなどから別途作成する「顧客マスタ」と自動で紐づけ、
送付先アドレスを抽出し自動的にメールを送付させる仕組みを作ります。
仕組み自体は簡単なので、手っ取り早く業務効率化が図れますが、
反面請求書データ送付を認めない（あるいは推奨されていない）企業が一定数存在するのも事実。
前提として請求書送付について双方の合意が必要になります。
電子ファイルでの送付が困難な顧客へは、郵送での対応をするなどしましょう。
発行された請求書を参照し、会計ソフトに売掛金として計上します。
【請求書発行システムを利用している場合】
発行の手続きが完了した請求書をロボットが確認し、会計ソフトに1件ずつ売掛金を計上していきます。
（この時点で請求書内容に不備がないように、あらかじめシステム上に承認機能を付与しておけば安心です。）
この際会計ソフトと連動するようにあらかじめ、
システムマスタ上と会計ソフト上の企業名などの表記を統一しておく必要があります。
自社独自の決まりで、より詳細な情報を会計ソフトに入力する必要がある場合（例えば金額の内訳入力など）は、
システムのフォーマットを変更させる、あるいは「顧客マスタ」から追記情報を取得／入力するなどで対応が可能です。
ただし、あまりに多くの例外的処理をロボットに実行させようとすると、必要なロボット数が増えてしまいます。
費用対効果を考え、場合によっては例外処理を手作業業務として残し、
定型化が可能な大部分の業務を自動化する方法をとるなどして、検証を進めていく必要があります。
【紙ベースの請求書を発行している場合】
フォルダに集約された請求書から必要情報を取得し、会計ソフトに転記していきます。
基本的にはシステムを利用している場合と同様です。
売掛金計上が済んだ請求書には、請求書内に「計上済みフラグ」を自動的に立てておきます。
これは次回以降ロボットが作動しても、二重計上をしないようにするためのロジックに必要となってきます。
発生月ごとに請求書発行一覧を作成します。
この請求書発行一覧上で債権管理を行います。
後段の「入金消込」時には、入金のあったものから明細を消し込んでいきます。
【請求書発行システムを利用している場合】
各社が展開するサービスの中には、WEBバンキングと連動し、
システム上で入金消込を実施できる機能を持ったものも登場しています。
しかし自社システムでそういった機能がない場合は別途一覧形式で集計する必要があります。
幸い多くのクラウドサービスにおいて、任意の期間で発行された請求書情報をCSVファイルで取得できるので、作成自体は手間になりません。
その他必要な情報は「顧客マスタ」を参照し、付与させます。
【紙ベースの請求書を発行している場合】
こちらでは、フォルダに集められた請求書の内容をロボットが確認して一覧表を自動作成します。
売掛金計上が済んだ請求書から「金額」「顧客ID」「顧客名」などを抜き出し、Excelに反映していきます。
WEBバンキングを参照し、入金のあった請求書を消し込んでいきます。
【請求書発行システムを利用している場合／紙ベースの請求書を発行している場合】
ロボットがWEBバンキングの入金情報を取得し、
請求書発行一覧から該当請求書を入金済みとして消し込んでいきます（入金日を入力）。
この際注意しなければならないのは、WEBバンキングに登録されている口座名の表記です。
口座名の多くは半角カナで表記されていることが多いので、
そのままではロボットが請求書発行一覧と照合することができません。
そのため、あらかじめ「顧客マスタ」にそれぞれWEBバンキングでの名称を入力しておき、
入金消込実施時に参照させる必要があります。
また、請求書内容によっては手数料のやり取りから振込金額が不一致となる場合もあります。
そういった場合は、ある程度の金額幅をロボットに設定し、
入金消込を実施させることも検討する必要があるかもしれません。
一定期日を以っても入金がない請求書については、自動でアラートを飛ばし通知し、
催促対応を実施することも可能です。
【請求書発行システムを利用している場合／紙ベースの請求書を発行している場合】
請求書発行一覧を参照し、入金消込が済んだ明細から、売掛金消込を実施していきます。
こちらは、②で計上した売掛金を消し込んでいくだけなので、同様のロジックでロボットに実施させることが可能です。
ただし一連の業務において、都度人間の目で適切な処理がなされているか確認し、正確性を担保することが肝要です。
今回のコラムでは経理財務業務におけるRPA導入機会をご紹介しました。
このほかにも人事/総務部門などのバックオフィスでの活用が進んでいます。
RPA導入時まず検討するべきは、
という観点での業務内容の見直しです。
そのため開発の前段階として「業務の棚卸」を実施していくことになります。
今すぐロボット開発／導入は無理でも、一度自社の業務フローを可視化することは、
業務効率化の第一歩です。
この際にぜひ一度検討してみてはいかがでしょうか。
2018.08.07
今回はUiPath開発中によく使用するアクティビティや関数を紹介しようと思います。
ファイルやフォルダを操作するアクティビティは、アクティビティツリーの「System―File」の中にあります。
これらのアクティビティを扱うためには、ロボットが現在どのフォルダ上で作業をしているか、
また、対象となるファイルが、どのフォルダ内に存在するか、意識する必要があります。
ロボットが現在どのフォルダ内で作業をしているかを調べるには、Directory.GetCurrentDirectory関数を使用します。
この関数は、現在ロボットが作業場所としているフォルダのパスを、String型で返してくれます。
下図は、「C:\tmp」フォルダ内のXAMLでロボットを動かしている例です。
Dirctory.GetCurrentDirectory関数で得られたカレントディレクトリパスが、
Write Lineアクティビティにより、Outputパネルに出力されました。
Directory.SetCurrentDirectory関数に、引数でフォルダパスを与えてあげると、ロボットの作業場所をそのフォルダに変更することができます。
この関数は、別のフォルダに移動するだけで、値を返すことはしないので、
先ほどのGetCurrentDirectory関数と同様にAssignアクティビティで使用しようとすると、エラーになってしまいます。
このような場合は、Assignアクティビティの代わりに、Invoke Codeアクティビティを使用するとよいです。
1つめのWrite Lineアクティビティでは、「C:\tmp」というカレントディレクトリパスが表示されています。
Invoke Codeアクティビティ内で実行されたDirectory.SetCurrentDirectory(“Folder A”)関数により、
カレントディレクトリが「C:\tmp\Folder A」に変更されたことが、2つめのWrite Lineアクティビティにより確認できます。
ファイルの一覧を取得するときは、Directory.GetFiles関数を使用します。
対象となるフォルダを引数で与えれば、そのフォルダの中にあるフォルダは除いて、ファイルのみを取得してくれます。
ファイルは１つとは限りませんから、ストリング配列型で結果を受け取ることになります。
下図のようにファイルとフォルダが複数存在するフォルダで実行してみましょう。
Directory.GetFiles(“C:\tmp”)関数で得られた複数の結果を、For Eachアクティビティにより、
ひとつずつ取り出して、Write LineアクティビティでOutputパネルに出力しています。
「C:\tmp」の中のファイルのみが表示されていることがわかります。
引数を追加することにより、取得するファイル名を指定することもできます。
このとき、ワイルドカードを使用できます。
Directory.GetFiles(“C:\tmp”,”*docx”)関数により、「C:\tmp」フォルダの中で、
ファイル名が「docx」で終わるものだけが表示されました。
第2引数は、あくまでファイル名の指定であって、検索ワードではありません。
そのため、「*」を外して、Directory.GetFiles(“C:\tmp”,”docx”)としてしまうと、上記のケースでは、何も表示されなくなります。
「docx」に一致するファイル名しか該当しなくなるからです。
Directory.GetDirectories関数は、Directory.GetFiles関数とは逆に、フォルダの一覧だけを取得してくれます。
対象フォルダの指定の仕方や、名前を指定する方法は、Directory.GetFiles関数と同じです。
Webやファイルから読み込んだ文字列を操作するときに役に立つ関数を紹介します。
文字列の前後に余分な空白があるときは、Trim関数で除去できます。
下図の例では、最初、「い」と「は」が、それぞれ半角スペースと全角スペースで挟まれていますが、
Trim関数により前後の余分なスペースが削除されることがわかります。
結果がわかりやすくなるように、Trim関数によりトリミングされた文字列の前後を、「@」で挟んでいます。
文字列の前後にあったスペースだけが削除され、文字列の中に含まれているスペースは残されていることがわかります。
文字列のうち、一部だけを使用したい場合は、Substring関数を使用します。
使用する部分が、X文字列目からY文字だとすると、Substring(X, Y)となります。
ただし、最初の文字は一番目ではなくゼロ番目と解釈されるので、注意が必要です。
「一二三四五六七」という7文字の文字列の、2番目(ゼロからカウントするため、指定する数字は1)から3文字だけが表示されました。
文字列の最後のZ文字だけを使用したい場合は、Substring関数とCount関数を組み合わせて使用します。
Countは、文字列の長さを計算してくれる関数です。
「一二三四五六七」は7文字なので、Count関数の結果は7になります。
Substring(4,3)が実行されたため、5、6、7文字目、つまり、最後の3文字が表示されました。
Excelやデータテーブルを扱う際に役立つ関数を紹介します。
通常は、Read Rangeアクティビティを使用する際、
対象ワークシートをワークシート名で指定することが多いと思いますが、ワークシート番号で指定することもできます。
上図のようなExcelファイルの、すべてのワークシートに対して、同じ作業を行う場合を考えます。
下図の例では、for eachアクティビティでワークシート名を順番に指定しながら、
読み込んだワークシートの内容を、output data tableアクティビティでString型に変換してから表示しています。
同じことをワークシート番号で行ってみましょう。
事前準備として、Excel Application Scopeアクティビティで、対象ワークブックの変数を取得しておきます。
Excel Application ScopeアクティビティのプロパティのOutput―Workbookの欄に、
ワークブック変数(WorkbookApplication型)を設定して、値を取得します。
取得したワークブック変数に対し、GetSheets関数を使用すると、総ワークシート数を取得したり、
N番目のワークシートを指定したりできるようになります。
Excel Application ScopeアクティビティのプロパティのOutput―Workbookの欄に、
ワークブック変数(WorkbookApplication型)を設定して、値を取得します。
Build data tableアクティビティで列名を指定しながら表を作成している最中に、
列の順番を入れ替えたくなったりすることがあります。
しかし、このアクティビティでは、列を追加することはできても、途中に挿入することはできません。
このようなときは、一度UiPath StudioでXAMLを保存して閉じてから、テキストエディタでXAMLを直接編集してしまうと楽です。
上図のデータテーブルの「失点」列と「得点」列をテキストエディタで入れ替えてみましょう。
XAMLをテキストエディタで開き、該当箇所を検索します。
ちょっとわかりづらいですが、オレンジ色の部分の「失点」と「得点」を入れ替えて保存します。
UiPath StudioでXAMLを開いてみます。
「得点」と「失点」が入れ替わりました。
今回のケースでは、入れ替える列のデータ型やオプションがまったく同じだったので、列名を入れ替えるだけで済みましたが、
データ型やAllow Null等のオプションが違う列を入れ替える際は、それらも入れ替えてあげる必要があります。
Build data tableアクティビティで最初から作り直すほうが早い場合もあります。
ケースバイケースで楽な方法で修正するとよいでしょう。
データテーブルをソートするときは、DefaultView.Sort関数と、DefaultView.ToTable関数を使用します。
上図のデータテーブルを、総得点の降順、総距離の昇順、の順でソートしてみましょう。
上図の2つの式により、ソートされたデータテーブルが作成されます。
データテーブルのX行、Y列目の値を取得する場合、データテーブル変数に対し、Rows関数とItem関数を使います。
XとYはゼロから始まることに注意して使用します。
いかがでしたでしょうか。
UiPathで使用できる各種関数、アクティビティの使い方をご紹介しました。
開発のお役に立てれば幸いです。
2018.08.06
ここ数年で欧米を中心に浸透し、日本でも2017年には導入企業が相次いだ「RPA（Robotic Process Automation）」。
労働人口の減少に直面している日本にとって、
ロボット（デジタルレイバー）による業務自動化技術であるRPAはぜひとも取り入れたいシステムです。
産業界からの注目度や導入実績では、依然として海外が先行していますが、
RPAの扱い方には国や地域によって違いがあります。
理由として、世界各国のビジネス環境や企業文化は当然ですが大きく異なっており、
自動化を求められる作業内容や、それを実現するためのソリューションも同様ではないためです。
今回は日本型と呼ばれるRPAと海外との違いについて考察し、具体的な事例についてご紹介していきます。
まず初めに、RPAの基本的な仕組みについて、触れておきます。
RPAは、簡単に言うと、人間が行っている定型業務を記憶し、
自動的に24時間365日働き続けることができるロボットです。
マクロと違う点として、RPAは複数アプリケーションを使った作業を得意としています。
例えば、取引先から届いたメールの発注書ファイルを取り出し、データを会計ソフトに反映したり、
販売管理システムへ反映したり、ということが可能となります。
ただし、イレギュラーに対しては、あらかじめ設定された判定基準、
対処方法によるもののみにしか対応することができず、
導入時の設定やリスクの洗い出しを十分に行う必要があります。
人事・経理・総務・情報システムなどの間接部門（バックオフィス）の事務・管理業務、
販売管理や経費処理、アプリケーションをまたがった入力処理などに向いていると言えます。
では、具体的に欧米と日本との違いはどのようなものがあるのでしょうか。
欧米におけるRPA導入のキーワードは「業務の標準化」です。
例えば、多民族国家であるアメリカは多様なバックグラウンドを持つ人々が共通して理解できることが伝統的に重視されます。
そのため、ビジネスの場面ではできるだけ文字要素を減らして視覚的にわかりやすく作られたツールや、
業務手順を標準化するといった配慮がなされており、RPAに関してもそうした傾向が見られます。
具体的には「オペレーター1,000人の入力画面操作を1カ月間すべて記録し、その結果をベースに標準化した手順を整備してRPAで自動実行する」というような導入パターンが多くあります。
また、欧州は言語の異なる国家の集合体であり、
各国でこれまで運用されてきたシステムを一体化する必要に迫られています。
この場合の導入では、システム統合のための時間と費用があまりにも大きすぎると見込まれた際、
各システムの連携を自動化するツールとして、RPAが検討されます。
このため、欧州でのRPAは人が介在しない完全自動のシステムとなることが大半です。
反対に、日本でのRPA導入では「ロボットと人間の共存」が求められます。
理由としては、日系企業では“現場”が力を持つとされており、
その背景には絶え間ないカイゼンで品質向上を図っている設計・生産工程や、
個別の事情にきめ細かく応じる受発注業務など、職人芸が尊敬される日本の文化が深く関わっていると考えます。
また、加えて「終身雇用制のもと、職務内容を厳密に取り決めることなく採用された従業員が、実際の必要に合わせて柔軟に対応してきたこと」なども理由の一つとして挙げられています。
現在の仕事を「人間+RPA+機械」という3層構造にしてRPAを使いこなしていくには、
企業全体でRPAに任せられそうな業務を洗い出し、どの業務にRPAを使うのかを決めておくことが重要です。
例えば、経理業務で言うなら、日々の伝票入力などのルーチンワークはRPAを導入し、
人間の仕事は収支表をもとにした経営戦略の考察など、企業の経営において本当に必要な情報を提供することに注力させることなどです。
ここで、日本におけるRPAと人間の共存事例をいくつかご紹介します。
RPAの導入事例として最も有名なのは、大手生命保険会社である日本生命保険の「日生ロボ美」です。
日生ロボ美とは導入されたRPAの名前で、請求書データのシステム入力作業を担当する社員として配属されています。
同社では、保険契約者から保険金の請求書が郵送されてくると、
記載されている10桁近くある証券記号番号などを入力して処理しなければならず、現在ではその業務をロボ美が担当しています。
ロボ美が入社したことで、それまで業務にあたっていた社員は、証券記号番号をスキャンするだけで良くなりました。
RPAが社内システムを横断し、データの収集から業務システムへの入力までを代行できるようになった結果、
1件あたり数分かかっていた処理時間が、20秒程度に短縮。
それで浮いた人的リソースを振り分けて、パターンに応じた柔軟な対応が必要な業務など、
人間でなければできない仕事にマンパワーを割けるようになりました。
サッポロビールでは、国内各エリアに取引先小売業への提案営業支援を行うリテールサポート担当者を配置しています。
POSデータの分析は、営業担当者や取引先小売業に対して販売チャンスの発掘や実施した施策の検証などの情報提供を行う上でリテールサポート担当者には欠かせない営業ツールの一つであり、
これまでは各担当者が1社当たり1日約1時間かけて、POSデータを手作業でダウンロードしていました。
手作業のためヒューマンエラーもまれに発生しており、さらに当初は数社だったPOSデータ開示も、現在は十数社に増加。
タイムリーな分析を必要とする半面、手作業では追いつかない状況となってきていました。
そこで、同社ではPOSデータの読み込みにRPAの導入を決定。
その結果、現在は1社当たり平均約30分でダウンロードが可能になりました。
さらに、手作業では作業工数抑制の観点から一部カテゴリーは週次取得にとどめていましたが、
導入後はすべてのカテゴリーで日次取得が可能となったため、日程が固定している催事についても、
よりきめ細やかな分析や提案が可能となりました。
前述のように導入メリットの多いRPAですが、その成功のためには、実際にそのRPAを動かす“現場の理解”が不可欠です。
いくつもの企業で導入の成功事例が相次ぎ、その名が普及してきたRPAですが、
企業で働く社員ひとりひとりが、その効果を十分に理解しているとは限りません。
しかし、RPAを最大限活用するのに何よりも大事なのが、これまでその業務を行ってきた社員ひとりひとりの知識・経験なのです。
そのため、導入を決めるにあたっては、RPAに任せる業務内容の洗い出しと同時に、
現場の社員全員への丁寧な説明も必須事項と言えます。
「RPAが従業員の作業を奪うのではなく、単調な作業や時間外の作業をRPAに代行させることで、従業員をより付加価値の高い業務へ移行させてくれる」ということをしっかりと時間をかけて説明し、
決してリストラへの布石など、マイナスの効果をもたらすものではないということを理解してもらって初めて、RPAと人間の共存が叶うのです。
これまで、日本の大手企業を中心に「ロボットと人間の共存」を実現してきた日本型RPAは、
今後中小企業や地方の企業・団体へと、徐々にその活躍の場を広げていくと予測されます。
人事、経理、営業サポート……etc. どのような業務においても、
これまで現場で働いてきた社員の方々の知識・経験をRPAによって最大限に活用し、
より働きやすい環境で社員ひとりひとりが輝ける職場になることを期待します。
2018.08.03
日本経済再生に向けて、働き方改革がなされている今、働き方改革について学ぶとともに、
それらの動きからRPA（Robotic Process Automation）を生かしていく方法について検討していきたいと思います。
首相官邸「働き方改革の実現」の冒頭には、
“働き方改革は一億総活躍社会実現に向けた最大のチャレンジ。多様な動き方を可能とするとともに、中間層の厚みを増しつつ、格差の固定化を回避し、成長と分配の好循環を実現するため、働く人の立場・視点で取り組んでいきます。”
と書かれています。
働き方改革は、日本経済再生に向けて、最大のチャレンジであり、
これにより企業文化や風土を含めて改革させるものと考えられています。
これらの改革を計画している背景としては、前述の通り日本経済再生に向けてというところが大きいと思われます。
日本の労働人口は想定以上に減少していると言われており、生産年齢人口が総人口を上回ると言われています。
総人口については、2050年には9000万人前後、2105年には4500万人まで減少すると考えられています。
労働力人口については、第二次ベビーブームに生まれた団塊世代のジュニアが労働力として加わったときにピークを迎え、
2060年にはピークの半分に減少すると言われています。
つまり、これらの背景から政府が考えていることは、労働力を増やすために女性や高齢者の積極的な雇用などから働き手を増やすこと。
出生率を上昇させ、未来の労働人口率を高めること。
一人あたりの労働生産率を高めることなどの対策が挙げられています。
ここで具体的な課題とされているのは、
①正規・非正規の不合理な処遇の差について
②長時間労働ついて
③単線型の日本のキャリアパスについて
などが挙げられます。
①正規・非正規の不合理な処遇の差については、正規・非正規の不合理な処遇の格差を埋めていければ、
自分の能力を評価されている納得感が醸成され、労働者が働くモチベーションを高め、
それによって労働生産性も向上されると考えています。
②長時間労働については、大きくニュースにも取り上げられました。
当時24歳の広告大手新入社員が、過労自殺したことについては、みなさんもご存知かと思います。
残業時間が過労死ラインと言われている月80時間を大きく超える105時間だったと言われている。
また、その大手広告企業では、1991年にも2年目の社員が過労自殺をしており、
2010・2014・2015年と労働基準監督署から数回にわたって是正勧告を受けていました。
このような長時間労働を解決することにより、健康の確保だけでなく、仕事と家庭生活との両立、
つまりワーク・ライフ・バランスが改善し、女性や高齢者も仕事に就きやすくなり、
労働参加率向上に結びつくと考えられています。
また、経営者はどのように働いてもらうかに関心を高め、単位時間あたりの労働生産性向上にもつながると考えられています。
③単線型の日本のキャリアパスについては、ライフステージにあった仕事の仕方を選択できるようにすることによって、
働きやすさや労働人口を高めることができるようになります。
例えば、日本における広義のフリーランスは、推計1,122万人に達しているとランサーズ株式会社の調査により発表されています。
2016年と比べてフリーランス人口は5%増となっており、今後も増加傾向にあると思われる。
ちなみに、アメリカでは2016年に5,370万人から、2017年には5,500万人へと増加すると考えられている。
日本でも若干、浸透しつつあるが、プロフェッショナルな人材がフリーランスとして、働く市場が拡大しており、
日本においてもナレッジの持った主婦や高齢者が週5とは言わずに、
企業と労働者がそれぞれニーズに合わせた形で、働くことができるようになっていくと考えられている。
このように総理が自ら議長となり、労働界と産業界のトップと有識者が集まって、議論を繰り広げて、
施策を進めているわけです。
また、その働き方改革の施策として、最近話題にあがっているのが、高度プロフェッショナル制度です。
これについて次に話していきたいと思います。
高度プロフェショナル制度は、残業代ゼロ法案・脱時間給制度などとも呼ばれており、
年収1075万円以上の一定の業種の労働者を労基法による労働時間、休日等の規制対象から外すというものです。
つまり、残業代を労働者に支払う必要もありません。
一方、時間などに縛られないため、成果を出せば数時間で帰宅することができるなど、
働き方を柔軟にするとも言われています。
この高度プロフェショナル制度について詳しく調べていきましょう。
まず、ある業種とは厚労省によって決められており、
「高度の専門的知識等を必要とし、その性質上従事した時間と従事して得た成果との関連性が通常高くないと認められる業務」
とされており、金融商品の開発、ディーリング、企業・市場のアナリスト・コンサルタント、研究開発などが念頭に置かれています。
また、年収が1075万円以上であることに加えて、職務内容が明確、労使委員会の5分の4以上の多数議決、本人の同意などが必要です。
これらの条件を見ると、ごくわずかな人にしか対象とならないように見えますが、
実は年収1075万円以上と言われている金額は、法案の条文には書かれていません。
なぜそのような具体的な数値が出てくるかというと、労基法改正案41条の2第1項2号ロによれば、
“労働契約により使用者から支払われると見込まれる賃金の額を1年間当たりの賃金の額に換算した額が基準年間平均給与額（厚生労働省において作成する毎月勤労統計における毎月きまつて支給する給与の額を基礎として厚生労働省令で定めるところにより算定した労働者一人当たりの給与の平均額をいう）の3倍の額を相当程度上回る水準として厚生労働省令で定める額以上であること”
と書かれており、「3倍の額」や「相当程度上回る水準」というのが、
曖昧であるためその金額を上げ下げできる恐れがあります。
他には、この制度のメリットである「成果を出せば数時間で帰宅することができる」という点に疑問を生じる声を聞きます。
なぜなら長時間労働を前提とした、成果給の制度を意味しており、そもそも長時間労働であるがゆえという事実が抜けているからです。
また、収入においても時給に換算すると、実は高額収入とは言えず、さらなる長労働時間を助長してしまうとも言われています。
高度プロフェショナル制度についても連日ニュースで流れるように、働き方について多くの人が敏感に感じており、
とくに労働時間について非常に注目されるところです。
つまり、これらの問題に多くの経営者も、自社の働き方や労働時間について考えていかなければなりません。
それに貢献するのが、RPAです。
RPAはRobotic Process Automationを言われるように、PCの動作全てを自動化することができるようになるツールです。
多くの労働者が、事務作業つまり、ルーチンとなっている単純業務を持っており、労働時間が増幅し、
作業からの考える時間が持てないのが現状かと思います。
しかし、RPAを導入すれば単純作業は全て自動化され、より高度な作業に集中することができます。
これらのことからも、労働時間が長いような業種や企業においては、RPAの導入を検討してみてはいかがでしょうか。
それにより、自社の働き方改革に貢献することができ、社員の労働生産性を高めることにも繋がるかと思います。
2018.08.02
この記事では私が、自分が勤める会社にRPAを導入し、運用を始めた一連の流れを書きます。
私の実体験になりますので、思いがこめられすぎて、少し読みにくい部分もあるかもしれませんが、熱が伝われば幸いです。
創業60年をこえた専門商社。
属人的に業務が進行しており、書類・データの残し方は人それぞれとなってしまっている。
ここ数年、標準化を目指し改善活動を進めており機運は高まっているがまだまだ。
多数のお客様と仕入れ先を抱えているため、それぞれのフォーマットがあり標準化は難しい。
事業部門トップが顧客に訪問した際に、「RPA導入を計画している」旨を聞き、私に調査を指示したことがきっかけ。
RPA導入のきっかけが欲しい方は、このパターンが良いかもしれません。
決裁権保有者に対し、まず第三者(できれば”お客様”の”偉い人”)から情報を伝えてもらう事により、
その決裁権保有者は『良い情報を得られた！』となりますので、
そこで時間をあまりおかずに整理された情報を伝えることにより、うまく進められるのではないかと。
いろいろなパターンはあると思いますが、一つの成功事例です。
なお、この時私は、RPAという単語は知っていたが詳しくは知らず、１から調査を開始しました。
▼調査結果はこちら↓
▼調査条件
この時の、下記所感を持ちました。
「思っていたより色々と対応できそう」
「自分でロボットを作るにはしんどそうだけど、社内からはかなり喜ばれそう」
「基幹システムはいつ刷新するかわからないため、今をそのまま改善できるRPAが地に足着いた現実的な解決案かも」
これらを、RPA調査を指示した上司に説明し、導入に向けて本格的に動くことを決意。
同時に、ソフトバンク様にデモを依頼し、社内の複数部門、グループ会社のメンバーが出席、
それぞれが好印象を持ったことも導入に向けて推進力を高められたきっかけだったと思います。
“思い”さえあれば、情報システム部門でなくても、社内に新たなシステムを導入することができます。
逆に、事業部門からの方が、具体的な導入効果を表現できるためRPAについては事業部門からの発信が向いていると思います。
また、調査を広範囲に行うことはお勧めしません。ただ時間と労力を浪費するだけです。
上記のように、調査条件をシンプルにすることでかなり絞れるはずです。
普段から、若手社員と話すと(飲みながら)、“テンションが上がらない業務”、“自分以外の誰でもできる業務”など細かなものが非常に多く、
本来の営業活動ができていない。と愚痴を聞いていました。
そこでRPA導入の費用対効果を出すためにこれらの調査を本格的に始めたところ、
自部門所属の数人へのインタビューだけで、ライセンス費用(60万円/月)は十分に回収できると分かったため、上申資料の作成に移りました。
など
RPAの導入・運用には、サーバー環境が必要です（サーバー型RPAの場合）。
そのため、情報システム部門との連携を求めました。
幸い、情報システム部門も独自でRPAの調査をしており、会話はスムーズに進めました。
当社では、事務局機能、サーバー周りの保守は情報システム部門。
ロボット作成、運用は各事業部門にキーマンを置くという形で進めることとしました。
スモールスタートの場合はサーバー環境を必要としませんが、
当社では対象のロボット案がすぐに多数出てきたため、最初からサーバー環境を要するプランで進めることにしました。
説明内容のストーリーはこうです。
（YouTubeにいくつか上がっているRPA関連の動画を使いました。お勧めはSoftBank Worldの講演動画です）
これで当社の場合は十分に理解を頂き、導入に向けて決済を頂きました。
お気づきの方もいらっしゃると思いますが、RPAロボット作成ツール自体の説明はほとんどしませんでした。
上層部は、そもそも“RPA”の事自体を正確に理解していないため、
BizroboだWinActorだと説明しても、結局どちらも“RPA”です。（質問は受けますので、準備は必要です。）
SynchRoidの柔軟性を確認できましたので、私はこの一本で上申しました。
（よくあるいくつかの製品を並べて〇×表はあえて作りませんでした）
また、キメの文句は「これを導入しないと、若手社員はどんどん辞めていきますよ。」です笑
▼必要なもの（サーバープラン）
・サーバー（クラウドサーバーでOK）
・開発用のPC *開発者の人数分
（通常、会社から配布されるPCではスペックが足りない場合が多いと思います。最低でもメモリ８GBが必要です。）
▼あった方が良いもの
・遠隔操作先用のPC
*サーバー上に仮想PCを設けても良いですが、サーバーへの要求スペックが高まってしまうため、１台手元に置いた方が開発が楽です。
・外付けモニタ
*できれば４Ｋモニタが良いです。開発画面では、実行ウィンドウ、タグなどいくつも
並行してみなければならず、フルＨＤモニタでも事足りないくらいです。
社内に情報システム部門があれば、このあたりは任せた方が良いと思いますが、
上記に書いた開発用のPCや、遠隔操作先のPC、4Kモニタなどは“後から気づく”類のものです。
ぜひ参考になれば幸いです。
情報システム部門が無ければ、必要スペックをRPAベンダーにまるまる用意していただくことも可能ですので、それもお勧めです。
ということで、予算の申請は余裕を持った方が良いです笑
決して、ライセンス費用のみで申請しないことをお勧めします。
まず当社ではスキルトレーニングを申し込み受講しました。
これ一回でRPAツールのことを理解するものではなく、ロボットを作る一連の流れを把握する程度と捉えた方が良いです。
それでも、受講をしないよりはした方が良いです。
これは絶対にさぼってはいけません。全部門に回るべきです。
また、会社によっては部門に回る順番も意識した方が良いでしょう。
RPA導入までの努力、労力は誰も理解してくれません。
逆に、メンバーは風の噂でRPA導入を知っていますので、期待を持つ人、疑心的な人などいろいろいます。
私はこういったスタンスで臨みました。
あくまで、「一緒に作り上げていきましょう。」「あなたの味方です」というスタンスです。
私が直接説明をした当事業部では、比較的に業務担当者からの「これもロボット化できる？」が多かったです。
説明の仕方が良かったのだと自負しています笑
今現在、リアルタイムに起きている問題はこちらです。
おおよそこれらが上がっています。
まだまだ数は少ないですが、今運用しているロボットの一例を紹介します。
当社ではまだ導入したてですが、すでにいくつかの業務で実績を上げておりすでになくてはならないものになっています。
なにより漠然と”他の誰かでもできる作業”、”時間と労力さえあれば行える作業”をしていた社員の方にとっては、
RPAは一筋の光であり意欲の向上に一役を買っていることが私にとっては一番の効果です。
しかし、RPAを導入した他の企業と話をしますと、当社の進みは早いケースのようです。
RPA導入メンバーとなった方は、しばらくはつらい時期が続くと思いますが、
その先に必ず成果が表れるものですので、ぜひ頑張ってほしいと思います。
ここまで駄文を読んでいただき誠にありがとうございます。
RPA導入に向けて困っている方にとって何か一つでもお役に立てれば幸いです。
2018.08.01
RPAに関する情報をチェックしていると、「BizRobo!」という名称を良く目にするかと思います。
しかしサービスそのものについては詳しく知らないという方も少なくないでしょう。
そこで本記事では、BizRobo!について解説します。
BizRobo! とは、RPAテクノロジーズ社が提供するRPAサービスの名称です。
事務業務を自動化する技術であるRPA（Robotic Process Automation）では、
自動化を実行するプログラムのことをロボットと呼び、ロボットを作成するためのソフトウェアが必要になります。
BizRobo! は、複数のロボット作成ソフトウェアと運用サポート、導入時のアドバイスをセットで提供しています。
大手銀行をはじめ導入企業も多く、国内シェアNo1を謳うNTTデータのWinActorと並び知名度も高いRPAサービスです。
国内400社以上での導入実績があります。以下のような導入例があります。
【大和ハウス工業】
基幹業務の効率化を目的としてアビームコンサルティング社の支援のもとBizRobo!を導入。
情報収集やデータ整理業務、会計レポート生成等に活用し、外注費削減などを目指す。
https://www.abeam.com/am/jp/ja/about/news/20170720
【日本生命保険（ニッセイ）】
RPAロボットを擬人化した「日生ロボ美ちゃん」を社のスタッフとして正式採用し話題に。データ検索やシステム入力を担当することで1件あたり数分かかっていた作業を20秒程度で処理し時間削減を実現。
http://rpa-technologies.com/about/#07-01
RPAのロボットは、大きく分けて各PC上で動くタイプと、サーバ上で動くタイプの2種類あります。
PC上で動くタイプはRDA（Robotic Desktop Automation）と呼ばれ、導入費用が安価に済むというメリットがあり小規模導入用途で人気があります。
一方で一元管理ができない、ログの把握が困難といったデメリットもあります。
サーバ上で動くタイプのロボットが狭義のRPAです。
管理のしやすさやユーザー管理ができるといったセキュリティ上の利点から大企業で多く導入されています。
BizRobo! はこちらに分類されます。
BizRobo! には、複数のロボット作成ソフトウェアが含まれています。
それぞれ特徴があり、利用企業の用途に合わせて適したソフトウェアを組み合わせることができるようになっています。
BizRobo! 中でも導入数が多いソフトウェアがBasic Robo!で、提供元のRPAテクノロジーズでも国内導入実績No.1を謳っています。
開発環境、ロボット監視環境、ロボット実行環境など複数のソフトウェアから構成されており、
ロボットを開発するソフトウェアはDesign Studioという名称です。
Basic Robo! におけるロボット作成は、プログラムの知識がなくてもできるのが特徴で、容易にループ（繰り返し）やファイル書き出しができます。
Excelのマクロと同様にレコーディング機能を備えており、ユーザーがクリックしたりテキスト入力したりする操作をソフトウェアが記録していきます。
一般的にプログラム言語では変数を宣言しますが、
Basic Robo!ではタイプと呼ばれる変数セットを作成し、タイプの中に複数の変数を作成します。
ロボットを作成する場合には、ロボットのなかにタイプを設定した後、右クリックで操作を記録しながらデータを取り出して変数に保存していきます。
記録した操作はフロー図のように表示されます。
Excelマクロでは実現が難しいような、Webからのデータ取得や他アプリケーションとの連携ができるのも利点です。
BizRobo! は知名度が高い反面、意外と誤解されていることもあります。ここではBizRobo! のよくある誤解を紹介します。
提供元のRPAテクノロジーズが日本企業のため、BizRobo! も日本企業が開発したサービスだと誤解されがちですが、
BizRobo! が提供しているロボット作成ソフトウェアはいずれも海外製です。
メイン製品のBasic Robo!はアメリカ企業のKofax社が提供しているKofax Kapow 10がベースになっています（Basic Robo!のソフトウェアを起動するとKofax Kapowという名称が表示されます）。
前述のとおり、BizRobo! は単体のアプリケーション名称ではありません。
RPAサービスを提供している多くの企業がソフトウェアとしてサービスを提供しているのに対し、
BizRobo! 提供元のRPAテクノロジーズ社では、BizRobo! をロボットの導入・運用を支援するためのサービスプラットフォームと位置付けています。
同社ではロボットのことを「デジタルレイバー（仮想知的労働者）」と呼び、人と同じように労働力として扱います。
ソフトウェアを販売するのではなく、複数のソフトウェアやOCR機能などを組み合わせたデジタルレイバーを作成、
提供するサービス全般をBizRobo! というサービス名で提供しているという位置づけです。
※https://rpa-bank.com/interview/7196/
ニュースなどで取り上げられるのは有名企業の事例が多く、
また導入費用が高額なことからも大企業向けのサービスだと考えられがちです。
しかしサーバ不要で初期投資を抑えられるクラウドサービス「Bizrobo! DX Cloud」をリリースするなど地方、中小企業向けのサービスも提供しはじめています。
BizRobo! が競合他社と異なる点として、パートナー企業と連携したRPAサービスを提供していることが挙げられます。
たとえばAI開発・データ分析を行うブレインパッド社では、
自社のAI技術データマイニング技術を付加したRPAサービス「ブレインロボ（BrainRobo）」を開発・提供しています。
自治体向けのシステム開発を行う大崎コンピュータエンヂニアリングでは、
今まで培った自治体向けシステム開発のノウハウを生かした自治体向けRPAサービス「OCEVISTAS」を提供しています。
いずれもBizRobo! のBasic Robo! をベースに、自社が持つ強みを組み合わせてサービス化することで差別化しています。
サービスごとにオリジナルのキャラクターを作成しています。
BizRobo! は、RPAにおけるロボットを作成するために必要なソフトウェアやサポートをセットにしたサービスのことです。
複数のロボット作成ソフトウェアが含まれていて用途に合わせて適した組み合わせができるほか、
ベースとなるソフトウェアにAI技術などを付加した連携サービスも多数存在し、
EC運営業務代行に特化したロボットや自治体業務に適したロボットなど、
さまざまな特徴を持ったロボット提供サービスが派生しています。
BizRobo! の提供元であるRPAテクノロジーズ社は、RPA操作スキルを持った女性スタッフを育成する「RPA女子プロジェクト」や、
ロボットを売買する「RPAマーケットプレイス」の提供（運営は子会社のセグメント社）など新たな取り組みにも積極的です。
RPAツールのデファクトスタンダードが存在しないなか、
「サービス提供社が多い」、「操作できる人材の育成を支援」、「ロボットの売買ができる」、「安価なクラウドサービスを提供」などを武器に、
BizRobo! の導入企業は今後も増えていくと予測されます。
出典
http://rpa-technologies.com/products/first/
https://rpa-bank.com/column/11305/
また、Basicrobo、SyncRoidについては以下の記事も併せてご覧ください。
