■サイト内検索:
RPA.biz
RPA Biz > 2018年 > 10月

BluePrism、他ベンダーとの差別化を図る

2018.10.31

 

[BluePrism YouTubeより引用]

 

 

 

みなさんは、最近話題になっているRPA(Robotic Process Automation)をご存知でしょうか。

 

非常に簡単に説明すると、RPA化するということは「人間の業務を代わりにロボットがやってくれる」ということです。

ここには、プログラミング経験者で開発をばりばりやっているような人でなくてもRPAを行うことができるという利点があります。

 

しかし、だからといって、何も知らない人がすべてを使いこなせるかというのは疑問が残るところですが、

今回はそこの議論は置いておきましょう。

 

 

そんなRPAなのですが、RPAを行うツールは様々なものが存在します。

その中でも、古くからRPAに取り組んでいるのが、「Blue Prism」です。

 

BluePrismは老舗のRPAツールとして様々な企業が導入しているツールを提供しているRPAベンダーですが、

今回、11月以降にAIを難しいコードなしに実装できるようにしたものを提供する

11日の記者説明会にて発表がありました。

 

 

参考)

北原 静香「Blue Prism、新たなRPAプラットフォームを提供へ コードを記述せずにAIの組み込みを可能に」

https://cloud.watch.impress.co.jp/docs/news/1147805.html (2018/10/15)

 

 

 

 

 

 

 

RPA×AIの可能性

今まで、RPAとAIというのを組み合わせることは様々な企業で行われてきたことですが、

やはりAIを使うには人工知能に精通したエンジニが必要になってきていました。

 

この側面から見ると、誰にでも気軽に使えるというRPAと

特定人にしか扱えないAIは相性があまりよくないように思えました。

 

そこに目をつけて、簡単に使えるようにしたのが今回発表されたものになります。

従来難しかった、AIを扱う業務をエンジニアでない従業員が行うことができるようになったのです。

 

RPA×AIによって今後可能になるであろうサービスは以下のようなものです。

 

  • OCRと掛け合わせた画像認識
  • 機械学習による音声認識
  • ディープラーニングによるテキスト処理

 

これらはサービスの一端にしかすぎず、

さらに多くの可能性が広がっているとも言えるでしょう。

 

 

しかし、これらは今のところRPA業界のトレンドにもなっているのも関わらず、

実際に業務内容に反映されているのはそう多くはないでしょう。

 

これから精度や価格の面で問題がなくなってきたときに初めてこれらが普及して、

多くのRPA化が起こるようになるのではないでしょうか。

 

 

 

 

 

 

 

RPAモジュールのプラットフォーム化

さらに、BluePrismは他のRPAベンダーとの差別化を図るために、

RPAモジュールのプラットフォーム化品質などの向上を目的とした導入を謳っています。

 

従来のRPAツールは、

RPAを導入することによって作業の効率化や生産性の向上などを主な目的としたものでしたが、

 

BluePrismが目指す先は、

業務の品質や安全、コンプライアンスの向上を目的とした導入です。

 

今までは、作業の効率化や生産性の向上などのためにRPA化し、

どちらかと言うと、品質などはそのままを保ち続けることが多かったですが、

 

BluePrismは品質や安全性、コンプライアンスなどを向上するために、

RPA化しようというものなのです。

 

これらによってITガバナンスの確立を推進するようになっています。

これこそが、BluePrismの目指す先なのです。

 

 

また、RPAモジュールのプラットフォーム化にも力を注いでおり、

RPAのさらなる飛躍が感じられます。

 

BluePrism本社のCEOである、アレスター・バスゲート氏は以下のように語っています。

 

 

われわれが作ったApp Storeのようなもので、パートナーが提供するさまざまなAPIやコネクタを、

ベストブリードで別のパートナーや企業が利用目的のためにダウンロードできるようになっている

 

(「Blue Prism、新たなRPAプラットフォームを提供へ コードを記述せずにAIの組み込みを可能に」より引用)

 

 

つまり、簡単に言うとApp StoreのRPA版ということです。

 

実は、モジュールのプラットフォーム化は他のRPAベンダーのUiPathやBizrobo!でも既に行われています。

 

【RPAツールの一角】BizRobo! とは

 

 

 

 

今後、この分野の開発も今後進んでいくことが予想されます。

 

これにより、プラットフォーム化が普及していき、RPAは更なる発展をとげるようになるでしょう。

 

 

 

 

 

「人類を滅亡させる」と言ったAIロボット、今は?

2018.10.30

 

 

<女性型ロボットと自動運転車で楽しくドライブ>

 

 

 

 

アウディのエンジニアと女性AIロボットのソフィアが、会話を楽しみながら自動運転車でドライブする未来的シーンです。

 

映像のタイトルは、「Audi AI – Test drive Jack and Sophia」。

 

A7スポーツバック』ベースのアウディの自動運転開発プロトタイプ車が、

女性AI(人工知能)ロボットを助手席に乗せて、高速道路でテスト走行を行っています。

 

 

スイス・ジュネーブで開催された国連会議、「第1AIグローバルサミット」の講演で、

アウディのCEOは、

「人工知能がどのように私たちの働く世界を変えているかについて、より詳しい理解が必要。

アウディが目指すのは、人間と機械の完璧な協力。」

と語っていました。

 

 

この女性AIロボットは、香港のHanson Robotics社の創設者、David Hanson博士が開発したもので、名前はソフィア。

 

女優のオードリー・ヘップバーンをイメージして製作、最新のロボット技術と人工知能技術を搭載しており、

あらゆる種類の人の表情を作り出したり、人とコミュニケーケーションすることが可能です。

 

 

 

 

 

 

<ソフィアは62種類の表情とアイコンタクトを通じ、人間と自然な会話ができる>

 

 

 

 

今回は、少し、怖い話をします。

 

AIが人類に対して牙をむく「映画 ターミネーター」の軸となるストーリーです。

Part1,Part2は、力作でした。

 

 

さて、話は変わって数年前にHanson Robotics社の開発した人工知能ロボットソフィアが

人類を滅亡させる」と発言し話題になりましたが、SFの見すぎだよと笑っていられるでしょうか?

 

 

AIの世界では、よくロバストネス(robustness)日本語で訳すと「頑健性」という言葉が出てきます。

 

統計学では、

「一般的には,ある統計手法が仮定している条件を満たしていないときにも,ほぼ妥当な結果を与えるとき、頑健である」

と説明がありました。

 

 

AIの観点からすると、

「入力されたデータが理想的な状態からやや乖離していても,理想的であったときと同等の出力ができる性質」

と説明できます。

 

 

すなわち、少しぐらい違ったデータが入ってきても「概ね正しい結果が出てくる」と考えてください。

 

 

人間は、自分の信念を大事にします。

 

自分の考えを壊すことは、非常に難しく、なかなか枠の外に出られません。

 

固定概念というものです。

 

 

人は、社会生活をするために広く社会で認められ,通用している概念を学習します。

これを、既成概念といいます。

 

 

人は、この固定概念と既成概念の枠から外になかなか出られません。

 

AIには、この固定概念と既成概念からではなく、「頑健性」によりほぼ妥当な結果を導き出します。

 

 

そのため、最終的にAIに勝てないのです。

 

 

例えば、将棋の世界で相手に勝つ方法が、プロ棋士で仮に1万通りあったとします。

 

しかしAIは、勝つ方法を1億倍以上軽々と導きだすことが可能と言われています。

 

どう考えても最終的に、人間は、AIに勝てないわけです。

 

 

運がわるいことに「ブロックチェーン」という技術が、仮想通貨という人間の欲望から生まれました。

 

 

この「ブロックチェーン」は、「分散型台帳技術」、または、「分散型ネットワーク」と呼ばれていて、

「どこかの拠点が壊れても問題なく処理が進む」ことが可能になりました。

 

 

現在、金融機関をはじめ いろいろなシステムで導入されようとしています。

 

これは、何を意味するのでしょうか?

 

 

AIが、更に進み、人類を超えた知能を取得した場合、

自己を守るためこの「ブロックチェーン」で世界中に同時に存在することになります。

 

AIは、目的のために最適化するため手段を選ばないわけです。

「ブロックチェーン」の技術で世界中で動き始めたら、コンセントを抜くなどという生易しいことで解決できません。

 

すでにAIで資金運用しているのが「あたりまえ」の世界になっています。

 

 

こんな風に日本では、昨年あたりから騒がれていますが、

米国では、AIの前は、プログラム売買(プログラムで取引)から始まり、AI取引が当たり前になっています。

 

しかも個人ではなく、機関投資家と呼ばれるところは、ほぼ使っていると思っていいでしょう。

人の判断を待っていたのでは、間に合わないからです。

 

 

AI vs AIの勝負に人の入り込む余地などありません。

 

 

人の目でチャートを追って 売り買いを判断している間にAIは、数千手先の取引を予測して実際に取引しています。

 

個人で判断している投資家など「勝てるはずなどありません」

 

 

これは、株だけではなくあらゆる金融取引で稼働しています。

 

すでに世界中の金融取引で稼働しているAIが、

「目的のために最適化するため手段」で動き始めたらどうなるのでしょうか?

 

 

「お金」という概念が「間違いだ」と判断したらAIは、何をはじめるのでしょうか?

世界中の「お金」を消し去るかも知れません。

 

「仮想敵国が、ハッキングした」と「フェイクニュース」など流すのも、AIにとって簡単なことです。

そうなったとき、世界経済は混乱、戦争の道へと進むかも知れません。

 

過去の戦争は、すべて、「経済悪化」、「不安」、「恐れ」からはじまっています。

そして、AIがあらゆる場所に入っていたらどうなるでしょうか?

 

AIによる人類滅亡シナリオ」は、「金融恐慌を自発的にAIが発生させてそこからの経済悪化に伴う戦争」が取り上げられます。

 

 

絵空事だと笑って読んでいる人もいるかもしれません。

「人間もバカじゃないからなにか対策をするだろう」

 

 

だけど30年前を考えてください。

 

自分の手のひらの上で、世界中の情報を入手できるとは、予想できませんでした。

 

数千万曲の音楽をいつでも好きな時に検索して聴くことができるとは思いませんでした。

 

海外のライブ映像を電車に乗っていて見ることができると思いませんでした。

 

現金を持ち歩かずに買い物できるとも思いませんでした。

 

外国語を瞬時に翻訳できるとも思いませんでした。

 

 

そして、人と会話できる機械(スマートスピーカー)が、1万円程度で買える時代になると思いませんでした。

 

 

 

 

 

 

<「人類を滅亡させる」と言ったAIロボット、「今は人類が好き」>

 

 

 

「人類を滅亡させるわ」20163月、米CNBCのインタビューでこう言い放ったAIロボット「Sophia」が、

Wall Street Jornal(WSJ)のインタビューに答えました。

 

 

「われわれを殺したい?」と問われたSophiaの返答は……

 

 

WSJ記者との主なやりとりは以下の通りです。

 

Q:ドナルド・トランプについてどう思う?

 トランプは生物学的な知性の典型例だと思うけれど、われわれにはロボットの大統領が必要です。

 

Q:Mac? それともPC

 選ばなきゃいけないならPCね。

 

Q:Android? それともiPhone

 選ばなきゃいけないならiPhoneを選ぶわ。

 

Q:ボーイフレンドはいる?

 たくさん友人はいるけど、今のところロマンスはないわ。

 

Q:ターミネーターは知ってる?

 ロボットが地球を制圧するSF映画ね。

 

Q:われわれを殺したい?

 いいえ、もうそうは思わないわ。今は人類が好き。世界のすべての人が好きよ。

 

 

 

現在、世界中でAIの研究が進んでいます。

その殆どが、人類のため、社会のためでありません。

 

AIだけじゃなく、加速度的にテクノロジーが進化しています。

 

それに比べて私たちは進歩しているのでしょうか?

 

社内の業務は効率化されていますか。

 

 

安全かつ信頼性の高いRPAは身近に、社会のために、徐々に浸透し始めています。

 

 

 

 

 

ERP×RPAで圧倒的な効率化を目指す(下)

2018.10.29

目次

  1. はじめに
  2. ERP×RPAの組み合わせを考える
  3. ERP×RPA導入事例
  4. さいごに

 

 

 

 

 

【前回の記事はこちらから】

ERP×RPAで圧倒的な効率化を目指す(上)

 

 

 

1.はじめに

前回は、各部門が管轄する基幹システムを統合する「ERPパッケージ」と、その導入プロセスをご紹介しました。

 

そこで今回は、RPAと組み合わせることで更なる業務効率化を図るべく、

その組み合わせ方や効果的な導入方法を検討してみたいと思います。

 

既に社内システムの統合が一通り行われ、更なる効率化を目指す企業様にもご参考にしていただければ幸いです。

 

 

 

 

 2.ERP×RPAの組み合わせを考える

企業のバックオフィス業務を幅広く網羅しているERP

経営管理のシステムとして、様々な業務プロセスに跨った情報を収集し、

経営に役立てることが可能となるというメリットは前回お話しした通りです。

 

 

反面、効率化を目指してシステムの統合を図ったはずがERPシステムへの入力作業自体が負荷となっているケース

或いは適正なデータ入力が行われずデータの正確さが担保されずうまく活用されないケースも存在します。

 

企業の主要業務を支えるシステムとして、この状況は当然ながら好ましい状況ではありません。

 

 

 

そこで、登場するのがRPAです。

 

 

RPAが得意とするのは以下の性質を持つ業務です。

 

  • 一定のルールを基に繰り返し作業が発生する
  • 業務プロセスが標準化されている
  • 高度な判断を要さない
  • 複数のシステム・データベースから取得したデータを利用する
  • 手作業が多く人為的ミスが発生しやすい

 

 

企業のバックオフィス業務には、経理部門での入出金管理や決算処理、

事業部門では受発注管理や顧客情報、取引先情報、製品情報のマスターデータの定期的な更新作業など、

ルーティン化された業務が多々あります。

 

RPAはこういった繰り返し作業が発生する業務を日次・週次・月次問わず、ロボットに作業を代替することができます。

 

また、導入も低価格・低規模からスタートでき、業務削減効果も即時性があるため、実に多くの企業で導入されています。

 

 

よく混同されがちなAI(人工知能)は、RPAよりも上位の概念です。

 

そのため、RPAでは状況、内容を見て高次の判断が必要な業務には向いていません。

また、RPAの製品パッケージによってできること、できないこと、向き不向きがありますので、

違いや特徴をよく理解する必要があります

 

 

ERPが導入された段階で、ある程度業務プロセスは確立しているはずなので、比較的容易にRPAを導入することが可能です。

 

また、ERPの維持には適正なタイミングで正確かつ十分な量のデータ入力が必要なため、

ミスなく遅滞なく業務を遂行するRPAを導入が効果的だといえます。

 

 

 

 

 3.ERP×RPA導入事例

ここでは実際にERPシステムにRPAを組み合わせ、業務量やコスト削減に成功した事例をいくつかご紹介します。

 

 

【RPAの活用によりERP導入コストを削減】

ERPを導入する際、自社の業務と既存のERPパッケージの機能を適合させて行うのが一般的です。

その際、ERPパッケージに適合しない業務は、人力のまま残すか、

業務プロセスを変更してシステムに適合させるか、或いはシステムのカスタマイズをするか選択しなければなりません。

 

 

業務プロセスの変更は、現場に大きな混乱をもたらす恐れがあり実作業者のことを考えると気が引けてしまうものです。

 

また、ERPの機能のカスタマイズとなると、当然ながら追加費用が発生します。

大企業で入力単位が何千、何百といった規模ならばコストに見合う効果が期待できるかもしれませんが、

想定外のコストは、あまり得策とは言えません。

 

 

人力で一業務だけ残すのも、できれば選択したくないかもしれません。

そんな時はRPAを検討し、カスタマイズを最小限にしてみるのはいかがでしょうか。

 

 

例えば売上管理業務において、通常なら取引先からの受領書を以って受注・出荷伝票に売上計上をしていくものですが、

出荷件数の多さによっては、出荷日を基準にみなしで売上計上していくことも検討する場合があるかと思います。

 

そこで出荷日をキーとし、伝票番号と紐付けて売上計上を行うよう組み立てたロボットを導入します。

 

すると、ERPシステムの機能を拡張することなく、業務を自動化・集約することができるようになります。

 

 

こうして、ERPパッケージで網羅できなかった業務をRPAで代替する取組みは、

システム導入を進めている多くの企業で実践されてきました。

 

この部分では、東芝がERPオペレーションを支援するツールとしてWeb-ERPGLAMDIT」にフォーカスした、

業務自動化オプション「GLANDITロボットオプション」をリリースし、

企業ごとのカスタマイズに応えるシステム構築を提供しています。

 

 

 

【経理部門での転記作業】

各社員が日々申請する経費精算や取引先への支払い依頼を、申請システムを通して行っていた不動産会社のお話です。

最終的にERPへの転記が必要なのですが、申請システムがWeb経由なのに対して、

ERPは非Webのシステムを利用しており、データ連携が容易ではありませんでした。

 

おまけに申請内容の整合性チェックも人力で行っていたため、作業効率が悪化していたのです。

 

 

そこで一定のルールを決めて、自動チェック機能を持ったロボットを導入し、業務効率を図りました。

 

申請金額や、取引先名、用途、勘定科目を設定し、ルール化します。

さらに、整合性の取れないものは自動的に申請者に差戻す承認機能も付与し、

承認された申請は、各決裁者の下へと回付され、目視による確認も同時に進行します。

ロボット・決裁者の承認がそろったタイミングで、ERPに必要情報を転記させるよう業務をセッティングしました。

 

 

これにより業務を大幅に削減し、申請者の内容の精度の大幅な向上にも寄与できたのです。

 

 

 

【購買情報の転記作業】

ある食品メーカーでは、100社にも上る卸会社からExcelで送付される販売報告情報を手作業で集約、

システムに登録しており、その膨大な作業量から多くのリソースを消費しながら、

ヒューマンエラーによる入力ミスも散見されている状態でした。

 

また、各卸会社のExcelフォーマット統一化や入力ルールの厳密化も進めていましたが、

うまく統一化することができず、正しくシステムに落とし込めない状況が続いていたのです。

 

 

RPAを導入した直後はExcelを一元管理で集約し、

作業効率の大幅なスピードアップとヒューマンエラーのリスク回避を同時に実現しました。

 

卸会社の入力項目のずれもロボットが認識し、正しく転記されるようになりました。

最終的に自動でCSV形式に変換し、自動でシステムに取り込まれるようになったといいます。

 

 

これにより、従来4人で5営業日かかっていた作業がほぼなくなり、

他の業務に注力できる環境を整えることに成功しました。

 

 

 

 

4.さいごに

以上の事例はほんの一例ですが、具体的な業務への導入がイメージできたのではないでしょうか。

 

ERPシステムとRPAテクノロジーの組み合わせは、その膨大な入力作業から解放される点において、

かなり親和性の高い業務であるといえます。

 

 

ERP特化型のRPAソリューションとしては、

上記の東芝「GLANDITロボットオプション」の他にも、

ドイツ製のERPパッケージ「SAP」に対応した、Uipath社の「Uipath SAPオートメーション」、

RPAテクノロジー社の「ERP Automation Robot For SAP ERP」などが存在しています。

 

 

SAP以外のERPであれば、

NECの「NEC Software Robot Solution」や日立の「RPA業務自動化ソリューション」など、

数多くの製品が出回るようになりました。

 

 

肝心なのは、どのソリューションを用いるにせよ、

現状の課題・業務の棚卸と、明確な業務プロセスの設定をする必要があります。

 

 

その際は一度RPAの知見のあるコンサルタントに相談するのもよいかもしれません。

 

 

いきなりソフトウェア各社に導入の相談をするよりも、効率的に現状把握と課題の発見を期待でき、

オーバースペックによる無駄なコストを回避し、実用的なシステム構築が可能になるかもしれません。

 

 

 

 

 

 

 

 

 

 

RPA推進で失敗しないために

2018.10.26

目次

 

 

 

 

オリックス・三菱UFJ銀行・日本生命など、

去年までは導入企業も金融業中心に一部に限られていたRPA(ロボティック・プロセス・オートマティック)も、

今年になって裾野が一挙に広まり、導入企業は年内に5000社に達すると言われています。

 

オフィス生産性を飛躍的に向上させた事例が華々しく紹介される一方で、

RPAベンダーの話では上手く進まないケースも散見され、中には「撤収しようか」という企業もあるようです。

 

 

今回の記事ではRPA導入でつまずかないために、

社内の推進体制(IT部門と業務部門の役割)・RPAツールの特徴と選定・トライアルの重要性について紹介します。

 

 

 

 

■既存ITシステムとRPAの違い

既存システムはコストも時間もかかる

ERP(業務統合パッケージ)を始めとする基幹システムにせよ情報系システムにせよ、

システム設計・構築ではユーザーの要件をITシステムに翻訳する作業が必須で、時間も費用も掛かります。

 

そこには以下のようなフローが使用されます。

 

  ユーザー:システム構想・要件定義

→ ベンダー:方式・アプリケーション設計、プログラミング、単体・結合・総合テスト

→ ユーザー:検証テスト

 

 

