2018.06.29
最近あらゆる業界でよく耳にする RPA（Robotic Process Automation）。
だれでも業務自動化ツールを作成できるという優れものです。
確かに実際に活用してみると、思っていた以上の効果やメリットがありました。
しかし、本当に安定したつくりを構築するには、場面場面に応じた工夫がなにより大切であることに気が付きました。
当レポートは、上記のような効果やメリット、工夫ポイントをまとめたものです。
活用事例の 1 つ目は『Web サービスでの大量処理』です。
同じような工程を何度も繰り返し行う業務はどの業界でもまだまだあることだと思います。
例えば、月末・年度末等の締め業務や納品物を過去分再作成しなくてはならないケース、
システム開発においてのテスト用データ集計など様々です。
このような事例の場合、担当者からすると以下のような不満が挙がることでしょう。
▸ こんな難易度の低いタスクに A さんを使うのはもったいない…
▸ 単純作業ではあるが納期がやたらと早い…
▸ 誰でもできるタスクだが夜遅くとなると社員がやらざるを得ない…
私の知る現場でも、納期や就業時間の関係でやむを得ずに原価の高いスタッフさんや社員が単純作業にかかりきりということはよく見る光景でした。
そこで RPA を活用することによりそれらの問題を解消した 1 つが、今回の Web サービスで大量処理を行った事例です。
当事例では何よりも処理する量に対して期限が短すぎるという問題があり、
はじめはスタッフ 3 人を 3 日間フルで活用する流れでした。
しかし 1 日を RPA 作成にあて、2 台の PCをフル活用することにより 2.5 日ですべての処理を完了することができました。
今回の事例では、下記ポイントが RPA 活用の判断基準となりました。
▸ 対象タスクが単純作業のため、RPA 作成に時間がかからない
▸ 常にチェックしなくても良いルーチンワークのため、夜間監視無しでも問題ない
当事例の効果としては、以下の2点が挙げられます。
▸ RPA 未使用：9 人/日 + 担当スタッフが他の業務
▸ RPA 使用 ：1 人/日 + 他の業務に RPA を活用できる可能性がある
また、上記だけでも効果としては十分ですが、以下のようなメリットも考えられます。
▸ 人間の作業に比べてミスが発生しにくい
▸ 早朝や夜間に処理できるため、Web の回線やサーバーが空いている
▸ スタッフの能力に左右されずに一定速度・安定クオリティを実現する
今回の事例に適した RPA を作成するにあたり、工夫・注意すべき点は以下が考えられます。
▸ 画面遷移、処理中待機処理の作りこみ
▸ リランのかけやすさ
まずは待機処理の作りこみです。
Web サービスに対して RPA を活用するうえで壁となるのがこの画面遷移や処理中での待機です。
画面遷移によるエラーとは、遷移が完了しているように見えて実はまだ裏では準備中であったために、
必要な画面要素が取得できずにエラーが発生するという事象です。
また、集計系 Web サービスでは集計中の待機画面に遷移して集計完了を待たなくてはいけません。
今回は監視無しで就業外に処理をさせることが前提であるため、
この手の問題でエラーとなって処理が止まってしまうのは致命的です。
遷移後のタグ要素を見つけるまでループや、多少無駄が出ても処理前後に待機時間を設けるなど、
念には念を入れて作成することをオススメします。
また、万が一にも朝出社した際に処理が止まっていたという時のために、
リランはかけやすく作成することを強くオススメします。
ただでさえ時間のない案件では、
エラーの箇所や原因が分からずすべて処理をやり直すということだけは可能な限り避ける必要があります。
そのため、パラメータファイルを用意して途中からでも処理を流せる作りや、
ログを出力させることでエラー箇所・原因が明確になる作りなどを心掛けてください。
続いて活用事例 2 つ目は『Web サービスでのレギュラー運用』です。
日々のレギュラー業務というものは、当記事をご覧いただいているあなたにとって活用事例 1 よりも身近に感じられるかもしれません。
実際に私の勤め先でもいまだに日々の日報を各々が Excel ファイルに入力し、メンバー分を集めてメール送付しています。
今回の事例では Web サービスのレギュラー運用となってはおりますが、
要点等は Webサービスに限らずにレギュラー業務共通で大切なポイントであるため、是非参考にしていただけると幸いです。
今回の事例では Web サービスで出力した帳票を VBA マクロにより加工し PDF としてメール送付するというものです。
一見すると、いろいろなサービスやアプリケーションを駆使しているため難しく思えます。
しかし、このいろいろなアプリケーションを使用できるということは RPA の長所であり、
それぞれのアプリケーションの得意なことだけをやらせればいいため、
いたってシンプルなつくりになるのです。
もちろん作ろうと思えば VBA マクロ等、何かしらのプログラムを組んで当タスクすべてを処理することはできます。
逆に、データの加工も含めて RPA にやらせることもできます。
しかし、Web サービスやメールアプリを操作するプログラムを組むのは少々骨が折れます。
また、RPA でのデータ加工を作成するのも苦労とともに速度的な不安が生じます。
そこで主な処理ステップは RPA で行いつつ、マクロ等外部システムを活用することで各長所を活かした構成になります。
このように、できるならば RPA のみにこだわらずに様々なアプリケーションを利用してより最適な構成を考えてみてください。
当事例のような様々なアプリケーションを利用した日々のレギュラー業務というものは、
RPA で自動化することにより想像よりもはるかに大きな効果を受けることができます。
▸ 一つ目は、精神的・物理的負担の軽減が挙げられます。
レギュラー業務は、毎日同じ時間に必ずやらなくてはならないということがほとんどだと思います。
‟必ずやらなくてはならない”という縛りは想像以上に社員を苦しめます。
「体調不良であっても気軽に休むことができない」
「会議を自分の都合でずらしてもらわなくてはならない」といった精神的にも物理的にも多くのダメージを受けることでしょう。
このレギュラー業務から解き放たれた時には感動を覚える程だと、わたしはそう思います。
▸二つ目は、運用の安定化です。
毎日同じことをやるとはいえ、人間誰しもミスはするものです。
更に、今回の事例は人力であっても様々なアプリケーションを介さなくてはならないため、
アプリケーションの数が増えれば増える程ミスのリスクは上がっていきます。
また、「メールの送信は何時以降にすること」といった制限がある場合は、
送り忘れや間違えて早い時間に誤送信してしまうリスクもあり、担当したくない業務ベストでも上位に挙がることでしょう。
これを RPA 化することにより、毎日同じ処理を同じ時間に安定して運用することができるのです。
事例 1 では数値で明らかな効果を発揮していましたが、上記のように 2 つ目の事例では数値よりも社員の負担軽減や運用の質の向上に効果を発揮することができました。
RPA を非常に効果的に活用できた運用業務ですが、もちろん注意する点も多々存在します。
ここでは代表して下記 2 点を挙げさせていただきます。
▸ エラー・完了通知処理
▸ サーバーの仕様に強いつくり
まずは「エラー・完了通知処理」についてです。
レギュラー業務を自動化することで担当者は完全に安心しきってしまいます。
そんなとき、想定外のエラーが生じたらどうでしょうか。
誰も気づかずに損害が発生してから気が付くことになってしまいます。
また、心配性の担当者の場合、せっかく自動化したにもかかわらず処理がちゃんと完了しているかを毎回確認しにいってしまうかもしれません。
これらが起こった時点で今後の運用への信頼が揺らいでしまい、全てを台無しにしてしまいます。
レギュラー業務に限ったことではありませんが、「エラー・例外処理」や「処理の完了通知処理」というのは忘れずに組み込むようにしましょう。
また、Web サービスでの処理を毎日行うということは、実行時に都度サーバーに問い合わせを行います。
そのタイミングによってはサーバーのメンテナンスやロードバランサーにより参照ファイルの ID がいつもと異なるかもしれません。
もし RPA のつくりの部分でURL や要素をガチガチに作ってしまっていた場合、ID の違いに対応できずにエラーとなってしまいます。
そのため、できる限り ID 等にはワイルドカードを使用するなど柔軟なつくりを意識していただけたらと思います。
RPA はプログラミング無しで高度な自動化ツールを作成できるという長所があります。
たしかに、ある程度の自動化ツールであれば素人でも簡単に作ることができます。
また、プログラミングの経験がなくとも使用する RPA ツールさえマスターすれば安定したロボットを作成することができるでしょう。
しかしより安定した、より応用のきくツールを作るためには下記スキルがあると更に RPA の効果は増すことでしょう。
▸ 論理的思考
▸ システム開発経験
▸ プログラミングスキル
まず論理的思考ですが、無駄のないしっかりとしたシステム構成を作成できるようになります。
後のことを考えた処理ステップの構築や、エラー処理のためのループ・分岐の適切な使い方は、RPA に安定とメンテナンスのしやすさを与えます。
システム開発の経験は、エラーの起こりにくいつくりや作成した RPA のテストに役立ちます。
どのようなことが要因でエラーが起こるかというのは、多くが経験から得るものです。
そのため、システム開発の経験は想像以上に役立ちます。
最後に、プログラミングスキルです。
事例２でも述べましたが、RPA のみでは速度や精度に多少の不安を覚えます。
そのため、より速度や精度を上げたい場合や、どうしても解決できない壁にぶつかった際には、
何かしらのプログラミングが組めると大きなアドバンテージとなるでしょう。
RPA はプロジェクトにコストの削減を、わたしたちに負担の軽減を与えてくれます。
しかし、誰でも作れるのだろうと甘く見て作成したところで、不安定で使い物にならないものが出来てしまいます。
いくら素人でも作れるという長所があったとしても、結局は RPA を活かすも殺すも RPA
開発者のスキル次第なのです。
なお、弊社は全員がRPA資格を保有したエンジニアで構成されているため、質の高いソリューションが可能となっています。
ご検討中の方は、ぜひお問い合わせください。
2018.06.28
経理担当者であれば、毎月の経理業務で源泉所得税の計算と納付を行ったことがあると思います。
また源泉所得税に関連する業務として、毎年1月には支払調書の作成があります。
源泉所得税の計算は電卓で行い、源泉所得税の納付は銀行の窓口で納付し、支払調書は、
総勘定元帳や請求書などを見返しながら作成しているケースが見受けられます。
ここでは、源泉所得税と支払調書の経理業務について、
経理担当者や会計事務所職員が実践できる業務効率化の方法をお伝えします。
源泉所得税の集計には、エクセルで以下のような源泉所得税集計表を作成し、
源泉所得税の金額算定と振込金額の計算を行います。
各項目と各セルの計算式は以下のとおりとなっています。
[A列：姓]
氏を入力します。
[B列：名]
名を入力します。氏と名を別のセルに入力することにより、氏名データの結合・分解が容易になります。
[C列：屋号]
屋号があれば屋号を入力します。A列及びB列は正式な個人名を入力します。
[D列：該当号]
支払調書の「区分」欄に該当する区分番号を入力します。主な区分番号と報酬内容は以下のとおりです。
1号：原稿料、イラスト、写真撮影、作曲、工業デザイン、グラフィックデザイン、印税
2号：弁護士報酬、税理士報酬、司法書士報酬、建築士報酬
3号：診療報酬
4号：モデル業務報酬、プロ野球選手
5号：テレビ出演料、放送作家報酬、
[E列：区分名]
報酬の内容を入力します。
[F列：細目名]
区分名に対応する細目を入力します。
[G列：基番]
郵便番号の基番を入力します。
[H列：枝番]
郵便番号の枝番を入力します。
[I列：住所]
住所を入力します。
[J列：報酬区分]
源泉所得税の納付書に対応する報酬区分を選択（入力）します。
今回は実務的に多く発生する「税理士等」「報酬料金」「非居住者」の3区分で作成しています。
[K列：税区分]
源泉所得税の計算にあたり、税込報酬から源泉所得税を計算するのか、税抜報酬から源泉所得税を計算するのか選択（入力）します。
[L列：報酬（税抜）]
源泉所得税の対象となる報酬額の税抜金額を入力します。
[M列：報酬（税込）]
源泉所得税の対象となる報酬額の税込金額を入力します。
[N列：源泉対象外]
源泉所得税の対象外の金額を入力します。
[O列：源泉所得税]
源泉所得税が自動計算されます。セル「O3」に次の計算式を入力しておきます。セル「O3」に入力した計算式を6行目までコピーします。
=IF($J3=”非居住者“,ROUNDDOWN(M3*0.2042,0),IF(K3=”税込“,ROUNDDOWN(IF(M3>1000000,1000000*0.1021+(M3-1000000)*0.2042,M3*0.1021),0),ROUNDDOWN(IF(L3>1000000,1000000*0.1021+(L3-1000000)*0.2042,L3*0.1021),0)))
[P列：振込額]
振込金額が自動計算されます。セル「P3」に次ぎの計算式を入力しておきます。セル「P3」に入力した計算式を6行目までコピーします。
M3+N3-O3
[セルL8からL21]
上記源泉所得税集計表サンプル画像のとおり、「人数」「支給額」「源泉所得税」の項目を入力します。
[セルM8からM21]
セルM8からM21には以下計算式を入力しておきます。
M9: =COUNTIFS($J$3:$J$6,”報酬料金“,O$3:O$6,”>0″)
M10: =SUMIF($J$3:$J$6,”報酬料金“,M$3:M$6)
M11: =SUMIF($J$3:$J$6,”報酬料金“,O$3:O$6)
M14: =COUNTIFS($J$3:$J$6,”税理士等“,O$3:O$6,”>0″)
M15: =SUMIF($J$3:$J$6,”税理士等“,M$3:M$6)
M16: =SUMIF($J$3:$J$6,”税理士等“,O$3:O$6)
M19: =COUNTIFS($J$3:$J$6,”非居住者“,O$3:O$6,”>0″)
M20: =SUMIF($J$3:$J$6,”非居住者“,M$3:M$6)
M21: =SUMIF($J$3:$J$6,”非居住者“,O$3:O$6)
ここまでで、1か月分の入力シートが完成します。
最後にL列からP列すべてをコピーし、Q列以降に残り11か月分を「コピーしたセルの挿入」し、
最後の列に12か月分の合計欄を作成し完成です。
源泉所得税を紙の納付書に手書きしている場合は手書きの納付書を廃止します。
その代わりにe-Taxを利用してe-TaxのWeb上で源泉所得税の納付書の作成及び提出をします。
e-Taxを利用するためには、利用者識別番号と暗証番号が必要です。
利用者識別番号と暗証番号の取得が済んでいない場合は、
e-TaxのWebサイトで利用開始の届出をする必要があります。
会社の基本情報などを入力するだけで簡単に利用者識別番号と暗証番号が取得できます。
顧問税理士がいる場合は、顧問税理士が利用者識別番号と暗証番号を管理している場合もありますので、
顧問税理士に問い合わせしてみてください。
源泉所得税を銀行窓口で納付したり、
インターネットバンキングのペイジーで納付している場合は、それをダイレクト納付に切り替えます。
ダイレクト納付の利用開始の手順は以下のとおりです。
１．上記（２）のe-Taxの利用届の手続きをし、利用者識別番号と暗証番号を取得します。
２．国税庁のWEBページから「国税ダイレクト方式電子納税依頼書兼国税ダイレクト方式電子納税届出書（入力用）」をダウンロードします。
３．ダウンロードした「国税ダイレクト方式電子納税依頼書兼国税ダイレクト方式電子納税届出書（入力用）」のPDFに必要事項を入力し、印刷します。
印刷後、代表者の署名・押印をして、所轄の税務署に提出します。
４．提出から１か月前後でダイレクト納付の利用開始ができる旨のメッセージが、
e-Taxのメッセージボックスに届きます。
１．源泉所得税業務とRPA
e-Taxとダイレクト納付が利用できる状態であれば、
それにRPAを組み合わせることにより源泉所得税業務の大半をRPAに任せることが可能になります。
源泉所得税の一連の業務とRPAの導入箇所は以下図のイメージです。
上記図のとおり、源泉所得税の集計のみを行えば、残りはRPAで処理することが可能になります。
納付期限である毎月10日の2～3営業日前にRPAをタイマー起動すれば、
月初の繁忙時期に源泉所得税の業務から解放されることになります。
事業会社の場合は、源泉所得税業務にRPAを組み合わせたとしても、
その業務の削減時間のインパクトは大きくはありません。
しかし、源泉所得税業務を多く受託している会計事務所では、
源泉所得税業務をRPAに任せることにより、大幅な工数削減が期待できます。
会計事務所での源泉所得税の納付書の作成や納付方法は各職員によって様々な処理方法で行われていることが多いと思います。
紙の納付書に必要事項を記入し、それを郵送するための封筒の宛名を手書きした後切手を貼り、
クライアントは忙しい中銀行の窓口で長い時間待たされのち、やっと納付できます。
このようなフローで源泉所得税業務を行っていては忙しさはいつまでたっても変わりません。
源泉所得税業務の会計事務所でのRPA導入のポイントは次の3点です。
・源泉所得税集計表ツールを所内全員が同じものを利用し、一つの共有フォルダにクライアント別に保存することです。
・各クライアントの納付書提出方法をe-Taxソフトや申告書作成ソフトなどで電子送信することです。
e-Taxソフトを使用するのか、申告書作成ソフトを使用するのかも統一します。
・源泉所得税の納付方法をダイレクト納付にします。
各職員で行っている処理方法を上記ポイントに沿って標準化することが重要になります。
会計事務所職員は、納付後のメール詳細を確認し、クライアントへの税額連絡で業務は完了します。
クライアント側は何もすることはなく、源泉所得税が口座振替になるのを待つのみです。
支払調書の作成は、毎月の支払状況の管理と源泉所得税の管理がとても重要になります。
源泉所得税の管理はエクセルで行っているが、それが支払調書のアップロードデータに連動していないケースが多くあります。
源泉所得税の管理データを支払調書のアップロードデータに連動させることにより、
毎年1月の支払調書作成業務時間を大幅に削減することができます。
データ連動については単純な定型的な業務のため、ここでRPAを導入することで、
ほとんど人間の手が加わらずに支払調書を作成することができます。
今回は経理業務の中でも細かい業務である源泉所得税についてフォーカスしたことで、
RPAができることのイメージが具体的に湧いたと思います。
これにより削減できる時間は多くはありませんが、業務効率化の一歩として実践してみてはいかがでしょうか。
2018.06.27
前回は、中小企業の「請求書照合・計上業務」と「入金・出金情報の会計システム入力業務」のRPA活用について紹介しました。
導入方法は簡単であり、効率もとてもよく、費用対効果は抜群です。
今回は前回の続きで、「請求書発行業務」のRPA活用について、実用例を見ながら紹介したいと思います。
「請求書発行」業務はほぼどの企業にとっても不可欠な業務です。
他の経理業務と同じく、量が多く、入力やフォーマット変換などの単純作業が多いです。
しかも、成長の早い中小企業にとって、事業が拡大すればするほど、請求書発行の量が増え、経理部門の負担もどんどん大きくなります。
今回紹介する企業の中でも、月180時間以上請求書発行業務に時間を取られる企業があります。
では、A社、B社の「請求書発行業務」RPA化の事例をみていきましょう。
多営業所展開のA社はシステムを導入し、請求書発行業務はほぼシステムで行っていますが、
システム操作の手作業部分はまだ多くあり、毎月多くの時間が取られています。
業務の流れを簡単に説明すると、以下の図になります：
まず、請求書情報入力の担当者が毎日各営業所で請求書情報を定形のExcelフォーマットに入力し、メールで経理部門へ送付します。
経理部門がメールを受け取り（請求書情報取得）、その中の請求書情報をみて、
営業が契約時にシステム内に入力した請求書情報などとあっているかをチェックします（請求書情報照合）。
この段階で、すでに多くの作業が発生しています。
そして、請求書発行リストを作成するために、システムから「未入金一覧」CSVファイルを出力し、
必要なフォーマットに変換します。
続いて、担当者がリストを見て、請求書発行対象外（日付はまだ先なものなど）項目を見つけ出し、消します。
これで請求書発行リスト（Excelファイル）は出来上がりです。
そして、この請求書発行リストを「請求金額計算システム」にインポートし、
「請求金額計算」（値引きなどの情報）を行います。
Excelファイルをインポートすればシステムが自動計算しますが、
ファイル形式変換やインポート実行などは手で作業しないといけません。
計算終わったら、システムから請求金額の計算結果ファイルが作られ、
このファイルをシステムにインポートします。
ここまでやって、ようやくシステムから仮請求書（PDF）が発行できます。
続いて、仮請求書を各営業担当にメールで送信し、内容の確認を行います。
請求書の量が多く、メール送付もとても時間がかかります。
確認結果が営業からメールで返信され、修正点があれば経理が返信し、そのまま修正します。
問題なければそのまま本番の請求書発行に入ります。
以上のプロセスはほぼシステムを利用していますが、手で操作する部分がとても多く、
毎月必要な時間が多いため、経理担当者への負担が大きいです。
詳しく見ると、これらの操作は大まか三つに分けられます。
すなわち、システム操作、Excelファイル変換、データ照合です。
いずれもRPAの得意分野であり、RPA導入方法すると以下のように、営業確認の段階以外、ほぼ全てRPA化可能です。
このように、請求書情報はRPAがメールの中のExcelファイルを取得し、システムの中の情報と照合します。
そのあと、事前に定義した書式に変換し、金額計算のシステムにインポートします。
終わったらそのまま計算結果をシステムに取り込みます。
そして、仮請求書PDFを発行し、定形メールを各担当者に送ります。
この一連の作業はほぼ中断せずにRPA化することが可能です。
経理担当者はただRPAが処理できないエラーやイレギュラーなどを対応すればよいので、大幅に時間を節約できます。
B社はA社と異なり、元々のシステムでは請求書発行の機能は含まれ、中間ファイル変換の回数もそれほど多くありません。
図のように、まず各営業担当が入力した請求書情報を社内のシステムから取得します。
発行段階前に、すでに金額等を確認済みのため、もう一度確認する必要はありません。
そして、システムから未入金一覧リストCSVを出力し、編集しやすくするために書式変更等もします。
また、そのなかから請求書発行対象外（未来日付のもの等）を消します（請求書発行対象リスト作成）。
作業量が多く、この段階までで、毎月40時間以上かかっています。
また、一部の請求書は取引先のご要望により一枚を複数枚に分割することもあります。
そして、請求書を印刷し、郵送します。
一部は取引先の要望によりPDFで発行し、メール送付します。
この印刷段階では一つの問題として、システム上印刷は一括でできず、20枚単位の印刷しかできません。
そのため、人が複数回操作しないといけないので、他の作業に集中するのが難しいです。
この流れを見て、やはり完全にRPA化するのが難しいかもしれませんが、
うまく使って効率向上させる方法はまだあります。
図のように、請求書情報取得から請求書発行対象リストまではRPA化可能です。
なぜなら、これらはExcelやシステム操作がメインだからです。
発行対象外業務のピックアップも事前に定義すれば、RPAも対応可能となります。
請求書分割はやはり基準があいまいなので、手作業で行うしかありません。
また、請求書印刷も簡単に自動化可能です。
印刷対象を選択し、印刷ボタンを押すだけのロボットがホントに必要なのか？という疑問があるかもしれませんが、
実際、B社は毎月印刷だけで5時間かかっています。
事実、この作業はRPAを夜中で完了させられたら、とても楽になると担当者もおっしゃっていました。
郵送は手作業になりますので、RPA化は難しいです。
また、その中の一部はPDFになっているため、こちらに関してはPDF発行をし、
そのあと取引先のメールアドレスで定型文を自動送信することはできます。
ただし、現状送付する前に一度目視確認が必要のため、やはりRPA化しないという方針で進めました。
A社とB社双方とも自社のシステムを有していますが、
現在のシステムは全ての経理業務をスムーズに対応できるかと言ったら、実際そうではありません。
特にA社の場合、システムが様々な機能があるように見えますが、
中間ファイル変換など、色々と手で操作しないといけないため、時間がたくさんとられてしまいます。
もちろん、システム丸ごと変える方法もあります。実際A社も検討してはいました。
そうすると請求書発行業務を全て電子化するなどが実現でき、RPA等がなくても現在より効率よく動くでしょう。
ただし、いくつかの問題が生じます。
まず、このシステムは今回紹介した業務のみではなく、全社の各部門が使われているシステムになります。
システムを変えるというのは、全社的に今までの業務プロセスを全て見直さなければならないことを意味します。
また、従業員が操作を覚えるのに時間も必要であるため、すぐには導入できないでしょう。
加えて、システムを全てリプレイスする費用も大きくなります。
以上の原因があり、なかなかすぐシステムを変えることができない場合が多々あります。
この場合、RPAを導入すれば、現在の業務プロセスを大きく変更せず、効率向上することが実現できます。
RPAの導入期間は短く、操作を覚えるのも簡単です。
B社も場合は、まさに一部の作業を自動化することにより、効率向上を図る良い例です。
RPAは苦手な部分こそありますが、使い方次第で柔軟にもなり、様々な業務で活躍できるでしょう。
2018.06.26
RPA（Robotic Process Automation-ロボットによる業務自動化）は、近年のBPOの最前線でよく聞かれるワードの一つです。
これまで人間が行ってきた定型の作業や業務をPC内のロボットが仮想知的労働者（=Digital Labor）として代行することで、
業務効率化と品質の向上、コストダウンが期待できます。
ただひと口に「自動化」といっても、
抽象的すぎてどんな業務にRPAを導入できるのかいまひとつ想像がつきにくいかもしれません。
今回は多くの企業で実際にRPAの導入が進められている業務のうち、
経理財務業務でのRPA導入機会を前回の記事に引き続いてご紹介させていただきます。
今回は、これまた手作業が多く発生しがちな経費精算業務フローの自動化を検討してみます。
各部署から日々回付される経費精算申請。
1件1件には大した労力がかかりませんが、締切前になって申請が集中し、
その分、一時的な労働力が注ぎ込まれていることが多いのが事実。
その業務を効率的かつ正確に処理するには、
自社の経費申請の仕組みとそれに適合するロボットの開発が肝要です。
手軽かつ安価な業務効率化の手段として活用されることの多いクラウド型経費精算システム。
実際に導入している企業様も多いのではないでしょうか。
この場合ロボットは、システム内を巡回しその後の処理に必要なデータを都度取得する役割を担います。
加えて申請内容の正当性や、照合に必要な領収書添付の有無を判断するような「承認機能」を付与することで、
一定の照合作業を代替することも可能となります。
（最終的な金額の整合性や費用科目の正誤は人間による目視で要確認）
経費精算システムを利用するうえで最も重要なのは、システム上に登録されているマスタ情報の管理です。
例えばロボットが後段で必要とする各社員の振込先口座情報は、
日ごろから最新の状態にしておかなければなりませんし、
また一事業単位で収益を算出する必要がある場合は、それぞれの事業コードの管理が必要です。
また、申請内容の正確性の担保も必要。
各社員が入力した申請金額や費用科目は、その後ロボットがそのまま流用することになります。
システム上の承認フローで決裁者もしくは経理財務担当者が照合し、
場合によっては差戻すなどしてロボットが正確なデータを取得できるようにしなければなりません。
要するに「ロボットが精密に業務を遂行できる環境づくり」が前提となってくるわけです。
中小企業や老舗企業の中には、申請書を介して申請内容をやりとりする企業も多いのではないでしょうか。
現在のOCR（光学的文字認識）技術は日々機能の発展が目覚ましいものの、完全な紙媒体のみの業務自動化はまだ困難な状態です。
そのため、申請書をExcel形式で入力／データ提出させる方法を検討するのが一般的です。
予め全社で統一のフォーマットを作成し、申請方法や入力内容のルールを定義づけ社員に共有します。
申請されたExcelを任意のフォルダに集積しておくことで、ロボットは一つ一つを確認して回り、
決められたセルにある各種情報（金額／費用科目／申請者名（ID）／部署名など）を取得し、
当月分の経費精算内容を一覧データとして作成します。
この一覧データが後段の振込／仕訳工程のデータベースの役割を担うのです。
申請書のみの情報では網羅できない情報は、別途マスタを作成しロボットが一覧データ作成時に情報を取得できるようにしておきます。
（例えば振込先口座情報。マスタ上で申請者の社員IDと振込先口座情報を紐づけ一覧データに別途入力させる）
経費申請が承認されたものから発生金額を「未払金」として会計ソフトに計上していきます。
決裁者／経理財務の承認が得られた申請は、
この承認履歴をトリガーとして作動したロボットによって自動的に会計ソフト上に計上されます。
この時申請時に入力された費用科目を基に仕訳を実施するため、
入力間違いはそのまま反映され、間違った処理が実行されてしまいます。
金額の入力ミスは言うまでもありませんね。
特に費用科目の定義は経理財務にとっては常識でも、
その他の社員にとっては意外と曖昧になっているケースが往々にしてあります。
そのため前段で述べた承認／差戻の徹底が不可欠になってくるのです。
この部分を徹底してシステムを運用していくと、
社員は費用科目の知識が身について自然と入力の正確性が上がっていくでしょう。
経費精算申請時に作成した一覧データを基に会計ソフトに仕訳を実施します。
月次で一覧データを作成しているためシステム利用のケースと違い、
こちらは任意のタイミングでロボットを起動させる必要があります。
（毎月〇日〇〇時と日時指定を組み込む or 起動時に特定のキーワードを入力したメールを送信するなど）
処理方法は原理的にはシステム利用のケースと同様で、ロボットが申請金額と費用科目を一覧データから抽出して入力します。
1件ごとでなく費用項目ごとの合計で入力する必要がある場合は、
一覧データ上で金額を集計するロジックをロボットに組み込んでおく必要があります。
決められた振込日に向けてバンキングサイトへの振込手続きを実行します。
ここでの業務はとってもシンプル。
なぜなら、大半の経費精算システムで申請一覧データがCSVファイル（全銀協統一フォーマット）でダウンロードできるからです。
このデータファイルを生成してしまえば、あとはバンキングサイトに取り込ませるだけ。
もちろんRPAで代替可能の業務ですが、
業務ステップが他の作業工程より格段に少ないので人力でも大した作業ではありません。
費用対効果を考えて自動化を検討しましょう。
自動化を進める場合でも、振込確定の前に人間の目での最終的なチェックは欠かさない方が賢明です。
ここでも一覧データを活用します。
一覧データの金額と、マスタ上から社員IDで引っぱってきた振込先口座情報を基にロボットがバンキングサイトに入力していきます。
この場合は1件ごとに処理を実行していきますが、
その一覧データをCSVファイル化し、バンキングサイトに取り込ませることも可能な場合が多いです。
いずれにせよロボットが自動的に処理を実行してくれるため、
人間の業務は最終的な入力内容の確認／振込手続内容の確定のみとなります。
振込が確定したら、申請時に計上した「未払金」の消込作業に入ります。
こちらも振込手続時と同じようにシステムから生成したCSVファイルを会計ソフト上に取り込ませます。
会計ソフト上で特殊な処理が必要な経費精算案件（金額の内訳入力や摘要欄への補足情報の入力など）が発生する場合は別ロジックの構築が必要です。
その際は、経費精算システム上の申請入力項目を改造して追加情報を入力させたり、
マスタ上で例外処理を実施する精算案件をマークしてロボットが判別できるようにしたりして、
通常のフローに組み込んでいくことになります。
一覧データを基に会計ソフト上で未払い金を消込みます。
費用科目と金額を抽出して、会計ソフトに反映させるのですが、
上記と同様に例外処理が発生する場合は、ロボットに別のロジックを付与します。
日頃RPA導入される企業様ヒアリングを行っていると、この仕訳の部分に例外処理が発生する事例が多いように感じられます。
事業部ごと、一事業単位ごとのようにそれぞれで収益計上を行っているためです。
その際は1件1件「どんな処理を行うのか」「どんなデータを別途取得しなければならないのか」「そのデータはどこから取得するのか」という観点から開発を進めていかなければなりません。
あまりにも特殊過ぎてその他大半の通常処理フローに組み込めない場合は、
無理にロボットに実行させるのではなく、割り切って人間の業務として残した方がいい場合もあります。
今回のコラムでは経理財務業務におけるRPA導入機会をご紹介しました。
このほかにも人事/総務部門などのバックオフィスでの活用が進んでいます。
RPA導入時まず検討するべきは、
という観点での業務内容の見直しです。
そのため開発の前段階として「業務の棚卸」を実施していくことになります。
今すぐロボット開発／導入は無理でも、一度自社の業務フローを可視化することは、業務効率化の第一歩です。
この際にぜひ一度検討してみてはいかがでしょうか。
弊社でもお見積もりいただけます。
2018.06.25
RPA元年と言われた2016年から現在まで、各社からさまざまなRPA製品が発売されています。
しかし、いろいろな製品がありすぎてどの製品が自社に向いているのかわからない、という方も多いのではないでしょうか。
そこで本日は、筆者が実際に利用したRPA6製品(BizRobo, UiPath, WinActor, Nice RTS, Axelute, ipaS)
の特徴とメリット・デメリットを整理してみたいと思います。
この記事を読んで、御社にピッタリのRPAを探してみてください。
RPAの元祖と言われるBizRobo。
日本RPA協会の理事長である大角氏が経営するRPAテクノロジーズ株式会社にて販売されており、国内での導入実績もNo.1です。
管理サーバと実行サーバを用意する必要があり、ライセンス費用も約60万円／月と高額なことから、
大規模利用向けの製品と言えます。
専用の開発ソフトでロボットを作成し、実行端末に配布して実行することが可能ですし、
管理サーバでエラーログを集中管理できるところも大規模利用に向いています。
操作対象の認識や制御には専用のコマンドが用意されているため、
他の端末での実行や画面のレイアウトの変更があっても、
問題なく作成したロボットを使用し続けることができます。
半面、専用のコマンドが用意されていないソフトはまったく操作することができないので、
導入を検討されている方は、
今の業務で使用しているソフトウェアがサポートされていることを確認してから導入するようにしましょう。
（サポートされるソフトウェアは随時追加されていますので、最新の情報を確認しましょう）
海外では実績がありますが、日本では新興勢力のUiPath。
2017年2月に日本法人ができたばかりですが、日本語マニュアルの整備や日本企業向けのサポート体制を整えてきています。
クライアント1台からの利用も可能ですし、サーバ型での利用も可能なため小規模～大規模まで幅広いニーズに対応できると思います。
料金は、ミニマムの構成で約60万円／年～とRPAツールの中では、
かなり低価格な部類になります。
ロボットの開発は操作の記録でも可能ですが、
プログラミング経験のまったくない業務ユーザだけで開発を行うには少し難しいかもしれません。
ただ、その分、高度で複雑な操作が可能なため、使いこなすことができればかなりの戦力になります。
プラグインも豊富で、GoogleやMicrosoft、AbbyyのOCR機能を導入しています。
プログラミング経験のある方や、システムベンダの協力が期待できる場合にはイチオシの製品です。
NTTデータが開発／販売を行っている、国産RPAのWinActor。
直観的な操作でロボットを作成することができ、業務ユーザの方だけでも十分に使うことが可能だと思います。
費用の方も、約90万円／年～と、こちらもRPAツールの中ではかなり低廉な価格設定になっています。
機能面では、
サーバ機能はないため、各クライアント端末にインストールして利用する形になりますが、
作成したロボットを他の端末にコピーして実行ライセンスだけを購入することで複数端末での実行も可能となります。
ただし、画像認識を行う場合やソフトウェアの起動から操作を行う場合には、
端末を変えるとロボットがうまく動かない場合があるので、
ロボットをコピーする場合にはなるべく端末の環境（解像度やソフトウェアのインストール先）が同じになるように心がけましょう。
ITFORが販売するRPAツール「NICE」。
開発元は海外のため、筆者が試した際にはマニュアルやガイドが英語しかありませんでした。
他のRPA製品とは少し異質で、イベントトリガという機能を有しています。
普通のRPAはロボットを任意のタイミングで実行し、大量の単純処理を行わせるバッチ型が多いのですが、
この機能では、あるルールを決めておくとルールの条件を満たしたタイミングで自動で処理を行う、というルールベースのリアルタイム処理ができます。
例えば、業務画面で顧客番号をクリックしたことをトリガに別のシステムで検索して検索結果を表示する、といったことが可能です。
費用は、アイティフォーの公式ホームページによると、
半自動ロボが35.5万円から、全自動ロボが350万円～とのことです。
デリバリーコンサルティングという日本のベンチャー企業が作成したＲＰＡツール。
画像認識とマウス・キーボード操作の組み合わせで自動操作を行います。
操作対象をオブジェクトとして認識するのではなく、画像のみで判別するため、
操作対象ソフトウェアの縛りはありませんが、確実性に若干難があるという印象です。
また、解像度の異なる端末にシナリオを配布したり、
ＯＳやソフトウェアのバージョンが変わると画像を取得しなおす必要がある点も、
再利用性という観点では弱点となるでしょう。
ライセンス料が月額払いという点が他の製品と異なるので、２～３か月限定で利用したいという形であれば
コストメリットがあるかもしれません。
なお、詳しい費用感は個別見積もりとなります。
富士通が自社のテストツールを一般向けに改修し、ＲＰＡツールとして販売を開始したもの。
実行時のエビデンスを自動で取得したり、手順書を自動で作成してくれる機能は他にない独自の機能ですが、
シナリオの編集機能がなく、記録した動作のままの実行しかできない点がＲＰＡとしてはまだまだ実用レベルではないといった印象でした。
ただし、逐次バージョンアップで機能追加をしていくとのことでしたので、今後の経過に期待したいと思います。
なお、こちらも費用は個別見積もり。
縦軸に利用規模、横軸に業務の複雑さを示すチャートで各製品の向いている業務の特性を表してみました。
管理サーバでの総合管理機能を有し、複数クライアントでの並列処理も可能なBizRoboが上部に位置しています。
BizRobo, UiPathはロボットの作成は難しめですが、その分複雑な処理が可能ということで右半面に位置しています。
NICE RTSは他のRPA製品と趣向が異なるので位置づけが難しいのですが、
管理サーバを有している点と、リアルタイム処理がメインなので、そこまで複雑な処理には向かないだろうということで中心やや左よりに位置しています。
WinActorは使い方は難しくないですが、使い方によっては複雑な処理も可能ということで左右の中心位置に、
ただし並列処理をする機能や複数クライアントへの配布機能があるわけではないので下部に位置しています。
AxeluteとipaSは使い方はシンプルですがその分あまり複雑なことはできず、
他の端末にシナリオを配布して並列実行するような使い方にも向かないので左下に位置しました。
RPAで効率化したいと検討している業務が、このチャートの軸でどの位置に該当するかを考えてみると製品選びの参考になると思います。
また、もし今回紹介した６製品以外をお考えの場合もこのチャートのような軸で比較をされると、
自社にピッタリの製品が見つかるかもしれません。
製品選定の際にはついつい、現時点での機能の多寡で優れている製品を選んでしまいがちです。
歴史の長い製品と新しい製品では、現時点での製品機能には当然大きな差があります。
しかし、新しい製品も随時バージョンアップし、他社製品の良い機能を取り入れていっているので、
数年経てば機能面での差はあまりなくなってくると考えます。
RPA製品は、製品間の互換性がほぼありません。
一度製品を使い始めたら他の製品に乗り換えようと思うと、すべてのシナリオを別の製品で作り直す必要があるので、
製品選定は慎重に、かつ長い目で見て有利な製品を選ぶことが大事です。
そのため、直近で利用想定のある業務を自動化するのに必須の機能が揃っていることを条件とし、
条件を満たす製品の中で自社の要員・業務に向いていそうな製品や使い勝手の良い製品を選んでおくことが、
長い目で見るといい結果に繋がるのではないかと思います。
RPAのツール選定、そのほかRPAでお悩みのことがあれば、
2018.06.22
今回の記事では、実際にRPAを導入することで現場の業務がどのように変化するかを具体例を交えてご説明したいと思います。
読者の方は、RPAが導入された後の業務がどのように変わると考えているでしょうか。
ロボットが完全に業務を独り立ちで実行し、もともとの業務担当の方が不要になり、
人の目によるチェックが全くない状況をイメージしているでしょうか。
確かにRPAに業務が置き換わることで、作業自体の質（速さと正確性）は増しますし、
ロボットが稼働できる時間は、人間が稼働できる時間と比べると大幅に増加します。
ところが、完全に業務から人が自由になるか、といったら実はそうではありません。
では、具体的な大手金融サービスのバックオフィスにおける業務のRPA化の実例を、
導入前と導入後の業務プロセスの変更に着目しながら記載していきたいと思います。
また、業務の変更前、変更後の記述のみではなく、
実際にどのようにRPAの導入が進むかのイメージが湧くように、
時系列を追って解説していきたいと思います。
RPAの導入の“いの一番”は業務選定になります。
そもそもRPA化に向いている業務とそうでない業務を見極める必要があります。
この記事の読者であれば、具体的にRPA化に向いている業務については一定以上の理解があると思いますので、
ポイントとなる点のみを強調します。
一番大事なのは、その業務をRPA化した場合に、短期間で費用対効果が上がるかという点です。
特にRPAのロボット開発を自社で行わない場合（外部ベンダーに委託する場合）、
開発にかかるコストの面で言えば、自社開発に比べ高くなる傾向があります。
また一度、RPA化を行ったとはいえ、ソフトウェアのライセンス料は毎年かかりますし、
業務プロセスを変更したことによるメンテナンス費用も当然発生します。
すなわち、これらの費用の支払いに見合った改善効果（時間短縮）がなければ、
基本的にRPAの導入は不要（コストに見合わない）ということになります。
ただし一方で、現場で働いている人たちには、RPA化が向いている業務などわからないという問題もあります。
この際には、一度実際にRPA化を行った業務のデモなどを見せて、
具体的なイメージ（実感）を持ってもらうことが非常に有効的だと考えられます。
今回のケースではこれらの条件を満たした業務として、
官公庁発表データの速報値取得（守秘義務の観点から特定のページをお伝えできませんが実際に発生している業務になります）という業務が選定されました。
この業務は、
「指定の時間になった時、インターネットに公開される政府発表の速報値をダウンロードして、指定のディレクトリにアップロードしておく」
という単純作業の業務です。
（毎日実行する必要があるが、指定の時間に出ていない場合もあるため、
公開されていない場合は何度も同じページにアクセスして確認する必要がある）
この業務が選定された理由は大きく2点ありました。
1 点目は、この業務が非常にシンプルな業務であって、
業務を遂行する上でアクセスの必要なシステムが一つのみであり、
開発にかかる工数が極小であるという点です。
2点目は、
「部署内におけるRPAを盛り上げるにあたって、
部署内で一番メジャーな業務（新人が必ず行うため、全員が経験する）であるため、
部署内でのRPA化に向けての業務洗い出しのきっかけづくりになる」
という点です。
それでは上記の業務が、業務ヒアリングおよびRPAの設計・開発を通じて、
具体的にどのようなプロセスに置き換わっていったのかを見ていきましょう。
まず最初に紹介するプロセスは、
現場担当の人が自分たちの業務を紹介したときの口頭での業務ステップになります。
上記の1から5のステップを聞いて、RPAの設計ができるでしょうか。
実はこれだけの情報ではRPAのロボットを作成することができません。
この情報をもとに更にヒアリングを実施し、ロボットの設計に落としていく必要があります。
例えば、上記の内容だけですと、「速報値のページがない場合にどうすればよいのか」であるとか、
「当日の速報値を保存するときの内容はどのような内容か（フォーマットは？）」といった点がわからず、
RPAのロボットを設計するための基本的な情報が足りません。
また、実際にヒアリングを進めていくと、
「ファイルサーバーへアクセスするには、特定のツール（ファイルサーバアクセスツール）が事前に起動されている必要がある」とか、
「インターネットにアクセスする際にはCitrixと呼ばれる仮想ブラウザツールを利用する必要がある」といった、
クライアント環境に起因した特別な条件が出てきました。
ヒアリングを実施した後の現在の業務フローは以下のようになりました。
いかがでしょう。違いを感じることができたでしょうか。
業務担当へのヒアリングにより、そもそもいつロボットが起動するべきなのかに加えて、
PCでの操作内容が明確になったことで、RPAのロボットに覚えさせることができる粒度まで業務プロセスを具体的にすることができました。
さて、いよいよ次はこれをRPA化後にどのようなプロセスになったのかを書き出したいと思います。
上記が最終的にRPA化を行った際の業務のプロセスです。
実際には、1-10まではロボットが実行してくれるため、人間の介在は不要となり、
人間が政府の速報値のページにアクセスをするという手間は完全になくなります。
ところが、完全にロボットだけで自立をさせることはできません。
アクセス先のページががダウンしているようなこともあれば、ファイルサーバへのアクセスが失敗することもあります。
そういったことも含めて、RPA化を導入した後であってもロボットが正常に動作していること、
または正常に動作したことを、やはり最後は人間が確認できるようにしていることが大事になります。
今回のケースではロボットが処理した結果（失敗・成功）をメールで通知するという手段でロボットが正常に動作したのかどうかを確認するという設計になりましたが、
「処理結果をファイルに残す」「処理結果を紙に印刷させる」といった別の手段で人間が業務完了を確認できるようにするということも考えられる方法です。
今回の記事はいかがでしたでしょうか。
「RPA化する=人間が不要」とならないと冒頭で宣言したことが、
具体例から感じ取ることができたでしょうか。
この記事を読んだ皆様が、この記事を通じて業務のRPA化に対して、より理解を深めていただければ幸いです。
2018.06.21
オブジェクト指向はプログラミングをする際にとても大切な要素の一つです。
オブジェクト指向は難しくてつまずいてしまったという意見をよく見かけますが、
おおまかに把握することはそんなに難しいことではありません。
UiPathのような初心者にも開発できるようなアプリケーションを使用する際にはこのような概念は必要ないように思うかもしれません。
ですが、実際はUiPathなどでメソッドやクラスを使用する際に理解しておくと調べていく中でやりやすくなると思います。
知っておいて損なことはないと思うのでしっかりと理解しておきましょう。
これで少しだけメソッドやクラスというのを理解していただければなと思います。
早速学びたいのですが、そもそもオブジェクトとは何なのでしょうか。
オブジェクトというのは日本語に直してみると「もの、こと」です。
今回用いるオブジェクトもこの「もの、こと」のことを表しています。
よくわからないなと思うかもしれませんが、オブジェクトとはそのような、もの自体のことなのです。
例えば、「そこのリンゴ」「マイクの自家用ジェット機」「ジェシカの写真」「私のパソコン」などの、
世の中の無限にある様々な「もの、こと」です。
ここで少しだけ注意しないといけないことは、「リンゴ」はオブジェクトとは言いにくいということです。
正確には「このリンゴ」のようになります。
ほんの少しの違いなのですがこの指示語が入るか入らないかで変わってくるので注意しておいてください。
少しだけでもオブジェクトについて理解できたでしょうか。
このオブジェクトを使ってこれから話をしていきます。
まだ完全に理解できていなくてもこれから話していく中でオブジェクトが何回か出てくるので大丈夫です。
オブジェクトを少しだけ理解したところで軽くオブジェクト指向について説明しておきます。
オブジェクト指向ってなんか難しい、というように感じる方が多いのは事実です。
これはオブジェクト指向が概念であるからです。
初めから具体的にオブジェクト指向を100%理解しようとすると詰まってしまいます。
ですので初めは雰囲気だけ理解しておいておけばいいと思います。
オブジェクト指向を用いる利点についてですが、実際の現実のように考えられることができる点にあります。
現実の我々は車を運転するときにどのようにタイヤが動いていて、エンジンが動いているかなどを意識しているでしょうか。
現実の私たちは、車を運転する際に車体の中の制御などのことを考えずにをアクセルを踏むことで直進しているのです。
オブジェクト指向はこれに似ています。
もっと簡単に考えるためにゲームのようにして考えてみましょう。
アクセルをAボタン。ブレーキをBボタンのようにして考えます。
では、マイクさんが自分の自動車を動かす場合を考えましょう。
マイクさんはAボタンを押すことで自分の車を発進させることができます。
マイクさんはBボタンを押すことでその自分の車を停車させることができます。
なにを当たり前のことを言っているのかと思うかもしれませんが、本題はここからです。
では、マイクさんが友達のジェシカさんの車を運転しようとする時はどうなるでしょうか。
皆さんも一度考えてみてください。
マイクさんはAボタンを押すことでジェシカさんの車を発進させることができて、
Bボタンを押すことでそのジェシカさんの車を停車させることができます。
またもや当たり前のことだと思ったかもしれません。
それは当然です。これが実世界のふるまいだからです。
これをプログラミングに導入したのがオブジェクト指向です。
プログラムを書くときに、いちいち車が変わるごとに新しいコードを書いていたのでは大変なことになります。
何万種類の車ごとに発進と停車の操作を書くことになるからです。
すべての場合について書くのではなくて、元から「車」というものを作ってしまった方が楽そうですね。
「車」を動かすときには、
Aボタンを押すと発進し、Bボタンを押すと停車する。
のように決めておくとどの車かどうかを考えなくても直感的に操作することができます。
つまり、オブジェクトがどのようなものであるかをいちいち確認しなくてもいいということです。
マイクさんは、「車」である「もの」に対してはある決まった操作をすることで発進や停車を簡単にすることができるということです。
ここからはそれらをどのように実装していくのか見ていきます。
プロパティとは日本語に訳すと「属性」です。
他のものではアトリビュートと書いてあるものもあるかもしれませんが今回はプロパティを使います。
簡単に言うとプロパティとはそれが構成されている部品のような感覚です。
車でいえば、「タイヤ」「エンジン」「バックミラー」のようなものです。
それだけではなくて、車体の色や走行距離、残りのガソリン量などもプロパティです。
どちらかと言うと後者の方がオブジェクト（その車）の特徴を表しているのでわかりやすいかなと思います。
このプロパティはその時々でいろいろな形に変化します。
走行距離などは走っていく中でもちろん更新されていきますし、ガソリンも減っていきます。
車体の色なども後々塗装することで変化することもありうるものです。
ですので変数を使って、
「車体の色」「走行距離」「ガソリンの量」
のようなものを「車」というクラスの中にプロパティとして定義しておきます。
（クラスは後ほど説明しますが、今は車というものの中にいれておく感覚でいいと思います。）
メソッドとは簡単に言うと「操作」のことです。
先ほどに述べた中だと、「車」の発進や停車というものが含まれます。
メソッドはUiPathにもあるので使ったことがある人も多いのではないでしょうか。
メソッドはそれぞれどんな操作をするかを表したものです。
オブジェクトの振る舞いとも言えるのではないでしょうか。
メソッドが作用するのはなにもオブジェクトだけではありません。
この後説明するクラスに作用させることでさらにオブジェクト指向を体現できることができます。
ここが先ほど説明したオブジェクトの中身を毎回確認しなくてもいいことにつながります。
最後に紹介するのがクラスです。
クラスは今までのプロパティやメソッドなどをいれておく箱のようなものです。
オブジェクトの集合体とも言うことができます。
クラスの中には属性のプロパティや操作のメソッドなどが入っています。
このクラスというものには継承とよばれる概念があります。
また車を例を考えてみましょう。
車の中には普通の自動車だけではなくて、トラックやタクシーなども含まれます。
他にもキャンピングカーやバスなどもありますよね。
この時に、新しくトラックやタクシーのクラスを一から作るとなると同じことを何度も行うことになります。
なぜかと言うと、発進や停車というメソッドをまた新しくそれぞれのクラスの中につくることになるからです。
このような場合に継承というものを使います。
一般的に「トラック」「タクシー」「キャンピングカー」「バス」などを総称して「車」と呼びます。
なので「トラック」「タクシー」「キャンピングカー」「バス」などは「車」の機能を持っているとも言えます。
よって「車」の機能をそのまま「トラック」「タクシー」「キャンピングカー」「バス」などに搭載できればいいのです。
これが継承です。
ある概念よりも上位に位置する概念を引き継ぐことで、同じ機能をそのまま使えるということです。
とても実世界に似ているので大人数などでコードを書くときには役に立つことになります。
ここまでオブジェクト指向について見てきましたが、これによってクラスやメソッドの位置関係が理解できたと思います。
この程度の知識でも、今後UiPathのようなアプリケーションを使用するときに使いやすくなると思います。
もっとオブジェクト指向について学びたい方は一度自分でコードを書いてみることをおすすめします。
自分でコードを書くことでどのような構成になっているのか深く理解することができると思います。
2018.06.20
前回の中小企業のRPAにそれほどテックに詳しくないがテックの渦中に入った実業ベースの中小企業社長の考えるRPA第二弾です。
■前回記事
私自身がエンジニアではなく、営業サイド出身であることから、
非テック系企業の社長や担当者へRPAを説明するときに、イメージしてもらうことを優先に、
随分とデフォルメした表現を使ってしまうことが多々あります。
その中でも頻繁に使ってしまう表現のひとつがこれ。
「AIはお分かりですよね。
ディープラーニングで学び進化していく、AIが自分で考えるロボットだとしたら、
RPAは考えないロボット。
ただし人間の単純作業を地道に正確に24時間ずっとやることができるんですよ。」
まあAIも全て自分で考える訳ではないとか、
いろいろと詳しいことを言うとこんがらがるので置いておいて、
ただAIとの比較においてRPAを語るのは意外と理解していただけるものだと思っています。
でも、単なる営業トークのテクニックではなく、
そもそももっと本源的なレベルでAIとRPAを比べてみると、どうなんだろう。
そんな素朴な疑問を少し掘り下げてみたいと思います。
３年毎に登場するビジネスのトレンドワード。
コンサルタントは毎回真剣ですが、導入する中小企業側からすれば、
ひとつひとつ真剣に拾っていたら、それこそケツの毛を全部抜かれてしまうことにもなりかねません。
そんな中、テクノロジーをまず二つに分けて真剣に取り組むかどうかを考えるやり方をおすすめしています。
それは、成長の為のテクノロジーなのか、効率の為のテクノロジーなのか？
成長の為のテクノロジー、それを私はブレークスルーテクノロジーと呼び、
効率の為のテクノロジーを業務改善テクノロジーと呼んでいます。
その意味で、AIは間違いなくビジネスブレークスルーを導くものだと思っています。
もう逆戻りすることが出来ないテクノロジー。少なくともこれは皆の共通の見解でしょう。
ただし、そちらのテクノロジーはその性質故にブレークスルー前に我々凡人がその後を予見するのが難しいということ。
毎日のようにAIについての記事や企業リリースが出ていますが、
それらのどれだけのものが本質なのか現段階では正直不明です。
まさに今は、それまで様々な人々が試行錯誤していたにも関わらず、
アイフォンの登場というブレークスルーまでスマホというのが待たなければいけなかったのと同じような状況なのでしょうか。
この手の爆発的な成長を社会へもたらすテクノロジーは、浸透するまで、
もしくは本当の意味での実用に耐えられるようになるまでには長い時間を要するものです。
翻ってもうひとつの効率の為のテクノロジー。
ビジネスの業務改善を実現する技術はそれこそ3年毎にまわってくるハレー彗星のようなもの。
現れては騒ぎ、そして忘れ、また別の名で現れる。
ビジネストレンドワードの99%はこちらに属します。
亡霊のように何度も現れますが、基本的に実現できることは一緒。
業務を改善するという代物です。
先にケツの毛を抜かれるというように表現しましたが、
それこそこの業務改善テクノロジーは自社の環境にあわせて付き合っていかなければ、
名前を変えた同じものを毎度購入させられる羽目になりかねません。
（大企業のようにそれも含めた大きな日本丸ビオトープの中で導入する側、される側、
それに関連する側と一緒に大いなる歴史を刻んでいるのなら別ですが）
またブレークスルーテクノロジーについては、
絶対に関わっていかねばならないのでしょうが、そのタイミングが必要です。
ブレークスルー前に見越して導入したり、何か開発したりしてもほとんどの場合ムダになることを覚悟のうえで。
じゃあ、RPAはこの二つの内どちらに属するテクノロジーなのだろうか？
成長か、はたまた効率か？
RPAは成長の為のテクノロジー。ブレークスルーを導くものなのか？
それとも、効率の為のテクノロジー。企業の業務改善を促すものなのか？
私の認識は、70%は「効率」。ただもう30%は「もしかしたら」という期待感です。
まず、RPAは業務効率技術であるという認識は、私以外の多くの人にとっても大勢を締めるでしょう。
単純作業を人間の代わりにやってくれる。
作業効率がアップする。
人不足に対応したり、人の削減が可能となったり、
または人が本来やるべき大切な仕事に集中出来たり。
それはまさに効率という言葉で示されることばかり。
ただそんな中で、私がはじめてRPAの導入に携わった時の奇妙な感触を紹介します。
そのプロジェクトは経理業務の一部をRPA化するという至って普通な案件だった。
営業として、それも導入のではなくキッカケ作りの営業の立場でRPAに向き合ってきた私にとっては、
実際にRPAを目の当たりにする機会でした。
金融機関のシステムをRPAで動かすにあたって、
エトセトラエトセトラ・・・
えっ、それって人と同じじゃん。
というのが、私が抱いた率直な感触であり、それはなんだか違和感に近いものでした。
結局、RPAって単に人より処理能力が高くて、
寝なくて24時間働けて、決められた範囲内ではミスしない、
でも融通の利かない労働力。
それは比喩ではなく人の延長線上にいる何かのような感じがしました。
そしてこの違和感こそが、ブレークスルーを導くのではという30%の「もしかして」です。
AIのような人を超えるものはない。
だが人と同じことを、人より正確に、人より早く、人より長く出来る。
それも人よりも安価に。しかも開発も比較的簡単に。
単純だけど、これにはとてつもないパワーがあると思う。
それと同時に思うのは、やはりRPAは構えて捉える技術ではないと思うということ。
たくさんの中小企業が気軽に導入するべき技術であるし、
またそのためには様々な用途に使えるよう導入コストをどんどん下げていく必要性がある。
その時にこそ、RPAが単なる業務改善による効率化だけでなく、
ブレークスルーにつながる技術となるのではと思います。
最後に、ブレークスルーの大いなる可能性を考えるにあたり、
AIをRPAへ掛け合わせることによる飛躍について少し。
繰り返しになりますが、RPA（Robotic Process Automation：ロボットによる業務自動化技術）は、
定型的な作業をロボットにより自動化することができます。
それにより、業務の飛躍的な効率化や人件費削減等、
常に人が出来る作業の補完としての活用を考えられてきています。
それに対して、AI（Artificial Intelligence：人工知能）は非定型業務において、
今はまだ人の設計の範囲内ではありますが、ディープラーニングなど自ら進化することで強みを発揮します。
この二つを掛け合わせることで、RPAがこれまで考えられていた範囲を大きく超え、
高度な知的処理を含めて対応が可能になると最近考えられています。
ここに至れば、それこそブレークスルーとか技術改善とかいうものを合わせた次のステージに進めるのでは。
しかもその未来はもう目の前に来ていると思います。
はたして、RPAが単なるビジネストレンドとして、3年後には消えてしまうのか。
（もちろん消えたとしても同じ概念は別の言葉として出現しているのでしょうが。。）
それとも、より高次な、私たち中小企業にとって成長への強い味方となるのでしょうか。
私は後者であるとやはり信じたいです。
2018.06.19
今回はEXCEL（マクロ）とRPAの違いについて説明するとともに、
EXCEL（マクロ）での業務をRPAにすることによるメリット、
実例やさらにRPAとエクセル（マクロ）の組み合わせについてご紹介したいと思います。
EXCEL自体は多くの方が使われていると思いますが、その中にマクロと呼ばれる機能が備わっています。
マクロとは、プログラムの複数の命令を順番通りに実行するものと考えてもらえればいいかと思います。
つまり、EXCELのマクロを活用すると、EXCEL内の定型作業（繰り返される作業）を自動で実施することができます。
例えば、EXCELに記入した売上データを週次でレポート化するなど、ある曜日だけに抽出するなどです。
実はRPAについても、同様にプログラムを用いて自動化をします（ただマクロより比較的簡単に使用できる）。
つまり、プログラムのスキルが必要になります。
しかし、EXCEL（マクロ）とRPAで異なるのは、自動化できる範囲です。
マクロはEXCEL内のデータを活用して自動化しますが、
RPAについてはブラウザ画面の情報収集も自動化できるため、
PCで操作する大方の動きをあらかじめ決めておけば、自動化できるようになります。
ブラウザ画面で情報収集できるものとして参考に以下の記事を読んで頂ければと思います。
【Webマーケティングの効率化～RPAを活用して～】
他には、経費精算のフォーマットをRPAで行いますと、乗車駅や降車駅のリストがあれば、自動でルート検索をして金額まで記入してくれます。
前述にて少々申しましたが、EXCEL（マクロ）にてプログラムするスキルの方がRPAのスキルよりも難しいと思います。
また、意外にマクロ（VBA）のスキルをもつ人は少なく、その人が辞めてしまうとEXCEL（マクロ）の修正が難しくなります。
それに比べてRPAは、アイコンのようなものを用いて自動でプログラムされるため、比較的専門知識がなくても簡単に自動化ができます。
このようにマクロを用いていたとしても、RPAにするメリットがあります。
実際に三井住友海上はEXCEL（マクロ）を導入したのち、RPAを活用しました。
（出所：IT media「EXCELマクロで年間35万時間を削減、それでも三井住友海上がRPAを導入した理由：
http://www.itmedia.co.jp/enterprise/articles/1801/22/news008.html」）
もともと、保険契約条件をEXCELに入力するだけで、Webの保険料計算システムで再計算できるマクロを作成していました。
EXCEL上でボタンをクリックすると、ブラウザが立ち上がり、
自動でEXCELに記載のある内容をWebブラウザ上の保険計算システムに埋め込むというものです。
このマクロによって1件処理するのに1時間かかっていた業務が、数分で終わるようになりました。
その結果年間35万時間を削減でき、現在では300以上の業務に反映されています。
しかしながら、幾つかの課題が浮き彫りになりました。
例えばひとつ例を挙げると、まずVBA（マクロ）による対応範囲の制限です。
その他システムと連動させる場合、EXCELと親和性の低いブラウザやオフラインソフトとの組み合わせが難しく、自動化が困難です。
また、このような新たなサービスでありがちな、
賛同者やニーズが一部（わかりやすい業務、イメージしやすい業務）に偏っており、
全体的な効率化を図りづらいという課題もありました。
そこでアクセンチュアの提案を受け、RPA製品ではなく、
まず作業ログの分析ツール（40人のPCに操作ログツールを入れる）を導入しました。
2ヶ月ほどログの収集を行ったところ、全業務時間の18%が自動化できると判明しました。
この結果、VBAに親和性のない操作に対してRPAを導入し、さらなる業務の自動化を図りました。
いきなりRPAを導入すると、今まで業務をEXCEL（マクロ）で行っていた方に戸惑いが生じます。
そのため、RPAとEXCEL（マクロ）との組み合わせも実務では行われています。
例えば、販売管理システムに登録されている出荷指示データをシステムが定期的にCSVファイルに出力します。
一方で、販売管理システムには登録が難しい細かな出荷付帯情報がある場合に、
担当者が別途Excelファイルに付帯情報を記載。
この２つのファイルをExcel VBAマクロで結合し出荷指示書を作成し出荷担当者にメールを配信しています。
元々は2つのファイルを目視で確認していました。
RPAで完全自動化も出来たものの、使い慣れたEXCELフォーマットを残し、
組み合わせすることとなりました。
（出所：https://www.infoteria.com/jp/warp/blog/aug/20180416/aug_tokyo_30717.html）
基本的にはEXCEL（マクロ）で完結する部分はEXCELで問題ないのですが、
EXCEL以外の要素に対して、EXCELのように使えるのがRPAです。
RPAで自動化した業務を最終的にEXCEL（マクロ）の関数を用いて最終化するような事例もあります。
（RPAはEXCELのように細かい関数には弱いため）
他のRPA導入事例については、ユニリーバ・ジャパン・カスタマーマーケティングがあります。
（出所：http://rpa-technologies.com/about/#07-05）
課題としては、各製品に興味を持ってブランドサイトを訪れたユーザーを自社運営による比較ポータルサイトを経由して、
スムーズに販売パートナーであるECサイトへ誘導するというものです。
例えば、「ECサイトの在庫、価格、ポイント還元率などの情報を取得し、適切に表示する」
という作業に必要なタスク項目は、おおよそ3,000項目以上。
3人が24時間働き続けても、1週間以上はかかる作業になります。
システム導入も検討されましたが、初期費用や運用費が高く、
運用中も想定外支出が発生することからRPA導入をされました。
RPAによるソリューリョンとしては、既存のブランドサイト内に製品価格を比較するポータプルサイトを新設。
オンライン上のさまざまなチャネルで販売されている自社製品に関する情報の取得をRPA化してリアルタイムでの表示ができるようになりました。
その結果、比較ポータルサイト上で価格や送料、ポイントといった重要な消費者ニーズを即時に把握できるようになり、
自社製品の販売動向を把握し、効果的な戦略を図れるようになりました。
また、営業方針として掲げる店内の商品割合を改善・管理するための社内ツールとして、
比較ポータルサイトを利用できるようになりました。
さらにユーザービリティが向上し、ブランドサイトからECサイトへのトラフィックが上昇した、
多数ある販売パートナーのECサイトへ効果的に誘導できるようになり、
各社の売上向上に貢献することができるようになりました。
例をみると、RPAを導入することが非常に簡単に見えますが、注意点もあります。
それは、三井住友海上の例でも同じですが、ツール作成にあたり細かいヒアリングを実施していることです。
特にバックグラウンドの業務は属人化されていることや定型化されていないことがあります。
マニュアルがあっても実態とは多少かけ離れていたりなど、
ツール開発する前の業務の見える化や標準化といった作業が必要になるわけです。
もしRPAの導入を検討している場合は、
一度業務の標準化、見える化がなされているかどうかを確認し、
場合によっては業務コンサル会社などを活用して業務を見直す方が良いと思います。
EXCELのマクロを活用している方はぜひRPA導入の検討をして頂ければと思いますが、
それを機会にそもそも業務について定型化されているかどうか、
誰もが同じ認識を持っているかどうかなどを一度振り返ってから、
導入を検討するのが良いと思います。
弊社ではRPAの開発だけではなく、業務フローの見える化や標準化を行っています。
ぜひ気軽にお問い合わせください。
■お問い合わせ
https://rpa-biz.com/?page_id=88
2018.06.18
先日、東京ビッグサイトで行われた「AＩ・業務自動化 展【春】」に行ってきました。
「ＡＩ・業務自動化 展【春】」は、ＡＩ（人工知能）技術・製品や、業務自動化ソリューションが一堂に出展する専門展で、最新技術の動向を注目する人で賑わっていました。
そんな数ある自動化ソリューションの中で、私が特に注目したのがAI-OCR。
今回のコラムでは、OCRの導入を検討されている方のために、AI-OCRの概要からOCRベンダー動向について紹介いたします。
OCR（Optical Character Recognition/Reader）とは、手書きや印字された文字（活字）を、コンピュータが利用できるデジタルの文字コードに変換する技術です。
簡単に言うと、紙やPDF等の文字情報を電子化する技術です。
OCRが文字の読み取り～データベースへの書き込みまで行うため、OCRを導入することによって今まで手間だった入力作業の手間が削減できる、といったメリットがあります。
また、業務効率化の観点から現在注目されているRPA（Robotic Process Automation）との親和性が高く、働き方改革の一環としての役割を担うことを大いに期待されています。
また、最近のOCRはAI技術を取り入れたOCR、いわゆる「AI-OCR」が話題になっています。
ここでは、従来のOCRとAI-OCRについてそれぞれ異なる点を紹介します。
OCRを導入した際、従来のOCRでは「請求金額」や「住所」等のような帳票上の項目ごとに手動で認識させたい文字の位置（座標）を設定する必要があります。
一方、AI-OCRの場合、そのような面倒な設定は必要なく、認識させたい項目に関するキーワードを登録することで簡単に使用を開始することができるため、
比較的導入のハードルが低いと言えます（ベンダーによっては初期設定としてAIの自動学習を導入前に行うことにより識字率を担保するところもあります）。
従来のOCRは非定型のフォーマットには対応していないことが多く、OCRで帳票上の文字を認識させる前にあらかじめどのフォーマットで認識させるか指定する必要があります。
そのため、様々なフォーマットをOCRで認識させたい場合、その都度設定が必要になるため、非常に手間がかかります。
一方、AI-OCRはAI技術によって自動でフォーマットの特定が可能です。
特に多店舗展開している企業等は請求書ひとつとってもフォーマットがサプライヤーによって異なるため、
自動でフォーマット認識させることはOCRの導入を検討する際の必須条件であると言えるでしょう。
残念ながら、OCRは帳票の画質等にかなり影響されやすく、完璧に文字を認識させることは出来ません。
これは従来のOCRでもAI-OCRでも同じです。
そのため、誤って認識した文字については、結果を出力する前に手入力で訂正する必要があります。
従来のOCRでは、訂正した文字を手動で辞書登録することにより、次回以降同じ形の文字を認識させる際のインプットになります。
AI-OCRでは、文字の訂正自体は手動で行いますが、その後の学習の部分はAIが自動で行います。
上記の通り、従来のOCRと比較すると、AI-OCRは機能面で優れていることがわかっていただけたかと思いますが、
導入を検討するにあたって価格やトライアルの有無についても考慮する必要があります。
AI-OCRはそれなりにコストがかかる一方、フォーマットや文字種（手書き文字や活字等）によっても認識結果が大きく異なる為、
導入の検討材料としてトライアルの申込をお勧めします。
トライアルの実施に当たっては、相当数のサンプルが必要なため、一度ベンダーに相談してみると良いでしょう。
最後に、ここでAI-OCRを開発・提供している主要OCRベンダーをご紹介します。
コージェントラボは東京の代官山に本社を置く、最先端の人工知能の研究・開発と関連ソリューションサービスを提供するAIベンチャー企業です。
AIの知見を持つエンジニアの確保が難しい現在でも、世界中からAIを専門とするメンバーが集結し、
高度な技術力とビジネス力でAIに関する製品を開発しています。
そんなコージェントラボが開発したOCR「Tegaki」は、その名の通り手書き文字の認識に特化しています。
手書き文字は、活字文字に比べOCRでの自動認識が特に難しいのですが、データを処理・学習する独自のAI技術によって99.22％という高い精度で帳票上の文字のデータ化ができます。
野村総研やトッパン・フォームズ等の大手企業への導入実績があり、メディアにも多く掲載され現在注目を集めています。
また、今年の1月にはソフトバンクとRPA分野における業務提携契約を締結し、
国内企業の膨大な書類処理業務の効率化を目指し、新たなソリューションの共同開発を目指しています。
Tegakiは平仮名、片仮名、漢字、数字、アルファベット、記号等さまざまな手書き文字を認識することができるほか、
要望に合わせて多言語や業界用語への拡張対応も可能のようです。
導入費用は公表されていないのですが、無料でトライアルも行っているため、
導入前にどの程度手書き文字を認識できるか試した後に見積りを依頼してみると良いでしょう。
シナモンはシンガポールに本社を置き、
機械学習やディープラーニングを活用した人工知能に関連する製品やコンサルティングを提供しているスタートアップです。
東南アジアで AI 技術者を雇用するために、
ベトナムの大学トップ3校からポテンシャルの高い学生を集め、AI 技術者を養成しています。
今年の2月には、MTパートナーズ、マネックスグループのマネックスエジソン、ベクトル、RPAホールディングス、
および島田亨氏ら複数の個人投資家を引受先とした第三者割当増資を実施し、
1億5千万円の資金調達を行いました。
この資金調達を受けて、シナモンはより高度な技術ときめ細かいサービスを提供するための組織体制強化やAI製品の基盤技術の強化等を実施していくようです。
そんなシナモンが開発・提供するOCR「Flax Scanner」は、
さまざまなビジネス文書から情報を抜き出してデータベース化するためのOCRツールで、
構造化されていない社内文書やEメール文等も、独自のAI技術で自動でデータ化することができます。
PDF、Wordファイル、印字・手書きの紙文書などさまざまなフォーマットに対応しており、
手書き文字の読み取りに関しては、ニューラルネットワークと呼ばれるAI技術を用い、
マシンにディープラーニングをさせる事によって最終的には99%以上の精度で正確な読み取りを実現しています。
Flax Scannerは、現在金融や保険業界を中心に導入されておりますが、導入社数は「数社」程度とのことです。
Flax Scannerの導入費用は400万円～で、ランニングコストは月額10万円～とのこと。トライアルは30万円～可能です（要問合せ）。
AI Insideは、東京に本社を置くソフトウェア開発・人工知能事業を行う企業です。
今年4月には、BPR（※1）に関するコンサルティングのノウハウを持つパソナと販売パートナーシップ契約を締結し、
業務改⾰に取り組む企業に更なる付加価値を提供することを目指しています。
AI Insideが開発・提供するOCR「DX Suite」は、独自のAI技術を導入しており、
様々なユーザーが記入する手書き文字を高精度でデジタルデータ化します。
帳票内の読み取りたい箇所をドラッグ&ドロップで指定することで、アウトプット形式を設定します。
一度こちらの設定を行う事で、同一帳票に対し、
読み取り位置ズレなどを自動で認識・修正することが可能です。
更に、DX Suiteは、認識したデータをそのままアウトプットするだけでなく、ドキュメントの設定に従って、人の目でチェックするための業務フローを設定できるシステムも完備しています。
導入費用は150万円から。導入までの期間は最短3日です。
（※1） ビジネスプロセス・リエンジニアリング（Business Process Re-engineering、BPR）とは、
企業活動の目標（売上、収益率など）を達成するために、既存の業務内容や業務フロー、組織構造、ビジネスルールを全面的に見直し、
再設計（リエンジニアリング）すること。
インフォディオは、東京に本社を置く、生命保険に関するソフトウェアやアプリケーション開発等を主に行う企業です。
インフォディオが開発・提供する「スマートOCR」は、独自のディープラーニングOCRエンジンにより、
請求書や診断書などの非定型の文書のデータ化を実現します。
AIの画像復元学習技術を使用して、帳票上のノイズ除去、網掛け文字処理、反転文字処理、塗りつぶし文字処理、
罫線・点線処理といったOCR変換の前処理を行います。
ホームページには導入費用に関する情報がなく、一度見積が必要のようです。
導入前のサンプル検証があり、ここでOCRの精度を試すことができます。
ABBYYは、世界各国に拠点を置く、ドキュメント認識サービスを提供するリーダー企業です。
ABBYYは去年8月に、PwCコンサルティング合同会社と業務提携し、
AI-OCR分野でのコンサルティングおよびソリューションを共同で提供を開始。
そのほか、今年2月にトッパン・フォームズ株式会社と販売代理店契約を結んだり、
4月には株式会社NSDとAI-OCRに関する認定パートナー契約を締結したりと、
積極的な動きを見せています。
そんなABBYYが提供するOCR「FlexiCapture」は、
請求書、注文書、会計伝票、船荷証券等の、複雑なレイアウトの紙書類やPDFファイルであっても、
柔軟にテキスト変換する最先端テクノロジーを有します。
FlexiCaptureに内蔵しているエンジンは、文書を分離し文書の種類を自動で特定します。
また、ページが混ざった状態から1ページおよび複数ページの文書を組み立てることができるため、
複雑さにかかわらずレイアウトが変化する文書を自動分類できます。
また、導入費用に関しては、初期費用が160万円（年間6万ページ以下の場合）+年間保守費用：32万円（初期費用の20%）です。無料でトライアル版の使用ができます（要問合せ）。
アライズイノベーションは、2016年7月に設立された、東京に本社を置く企業で、
人材不足やノウハウ継承の課題を解決させるための『企業向けAIサービス（Enterprise AI）』、
システム開発において高い生産性を実現するための『超高速開発』、
そしてそれらのサービスの基盤となる『クラウド』の三つを専業としています（企業Webサイトより）。
アライズイノベーションが有するOCR「AIRead」は、FAXや書類等の文字をAIで文字認識するOCRソリューションで、
ビジネスや業務で発生する注文書や請求書等の文字（活字・手書き文字）の自動認識において、
AIによるディープラーニングの技術を取り入れており、
誤認識した文字を学習して認識精度を飛躍的に向上させることができます。
さらに、人が書く文字の癖や書類のレイアウトも併せて学習することが可能なため、
様々な利用シーンで企業が求める業務効率化や労働生産性の向上を実現します。
利用パターンは買取型と利用型の2種類あり、導入費用はそれぞれ異なります。
トライアルはありませんが、有料PoCで認識率を試すことが可能です（20万円＋5万円／帳票種類）。
いかがでしたでしょうか。
今回はOCRの概要から、AI-OCRの特徴、主要ベンダーの動向をご紹介させていただきました。
ここ最近AI-OCRが注目されていますが、文字認識の観点で言うと、
OCRはまだまだ発展途上と言えます。
引き続きOCRの技術動向に目を向け、最新情報をお届けしたいと思います。
OCRも含めたRPAソリューションについては、ぜひ弊社にお問い合わせください。
2019年5月に東京ビッグサイトで開催される展示会への出展が決定！！
RPA導入に関する無料相談会を実施いたします。無料相談会のご予約はこちらまで。
2018.06.15
ドイツが2011年『Industry 4.0』を提唱して以降、諸外国や我が国日本においても、『第四次産業革命』というワードをよく目にするようになりました。
今回は、この『第四次産業革命』について解説したいと思います。
第四次産業革命を語る前に、これまでの産業革命について振り返ってみます。
第一次産業革命の大きな特徴は、ニューコメンが発明した「蒸気機関」の登場です。
この革命の発端となったイギリスでは、飛び杼（flying shuttle）やミュール紡績機などの発明により綿織物工業における技術革新がなされ、1785年にエドモンド・カートライトが蒸気機関を動力とした力織機を発明したことで生産速度が大幅に上がりました。
その後も問題点の改良が各地で行われ続けた結果、原材料と製品の輸送を安価で迅速におこなうためにと、交通面も進化しました。蒸気機関の技術を輸送手段に使用する試みがなされるようになり、蒸気船や蒸気機関車が実用化されたのです。
その後、イギリスが1825年に機械輸出を解禁したことでその他の国々にも産業革命が伝播し、ベルギー、フランス、アメリカ、ドイツへと続いていきました。
第二次産業革命では化学、電気、石油および鉄鋼の分野で技術革新が進み、ドイツやアメリカで様々な発明が生まれました。
ガソリンエンジンが発明されて飛行機や自動車の実用化が進み、フォードやGMなどの自動車企業が組立ラインだけではなく、材料から完成車まで全工程の垂直統合を図り、「大量生産」を可能にしました。
また、アメリカではトーマス・アルバ・エジソン、ニコラ・テスラらによって送電技術の発明がなされ、産業として発展していきます。
日本の高度経済成長期と同時期に起きたこの革命は「デジタル革命」とも言われています。
商用コンピューターの普及が始まり、産業用ロボットの普及と相まって生産ラインの自動化が進められていきました。
同時に、インターネットが普及したことでAppleやGoogle、FacebookなどのIT企業が成長を遂げました。
これらの産業革命に続く新たな産業革命として、まさに今始まっているのが「第四次産業革命」なのです。
第四次産業革命を語るにあたって外せないキーワードは２つあります。それが、「IoT」と「AI」です。
「IoT」つまりInternet of Thingsとは、すべてのモノはインターネットにつながり、これによってさまざまな産業構造の変化をもたらします。
例えば、自動車がインターネットに繋がれば道路の込み具合や工事の有無などのデータが収集可能になり、ウェアラブル端末が普及すれば移動距離や健康状態などのデータが収集可能になります。
そして、これらのIoTによって得られたビッグデータを解析し活用するのが、人工知能とも呼ばれる「AI」です。
AIでは人間がコンピューターに対してあらかじめ分析上注目すべき要素をすべて指示しなくても、コンピューターが自ら学習し一定の判断をすることが可能となります。
また、スマートフォンの音声認識や産業分野のロボット制御、画像処理など、IoTによってもたらされたビッグデータの分析以外にも、さまざまな場所においてAIは活用されています。
これらの技術を活用している第四次産業革命の取り組みとしては、次のようなものがあります。
（例）メーカーによる自社製品の稼働状況データを活用した保守・点検サービス、ウェアラブル端末を利用し個々の患者に合わせたオーダーメイド治療、保安会社による独居老人の見守りサービスなど
インターネットを通じてサービスの利用者と提供者を素早くマッチングさせることにより、個人が保有する遊休資産（自動車、住居、衣服等）を他者に対して提供したりするサービスです。
（例）個人の所有するマンション等を宿泊施設として提供する「民泊サービス」、個人の持つ専門的なスキルを空き時間に提供するサービスなど
（例）AIを使った資産運用、介護などでのロボットによる生活補助など
「フィンテック」とは、金融（Finance）と技術（Technology）を組み合わせ、ITを活用した革新的な金融サービス事業のことを指します。
（例）モバイル決済、自動で家計簿を作ることのできるクラウド家計簿、個人間での送金や貸借を仲介するサービスなど
第四次産業革命にかかわる取り組みは、2011年のドイツ以降、アメリカ、イギリス、イタリア、ベルギーなどで進められてきました。
ここでは、海外における実際の取り組み事例をもとに、今後の日本に求められることについて考えたいと思います。
Wi-Fiを都市のICTの共通基盤として活用することで、大規模なスマートシティ化が進行しています。
交通量のセンサー情報を小電力無線、Wi-fiでコントローラに送り、エリアを適切な明るさに調整して点灯。
駐車場の利用状況を道路に埋め込まれた小電力無線のセンサーやWi-fiを経由して提供。住民に駐車可能な地点の情報をリアルタイムで提供するとともに、スマートフォンで駐車料金を支払えるようにしています。
IPカメラを利用し、バルセロナの街を監視。監視対象は道路のみに限定し、個人の家は映さないよう配慮がされています。
スマートフォンなどの端末を利用し、位置情報や通行人の流れを把握。現在地に合わせたクーポンの発行など、効果的な顧客誘導を行っています。
ごみ収集箱にもIoTセンサーを設置。ごみの量を自動で判断し、Wi-fiで市へ連絡。市のごみ収集経費削減に役立っています。
「医療・健康」「輸送・交通」「エネルギー・環境」「文化・コミュニティ」の４領域に特化し、ICTにより街の活性化を目指しています。
バイオメトリックセンサー（生体認証センサー）ネットワークを構築し、呼吸器系に疾患のある患者への対応を改善。
位置情報サービス、センサー、モバイルアプリ、電子看板を組み合わせ、バスの運転手へ利用客の有無を知らせるサービス。乗客はバスを待つ際に自動的に「チェックイン」し、情報がバス会社へと伝えられます。
「Manchester Corridor」の主要道路を自転車・バス専用道路に指定。自転車にIoT無線タグをつけ、安価な自転車シェアリングを推進。
ランプポスト（街路灯）や、配電用機器等を格納しているストリートキャビネットなどにIoTタグを設置し、異なる場所・高度で大気質を把握。
市が中心となり、データを活用することで市民の生活の質向上を目指しています。
街灯にWi-fi等を設置し、人や車、バイクなどの移動データを分析。交通量の多い道路では、通勤の時間帯は時速20kmで走行すると赤信号にかかることなくスムーズに走れるよう制御されています。
世界初の「スマート国家」を目指し、国全体で取り組みを進めています。
専用の機器を取り付け、高齢者のいびき、呼吸の乱れ、咳、異常音などの生活音をクラウド上に蓄積し、咳が続くなどの異常事態と判断された場合は、アラートで家族や介護スタッフの携帯へ通知が届くサービス。
計測機器をインターネットと連携させることで、太陽光発電装置、家庭内の公共料金・エネルギー使用量を見える化するアプリの開発。
これらの事例から考えられることは、これからの日本に求められるのは公共性の高いものから個人に特化したものまで、様々な分野を網羅したスマートシティの形成だということです。
「環境」「エネルギー」「交通」「通信」といった、公共インフラと呼ばれるものに加えて、「医療」「介護」「サービス」「危機管理」などにもIoTやAIの活用範囲は広がっており、自治体の永続的な財政負担や人的支援を必要とせず、企業等が自発的に事業創造しやすい環境を整備することが求められています。
政府はこれらの各分野における取り組みを促進するべく、ビッグデータの公開や有効なデータセットや開発キットの提供等、民間企業が新しいサービスを開発しやすい仕掛けづくりに取り組んでいくことが必要であると言えるでしょう。
第四次産業革命とは、IoTやAIを活用した産業構造の変化による産業革命であり、現在進行形で行われている革命です。
IoTによってもたらされるビッグデータを活用し、公共インフラだけでなく医療、危機管理などの多分野に横断した活用を目指すことが求められています。
2018.06.14
現在、日本では労働人口が減少し、企業では慢性的な人員不足に陥っています。
それにもかかわらず、政府は現在、「働き方改革」として、残業を減らし、休暇をとろう！という方針を進めています。
人手が足りない状態で、いまより労働時間を短くするにはどうしたらいいのか。
その担い手として注目をされているのが、RPA。
RPAとは、ロボティック・プロセス・オートメーション（Robotic Process Automation）の頭文字をとった形で略されています。
RPAのメリットはコスト削減、ミス防止、業務効率化。といった点が挙げられており、
そのメリットを生かし、ビックデータを扱う銀行や生命保険会社で導入されています。
RPAは単純作業を得意としているため、夜間にひたすら集計作業を行い、
朝一で人間が出社してから確認作業を行う。という形で導入されたのが始めです。
当然、ロボットなので夜間に動いても深夜手当や残業手当は発生しません。
また、単純作業しかできませんが、その代わり、正確です。
RPAの実行結果を人間がチェックしたところ、間違いはほぼゼロで、いわゆる人為的ミスも減ったともっぱらの評判です。
RPAのデメリットは、今のところ単純作業しかできない。ということかもしれません。
人間は疲れると判断力が鈍り、ミスをします。
ロボットはいくら働き続けてもミスをしません。ただし、判断力がありません。
そのため、単純作業をロボットに、その作業をもとに人間が判断をする。というように業務を進め、効率化する企業が先に述べたような銀行や保険会社以外の業種でも増えてきました。
今回はそんなRPAをいざ導入する！となった際に、失敗しないためのチェックポイントをお伝えしたいと思います。
ちなみに、RPAは現在、海外版でも日本版でも多くのツールが開発され、販売されています。
各ツールに得意分野、不得意分野があるので、ツールの選定は必要ですが、今回のこのポイントは、どのツールを導入するにあたっても当てはまる内容となっています。
まずは、以下の流れにそって、RPA導入のための準備が必要となります。
準備をしっかりしておかないと、導入後に必ず問題が出てきます。
家を建てる際にも基礎工事が大事ですよね？
基礎はしっかりと構築し、安定した稼働を目指しましょう。
まずは、日々行っている業務の整理が必要です。
属人化を排除し、誰がやっても同じ結果が出るよう、標準化することが必要です。
標準化するために、複数の人で業務フローを洗い出し、精査していくことが大事です。
その作業の過程で、気づきがあったり、効率の良い方法が見つかるかもしれません。
これは、RPAを導入することがないとしても、業務をスムーズに進めていくために必要な重要な作業です。
紙ベースで構わないので、日々の業務を洗い出しましょう。
業務の整理が出来たら、以下の作業により、業務フローを見直します。
１）その業務は必要か。取捨選択をする。
２）その業務の目的は何か。明確にする。
３）同じような業務が重複していないか、チェックする。
４）業務の進め方はそのやり方しかないか検討する。
５）優先順位を再確認し、どの箇所をロボット化するか、想定しながら再設計する。
何が何でも全てをロボット化するわけではありません。
上記作業で業務の整理が出来た時点で、ロボット化する箇所、人が引き続き行い作業の切り分けをします。
RPAにはAIが搭載されているわけではないので、単純な繰り返し作業は得意ですが考える作業には適していません。
このことを頭に置いて、イレギュラー処理は人間が行うようにしましょう。
※AI（人工知能）を搭載しているロボットもありますが、RPAにAIは搭載されていません。
RPAはルールに基づいた、ルーチン作業（繰り返し作業）は得意ですが、ノウハウによる判断はできません。
条件による処理の分岐などの判断が、想定とは異なり、処理が中断することも考えらえます。
処理が途中で止まっても気づかないような設計では安心できません。
危機管理として、きちんと想定をしておくべきです。
そしてここまで完了した時点で、やっと、どのRPAツールを使用していくか検討できます。
実際にRPAでロボット化していく作業よりも、準備、事前調査の方が大事だということを理解していただけましたか。
国内外さまざまな製品が提供されているRPA。
自動化したい業務に適しているのかの見極めが重要です。
画面認識が得意な製品、ブラウザとの連携が得意な製品、メール関連が得意な製品。
それぞれの得意不得意が特徴としてあります。
また、初期化コスト、サポート体制、自動化の実現性、また社内開発の場合、技術の習得が容易かどうかも判断基準となります。
このようなさまざまな判断基準がある中で、最も重要なことは、安定して業務が自動化できるかどうか。
画面はポップでかわいらしいキャラクターが、案内してくれるインターフェイス。
RPAを立ち上げるとウキウキした気持ちになるけれど、いざ動作をさせると、エラーばかりで作業が中断されてばかり。
それでは導入した意味がありませんよね。
まだRPAを全く導入していない、部分的にしか導入していない。
そういった企業は、他社の事例を研究し、参考にすることをおすすめします。
セミナー形式で事例を紹介してくれる場合もありますが、だんだんとRPAを導入する企業が増えつつあるいま、
ユーザー同士の情報交換の場も多く開催されています。
実際に使っているユーザー、開発しているエンジニアの声、そういった生の情報はどのマニュアルを読んでも書いていませんし、
研修やセミナーでは教えてもらえません。
そういった場所に積極的に参加をし、情報を得るのはとても有効な手段です。
いざ導入した際には、まず効果の出やすい業務から取り組むことをおすすめします。
処理しなくてはいけない膨大な業務があるので、ロボット化したはずです。
そのすべての業務を一気にロボット化した場合、うまくいかなかった時の原因追及をすることが困難になります。
千里の道も一歩から。
まずは簡単な、日々よく行う業務から徐々にロボット化していきましょう。
また、RPAツールには大きく分けて、RDA（Robotic Desktop Automation）という、PC操作を単純に録画して再生するような、導入が簡単なものと、
ワークフローに細かく対応できるサーバー型のRPAの、2種類があります。
RDAタイプの方が導入は簡単ですが、大きな業務の生産性の向上は見込めませんので、
サーバー型のRPA導入を検討することをおすすめします。
RPAは繰り返し行される作業を、自動化して仕事を完了させるというものです。
データの転記などを人間がおこなった場合、思わぬミスが発生するので、
ロボット化して、その分を、もっと価値の高い仕事に割り当てるような使い方をする人が増えています。
昨今、人口の減少がますます進み、人手不足が加速しています。
ロボットに仕事をとられる、乗っ取られる。というマイナスなイメージを持たず、
ロボットとうまく共存をして「働き方改革」を実現するためのツールとなります。
今後、RPAツールはますます発展していきます。
いまは海外のツールが多く販売されていますが、国産のツール発売も多く見込まれます。
RPAはそれぞれ、設定のしやすさやRPAツールでできること、得意なことがそれぞれ異なります。
そのため、一企業で複数のRPAツールを導入しているケースもあります。
当サイトにも多くのRPAツール比較検討ページがあるため、参考にしてください。
2018.06.13
RPAの導入を検討中の方にとっては、導入によって大幅な業務削減や、残業時間の軽減に大きな効果を期待されているのではないでしょうか。
RPAは適切に導入すれば、当初の計画以上に業務は効率化します。
必要以上に手間をかけていた業務があったことを実感できるでしょう。
社内の不要な業務による時間、人員のロスがなくなると、従業員の単純作業によって発生していた残業も削減しますから、退社時間が早まり、ストレスによる疲労も小さくなるかもしれません。
個人の業務負担が減り、通常の業務に専念できるようになることでミスの発生も少なくなり、仕事の質も向上することが見込まれます。
これまで時間に追われ余裕がなかった従業員も語学や資格取得などの研修機会も取り組みやすくなります。
個人の質が向上することは企業にとっての人的資産の付加価値を高めることにもつながります。
負担でしかなかった研修も準備してのぞめば成果も得られて労使のどちらにもプラスになる、と言えるわけです。
しかしあくまでもそれは正しい理解と活用が実行できていれば得られる結果です。
自動化でできること、ロボットにできることはロボットにしてもらい、知的生産性をあげる業務に集中することが求められるのは、
より質の高い業務を遂行できる人材が育っていればのことです。
人材を育成し、社内の戦力とするだけにとどまらず、社会貢献も企業の責任として近年は厳しい目を向けられていることもあります。
RPA導入は効率化や生産性向上を実現させるのはそうした大きな結果につなげるためでもあります。
企業の社会貢献CSRも大切ですが、さらにちょっと大きなテーマでは、国連が掲げている持続可能な開発目標「SDGs」があります。
言うまでもなく世界各国からの注目度も高く、国連加盟国は「2015年から2030年までに、貧困や飢餓、エネルギー、気候変動、平和的社会など、持続可能な開発のための諸目標を達成すべく力を尽くす」というものです。
こうした目標を実現するためのツールとしてAIやRPAは今後すべての事業で活用されていくと考えられるのです。
IoTはすでに身近な生活道具になりつつあり、工場のような大規模なものから家庭用家電まで幅広く製品化されています。
AIによってさまざまな支援を可能にしたスマートスピーカーは、ちょっとした執事やメイドのような存在で日常生活になじんでいます。
もはやスマートスピーカーなしの生活は考えられない、という声も海外では聞かれるとか。
こうした生活スタイルの変化と同じように仕事の形も変わりつつあるのです。
AIが仕事を奪うのではないか、ということが話題になりましたが、
現時点ではAIにできることはアルゴリズムをプログラムにすることで膨大なデータを読み取ることや、
ディープラーニングによってその認識できる幅を広げることは可能ですが、
抽象的な条件ではまだ認識できる段階にありません。
人の判断の精度を上げるために膨大なデータを検索するツールといえます。
もちろん今後AIは技術者たちや量子コンピューターによってその開発速度をあげながら高い能力をめざしていくでしょう。
そこでも人間のもつ知性や倫理的な判断があってのAIであることに変わりはありません。
（悪意のあるAI開発の可能性はゼロではないと懸念事項にはなっていますが。）
世界各国の繰り広げる激しい技術競争にどこまで日本の人工知能が寄与していくのか冷静に見守りたいところです。
RPAは業務や事業規模に応じてカスタマイズ可能なシステムです。
人材不足に悩む地方や、小規模事業者にこそRPAを活用することで人的資源を補う業務の支援は可能です。
どのような業務の負荷が大きいのか、事業の目的に沿った適切な導入準備をし、
伝票処理やデータ入力などの単純作業は人の手をわずらわせるため生産性が良くない業務でもあります。
RPAにはそういった定型作業を担わせ、注力したい業務に人材を集中することがおすすめです。
操作や設定が難しいのではないか、心配する必要はありません。
システム導入時にはふだんの作業が滞りなく進捗管理できるように設定のサポートも受けられます。
まずはシンプルな定型業務に導入すること、管理やメンテナンスを怠らないこと、任せっぱなしでいいというわけではないのです。
業務を管理して運用することがRPAの導入を失敗しないために最も重要なことです。
導入してからもよりその効率化のための調整や修正も行いながら事業にフィットしたRPAの運用を実現させていく必要があります。
GDP、経済成長率、生産性向上、働き方改革と言われてもそもそも業務の効率化はどこから着手すればいいのか、
という悩みを持つ企業は、規模を問わず少なくありません。
大企業では導入することで社内失業を生みだしてしまうのではないか、
従来のシステムの運用からの過渡期には業務が遅延するのではないか、
生産性ばかり求められても残業を減らせば仕事が止まってしまうのではないか、など、
システム導入の壁が厚く悩みは尽きません。
中小企業の場合であれば人員補充はできない、
下請けなので簡単にシステムを変えると顧客への説明の必要が生じるなど煩わしくなるのではないか、
パソコンだけでも手一杯なのにロボットを導入しても誰がメンテナンスを担当するのか、など、
消極的になる経営者も存在します。
利益に直結させる生産性向上として効率化を急ぐあまり、
誤った社内改革をしてしまえばそのダメージは計り知れません。
事業規模にかかわらず変革はいつも困難を極めます。
それでも決断のスピードでは世界に大きく遅れを取っているのが国内の多くの企業現実でもあります。
そして新興国などの開発や投資のスピードは加速し続けているため近い将来ほんとうに先進国としての立場を維持していられるか不安視されてもいます。
生産性をあげることは事業推進力です。単純な作業に時間をとられて顧客への対応や提案スピードに時間を要することは致命的なマイナスとなります。
市場も規模も小さいからRPAの導入はうちには適していないだろう、
またその反対に、組織規模が大きすぎて導入することが業務の妨げにもなりかねないのではないか、
とためらっている間も時は流れていき、事業推進の遅れはビジネスの結果を揺るがします。
小規模だからこそ、従業員を少数精鋭とするためにも焦らず、
冷静に導入準備をすることが、まさに「失敗しないRPAの導入」であり事業にとって大きな攻めの一歩となります。
さまざまな導入事例をもとに、事業規模に応じた導入を策定することで一時的な混乱があったとしても、
環境への順応能力は思った以上にその期待に応えてくれるでしょう。
RPAを導入し使ってはじめてわかる、目に見える効率の良さがあるからです。
時間外労働5％削減を可能にするということで今年導入した大手企業では、
伝票処理などデータ入力業務などの200業務にRPAを順次導入するといいます。
経理など売り上げへの貢献が見えにくい事務業務の生産性向上と間接費のコストカットを実現します。
人員削減を行う前にまず業務の効率化を図り、
今いる人材を少数精鋭に変えるチャンスがRPA導入のもたらす可能性です。
地方や小規模事業者にとってRPAの導入をおすすめするのは、
こうした問題が目に付くからです。
人員不足で単純作業の負担が大きいと生産性が下がるのは当然です。
作業を軽減する目的で適切にRPAを導入することで地方や小規模事業者も経営に専念する人員が確保できます。
システム導入で従業員の能力開発にも時間的余裕が生まれます。
業務も見える化するのでさまざまな働き方による雇用も可能になります。
フルタイムの雇用では確保できなかった人材も求人募集することができます。
これまでのスタイルにとらわれることなく、強い企業、長く続く企業づくりに目を向けるなら、
RPAやAIの活用は地方や小規模事業者だからこそ必要ではないでしょうか。
2018.06.12
普段はRPAコンサルタントとして、保険会社の業務に対してRPA導入を行っております。
そこで今回は、実体験を基にした導入事例、導入において重要な事項、削減効果などを紹介させて頂きます。
RPA(Robotic Process Automation = ロボティック プロセス オートメーション)とは、
バックオフィスにおけるホワイトカラー業務など、
これまで人間が手作業で行ってきた業務を、ルールエンジン、機械学習、光学文字認識などの認知技術を取り入れたソフトウェアロボットに代行してもらうことにより、
業務の大部分における自動化や効率化を図る取り組みを指す言葉です。
今回ツール選定から行いましたが、使用したのは「UiPath」になります。
費用や学習コストなどを総合的に見て判断しております。
特に、eラーニングが充実しているという点は、
チームにRPAを扱える人間を増やす場合にも手っ取り早く飲み込んでいけるところで大変優れておりました。
開発者が「UiPath Studio」でロボットの作成。
運用者が「UiPath Orchestrator」でデプロイ、ログ監視、バージョン管理などを行っております。
など
上記はほんの一部ですが、今後100業務以上にRPAを導入予定となっております。
住所変更の手続き業務を対象とします。
年間変更件数が6~7万件ほど発生していたこともあり、非常にユーザー部門にとっては高負荷な業務の一つでした。
担当者の人数を単純に増やして対応し続けるのは現実的ではなく、
かといって新たな機能を基幹系システムに追加するのはコストと時間が掛かりすぎるといった懸念がありました。
また、そうしたコスト的懸念以外にも複数担当者が分担して進めている業務であったため、
従来の業務方法の見直しも行わなければ事務処理の品質維持が厳しくなる可能性もありました。
現行業務では、4人程度の分業制となっていました。
まず初めに、住所変更前作業としてコールセンター、インターネットサービス、窓口等の多岐に渡る住所変更の受付内容から住所変更を行う為のデータを作成し、
顧客に合わせたサービスの住所変更受付システムに入力する必要があり、受付票の印刷や請求書の点検などを行います。
そして次に、住所コードの検索を固有のマスタから行う必要があります。
その後、顧客が加入している保険会社に応じた契約者情報を管理するシステムの操作画面を立ち上げ、
上記で作成したデータを基に担当者が新たな住所を入力します。
それを別の担当者が、システムの登録内容に誤りがないかチェックし、
問題がなければ登録手続きを行っていました。
そして最後に、管理台帳に変更記録を入力していました。
1件あたり約7分~10分を要していた作業であり、
人間が行っているので些細な入力間違いやチェック漏れ等も発生していました。
1件あたりは数分程度の作業ですが、
月間にして数千件（約500時間）、年間にして数万件分の作業が発生する業務であり、極めて業務負荷が高くなっていました。
RPAを導入したことによって、月間で8割程度の工数削減に繋がりました。
現状はまだ全業務のRPA化には至っていませんが、これだけの効果が出ているのです。
RPA化されていない部分は主に、住所変更の登録内容や台帳記載の最終確認や何らかの原因でロボットが停止した場合の作業で、
こちらは手作業で対応しています。
特に、効果として大きかったのは住所変更を登録する際に発生していた住所の分割後の入力作業であり、
入力フォームの入力間違いなども同時になくなりました。
今はまだ念の為最終確認を人間が目視で行っていますが、精度も悪くない為、完全にRPA化するのも難しくはないかもしれません。
意思決定者、ユーザー部門、RPA導入部門の3者の連携が重要となります。
また、実際にいざ導入が決まりロボットを作るフェーズとなった場合には要件定義時において、
下記3点があれば、より正確な工数見積もりが可能です。
まだまだ、RPAの工数や具体的な導入期間の見積もり精度は模索中ではありますが、
現行業務がどれだけ可視化されているかによって導入の難易度は大きく変わってきます。
ユーザー部門の業務においては、属人化されている内容が非常に多くあります。
見積もりをした後に追加要件として、RPAシステムの機能を追加していくことによって、プロジェクトが炎上気味になったりすることがよくあります。
現行業務のマニュアル等が一切無いとか、マニュアル内容が業務経験者にしかわからないようなレベル感だと、要件定義のフェーズで非常に工数が掛かってしまうことがあります。
それだけ、現行業務の可視化レベルというものはRPA化において重要な項目となっています。
理想的な話で言うと、新卒で入ってきた人間が現行業務マニュアルを見ながらであれば実際に業務をこなせるようなレベルになっていれば御の字です。
結局のところ、RPAといった技術に関しても、ソフトウェアロボットに業務を代行させるといった側面があるため、代行させる業務像が掴めていないと始まらないのです。
また、場合によっては現行業務をそのままRPA化しないこともあります。
RPA化に最適化させた形で業務フローを改善したり、業務フローの改善が厳しくても、
使用しているExcelのフォーマットの内容などをRPAツールで扱いやすい形に調整するといった作業は非常に重要で、RPA開発では「あるある」です。
RPAツールによっては、Excel操作できる内容に限界があったりしますが、
それでRPA化を諦めるのではなく、Excelの中身自体を変更するといったアプローチを取ることができるのです。
基本的なシステム開発だと、下記のようなウォーターフォール型が一般的かと思われます。
しかし、RPA導入・開発においてはアジャイル型が向いており、
各RPAツールも扱いやすく出来ているためとにかくスピード重視で行う場合が多いかと思われます。
そのため、上記の重要な事項でも述べましたが、
要件定義フェーズを厚くすることでRPAにおいては「要件定義書 = 基本設計書」となり得るので、
リッチなドキュメント作成の手間はかかりません。
要件さえ固まってしまえば早速ロボットの開発に着手し、
いち早くプロトタイプを作ってユーザー部門とロボットの挙動内容のすり合わせを繰り返していくことでより正確なRPA導入に繋げて行くことができる利点があります。
普段からRPAツールに触れている身として、「AI」や「OCR」といった単語はよく耳にしますが、
特にOCRについては最近手書き文字でも非常に高い精度で読み取れるツールも出てきているため、
今後RPAとの連携も増えてより業務に活かしていけるのではないかと考えています。
今後もますます保険会社系や金融系などのバックオフィス業務はRPA導入が間違いなく進んでいくと思われます。
ROIが現代のソリューションの中では圧倒的に高いと思われます。
以上、保険会社へのRPA導入事例でした。
2018.06.11
昨今、様々なRPAが登場し世間を賑わせていますが、
その多くは海外製のRPAを国内の商社が代理店として販売しているものになります。
海外製だとメニューや説明資料が英語だったり、
問い合わせに時差があるため翌日回答になったりと、日本の企業には若干ツライところもあります。
しかし、WinActorはNTTデータが開発した純国産RPAツールであるため、
メニューは当然のことながら、ドキュメントもサポートも全て日本人による日本語のものとなっています。
また、ユーザの意見をフィードバックして次のバージョンに反映してくれるなど、
かゆいところに手が届くので、日本企業にはお勧めの製品となっています。
・クライアント型
RPAにはサーバー型／クライアント型の２種類がありますが、一般的にサーバー型は大企業向けでクライアント型が中小企業向けとなります。
サーバー型は端末の動作状況やログなどを一元管理可能な一方、導入費用が最低でも数百万円～とかなり高価なため、導入のハードルが高くなっています。
WinActorはクライアント型なので、PC一台から導入することができ、比較的導入のハードルが低くなっています。
・操作記録型
WinActorには「記録モード」があり、記録状態にしながら普段どおりに業務を行うことで、ロボットに操作させるシナリオを自動で作成してくれます。
動作のたびに違う動きをさせる、など複雑な処理をさせたい場合は、シナリオを手で編集する必要がありますが、基本部分は自動で作成してくれるため、一から作るものと比べて容易に作成できます。
・Windowsアプリを操作可能
RPAの中にはInternetExplorerの操作やExcel操作など、限られた製品の操作しかできないものもあります。
WinActorはWindowsアプリケーション全般の操作が可能なため、自社で導入しているシステムやパッケージ製品の操作も可能です。
・画像認識
WinActorは画像認識を用いた処理の判定が可能です。
アイコンやエラーマークなど、特定の画像が表示されたら○○をする、といった判断条件を作成可能なため、利用可能な業務の幅が広がります。
画像の類似率も設定できるため、適切な閾値を設定することでOSの違いや端末の違いなど、
多少の変更に対しては動作に影響しないシナリオを組むことができます。
・シナリオのコピーが可能
WinActorはある端末で作成したシナリオを他の端末にコピーして実行することができます。
一度シナリオを作成してしまえば、複数台で並列に実行させることができるので大量処理が必要な業務にも利用可能です。
・対応ブラウザ
WinActorの対応ブラウザはInternetExplorerのみとなっており、ChromeやSafari、FireFoxといったブラウザでは利用できません。
InternetExplorerは最新のHTMLやCSSに対応していないため、最新のサービス等は利用できない可能性があります。
※画像認識機能を使用して対応可能な場合もあり。
・対応OS
WinActorはWindowsのみ対応となっております。MacやLinuxでは利用できません。
・PCを占有
シナリオを実行中はPCを占有するため、人が使用している端末で動作させることはできません。
専用端末を用意することをお勧めします。
（帰宅時に起動して翌朝の始業時に止めるといった使い方であれば可能）
※上記は販売代理店により異なります。
WinActorでロボットを作成するには、まず操作の記録を行います。
Excelのマクロと同じように、記録ボタンを押してから記録停止ボタンを押すまでの間の人の動作を記録しますが、
Excelと違う点は、最初に記録対象のウィンドウを記録しておく点です。
ExcelマクロはExcel上の操作しか記録できませんが、
WinActorはWindows上で動くアプリケーションであれば大体のアプリケーションに対応していますので、
どのアプリケーションに対しての操作を記録するかを事前に選んでおきます。
記録された動作はフロー図のような形でWinActor上に表示されます。
※ブラウザ専用のＩＥモードと、一般アプリケーション向けの記録モードがありますがどちらも使い方はほとんど同じです。
①で記録した動作の編集を行います。
記録したまま実行しても良いのですが、それでは1回実行するごとに人が起動してあげなければいけないので、RPAの効果があまり発揮されません。
RPAを効率的に使うには１度記録した動作を繰り返すように設定してあげる必要があります。
また、実務においては条件によって動作を変える必要もあると思いますのでこの編集によって、
ＲＰＡがなるべく人の代わりになるように設定してあげることが重要なポイントです。
シナリオ編集画面では、条件やアクションをドラッグ＆ドロップで簡単に追加することができます。
②で編集した操作が、狙った通りの動作をするかテストします。
実行速度を遅くしたり、ステップ実行（一処理ごと実行する）機能を使って正しく動作していることを確認していきましょう。
ただし、特殊な例（目安として全体の５％未満）に該当するようなケースまですべて自動化しようとすると、
操作シナリオの作成に手間がかかりすぎてしまうので、
レアなエラーケースは記録だけしておいて、後で人が実行するようにしておいたほうが効率的にＲＰＡを利用することができます。
①～③で作成したシナリオをいよいよ実行端末で動作させ、運用していきましょう。
画像認識機能などは端末が変わるとうまく動作しないこともありますので、認識精度の閾値などを調整してどの端末でもうまく動作するようにしましょう。
また、運用開始していきなり何時間も放っておくと最初の方でエラーになって固まっていたり、
うまく動いていない状態で全部処理してしまったりということもあるので、
初めのうちは頻繁に状態のチェックをすることをおススメします。
数日間安定運用できたら、その後は日に一度のチェックで十分になってくると思います。
まずはトライアル版を試してみましょう。
WinActorは体験版を1ヶ月間無償で試用することができます。
RPAを試してみたい業務がある場合、まずはトライアル版を導入して思った通りの動作が可能かどうか、
狙った通りの効果が出るのかを検証しましょう。
トライアル版で作成したシナリオはそのまま製品版でも使うことができますので、
効果が得られそうな結果が出た場合はそのまま製品ライセンスを購入し、
実業務に使用することができます。
年間９０万円と聞くと高いと感じるかもしれませんが、ＲＰＡはうまく利用すれば単調な事務作業をする人員を何人も削減できるほどの効果を発揮します。
もちろん人と比べると柔軟性に欠ける部分や融通が利かない部分もありますが、
その分定型の仕事は人より早く、正確に実行してくれます。
人件費削減・業務効率化を考えられている方はぜひ一度試してみる価値があると思います。
WinActorはRPAツールの中ではかなり安価な方のツールとして認知されています。
お問い合わせはWinActorの公式サイト、または販売代理店まで。
2018.06.08
UiPathのそれぞれの変数の型には様々なメソッドが存在します。
そのメソッドはどのようにできているのでしょうか。
メソッドの成り立ちについて少しだけでも理解しておくことで今後のメソッドの使用の際に作業しやすくなってくると思います。
ここではUiPathが使用しているプログラミング言語を見ていくことで、メソッドがどのようにしてできているのかについて確認していきます。
UiPathではVB.NETと呼ばれるものを使って様々なタスクを動作できるようにしています。
VB.NETとはVisual Basic.NETの略称で、Microsoft社が開発したプログラミング言語です。
このVB.NETの特徴としては、Windowsとの互換性が高く、
プログラミング言語を経験したことのないプログラミング初心者にもわかりやすいようなものとなっています。
このプログラミング言語をUiPathでは採用しています。
そのため、わからないメソッドや型などがある場合にはこちらのMicrosoftの公式のページから随時調べることができます。
今回はその中でも少し特殊な「時間の管理の仕方」について見ていきましょう。
時間を管理する型として大きく二つの型があります。
DateTime型とTimeSpan型の二つです。
DateTime型は時刻や日付などを簡単に収納しておくためにつくられた型です。
簡単に現在の時刻、日付、曜日などを取得するプロパティなどがあります。
それに比べて、TimeSpan型は日本語で「時間間隔」と訳されるように、時間そのものではなくて時間の値をいれておくための型です。
時間間隔の加減算などを簡単に行うことができるようになっています。
DateTime型のメソッドには、DateTime型同士を比較したり、足してみたりなどのものがあります。
今の二つだけでも気づく方もいらっしゃるかもしれないですが、このメソッドにはDateTime型を引数にして使用するものもあるのです。
もちろんそれ以外を引数にとることもあるのですが、今回は引数にDateTime型を使うものを重点的に見ていきましょう。
1．Equalsメソッド
このメソッドはDateTime型同士を比較するメソッドです。
等しい場合はTrue、等しくない場合はFalseを返します。
このメソッドは引数を一つとるものと二つとるものがあります。
直感的に簡単なのは引数が一つの時なのでそちらから見ていきます。
使い方は、「test_date1.Equals(test_date2)」のように使用します。
ここではtest_date1とtest_date2を比べます。
この使用例のような場合ではtest_date1のメソッドとしてEqualsメソッドが呼び出されています。
次に、引数が二つの場合について見ていきます。
使い方は、「DateTime.Equals(test_date1,test_date2)」のようにして使用します。
ここでもtest_date1とtest_date2を比べています。
この使用例のような場合ではDateTimeのメソッドとしてEqualsメソッドが呼び出されています。
ここで両方について注意していただきたいのは、test_date1とtest_date2はDateTime型の変数ですが、
DateTimeというのは変数ではないということです。
ですので、引数は自由に変えていただいていいですが、「DateTime.Equals」までは固定で同じものを毎回使用することとなります。
また、返り値はInteger型で返ってくるので出力するときなどには注意してください。
「DateTime.Equals(test_date1,test_date2).ToString」のようにすると文字列として出力できます。
2．CompareToメソッド
CompareToメソッドも先ほどのEqualsメソッドと同じく、二つのDateTime型同士を比較するメソッドです。
基本的には同じ操作方法と考えてもらって大丈夫です。
異なる点についてですが、このCompareToメソッドは二つのDateTime型の大小を出力する点です。
返り値についてですが、大きければ「0」よりも大きい値「1」を返します。
逆に小さいときは「0」よりも小さい値「-1」を返します。全く同じときには「0」を返します。
使用例を見ていきます。使用例も先ほどのEqualsメソッドと同じく引数を一つとるものと二つとるものがあります。
引数が一つのものは、「test_date1.CompareTo(test_date2)」のように使用します。
ここではtest_date1とtest_date2を比べます。
この使用例ではtest_date1のメソッドとしてEqualsメソッドが呼び出されています。
この場合はtest_date1の方がtest_date2より大きい場合には「0」よりも大きい値「1」を返し、
逆にtest_date1の方がtest_date2より小さい場合には「0」よりも小さい値「-1」を返します。
引数が二つの場合についても見ていきましょう。
使い方は、「DateTime.CompareTo(test_date1,test_date2)」のようにして使用します。
ここでもtest_date1とtest_date2を比べています。
この使用例ではDateTimeのメソッドとしてCompareToメソッドが呼び出されています。
この場合はtest_date1の方がtest_date2より大きい場合には「0」よりも大きい値「1」を返し、
逆にtest_date1の方がtest_date2より小さい場合には「0」よりも小さい値「-1」を返します。
注意については先ほど述べたものをもう一度見直しておいてください。
3．Subtractメソッド
SubtractメソッドはDateTime型どうしの減算をおこなうメソッドです。
使い方は、「test_date1.Subtract(test_date2)」のようにして使用します。
この場合は、「test_date1」-「test_date2」の値が帰り値となります。
なので、返り値がマイナスの値にもなりうることに注意してください。
さらに注意していただきたいのは返り値はString型ではないので出力する時には「.ToString」をつけ忘れないようにしてください。
（返り値は後ほど説明するTimeSpan型になります）
TimeSpan型には日数や時間数、分数や秒数などが格納される型です。
格納されるもので分かる方もいるかもしれないですが、実際の時間を格納するわけではないので注意してください。
格納するのはすべて数字です。
TimeSpan型に関しては演算子を紹介しておきます。
演算子とは足し算や引き算といった時に登場する、「+」や「-」のようなもののことをいいます。
演算子とメソッドとの違いは、演算子の方が直感的でわかりやすいところです。
実際に見ていきながらのほうがいいと思うので具体的に見ていきます。
1.足し算、引き算
足し算を「+」、引き算を「-」として扱います。
なので、「time1 – time2」のような形をとります。
メソッドで「time1.Subtract(time2)」のようにも書くことは可能ですが、見てすぐにわかりやすいのは前者のほうではないでしょうか。
2.等しい、大きい、小さい
これらの演算子も通常のように使用できます。
「=」や「<」、「>」のような演算子を使用することができます。
また、以上や以下のようなものも「<=」のようにあらわすことで使用することができます。
3.マイナスやプラス
「-2」のような表記のように、「- test」のような演算子も使用できます。
もちろん”-“演算子は符号を逆にする演算子で、「+」演算子は符号をそのままで表示する演算子です。
このように時間の変数の管理について、DateTime型とTimeSpan型をうまく使い分けないといけません。
この時には返り値がどの型の値なのかどうかを確認しながら実行することでミスを減らすことができると思います。
また、ここで用いたDateTime型などではグレゴリオ暦で日時を扱うようになっています。
ですので、うるう年の計算などはグレゴリオ暦に依存しています。
もしも、ヘブライ暦・イスラム暦などの暦のようなものを使用したい場合はCalendar型をお使いください。
2018.06.07
今回のコラムは、前回の内容を受け、製薬業界のBPR施策における4領域のうち後半の残り２つについて説明していきます。前回コラムを参照したい方は、下記のリンクをご覧ください。
前回コラムからの復習になりますが、BPRの施策は大別すると以下の方向性に整理できます。
BPR（業務改善）の方向性
前回コラムでは、シェアードサービスやサプライヤー集約化を扱った「Consolidation」とフローや会議体の簡省力化を扱った「Simplification」を取り上げましたが、今回のコラムでは各組織／個人間でばらつきのあった業務内容を統一化する「Standardization」と、RPAを含めたITの力が発揮される「Automation」について事例を含めて詳述していきます。
Standardization（標準化）
製薬業界は、前々回コラムで述べた事業背景から、事業部ごとやローカル拠点ごとに独自の業務手順・ルールが残りやすい傾向があります。また、中途採用が多い企業では、各社員が前職の会社のやり方を引きずっており、同じ部署内であっても個人間で業務の仕方が異なることもあります。このよう事業背景から、主要な業務については企業としてSOPを始め業務マニュアルの作成の実施を徹底していることが多いと思います。ただ、このSOP／業務マニュアルで対象となるのは、企業にとってコアとなる業務であることが多く、バックオフィス業務の中でも特に微細な事務作業、例えば営業事務や購買、サプライチェーン回りについてはその業務の全てがマニュアル化されているわけではないと思います。
また、仮にグローバルで定義された業務フローであっても、実際にローカルの拠点では全く異なるフローがまかり通っているケースも散見されます。これは各国の法規制上やむを得ない場合ももちろんあり得ますが、ただ単に慣習でそのような状態のままになっている可能性もあります。グローバル展開している製薬企業については、一度グローバルSOPとローカル業務のギャップ分析をすることをお勧めします。その結果明らかとなった業務フローの違いを一つ一つ精査し、やむを得ない事象かそうでなく標準化の余地があるのかを判断していくと、大きな改善機会が見つかると思われます。
また、この標準化の取り組みは、他の領域の施策を行う上での前提条件となります。前回コラムで取り上げたシェアードサービスによる集約化施策や、後程述べるITによる自動化施策を展開するには、まず既存SOP／マニュアルの陽が当たっていない隠れた業務までしっかりと分析・整理する必要があります。そして、現状の業務のばらつき度合いを詳らかにし、会社として目指すべき標準フローを定める「地ならし」が必要です。その工程を経なければ、仮にシェアードサービスの部門を立ち上げたとしても効率化は図れませんし、RPAやITシステムを導入したとしても一部の人しか使えない残念な結果となります。
更に、この標準化の取り組みを発展させるとベストプラクティスの適用まで視野に入ります。先ほどまでの「標準化」は各組織／個人間の「ばらつきを抑える」ことに焦点を当てていましたが、ベストプラクティスの場合、「業務効率／生産性の底上げを図る」ことが主目的となります。これはバックオフィス業務であれば、例えばエクセルのマクロや計算式に強い社員が作成した帳票を共有することや、会議報告用のパワーポイントフォーマットを優れた社員の方のものに統一する等、色々とアイデアはでてくるかと思います。例えば、各医療機関の製剤需要予測において、過去の実績記録を活用し精度の高い予測をしている社員の知見を形式知化して、他の社員にも敷衍させるといったケースが挙げられます。そうすることで、全社的により少ない在庫で、効率の良い製剤供給を狙えます。
このような標準化の取り組みですが、具体的な施策としては、一般的には業務マニュアル／SOPの作成・再設計と周知のためのトレーニングセッションの実施が行われます。但し、例え新しい業務マニュアルを作ったとしてもそれを短期間で広範囲の社員に普及させるのは至難の技であることは、実際にこの分野の業務に携わったことのある方なら皆感じる事でしょう。
そこで、半ば標準フローを強制させる仕組みとして、ワークフローシステムを使うという手があります。医療業界では主要でクリティカルな業務については各社既に頑健たるワークフローシステムはお持ちだと思いますが、周辺の事務作業についてはフォローしきれていないケースもあるかと思います。そのような周辺業務こそが手順・ルールのばらつきを生む温床となっています。それを半ば強制的に標準化してしまう為には、申請・承認プロセスをワークフローシステムで一元化することが求められます。例外は基本的には認めない方針をとります。業務上のコミュニケーションにおいて、口頭やメールだけでのやりとりを残してしまうと、自然と例外対応に追われることになります。その誘惑を抑え、標準化を徹底するにはシステムに責任を負わせるのが一番です。ワークフローシステムを導入することで、事業部側に対しても「そういうシステムになってしまったので融通が利かなくなった」と言う弁明が使えます。このような標準化の取り組みは必ずユーザーサイドで反発が出てくるものですから、予めその標準化初期の不具合・負担増加の責をシステムに押し付ける事は、卑怯かもしれませんが円滑に標準化を進める上ではクレバーなやり方ではあります。
また、ワークフローシステムの導入と並行して、使用する帳票／書類を、標準フォーマットに統一することも非常に有効です。特にエクセル帳票においては後で集計しやすい形に予め設計しておくことが、後工程の業務負荷を軽減する上で重要になってきます。エクセルの操作技術は、社員のリテラシー度合いによって大きく変わります。端的なケースですが、Vlookupを知っていれば、一瞬でできる作業であっても、習熟していないが故に、不毛なコピー＆ペーストをしている社員も少なくありません。社内ベストプラクティスとして、効率性／生産性の高いエクセル作りをしている社員の帳票を、皆で共有していく観点が重要になります。
Automation （自動化）
自動化の取り組みについては、主にITシステム・ツールが活躍する領域です。近年、多くの企業で導入が進められているRPAもこの分野に入る取り組みとなっています。このコラムではITシステムに括られる一般的なパッケージソフトウェアやSaaS型サービスおよび自社専用にスクラッチ開発したシステムについては割愛し、主にRPAによって、製薬企業のどのような業務分野で自動化が進められるかを述べていきたいと思います。
まず、これは製薬業界に限らずヘルスケア業界全般の事例となりますが、UiPATHでこの業界への取り組みが紹介されています。
UiPATH「Use Cases for Healthcare Automation: Revenue Cycle Management」
このUiPATHからのRPA事例紹介によると、まず医療機関側での活用事例として「日次のレポーティング／モニタリング業務」といった典型的なバックオフィス業務の自動化による効率化がある一方、収益や患者満足度への貢献もできることを謳っています。
例えば、RPAを使うことで、患者の診察予約を滞りなく受付け、かつ現状の医師リソースを最大限活かすことで収益の改善が見込めると述べています。RPAロボットにより、診察受付の電子データをいち早く院内の担当者に伝え、コールセンターと患者の間の仲介業務の一部を自動化・迅速化できたようです。
また、患者退院後における経過観察期間において、対患者とのコミュニケーションをRPAロボットにより代替するアイデアも挙げられています。慢性疾患の場合、退院後の経過観察、つまり患者の状態モニタリングは欠かせません。患者が退院後も定期的に投薬を続けているか、診察訪問の予約を入れているか等について、ロボットがタイムリーに患者に対してリマインド連絡をする事例が紹介されています。
こちらの上記UiPATHの記事は、「医療機関側」でのRPA活用事例になりましたが、同様のアイデアは「製薬業企業側」にも敷衍できるのではないでしょうか。例えば、病院側からの注文受付をする担当者様を支援する形で、受注データ（EDI）を迅速に在庫やデリバリーシステムに繋げられるようにする。または、対病院に対して、必要となる定期的なコミュニケーション／リマインド業務をRPAロボットで代用する等考えられます。
もちろん、これらの「収益増加」や「顧客満足度向上」を目指したRPAの活用は発展系であり、RPAの基本用途はあくまでも「効率化」だとは思います。先のコラムでも述べました通り、製薬業界は社内に複数かつ非連携のシステムが混在しているケースが多く、「システムtoシステム」や「システムtoエクセル」といった領域でのRPA活用がまず事例としては圧倒的主流になっています。ただ、これらの業務効率化を狙った活動と同時に、サプライチェーン周りを改善することでリードタイムを減らすることで収益増加を狙うことや、他競合と比べてより手厚い病院フォローをすることで満足度の向上を狙うといった使い方も同時に検討する価値は大いにありうるのではないでしょうか。
以上で製薬業界におけるBPRおよびRPA機会の事例紹介は終わりになります。今回のコラムでは、前回の続きということで製薬業界におけるBPR主要4方針のうちStandardization（標準化）とAutomation（自動化）の2つを取り上げました。特にこの「自動化」の分野では、RPAという新しい技術の台頭により、通常のシステム開発に比べて低コストでかつクイック・ウィンな取り組みが可能となりました。この技術により、今まで「システム開発するには些末すぎて手作業で行っていた作業」も自動化の恩恵に浴することができるようになります。医療業界に従事されている方は、今一度この新しいRPAという技術について学び、自社の業務の何に適用できるか一度考察されてみてはいかがでしょうか。
2018.06.04
今回のコラムでは、最近、特に取り組みが活発化している地方自治体におけるRPA活用事例をご報告していきたいと思います。
自治体におけるRPA活用は、近年各RPAベンダーが注力して取り組んでいる領域であり、様々な取り組みがプレスリリースやその他公表情報により報告されています。
自治体の場合、予算厳守の文化でもありますので、
首長が即断でRPA導入を促すことはなく、他のシステムと同様、
来年度予算の中に入れられるかが重要になります。
2017年に金融を始め大手民間企業での導入事例が新聞雑誌等で脚光を浴びましたが、
その影響を受け地方自治体側では次年度つまり2018年度の取り組みとしてRPA導入を挙げてくる自治体が出てきております。
この傾向は、2018年度、2019年度と年を経るにつれ大きなトレンドとなる可能性を秘めています。
今回はその中でも先駆けてRPAの取り組みを公表している代表的な自治体事例を紹介していきたいと思います。
まず、「地方自治体におけるRPA活用」と言って真っ先に思い浮かべるのが、
自治体庁舎内における自動化の取り組みです。
これはRPAと呼ばれる技術が特に定型のデスクワークに向いていることから、
非常に相性の良い組み合わせであることは、関係者からすると容易に想像できると思います。
自治体のお仕事は実際には多岐にも及んではいますが、
住民からの住所変更や出産・児童手当、確定申告など、諸々の申請処理であったり、
法人に対しても登録処理や事業税手続き、補助金申請処理など様々な定型業務を行っています。
これらの業務については基本的にルールやワークフローは明確に存在しており、
RPAをインストールするための下地は出来上がっていると言えます。
実例で見ると、まず有名な例としてつくば市の取り組みが挙げられるでしょう。
茨城県つくば市では、ＮＴＴデータ、クニエ、日本電子計算（ＪＩＰ）といった民間企業と一緒にRPA導入の共同研究を行うことを2018年1月に発表しています。
RPAツールとしては、NTTデータの「WinActor/WinDirector」を使用、
RPA開発前の業務精査・ロボット対象の抽出等のコンサル部分をクニエが、
その後のRPA開発および既存システムとの連携等にNTTデータとJIPが関わっているようです。
つくば市におけるRPA対象業務についてですが、
市では以下の業務を現状課題として挙げており、
おそらくこれらの領域を先ずは中心にRPA化の取り組みが行われると推測されます。
いずれにしても、RPAが最も効力を発揮する電子データからシステムへの変換だけでなく、
紙や画像データといったOCRを絡めた取り組みも見据えているようです。
OCRは未だ精度の問題が残っている技術ではありますが、
自治体の申請書はその中でも比較的高精度の読み込みが期待できる分野です。
OCRの精度を高めるには、OCRが読み込みやすいように帳票を再設計する必要があります。
これは例えば記入欄をマスで区切り、一マス一文字にするようにするとか、
網目を使わない、帳票上の固定の場所に固定の情報を置くようにする（備考欄のようなものに重要な情報を列挙するのは避ける）といった工夫を凝らす必要があるのです。
企業が扱う、外部からの請求書や名刺といったものはそのフォーマットを企業側はコントロールできないために、
OCRで読み込もうとすると精度問題がついて回るのですが、
こと自治体の帳票に関していえば、
自治体自身が帳票フォーマットを自主的に改変できるという強みがあります。
まさしくこの行政分野において本来はOCRの導入は真っ先に取り組むべきであります。
次の事例として、NTTデータが支援した京都府の取り組みが挙げられます。
RPAの利用が適していた業務として以下の領域を挙げています。
まず、ポータルサイトへのアップデート業務についてですが、
以下のフローをRPAとExcelのマクロを使い自動化したようです。
次に補助金の実績確認業務ですが、これは府が補助金を交付した市町村に対して、
その効果・実績を確認する業務を指します。
府では、その確認項目が39もあったのですが、それらをRPAにより自動化させ業務負荷を軽減、
更に人的ミスもなくなったとのことです。
この京都府の場合もやはり、システムおよび定型の電子データを扱った業務がRPAの一大機会となっているようです。
印刷物形式の統計データをサイト用のオープンデータに変換するような業務は正に定型作業でありますし、
また補助金の実績確認についてもおそらく実績情報なるものが定型の電子データであり、
その情報を拾っていく作業をRPAロボットにさせていると推測されます。
この京都府の事例を鑑みて想うのは、
特に自治体においては「システムtoシステム」の領域におけるRPA機会が非常に大きいのではないかということです。
自治体のIT意識のレベルによって差はありますが、一般的に民間企業に比べて、
自治体のほうは個別システムのタコツボ状態になりやすいと言われています。
これは、一つのシステムベンダーに依存しすぎるのを良しとできない文化であったり、
そもそもCIO的な立ち位置の人間が自治体側で欠損していることから、
個々の連携が全く取れないシステムが集まってしまっている事象を指します。
そうなると、あるシステムと別システムの間を情報連携するのに、
人間の手でデータ加工する作業がどうしても出てきてしまいます。
そのようなタコツボ状態を一気に解決するためには、大型のシステム投資が必要となりますが、
それは次期予算策定する上でおいそれとできるものではありません。
そのようなケースの時に、比較的に低コストで始められ、
簡単なプログラムであれば（研修を受ければ）職員自ら開発・導入もできうるRPAは魅力に映るのかもしれません。
次に、これは具体的な自治体の事例ではないですが、
地方自治体にRPAの機運が高まっている詳細として日本RPA協会の取り組みをご紹介したいと思います。
日本RPA協会で行っている「行政・アカデミア分科会」での取り組みということで、
同協会は2 017年11月に、自治体を支援する「RPA自治体支援プログラム」と中央官庁を支援する「RPA中央官庁支援プログラム」を発表しています。
これは官公庁や自治体職員自らRPAツールを扱える人材育成の面もあるようです。
このような取り組みが今後も活発化していくでしょう。
具体的に「RPA自治体支援プログラム」では、以下の支援を行うことを謳っています。
この支援プログラムの内容を見るに、
少なくない自治体が「自分たちの手でRPAの開発・導入をしたい」をいう意識を持っていることが分かります。
確かにRPA自体はExcelのマクロに近い技術ですので、技術的難易度は差ほど高くなく、
ツールの発展もあって現場担当者でも簡単なものであれば作れるようになれるかと思います。
実際にどの程度、自治体職員側で自主的にRPAを作れるのか未だ不透明な部分は残りますが、
ベンダー側としては開発・導入支援だけでなく研修サービスについてもビジネス機会が出て来ると予想されます。
自社内のRPA導入についてご検討の方は、今年5月に東京ビッグサイトで開催される、RPA導入無料相談会にてご相談を承っております。
詳しくはこちらのページでご紹介。
2018.06.02
UiPath Studioには様々なUI(ユーザーインターフェース)が搭載されています。
これらは単純で直感的に分かるものが多いですが、その中でもよく使うであろう機能について調べてみました。
activityパネルには複数のアクティビティが用意されています。
アクティビティとはアプリケーションを自動化するのに使用するアクションのことです。
例えばクリックや入力、出力などのデータの処理を行うことです。
このアクティビティは全部で約300種類にもおよび、この多くのアクティビティを使用することで
デスクトップアプリケーションやウェブブラウザなどの多くの機能とのインタラクションが可能となります。
また、このアクティビティは[🔎Search Activities]を使用することで簡単にアクセスすることが可能で、
[Favorites]、[Recent]、[Available] などの機能も搭載されています。
これらの機能は 「▷」や「▷」をクリックすることで開いたり閉じたりすることが可能です。
さらに追加でアクティビティパッケージをインストールすることも可能です。
これにより独自のパッケージを追加・削除することができます。
リボンは以下の4つのタブから構成されています。
(1.START 2.DESIGN 3.EXECUTE 4.SETUP )
これらを使用してフォルダーやプロジェクトを開いたり、シーケンスの起動など様々な機能があります。
ここではプロジェクトの新規作成や既存プロジェクトを開いたりすることができます。
新規の空のプロジェクトのは[Blank]から作成することができます。
この際に既定では[C:\Users\Username\Documents\UiPath]に作成されます。
ここではシーケンスやフローを新しくを開いたり、上書き保存などをすることができます。
また、変数の管理やサードパーティ製アプリケーションのユーザーインターフェース要素の検査を行います。
ここではプロジェクトの開始または停止、デバッグプロセスの開始などを行います。
また、ステップ実行やログを開く操作も行うことができます。
ここでは、プロジェクトの公開やプロジェクトのショートカットの作成を行います。
また、タスクのスケジュールの設定やエクステンションのインストールをワンクリックで実行できます。
今回はUiPathのユーザーインターフェースについてまとめてみましたが、
どれも直感的に分かりやすい仕様になっています。
これらの機能を使用して簡単にUiPathを使っていきましょう。
2018.06.01
5月9日～11日の3日間、東京ビックサイトで「AI・業務自動化展」が催されました。注目しているビジネスパーソンの方が多く、会場は非常に盛況でした。その中でも、やはり目に付くのがバズワードとなっている「RPA」の名前を冠した商品やサービスの数々です。猫も杓子もというのは少々大袈裟ですが、それほど多くのソフトウェア企業がRPA＋●●という切り口で、ビジネスを開拓していこうとしています。今回ご紹介するのは、そのようなRPAの名前を掲げているわけではありませんが、将来的にRPAとの連携、応用があるのではないのかと思わせる機械学習プラットフォームの話です。
まずAI・機械学習について
皆さんAIというとどのようなものをイメージされるでしょうか。日常で、普段我々が接しているAIというと、スマホの音声認識技術であったり、チャットボットに見られる言語解析、あとはFaceBook等で使われている顔認証や、自動運転や医療現場で病気の早期発見に使われている画像認識技術などでしょうか。あとは世界王者に勝ったことで有名な「AlphaGo」を思い出される人も多いかと思います。これらのAI技術、厳密に言うと機械学習になりますが、これが精度を高めるに何といっても膨大な「教師データ」が必要です。教師データは簡単に言うとインプットとなるデータと、それに対するアウトプット／結果がセットになっているものを指します。
例えば、「ツバメが低く飛ぶ」というのに対して「雨が降る」というのがアウトプット／結果です。これを人事採用評価に活かすとすると、「（本人が提出した」各種の履歴書情報」「SNS上での情報」「SPSテスト結果」「面接での発言内容」「面接での顔の表情・動き」といったものがインプット情報であるとすれば、アウトプット／結果は「採用／非採用結果」「（入社した場合の）3年後の人事評価」というものに例えばなります。このデータが膨大にあれば、AIに機械学習をさせることにより、入社面接時の情報で「●％の確率のこの方は有望な人材」といった予測をさせることができるようになるということです。倫理上の善悪は置いておいて、今まで人間が勘や経験知で取り扱っていた分野が機械に取り代わる脅威と機会を兼ね揃えた技術と言えます。
ただ、このAI・機械学習の技術ですが、その「インプット」と「アウトプット／結果」の予測精度をどうすれば高められるか、というのは未だ日進月歩の世界であり、世界の知能が鎬を削って開拓している状況です。TensorFlowに代表されるようなディープラーニングもその中の1モデルです。パーセプトロンを使ったニューラルネットワーク理論もあれば時系列に強いリカレントニューラルネットワークといった理論もあります。そのようなモデルの選定もあり、更にその予測モデルの中の細かいパラメータ設定の問題もあります。なので、「インプットとアウトプットデータは揃った。で、最適な予測ができるようになる為には、どのモデルとパラメータ値を採用すればいいの？」といった課題に直面することになる訳ですが、そのような時に登場するのが、昨今脚光を浴びているデータサイエンティストと呼ばれる技術者たちです。
機械学習プラットフォーム「DataRobot」について
そこで、今回のコラムでご紹介したい「DataRobot」と呼ばれるツールの話になります。DataRobotは、スキルレベルにかかわらず、すべてのデータサイエンティストがより良い予測モデルをより速く生成し、ビジネスに展開することのできる機械学習のプラットフォームです。つまり先ほど述べたAI・機械学習技術を企業が活用するときに直面する「どの予測モデルをつかうか」「パラメータ値をどうするか」といったことや、更に「そのようなモデルをプログラミングできる技術者がいるのか」といった課題を大幅に軽減するツールです。即ち、それは簡単に言ってしまうと、広く多くの人／企業に対してビジネス上でAI技術が使えるようにするためのツールと言えます。
企業名はサービスと同名のDataRobot, Inc.で、2012年に米国マサチューセッツ州ボストンにて設立し、現在は米国のほか、日本、イギリス、ウクライナ、シンガポール、オーストリア、ベラルーシ、インド、アメリカ、インドなど世界に営業拠点を置いてビジネスを行なっており、スポーツ、金融、ヘルスケア、小売ほか、幅広い業界で同社のサービスが採用されています。公表情報によると、日本では大阪ガス、トランスコスモス、パナソニック、三井住友カード、リクルートなど様々な業界での導入実績が既にあるようです。東京ビックサイトで行われた「AI・業務自動化展」でもDataRobotのブースでは、ローンの貸し倒れリスクの予測モデルについて実演をされていました。
東京ビックサイト「AI・業務自動化展」におけるDataRobotのブース
もう少し、DataRobotの仕組みついて述べますと、DataRobotでは世界でも有数の優秀なデータサイエンティストを内部に抱えており、彼らのモデル構築する上での知見を活用できるのがウリとなっています。それにより「誰でも簡単に超高精度の 予測モデル生成を行える」と謳っています。この事の利便性は、実際にPhyson等で予測モデルのプログラミングを試した経験を持つ方なら分かっていただけると思います。筆者も実際にAIプログラムを自分で提供できるようになろうと、幾つか教材で試したことがありますが、このAI・機械学習の領域は、行列等の数学知識に加え、統計学、プログラミングといった複数の高度な技術が求められ、一回習ったからと言っておいそれと応用・活用できるものではないと肌身に感じたものです。しかもモデル理論も日進月歩で進化しており、覚えたことが来年には古い概念になっていたりするリスクもあります。つまり「この分野は一部の天才達に任せたほうがいいや」という心情になります。そうなると次に考えるのは「そのような天才達（＝優秀なデータサイエンティスト）を雇おう」ということになりますが、彼らは非常に高額ですので一部の大企業でなければとても費用対効果でペイできる存在ではありません。必然、中堅・中小企業の方々はAIを使いたいと思っても、ベンダーからパッケージ製品／サービスを購入するしかありませんでした。しかし、RPAの脚光で明らかになったように、企業にはそれぞれ抱える課題・悩みは千差万別であり、「自分たちの課題にピンポイントに合った解決策を作り出したいんだ」という声は常に中小企業の潜在ニーズとして存在しています。今回のDataRobotのデモを見て感じたのは、そのような中堅・中小企業にとって自社に合ったAIの活用ができるようになる地平が見えてきたと共に、RPAと組み合わせることでより高度な業務についても広く多くの会社で自動化できる世界がやってくるのではないかいかという期待を抱かせた事です。
DataRobotの得意／不得意領域
次に、このDataRobotが有効に活用される上での得意／不得意とするデータタイプの説明をしたいと思います。ガートナーカスタマー360サミット2017における新日鉄住金ソリューションズの発表によると、以下になります。
ガートナーカスタマー360サミット2017 新日鉄住金ソリューションズ報告資料
こちらの情報に、最新のDataRobotVer4.0の情報を加え、下記に更新してみました。
DataRobotの得意領域
簡単に要約してしまうと、DataRobotが現在最も強い領域は定量情報についてです。テキスト情報や画像分析、音声認識を一般企業が気軽に使うには未だ敷居があるようです。ただ、一般企業にとってRPAと組み合わせた「自動化」の効力が最も発揮されるのが、これらの発展途上の分野ではないでしょうか。定量情報の分析だけだと、精度は落ちますが、エクセルで回帰分析をすることもできなくもありません。今回のコラムでは、将来的にDataRobotのようなAIモデル構築のプラットフォームが定量情報のみならず自然言語や画像、音声認識にまで活用可能になった際に、RPAと連携することで中小企業でもどのような事ができるようになるのか考察していきたいと思います。ただここで挙げたアイデアは、正直将来の可能性のほんの一端にしかすぎません。考えれば考えるほど、色々な可能性が皆様の頭の中にも更に浮かんでくると思います。まさにこの「個社カスタマイズが容易」なAIとRPAとが融合することで、近い将来、一大ビジネス機会が生まれることを感じ取っていただければと思います。
RPAと汎用AIプラットフォームとの連携可能性
（1）Webマーケティングの施策アドバイス
現在、B2CのみならB2Bの企業にとってもPCやスマホ等のインターネットを介しての宣伝・広告活動の重要性は増すばかりです。これは主にGoogle Analyticsにあるような定量情報の扱いがメインにはなりますが、各社社内の人材もしくは広告代理店、Webマーケティング専門会社等の外部に依頼して、どのような施策を打つべきか日々格闘しています。例えば、どのようなコラムをどのくらいの頻度で書くとSEO上効果的か、バナーのデザインはどのようなものがいいか、サイト内の文言やページ構成、ボタンの配置・色、など様々な施策を試しPDCAを回しています。
このWebマーケティングの取り組みで難しいのが、効果的な施策というものが時と場合によって変わることです。Googleのロジックの変更による影響もありますし、競合他社の状況、商品のタイプや顧客層によっても効果的な施策というものが変わってきます。幾つか王道と呼ばれるような打ち手パターンはありますが、基本的にWebマーケティングはこのように個社ごとの状況に合わせて暗中模索中で取り組んでいるのが実情です。
そこで、個社ごとの取り組みをRPAによってしっかりとモニタリングし、蓄積された施策評価データをもとにAIがアドバイスするようなサービスは考えられないでしょうか。この場合、インプットデータは「環境情報」（現在のPV／UU数、滞在時間、直帰率推移、視聴者セグメント構成や、競合サイトのPV推測値等）と「施策情報」に分けられ、アウトプット／結果データは「PVやCV上昇値」が考えられます。そのような情報が蓄積できれば、例えば「この直帰率が上がってきている今の状況だと、最もCVに効く施策は●●」といったことがAIによりアドバイスができるようになります。ただ、これは口で言うのは易し、であり実際にはこの「環境情報」や「施策情報」というのを綺麗に意味のあるレベルまで情報整理・落とし込みするのは至難ではあります。
より狭い施策分野に限定すると、もう少し現実性の高い活用ができる可能性があります。例えば、SEO目的で書くブログですが、このテキストデータを上手くその構成要素に分解できれば、過去のブログテキスト情報とそのページのPV獲得数情報をRPAにより自動抽出してAIモデルに蓄積させることで、「今回のブログだとPV数は●●程度獲得できるだろう」といった予測が立ちます。これだけだと予測だけになってしまうので、さらにそこから踏み込んで「●●のような書き方をすればPVは●％の確率で上昇する」といったアドバイスまでできたらより実用性の高いものになります。
（2）チャットボットのシナリオ自動作成
次に、目下様々な企業で対カスタマー向けや社内のQ&A対応として活用しているチャットボットについてです。これらのツールには質問者が入力した情報が一体何のテーマに相当するのか符合させるのに自然言語解析のAI技術が使われています。しかし、このチャットボットを導入検討した方なら分かると思いますが、その質問テーマに対する回答を用意し繋ぎ合わせる作業、つまり「シナリオ作成」と呼ばれる工程は実は人間が作らなければなりません。ニュースで話題となった横浜市資源循環局のチャットボット「イーオ」も、まさに同様に裏では様々な質問について回答シナリオを人間が準備して構築したはずです。
横浜市資源循環局のチャットボット「イーオ」
このシナリオ作成についてですが、ベンダー側で一般的なシナリオ案は持っていますが、質疑応答の内容は正に個社ごとに千差万別、いかにたたき台となるシナリオ案があったとしても、結局は個社ごとに地道に作っていくしかありません。またこのシナリオ作りは1回で終わらず、基本的に日々のメンテナンス・更新はかかせません。
そこで、このシナリオ作成についてAIモデル構築プラットフォームを使って自動化できないでしょうか。膨大な問い合わせフォームやメールの履歴から質問テキストの「インプット」と人間のオペレーターによる回答テキストの「アウトプット」の情報をRPAにより自動抽出して、AIモデルに投入しシナリオを自動で作成・更新していくアイデアです。このようなことができれば、中小企業にとってもチャットボット導入が容易になるのではないでしょうか。
以上、例えばということで、RPAとAIの活用による可能性をご紹介しましたが、アイデアはまだまだあると思います。既にAI適用が進められている分野ではありますが、契約書や請求書の読み込みに使われているOCRに対して、もっと個社カスタマイズしたAIモデルの構築が可能になるかもしれません。また、音声認識のAIモデルが容易に作れるようになれば、会社特有の専門用語等が駆使された会議の議事録作成に使える日がやってくるかもしれません。今後もこのDataRobotのような「個社カスタマイズが容易」になるAIプラットフォームの進化をしっかりと追っていきたいと思います。
