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

中小企業における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