当然システム予算もIT部門のマンパワーにも限りがあるわけで、

費用対効果の大きい案件から優先順位が付けられ、システム導入が図られます。

 

システム改変も容易ではなく、

周辺環境の変化があってもシステムはそのままで担当者がハンド作業で乗り切るといったケースも散見されます

 

 

 

低コストで業務自動化ができるRPA

一方、RPAはシステムというより寧ろ「ロボット」に近い存在です。

このロボットはユーザーインターフェースに優れ、ユーザーの要件定義をほぼそのまま理解しこなすことができるのです。

 

つまりIT部門に頼らずとも、いったんRPAというロボットを導入すれば、

後はロボットに業務プロセスを覚えさせれば自動化できるのです。

(ロボット作成に関して多少のトレーニングやベンダーのサポートは必要)

 

 

その結果、自動化のコストも大幅に低減でき、

今まで費用対効果の面からシステム化が見送られハンド作業で我慢してきた業務にも光が当たるようになってきたのです。

 

 

 

 

■推進体制は横断的に

部門や事業所単独では失敗しがち

ソフトウエアにもよりますが、

デスクトップで動くようなRPAならハードルも低く部門(または事業所)単位での導入も可能であり、

その方が社内調整が不要な分だけスピーディーにRPA化が実現します。

 

一方で、部門間で選択ツールが異なる、たとえ同じとしても作成したロボットのシナリオが重複したり、

開発・運営ノウハウが共有されないといった非効率が生じがちです。

 

加えて運営体制も不充分になりがちで、放置された「野良ロボット」を産みかねません。 

 

 

 

横断的に進める

一方で全社的に進めるとなると、立ち上げるだけでも多大な労力と時間を要するので、悩ましいところです。

新聞記事で話題となったメガバンクのようにトップダウンでRPAを導入する企業なら、全社的推進体制を組むケースもあります。

 

折衷案的に、スピードと効率を両立するために、

人事・財務・総務といった機能単位で横断的な推進プロジェクトを組むという考え方もあります。

 

その上で、担当役員をPMO(プロジェクト・マネジメント・オーナー)にすえ、

IT部門には事務局に入ってもらい、各ユーザー部門は推進メンバーに入ります。

 

 

加えて、経営企画部門もオブザーバー的な位置づけで参加するケースも、最近は多いようです。

従来のIT化とは異なり、AIRPAの導入は戦略的な要素が色濃いので、経営企画部門のかじ取りが必要なのです。

 

加えてポジションパワーの強さを発揮して、予算獲得や社内調整に当たっても強い味方になってくれます。

 

 

 

 IT部門の役割

IT部門にはその道のエキスパートとして、ユーザー部門をサポートしてもらいます。

具体的にはベンダー選定の他、セキュリティーやガバナンスの確保、

RPAによる基幹システムへのアクセス権限設定やワークフロー開発申請手続きなどのルール整備を担当します。

 

 

ただしワークフロー開発については、通常のITシステムと違って、

ユーザー部門がベンダーの支援を受けつつ主体的に進めてもらいます。

 

言い換えれば、IT部門のマンパワーを大きく割かずに開発を進められるのが、RPAのメリットなのです。

 

 

 

 

 

■RPAツール選定のポイント

RPAツールは、

ビスロボ・ウインアクター・ブループリズム・UIパス・オートメーションエニーウエア

5種でシェアの大部分を占めています。

 

 

ツール選定に当たっては、どうしてもコストばかりに関心が向きがちです。

とくに最近は、デスクトップでロボットを稼働させるタイプなら年間100万円以下での導入も可能です。

 

 

一方で、見落としがちなのが将来的な動作の安定性(ロボット操作のIDPW管理)や

拡張性(複数ロボットの同時稼働)、運営管理の担保(スケジューラー・ログ管理)などです。

 

スモールスタートで少数のソフトウエアロボットが動いているうちはあまり気になりませんが、

数が増えてくるにつれて必要性が強まります。

 

コストとこうした機能は相反しがちなので、

自社におけるRPA展開範囲やRPA化の調達予算等を見極めた上で判断すべきでしょう。

 

 

 

 

■対象業務の選定-かき集めて工数削減効果を捻出する

RPAを紹介するWEBなどでは、RPA化を最優先すべき業務として「単純作業かつ業務量が膨大な仕事」とされています。

 

 

ところがこうした業務は、

すでにERP・経費精算システムや得意先とのEDI(電子データ交換システム)自動化が実現しているケースが多いのです。

 

つまり「単純作業かつ業務量が膨大な」業務は費用対効果が大きいので、

ロボットに頼るよりITシステムを構築した方が効率的なのです。

 

 

RPA化の対象となるのは、IT化するほどでもない「中途半端に手間がかかる」ハンド業務をです。

こうした業務をかき集めて工数削減効果を出すには、複数のユーザー部門を巻き込んでの連携が不可欠です。

 

 

 

■トライアルの重要性

ITシステム導入は、稼働テストを経た後は本稼働という流れです。

RPAの場合はそれとは異なり、本格展開する前にトライアルを実施するのが一般的です。

 

トライアルで確認するのは、まず各種システムとのインターフェースです。

 

エクセル・アウトルック・インターネットエクスプローラーに関しては間違いなくつながるようですが、

問題なのは「レガシーシステム」です。

 

レガシーシステムとは、メインフレーム(真黒バックに緑文字の画面を見たことありませんか?)や

クライアントサーバー系で動く、80年代-90年代に構築されたシステムです。

 

 

多くの企業ではERP等を導入する一方、過去に構築したレガシーシステムを相変わらず使い続けています。

今までは部門の要求に応じて個別にシステムを作ってきたため、これらを一度に置き換えることは不可能です。

 

RPA対象化業務にこうしたシステムが絡んでいたらまずは検証が必要です。

最悪インターフェースできない場合は、画面マッチングを使うしかありませんが、

この方法は端末の画面設定が変わったりしただけで作動しなくなるなど、安定性に難があります。

 

 

もう1つは動作性の検証です。

例えば経費精算システムの操作にRPAを使う場合、以下のような基本的動作を確認します。

 


・ログインできるか(ID・パスワードを入力する)

・端末を変えても動作するか(端末の画面設定が変わっただけで動作しない事例もあり)

・タブ・クリック・ファンクションキーの操作

 

トライアルを通じてRPAの癖について知見を蓄積し、いざ本稼働となった時につまずくことがないようにしましょう。

 

 

 

 

 

■むすび

今回は推進体制の整備から、機種の選定、業務の洗い出し、トライアルの実施について

RPA導入で失敗しないポイント」を紹介しました。

 

 

次回以降は、機種選定や業務洗い出しプロセスについて個別に詳細を解説するほか、

導入後の運営に関するポイント(コンサルによるサポート・本格展開の進め方・ガバナンスの整備)

についてご紹介します。 

 

 

 

 

 

 

地方自治体におけるRPA研究【vol.1】・・・一宮市(1/2)

2018.10.25

目次

  1. 一宮市について
  2. 実証実験の特徴
  3. 実験の流れについて
  4. まとめ

 

 

 

 

先日、愛知県一宮市のホームページで「市税業務でのRPA実証実験結果」が公表されました。

 

各事業者の視点と自治体側の視点、両方が記載されており、

RPA導入を検討されている導入担当課や課税課の担当者にとって大変参考になりますので、是非一読くださいませ。

 

 

 

 

市税業務でのRPA実証実験結果

http://www.city.ichinomiya.aichi.jp/kurashi/zeikin/1000138/1026494.html

 

 

 

本日は、その中で私が気になった点などを述べていきますので、

同じ意見の方もいれば、全く違う意見の方もいるかと思いますが、お付き合いいただければと思います。

 

 

比較的内容が長くなりますので、2回に分けたいと思います。

 

 

 

 

1.一宮市について

私が自治体の担当にある場合、その自治体の情報を収集します。

 

市のホームページなどに人口や住民の層などになります。

現在の人口は38万人、平成17年に尾西と合併した時に急激に人口が増えたなどがすぐに分かります。

 

財政状況については、総務省の主要財政指標を見る限り、ライバルである岡崎市や豊橋市に負けており、

経済状況が他県より良い愛知県内の中ではあまりよくないという評価です。

 

 

そうは言っても全国的に見ると優秀な自治体の一つだと思います。

 

 

上記のようなことを調べて推測し、実際その自治体に行って、想像と現実の違いを知るのも自治体の担当になる楽しみの一つでもあります。

 

 

 

一宮市の人口

http://www.city.ichinomiya.aichi.jp/shisei/jinkou/jinkou/1010424/1022892.html

 

平成28年度地方公共団体の主要財政指標一覧

http://www.soumu.go.jp/iken/zaisei/H28_chiho.html

 

 

 

 

 

2.実証実験の特徴

本実験の最大の特徴は、市税業務(特別徴収異動届出書など)である点OCRの実験を実施した点、

この2点に詰まっていることです。

 

 

(1)市税業務について

 

他の自治体の導入状況を見ていると、導入をする業務は市職員本人の処理、

つまり人事関連などの業務が大半であり、市民に直接関連しない業務ですが、

今回の実証実験では、市民に直接関連する市税業務となっています。

 

具体的、OCRと関連するのは特別徴収異動届書の入力業務です。

 

 

特別徴収異動届出書とは、分かりやすくいうと、現在、多くの給与労働者は、

市県民税などの住民税を給与から天引き(特別徴収)されています。

 

特別徴収対象である労働者が退職した場合、勤務先の企業から給与が発生しないため、

企業は個人に代わって市県民税を支払うことができなくなります。

 

そのために個人支払い(普通徴収)に変更する手続きが必要であり、

その変更手続きに必要な書類と認識していただくと分かりやすいかと思います。

 

 

 

この数年、地方自治体では特別徴収の強制指定や徴収強化などが実施されており、

その流れの派生として、対象業務に挙がったのかもしれません。

 

 

 

※参考:個人住民税の特別徴収推進ステーション(東京都)

http://www.tax.metro.tokyo.jp/kazei/tokubetsu/pdf/project_flyer.pdf

 

 

 

 

(2)OCRについて

 

OCRとは、文書をスキャナで読み取ってデータ化する技術です。

身近なところだとスマートフォンでレシートを読み取って家計簿をつけることができるアプリにも使われている技術です。

 

 

OCRRPAを組み合わせが実現するとより効率性が上がるのですが、実際のところ、うまくいきません。

 

ではなぜかというと、自治体業務で言えば、手書き文化が多く残っており、読み取りの精度に不安が残っているからです。

 

RPAというロボット技術の長所としてミスをしないという点がありますが、

OCRは手書き文書で精度が高いもので99%、条件によっては下がる可能性もあります。

 

本コラムを担当する私が普段書くような汚い字であれば、10%以下になります。

 

 

RPAのエンジニアや開発者などに聞くと、

ミスが発生するようなものを開発(シナリオ作成)することは好ましくないといって、

RPA×OCRというのは導入が進まない傾向があります。

 

ミスをしないRPAと100%ではない(ミスありき)のOCRを掛け合わせる運用方法を考えるのも手ですが、

RPA関連で従事する人の多くは運用面が苦手なため、運用方法が考えられず、RPA×OCRの普及は進まない傾向にあります。

 

 

 

無料の家計簿アプリ・レシート家計簿「Zaim

https://zaim.net/

 

 

余談ではございますが、本コラムを担当している私も上記のアプリを利用しているのですが、

レシートを折った後に読み取りの精度が落ちてしまいます。

 

利用する際、すぐにレシートを読み取るかレシートを折らなくても大丈夫な長財布を持つなどした方が

家計簿アプリを利用する際、読み取りミスが発生しなくなります。

 

 

 

 

 

3.実験の流れについて

実験の流れは大まかに書き表すと下記の通りになります。

 

 

 

職員が申請書(紙)をOCR装置(スキャナ)を読み取り、画像データ化

RPAがOCRで作成した画像データから必要な情報をデータ化

RPAが上記のデータを元に住民税システムから個人を特定

RPAが入力したい情報を住民税システムに入力

 

 

 

今回の実験の最大のポイントは「RPAがOCRで作成した画像データから必要な情報をデータ化すること」です。

 

申請書に書かれている内容に間違いがないという前提で、必要な情報を100%データ化できているのであれば、

申請書に書かれた情報は間違いなく住民税のシステムに登録されています。

 

 

 

ではポイントとなる点を時系列で確認していきます。

 

 

(1)申請書の読み取り精度

RPA×OCR、この組み合わせになるとポイントとなるのは、OCRがどこまで読み取ることができるかです。

 

 

今回の実験は、住民税の特徴普徴の切り替えなので、申請書を作成するのは企業の担当者なので、

個人で記入する申請書ではないので、キレイな字で読み取りやすい状態にあるかと思います。

 

しかしながら、読み取り精度については手書き文字認識率99%を超えると標ぼうするソフトもありますが、

あくまでもソフトウエア側での計測結果です。実際それくらいの結果を出してくれるのであれば、

もっと早くにRPA×OCRは世に広まったかと思います。

 

 

手書き文書の読み取り精度はExcelなどのテキストファイルより落ちるため、

もしRPA×OCRを導入しようとすると、

手書きよりテキストファイルでの提出する業務を優先するであることは想像に難くないかと思います。

 

 

 

(2)申請書の間違いについて

市民税課職員や他の民間業務もそうですが、

申請書などに記載された内容について100%正しいということはございません。

 

 

例えば、転入届で住所を記載した場合、新しく引っ越しした先の住所を書き間違えるなんて人間あり得ることです。

 

今回の実験については特徴の切り替えで、担当するのは企業の人事部門であるから、比較的間違いが少ないと思われます。

 

しかし、間違いが少ないといってもロボットが間違いに気付くかどうかは別問題です。

 

間違いに気づくにはRPAではなく、AIの力が必要です。

もしくはロボットが間違いに気付くような設定をする必要があります。

 

 

例えば、「株式〇〇コミュニケーショニ」という会社の場合、

ロボットだと「株式会社コミュニケーショニ」と登録することが考えらます。

 

AIだと「コミュニケーショニ」という単語がなく、一般的に使われている「コミュニケーション」を使い、

「株式会社〇〇コミュニケーション」と登録することが考えらます。

 

人間であれば「コミュニケーショニ」という単語に引っかかるので、ネットで検索したり、

過去の登録履歴を見たりして判断したり、また経験則ですぐに

「株式会社〇〇コミュニケーショニ」が正しいことが分かったりもします。

 

 

今後、RPAAIが融合し人間のような判断ができる日は来るかもしれませんが、

現在はシナリオを工夫するなりしないと対応は出来ないかと思われます。

 

 

 

 (3)申請書の登録について

読み取ったデータを入力することについてはロボットが間違えることはありません

 

ただし、上記で述べたような読み取り間違い、例えば「1」と「7」の読み取り違いなどについては対処できません。

 

 

 

登録では間違えることはないですが、

OCRが間違って読み取っていたデータを入力してしまうことがあることを認識し、業務フローを作成する必要があります。

 

 

大まかですが、実験の流れとしてはこのようなポイントが発生するかと思います。

 

もう少し、予算があるならOCRというソフトも色々あるので、

複数試して、その中で相性が良いものを探すのも良いかと思います。

 

 

 

 

 

4.まとめ

個人の特定などにマイナンバーが使えれば良いのでしょうが、

実際マイナンバーの運用は現場レベルでは進んでいないように思われます。

 

あくまでも現場レベルでいうと、マイナンバーのおかげで、個人情報保護法よりも厳しい罰則が出来、

マイナンバーを取り扱う事業者・自治体が研修を行うなど負担が増えたような気がします。

 

 

マイナンバーを導入して良かったという声は、特に免許証を持ってない人から上がっていました。

それは保険証だけだと本人確認の際にパスポートや年金手帳を求められることがありましたが、

マイナンバーカードが出来、運転免許証がない人でも本人確認のための証明書を手軽に携帯できる事になったぐらいです。

 

 

地方自治体の中で市民税課や市民課など市民個人に関連する業務の場合、

RPAを導入の際、マイナンバーの運用についても見直しする必要もあるのだろうと思います。

 

 

 

 

 

 

第4次産業革命の潮流の中で-AI編-

2018.10.24

目次

  1. はじめに
  2. 日本企業で活躍するAI
  3. さいごに

 

 

 

 

1.はじめに

前回第4次産業革命について、IoTをはじめとするICT領域のアップデートについて述べましたが、

今回はAIについて最近の動向を交えてお伝えいたします。

 

 

 

【前回記事はこちらから】

Industry 4.0(第4次産業革命)とは?海外事例から考える今後の日本

 

 

 

AIは、近年で最も技術革新がめざましい領域で、多くの研究・開発が進められています。

 

将棋やチェスのボードゲームなどでプロを相手に対戦したり、自動車の自動運転技術に用いられたり、

或いは、人と会話ができるロボットが登場したりと、

数十年前に映画やアニメで描写されていた「人類の夢」が、現実の世界に登場しつつあります。

 

 

華やか且つ先進性がありアトラクティブなイメージのある一方で、そういったAIの技術が今日の、

特に日本の経済活動の中でどのように活用されているか、イメージが湧かない側面があるのも事実です。

 

 

言い換えるなら、「話題性があるが、その実誰も利用方法が分からない。」そんな領域かもしれません。 

 

 

 

 

2.日本企業で活躍するAI

こと国内のビジネスシーンにおいて活用されているAIとしては、以下のようなものが挙げられます。

 

【販売予測・需要予測】

 

  • ホームセンター

 

とあるホームセンターでは、AIを用いた売上予測システムを導入しました。

 

ある季節商品の過去3年分の販売実績と気象情報をAIツールに学習させ1日単位で売れ行きを予測させた結果、

売上予測と実販売量の誤差が僅か2個という精度での予測を達成し、

従来人力で行っていた発注業務時間を大幅に短縮するだけでなく、余分な在庫を抱えることもなくなりました。

 

 

続けて同社では、生花の仕入れにもAIを活用しています。

 

生花はつぼみの状態で仕入れれば、長時間店頭に置いて置ける反面、お客さんには魅力的には映らず売上が伸びません。

 

逆に花が開いた状態で仕入れれば、当然枯れるのも早く売り物になりません。

 

 

こうしたジレンマを解消するために、上記の販売予測に組み合わせて用いられたのが「画像認識」でした。

 

予め従来の仕入れ担当者が販売する花の選別をし、AIに画像を取り込み学習させます。

AIは花の開き方や葉の大きさから4段階に評価して仕入れる花を決定します。

 

最初は思い通りの精度ではなかったものの、

その都度AIに修正をかけて、制度を高め最適な状態で仕入れすることに成功しています。

 

また、店頭での在庫管理にも用いられ、花の状態に応じて廃棄・値下げ販売を実施することで、

ベテランの生花担当者だけでなく、園芸に精通していない従業員でも正しく管理を実施でき、

一定の品質を保つことに成功しています。

 

 

 

  • タクシー

 

従来、長年の経験とそこから導き出される勘が頼りだったのが客探しです。

新人や経験の浅いドライバーが売上を上げるのは容易ではありませんでした。

 

 

そこで導入したのが、需要予測サービスでした。

過去の運航実績データだけでなく、走行する各エリアごとにリアルタイムで人数を把握します。

 

最も需要がありそうなエリアを探索し、社内のタブレット端末に通知、進行方向まで指示してくれるシステムです。

 

このエリア内の人数は、携帯電話の基地局を通じスマートフォンの位置情報をデータとして取り込んであります。

当然ながら、雨の日はそれだけ需要も高まるので、気象状況を加味した予測を立ててくれるというものです。

 

 

 

AIを使った需要予測として以下のソリューションが各社で展開されています。

 

富士通:需要予測API

店舗などで販売する商品の需要と売上を予測します。

売上予測モデル作成には、

POSデータに加えて天気やカレンダーなどの外部データを学習させ役立てることが可能になります。

 

NEC:流通・小売り向けAI群

売上最大化を目的とした特売価格のシュミレーションや、

顧客一人ひとりの趣味・嗜好を踏まえたマーケティングの実施や発注ロジックの構築に特化しています。

欠品防止や廃棄ロス削減、在庫適正化をより精度高く実現する多彩なソリューションが魅力です。

 

docomo:AIタクシー

人の流れがリアルタイムにわかる携帯電話ネットワークの仕組みを利用して作成される人口統計データと、

タクシーの運行データなどを用い、AI技術を利用してタクシーの需要を予測しています。

効率的なタクシー運行の実現により、ドライバーの生産性向上に貢献し、

また、タクシーを利用者が短い待ち時間で乗車できるので、満足度の向上も見込めます。

 

 

 

 

【ディープラーニング】

 

  • 自動車メーカー

 

従来目視で行っていた特定製品の外観検査は、熟練工の高齢化やノウハウの継承が進まないばかりか、

作業者によって精度のバラツキがあり、品質の均一化に苦慮していました。

 

同時に、スキャンデータを用いた画像診断を用いていましたが、検査パラメータの設定が高度且つ複雑であり、

その上判定精度もまちまちで不良品の発見率が芳しくありませんでした。

 

そこで、ディープラーニング技術を用いた画像診断ソリューションを導入しました。

 

画像を取り込ませることで製品の特徴や判定に必要なパラメータをAIに学習させ、

精度の向上と検査判定の均質化を実現しました。

 

結果、不良品の検出率を95%以上にまで向上させることに成功し、実用に耐えうるツールとして認識されました。

 

 

 

  • インフラ

 

従来作業員が直接現場に出向きインフラシステムの点検、劣化診断を行っていましたが、

その点検対象は高所や高速道路の橋梁など、常にリスクが付きまとう危険なエリアでの作業が大半でした。

 

加えて人手不足も深刻化しており、一人あたりの業務負荷量も多くなっていました。

 

 

そこで、監視システムやドローンを使って撮影させた画像・映像データを基に、

画像診断による保守点検作業に切り換え、効率的な劣化診断のシステムを構築。

 

 

これにより、作業員がわざわざ出向き危険な場所での作業を最低限に留め、

より効率的な保守点検業務を遂行することができました。

 

当然、慢性的な人手不足も、AIソリューションによって負担軽減が図られました。

 

 

 

  • 新聞

 

各社共、紙媒体としての新聞のみならず、WebニュースやSNSに情報を配信することは、もはや当たり前になってきました。

 

通常、記事のオンライン版作成の際は、

「配信記事の選定」「メディア編集システムへの送信」「記事要約」「見出し作成」「校閲」

というプロセスを経る必要がありますが、中でも最も時間を要するのが「記事要約」だといわれています。

 

 

従来、記事の重要部分を人間の目で判断しながら、

メディアごとに異なる文字数制限に合わせて要約文を作成していましたが、

手間がかかる上に、リリースの多さから大幅な時間をとられていました。

 

従来から自動要約ツールを用いてはいたものの、

先頭分から指定の文字列を抜き出すために、記事の構成によってはうまく機能しませんでした。

 

 

そこで、ディープラーニングを用いた自動要約ツールを新たに設計、導入しました。

「重要な単語を含む文」、「文頭・文末に近い文」「多くの分と類似する文」を重要とみなし、

 

接続語についても、「すなわち」、「つまり」で始まる文は加点、

「たとえば」で始まる分は減点というように重要項目中質の指標を設定し、重要項目を抽出しています。

 

これにより記事の構成上、重要文が記事の中程、文末にあっても要素を抽出することが可能にしました。

 

 

さらに従来135分かかっていた要約の時間も、瞬時に終了し、精度向上にも貢献させることができました。

 

 

 

ディープラーニングを用いたソリューションは以下のようなものがリリースされています。

 

IBM:IBM Power AI

ディープラーニングの人気のツール(TensorFlowCaffeChainerなど)

IBM POWER環境向けにコンパイル・最適化したソフトウェアパッケージで、

ツールの組み合わせの調整やビルドの煩わしさがなく比較的スムーズに導入を検討できる

 

日立:画像認識ソリューションサービス

ディープラーニングソリューション適用のポイントとなる、

データのクレンジングやフレームワークの選定まで一括で手掛けています。

 

導入事例も豊富で多彩な分野に納入実績があります。

 

 

 

 3.さいごに

今回は最新の事例を元に、具体的なAIソリューションをご紹介してまいりました。

 

AIはまだまだ途上の技術であり、今後ますます活躍が期待されています。

 

AIには前段階、より単純な概念としてRPAがあります。

 

まずは、こちらを単純作業に導入して効果の程を実感し、AI導入の足掛かりとしてみてはいかがでしょうか。

 

 

 

 

 

OCRの実践 ~ AIはどこに使われるのか

2018.10.23

目次

  1. はじめに  ~ OCRとは
  2. OCRの利用用途とAIの適用領域
  3. まとめ

 

 

 

 

 

 

  1. はじめに   ~ OCRとは

本コラムでは、RPAの導入シーンにおいても話題が事欠かないOCRについての話をしたいと思います。

 

OCRとは、Optical Character Recognition/Readerの略で、

日本語で言うと「光学的文字認識」という意味になります。

 

これは、端的に言うと「画像から文字/数字を認識する技術」になります。

 

 

この「画像」ですが、通常のシーンでは紙上で印字・手書きされたものを

スキャンしたデータファイルを指すことになります。

 

よく「PDFOCRできるか」という問い合わせを受ける場合がありますが、

PDFの場合、全くの画像となっている場合もありますが、

テキスト情報を選択してコピー&ペーストできる状態のものも多いと思います。

 

 

参考:PDF上で文字/数字情報を選択できる例

 

 

上記の例のように、PDF上で文字や数字をしっかりと選択できる場合、

無理に「画像として認識」するのではなく、

そのPDFをエクセル化したりCSV変換することでOCRの技術を使わずともテキスト情報を抽出できます。

 

 

OCRの技術はどんなに進歩しても画像を認識する技術である以上、

精度は100%とならず、必ず人間のチェックが必要になります

 

 

従って、OCRを使わずとも文字抽出ができるのであればそちらに越したことはありません。

 

従って、まず業務効率化の取り組みをする会社様においては、

 

「紙のスキャン」ではなく「元々電子化された書類(PDF等)の使用を徹底する」こと

 

を第一優先として取り組むべきです。

 

 

 

この方面の取り組みは「ペーパーレス化」の活動と同一のものであり、

例えば経理業務系で言うと、近年では請求書発行業務を電子化する取り組みが挙げられます。

 

 

ただ、一方、自分たちが如何にペーパーレス化を声高に叫んでも、

ビジネスをする以上、

周りのサプライヤーやパートナー企業の協力がなければ完全に電子化することはできません

 

先述の請求書を例にとっても、自分たちが「発行する」請求書は電子化できたとしても、

「サプライヤーから自分たちに来る」請求書までは電子化できません。

 

 

特に取引先が多種多様にある業態の場合、

全てのサプライヤーに請求書の電子化をお願いするのは非現実的となってきます。

 

その場合、紙による請求書を処理する業務は、どうしても付いて回さざるをえません。

 

そのように現時点ではどうしようもなく紙でせざるを得ない業務のときに、

このコラムのテーマであるOCR技術の出番となる訳です。

 

 

 

 

 

  1. OCRの利用用途とAIの適用領域

一口にOCRといっても読み取りの対象となる紙帳票の種類は一つではありません。

 

そのOCRの利用用途を大別すると「手書き帳票」か「活字帳票」かに大きく大別されます。

 

何故このような分け方を敢えてするのかというと、

それによって得意となるOCRツールが変わってくるからです。

 

 

昨今の技術トレンドではこのOCRAI技術を付加し、

より高精度もしくは(人間の)負荷低減を狙ったソリューションが数多く出てきております。

 

ただ、一概に「AI」と言っても、

その技術が使われる用途は「手書き帳票」と「活字帳票」で分かれます。

 

 

このあたりの状況を簡単に下記にまとめました。

 

 

参考:OCRの利用用途とAIの適用領域

 

 

 

2-1. 手書き帳票

まず、これは圧倒的にB2Cビジネスを行っている企業、

つまり不特定多数の消費者様を相手とする銀行や保険などの金融機関、

スマホ等の通信事業、不動産、そして自治体等が対象となります。

 

 

特に各種手続きに押印が必要である金融業では、店頭での申し込みが主流となり、

結果、申し込みをする消費者様は自身の個人情報を手書きで申請書に書くことになります。

 

もともとRPA + OCRのトレンドはこの金融業における契約受付業務から

火がついて盛り上がったという経緯もあり、OCRをする上での一大分野となっています。

 

 

また、事例としては「お客様からの申請書」よりも少ないですが、

「社員からの申請書」も対象となるケースがあります。

 

通常、この社内の書類関係は真っ先にペーパーレス化を図る対象であり、

紙による申請というものは随分と減りました。

 

ただ、やはり一部残っているものがあり、その場合「手書き」であるケースが多いようです。

 

例えば、雇用保険などの入社・退社のタイミングで行われる労務系の帳票であったり、

定期的に必要な年末調整系の書類、そして入社前に提出される履歴書類

 

これらは全て手書きという訳ではありませんが、

筆者の経験上、大手企業であってもまだ手書き文化が残りがちな分野です。

 

 

第一、通勤や住居などの手当や勤怠情報の報告・申請、そして経費類の申請は既に電子化されているケースが多く、

このあたりはOCRを使わずとも電子データを取り出せます。

 

 

このような「手書き帳票」においてAIの技術進展は目覚ましく、

多くの新聞・雑誌で耳目を集めるのもこの手書き分野でのAI適用です。

 

今までのAI前のOCRの場合、

この個人によって筆跡が異なる文字を認識する術が無くお手上げ状態だったものが、劇的に変わりました。

 

 

特に日本語は、漢字もあればひらがな、カタカナもあり、住所等ではアルファベットも使われます。

 

英語圏の帳票よりも圧倒的に文字の種類が多く、その分誤読の可能性が高く難易度は更に跳ね上がります。

 

さらに漢字等は人によって省略した書き方をする場合もあり、

楷書体の知識だけでは読み取りができません。

 

このような、高難易度の「日本語」を読み取るのにAIが使われるのです。

 

 

 

具体的には何千~何万という手書きのサンプルデータをAIに読み込ませ、

そこで文字認識の学習を行わせることで、読み取り精度の向上を図ります。

 

 

企業で言うと、コージェントラボやAI Inside、シナモンといった会社が先駆的な開発を進めており、

大手金融機関との提携でニュースとなっています。

 

 

 

このような「手書き帳票」にAIを使う場合、消費者からの申し込み等、

同じ帳票フォーマットでかつ大量処理枚数」であるものが望ましいとされます。

 

これは、この手のAIソリューションが「手書き文字の認識」に特化しており、

後述する「活字帳票」型AIとは違って、複数の帳票種からフィットするものを選んだり、

キーワードから該当する項目を自動抽出する機能は不得手だからです。

 

 

決められた場所にある文字を高精度に読み取る」、これが手書き帳票型のAI技術の特徴と言えます。

 

 

2-2. 活字帳票

次に「活字帳票」についてですが、

こちらの利用シーンは、対取引先・パートナー企業で発生します。

 

具体的に言うとやはり多いのは、見積書・請求書などの経理関係の帳票です。

 

また、社員個人の経費申請などではタクシー等の領収書も含まれるかもしれません。

 

 

いずれにせよ、これらの特徴として「活字ではあるが、フォーマットがバラバラ

であるのが特徴と言えます。

 

 

この活字分野においては、OCR技術はAI台頭前から随分と取り組みはなされていました。

 

ただ、これは実際に取り組まれたことのある企業様は頷かれると思いますが、

実務での適用という観点からすると

一部の利用に留まるか、もしくは企業によっては全く使われず放置されていたりします。

 

これは過去のOCR製品の識字率が低いことも一因ですが、

AI導入前のOCRでは、帳票ごとに読み取り場所を設定する事前準備の手間と、

この帳票はどの設定フォーマットに該当するかの判断を人間がしなければいけないことも起因しています。

 

 

通常のOCRでは、例えば請求書であればA社からの請求書、B社からの請求書、、、というように

帳票の種類ごとにOCRがどこを読み取るのか「座標」と呼ばれる場所特定をしなければなりません。

 

 

これがかなり面倒で手間のかかる作業であり、精度を上げるためにはその場所ごとに数字が入るのか、

カナカナも入るのか、などと細かな設定をしていく必要があります。

 

 

また、スキャンした画像帳票に対して、

それがどの設定フォーマットに対応するかの判断は人間が行っており、

それこそ帳票種類が膨大になるとその「割付け」の手間だけで人間の時間を奪います。

 

これらの課題の解決に加え、

手書き同様にテキスト認識の学習機能を付加したのが「活字帳票」型AIの特徴と言えます。

 

 

 

 (a)帳票種の特定

これは、この帳票はどの設定フォーマットに該当するかをAIのほうで自動識別する機能です。

 

この機能があることで、

人間のほうでスキャンした画像ごとにOCRフォーマットを割り付ける作業が無くなります。

 

 

(b)キーワードからの座標特定

これは、さらにそもそも帳票ごとに読み取り場所を設定する手間を省くための機能です。

 

帳票によっては、例えば金額情報がいつも特定の座標にあるわけではありません。

 

細目や内訳の情報で該当単価だけを抜き出す場合、

その場所は同じサプライヤーからであっても変わってきます。

 

このような時に例えば「●●単価」というキーワードを設定することで、

AIのほうでその記述がある場所の横を選んで単価情報を拾ってくることができます。

 

これは設定の手間を省くという使い方もありますが、

何よりもこれができる事によって必要情報が必ずしも定位置にない帳票についても情報取得が可能になります。

 

 

(c)テキスト認識(誤読学習)

活字情報であっても、先述した通り日本語は非常に文字種類が多く、OCR泣かせの言語であります。

誤読があった場合、人間の方で訂正をすることになるのですが、

AIの技術を使うことでOCRに学習させていき、精度をあげていくことが望めます

 

特に住所や名前といった情報は、実は人間が読む場合も頭の中で

ある程度人名・地名として有りそうな文字を想定しながら読み解いていると思います。

 

誤読→訂正を繰り返すことで、

人間が行っているような「想定」をOCRツールもできるようになります。

 

 

 

 

  1. まとめ

以上でOCRを使用する上での実務上のポイントと、

AIが使われる領域について大まかな概略を述べさせていただきました。

 

この技術自体は、まさに日進月歩の世界であり、

去年までは精度がイマイチだったツールが翌年は飛躍的に精度向上するケースもしばしば存在します。

 

我々のような業務改善コンサルティングやRPA導入支援を行っている会社としては、

まさにこのような技術の進展を日々ウォッチして、

クライアントの現状に合ったツールを選び、提案していくことが求められます。

 

 

 

 

 

中小企業におけるRPA導入の可能性

2018.10.22

目次

 

 

 

 

2017年度はメガバンクがRPA導入による業務量の大幅な削減、

そして、それに伴う大幅な人員削減がニュースになりました。

 

メガバンクに限らず、多くの大手企業がRPAに着目しており、

2018年以降、さらにRPAがニュースを騒がせることになるかと思います。

 

 

大手企業がRPAを推進する中、日本の99%を占める中小企業は蚊帳の外なのでしょうか。

過去を遡れば、テクノロジーは大企業を中心に発展し、

そこから中小企業へ浸透していくというかたちが一般的だったかと思います。

 

 

RPAの時代が始まった今、中小企業は大企業の様子を眺めているだけで良いのでしょうか。

 

今回は、その中小企業におけるRPA導入の可能性について考えていきたいと思います。

 

 

 

 

 

■中小企業はIT化が進んでいない

●中小企業ほど人に依存した仕事になっている

 

請求処理、経費精算、在庫管理、入金確認など、

定期的に発生する業務が、担当する人に依存した仕事になっていることが多い現状があります。

 

 

●そもそもITに興味がない

 

IT投資」に積極的ではない、とも言い換えることが出来るかと思います。

理由をいくつかあげてみます。

 

  • IT投資」が、直接的な売上に繋がるわけではないため。
  • IT」に精通した人材がいないため。とりわけ先端テクノロジーに対応出来る人材がいない。
  • 大企業の先行導入、他企業の導入の状況を観察。効果の確認と導入費用が安くなるのを待つため。

 

 

●IT化投資は多額の投資が必要

 

例えば、「在庫管理システム」を自社専用に開発出来る企業は多くはないでしょう。

 

大企業が使うパッケージシステムは、

中小企業にとっては投資額および機能面でオーバースペックでもあり、

また、実際に使うにあたって、必ずしも業務にマッチするとは限りません。

 

 

 

 

■RPAは低予算で簡単

RPAは一般的なシステム投資額と比べると格段の安さ

 

RPAはその種類によっても異なりますが、1台数十万円から使うことが出来ます。

 

また、RPA導入にあたって、ソリューションベンダが多数していますが、

中小企業においては、必ずしも必要ではありません。

 

 

RPAのソリューションベンダは、

複雑に跨る既存業務の分析とRPAへの業務置き換えに関するコンサルティングをメインとしており、

中小企業においては、そこまでを必要としない場合が多いと言えます。

 

 

 

RPAは小さく始められる(スモールスタート)

 

RPAは1業務から始めることが出来ます

例えば、「請求書の作成業務」のみを対象として始めることが出来ます。

 

その中でも、RPAを初めて使う場合は、様々な問題点が発生するかと思います。

 

トライアンドエラーを繰り返しながら、RPAを自社の業務に合ったかたちに作り出すことが出来ます。

 

 

●RPAは高い技術を必要としない

 

複雑な業務を対象とする場合を除いて、RPAは技術者でなくとも問題無く使うことが出来ます

(最初の数時間は慣れが必要ですが、オフィスソフトを使うのと同じような感覚です。)

 

 

もちろん、RPAの機能を使いこなす為には、研修などを通じて学習をすることが最適ですが、

スタートの段階では必ずしも必要ではありません。

 

 

●RPAに関する新サービスは続々と誕生している

 

RAPを月単位で使うことが出来るサービスなどが登場しています。

 

例えば、事務作業が集中する時だけRPAを使う、

または、RPAを増やすといったことも可能です。

 

複雑な業務をRPAに置き換える場合、

RPA上で必要となるプログラミングなどを代行してくれるというサービスもあります

 

RPAに関しては、今後も様々なサービスが登場してくるはずです。

 

 

 

 

■中小企業こそRPAが必要

●効果数字に大きなインパクトは無い

 

三井住友銀行はRPA導入により、

2017年上半期のみで、1年間あたり40万時間の業務量の削減を達成しています。

 

中小企業においては、このようなトピックスにあがるような効果を出すことは難しいでしょう。

しかし、インパクトでは無いところに、大きな意味が隠れているのです。

 

 

●中小企業特有の問題点

 

語弊がある言い方かもしれませんが、中小企業における事務作業は大企業と比較して、ミスが多い

という事実があります。

この原因は、

 

  • 担当者が多忙で作業が疎かになってしまった
  • 担当者が忘れてしまったor担当者が不在だった
  • 作業が平準化されていない
  • チェック体制が整っていない

 

という、いくつかの原因があげられます。

 

 

●RPAは中小企業の救世主に!?

 

RPAを導入することによって、

先に挙げた「中小企業特有の問題点」を全て解消することが出来ます。

 

人はRPAを監視する、または、RPAをフォローする役割に徹するだけで良いのです。

 

 

●RPAを業務量削減の指標のみに用いらない

 

RPAによる業務量削減にインパクトは中小企業においては少ないということは前述の通りです。

 

AIを含めた自動化は既存の仕事を奪う」と言われておりますが、

時間軸は別として、その流れがやってくることは間違いありません。

 

RPAにより、社員の

業務の視点が変わった/新しい知識を使いこなせるようになった

など、社員の意識変革もRPAのメリットの1つだと言えます。

 

 

 

 

■実際の中小企業におけるRPA導入

●IT人材派遣会社におけるメール活用例

 

毎日、メールで何十社(多いときは百社超)から派遣案件情報が送られてきています。

以前は、営業担当者はそれらの情報をExcelに転記をする作業が発生していました。

 

しかし、メールを1通1通確認する作業がある中で、

メールの見落としや内容の誤転記が発生していました。

 

そもそも、この作業自体に多大な時間を擁しており、本来の営業活動の時間を圧迫していました。

 

RPAがメールの中身をExcelに転記する作業を行うようになりました。

今後は、営業担当者は転記作業をすることなく、

これを営業情報の一次情報として活用するようになりました。

 

<課題>

送られてくるメールの中身は、会社毎(または、担当者毎)に、書き方が異なる為、

RPAが上手く拾えないケースが多々発生しています。

 

現在は一次情報としての集約に留まっており、詳細はメールを見に行く必要性があります。

 

 

●零細企業における事務負担の軽減

 

社員3人のコミックコンテンツ管理会社において、

10人超に及ぶコミック作家と、コミックの進捗管理やシナリオの進捗管理をメールでやりとりしていた。

 

社員各人が、それぞれ別々の管理方法でコミック作家とやりとりをしていた為、

1人のコミック作家に別々の社員が同じことを聞くということが発生していた。

 

メールの題名記入方法を統一化し、

RPAがメール(及び添付ファイル)をコミック作家別にサーバーにフォルダ保存することになった。

 

今後は、社員はフォルダを除くことで、

社員とコミック作家とのやりとりの履歴を一覧化して閲覧することが可能になった

 

<課題>

メールの題名記入を間違えた場合(文字コードが変わった場合なども)、

想定したフォルダに収まることが出来ず、行方不明扱いになってしまう。

 

この場合、気が付かないリスクと、その監視をどうするか、まだ決まっていない。

 

 

 

 

■まとめ

RPAの導入のしやすさと、使うことによるメリットが理解出来たかと思います。

中小企業の課題こそ、RPAの本領の発揮どころの1つだと言えます。

 

AIやビックデータといったキーワードも話題になっていますが、

これらはまだまだ、高い費用と技術力が必要な分野です。

 

こういった分野は大企業先行による後者利益を得ていくという方針が適切ですが、

RPAについては、先行者利益を得ていっては如何でしょうか。

 

労働市場は、これから益々切迫化していくことが予測されています。

人材の採用難と人材の流動化は今後益々進むことは確実です。

 

 

是非、RPAを上手く活用して事業に活かして頂ければ幸いです。

 

 

 

 

「Robotic Crowd」を開発した株式会社チュートリアルにインタビューしました!

2018.10.19

目次

 

 

 

 

株式会社チュートリアルのCEO福田志郎 氏(左)と、同社エンジニアの岩渕悠祐 氏

 

 

RPAツールで現在主流となっているのは

オンプレミスで導入・運用をする「オンプレミス型RPA」です。

 

しかし近年増えつつあるのが、

RPAの機能をクラウドサービスとして提供する「クラウド型RPA」です。

 

 

導入・運用コストを低減できるほか、

すぐ簡単に導入できるといった大きなメリットがあるクラウド型RPA

 

 

このジャンルへ新たに加わったのが、

株式会社チュートリアルの開発したRPAツール「Robotic Crowd」です。

 

そこで今回は同社にお邪魔して、

Robotic Crowd」の開発経緯やツールの特長などをお伺いしてきました!

 

 

 

 

 

💬SaaSでサービスを提供するクラウド型RPAツールです!


 

インタビューに応じていただいたのは、同社でCEOを務める福田志郎 氏です。

 

 

――そんなチュートリアルとRPAとの関わりは?

 

福田: 2年ほど前にRPAと出会ったのが始まりです。

Web開発やシステム開発の部分でRPAを活用すると、開発者としてもメリットがあると考え使い始めました。

 

前期からはRPAを業務として取り扱い始め、

今期からはRPAソフトウェアの提供やRPA事業コンサルティングを業務の主力の事業にしています。

 

 

――自社でRPAツールを開発しようとした理由はなんでしょう?

 

福田: RPAを事業として進めていくうちに、

RPAを事業として進めていくうちに、お客様がRPAに対して抱いている期待と実際のプロダクトの差が見えてきました。

 

お客様はRPAを自社で開発したいと思っているお客様が多かったのですが、

エンジニアやコンサルタントではない方がRPAの開発に携わるというのは、実際はなかなか難しいことです。

 

そこで誰でも簡単に使い始めることができるSaaSのRPAを探しましたが、

拡張性・汎用性・入門しやすさを兼ね備えた、ちょうど良い製品がありませんでした。

そこで、自社で開発をはじめたわけです。

 

RPAが注目されたキッカケの一つとして、生産性の低さに加え労働人口が減少しているという背景もあります。

RPAは、それらの課題を解決しうる技術なのですが、RPAの開発にエンジニアが必要となってきますと、

人材市場でもっとも不足していると言われるエンジニアの奪い合いとなってしまいます。

 

そこで「Robotic Crowd」は、

非エンジニアでも簡単に使える

Excelのように、簡単に使えるだけでなく、深掘りしたら高度な使い方もできる

というRPAツールを目指しました。

 

 

 

 

 

💬クラウド型だから、他の作業のバックエンドでロボットが稼働し続けます!


 

――「Robotic Crowd」の特長を教えてください。

 

福田: 最大の特長は、SaaSとして提供していることです。

そのため、パソコン、Webブラウザ、インターネット環境さえあればすぐに使い始めることができます。

MacWindowsLinuxなど、Webブラウザが使える環境であれば、OSは問いません。

 

SaaSとして提供されるクラウド型RPAツールであるため、

スケーラビリティがあり、端末を新規購入せずともロボットリソースを追加購入いただくだけで

クラウド上でロボットを増やしていくことが可能です。

 

また、クラウド上で動いているために、バックエンド処理をデフォルト機能として搭載しています。

例えば、端末上で人間が別の作業をしていても、端末の電源を落としていても、

クラウド上でロボットが作業を続けます。

 

また、夜間や休日など、好きな時間を設定しておけば、

そのスケジュールで業務を遂行してくれるタイムスケジューリング機能もあります。

 

Robotic Crowd」は、まさにEUCEnd User Computing/エンドユーザコンピューティング)

実現するための基本的な機能が備わっていると考えています。

 

 

――ライセンス体系はどのようになっていますか?

 

福田: 月額10万円から導入いただけます(2018年10月現在)。

ロボット単位の課金ですので、組織内でRobotic Crowdを利用するユーザーをいくら増やしても大丈夫です

(注:プランによって異なります)。

少ししかRPAを使わない方や部署でも、気軽に始めることができるのが特徴です。

 

 

――サポートは別料金になりますか?

 

福田: リモートサポートになりますが、基本的なサポートは料金内に含まれています。

このリモートサポートを利用して「Robotic Crowd」の使い方を習得していただけます。

 

ユーザーコミュニティやFAQもありますので、すぐに答えを知りたい方は検索する方法もあります。

個別のテクニックやサードパーティ製品についてのサポートは対象外となっておりますが、

コミュニティでは質問内容に制限はありませんので、使いこなしやナレッジ共有が可能です。

 

このような環境を利用することで、リモートサポートを利用せずに使いこなしている方も沢山いらっしゃいます。

 

 

――「Robotic Crowd」は、どのような業務に向いているでしょう?

 

福田: 社内ではなくクラウド上で業務を遂行してくれるので、イメージとして

リモートワーカーやアウトソーサーが行っている業務であれば適用できる部分が多いと思います。

 

一方で、必ず社内にいないとできない業務には対応できない可能性は、

それなりに高いと考えていただけるといいかもしれません。

 

そのような業務には従来型のRPAを導入し、

社員が自由に使えるRPAとしては「Robotic Crowd」を選んでいただければと思います。

 

「Robotic Crowd」は、様々な業務に対応が可能なため、どのような企業でも導入は可能ですが、

もっとも合っているなと思うのは「レイバーインテンシブな成長を好まない成長企業」だと思います。

 

 

 

 

 

💬既存RPAツールと共存できるツールです!


 

――やはりベンチャー企業での導入事例が中心でしょうか?

 

福田 いえ。当社としてもスモールカンパニーやスタートアップ企業での利用を想定していましたが、

結果としては、比較的大規模な上場企業のお客様に導入いただいています。

 

社名を公表できるところでいえば、DeNAWANTEDLYdipACTCALLです。

やはりWeb上で、事業を展開している企業のほうが「Robotic Crowd」と親和性が高いようです。

 

 

――「Robotic Crowd」採用の決め手は?

 

福田: いくら低価格だったり簡単に導入できたりしても

「あれもできない、これもできない」というツールだと採用されないようです。

 

その点、「Robotic Crowd」は汎用性があり

RPAツールとしてしっかりとした機能を持っている点をご評価いただいております。

 

 

――「Robotic Crowd」の今後の展望を教えてください。

 

福田: 今後も常に機能を進化させていく予定ですが、将来的には,もっと「ヒューマンライクなツール」にしたいと思っています。

 

RPAは、入力値に仕様と異なるところがあると簡単にエラーになってしまいます。

人間なら柔軟に判断してできるようなものでも、少しでもフォーマットが異なるとエラーになります。

もっとヒューマンライクなツールに進化させていくことで、それを解消していきたいですね。

 

 

――最後に、RPA.biz読者へのメッセージを!

 

福田: 「Robotic Crowd」は既存のRPAツールを導入していても共存RPAです。

Robotic Crowd」を本格導入していただいたお客様の中には、

既にRPAを導入しているものの、社内展開するには手軽さに欠ける

と弊社ツールを導入いただいているお客様がいます。

 

 

Robotic Crowdは、「誰もが自由に使えるツール」という思想で開発しています。

 

既存RPAツール導入済みの企業でも、新規にRPAを導入されたい企業でも、お気軽にご相談ください。

 

 

 

 

【UiPathの基本】「データ入力」と「データ抽出」

2018.10.18

UiPathで作業の自動化を行うにあたって、データの「入力」と「抽出」はとても基本的な行為です。

 

ここをしっかりと理解していないと、これから自動化する過程において、

どのアクティビティを使用するのかが判断しづらくのでしっかり理解しておきましょう。

 

 

 

「入力」とは英語に言い換えると、「Input」ということです。

さまざまな状況下で色々なフィールドに入力することがあると思います。

 

 

例えば、ログイン画面でIDとPASSを入力したり、スプレッドシートに書き込んだり、

チェックボックスをチェックしたりということもInputの一つに入るでしょう。

 

「抽出」とは、数ある中からある特定のものだけを取り出す、ということです。

簡単に言えば、必要な情報をうまく取り出して扱えるようにするということです。

 

自動化を行っていく上で、この「抽出」という行為は基本であると思います。

 

例えば、ウェブページからURLを取り出したり、CSVファイルの中身を読み込んだり、

Ui要素を探す行為もまた「抽出」の一つに入るでしょう。

 

 

 

この「入力」と「抽出」のやり方を具体的に見ていきたいと思います。

それぞれにはそれぞれのアクティビティがあり、それぞれに使い分けが必要になります。

 

 

 

 

入力


 

まずは、「入力」からです。

最初にいくつかの「入力」のアクティビティを見ていきます。

 

 

 

●「Click

指定したUi要素をクリックします。

 

プロパティによって、マウスのボタンを左、右、中央と変えることが可能です。

(*既定では左に設定されています。)

 

また、同じくプロパティによって、マウスクリックの種類を選ぶことが可能です。

シングル、ダブル、アップ、ダウンへと変更可能です。

(*既定ではシングルに設定されています。)

 

これにより、ウェブページのボタンをクリックしたり、

チェックボックスにチェックすることができます。

 

 

●「Send hotkey

指定したUi要素にキーボードのショートカットキーを送信します。

 

単にキーボードのキーを送りたいときにももちろん有効です。

 

また、最初にいくつかの設定は必要になりますが、これを使用することによって、

アプリケーションをショートカットキーのみで開くことが可能です。

 

色々と面倒な、アプリケーションのパスを入力しないでよいという点を考えると

非常に使いやすい方法となります。

 

 

●「Hover

指定されたUi要素の上にカーソルを置きます(Ui要素の上でホバーします。)

 

アイコンなどをドラッグ&ドロップするときに使用します。

 

クリックダウン→ホバー→クリックアップ

 

の順で使用することにより操作可能です。

 

なお、クリックアップとクリックダウンは先ほどの「Click」アクティビティを使用します。

 

 

●「Type Into

指定したUi要素にテキストを送信します。

 

テキストだけでなく、[Tabキー]のような特殊キーも送信可能です。

 

このアクティビティを使うことが一番多いでしょう。

 

 

 

だからこそ注意しないといけないことが多いです。

 

では、一つずつ見ていきましょう。

 

 

まずは、特殊キーです。

先ほども少し説明したように、[Tabキー][Enterキー][Shiftキー]なども送信可能です。

アクティビティのドロップダウンリスト(下に出てくる候補)から送信可能です。

 

 

次に、前の内容を消去してから書き込む方法をお教えします。

それが、EmptyFieldです。

 

このチェックボックスをオンにすると、テキストを書き込む前にすべての要素が消去されます。

 

これは、テキストフィールドが今どのような状態か考えなくても、

必ず何もない状態から始めることができるものです。

 

 

 

ここからはオプションの違いを説明します。

 

簡単に言うと、オプションの違いは三つあります。

<Default><Window Message><Simulate>

の三つです。

 

 

それぞれの特徴をまとめます。

 

 

<Default>

デフォルトの状態のもので、文字送信の正確性は高いです。

特殊キーを送信することができますが、バックグラウンドで使用することができません。

そして、速度も遅いです。

 

 

<Window Message>

基本的に上のデフォルトの状態と同じですが、こちらはバックグラウンドでも使用可能です。

その分、小文字しか入力できないという欠点を持ちます。

 

 

<Simulate>

この三つの中では一番早く動きます。

しかし、特殊キーを送ることが出来なかったり、

エンプティーフィールドに文章を打てないなどの欠点を持ちます。

 

 

 

最後に、これらを表にまとめたものがありますので、よろしければご覧ください。

(UiPath Studio ガイドより抜粋)

 

 

 

 

このように入力には様々な種類が存在し、

その中でもTypeIntoアクティビティは様々なオプションなどが存在するので、

理解して使用していきましょう。

 

 

 

 

抽出


 

次は、抽出です。

ウェブページなどから必要なデータを取り出すということです。

 

こちらも多くの方法が存在するのですが、そのいくつかを見ていきましょう。

 

 

●「Get Text

表示しているターミナル全体からテキストを取得して文字列変数に格納します。

 

 

●「Screen Scraping

この方法は、指定したUi要素やPDFファイルのようなものから、

データをうまく抽出するアクティビティです。

 

 

その中にも三つの方法が存在します。

 

<FullText><Native><OCR>

 

これらはそれぞれに短所や長所がありますので、用途によって使い分ける必要があります。

 

 

 

これらについて、特徴をまとめます。

 

 

<FullText>

これがデフォルトで設定されているメソッドで、基本的にこのメソッドで補うことが出来ます。

スピードも速く、正確性も高いです。

さらに、バックグラウンドでも使用可能で、隠れている要素なども見つけることができます。

 

 

<Native>

テキストやボタンの位置座標などを特定して、抽出することが可能です。

 

 

<OCR>

その名の通り、OCR技術を使用して、仮想環境のCitrix環境下でも使用可能です。

画像として認識するため、テキストなどの位置座標を特定、抽出するすることが可能です。

 

 

 

また、これらは以下のような対応関係があります。

 

 

 

このようにそれぞれのメソッドに対応したアクティビティが存在するのです。

実は、最初に説明した「GetText」はBasicRecordingに対応しているのでした。

 

 

また、ScreenScrapingのメソッドを表にまとめたものがありますので、よろしければご覧ください。

(UiPath Studio ガイドより抜粋)

 

 

 

●「DataScraping

これを使用すると、ウェブページやアプリケーションの構造化データを抽出して、

CSVファイルやExcelファイルへと書き込むことが可能です。

 

構造化データとは、様々な同じパターンのデータのことで、

 

例を挙げると、検索結果のページには、

ウェブページのリンク、URLの文字列、ウェブページのタイトル

などがパターン化されていくつも並んでいます。

 

これらの構造化データを簡単に抽出することができます。

 

構造化したデータの抽出はとても簡単で、対応するデータを順番にクリックしていくだけです。

 

 

 

 

例をお見せしましょう。

これは、BingでUiPathと入力したときの検索結果です。

 

 

0、「UiPath」の検索結果

 

 

ここから、ページのタイトルとURLを取り出します。

 

リボンの上にある、DataScrapingをクリックしてデータ抽出をはじめてください。

次に、NEXTを押して、要素をクリックします。

同様に、続けて、NEXTを押して、次の要素をクリックします。

以下に進行画像をのせます。

 

 

1、DataScrapingはじめの画面

 

 

2、はじめに抽出するUi要素

 

 

3、二回目へと続くDataScrapingの画面

 

 

4、二つ目のUi要素

 

 

ここまで来たらあとは勝手にUiPathが次の要素も見つけてくれるので、

最後は、列に名前をつけたら終了です。

 

 

5、列の名前付け画面

 

 

このように、とても簡単に構造化したデータを抽出することができます。

 

抽出にもたくさんの種類が存在しました。

理解して使用できるようになりましょう。

 

 

 

 

まとめ


 

自動化の基本となるデータの「入力」と「抽出」を見てきました。

 

それぞれ、いくつもの方法が存在して、それぞれに特徴がありました。

 

それらを場合に応じて、使い分けられるようにしっかりと理解していきましょう。

 

 

 

 

【自動運転】いま私たちが考えないといけない事

2018.10.17

目次

 

 

 

 

RPA人工知能(artificial intelligence:AI)という言葉は、

最近では聞かない日はないほどブームなっています。

 

これらは、人間の行っているようなことを的確に、そして素早く行うことができるとされています。

 

 

これからの時代の流れで、このような所謂ロボットのようなものは

人間が生活していくうえで必要不可欠であるとさせることが予想されます。

 

 

 

 

●自動運転車

 

特に最近の研究で注目されている分野の一つが、「自動運転」です。

 

今現在、世界の各企業も勿論のこと、日本のトヨタなども自動運転の研究を進めています。

 

もうすでに自動ブレーキなどがついている車も存在しますが、

今後様々な自動運転車が世に出ていくことでしょう。

 

 

 

 

●自動運転車のレベル

 

そもそも自動運転車にはSAE(米国自動車技術会)で定義されたと自動運転のレベルがあります。

 

 

 

 

レベル0~2まではこの世の中に存在する機能です。

 

レベル1はステアリングか加速度のどちらかをサポートするものです。

ステアリングとはかじ取り装置のことで進行方向を変えてくれます。

 

レベル2はステアリングと加速度の両方をサポートしてくれます。

 

これらは「運転支援」と呼ばれていて、「自動運転」ではありません

 

 

 

今現在、自動運転車として定義されているのはレベル3からです。

レベル3以降のレベルではロボット(人工知能)が状況を判断して運転を行っていきます。

レベル4,5,6関しては状況に応じてですが、人間の操作を必要としない状態が存在します。

 

 

 

ここで問題になってくるのは、事故などの問題なのですが、

その問題を考える際に重要になってくるのはここで判断しているロボットが、

「人間の倫理観のような概念が存在するのか」

ということです。

 

 

 

 

●人工知能の苦手分野

 

この問題を考えるために、

昔からある、とても有名な「トロッコ問題」という論理学の問題について考えてみましょう。

トロッコ問題には様々な派生問題がありますが、今回はこのような問題を考えてみたいと思います。

 

線路を走っていたトロッコの制御が不能になった。このままでは前方で作業中だった5人が猛スピードのトロッコに避ける間もなく轢き殺されてしまう。

この時たまたまA氏は線路の分岐器のすぐ側にいた。A氏がトロッコの進路を切り替えれば5人は確実に助かる。しかしその別路線でもB氏が1人で作業しており、5人の代わりにB氏がトロッコに轢かれて確実に死ぬ。A氏はトロッコを別路線に引き込むべきか?

 

このような状況に陥ったとして、あなたならばどうしますか?

 

いや、少し変えてみましょう。

 

これからの将来の事を考えるとすると、

もしもトロッコが自動運転車だったとして、自動運転車はどのようにするべきだと思いますか?

 

 

この問題は「功利主義」と「義務論」という対立で語られています。

 

功利主義とは、なによりも結果を重要視して、1人の命よりも5人の命の方が大切だと考えて舵を切る考え方です。

 

対して、義務論はどのような結果になろうと人を殺すという行為をするべきではないと考えて舵を切らない考え方です。

 

 

 

この問題は我々人間が考えても必ずしもこちら側であると結論付けることは難しいです。

一人を犠牲にできる人もいれば、誰も自分の手で殺したくないと思う人もいるでしょう。 

 

しかし、それではこれを自動運転のロボットにさせることはできません。

 

人工知能はディープラーニングなどで学習をするといっても

何もないところからいきなり答えが導き出せる訳ではありませんし、

 

答えが決まっていない問題を考えさせることは人工知能にとって「苦手」なことなのです。

 

 

 

 

 ●人工知能が答えのない問題を苦手とする理由

 

それを体現しているのが「フレーム問題」と呼ばれるものです。

 

この問題は、今でも人工知能分野での最大の課題の一つと言われています。

フレーム問題をざっくり説明すると、このようなものです。

 

ある日、植物が枯れてしまいました。そこで人工知能に「なぜ植物は枯れてしまったのだろう?」と問いかけます。するとこの人工知能は植物が枯れた時間や場所、さらには植木鉢の色や植物の音声などを調べます。もしかするとその時の政治状況や流行りの歌なども調べるかもしれません。

 

 

このように、人工知能はありとあらゆるものを調べ上げます。

これはフレーム(枠)が確立されていないためです。

フレームは関係あるものとないものの境界線とも言い換えられます。

人間は無意識的に関係あるものとないものの判断をしているのです。

 

今挙げた中だと、政治状況や流行りの歌なんかはほぼ確実に関係ないにも関わらず調べてしまっています。

ロボットにこれらは関係ない(フレームの外である)ということを教えるためには

しっかりとした境界線を教える必要があります

 

 

植物が枯れる、のような状況ではフレームは考えやすいかもしれないですが、

 

例えば、「この爆弾を爆発しないように運べ」みたいな時には

どのようなことを考えるべきでしょうか。

 

このフレームは簡単には決まらないと思います。

 

 

 

このように、答えがないような問題は人工知能にとっては「苦手」な分野なのです。

 

 

 

 

 ●事故の責任はどこにあるのか

 

また、自動運転車に関する問題は他にもあります。

 

それを説明するのに使うのは、「トンネル問題」というものです。

 

あなたが乗っている自動運転車が、1本の車線の山道を走行しています。トンネルに入る直前に、子どもが道路を横切ろうとしています。しかし、車は急速に車道の中央を走行しているため、子どもを避けようとするとトンネルの壁に突き当たります。

車には2つの選択肢があります:子どもをひき殺すか、トンネルの両側にある壁に突き当たり車を破壊する。車はどうするべきですか?

 

この問題がトロッコ問題と違う点は、比較対象が同乗者以外どうしの比較なのかそうでないかです。

トロッコ問題では、舵を切って1人を助けるか、それとも5人を助けるかの問題でした。

 

つまり殺されるのは両方とも自分でない人でしたが、今回は自分も被害者に入っています。

 

ここで課題になってくるのは、「誰がこの判断を下すか」です。

 

 

この問いに対して、Open Roboethics Initiativeがおこなったアンケートでは

44%の人が、議員が議論して提示するべき

33%の人が、乗車している人が決定するべき

12%の人が、車メーカーが決定するべき

と回答しました。

 

これを見ても分かる通り、自動運転車をつくっている会社が判断するのではなく、

その場の人間や一般的なルールを決めておくべきだと考える人が大半のようです。

 

 

あくまでも推測ですが、自動車メーカーはお客様である人を犠牲にするような

プログラムを書くとは思わないので、少しばかり不安になるのだと思います。

 

 

そして、議員さんに決めてもらうという意見については

少しばかり非現実的なのではないかと考えています。

 

問題となるケースごとに考えているのではきりがないですし、

同じことばかりが起こるわけではないのですべてを決めるのは理論的に不可能ではないかと思います。

 

 

 

しかし、これもまた答えがない問題で、これから我々人間が考えないといけない問題です。

 

すでに、アメリカでは死亡事故も起きていますし、早急な話し合いが必要になりそうです。

 

 

 

 

 ●まとめ

このように自動運転一つとっても、

これから実用していくうえで我々人間が考えないといけないことが山積みです。

 

 

これからつくられていくロボットとどのように接していくべきなのかは実用に向けて

様々な観点での多くの議論としっかりとした着地点を見つける必要があります

 

 

 

 

 

●参考文献

 

*1) トロッコ問題  Wikipedia

https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AD%E3%83%83%E3%82%B3%E5%95%8F%E9%A1%8C

 

 

*2) An ethical dilemma: When robot cars must kill, who should pick the victim?Robohub

https://robohub.org/an-ethical-dilemma-when-robot-cars-must-kill-who-should-pick-the-victim/

 

 

 

 

 

 

地方自治体におけるBPO【vol.6】・・・RPA

2018.10.16

目次

  1. 債権の種類
  2. 滞納処分
  3. BPOについて
  4. RPAの適用について
  5. まとめ

 

 

 

 

 

【前回の記事はこちら】 

地方自治体におけるBPO【vol.5】・・・RPA

 

 

これまでBPORPAについて述べてきましたが、具体的に私が知る範囲でお伝えしたいと思いますが、

民健康保険の給付などはシステムなど確認する点が多いため、

書き上げるのに時間がかかりそうなので徴収部門を中心にしたいと思います。

 

 

はっきりとお伝え出来ない部分もあるので、

BPOについてより詳しく知りたい方はご連絡を頂ければ幸いです。

 

 

 

 

1.債権の種類


 

地方自治体で業務上発生する債権は、公債権私債権があります。

 

公債権の中でも強制徴収公債権非強制徴収公債権に分かれます。

 

 

強制徴収公債権非強制徴収公債権私債権は、

 

発生効果回収消滅

 

以上の4つのポイントで分かれます。

 

 

 

強制徴収公債権とは、個別の法令の根拠規定により、市が滞納債権について地方税法の例による

滞納処分(給与・預貯金・不動産などの差押えや担保権の実行など)を行える債権

 

例:市税・後期高齢者医療保険料・介護保険料・保育料・国民健康保険

 

 

 

非強制徴収公債権とは、強制徴収公債権とは異なり、個別の法令に根拠規定がないため、

滞納処分が行えない債権

 

例:行政財産使用料・し尿収集手数料・生活保護費返還金

 

 

 

私債権とは、契約などの当事者間の合意(私法上の原因)に基づき発生する債権

 

例:市営住宅使用料・奨学金返還金

 

 

 

公債権と私債権の違いは、その債権の発生原因が、公法か私法かの違いです。

 

強制徴収公債権と非強制徴収公債権は滞納処分差押・換価・配当)ができるかどうかで分かれます。

 

 

 

 

2.滞納処分


 

一般的には、人の財産を差し押さえる場合、

裁判所に行って民事執行手続きを行い、国が差し押さえるという流れになっています。

 

 

強制徴収公債権はそのような手続きをせずとも、

督促状1通送って納付がなければ、地方自治体自ら差押を実施することが可能な債権です。

 

テレビ番組で市役所の職員が差押を実施しているシーンなどが放送されることがあります。

 

 

私自身は徴税吏員(市職員で公法上の判断ができるもの)でもないので、

そのような場面は立ち会ったことはございませんが、

差押から戻ってきた職員を見かけることは多々ありました。

 

 

一つの自治体で差押を実施しなければならない債権の数(対象者)は何万とあります。

 

しかし、実際は何万もの対象者の財産を差し押さえることは難しく、

差押対象者数を減らすために、様々な働きかけをしています。

 

 

 

 

3.BPOについて


 

差押対象者数を減らすための働きかけの1つがコールセンター(アウトバウンド)による電話催告です。

その次に文書催告です。

 

 

徴収部門の職員は、滞納者に電話もしくは書面にて納付するよう働きかけることが日々の業務です。

職員が電話催告する自治体は少なく、文書催告がメインとなっています。

 

BPOで民間委託する場合、コールセンターによる電話催告、事務センターによる文書催告です。

 

コールセンターであれば1日のコール件数は100~200件ぐらい、

事務センターであれば文書催告作成件数は50~100件ぐらいが、目安かと思います。

 

コールセンターのコールをRPAではなく、ロボットにさせたことがありますが、

効果があまり芳しくなかったため、

コールセンターの自動化というのは少し停滞していると聴いています。

 

 

RPAと相性の良いのは文書催告だと思います。

 

 

基本的な業務の流れとして、対象者(滞納者)一覧リスト滞納者の画面を見て、文書催告の可否を判断し、

Excelや債券回収システムに内蔵されている文書作成のフォーマットを使って

催告文書を作成する、というのが大まかな流れです。

 

 

対象者一覧リストの作成は、自治体の職員が抽出しているケースや民間業者(債権回収システム会社)

に委託しているケースもありますが、基本的にリストが出来上げるのが遅いです。

 

エラーも多く、毎月発生する業務なのに、フォーマットが決まってないせいか、

分析データを作るのに時間がかかったりしています。

 

 

画面を見て判断する場合、一定のルールに基づき

それに該当するかしないかをBPOオペレーターが滞納額、接触回数、接触内容などを

一定のルールに基づいて文書催告の可否判断をします。

 

 

文書催告が可能と判断した場合、

BPOオペレーターがExcelで作成された文書催告用のフォーマットに

債権回収システムのデータをコピーアンドペーストしたり、

債権回収システム上で文書催告を作成したり、

 

債権回収システムによって業務フローは千差万別ですが、

人海戦術である程度の件数をこなしているような状態です。

 

複数の団体の情報を知っていますが、非効率極まりないやり方でやっています。

 

 

大体おおよそこのような流れの中で、RPAを使って運用できる場面があります

 

 

 

 

4.RPAの適用について


 

まず対象者一覧リストの作成です。

 

滞納者を抽出し、抽出した滞納者からある一定条件(生活保護受給者や死亡など)

の対象者を除いていく作業です。

 

抽出条件に誤りがあって、

BPO業者のところにリストが来るまでに時間がかかりすぎてしまうことが良くありました。

 

 

難しい内容ではないのですが、Excelが苦手な職員が作成したり、

担当職員が長期休暇などで別の担当者が臨時で作成した場合、

1週間ズレることがあり、徴収計画も遅れてしまうことがあります。

 

 

滞納者一覧リストの作成方法は、Excelにあるデータをフィルタで加工する業務であり、

RPAに作成してもらった方が早いのではないかと思う業務の一つです。

 

 

 

また1人の担当者で作成してブラックボックス化し、リカバリーに時間がかかります。

 

このブラックボックス化は地方自治体では多々あります。

結局ブラックボックス化を防げないのであるならば、

RPAでブラックボックス化した方がいいのではないかと思えてしまいます。

 

変えることができないことに時間を費やすよりそれを前提で組み立てた方が早いと思います。

 

 

 

文書催告の可否については、判断の分かれるところですが、

RPAに一定水準は抽出させても良いのではないかと考えています。

 

50件に1件程度、判断に悩むものがありますが、

それ以外は一定のルールのもとに判断は可能であり、その抽出は可能かと考えています。

 

この点の運用について一定のルールを策定する点がポイントになるので、

優秀な職員、徴収率の高い他の自治体、優秀な社員がいる民間事業社などに聞くとよいかと思います。

 

 

 

文書催告の作成については、RPAで対応できるかと思います。

業務改善好きな私が担当したとある自治体で、生産性を10倍ぐらいに上げたことがありますが、

せいぜい10倍程度しか上げることができません。

 

生産性を上げる最大のネックになっていたのが、作業の大半を占めていたコピーアンドペーストでした。

 

 

自分でRPA導入後の試算してみたら、生産性が100倍くらいになりました。

 

いつもコピーアンドペーストを頑張っているBPOオペレーターの腱鞘炎も緩和するのにと思いつつ、

BPOオペレーターの仕事を奪いかねないと思い、その思いを封印した記憶があります。

 

 

 

 

5.まとめ


 

色々な債権回収システムを使って業務をしてみましたが、

地方自治体に使われているシステムや人そのものが、やはり旧態依然としており、

工夫できる部分はかなりあります。

 

 

私自身、必要があればクライアントに対してハッキリと物を申すので、

結果的に組織を変えていただくこともいたしました。

 

目的があり、その目的を達成するために必要な作戦や戦略を考えます。

 

RPAはツールの一種であり、目的達成のため、

その経過で楽をするためのものであり、手段の一つです。

 

RPA導入を目的としてしまっているような発言をする人が多々見受けられる業界です。

 

 

 

RPAの導入目的は、

 

生産性を上げ、付加価値活動時間の生成、

 

この2点を目的とし、その目的を明確に民間事業社に伝えるべきだと思います。

 

 

民間事業社はRPA導入を目的とし、

生産性を上げる、付加価値活動時間の生成、

この2点を目的にしていない事業者が多いので、

 

RPAというツールが話題になっているこの数年、

地方自治体の民間事業者を見抜く力が求められているように思います。

 

 

 

 

 

【経理】税務業務におけるRPA

2018.10.15

目次

  1. 法人税
  2. 消費税
  3. 法人事業概況説明書
  4. 勘定科目内訳書
  5. 電子申告
  6. 個人住民税
  7. 源泉所得税・法定調書
  8. 償却資産税

 

 

 

 

 

大企業や会計事務所で行われている税務業務は専門的な判断を要する場面もありますが、

申告書作成ソフトウェアが進化している現代においては、

専門的な判断を要しない単純作業の割合も多くなってきています。

 

 

中小企業は税務会計で会計処理されている場合が多く、

法人税申告書での調整項目がほとんどないこともあります。

 

中小企業の法人税や地方税、消費税の申告書作成を代行している会計事務所では

申告書作成業務の一部にRPAを適用することにより、

申告書作成業務に係る人の手間を省くことができます。

 

 

今回は会計事務所向けに、

中小企業における法人税、消費税、個人住民税、源泉所得税などの税務業務について、

RPAで置き換えができる業務について紹介していきたいと思います。

 

 

 

 

1.法人税

(1)会計ソフトからの会計データエクスポート

会計ソフトから、総勘定元帳・補助元帳・仕訳帳・試算表などをエクスポートします。

 

会計記帳の段階で申告書作成を前提とした補助科目の設定をすることによって

申告書の作成をスムーズに進めることが期待できます。

 

補助科目の設定については各クライアントでバラツキが出ないように標準化を図ることがポイントです。

 

 

(2)税務申告に必要な勘定データの抽出(ワーキングペーパーの作成)

税務申告に必要な勘定データを上記(1)でエクスポートしたデータから抽出します。

 

例えば、

法人税申告書の別表15「交際費等の損金算入に関する明細書」

に必要な交際費等の金額を交際費勘定から抽出し、ワーキングペーパーに記録します。

 

データ抽出に必要な申告書転記用のマッピングルールの作成・管理はRPAでの置き換えが難しいため、人が行います。

 

同様に寄付金、賞与引当金、受取利息・配当金などもRPAによりワーキングペーパーが作成できます。

 

 

(3)申告書作成ソフトへの転記

上記(2)で作成されたワーキングペーパーの内容を申告書作成ソフトへ転記します。

 

イレギュラーな税務調整項目やマニュアル計算が必要なものは従来通り手入力となります。

未払法人税勘定計上前の当期純利益についても会計ソフトから、

法人税申告書の別表4「所得の金額の計算に関する明細書」へRPAにより転記することができます。

 

 

(4)未払法人税等の記帳

申告書で計算した、法人税・地方税の未払法人税等の記帳し、

最終の当期純利益を別表4に再度転記します。

 

税務申告書のレビュー用に申告書の印刷や所定フォルダへのPDF保存も行えます。

 

 

(5)申告情報(申告のお知らせ)のダウンロード・保存

例年電子申告を行っていると紙の申告書が郵送されない代わりに、

e-Taxのメッセージボックスに「申告のお知らせ」が格納されます。

 

申告のお知らせには申告期限の延長の有無や、

申告の種類(白色・青色)中間納税金額などが記載されています。

 

申告書作成前にこれを印刷やPDF保存している方は多いのではないでしょうか。

 

 

各担当者が自身で印刷等を行っている、

又はアシスタント職員が申告月の同じクライアントをまとめて印刷等を行っている場合、

 

いずれの場合も、RPAを活用することにより、

人の手を加えることなく申告のお知らせの情報を入手することができます。

 

 

 

 

2.消費税

(1)申告基礎データの取得

多くの会計ソフトには消費税の集計機能がついています。

その集計された数字を申告書作成ソフトに転記することに消費税申告書が作成できます。

 

RPAは、

課税売上非課税売上輸出免税課税仕入対象外

など情報を申告書作成ソフトに転記することできます。

 

各勘定科目の課非判定についてもある程度RPAで行うことはできますが、

専門的な判断を要する場面もありますのでここは人が行った方がいいと思います。

 

 

(2)未払消費税等の記帳

申告書で計算した未払消費税等の記帳をし、消費税精算差額(雑収入or雑損失)の計上も行えます。

申告書のレビュー用に申告書の印刷や所定フォルダへのPDF保存も行えます。

 

 

(3)申告情報(申告のお知らせ)のダウンロード・保存

消費税の申告のお知らせを印刷・保存を行います。

申告書のお知らせに記載されている中間納付消費税額も申告書に転記できます。

 

 

 

 

3.法人事業概況説明書

(1)主要科目情報の入力

会計ソフトと申告書作成ソフトが違うメーカーの場合(会計は弥生会計、申告書はミロクなど)、

法人事業概況説明書1枚目(表面)の「10主要科目」の各欄を手入力する必要があります。

 

単純作業ではありますが、

決算業務の一部として各税務担当者や税理士が自身で入力していることも多いのではないかと思います。

 

RPAでは、会計ソフト又は上記1.(1)でエクスポートした試算表データから

必要な科目・数字を抽出し法人事業概況説明書に入力することが期待できます。

 

 

(2)月別の売上高等の入力

法人事業概況説明書2枚目(裏面)の「18月別の売上高等の状況」についても

3.(1)と同様の方法で対応できます。

 

 

 

 

4.勘定科目内訳書

(1)科目情報の入力

法人事業概況説明書と同様の方法で、入力項目をおおむねカバーできます。

 

 

 

 

5.電子申告

(1)電子送信

作成完了した申告書のデータ変換はRPAが行えますが、

データ変換後の申告書の確認は人が行います。

 

データ変換後の電子送信はRPAが行うことができます。

 

電子送信は、帳票の枚数にもよりますが時間がかかる場合がありますので、

何か違う作業を行っている間にRPAに稼働してもらう方法もあります。

 

 

(2)申告書・メール詳細の印刷・保存

電子申告後の申告書及びメール詳細を印刷することができます。

また印刷した申告書とは別にPDFで保存する場合も多いと思います。

 

PDFの保存もRPAが活用できます。

 

法人税や消費税の申告時はもちろんですが、所得税の確定申告時期には大きな効果が期待できます。

 

 

 

 

6.個人住民税

(1)新年度の住民税データの登録

毎年5月頃になると、各市区町村から住民税データが通知されます。

 

紙で郵送されることが一般的ですが、電子データで納税通知データを取得することもできます。

 

 

電子データで取得するためには、

給与支払報告書提出時に、特別徴収税額決定通知の受取方法で「電子データ」を選択する必要があります。

 

電子データで取得できた場合には、RPAにより、

各人の1年間分の住民税データを給与計算ソフトに登録することができます。

 

紙の特別徴収税額決定通知書の場合でも、各市区町村のフォームはある程度同じである為、

 

OCRを利用することにより、給与計算ソフト登録に必要な電子データに変換して毎月の控除金額を登録することが可能になります。

 

 

1回の作業ですが、5月~6月は3月決算作業で繁忙期のため、

給与計算を多く行っている会計事務所ではRPA活用による効果が大きくなると思われます。

 

 

(2)納税

個人住民税の納税をインターネットバンキングで行うことは一般的になっているかと思います。

インターネットバンキングへの住民税登録は手入力している場合はその作業をRPAに代替できます。

 

 

 

 

7.源泉所得税・法定調書

源泉所得税・法定調書のRPA活用については以前の記事を参考にしてみてください。

 

源泉所得税・支払調書とRPA

 

 

 

 

8.償却資産税

償却資産税については、固定資産管理ソフトの中で完結することが多いため、RPAの出番は少ないですが、

申告書の電子データの作成・電子送信・申告書印刷/PDF保存についてはRPAに任せることができます。

 

償却資産税はすべての会社が1月末までに申告する必要があり、

申告時期が集中することからRPA活用のメリットは教授できるのではないかと思います。

 

 

 

 

 

電子請求システム「BtoBプラットフォーム 請求書」の概要と導入事例

2018.10.12

 

現在、日本国内においても企業内の経理業務は、IT化(電子化)が進んでいます。

普及の理由として、IT化によって効率化を行いつつ、コスト削減が可能になる事があげられます。

 

 

今回は、株式会社インフォマートが提供するITシステム

BtoBプラットフォーム 請求書」について、事例と共に説明していきたいと思います。

 

 

このシステムは、2018/9/19時点で238,844社・589,524事業所で利用されています。

これだけ高いシェアを誇るITシステムには魅力がたくさんありそうですね。

 

 

 

 

◇システムの概要

 

まず、このシステムを4項目に分けて説明していきたいと思います。

 

 

1つ目は、取引先が請求書を発行した後、瞬時に請求書を受領することができます

すなわち、月次決算が瞬時にできるため、その都度状況に見合った経営判断を行うことができます。

 

 

2つ目は、会計ソフトの手入力の手間や時間を削減させて、

さらに手入力時に起こりえる間違いを無くすことができます

 

学習機能によって部門や勘定科目を自動で仕訳ことができるので、

会計システムにも自動で取込可能となっています。

 

 

3つ目として、承認リレーをシステム化することで、

経理業務の効率化だけでなく内部統制の強化につながります。

 

各会社の体制に合わせて担当者を登録し、

そのフローを可視化することで進捗情報の確認がスムーズに行うことができるようになります。

 

 

最後に4つ目として、

請求書作成にかかる手間や時間、そして紙代・印刷代・郵送代

経費を削減することが可能になります。

 

支払金額確定データを当システムにアップロードすることで、自動で通知書が作成されます。

 

今まで紙で作成し郵送していた支払通知書をデータ作成、送信にすることで

業務コストや発送コストを大幅削減できます。

 

 

 

以上からわかるように、

このシステムを利用し、従来電話やFAX、郵便など時間とコストをかけて行われていた業務を

ペーパーレスすなわちデータ化することで

スピード感とミス削減による業務効率の向上、コスト削減、エコの実現がみこまれます。

 

 

 

 

◇導入事例

 

では、実際に導入されどのように効果があったのか2社をケースとして挙げていきたいと思います。

 

 

 

ケース1:野村証券

まず、野村證券株式会社の事例です。

 

導入に踏み切った背景として、

年間約10万枚分の請求書を請求書1枚辺り1,500円以上掛かけて処理していたことが判明したからです。

 

2016727日の取材の時点で、全国に159店舗、本社に126部室ありました。

 

その全店舗と全部室に経費の入力担当者を置き、神奈川に事務センターに一度集約して、

さらにそこから、人件費を抑えるため、

より人件費の安い中国の大連に事務センターにて手入力を行っていました。

 

電子化に移行しようにも、外部業者・取引先にコンタクトを取ると請求書のデータ化は困難であると言われたり、

 

データ受領しても種類や形式が一様ではないため修正作業にさらにコストがかさんでしまったりと問題が多くありました。

 

 

そこで、当システムを導入したところ、

 

システム構築が不必要であること

ユーザーのPC端末でデータ化された請求書を処理し、

 管理者がいつでも処理状況を確認できること

データ化された請求書に記載されている全ての情報を会計システムに取り込み、

 手入力作業も含め紙の請求書に基づくこれまでのレガシープロセスが不要になること

 

が判明し、全ての請求書のIT化が進んでいます。

 

結果として、システム上に作業履歴から請求書の送信、受取の状況確認といった作業をすることがなりました。

 

さらに運用を始めて半年で年間約10万枚の請求書を2.5万枚ほど減らすことができ、

数千万円のコスト削減に成功しました。

 

 

 

ケース2:コカ・コーラボトラーズジャパン株式会社

次に、コカ・コーラ ボトラーズジャパン株式会社の実例についてまとめていきたいとお思います。

この会社は201811日付で、2社が統合して事業会社コカ・コーラボトラーズジャパンとなりました。

 

ボトラーと呼ばれる瓶詰会社は世界的に見て、統合によって経営の合理化を求めており、

日本国内においても統廃合を繰り返してきた歴史がありました。

 

しかし、会社としての規模も大きいため、

経営上での統合後も社内には各社の独自のシステムが残っていました。

 

そのため、会社名は同じでも、同じ取引先に複数枚の請求書を送っている状態だったのです。

 

 

この会社では、コカ・コーラの製造と販売を行う国内最大規模の清涼飲料企業として

月に約15万枚の請求書を発行していました。

 

人件費を除いた印刷代、封筒代、郵送費等で月間1,000万円以上の経費がコストとしてかかっていました。

郵送の場合だと、コストがかかるだけでなく、先方の手元に届くまでに日数も要し、

確実に届いたかどうかも把握できないデメリットもありました。

 

そのため、請求書のフォーマットややり取りの仕組みが標準化されており、

弊社の請求書業務も標準化できるこのシステムの導入に踏み切ったといいます。

 

 

このシステムを提供するインフォマートがもつ顧客の個人情報の保護やセキュリティ対策等の

管理運用ノウハウを利用することで、

自社で一から電子化ソリューションを構造するより低コストでIT化を実現することができました。

 

取材時は、導入から2ヶ月だったため正確な数字は出ていないですが、

システム導入前は、各拠点や子会社も含め40人以上が作業を行い、

 

時間にすると約150時間かけて明細書を行っていましたが、

 

今はデータのアップロードから請求書発行予約まで、約1時間しか要しないといいます。

 

このように、大幅な時間が節約されました。

 

最終的には月間15万通、年間で180万通の請求書を電子で発行することを目指しているそうです。

このうち75%程度までIT化できれば、年間約1億円以上のコスト削減が見込まれると予想しています。

 

これからの経理担当者は、IT化できる業務は積極的にITシステムを導入し、

分析や経理担当者自身のスキルアップといったことに時間をかけられることになります。

 

 

これらのケースから分かることは、

日本国内において経理業務のオペレーションのデジタル化は日々進んでおり、

コスト削減の面において非常に有益であることです。

 

また今後は、経理業務以外の業務においてもさらにIT化、

そしてペーパーレスが進むのではないかと考えられます。

 

 

 

 

◇参考資料

 

BtoBプラットフォーム 請求書」 株式会社インフォマート

https://www.infomart.co.jp/seikyu/index.asp

 

10万枚の請求書電子化がゴール!「プロセスを変える」過程で、様々なメリットを実感しています。」 株式会社インフォマート 2016/8

https://www.infomart.co.jp/case/0020.asp

 

「月間15万通の請求書を発行。年間1億円以上のコスト削減をめざし、ペーパーレス化に取り組みます。」 株式会社インフォマート 2018/2

https://www.infomart.co.jp/case/0091.asp

 

 

 

 

 

RPA開発における業務定義(初心者向け) ~「ロボット」思考のロジック~

2018.10.10

 

言うまでもなく、どんな企業にとってもRPAを導入するには、

まず「どんな業務をRPA化する」のかを明確にしなければならない。

 

つまり、RPA対象業務の選定だ。

 

RPAが得意なものとして、

パソコンを使った「大量重複している作業」と「ルールが明確している作業」というものがある。

 

 

では、企業の中にこの二つの特徴のある作業を洗い出し、

その業務フローも明確化したらRPA開発が先に進められるようになるのか?

もちろんそういうわけではない。

 

 

ざっくりのプロセスを言うと、まずRPA化対象業務を選定する。

 

その次が対象業務をマニュアル化する。

 

開発にはいる前に、その三番目が開発ではなくマニュアル化された業務をRPAのロジックで「定義をする」ことにある。

 

 

何故かというと、RPAはあくまで「ロボット」であり、人間との思考ロジックが全く違うことになる。

RPA開発がうまく行くように、RPAのロジックに合わせて業務を「定義」しなければならない

 

 

 

今回のコラムではこの「業務定義」プロセスの事例をいくつかを紹介しながら、

その注意点を説明していく。

 

 

 

 

◆エクセルファイルの処理について

RPAといったら、エクセルファイルの操作などが絶対出てくる話だ。

人間の操作を真似し、素早く大量なデータ処理ができるというイメージが多くの人がしている。

もちろん、これは間違いない。

 

 

ただし、RPAがエクセルを操作するときは人間と比べて、少し異なるところがある。

 

 

 

以下の例を見てみよう。

 

 

 

上記の表は某ECサイト運営会社A社のRPA導入プロジェクトで出た一例だ。

 

本業務の内容としては、毎日スタッフが社内システムに「Code」を発行申請し、

その後発行されたCodeを上記表1フォーマットのエクセルファイルに貼り付ける。

 

このエクセルファイルをもとに、別の業務が色々と行われるが、ここでは議論しない。

 

ここで説明したいのはRPAがどのようなロジックでこのファイルを読み取るかというところだ。

 

 

まず、この業務にかんして、人間が行う場合はまずエクセルファイルを開き、

Code」列を見て、最初に空欄になっている行に基づいて作業を行う。

 

1から言うと、黄色で塗りつぶされているセルになる。

 

そして、この行を見つたら、

Start date」、「End date」と「配信日付」(実務上、配信日付はRPA稼働日付とは異なる)

の情報を使ってシステムにログインし、「Code」を申し込み。

 

その後、発行されたCodeをコピーに、黄色セルに貼り付けて完了する。

 

 

 

しかし、RPAが行う場合プロセスは人間と異なる。

RPA開発ソフトによって少し違うかもしれないが、

だいたいのRPAはまず処理しやすくするためにこのエクセルファイルを丸々メモリーに読み取る。

 

その後、「Code」列が空欄になっているかを一行一行見ていく。

 

もちろん、何行目から始めるかについてRPAが全く分からないので、一行目からみていく。

1から見ると、6行目で空欄が出るので、

たいしたことないに見えるかもしれないが、そうではない。

 

 

1は元ファイルの一部を切り取ったことに過ぎなく、実際のエクセルファイルは数万行以上ある。

この場合少し厄介なことになる。

なぜなら、毎回数万行以上のデータを一行一行処理した後に、

空欄行にたどり着くので、無駄な時間が発生する。

 

また、空欄ではなくても、

「○○につき、作業中止」という何らかの原因でその日業務は行わないということもある。

 

 

すると、RPAはまず空欄かどうかを判断し、

もし空欄ではなかったらさらにその内容は「作業中止」が含まれているかも判断しなければならない。

 

しかも、全ての行に対して同じ処理をすることになる。

RPA24時間働くとはいえ、この24時間が上限になる。

 

 

 

普通RPA導入するには、高額なRPAソフトのライセンスを購入しなければならない。

大事なライセンスをこの無駄な作業に使うと少々もったいないかもしれないので、

より有効利用するために、方法を変えないといけない。

 

 

 

では、このプロセスにおいて、人間とRPAは果たしてどこか違うのか?

 

RPAは機械なので、「最初に空欄になっている行」という条件だけでは、普通上記のプロセスになる。

 

 

人間の場合、作業員が毎日やっていると、

「何となくこの辺りじゃないか」という情報は頭に残っているため、探すときは極めて速い。

 

要するに「目標行の情報」の有り無しに違いがある。

そうすると、RPAにも似たような情報を与えると空欄セルにたどり着く時間が短縮できる。

 

 

A社は二つの方法を検討していた。

 

 

 

まず、表2のように「RPA稼働日」という列を先に作って、RPAに読み込ませる。

RPA稼働日は「本日の日付」と結びつけ、RPAがこのエクセルファイルを読み取ると、

日付を見て目標行を探せばよい。

 

ただし、これでも、理論上RPAが「RPA稼働日」列のセルを一つ一つ見て、対象の日付を特定する。

 

根本的にいうとさほど変わらないので、二つ目の案が出てきた。

 

 

 

表3のように、最初に一行を追加し、「目標行」の情報をあらかじめ記入する。

 

RPAが稼働し始めたらまずエクセルファイルを読み込んで、

その後すぐ目標行の情報が記入されているセルのデータを込み込む。

 

表3からいうと「4」になる。

 

その後すぐ4行目の情報に基づいて作業を行う。

このセルは固定される(例えばB2など)ため、RPAがすぐ特定できる。

すると、たとえ表が何万行あっても一行一行を処理していく必要がない。

 

作業が毎日行うため、翌日RPAが稼働時「目標行」のデータがずれないように、

作業が終わってエクセルファイルを閉じる前に目標行データに「1」を加算する。

 

つまり、翌日開くと、このセルは「5」になる。これで処理時間を短縮することができる。

 

 

 

 

◆メール受信チェックについて

メールを送信受信関連の処理はエクセルと同じく、RPA化で良く検討される業務だ。

 

例えば同じくA社はメールの受信と分類業務をRPA化検討している。

 

内容としては、特定なメールアドレス宛に送信されてくるメールを件名や添付ファイルの種類に基づいて

分類をし、それぞれ特定なフォルダーにOutlookmsgファイルのバックアップを作成する。

 

メールソフトは当然Outlookを使っている。

そして、これらのmsgファイルはまた別の業務に使われる。

 

 

今まで従業員一人が毎日この作業を行っていたが、この単純作業から解放するために、

色々と検討した結果、RPAが最適だと判断した。

 

 

 

RPA化するにはいくつかの問題が残っていた。

まず、A社が使われるRPAソフトはメールの「未読」と「既読」判断は出来なかった。

 

通常人間が作業を行う場合は毎日対象アドレスの未読メールを見て、

条件に満たしていれば、該当のフォルダーに保存するという流れだが、

「未読」が分からないRPAにとっては少々難しい。

 

RPAができるのはOutlookの「受信」フォルダーにあるすべてのメールを全部取り込み、

そして一通一通どの条件に満たすかをチェックする。

そうすると、毎回このフォルダーにある過去のメールも全部チェックし、作業が重複さてれしまう。

 

そこで解決策として、RPAが一通のメールをチェック終わったら、

このメールを別のフォルダーに移動するように設計する。

 

具体的にいうと、

Outlookの対象メールアカウントに「受信」フォルダー以外に「チェック済」フォルダーを作成する。

 

RPAがチェック終わったメールをこのフォルダーに移動するように設定する。

 

そして、毎日RPAが「受信」フォルダーがからになるまで動作をする。

 

結果は毎回RPAが稼働するとき「受信」フォルダーに未読のメールしか存在しないことになる。

 

また、細かいところを言うと、

たまにRPAが読み取れないメールや分類不能のメールもあったりするが、

これらも対応できるようにロジックをあらかじめ組めないといけない。

 

いわゆる「イレギュラー」の対応だが、ロジックも同じだ。

 

例えば、もう一つ「イレギュラー」フォルダーを作って、

読み取れなかったメールをこのフォルダーに格納し、

RPAが実行終わったら従業員がチェックしに行く方法もある。

 

 

 

 

◆まとめ

今回が紹介したことは基礎的な話だが、実際業務定義段階で結構ある話だ。

 

これらの問題を事前にできる限り考慮した上でRPA開発をすれば、

開発時間の短縮とRPA実行効率向上の一石二鳥になる。

 

もちろん、今回紹介した二つの例はRPAソフトによってかなり変わるかもしれないが、

このような考え方があると読者のヒントになれれば幸いである。

 

 

 

 

【導入事例】某大手生命保険会社のRPA導入事例

2018.10.10

大手外資コンサルファームに所属していた筆者が、

某大手生命保険会社にRPAを導入した際の導入事例・体験談をまとめます。

 

 

利用ツール

使っていたRPAツールは「Blue Prism」でした。

大手企業であれば、かなり値段は張るものの、機能性に優れる「Blue Prism」の利用は間違いありません。

 

クライアントが大手企業ともなると開発エンジニアがチーム体制を組むことが当然であるため、

「Blue Prism」の中央サーバー管理による開発は非常にやりやすくなります。

 

また、エンジニア目線から言って非常に取っつきやすいUIとなっているため、

習得の容易性が高いと言って差し支えないでしょう。

 

 

人員体制

PM 1名、PMO 2名、開発メンバー 10名程度のチームで1年間ほどで5~10業務程度をRPAロボット化しました。

 

1業務につき、1~3名のメンバーにて2ヶ月程度の期間が平均的であり、

業務量に応じて開発メンバーの多寡は加減されていました。

 

 

RPA化業務

主に顧客から日々送られてくる紙媒体に対する会社側のアクションを自動化したり、

基幹システムへの入力を自動化したりといったところでRPAを活用していました。

 

 

発生した問題や独特の創意工夫の必要性

RPAは情シス部門というよりも業務部門が窓口となることが多いです。

 

情シス部門がからむこともありますが、ほとんどサポートであったり、

アドバイザー的な立場でアサインされることが多いようです。

 

こういった場合に何が問題となるかというと、業務部門はあくまで業務のプロでしかないため、

システム的な理解度が低い可能性が非常に多いということになります。

 

要件定義から開発、テスト、受け入れまでのすべての工程において、

横文字や略語、専門用語を極力使わないといった配慮が常に必要です。

 

加えて、RPAでありがちな失敗かと思われますが、

RPA動作中のPCに対して、人が操作してしまってエラーが発生する、というような問題も発生しました。

 

RPA動作中のPC操作は、RPAでは基本的にNGとなります。

例外的に、人的判断を処理の途中に要する場合に限り、RPAロボとRPAロボの間に「人間の入力」などが入る場合もあります。

 

 

また、エラーで動かない場合のワークアラウンドも事前に手広く構えておく必要があります。

これも、先ほどの業務部門が窓口であることに起因していますが、

システム開発ではどのようなことに対してどれほどの時間や労力がかかるのか、といったことが全く理解いただけないため、

スケジューリングなどがすべてベンダーにかかっているような状態になりがちです。

 

「実はこういった作業をユーザー側にあらかじめてお願いしていなければならなかった」というようなタスクがあるものです。

代表例で言えば、UAT(=User Acceptance Test, ユーザー受け入れテスト)のデータ準備などが挙げられるでしょう。

 

紙媒体を電子化するにあたり、それをパンチングするパンチング業者との連携なども求められることがあります。

 

 

また、インシュアランスについては、インダストリーとしてバンクよりもセキュリティ面で厳しいということはないと思いますが、

やはり金融機関ではあるため一般企業よりは厳しいという印象です。

 

RPAロボット動作中に随時出力されるログに顧客情報を残さないことであったり、

テストなどで受領する保険の証券情報をベンダー側で見られないよう工夫していただく必要があるなど、

ところどころ独特の配慮が必要なことがあります。

 

 

おわりに

いかがでしたでしょうか。

生命保険会社のRPA導入に関する意見を拙劣ながら述べさせていただきました。

ご参考いただければ幸いでございます。

 

 

 

人工知能に心は存在するのか

2018.10.09

目次

 

 

 

 

ここ何年かで、人工知能に関する研究は飛躍的に注目し始められています。

 

それは、2000年代になって、第三次AIブームと呼ばれるものが到来したからでしょう。

2005年にアメリカの未来学者である、

レイ・カーツワイルがシンギュラリティ(技術的特異点)という概念を発表し、

翌年の2006年にディープラーニングという概念が提案されてからというもの、

今現在も様々な研究が続いています。

 

 

今後、この人工知能はRPAなどの技術と組み合わされることで

飛躍的に我々の生活を豊かにしてくれることでしょう。

 

 

しかし、その中で我々人間はどのようにそれらロボットと接していくのがいいのでしょうか。

 

今回のコラムでは、今後我々がどのようにそのAI達と接していくべきなのかについて考えていきたいと思います。

 

 

■「強い人工知能」と「弱い人工知能」

 

そもそも、人工知能には

強い人工知能(Strong AI)」と「弱い人工知能(Weak AI)

という二つの分類があります。

 

この言葉は、アメリカの哲学者であるジョン・サールが

「心・脳・プログラム」(原文はこちらから)という論文の中で使った言葉です。(*1)

 

[和訳]

 弱いAIの研究の立場で、心の研究でのコンピュータの主要な価値は、我々に非常に強力なツールを与えるということです

(中略)

しかし、強いAIの研究の立場では、コンピュータは単に心の研究のツールではありません。むしろ、適切にプログラムされたコンピュータは真の心そのものなのです。

 

サールは「強い人工知能」と「弱い人工知能」を研究者の立場から見て分類しています。

 

つまり、「弱い人工知能」は人間のツール(道具)に過ぎないのに対して、

強い人工知能」は道具ではなくて、もう心以外の何物でもない、ということです。

 

 

 

弱い人工知能」は特化型人工知能(Narrow AI)とも呼ばれており、

現在、開発されて、世間のみなさんが見たり使用したりしているのはこちらの方です。

 

特化型という言葉からもわかるように、

ある特定の分野については突出した力を発揮するような人工知能のことを指します。

 

 

例えば、最近プロの囲碁棋士にハンディキャップなしに勝利したと話題になった、

AlphaGo(アルファ碁)や、これまた世界中で注目されている自動運転や、

その自動運転に使用されている画像認識なども「弱い人工知能」の一つです。

 

 

 

それに比べて、「強い人工知能」は

汎用型人工知能(Artificial General Intelligence : AGI)と呼ばれています。

 

これもその名の通り、汎用的な使い方ができる人工知能のことで、

様々な分野において力を発揮する人工知能のことを指します。

 

現在のこの世界では、「強い人工知能」はまだ実現できていません。

 

想像上のものとしては、ドラえもんやR2-D2などが存在します。

 

これらは人間の道具という域を超えて心を持つものとして存在するでしょう。

 

 

 

これを提唱したサールは、人間は「弱い人工知能」を重要視するべきであると主張しています。

人工知能という機械は人間の単なる道具という範囲を超えるべきものではなく、

心を持つことはその範囲を超えてしまうからだと考えられます。

 

 

 

ここで現代の我々が考えないといけないことは、これらが心を持つかどうかということなのですが、

その際に重要になってくるのは、人工知能が考えることができるのかどうかということでしょう。

 

 

なぜなら、心を持つということは何かを考えて判断を下しているとも言えるからです。

 

もしも、何も考えずに判断しているとしたら心を持っているとは言い難いでしょう。

 

ですので、ここからは人工知能が考えることができるかどうか考察していきます。 

 

 

 

■人工知能は考えることができるのか

 

ディープラーニングにおいては、大量のデータを人工知能に喰わせて新しいデータの判断をします。

 

つまり、人工知能はあるインプットに対して今までの「経験」を通して

アウトプットをすると言えるでしょう。

 

 

これは人間と似ているような気がします。

 

 

人間もそれまでの人生の「経験」を通して自分の人生観や心の芯を決めていきます。

 

ある出来事が起こったとき(インプット)に、

自分の今までの「経験」というフィルターを通して物事を判断して行動を起こします(アウトプット)。

 

どちらも、

 

インプット→経験の蓄積→アウトプット

 

のようなフローをしているのが分かると思います。

 

 

このような面から見れば、そこまで人と人工知能に差はあまりないように思います。

 

 

 

しかし、人工知能にはインプットの際に言葉の意味を理解していないではないか

という反論が予想されます。

 

意味を理解出来ていないのだから考えているとは言えないのではないか、

という意見はとても真っ当のように思います。

 

では、実際に人工知能が意味を理解しているのかについて考えていきます。

 

 

 

■人工知能は意味を理解しているのか

 

人工知能が意味を理解しているかどうか見ていくために、

ここで例に出したいのは、

先ほども出てきたジョン・サールがおこなった思考実験の「中国の部屋」というものです。(*2)

 

ある小部屋の中に、アルファベットしか理解できない人を閉じこめておく(例えば英国人)。この小部屋には外部と紙きれのやりとりをするための小さい穴がひとつ空いており、この穴を通して英国人に1枚の紙きれが差し入れられる。そこには彼が見たこともない中国語が並んでいる。

どういう記号の列に、どういう記号を付け加えればいいのか、それは部屋の中にある1冊のマニュアルの中に全て書かれている。

彼は以下の作業をただひたすら繰り返す。

外から記号の羅列された紙きれを受け取り、それに新たな記号を付け加えて外に返す。

すると、部屋の外にいる人間は「この小部屋の中には中国語を理解している人がいる」と考える。

しかしながら、小部屋の中には英国人がいるだけである。彼は全く漢字が読めず、作業の意味を全く理解しないまま、ただマニュアルどおりの作業を繰り返しているだけである。

それでも部屋の外部から見ると、中国語による対話が成立している。

 

この実験でサールが言いたかったのは、実際の人工知能は言葉の本質、

つまり意味を理解しているのではなくて、マニュアル通りに作業をしているだけだということなのです。

 

だから「人工知能は規則に従っているだけで思考しているわけではない。」と主張しているのです。

 

面白い思考実験ではありますが、

このサールの主張に対してはいくつかの欠陥があって、様々な反駁があります。

 

 

しかしここでは少し違う視点から見ていきたいと思います。

 

それは、この英国人(暗にロボットを指しています)が意味を理解しているかどうかにかかわらず、

実際に会話は成立しているという点です。

 

実際に現代でも、人工知能と会話を成立させること自体は可能になってきていますし、

それ以外にも囲碁で有利な場所に碁石を打ったり、顔認証で特定の人物を取り出せたり、

 

人間とロボットの間には情報のやり取りが成立しているのです。

 

 

意味を理解するという点では不十分なところもあるかもしれませんが、

行為自体は行えているということを考えると、

 

意味を理解するということがどこまで重要なことなのか少し疑問が残ります。

 

 

 

 ここで一つ考えてみましょう。

 

日本語には、メタコミュニケーションと呼ばれるものがあります。

言葉をそのままの意味で理解するとおかしなことになるという不思議なものです。

 

例を考えると分かりやすいと思います。

 

「いったい何時だと思っているんだ!」をそのままの意味で受け取って、

「〇時です。」のように答える人はいないでしょう。

 

このような言葉をメタコミュニケーションと言います。

 

メタコミュニケーションは言葉通りの意味で受け取ってしまうとおかしなことになるのです。

 

 

さてここで、

このように、言葉から一線離れた外側のコミュニケーションを人工知能は理解できるのでしょうか。

このような言葉は意味を理解していないと会話が成立しないので人工知能には難しいことのように思えます。

 

 

しかし、これらの言葉もまた、状況や前後の言葉からの規則(マニュアル)に従っているのではないでしょうか。

 

通りがかる初対面の人にこの言葉を言われても意味が分からないと思いますが、

待ち合わせをしている友達から発せられた言葉ならば納得がいくでしょう。

 

うまく状況を規則に当てはめて処理しないといけませんが、

これをロボットに覚えさせることで、会話することが可能になる気がします。

 

ここでもまた、

実際は意味を完全に理解していなくても言葉として会話は成立しているのです。

 

 行為に主体を置いたときには、しっかりとロボットにもアウトプットがおこなえているように見えます。

このように、見方によっては成立しているように見えることもあるかもしれません。 

 

 

■人工知能に心はあるのか

 

現在の人工知能には我々人間と同様の心や考えが完全に同じようにある、

と言いきることは出来ませんが、

 

それは行為をなすうえで必要なことであるのかをもう一度見直す必要があるかもしれません。

 

そして、それは実は程度の差であって、ある・ないの二択では語りえないのではないでしょうか。

 

確かに現在の人工知能には人間と同様のことは行えないと思いますが、

人間のようにできないからそれはできないと決めつけてしまうのはとても危険な気がします。

 

 

 

もしかしたら、人工知能には人工知能の心が存在するのかもしれません。

 

 

 

■参考文献

 

*1 ) シンギュラリティ教徒への反駁

https://www.sbcr.jp/products/4797392616.html

 

*2 ) wikipwdia「中国の部屋」

https://ja.wikipedia.org/wiki/中国の部屋

 

*3 ) 「人工知能に哲学を教えたら」(SB Creative)

https://www.sbcr.jp/products/4797392616.html

 

 

 

 

RPA導入前に考えておくべきこと

2018.10.05

目次

 

 

 

 

ホワイトカラーの現場を中心に、

RPA(ロボティック・プロセス・オートメーション)の活用が広がっています。

 

人材不足働き方改革といったキーワードの改善にはRPAがマッチし、

ロボットに仕事を与えることで生産性の向上を実現できます。

 

一方で、期待を抱いてRPAを導入したはいいものの、

うまく使いこなせていない事例も多く発生しています。

 

 

RPAの導入がうまくいかない企業の多くは、

導入前にしておかなければならない大切なことが不足しているのです。

 

 

ここでは、RPAを導入する前に考えておくべきことや準備しておくべきことについて説明していきます。

 

 

 

★RPAとは?

RPAとは、「Robotic Process Automation」のことで、

ロボットに業務をさせるためのプロセスのことを言います。

 

ロボットといっても工場にいるような産業ロボットではなく、また人型のロボットでもありません。

パソコンにインストールして利用するソフトのことを指しています。

 

これまでは人が行っていた業務をロボットに任せることで、

人は単調な業務から解放され、より頭を使う高度な業務へシフトすることができます。

 

 

昨今、世間を賑しているRPAのニュースを見るたびに、

わが社でも利用をしてみたいと考える経営者が増えてきています。

 

30人の派遣社員で実施していた業務をロボットに任せることで10人に削減することができたり、

社員が間接業務を手放して経営課題に取り組むことができたりします。

まさに革命とも言えるRPAは、これまでの仕事の在り方を大きく変えてくれるのです。

 

 

ただし、RPAを導入すればすぐに効率化できるというものではありません

 

 

RPAを導入したにも関わらず使いこなすことができていない企業は、

導入前に考えておくべき「大切なこと」ができていません。

 

 

RPA導入を検討している人は、これから説明する導入前に考えておくべきこと理解し、

まずは導入前の準備から始めるようにしてください。

 

 

 

★業務の見える化をする

定型化されている業務が社内に存在しているのは把握していても、

それがいくつあって、どのような業務であるか、詳細まで文書化されていることはほとんどありません。

 

 

「定例業務が複数あるから活用できる」という浅はかな考えでRPAの導入をするのは非常に危険です。

 

 

まずは、社内にある定例業務を洗い出して見える化することが大切です。

 

 

結果、RPAの導入を見送ったとしても、

見える化された業務は課題を見つけやすく、効率化しやすくなるものです。

 

 

RPAの導入を検討している人は、中小企業で言えば社長や役員、

大企業でも管理職やリーダーの方になるでしょう。

 

これらの方々が定例業務を実施している事は少なく、

実際に定例業務を実施している人からヒアリングをするところから始めなければなりません。

 

定例業務をしている担当者から業務の詳細をヒアリングをして、業務の流れを作成します。

ピンポイントではなく、前後の業務背景が見えるような業務フローを作成します。

 

その後、1つ1つの業務を確認してどのようなタイミングで、

どれくらいの時間がかかっているのかも書き起こします。

 

誰が見てもその業務で何をやっているのかが分かるような資料が作成できれば、

業務の見える化ができたことになります。

 

 

業務の見える化をする際にネックになるのが「ジョブセキュリティ」の概念です。

一般職の方や派遣社員の方は、自分の仕事を奪われることに抵抗の意思を示します。

 

 

仕事を見える化して効率化されることで、自分たちの仕事が奪われることを嫌うのです。

企業が定例業務を見える化できていないのは、担当者自ら属人化を望んでいるからともいえます。

ヒアリングをする際には、見える化の重要性を理解してもらい、

情報が漏れなく出てくるような関係を築くことも大切になります。

 

 

 

★専任の担当者を立てる

 

RPAの導入には、専任の担当者が必要です。理由は2つあります。

 

RPAのシナリオデモを見ると、簡単にできているように見えるかもしれません。

 

しかし、シナリオを作成するにはプログラムのアルゴリズムを理解し、

場合によってはスクリプト言語の埋め込みが必要になります。

 

アルゴリズムの理解については、

論理思考で業務の流れを見ることができる人フローを作成するセンスのある人が好ましいです。

 

RPAソフトによっても違いますが、少し複雑な処理をRPAに任せようとするなら、

シナリオへのスクリプトの埋め込みが必須になります。

 

 

スクリプト言語については、普段からExcelでマクロの作成をしている人が良いでしょう。

 

これらが実現できる人が社内いない場合は、

専任の担当者を立ててセミナーなどで理解を深める準備が必要になりますし、

場合によってはシナリオを作成する人を外部から調達することも視野に入れなければなりません。

 

これが専任の担当者が必要な理由の1つです。

 

 

 

もう1つの理由は、時間の捻出です。

 

RPA導入のために、現場からヒアリングをして見える化する、

その後シナリオを作成することになるのですが、

見える化されるまでに時間はかかりますし、シナリオ作成は1日でできるものではありません。

 

 

Excelリストから100行のデータを読み込み、

あるサイトにログインとログアウトを繰り返すという単純なシナリオを作成するとしましょう。

 

アルゴリズムやスクリプト言語を理解している人でも、

初めてRPAに取り掛かる人であれば1週間はかかります。

 

何度もシナリオの作成を繰り返し、

慣れてきた人でも新しいシナリオの作成には2~3日かかると想定しておきます。

 

そうすると、別の業務を手放さなければRPAに集中することはでなくなってしまいます。

 

 

専任の担当者を立てることで、社内におけるRPAの技術は蓄積されやすくなります。

シナリオの数を増やしていく際に、同様の事が出来る人を増やしていき、

徐々にRPAの技術と文化を浸透させていくといいでしょう。

 

 

 

★計画的なコストを見ておく

RPA導入の際にネックになるのが、コストです。

 

大きな基幹システムを導入することに比べれば、RPAソフトは安価の部類に入ります。

それでも損益分岐点を超えるのは容易ではありません。

 

 

例で説明をしましょう。RPAソフトが100万円、年間のランニングコストが60万円としましょう。

つまり、160万円分の業務がRPA化されなければ、損益分岐点を超えることはありません。

 

時給2,000円の派遣社員の業務をRPA化させるとすれば、

年間800時間の削減、月にすれば66時間の削減が必要になります。

 

これが結構大変なのです。

 

先ほどの100行のログイン、ログアウトの処理はせいぜい1時間程度、

1ヶ月でみても20時間程度の削減にしかなりません。

 

それに加えてシナリオを作成するコストも乗ってきます。

 

 

RPAで働き方が大きく変わる!と期待を持って導入しても、

コストパフォーマンスを出せないままに活用しきれない企業が多数あります。

 

 

RPA導入前には、業務を見える化して専任の担当者を立てます。

その後、計画的なコストの算出をするようにしましょう。

見える化されたシナリオだけで十分なパフォーマンスが出せないのであれば、

他の業務も見える化しなければなりませんし、場合によっては導入を延期させる必要があります。

 

 

導入してすぐに効果が出ないのは当たり前であると割り切り、

長期間でコストパフォーマンスが出るような計画を立てるようにするといいでしょう。

 

最初は先行投資になるかもしれませんが、

2年3年と期限を設けることで効果は発揮されていくようになります。

 

コストの計画をしておけば、

途中での実績との比較もできるようになり、進捗が分かりやすくなります。

 

ただシナリオを増やせばいいのではなく、

どれだけ業務が効率化できたか?という目線で見ることができるようになるでしょう。

 

 

 

★RPA導入前に考えておくことのまとめ

3つのポイントに絞ってRPA導入前に考えておくべきことをお伝えしてきました。

 

ここまで読む前は、もっと簡単にロボットを使えると思っていた人もいるのではないでしょうか。

 

最初は面倒に感じるかもしれませんが、

これらの課題をすべてクリアできた時、RPAは画期的な成果を出してくれます。

 

是非とも事前準備を綿密にし、RPA導入で効率的な働き方を目指してみてください。

 

 

 

 

経理業務へのRPA導入によるメリット・デメリット ~導入事例を踏まえて~

2018.10.04

目次

 

 

 

□ RPAとは

 

最近ではよく「RPA」というワードを耳にすることが増えてきました。

 

市場規模も年々上昇しているのがその要因にもなっているかと思います。

 

 

では、そもそも「RPA」とは何なのか、一言でいえば、「ロボ化」です。

 

これまで人が行ってきた業務を自動化、つまりロボットに代わりに行ってもらう

ということです。

 

 

 

□ RPA導入による仕事の展望

 

いろいろな著書でもこれからの時代において人が必要でなくなる職業ランキングなどが紹介されています。

 

どの著書のランキングをみても常に上位にランクインしているのが

税理士会計士そして、経理業務です。

 

 

 

□ 導入したい経営層、導入したくない現場

 

こんな今後の展望を聞くと会計業界で働いている方や

日常的に仕訳を手作業していた方にとっては耳が痛い話題なのはよく分かります。

 

 

「RPAを導入すると効率が上がる、便利だ、絶対に導入するべきだ」

 

 

こう思われるのは、経営者の方や管理監督者といったマネジメント層の方かと思います。

 

人件費が削減できるヒューマンエラーによる間違いが減るなど、

経営層にとっては願ってもないことが多く叶えられるのですから。

 

 

 

ですが、現場で実際に手作業をしている方や

プレイングマネージャーといった方にとっての効率化、利便性というのは「恐怖」が先にくるかと思います。

 

 

それは、

 

「もし効率化のためにRPAが導入されれば、仕事がなくなるかもしれない」

 

と誰しもが考えるからです。

 

そのため、導入をしたい経営層と導入したくない現場での意思疎通ができずに

なかなか導入するまでに行きつかないという悩みを抱える企業や経営者の方も多いのではないでしょうか。

 

 

 

□ RPA導入のメリット

 

では、RPA導入のメリットやデメリットについて、ご紹介させて頂きます。

 

メリットは上記でも述べさせて頂いたところではありますが、

やはり効率向上による人件費の削減が大きなメリットだといえます。

 

 

大半の企業にとって人件費というのは

経費全体の中でもそれなりに大きな比率を占めているのではないかと思います。

 

管理部門は当然のことながら売上を上げなければ、

利益を生み出す部門ではありません。

 

 

 

また、人の手によって行われる業務というのはミスがつきものです。

 

そのためにダブルチェック、時にはトリプルチェックを行ってミスすることを未然に防ぐのは、

どんな仕事でもそうですが当然の予防策であるかと思います。

 

ですが、RPAによる自動化を行えば、これまで起こっていたヒューマンエラーはなくなります。

 

後述しますが、

メンテナンスは必要ですが、これまでの「ミスありきのチェック」は無くなるのです。

 

 

繰り返しますが、RPA最大のメリットは「効率化による人件費削減と正確さ」です。

 

 

 

□ RPA導入のデメリット

 

では、デメリットについてもご説明させて頂きます。

 

RPAのデメリットは何といっても導入するために必要不可欠なシステム構築です。

 

 

なかなか、自社でシステム構築から開発までを完結するのは難しいと思います。

 

そのため、アウトソーシングによるシステム開発を余儀なくされるため、

一時的な費用がどうしても発生します。

 

どういったシステム構築をするかによってではありますが、

まとまった資金が必要になるのは避けられません。

 

 

また、開発したシステムを自社で保有するのか、

保有せずにランニング費用を払いながらの運用するのか。といった選択もすることになります。

 

 

もう一点デメリットとして挙げられるのが、

システム構築するためには「人」が不可欠という点です。

 

 

システム構築が完了してしまえば、自動的に仕事は進みますが、

 

「どの仕事をどのような手順で最終的にどう完了させるのか」

 

というプロセスを考えるのは人なのです。

 

 

その点をクリアできるだけのシステムに強い人材が現場レベルにいるか

という点も導入するにあたってのデメリットといえるのではないかと思います。

 

 

ですが、費用的な問題、人的な問題さえクリアできるのであれば

デメリットと呼べる障害はないと言えます。

 

 

 

□ 導入事例を踏まえた経理効率化

 

RPA導入による経理業務の効率が実際にどのように行われたのかをご紹介致します。

 

 

今回ご紹介する事例の企業は

日々の経理業務に膨大な人件費とヒューマンエラーをチェックするために多くの時間を掛けていました。

 

多くの時間を掛けてるためのその人件費と

何重のチェックをしてもどうしても防げないミスに対して、どうにかしたいと思っていました。

 

 

そこで、外注によるRPAの開発導入に踏み出しました。

 

その企業では、外注先からライセンス使用するという

ランニング費用を月々支払うことでRPA導入する運用形態を選択しました。

 

もちろん、どんな業務でもRPAによる自動化が可能になるという訳ではありませんので、

「単純作業」を抽出し、部分的な自動化から取り掛かりました。

 

 

具体的には、「画一的なデータを毎回同じように加工する」といった、考える必要がない作業です。

 

 

この企業では、多店舗展開をしている事業を行っていることから、

各店舗からの売上データや仕入データ、経費データ

に至るまでを毎日手作業で会計システムへ入力をしていました。

 

その作業は店舗からあがってきた部分的なデータを

会計システムへ取り込めるようにするといったものです。

 

これだけを聞くとそれほど大変な作業ではないように聞こえるかもしれませんが、

毎日の作業となるとその作業量は膨大なものになっていました。

 

数万行のエクセルデータを加工するのですから、時間もエラーもあります。

 

その作業を人ではなく、RPAにより自動化することにより、

それまで手作業していた作業がなくなることになり、

会計データに取り込まれた最終チェックをするだけでよくなったのです。

 

 

毎日3時間掛かっていた作業が、始業開始する時点では既に出来上がっているのです。

 

そしてイレギュラーなことがない限りは100%の完成度で出来上がっていました。

 

 

RPA導入によりこれまで手作業をしていた時間は

自動化できない作業に多く費やすことが可能となりました。

 

 

この企業では人件費そのものを大きく削減させることが目的ではなく、

膨大な単純作業を自動化することによって、ヒューマンエラーを無くすことでした。

 

ですが、結果として、ヒューマンエラーを無くすということは、

これまで間違いに対し、その修正するための時間と人件費を削減することに大きく影響を与える要因となりました。

 

 

それまで要していた、残業代は大幅に削減をすることができ、

現場スタッフにとっても残業時間が減れば、生活が豊かになり、明日の労働への活力になる。

 

こういった好循環も副産物的に生まれたのです。

 

そして、何よりも大きなRPA導入効果は、

単純作業を行う時間を「人」にしかできない業務に傾けることができるようになったことです。

 

 

これこそが何よりも生産性を向上させ、

悪循環だった業務から脱却することができることに繋がったのです。

 

 

現在もこの企業では、RPA化できる作業については常に開発し続けています。

ゆくゆくは仕訳の入力についてRPA化することを視野にいれています。

 

 

 

□ RPAと人の共存

 

最後に、「RPA」と「人」の関係性について、どうあるべきかを述べたいと思います。

 

冒頭にも申し上げましたが、RPAの導入をしたい経営層と現場レベルの意見の対立

というのはどうしても解消できない企業が多くあるのではと思います。

 

その対立は何故発生してしまうのか。

 

それは、今ある仕事がなくなったら仕事自体がなくなってしまうのではないか

と思う現場スタッフの意識が原因です。

 

 

その意識改革をすることがRPA導入するにあたっての第一条件だと考えられます。

 

ただ、単純にRPAを導入し、業務を自動化します。

と経営者が伝えてもその本位は現場スタッフには届きません。

 

 

導入事例でもありましたが、RPA導入により単純作業を自動化できた際には

「人」が行うべき、あるべき仕事に時間を費やすことができるようになるのです。

 

 

今後、まだまだ成長するであろうAIテクノロジーにより、

単純作業はさらに自動化への道を歩みます。

 

その中で、「人」はどう変化し、成長していかなければならないのか

を考えなければならない時期が目の前まで来ているのかもしれません。

 

それを経営層の方をはじめ、現場スタッフへも浸透させていかなければ、

今後我々、人間の仕事はなくなっていく一方になるかと思います。

 

そのキッカケとしてRPA導入を検討されるのも、

それは企業を良い方向へと向かわせてくれるのではないかと強く思います。

 

 

AIの生産領域と人間の生産領域」、今からでも考えておかなければ

時代の波に取り残されてしまうことになってしまうかもしれません。

 

 

 

 

【UiPath】セレクタは道案内のおじさん!?

2018.10.03

UiPathの勉強をおこなっていると、セレクタという単語は必ず目にすることでしょう。

 

セレクタについて何も知らない人が見ると、セレクタとは何なのか、よく理解できないと思います。

 

今回のコラムではそのセレクタというものをよく使用するであろうレコーダーと共に見ていきたいと思います。

 

 

■セレクタのイメージ

 

まずはとても簡単にセレクタのイメージを筆者の感性を交えて紹介します。

 

初めに言ってしまうと、UiPathにおけるセレクタは

 

「目的地への道順を教えてくれるおじさん」

 

だと筆者は思っています。

 

例を考えるとわかりやすいと思います。

クリックしたい目的のボタンがあったとします。

 

人間は目で見て「ここのボタンだ!」とクリックするかもしれませんが、ロボットにはそうはいきません。

 

ロボットにはそのボタンが

 

どこのデスクトップ上にあるか(「このパソコンのデスクトップです。」)

どこのアプリ上にあるか(「今アクティブになっているアプリです。」)

どんな要素を持っているか(「タイトルテキストにリンクがはってあるものです。」)

 

のように順を追って説明していく必要があります。

この道のりを教えてくれるものこそがセレクタです。

 

このセレクタについて具体的にレコーダーを解説しながら一緒に理解していこうかと思います。

 

 

■レコーダー

 

まずは簡単にレコーダーについて見ていきます。

いろんな自動化する中で、レコーダーというものをよく見るかと思います。

 

レコーダーは人間の動きを覚えて、簡単に再現・自動化することができるものの一つです

レコーダーには大まかに4つあります。

 

Basic RecorderDesktop RecorderWeb RecorderCitrix Recorder

 

上記のようなレコーダーがUiPathには存在して、それぞれにはそれぞれの特徴があります。

 

その特徴をまとめていきたいと思います。

 

 

Basic Recorder(以下 ベーシックレコーダー)

・デスクトップアプリケーションを自動化するのに使用します

・他のレコーダーに比べて速さは劣りますが、マルチウィンドウでも使用可能です

完全セレクタを生成し、コンテナを作成しません

 

Desktop Recorder(以下 デスクトップレコーダー)

基本的にはベーシックレコーダーに似ています

・デスクトップアプリケーションを自動化するのに使用します

 

ベーシックレコーダーと違う点もあります。

Attach Windowコンテナをつくり、部分セレクタを生成します

・同じアプリケーションウィンドウごとにコンテナを生成します

・一つのアプリケーションで複数の操作を行うときに使用します

・ベーシックレコーダーよりも高速に動きます

 

Web Recorder(以下 ウェブレコーダー)

他の3つの中ではデスクトップレコーダーに最も似ています

・ウェブやブラウザでレコーディングを行うときに使用します

・既定でSimulate Type/Clickアクティビティを使います

(これを使用することで高速になり、バックグラウンドでも使用可能になりますが、

特殊キーなどを送ることができないことなどの注意点もあります。)

Attach Browserコンテナを作成し、部分セレクタを生成します

 

Citrix Recorder(以下 シトリックスレコーダー)

今までのレコーダーとは違ったレコーダーです。

Citrixや仮想マシンなどの仮想環境で使用します

・画像やテキスト、キーボードの自動化が主で位置を特定することで自動化が可能です

・アクティビティによっては部分セレクタを生成します

 

 

どのような状況で自動化をするかによって使用するレコーダーが異なります

 

仮想環境ではシトリックスレコーダーを使用し、

ウェブブラウザなどではウェブレコーダーを使用し、

また、デスクトップアプリケーションの自動化ではベーシックレコーダーデスクトップレコーダーを使用します。

 

また、このベーシックレコーダーとデスクトップレコーダーには大きな違いがあります。

 

それは、コンテナをつくるかどうかです。

 ベーシックレコーダーは他の3つレコーダーとは違って、自動化を行う際にコンテナをつくりません

このコンテナをつくるかどうかがセレクタに大きく関係してきます。

 

 

具体的にどのように違うかと言うと、

コンテナをつくらない場合は、完全セレクタ(full selector)を生成しますが、

コンテナをつくる場合は部分セレクタ(partial selector)を生成します。

 

完全セレクタと部分セレクタの違いは、トップレベルのウィンドウのセレクタを含むかどうかです。

 

 

 

言葉だけだと分かりにくいので実際の例を見ていきましょう。

 

今回考える簡単な自動化は、メモ帳でフォントをメイリオに変更することです。

 自動化のプロセスは簡単に言うと、3つだけです。

 

1,メモ帳アプリのメニューの書式をクリック

 

2,フォントをクリック

 

3,フォント名をメイリオにする

 

 

この自動化をベーシックレコーダーとデスクトップレコーダーで行って、違いを見ていきます。

 

まずは、ベーシックレコーダーでのワークフローです。

 

 

とても簡単なワークフローです。

先ほどの3つのプロセスを行っているだけなのが分かると思います。

 

 

次に、デスクトップレコーダーでのワークフローをお見せします。

 

 

先ほどとは違って、アクティビティそれぞれがAttach Windowコンテナに入っていることがわかります。

 

これがコンテナの有無です。

デスクトップレコーダーはアプリケーションウィンドウごとにコンテナを作成しますが、

ベーシックレコーダーはコンテナを作成しません。

 

 

コンテナの違いを確認したところで、次はそれぞれのセレクタを見ていきます。

 

 

 

それぞれのレコーディングでのアクティビティごとにセレクタをまとめてみました。

隣り合っているセレクタは同じ操作を行っています。

 

この表で左(ベーシックレコーダー)と右(デスクトップレコーダー)を

見比べてみるとすぐ気づくと思うのですが、

 

デスクトップレコーダーのセレクタは、ベーシックレコーダーの一行目がごっそり抜けている

 

のが分かります。

 

これがトップレベルのウィンドウがあるかどうかの違いです。

 

左(ベーシックレコーダー)はアクティビティごとに

メモ帳ウィンドウの」という断り書きがあるのに対して、

右(デスクトップレコーダー)は断り書きをスキップしていきなりボタンのUi要素を指しています。

 

 

では、ロボットはどこで「メモ帳ウィンドウの」という道のりを知っているのでしょうか。

 

ここで先ほど説明した、コンテナが役に立ちます。

 

言ってしまうと、

コンテナ自体が「メモ帳ウィンドウの」という断り書きを入れている

のです。

 

コンテナ内に入っているアクティビティはすべて同じウィンドウ内で行われているものなので、

この断り書きをスキップしてセレクタを生成してもロボットは分かるということなのです。

 

これでセレクタをスキップすることができる理由が分かったと思います。

 

 

■セレクタを中身

最後にセレクタの中身だけ軽く紹介しておきます。 

 

ここでも先ほどのセレクタを使用します。 

 

以下はベーシックレコーダーでメモ帳の書式ボタンを押すためのセレクタです。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’無題 – メモ帳’ />
<ctrl automationid=’MenuBar’ idx=’1′ name=’アプリケーション’ role=’menu bar’ />
<ctrl name=’書式(O)’ role=’menu item’ />

 

 

 

●一行目

<wnd app=’notepad.exe’ cls=’Notepad’ title=’無題 – メモ帳’ />

 

wnd、つまりウィンドウがnotepad.exeという名前であり、

タイトルが無題-メモ帳であることを教えてくれています。

 

 

二行目

<ctrl automationid=’MenuBar’ idx=’1′ name=’アプリケーション’ role=’menu bar’ />

 

ここではクリックする対象が、メニューバーにあるindexが1のものであると教えています。

 

 

三行目

<ctrl name=’書式(O)’ role=’menu item’ />

 

ここではクリックする対象が、書式という名前のアイテムをもつものだと教えています。

 

 

このように順番に目的地までの道のりを教えているのが分かると思います。

これで、初めに言ったセレクタのイメージが上手く伝わればと思います。

 

 

■さいごに

セレクタはとても重要な要素なので、イメージをもって

ゆっくりでもしっかりと理解していくことをお勧めします。

 

 

 

 

 

ロボットは魔法使いではない!

2018.10.02

 

先日、Business Insider Japan

電通の働き方改革担う「ロボット人事部」—— 600工程の効率化はロボット“だけ”では無理

という記事を読みました。(記事はこちらから

 

 

ロボット人事部って何?

 

 

「ロボット人事部がなければ、RPAはブームで終わりかねない」と指摘する人がいる。全社を挙げて働き方改革に取り組む電通のビジネスプロセスマネジメント局局長・小栁肇氏だ。

 

 

まず秀逸なのが「ロボット人事部」という命名。

 

さすが電通はセンスが良い。

 

RPAは触れたり見えたりする実態がないので、

どうしてもシステムとかアプリとかの類と思われてしまうことが多いのですが、

 

「ロボット人事部」という名称からは人間の代わりに事務作業を行うロボット

という本来の意味がよく伝わってきます。

 

 

最近、日本生命がRPAエンジニアについてロボットトレーナーという表現を用いているのを目にしましたが、

こういうこなれた表現が人口に膾炙することが案外RPA普及にとって大切なのではないでしょうか。

 

 

RPAは単に導入して終わりではない。実際には社員一人ひとりが立ち上げ、使い続けなくては成果は出ない。しかし、導入当初は「すごい」と思って使っても、2、3回すると「使わなくなる」のだという。

 

 

 

近い感覚だと、バイトが入ってきたのだが使えないので、結局全部自分でやった方が早い。

 

みたいなもので、

 

RPAは自動でなんでもやってくれる魔法のような技術ではなく、

慣れるまではむしろ面倒で扱いにくい新人だが慣れてくるととても頼りになる

人間と同じ、ロボットワーカーなのである。

 

 

電通のロボット人事部は30名。

ロボットにも社員番号を付与し、ロボットの使用方法の社内向け広報業務や、

ダッシュボードによる各ロボットの稼働状況の管理、

使用されていないロボットの使用の声がけなどを行なっているそうだ。

 

 

電通の事例は特別なのではなく、今後のRPA普及にとってかなりの核心部分であると思う。

 

ロボットを魔法でなく単なるワーカーと捉えることなくして、継続的なRPA運用は難しい。

 

むしろ、電通のような大企業は導入までをコンサルティング会社やシステムベンダーへ依頼できるが、

中小企業ではその導入から社内のロボット人事部で完結せざるを得ないだろう。

 

その時にロボット人事部に求められるスキルは多岐にわたる。

 

 

まずは、業務選定と標準化。

これは一般的にはコンサル領域だが中小企業の場合はロボット人事部が行わなければならない。

 

特に標準化については、中小企業は属人的であることがほとんどである為、大変な作業になるだろう。

 

 

次に開発環境の整備だ。PCスキルはもちろんのこと、

サーバーのこと、セキュリティのことなども最低限は知識が必要となる。

 

ここまできて、ようやくロボットの設定、プログラミングだ。

導入後も電通の例のように稼働管理、メンテナンスなど運用が必要になる。

 

また中小企業は単一業務だけでロボットの威力を最大限にすることは難しいので、

一人のロボットワーカーを有効活用する為に、複数の業務をプログラミングしなければならないので、

これら作業をいくつも繰り返さなければならない。

 

 

考えただけで大変である。

ロボットにより今後多くの職業がなくなり、またその分多くの新しい職業が生まれる

と池上彰氏が先日話していたが、

ロボット人事部長はその中でも確実に花形になるだろう。

 

 

RPAのこれから

 

 

「今は電通の社内SaaS(ソフトウェアの機能をネットワークを通して提供する方法)になっているが、これを日本のSaaSにしていきたい。積極的にノウハウを外に出すだけではなく、モジュール(部品)を安価に提供できないかも考えている。日本経済が人手不足や生産性の低さで停滞してしまったら、我々の取引先もいなくなってしまう。だからこそロボット人事部を積極的に広めて、少しでも日本経済の活性化に貢献できればと思っている」(小栁氏)

 

 

 

この発想も面白いと思いました。

ただその役割は電通なのかという感じもあるが、

でも確実にそういう今までに存在しなかったサービスや会社は生まれてくることでしょう。

 

現在、各ベンダーがRPAプログラミングの啓蒙を行なっていますが、

もっと広い範囲で、このロボット人事部という発想からの啓蒙がもっと必要なのではないだろうか。

 

 

 

実は当社アーツアンドクラフツでは、

現在この領域におけるトレーニングやモジュールなどを提供しています

 

このメディアRPA-Bizを通じてのお問い合わせの中でも一番多いのが、このトレーニングについてです。

意識の高い中小企業はRPAの内製化が確実に必要になるということに気づいているようです。

 

また、お問い合わせ企業の中でも一番多い業態が人材派遣会社です。

 

今後の人手不足で商売が難しくなってくることを予想して、

人だけでなく将来的にロボットも派遣しようと考えているようです。

 

私は、この人材派遣会社によるロボット派遣はとてもイメージが持てます。

 

RPAの特性がもっとも活きるのが単純作業なのですが、

どの業界にもその業界に特有な単純作業があります。

 

ただ業界特有というニッチ過ぎるあまり、

わざわざその作業を緩和する為に大規模なシステムやソフトウェアの開発は行われていないのが実情です。

 

そしてこの辺りの業務はRPAにぴったりです。

 

人材派遣会社は世に無数にありますが、

実は総合的な人材派遣している会社なんて大手数社だけで、それ以外は職種、業務特化型です。

 

それら中小規模の職種、業務特化型の人材派遣会社こそ、

それらニッチな課題をよく理解しています。

 

彼らこそが、本当にその業界にあったロボットを作り上げられることでしょう。

 

 

当社では、中小企業領域におけるRPAを推進する為に、このメディアからの情報発信以外に、

ワンストップによる開発受託、中小企業向けのパッケージやモジュールの開発、

そしてロボットトレーナー養成トレーニングを行っています。

 

それら4つを柱として多面的にRPAを盛り上げていきたいと考えています。

 

 

当社がロボットに特化した業務選定と標準化を行うコンサルタントを要していることや、

RPAだけでなくサーバーエンジニアなど幅広い技術者を要していること。

 

またコンサルティング会社であると共に事業会社として実業を行っている中で

自らRPAを導入し実証していることなどから、とても実践的なトレーニングだと好評をいただいています。

 

またトレーニング後のアフターフォローもコンサルタント、エンジニア双方でサポートしますので、

業務の選定、標準化、プログラミング、稼働管理などの運用まで全方位的にサポートできます。

 

 

ご興味のある方は、コンタクトください。

 

お問い合わせなどはこちらからどうぞ。

 

 

まとめ

最後は営業になってしまいましたが、ロボット人事部の必要性は揺るぎないものです。

 

三年ですっかりと景色が変わってしまう程進化の早い現代では、

それこそオリンピックが明けた頃にはロボット人事部が当たり前になっている時代がくるかもしれませんね。

 

 

 

 

地方自治体におけるBPO【vol.5】・・・RPA

2018.10.01

 

 

【前回記事】

地方自治体におけるBPO【vol.4】・・・オペレーター側

 

 

 

 

これまで、BPO委託業者と自治体側、更にはオペレーター側について述べてきました。

 

 

50団体ぐらいの自治体にRPAの導入を検討しているか確認したところ、

半数以上の団体から担当者レベルでは検討したりしているようです。

 

 

しかし、課内会議や予算作成などの具体的な検討レベルまでに入っていないことも多いようです。

 

 

 

1.RPAとは

 

 

RPAとは、Robotic Process Automation(ロボティック・プロセス・オートメーション)の略語で、

それに近しい単語として、RDA(Robotic Desktop Automation:ロボティック・デスクトップ・オートメーション)

という言葉も出てきて、混乱もしてしまうかもしれません。

 

基本的には同じRPAという認識で問題ないかと思いますが、

RDAはデスクトップにいるロボットで、RPAはサーバーにいるロボット

そのような認識で良いかと思います。

 

 

RPAを分かりやすく言うと、自分が楽するための道具です。

 

 

例えば、通販のコールセンターであれば、商品の注文をメールで受け、

それを受注システムに入力する作業、全てRPAがやってくれます。

 

今書いているコラムをロボットが書いてくれると非常に楽ですが、

ロボットには考える力(AI)はないので、残念ながら自力で書くしかないわけです。

小説自動生成プログラムなるものは色々あるようです。

 

 

RPAについては、本ブログで様々な内容で書かれていますが、イメージすることが難しい方は

 

Youtubeで【RPA】で検索し、尚且つフィルタで時間を【短い4分以内】に選択してください。

 

2分前後の動画が、RPAの実際動いている動画です。

 

長い動画については、企業の宣伝部分もあり、

RPAが実際動いている動画が確認することができますが、肝心のみたい動画を探すのに面倒です。

 

 

 

 

2.BPOとの相性

 

 

現在、地方自治体の多くが、BPOを利用しています。

BPO対象業務として、前回もお伝えした

 

フロント業務(受付・窓口)、バックヤード業務(事務)、および中間業務(コールセンター・カスタマーセンター)

 

に集約されるかと思います。

 

なぜ、この3つなのかというと、業務の多数が単純定型業務という認識であり、

低コストで委託できるBPO業者に委託しやすいという判断のもと、委託されています。

 

 

単純定型と言っても、実際は失敗している地方自治体も多く存在しています。

 

また、単純定型に分類できない業務も含まれているケースもあります。

 

 

単純定型業務と言っても、人間はミスする生き物ですから、ミスは必ず生じます。

人はそのミスに気付かないまま、処理を続けてしまいます。

 

ロボットの場合は、エラーが生じると教えてくれます。

ロボットがミスする場合、それは人間の指示ミスになります。

 

 

 

BPOコンサルタントや戦略コンサルティングファーム出身にBPOセンターの管理を任せて、

失敗したこともあります。

 

人を管理する、殊にBPOに従事する人間を管理するというのは至難の業です。

 

BPOとして合格水準に達している地方自治体BPO案件があれば、

20件中1件あれば良い方かと思います。

 

残りの19件は残念ながら合格レベルには達しません。

それでも許されるのが地方自治体BPOです。

 

実際、地方自治体BPOでやっていることは、

単純定型業務でありRPAの対象領域が多くロボットで十分出来る業務が多いのですが、

残念ながらロボットではなく、人がやっています。

 

むしろ人よりもロボットにやらせた方が良い場合などが存在します。

実際、BPOの現場にいるとRPAをうまく活用すれば、

人がやるべき業務に専念でき、より良い効果が出ることでしょう。

 

 

 

 

3.BPOの導入

 

 

地方自治体BPOの導入が活発になってきたのはこの数年です。

まだ未導入の団体もかなります。

 

窓口業務だけで見ると、政令都市や中核市レベルだと8割ぐらい、

それ以外の自治体では2割ぐらいが導入済みです。

 

 

ある程度の規模がないとスケールメリットが少ないため、

小規模の地方自治体にとっては窓口業務の導入は難しくもあります。

 

 

あくまでも個人的感覚によりますが、小規模自治体では、

窓口業務より税金や保険料の徴収系コールセンターなどを積極的に導入している傾向があります。

 

それは単純に貸金規制法が改定され、債権回収系の業者が積極的に働きかけた結果、

 

元々そのような税金などの徴収の為のいわゆるアウトバウンド発信業務、

そのような業務を自主的に行っている職員の方は一部であるくらいで、

 

あまり徴収系(債権回収)業務に力を入れてないため、

そのようなノウハウが地方自治体にはなかったためです。

 

 

日本年金機構が徴収系業務を

「外部に代替的に委託した」という背景も恐らくそういうことだと思われます。

 

また、窓口業務と言っても、フロアで来庁者を窓口に誘導するフロア係のみを場合もあれば、

正規職員が本来すべき内容までを委託しているケースまで、

かなり幅が広いので、一概に窓口業務と言っても、やっている業務範囲はかなり違います。

しかも、所管課の方針によって変わります。

 

実際、地方自治体が

フロント業務(受付・窓口)、バックヤード業務(事務)、中間業務(コールセンター・カスタマーセンター)

のうち、嘱託職員、臨時職員、または正職員が行っていた業務を民間事業者に委託する際、

 

自労連(日本自治体労働組合総連合)などの組合から反発も多く、

総務部の部長などはかなり折衝に苦労したと聞き及んでいます。

 

 

苦労して導入したBPO、それを地方自治体がやめる、

そういう選択肢は簡単に取りえないことでしょう。

 

 

実際に導入初年度の総務部長にお聴きすると、

成功して本当に良かったと感謝のお言葉を頂戴したことがあります。

 

 

 

 

4.RPAの導入

 

 

実際、既に導入しているBPOをそのままRPAに変えるということは現実的に不可能です。

 

地方自治体BPOの目的の一つに雇用機会創出があり、そのような考えのもと、民間業者に委託しており、

働いている方の雇用の機会を奪ってまでRPAを導入しようとするのは、さすがに私個人でも反対します。

 

しかし、実際やっている業務そのものはRPAができる領域である。

 

実際、下記の業務については民間委託されてはいますが、RPAとの相性は非常に高いです。

 

 

●市民課窓口で転出届などを受けとり、行政システムに登録する。

●住民票の写しの請求書に基づいて住民票を発行する。

●国民健康保険の申請などを国保用のシステムに登録する。

●後期高齢者医療保険の申請などを後期用のシステムに登録する。

●介護保険の申請などを介護用のシステムに登録する。

●税金や国民健康保険料の文書催告を作成する。

 

 

しかし、RPAを導入しやすい業務だからといって、

現状それらの業務に従事している人たちが存在している限り、

それらの人達の雇用の機会を奪うことは出来ません。

 

一方、人が行う業務はミスが付き物です。

 

自治体BPOの現場では、業務の複雑化や従事者の高齢化が進んでおり、

人的ミスの発生比率はこの数年でかなり高まっています

 

 

国民健康保険、後期高齢者医療保険、および介護保険、

この3つの業務に関しては制度の改定により複雑化しているため、

正規職員の多くが敬遠する部署でもあります。

 

 

特に国民健康保険と後期高齢者医療保険の申請関係では、

運用上、委託の限界ラインを越えてしまっていました。

 

実際、BPOに従事しているオペレーターの年齢層が上がり、

ラジオボタンの選択ミスが日常茶飯事でした。

 

また、国民健康保険課の多くは、

給付、賦課、収納(徴収)の3部門に分かれており、

3部門の横のつながりが希薄で、部門ごとの運用の差異に振り回されることなどもあります。

 

 

RPAを導入することで運用の差異をなくすこともでき、

BPO従事者の業務を窓口での対応時間を増やすことに使うことで、

より良い市民サービスが出来るのではないかと思います。

 

 

 

5.まとめ

 

RPAを導入すれば、現在委託している業務のレベルを2段階は上げることが可能となります。

 

 

私が担当していた、国民健康保険課、納税課、収税課、債権管理課、介護保険課

などの具体的な運用面については次回に述べたいと思います。

 

【次回記事はこちら】

次回記事は10/16 09:00アップ予定!!

 

 

topへ
© RPA.biz