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

中小企業における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アップ予定!!

 

 

【RPA業界必見!!】大手外食企業におけるRPA導入事例

2018.09.28

 

<目次>

 

■大手外食企業が進める“働き方改革”

 

■RPA導入に向けた調査開始

 

■RPA導入の流れ

 

■RPA導入実績のまとめ

 

■RPA導入に関する所感

 

■まとめ

 

 

 

 

 

働き方改革」という言葉はニュースでも盛んに流れています。

そして、多くの企業でも「働き方改革」を旗印に、様々な施策が動いています。

 

某大手外食企業における「働き方改革」プロジェクトの中で、

実際に導入されたRPAの事例を軸に紹介していきたいと思います。

 

 

 

 

■大手外食企業が進める“働き方改革”

 

●社会全体が人手不足

 

2018年現在、社会は空前の人手不足と言われています。その理由の1つに少子高齢化があります。

 

 

(出典)国立社会保障・人口問題研究所

 

 

図を見ると、2010年以降急速に生産人口が減っていることがわかります。

 

つまり、働く人が減っているのです。

 

そして、2018年現在の好景気(諸説ありますが)という要因もあり、

企業は人の採用が難しくなっている現状があります。

 

 

 

●外食ってブラック?

 

外食業界は、他の業界と比較しても、人手不足感は際立っています。

労働集約型産業の代表的な業界ということもありますが、

給料が安い」「労働時間が長い」「休めない

というイメージがあることも原因の1つです。

 

 

給料が安い」ことは、今回のプロジェクトの対応範疇外ですが、

後の2つをどうにか改善する必要があります。

 

実際問題、「給料が安い」はイメージ先行かもしれません。

高くはないかもしれませんが、大手外食チェ-ンの正社員であれば、問題なく家族を養えます。

 

 

 

●外食業界のもう1つの問題点

 

外食業界のもう1つの問題点は、大手含めて利益率が少ない会社が多いということです。

 

 

(出典)StockClip「国内外食産業の業績ランキング」

 

 

売上高順に並んだランキングですが、

大手外食チェーンは軒並み1桁台の利益率だということがわかります。

 

この為、社員を安易に増やせる状況ではなく、

その少ない正社員と多くのアルバイトやパートなどの非正規人材によって成り立っている現状の中、

その少ない正社員は、事務作業などの非付加価値業務に追われているという現状があります。

 

 

前置きが長くなってしまいましたが、

 

・外食産業は人手不足だが、給与を高く設定することが困難な為、採用難である。

・社員には仕事の負荷が重くのしかかっている。

 

上記を改善させるべく、今回のプロジェクトが始まりました。

※このプロジェクトの内、RPA導入に関するシーンを切り取っています。

 

 

 

 

■RPA導入に向けた調査開始

 

●店舗はどれだけ事務作業をしているのか?

 

シフトの作成、レジ締め作業、本部への売上報告書の作成、クレーム報告書、発注作業

 

など多数の事務作業があります。

1日の内、3割が事務作業という結果でした。

 

 

 

●本社(本部)は売上や入金をどのように確認しているのか?

 

売上といっても、現金以外に金券(ギフト券、商品券、株主優待券など)・クレジット・電子マネー

といった売掛が多種に渡ります。

専属の社員を多数用いて、既存のシステムとエクセルで日々確認しています。

 

 

 

 

■RPA導入の流れ

 

●業務フローの確認と現場ヒアリング

 

RPA導入において、大事な点は、業務フローがキチンと整備されていることです。

 

たとえ整備されていたとしても、業務フローには記載されていない業務は必ずあります。

担当者にヒアリングをして、必ず業務を確認しましょう。

 

 

<注意点>

RPAは、あらかじめ決めた業務を行ってくれるロボットです。

つまり、臨機応変な対応は出来ません

イレギュラー業務が発生するのであれば、そのパターンを全て網羅しておく必要があります

逆に網羅出来ない業務が発生する場合、RPA導入はお勧め出来ません。

 

 

 

●業務改善案を練る(コンサルの方のみ)

 

たとえ大企業といえども、そもそも必要なの?という非効率な業務は必ずあります。

何のための業務なのか誰が必要としている業務なのか

という視点で案を練りましょう。

 

 

<注意点>

RPAに置き換えるという視点では無く、業務がどうあるべきかという視点を持つことが重要です。

ほとんどの場合RPAは必要ないかもしれません。

 

 

 

●RPA製品を選びます

 

2018年現在、有料無料含めて10数個のRPAツールが存在しているようです。

最終的には、以下の2つが候補となりました。

 

 

  • WinActor」 販売元:NTTデータ

   国産型RPAツール。デスクトップ型のPRA。フローの作成画面などのUIがわかりやすい。

   小規模業務を得意としている為、中小企業でも導入しやすい。

  • BizRobo!」 販売元:RPAテクノロジーズ

   RPAツールの大手。サーバ型とデスクトップ型の2つから選ぶことが可能。

   実績が豊富であり、ほとんどのバグや不具合は解消されている。価格面から大企業向き。

 

 

この内、「BizRobo!」を選ぶことになりました。

また、販売元であるRPAテクノロジーズからではなく、某大手ベンダ経由になります。

 

 

理由としては、以下があります。

 

・将来の拡張性を考えてのこと。

 

現時点では、デスクトップ型RPAのみで実現可能な為、

どのRPAツールを使った場合でも問題ないのですが、

検証を重ねてRPA業務の対象範囲を今後広げていきたい為

 

 

・ベンダを経由することで、RPAのフローの書き方などのコンサル支援を受けることが出来る。

 

値段が高くなることがネック。

 

 

<注意点>

BizRobo!」は、提供元会社であるRPAテクノロジーズ以外にも、

ソフトバンクやリコーなど様々なベンダがソリューション(RPAコンサル含め)

として提供を行っております。

 

しかし、2018年現在では、どのベンダを利用したとしても大きな違いはありません

ベンダ各社はRPA導入に関するノウハウを蓄積し始めたばかりであり、

ソリューションの中身はどこも似たようなものです。

 

 

 

●システム環境の確認

 

サーバ型RPAなのか、デスクトップ型RPAなのかという違いはありますが、

RPAはシステム環境が変わっただけで、不具合を起こす可能性があります。

 

 

<注意点>

RPAは、GUIが少しでも変わっただけで不具合を起こします

サーバやPCなどは、担当者との情報共有はしっかりとしておきましょう。

 

 

 

●RPAの設定を行う

 

RPAのフロー作成自体は、ものすごく簡単です。

一度、操作方法さえ覚えてしまえば、ITに詳しくない人でも問題なく設定することが可能です。

 

 

 

●今回は、スクリプトが必要になるなどの難しいRPA業務は導入しませんでした。

 

複雑な業務に対してRPAを使う場合は、スクリプトなどでのプログラミングが必要となります。

 

 

<注意点>

フローは粒度をとにかく細かく書く記述する必要があります

例えば、「メール送信」という動作も

 

「メーラー立ち上げ」→「宛先の入力」→「題名の入力」

→「本文の入力」→「送信ボタンの押下」→「OKボタンの押下」

 

などです。

 

 

 

●RPA動作開始と検証

 

RPAが動作開始後は、動作と結果がしっかりと想定通りなのかどうかを確認します。

他ソフト(Excelなど)との連携状況もしっかりと確認します。

 

想定業務外の事態が発生、既存のソフトウェア(たまにしか動かないソフトなど)が

RPAを邪魔してしまう事態が発生する可能性があります。

 

暫くは、常時監視する姿勢が必要です。

 

 

<ポイント>

RPAのナレッジは社内でしっかりと蓄積しましょう

 

RPAが出来ることの理解、RPAの障害パターンの把握が深まれば、

より複雑な業務へと拡張させていくことが出来ます。

 

 

 

 

■RPA導入実績のまとめ

 

●結果事例① 【店舗】レジ締作業の時間短縮、【本社(本部)】エラー確認の時間短縮

 

これまで、店舗はレジ締作業において、1日あたり30分~1時間を擁していました。

その内、売上データの不備確認が多くの時間を占めていました。

 

売上データは本部へ自動送信されますが、売上データに不備がある場合、

自動送信がエラーとなってしまいます。

 

 

本社(本部)は毎日、そのエラーの有無の確認、エラーがあった場合の調査に時間を費やしていました。

店舗、本社(本部)の2重チェック体制となっていました。

 

 

RPA導入により、店舗はレジ締作業において、売上データの不備確認を不要とし、

自動送信にエラーが発生した場合は、

その発生と発生理由を本社(本部)の担当者へ自動でメール送信されることになりました。

 

 

店舗の作業が大幅に減ると同時に、本社(本部)も、

メールによるアラートにのみ対応すれば良いということになりました

 

 

 

●結果事例② 【本社(本部)】売掛請求の入金照合を時間短縮

 

本社(本部)は、金券類やクレジットカード、

そして電子マネーなど多種に渡る売掛の入金確認を行っています。

 

様々な売掛先からの入金日は1か月の中で十数回もあり、

これまでは、その照合チェックをエクセル上で行っていました。

 

1年を通してみても、請求額と入金額に相違が発生することは、

まず無い為(金券が偽物だった場合などであり得ますが事前連絡により承知済です)、

内部統制上での必要事項とも言えます。

 

 

RPA導入により、入金データと請求データの照合を自動で行い、

相違がある場合のみ、メールで担当者へ自動メール送信されるようになりました。

 

 

これは、本来であれば、システム開発によって対応されていても良いかと思うのですが、

対応されていませんでした。

 

新たにシステム開発した場合との費用検討の結果、RPA導入にメリットがありました。

 

 

 

 

以下は、検討したが断念した事例

 

 

●断念事例①店舗における発注作業のRPA化

 

店舗では、毎日の作業として、食材や備品(食器など)を、

Web発注システムを使って発注作業を行っています。

 

これをエクセルに発注内容を記入してメール添付することで、

RPAが自動的に外部のWeb発注システムに登録することで、発注作業の簡易化という検討を行いました。

 

 

しかし、食材は結構な頻度で変わる

(例えば、エビでもインドネシア産エビが高騰の為、ベトナム産エビに代わるなど)為、

RPAのメンテナンスが大変だということで、メリットを生み出すことが出来ませんでした。

 

 

 

●断念事例②RPAが印刷を行う

 

本社(本部)では、毎日の作業として、数百枚にも及ぶ法定帳票を印刷するという作業があります。

それを深夜に自動的に行うことで、日中の印刷作業を無くすよう検討を行いました。

 

 

しかし、そもそも法廷帳票を紙で保存では無く、

データ保存とすることで印刷作業を無くすべき姿だという結論に至りました。

 

単純な話しかと思いますが、

既存業務をRPAに置き換えるという観点だけではいけないということに気が付きました。

 

 

 

 

■RPA導入に関する所感

 

●RPAありきではダメ

 

RPAが出来ることは限られいます。

 

RPA自体が何か新しい価値を生み出すわけではありません。

あくまでも既に回っている既存業務の改善がメインです。

 

また、多くの場合、

既存のシステムを改修すればRPAではなくても対応出来る

ということです。

 

既存の業務を改善する上でのソリューションの1メニューとして捉えるべきだと感じました。

 

 

 

●社内コンセンサスの大変さ

 

RPA導入によってこれだけの効果が出ます」と言えば、経営層は喜んでくれます。

 

 

しかし、RPA導入によって、仕事が無くなってしまう人がいるのも事実です。

 

または、慣れ親しんだ業務が無くなることが嫌だという人もいるでしょう。

 

とある店長は閉店後の売上データ不備確認でその日の業務を振り返ると言っていました。

RPA導入は本社(本部)のみならず、店舗を含めた幅広い、且つ、丁寧なコンセンサス形成が必要です。

 

 

 

●RPA導入により属人的な業務が減る

 

会社の規模に関わらず、会社にはその人しか知らない業務という属人的な仕事があったりします。

 

また、人によって業務の進め方にクセがあることも多いかと思います。

 

RPA導入によって、業務が可視化され、

また、業務の進め方もある程度統一されると感じました。

 

この観点で言うと、効率化もそうですが、内部統制の面でも良い影響があるかと思います。

 

 

 

 

■まとめ

 

今回は、大きな流れでRPA導入についての説明をしました。

 

RPA導入を考えている会社は、

チャットボットなどの簡易AIの導入も同時に検討していることが多いかと思います。

 

RPA導入担当者は、それらの他のプロジェクトを把握して、

どのような連携が考えられるか、という視点を持っても面白いかもしれません。

 

いずれにせよ、RPAはこれから発展していくツールです。

 

RPAに関わることはあなたの社内はもちろん、市場価値が高まることは間違いないと思います。

 

 

 

 

【RPAにより】ホワイトカラー業務が変化する?

2018.09.27

RPAとホワイトカラー業務の課題

 

 

企業において、業務効率化は至上命題のひとつではあるものの、

比較的小粒の業務についてはコスト面および対応のしづらさから、人手に頼っている部分が多く残っています

 

 

多くのコンサルティング会社は、

企業のバックオフィス部門の生産性向上と人的資源の有効活用を推進するため、

RPA(Robotic Process Automation)ツールを活用し、

業務自動化を推進する業務改革サービスを提供しています。

 

 

大量定型業務はビジネス・プロセス・リエンジニアリングや大規模システムの導入により、

効率化が実現できているものの、

小粒の業務はさまざまな理由によりいまだ人海戦術で対応している企業が散見されます。

 

 

RPAツールによって、従来型のシステム開発手法では対応しにくい

ボリュームが小さい」「変更が多い」「標準化できない

といった業務であっても、RPAツールを活用することで効率化が可能となります。

 

 

数多くの業務改革経験を生かし、現場を巻き込んだスピーディな業務改革を実施するRPA業務改革サービスは、

RPAと、コンサルティングの業務改革ノウハウを組み合わせたサービスです。

 

RPAの対象業務としては、

これまで自動化できなかったERPWebメールファイルサーバーデスクトップ上のExcel

などアプリケーションをまたいで発生する広範囲の業務を自動化することが可能です。

 

業務の一連の流れと参照情報を整理し、ロボットが記憶し自動化するため、

コーディングなどのシステム開発が不要です。

 

 

そのため、従来のシステム開発手法では対応することが難しかった

業務量が少ない」「変更が多い」「標準化できない

といった業務でも自動化することができます。

 

 

また標準的なアプローチのため、簡易効果診断では、ロボット化する対象業務の洗い出しを行い、

工数削減の効果および開発費用の概算を算定します。

 

トライアル導入では23つのロボットを導入し、実環境におけるロボットの有効性を検証し、

効果の実感を確認した上で本格導入へと進みます。

 

 

 

RPAで「ホワイトカラーの仕事の47%がなくなる」の意味

 

 

 

 

 

生産性向上が必要になる中で、企業での積極活用が叫ばれているテクノロジーが、

RPA(Robotic Process Automation:ロボティック・プロセス・オートメーション)です。 

 

 

去年開催された日本RPA協会の主催セミナー「やらざるを得ないRPAと取り組みの実態」では、

いまITにおいてキーワードになりつつあるRPAについての解説がありました。

 

 

今後、日本は労働者人口が大きく落ち込むと予想されています。 

 

内閣府の「平成28年版高齢社会白書」によると、2025年には日本の人口は700万人減少し、

15歳から64歳の人口が約7000万人まで落ち込むと言われています。 

 

そのような日本の労働人口が減少する状況下において、

日本人の働き方を大きく変えるテクノロジーがRPAなのです。

 

RPAはアプリケーションを使って行うオフィスワークを学習し、それをそのまま実行することができます。

 

 

いわば、人が手動で行っていた各種ツールによる事務処理などの

ルーティンな作業を代行してくれるデジタルレイバー(仮想知能労働者)です。 

 

人がやりたくない、やるべきではない作業を人の200倍のスピードで処理してくれます。

そして、36524時間稼働してくれます。 

 

 

デジタルレイバーという新しい労働力が活用できるというわけです。 

 

また、RPAは人の操作を記憶させるだけなので、

稼働させるために大規模なシステム導入やプログラムの修正・変更の必要はありません。 

 

 

ノンプログラミングで容易に構築でき、短期間かつローコストで導入することができる

というメリットも生まれます。 

 

 

 

ホワイトカラー生産性調査の必要性について

 

 

ユーザー部門が対象システムを活用することによって、

どの程度生産性を向上できたか、定量・定性両面から把握します。 

 

これにより、成功事例の全社展開や費用対効果の振り返りなど、

積極的な IT マネジメントを遂行できるようになります。

 

 

 

ホワイトカラー生産性調査をどのようにすれば良いのか

 

 

測定が難しいシステム導入によるホワイトカラーの生産性向上度合いを、

短期間で簡易的に調査して定量的に示します。 

 

さらに、その部門の“業務項目”にブレイクダウンしその効果を示します。

 

同時に、定性面での特徴も示すことで、数値とその論拠をマネジメント層がわかるような形で表現します。 

 

 

生産性調査でよくみられる“調整”や“資料作成”といった作業項目での評価のみならず、

年度計画立案”“市場調査”といった、マネジメント層が理解できる業務項目ベースで効果を示すべきです。

 

 

 

RPAは従来のシステム変更とどう違う?

 

 

業務の自動化は業務システムの見直しでも実現できますが、RPAは概念が異なります

 

 

例えば、顧客管理業務のケースで考えてみましょう。 

 

顧客管理システムが導入されている企業でも、

顧客データのインポート作業などはたいてい人の手で行ないます

 

また、入力作業の報告メールを送ったり、入力作業後に他のスタッフがダブルチェックしたり、

人手による作業はそれなりに発生します

 

業務効率化のためにシステム改修を行なったとしても、

システム間のデータ移行やチェック業務などはなかなかシステムに組み込みにくい作業です。

 

一方RPAの場合、入力作業からチェック、報告までのプロセスすべてをソフトウェアロボットが代行します。 

 

つまり、

システム変更ではカバーしきれない業務範囲でも、RPAでは自動化できる可能性が高い

というのがポイントです。

 

システム変更ではイレギュラー対応など非定型業務の自動化が難しいケースが多いのですが、

RPAならAIなどの導入で実現できるケースもあります。

 

 

 

RPAでロボットがホワイトカラー業務を代行できる時代へ

 

 

とある銀行グループが業務自動化技術を導入して、

9,500人相当の仕事量を削減する方針を20179月に発表したことが大きな話題となりました。 

 

この業務自動化技術のメインとなるのが、

RPA(Robotic Process Automation:ロボットによる業務効率化)です。 

 

もちろん、RPAの導入により、

品質の向上とリードタイムの短縮、労働不足の解消につながっており、効果は出ているそうです。

 

 

ロボットによる業務代行というと製造業をイメージしがちですが、

RPAはPCを使った業務などホワイトカラーの業務を代行します。

 

そのため、仮想労働者(デジタルレイバー)とも呼ばれることもあります。

 

ロボットによる業務効率化というと、単純作業の代行というイメージを持つ方も多いかもしれません。

 

RPAでは3つのクラスに分かれていて、最も高度なクラス3になると

AI(人工知能)の学習能力によって分析や業務改善などの複雑な業務ができるものもあります。

 

 

<クラス詳細>

  • RPAクラス1:定型作業の自動化
  • RPAクラス2:一部非定型作業の自動化(イレギュラー対応もできる)
  • RPAクラス3:高度なタスクの自動化(業務プロセスの分析・改善もできる)

 

 

RPA2016年以降、働き方改革の手段の1つとして注目を集めている技術です。

 

自動化技術などの導入により、

人間は人にしかできない仕事や新しい仕事を担当するようになるでしょう。

 

 

仕事に必要なスキル向上も合わせて行い、オフィスワーク全体の生産性を高めていきます。

 

今、人が行なうPC業務をRPAによって自動化することを目指している企業は少なくありません。

 

 

 

 

オフィスワークにおけるAI導入: メール/文書分析

2018.09.26

 

今回のブログでは、オフィスで行われる事務作業について

既にAIの技術が開発され導入していっている事例をご紹介したいと思います。

 

 

 

昨今の電子化の流れを受け、ビジネス上の様々な情報が電子データとして扱えるようになってきました。

 

これは即ち、AIにとって「教師データ」となるソースが質量ともに高まったことを意味し、

ビジネスシーンにおけるAIの活躍の場を押し広げる事に繋がりました。

 

 

教師データ」というのは、AIが学習する上で必要不可欠な参考データのことですが、

これは端的に言えば、今まで人間様が行っていた判断・意思決定の記録を意味します。

 

 

 

例えば、今まで社員が夜を徹して行っていた文書やメール文などの

チェック業務のレコードを「教師データ」としてAIに学習させれば、

 

次からはAIが自動で今までの判断基準を参考に人間の代わりにチェックを行ってくれるようになります。

 

 

 

今回のブログでは、AIを使ったユニークなビジネスソリューションを展開している、

FRONTEO社の取り組みをご紹介したいと思います。

 

 

FRONTEO社は2003年に設立、現在マザーズに上場しています。

 

KIBITとという独自の人工知能モデルを活用し、

法律事務所や医療機関、官公庁や民間企業へのサービス展開を行っている企業になります。

 

 

特に実績として名高いのは、

法律関係での「ディスカバリ」とよばれる

訴訟案件における証拠の収集や特定、提出にいたるプロセスと、

 

フォレンジック」という

情報漏えい、談合・カルテル、横領、労務問題、ハラスメント問題、セキュリティ事案

をはじめとするさまざまな不正調査プロセスへのAI適用です。

 

 

これらいずれの業務も、本来人間(調査員)が行う場合は、

膨大な量の文書や電子メールでのやりとりのチェックが発生します。

 

 

この膨大な調査業務をAIで効率化するというのが、サービスのコンセプトになります。

 

 

参考: FRONTEO ホームページ(http://www.fronteo.com/

 

 

 

 

少ない教師データでも学習効果を高められる独自人工知能技術「KIBIT」

 

 

FRONTEO社では、Landscapingと行動情報科学を併せた同時の人工知能術を開発しており、

 

特徴としては少量の教師データで、パターン解析・学習をすることができることを謳っています。

 

 

この「教師データ」というものは、AIを実務で活用しようとするときに必ず直面する厄介な問題です。

 

AIの精度をそれなりのものにするためには、まず実際に人間が行った

評価・判断・意思決定に付随するデータをAIに「喰わせる」必要がありますが、

 

実際にそのファクトとなるデータがなかなか集まらず

結果、AIの学習が滞り、「頭の悪いAIしか育たないケースが散見されます。

 

 

 

これは、AIの一大分野である「画像認識」の技術でも言えることです。

 

 

よくIoTとの絡みで、工場内の検品業務にAIを導入するような取り組みが

新聞雑誌で取りざたされることがありますが、

 

この場合も事前に人間が判別した「不良品」の画像データを相当数AIに喰わせる必要がありますが、

そもそもそれほど不良品率が低い工場だと、教師データ自体が集まりません。

 

これを改善する方法として「不良品」ではなく「良品」のほうを教師データとしてAIに入れ、

その基準から外れたとAIが判断したものを「不良品」と一次判定するような取り組みが挙げられていたりします。

 

 

いずれにせよ、この工場の検品という領域ではまだ大ロット少品種の大量生産品が対象であり、

ジュエリーなどの小ロット多品種のケースではまだまだAIの導入の壁は高い印象です。

 

 

この「教師データ」の問題を、FRONTEOが得意とするフォレンジックの領域に当てはめると、

 

例えばそれは社内の社員の不正の証拠となる電子メールの数々が「教師データ」となります。

 

 

FRONTEOでは、おそらく膨大な数のクライアントにおける不正事例をもっており、

それをAIにインプットし学習させているのだと推測されます。

 

この社員のメール文面から不正示唆を判別する能力ですが、しっかりと学習されたAIであれば、

普通の一般的では見過ごしているような点まで気づいてくれるようになります。

 

例えば、一見、サプライヤーの担当者と親睦を深めるために飲みに誘うだけにしか見えない

メールであっても、わずかなニュアンスの違いを検知し、

談合の可能性を示唆してくれるようになります。

 

 

 

 

 

様々なビジネスシーンへの適用可能性

 

 

このような文書やメール文を解析し示唆をだすAI技術ですが、

この効能の潜在的価値はビジネス上で計り知れません。

 

 

そう、それは何も法律関係に事象にとどまらず、かなり広範囲に適用できる武器となりえます。

 

例えば、以下のようなシーンでの活用が見込めます。

 

 

  • 人事部: 退職リスクの事前検知
    • 全社員のメールをAIに定期的に読み込ませることで、退職する可能性のある社員(モチベーションが下がってそうな社員)をいち早く発見
    • 人事部は、いちはやくそのような社員にフォローを手掛けることで、離職率の減少に貢献できる
  • 人事部: パワハラ・セクハラの防止
    • 上司のメールや、社員の愚痴メールなどをAIが検知
    • パワハラ・セクハラの兆候をいち早く検知し、人事部側で防止策をとれる
  • 営業部: 失注リスクの事前検知
    • 既存顧客との担当営業のメールや日報等をモニタリングし、失注リスクをいち早く検知
    • 営業マネージャーは、失注リスクのある顧客に対していち早くフォローを講じれる
  • コールセンター: 潜在的営業機会の検知
    • 顧客からの問い合わせメールやコールセンターでの録音データをテキスト化したものから、潜在的な営業機会を検知
    • 営業としては、受注確度の高い問い合わせを優先的に開拓することができるようになる
    • さらに発展系として、顧客の問い合わせメールを、クレーム、改善要望、感謝といったようなカテゴリに分類し、それぞれの関係部署に転送することも考えられうる

 

 

ここで挙げた事例は、ほんの一部にしかすぎず、

アイデア次第では様々な用途にこの技術が使われうることは皆さん用意に想像できるかと思います。

 

 

要するにこの技術は、

「テキストデータ群から、ある傾向をもつものを自動で抽出する技術」

に他なりません。

 

 

我々の日常業務は常にドキュメントやメールといったテキストデータに囲まれています。

 

 

 

また、最近では音声データの自動テキスト化技術も急速に発展していっています。

 

これは即ち、

コールセンターでの応答や、入社面接での面談応答、会議の討議内容といったことまで自動でテキスト化され、

AIの恩恵に与れるようになるということです。

 

 

今まで熟練社員でしか見つけられなかった「気づき」のノウハウを、

入社1日目の新入社員でも享受できるようになる時代が到来しようとしています。

 

 

 

 

RPAとの関係

 

 

最後に、このKIBITのようなAI技術とRPAの関係について述べたいと思います。

 

RPAは他のコラムでもご紹介している通り、現在市場で実装されているものは「考える」力は持たず、

手を動かす」方を中心に自動化するのが主流でした。

 

つまり、判断や示唆出しといったものではなく、

その後の定型操作・作業の自動化のみに特化しているということです。

 

一方、AIの技術というものは、まさに今回のコラムでご紹介したFRONTEO社の技術のように、

まさしく人間が「考える」とこであった判断・示唆出しを高度に自動化してくれます。

 

 

このAIRPAが融合できたときに、

考える」ことと「手を動かす」こと

が同一のPCもしくはサーバ上で行えるようになります。

 

これこそがロボットワーカーの最終形態とも呼べるものであります。

 

このAIRPAの融合というテーマは、昔から様々な識者が唱えている事であり、

 

近い将来に実際の巷間のオフィスで実現化される可能性が高いと言えます。

 

そのような世界が到来した時、RPAの活用はさらにもう一段広がることは確実であり、

人間である社員側は今とはまた違う働き方を求められる世界がやってくることになります。

 

 

 

 

【UiPath Orchestrator環境を構築する】 その4 Orchestrator

2018.09.25

 

前回は、UiPath Orchestrator環境を構築するために、ElasticsearchKibanaをインストールしました。

 

 

【前回記事はこちら】

【UiPath Orchestrator環境を構築する】 その3 ElasticsearchとKibana

 

 

 

今回は、Orchestratorをインストールします。

 

今回も、Orchestrator v2018導入ステップバイステップガイドを参考にしながら、インストールしていきます。

 

OrchestratorTCP443ポートを使用しますが、インストーラーが設定してくれます。

 

インストーラーは、UiPathサイトからダウンロードできます。

インストーラー実行後、ライセンス条項に同意して、「Advanced」を選択します。

 

 

 

 

デフォルトのインストール項目にOrchestratorは含まれていませんので、追加しましょう。

 

 

 

 

不要な項目を外して、Orchestratorだけをインストールすることもできます。

 

今回は、Orchestrator Websiteとロボットロボット自動起動機能をインストールします。

 

 

 

 

ホスト名が正しいことを確認して次に進みます。

 

 

 

 

Application Pool Identity」を選択して次に進みます。

 

 

 

 

SQL Server名uipath_sqlの名前パスワードを入力して次に進みます。

 

 

 

 

ElasticsearchURLを入力して次に進みます。

 

 

 

 

Windows認証を使用する場合は、チェックを入れて、ADドメイン名を入力します。

 

今回は、チェックを入れずに進みます。

 

 

 

 

Install」をクリックします。

 

 

 

 

インストールが完了しました。「Launch ~」のチェックを外して終了します。

 

 

 

 

インストーラーがちゃんとWindowsファイアウォールを設定してくれたか確認します。

 

 

 

 

TCP443ポートが許可されています。

インストーラーでロボットの自動起動を選択した場合は、サービスも確認しておきます。

 

 

 

 

IISマネージャーで「UiPathOrchestratorYYYY.X」サイトが作成されていることを確認します。

 

 

 

 

SSMSUiPathデータベースにテーブルが作成されていることを確認します。

 

 

 

 

続いて設定ファイルを確認します。

 

まず、IISマネージャーでサイトを停止します。

 

 

 

 

サイトが停止したら、設定ファイル

C:\Program Files (X86)\UiPath\Orchestrator\Web.config

をメモ帳で開きます。

 

 

組織単位機能を有効にしたい場合は、「OrganizationUnit.Enabled」を検索し、

見つかった行のfalsetrueに変更します。

 

Orchestratorガイドには、まだテスト中、と書いてありますが、

この機能を必要とする環境は多いと思います。

 

 

 

 

Web.config内では、「<!–」と「–>」で囲まれた部分はコメントアウトされます。

続いて、Orchestratorのログの書き込み先を確認します。

 

logger name」で検索すると見つかります。

 

 

 

 

図のようにdatabase, robotElasticBufferと書かれている場合は、

SQL ServerElasticsearchの両方にログが書き込まれます。

 

Orchestratorガイドには、200万を超えるログを保持すると、

パフォーマンスの問題が発生する場合がある、と書かれています。

 

書き込み先をElasticsearchのみにする場合は、「database, 」を削除します。

 

 

 

 

Web.configには他にもたくさんの設定項目がありますので、Orchestratorガイドを見ながら、

ご自身の環境に合うように設定しましょう。

 

 

Orchestratorガイドは、ところどころ和訳文がわかりづらくなっているので、

英語版を読む方がよいかもしれません

 

 

 

Web.configの確認/変更が終わったら、IISマネージャーでサイトを開始します。

 

 

 

 

Orchestratorの画面を見てみましょう。

 

ブラウザで「https://ホスト名」を開きます。

 

ブロックされる場合は、信頼済みサイトに追加します。

 

 

 

 

 

 

Login画面が表示されたら、「default」テナントに、「admin」ユーザーでログインします。

 

パスワードは「890iop」を使用します。

 

ログイン後、パスワード変更を要求されます。

 

 

 

 

 

 

Orchestratorの管理画面が表示されたら、

右上のAボタン(adminの頭文字)をクリックしてメニューを表示し、「Settings」を選択します。

 

 

 

 

Generalタブで、Timezoneを変更します。

 

 

 

 

日本のタイムゾーンを選ぶ場合は、UTC+09:00の中から探します。

 

選択後、「SAVE」をクリックします。

 

 

 

 

 

 

他のタブにも設定項目があるので、環境に合わせて設定します。

 

 

設定が終わったら、他のPCのブラウザでもアクセスできることを確認します。

 

自己証明書は信頼度が低いので、ブラウザに警告が表示されますが、かまわずアクセスします。

 

 

 

 

 

 

他のPCのブラウザでもログイン画面を確認できました。

 

 

この時点で、管理用ユーザーの追加等はできますが、ロボットの登録はまだできません

 

ロボットを登録するには、ライセンスが必要となります。

 

 

ライセンシングについては、次回、説明します。

 

 

 

 

 

 

 

おまけ1 httpsではなくhttpでOrchestrator管理画面にアクセスできるようにする

 

 

ブラウザでOrchestratorを見るたびに自己証明書で注意されるのは面倒です。

 

設定をいくつかいじって試してみたところ、

httpでOrchestratorにアクセスできるようになりましたので、

ここでは、その方法について書きます。

 

 

まず、UiPathOrchestratorサイトを停止します。

 

 

 

 

UiPathOrchestratorサイトのバインドを編集します。

 

 

 

 

まずhttpを追加します。

 

 

 

 

種類がhttpになっていることを確認してから、ホスト名を入力し、OKをクリックします。

 

 

 

 

httpsを選択して削除します。

 

 

 

 

httpsが削除されたことを確認してから閉じます。

 

 

 

 

サーバーを選択して、サーバー証明書をダブルクリックします。

 

 

 

 

サーバー証明書を削除します。

 

 

 

 

Web.configをテキストエディターで開き、https接続に関する部分を探し出します。

 

 

 

 

コメントアウトします。

 

 

 

 

Web.configを上書き保存してから、IISマネージャーでサイトを開始します。

 

 

 

 

以上で設定は終わりです。

 

 

ブラウザで「http://サーバー名」を開いてみましょう。

 

ブロックされる場合は信頼済みサイトに追加します。

 

 

念のため、他のPCのブラウザでも確認しておくとよいでしょう。

 

 

 

 

おまけ2 ディスク使用量

 

 

今回作成した3サーバーの、Orchestratorのインストールが終わった時点でのディスク使用量を調べました。

 

Orchestrator用サーバーのディスク使用量:

 

 

SQL Server用サーバーのディスク使用量:

 

 

Elasticsearch+Kibana用サーバーのディスク使用量;

 

 

 

 

 

今後、ロボットを動かしながら、ディスク使用量や、ログやデータベースのサイズの変化を見ていく予定です。

 

 

 

 

 

事例から見る中国のRPA発展外観

2018.09.21

 

近年、日本のRPA市場が急速に成長していることは言うまでもない事実ですが、

今回のコラムでは、中国のRPA市場発展を紹介していきたいと思います。

 

この数年間の中国では、モバイル決済、シェア経済などを始めた

「インタネットプラス」産業が急速に発展し、

いくつかの業界から言うと世界のトップランクになっていると言っても過言ではありません。

 

TencentBaidu、アリババ、Huaweiなどの企業は

最近盛り上がっているAIビッグデータにも力を入れています。

 

こんなITが好調に成長している環境のなか、RPAはどのようになっているでしょう。

本文は近年中国国内RPAに関するビッグニュースを基に、中国RPA発展の外観をみていきます。

 

 

Ernst & Youngがサポートする中国南方航空

 

中国南方航空(以下「南方航空」)は国営大手航空会社です。

2016年の売上は約1148億元(約1.8兆円)、運輸人数は約1.1億人でした。

近年LCCなどの格安航空の参入や燃料費上昇に伴い、コスト削減が大きい問題になっています。

 

そして、南方航空がRPAに目を付けました。

20186月前後から、その第一弾として、Ernst & Youngとコラボをし、

車内の財務システムをRPA化することを図りました。

 

Ernst & Youngはまず南方航空の財務業務を分析し、重要度の高い業務を180個洗いだしました

続きまして、最もRPA化に向いている業務を13個選出し、

費用対効果で評価した上で、試験として4つの業務に絞りました

 

つまり、「国内昇降費精算」、「銀行決済」、「コスト月報」と「食事費用精算

を先行業務として開発をし、実装すると同時にその効果を検証していったのです。

 

具体的な業務内容は公開されていないですが、

南方航空は業務を選定した理由については推測できるでしょう。

 

航空会社は分社や子会社がとても多いため、財務試算や精算する際に、

各グループ会社のデータを集めて、フォーマット変換などをし、

最終的に社内の会計システムに取り込みます。

作業の量が多く必要時間が長いです。

 

銀行決済、食事費用精算なども似たような特徴があります。

 

当然、これらの業務は費用対効果が大きく

RPA開発も比較的にしやすいとErnst & Youngが判断したのでしょう。

そして、試験段階の結果について、Ernst & Youngが目安結果を公開して、下記表1になります:

 

 

 

 

効果は極めて大きいと言えるでしょう。

南方航空は中国航空会社の中ではRPA導入の一番手として、今後とも他の業務をRPA化する予定です。

 

 

中国保険業界を攻めるデロイト

 

20186月の「CIFI中国保険財務革新会議」では、デロイトは参加者として、

自社の金融・保険会社向けRPAソリューション「小勤人」を披露しました。

デロイトの講演では、自社がRPA導入に成長したABC三社の事例を中心に説明をしました。

 

大手金融サービス企業A社はデロイトのRPAソリューションを利用し、

ネットバンキング突合業務を自動化しています。

 

内容として、RPAが毎日ネットバンキングから取引履歴をダウンロードし、

自社会計システムとの履歴を突後します。

とても単純な業務ですが、量が極めて多く、膨大な時間が使われています

 

このシステムの導入により、A社グループ全体で約200人の従業員がこの業務から解放されました。

 

大手外資保険会社B社は近年中国での業務量が急増しているため、

契約書処理と賠償データ処理業務も多くなっています

 

それを解消するために、RPAを導入しました。

RPAのメインの業務は新規契約書入力賠償データ更新になります。

 

業務内容についてデロイト詳しく語っていなかったですが、

主にシステムの間の転記、または突合業務になります。

 

それ以外、契約書の標準用語チェックもRPAが実行し、

間違っている言葉が使われたら自動で治すことが可能になっています。

 

結果として、今まで従業員10名が必要となる作業はRPAが代わりに行い

処理時間も70%短縮されました。

 

企業Cは中国国内大手上場保険会社であり、人事業務においてデロイトのRPAシステムを導入しました。

主に新入社員の情報確認などについてつかわれています。

 

例えば、

政府のサイトに身分証明書ID(マイナンバー相当なもの)により新入社員の個人情報取得

医療保険番号により医療保険情報の取得

などです。

 

導入により、該当業務の効率は50%向上しました。

デロイトのRPA小勤人」はデータ収集、入力、システム間の接続などに得意し、

さらにAIと組み合わせ、データ分析することも可能だと言われます。

 

 

アリババの「アリクラウドRPA」

 

アリババは中国ECサイト運営会社最大手として、近年世界中でも活躍しています。

会社が1999年設立以来、高速成長をし、2017年の売上は3.77兆元(約61兆円)に達しました。

規模が大きくなるとともに、各部署の業務量も急増しています。

 

対策として、2016年にアリババがRPAにたどり着き、自動化によって効率向上を図りました。

 

最初は問い合わせ対応(チャットボックス)ロボットを実装しました。

お客様から問い合わせがあれば一回ロボットがキーワード検索とナビの形で対応し、

対応しきれない場合従業員に振るという形でした。

 

実際の効果はとてもよく、アリババ傘下の各グループの各業務に普及してきました。

それが最終的に「アリクラウドRPA」(使用RPAソフトの種類は未公開)となり、

2016年から2017年の間で他社にサービス提供し始めました。

 

現在アリクラウドRPAはカスタマーサービス以外に、

財務文書処理などにも対応できるようになり、汎用性の高いロボットを開発しています。

 

小売、IT、金融、証券以外、自社既存のネットワーク

(地方政府がアリババのクラウドソリューションを採用しているところが多い)を生かし、

政府機関に「アリクラウドRPA」を導入しています。

また、アリババは2018年に中国RPA市場規模が急成長し、60%以上の増加率と信じています。

 

 

「国産」RPAソリューション、i-SEARCHの「iS-RPA」

 

i-SEARCH(芸賽旗)は2011年上海に設立されたITベンチャー企業です。

主にビッグデータなどのデータ分析に注力しています。

 

20181月、世界中にRPAが好調だという背景に、

i-SEARCHは「国内初のRPA総合ソリューション」とアピールポイントとし、

「iS-RPA」( i-Search Robotic Process Automation)を発表しました。

 

iS-RPA」は開発言語Python3.0をベースにしたRPAソフトです。

レコーディング操作、UI情報読み取り、

デスクアプリ対応、OCRなど主流RPAソフトの機能は一通り揃っています。

 

中国大手コールセンターは既に「iS-RPA」に基づいたソリューションを実装しています。

従業員の電話対応時間短縮をメインの目的として、

iS-RPA」は総合的なソリューションを提供しています。

 

まず、インタネットからのチャットボックス問い合わせはまずRPAナビに繋がり、

お客様の問い合わせ内容により割り振りをします。

そして人間が対応する段階になると、チャットする間にチャット内容をモニタリングをし、

特定なキーワードがチャット内容の中に現れるとRPAがそれに関連する情報を担当者に勧めます。

 

これにより、従業員がキーワードを検索する時間を短縮します。

また、電話対応するときもRPAによる「ワンタッチ業務」ロボットが実装され、

特定なUI操作をマウスクリックだけでバックグラウンドで実行されます。

 

iS-RPA」のコールセンターソリューションは完全な「無人化」することではないですが、

問い合わせ対応の時間を平均15%短縮することができました。

 

 

まとめ

 

中国のRPA市場は後発ではありますが、海外大手会計事務のリードやローカル企業の台頭により、

市場がどんどん拡大しています。

 

ざっくり分けると、中国のRPAベンダーは3種類があるように見えます:

 

  • 大手外資企業:Ernst & Youngとデロイトをはじめとしたグローバル企業は自社の高い技術力と豊富な経験を武器として中国市場に攻めている。
  • 大手ローカルIT企業:アリババなどの大手ローカル企業は自社の技術とローカルに馴染んだマーケティングルートなどを生かし、事業展開をしている。
  • ローカルベンチャー企業:i-SEARCHのような企業が現地市場に合わせた独特な製品を開発している。

 

また、今回の事例では、RPAを導入した企業のいずれも大手でした。

原因として、人件費による可能性が高いです。

 

近年中国の平均人件費は高くなっているとはいえ、日本に比べまだ低いです。

 

賃金の高い上海でも、現在の最低賃金は4万円弱/月になります。

この環境では、大きい規模でなければ、費用対効果はあまり良くない可能性もあります。

 

勿論、一概にはいえないですが、これは原因の一つだと考えられます。

逆に言うと、人件費が高い日本では、RPA導入がより多くの中小企業にも有効でしょう。

 

 

 

 

【UiPath Orchestrator環境を構築する】 その3 ElasticsearchとKibana

2018.09.20

前回は、UiPath Orchestrator環境を構築するために、SQL Serverをインストールしました。

 

【前回記事はこちら】

【UiPath Orchestrator環境を構築する】その2・・・SQL Server

 

 

今回は、ElasticsearchとKibanaをインストールします。

今回も、Orchestrator v2018導入ステップバイステップガイドを参考にしながら、

インストールしていきます。

 

 

まずはWindowsファイアウォールの設定をします。

SQL Server用にTCP 1433ポートを設定したときと同じ手順で、

Elasticsearch用のTCP 9200ポートKibana用のTCP 5601ポートに受信許可設定をします。

 

 

 

 

 

作成した規則をダブルクリックすると、

プロパティが表示されるので、設定内容を確認しましょう。

 

 

 

 

続いてJava Runtime Environmentをインストールします。

Javaのサイトから推奨バージョンをダウンロードします。

 

 

 

 

推奨バージョンのJREのインストールが完了したら、

エクスプローラーでインストールされたフォルダのパスをコピーします。

 

 

 

 

コピーしたパスを、環境変数JAVA_HOMEに設定します。

 

スタートメニュー右クリック→システム→システムの詳細設定→環境変数

 

の順にクリックしていきます。

 

 

 

 

 

 

 

環境変数ウィンドウが表示されたら、ユーザー環境変数(上段)ではなく、

システム環境変数(下段)の新規ボタンをクリックします。

 

 

 

 

変数名に「JAVA_HOME」と入力し、

変数値に先ほどコピーしておいたパスをペーストしてOKをクリックします。

 

 

 

 

システム環境変数にJAVA_HOMEが追加されたことを確認したら、

OKをクリックしてウィンドウを閉じます。

 

 

 

 

 

Javaの設定が終わりました。

 

 

次は、Elasticsearchをインストールします。

 

Elasticsearchのサイトから、インストーラーをダウンロードします。

 

 

 

 

ダウンロードしたインストーラーを実行すると、ウィザードが表示されます。

 

LocationとServiceについては、デフォルト値を使用するので、

NEXTをクリックするだけでよいです。

 

 

 

 

 

 

Configurationでは、いくつか確認すべき点があります。

まずはウィザードが自動入力してくれているNode nameがホスト名になっていることを確認しましょう。

ADに参加している場合は、ドメイン部分まで書きます。

 

 

 

 

次に、Elasticsearchが使用するメモリサイズを指定します。デフォルトは2GBです。

ステップバイステップガイドには、OSメモリの半分以下を割り当てる、と書かれています。

今回使用しているサーバーはメモリが4GBしかないせいか、2GBから変更できませんでした。

 

 

 

 

もっと多くのメモリが積まれている場合は、

つまみを左右に動かすことによって割り当てるメモリサイズを変更することができます。

 

Hyper-Vの仮想マシンで動的メモリを有効にしている場合は、注意が必要です。

動的メモリの場合の注意点については、後半のおまけの中で説明します。

 

 

Lock JVM memory」は、スワップによるパフォーマンス低下を避けるための設定です。

ここではデフォルトのままにしておいて、使用していくうちに問題が出てきたら設定を変えることにします。

 

Network hostは空欄にしておきます。

ここを空欄(デフォルト)にしておくと、localhostからのアクセスのみを受け付けるようになります。

インストールが無事成功したら、設定ファイルを編集し、

プライベートIPアドレスからのアクセスも受け付けるように設定しなおします。

 

 

 

 

ウィザードを進めると、プラグインを選択するパートになりますが、

筆者の環境ですと、日本語検索のためのプラグイン「Japanese (kuromoji) analysis」等

にチェックを入れるとValidation Errorとなり、インストールを進められなくなります

 

 

 

 

よくよく見てみると、ステップバイステップガイドのサンプル画像でもValidation Errorが出ています

ひとまずここはチェックを外して、プラグイン無しでインストールします。

Elasticsearch installed successfully」と表示されたら、さっそくブラウザで確認してみましょう。

Open Elasticsearch in the browser」をクリックします。

 

 

 

 

Internet Explorerのダウンロード

~.json このファイルを開くか、または保存しますか?」が表示されたら、

ファイルを開きます。

今回は内容を表示するだけですので、ファイルを開くためのアプリは何でもかまいません。

 

 

 

 

 

 

 

 

 

ブラウザを閉じて、ウィザードを終了します。

設定ファイルを編集するために、サービスを終了します。

 

 

 

 

C:\ProgramData\Elastic\Elasticsearch\config\elasticsearch.yml」をメモ帳で開きます。

C:\ProgramData」フォルダは、デフォルトでは隠しフォルダになっています。

 

 

 

 

ウィザードではデフォルトにしていたNetwork hostの設定を追加します。

追加する内容は、「network.host: _site_, _local_」です。_site_は、

プライベートIPアドレスからのアクセスを受け付ける設定、_local_は、

localhostからのアクセスを受け付ける設定です。

 

 

 

 

変更内容を保存してメモ帳を閉じたら、サービスを起動します。

 

 

 

 

http://localhost:9200」と「http://ホスト名:9200」の両方で接続できることを確認します。

 

http://ホスト名」が信頼済みサイトではない、という警告が表示されたら、

信頼済みサイトに追加してから、もう一度URLを入力します。

 

 

 

 

さらに、同じネットワーク内にある他のPCのブラウザでも、

http://Elasticsearch用サーバー名:9200」で接続できることを確認します。

 

 

 

 

設定が反映されたことを確認できたら、先ほど入れられなかったプラグインを追加しましょう。管理者権限のコマンドプロンプトで、以下のコマンドを入力します。

 

cd \Program Files\Elastic\Elasticsearch\bin

elasticsearch-plugin.bat install analysis-kuromoji

 

 

 

 

成功すると、「Installed analysis-kuromoji」と表示されます。
サービスを再起動すると、プラグインが読み込まれます。
Elasticsearchの設定は以上です。

 

 

 

次は、Kibanaをインストールします。

Elasticsearchのサイトから、ZIPファイルをダウンロードします。

 

 

 

 

ダウンロードしたZIPファイルをダブルクリックすると、

kibana-5.5.2-windows-x86」というフォルダが表示されるので、

これを、「C:\ProgramData\Elastic」フォルダ内にコピーします。

 

 

 

 

ファイル数が多いのでコピーには時間がかかります。コピーが終わったら、

フォルダ名を「kibana-5.5.2-windows-x86」から「Kibana」に変更します。

 

 

 

 

C:\ProgramData\Elastic\Kibana\config」内のkibana.ymlをワードパッドで開きます。

メモ帳で開くと、改行されていない状態で表示されてしまうので、ワードパッドを使用します。

server.host」の設定を追加してテキスト形式で保存します。

 

 

 

 

 

 

C:\ProgramData\Elastic\Kibana\bin」フォルダ内にあるkibana.batを実行します。

 

 

 

 

Status changed from yellow to green – Ready」と表示されたら、成功です。

このコマンドプロンプトは閉じてしまうと、Kibanaも同時に終了してしまいます

コマンドプロンプトをそのまま置いておいて、Internet Explorerで「http://自ホスト名:5601」を開きます。

 

 

 

 

about:blank」に関する表示が出たら、信頼済みサイトに追加します。

 

 

 

 

Configure an index pattern」というページが表示されれば成功です。

 

 

 

ブラウザとコマンドプロンプトを閉じてKibanaを終了します

(インデックスパターンの設定は、Orchestratorをインストールした後に行います)。

 

Kibanaをサービスに登録するために、NSSMを使用します。

NSSM 2.24のZIPファイルをNSSMサイトからダウンロードします。

 

 

 

 

ダウンロードしたZIPファイルをダブルクリックすると、

nssm-2.24」というフォルダが表示されるので、

これを「C:\Program Files」フォルダにコピーします。

 

コピー後、管理者権限のコマンドプロンプトで、以下のコマンドを入力します。

 

 

cd \Program Files\nssm-2.24\win64

nssm.exe install “Elasticsearch Kibana” “C:\programData\Elastic\Kibana\bin\kibana.bat”

 

 

 

Service “Elasticsearch Kibana” installed successfully」と表示されたら成功です。

サーバーマネージャーからサービスを起動して、

Elasticsearch Kibana」サービスが登録されていることを確認しましょう。

 

 

 

 

自動起動設定はされていますが、

この時点ではまだ「Elasticsearch Kibana」は実行されていません。

右クリックして「開始」します。

 

 

 

 

 

 

Elasticsearch Kibana」サービスが「実行中」状態になりました。

Internet Explorerで「http://自ホスト名:5601」を開いて、

Configure an index pattern」が表示されることを確認します。

念のため、他のPCのブラウザでも確認しておくと良いでしょう。

 

 

 

 

以上で、ElasticsearchとKibanaの設定は終わりです。

 

 

次回は、Orchestratorをインストールします。

 

【次回記事はこちら】

【UiPath Orchestrator環境を構築する】 その4 Orchestrator

 

 

 

 


おまけ1 Hyper-V仮想マシンへのElasticsearchインストール

 

Hyper-Vの仮想マシンで動的メモリを有効にしている場合、注意が必要です。

 

 

 

 

動的メモリが有効になっていると、

ウィザードが起動された時点で仮想マシンに割り当てられていたメモリサイズが、

ウィザード上でElasticsearchに割り当てられるメモリサイズの最大値となってしまいます。

 

 

 

動的メモリを無効にしている場合

 

 

 

 

 

 

 

動的メモリを有効にしている場合

 

 

 

 

 

動的メモリを使用する場合は、あらかじめ「この仮想マシンが使用できるメモリの量」、

もしくは、「最小RAM」を大きめに設定しておきましょう。

 

 

 

 

【UiPath Orchestrator環境を構築する】その2・・・SQL Server

2018.09.19

【前回記事はこちら】

 

【UiPath Orchestrator環境を構築する】 その1 初期設定

 

 

 

前回は、UiPath Orchestrator環境を構築するためのWindows関連の設定を行いました。

 

 

今回は、SQL Server用サーバーに、SQL Server 2017をインストールします。

 

まずはWindowsファイアウォールを設定します。サーバーマネージャーのツールメニューで、

セキュリティが強化されたWindowsファイアウォール」を選択します。

 

 

 

 

セキュリティが強化されたWindowsファイアウォール」が表示されたら、

左ペインの「受信の規則」を選択してから、右ペインの「新しい規則」をクリックします。

 

 

 

 

新規の受信の規則ウィザード」が表示されたら、「ポート」を選択して次に進みます。

 

 

 

 

TCP」と「特定のローカルポート」を選択し、

SQL Serverが使用するポート番号「1433」を入力してから、次に進みます。

 

 

 

 

接続を許可する」を選択して次に進みます。

 

 

 

 

規則が適用されるプロファイルは、ご自身の環境に合わせて選択してください。

筆者の環境では特に限定する必要が無いので、すべてにチェックを入れています。

 

 

 

 

最後に、受信規則に名前を付けます。「SQL Server」等、わかりやすい名前を付けましょう。

完了をクリックすると受信の規則が追加されます。

 

 

 

 

SQL Server用の受信の規則が作成されました。

 

 

 

ファイアウォールの設定が終わったら、SQL Serverをインストールします。

SQL Server 2017の評価版は、Microsoftのサイトからダウンロードできます。

 

 

EXE形式をダウンロードして起動すると、インストールの種類を選択する画面が表示されます。

メディアのダウンロード」を選択すると、インストールメディアをISO形式でダウンロードできます。

 

 

 

 

 

 

ダウンロードしたISOファイルをダブルクリックすると、メディアの中身が表示されます。

Setupを実行すると、SQL Serverインストールセンターが表示されます。

 

 

 

 

 

 

左のインストールメニューから、新規スタンドアロンインストールを実行します。

 

 

 

 

今回は、無償のエディションを指定します。

 

 

 

 

ライセンス条項に同意すると、ルールチェックが行われた後に、

Microsoft Updateを使用するか尋ねられます。

チェックを入れて次に進みます。

 

 

 

 

インストールルールでチェックが行われます。

Windowsファイアウォールの警告は無視してよいです。

 

 

 

 

インストールする機能の選択で、「データベースエンジンサービス」を選択して次に進みます。

 

 

 

 

インスタンスの構成で「既定のインスタンス」を選択します。

 

 

 

 

サーバーの構成では、照合順序を「SQL_Latin1_General_CP1_CI_AS」に設定します。

 

 

 

 

 

 

 

 

認証モードはどちらでも構わないようです。

今回は混合モードに設定します。

現在のユーザーの追加」を行ってから、次に進み、インストールを実行します。

 

 

 

 

 

 

 

 

インストールが完了したら、SQL Serverインストールセンターも終了します。

SQL Server関連サービスの設定を確認します。

サーバーマネージャーのツールメニューからサービスを選択します。

 

 

 

 

 

 

続いてSQL Server Management Studio (以下SSMS)を、

Microsoftのサイトからダウンロードしてインストールします。

インストーラーを実行して、インストールボタンを押すだけです。

 

 

 

 

 

 

スタートメニューの「Microsoft SQL Server Tools」内にある、

SSMSを起動してSQL Serverにログインします。SQL Server認証で接続します。

 

 

 

 

ログイン後、オブジェクトエクスプローラで、UiPathデータベースを作成します。

 

 

 

 

データベース名に「UiPath」と入力し、OKをクリックします。

 

 

 

 

次に、新しいログインを作成します。

 

 

 

 

全般メニューで、ログイン名「uipath_sql」を入力します。SQL Server認証を選択します。

 

 

 

 

次に、サーバーロールメニューで、dbcreatorを追加します。

 

 

 

 

続いて、ユーザーマッピングメニューで、masterデータベースとmsdbデータベースのpublic

UiPathデータベースのdb_ownerpublicの役割を与えたら、

OKをクリックしてユーザーを作成します。

 

 

 

 

 

 

 

 

最後に、作成したユーザーに権限を与えるクエリを発行します。

新しいクエリ」ボタンをクリックします。

 

 

 

 

以下のクエリを書き込んだら、「実行」ボタンを押します。

 

USE master

GO

GRANT EXECUTE TO [uipath_sql]

GO

 

USE msdb

GO

GRANT EXECUTE TO [uipath_sql]

GO

 

 

作成したユーザーでログインできることを確認するため、SSMSを終了してから接続しなおします。

終了時にクエリを保存するかどうか尋ねられますが、保存する必要はありません。

 

 

 

 

以上でSQL Server関連の設定は終わりです。

 

次回はElasticsearchKibanaをインストールします。

 

 

【次回記事はこちら】

【UiPath Orchestrator環境を構築する】 その3 ElasticsearchとKibana

 

 

 

 

 

おまけ UiPathデータベースの中身

 

UiPathデータベースの中身が気になる人もいらっしゃると思います。

今回の手順ではデータベースを作成しただけなので、

テーブル一覧を表示させても結果は下図のようになります。

 

 

 

 

Orchestratorのインストール直後に同じことをすると、以下のような結果が出ます。

 

 

 

 

58個のテーブルが作成されています。

ときどき中身を確認したくなりそうなテーブルもいくつか作られています。

 

 

 

 

 

 

 

【UiPath Orchestrator環境を構築する】その1・・・初期設定

2018.09.18

UiPathの扱いに慣れてくると、

きっとUiPath Orchestratorを使ってロボットを管理してみたくなるでしょう。

 

UiPath Orchestratorを導入することにより、スケジュール管理やログ管理など、

さまざまなことを実現できます。

 

UiPath Orchestratorを試すのに最も簡単な方法は、

UiPath社が公開してくれているUiPath Community Edition Orchestratorを利用することです。

 

簡単な手続きをするだけで、UiPath Orchestratorによるロボット管理の雰囲気を掴めるようになります。

こちらを利用しても良いのですが、サーバサイドの理解も深めるために、

UiPath Orchestrator環境を構築してみようと思います。

 

UiPath Orchestrator環境を用意するために必要なハードウェア要件やソフトウェア要件は、

UiPath Orchestratorガイドにまとめられていますので、一度、目を通してみてください。

 

 

大まかに言うと、以下の役割を果たすWindows Serverを用意することになります。

 

・UiPath Orchestrator Web Server (必須)

・Microsoft SQL Server (必須)

・Elasticsearch、Kibana (オプション)

 

基本はサーバー3台、小規模な環境ではサーバー2台でも可、とガイドに書かれています。

今回は、Hyper-V上に仮想サーバー3台を用意します。

 

 

Orchestrator v2018導入ステップバイステップガイドを参考にしながら、

以下の順番でインストールしていきます。

 

1:Windows Serverの設定

2:SQL Serverの設定

3:ElasticsearchとKibanaの設定

4:Orchestratorの設定

 

今回はWindows Serverの設定をします。

MicrosoftのサイトからWindows Server 2016評価版をダウンロードできます。

 

 

まずはOSのインストールやネットワークの設定、Windows Update等を済ませましょう。

準備が終わったら、以下の設定を行っていきます。

 

1:役割と機能の追加

2:Web Deploy 3.5とURL Rewrite 2.1のインストール

3:自己署名証明書の作成

 

いずれも、Orchestrator用サーバーに対して行います。

 

 

まずは、役割と機能を追加します。

念のため、デフォルトの役割と機能を確認しておきます。

 

 

 

 

ウィザードをサーバーマネージャーから起動して、役割と機能を追加していきます。

 

 

 

 

ウィザードが表示されたら、「サーバーの役割の選択」が表示されるまで「次へ」を繰り返します。

サーバーの役割の選択」が表示されたら、「Webサーバー(IIS)」にチェックを入れます。

 

たまに、追加しようとしている役割に必要な機能も追加するかどうかを尋ねられるので、

そのときは、追加してあげましょう。

 

 

 

 

次へ」をクリックすると、「機能の選択」が表示されます。

ステップバイステップガイド「2.2. 前提条件のコンポーネントのインストール」内の

表に記載されている機能を追加します。

 

 

 

 

 

 

 

 

 

 

インストールオプションの確認」に進み、

必要に応じて対象サーバーを自動的に再起動する」にチェックを入れてから、

インストールをクリックします。

 

 

 

 

 

正常に完了しました」と表示されたら、「閉じる」をクリックして終了します。

役割と機能がちゃんと追加されているか確認します。

 

 

 

 

問題なさそうです。

 

次は、Web Deloy 3.5URL Rewrite 2.1をダウンロードします。

どちらも、x86用ではなくamd64用をダウンロードします。

 

 

 

 

 

 

 

 

ダウンロードしたインストーラーを実行します。

Web Deploy 3.5は「標準」セットアップでインストールします。

 

 

 

 

URL Rewrite 2.1もインストールします。選択する項目が無いので割愛します。

 

次は、自己署名証明書を作成します。

サーバーマネージャーからIISマネージャーを起動します。

 

 

 

 

IISマネージャーで、サーバーを選択してから、サーバー証明書をダブルクリックします。

 

 

 

 

自己署名入り証明書の作成」をクリックします。

 

 

 

 

FQDNを入力し、証明書を作成します。

 

 

 

 

自己署名証明書が作成されたことを確認します。

 

 

 

Orchestrator用サーバーのWindows関連の設定は以上です。

 

次回は、ElasticsearchKibanaの設定を行います。

 

【次回記事はこちら】

【UiPath Orchestrator環境を構築する】その2・・・SQL Server

 

 

 

おまけ

 

UiPath Orchestratorとは直接関係ありませんが、

Windows Serverの設定をするときに手助けになりそうな小ネタを書きます。

 

 

 

 

おまけ1 コンピューター名の設定方法

 

 

コンピューター名の設定方法がわからない方のために。下の画像を参考にしてください。

 

 

 

 

スタートボタン右クリック→システム→システムの詳細設定→コンピューター名タブ→変更、

 

とクリックしていくと、コンピューター名の入力欄が表示されます。

新しいコンピューター名を入力してOKボタンを押すと、

再起動を促す表示が出ますので、再起動しましょう。

 

 

 

 

おまけ2 役割と機能の一覧

 

 

Windowsの役割と機能の一覧をPowerShellで出力する方法です。

Windows ServerPowerShellで「Get-WindowsFeature」コマンドを実行すると、

役割と機能の一覧を取得できます。

 

 

 

 

ただし、機能の名前が長いと、省略されてしまいます。

 

この例ですと、「Active Directoryライトウェイトディレクトリサービス」が省略されています。

 

省略させずに表示させたい場合は、

Get-WindowsFeature | Format-Table -Autosize -Wrap」を使用しましょう。

 

 

 

 

インストールされている機能だけを表示したいときは、

Get-WindowsFeature | oss | sls \[X」を使用します。

 

Format-Tableと組み合わせることも可能です。

 

 

 

 

おまけ2のおまけ

 

 

Windows10にはGet-WindowsFeatureコマンドはありませんが、

代わりにGet-WindowsOptionalFeatureコマンドを使用できます。

 

Windows10で役割と機能の一覧を取得したいときは、

Get-WindowsOptionalFeature -Online | Format-Table」とすると、見やすくなります。

 

 

 

 

【実際の導入事例】RPAを導入してから運用まで

2018.09.14

RPA導入の目的

弊社のRPA導入の最大の理由は

事務員の人手不足を解消し、より専門的な知識を必要とする業務に時間を割くこと」です。

 

人手不足の問題は多くの中小企業が直面していると思います。

弊社の事務員は女性20名ほどで構成されており、仕事内容から3つのグループに分かれています。

 

 

産休・育休を積極的に取り入れているため、結婚や出産後も安定して勤めることができる反面、

復職後の席を空けておく必要があるので、安易に新しい社員を採用できないという問題があります。

 

 

しかしながら、現場は当然人手不足に陥り、以前よりも残業を強いられることになります。

 

このような背景の中で、今回、RPAを導入し事務仕事の機械化を進めようというプロジェクトが発足しました。

 

 

筆者は、そのプロジェクトチームのメンバーの一人であり、一事務員の立場です。

 

プロジェクトチームは、3つのグループを束ねるリーダーと

各グループから1名ずつ選出されたメンバーで構成されています。

 

 

 

RPA vs 派遣社員

人手不足はRPAでしか解消されないのか、と問われれば答えはNOです。

 

弊社でも当初派遣社員の雇用が検討されていました。

 

説明するまでもないですが、休職者が復職するまでの期間限定で派遣社員を雇い、

事務員の業務の負担を軽減するためです。

 

 

比較する際のポイントは下記の2点が挙がりました。

① 費用 ・・・ 経営者サイドで重要な検討事項
② 効果 ・・・ 事務員サイドの要求事項

 

一つ目の費用については、筆者は一事務員であり具体的な数字は把握していないため割愛しますが、

結論として派遣社員よりもRPAの方が安く済むとのことでした(長期的な目で見た結果かもしれません)。

 

 

二つ目の効果については、派遣社員の場合、教育時間を懸念する声が挙がりました。

 

また、時間を割いて教育したのに関わらず期間限定で辞めてしまうのは非効率であるという意見も挙がりました。

 

一方、RPAに関しては、最初にシナリオ作成や操作者の教育に時間が必要になりますが、

長く使っていけるという意味では効率的であるという肯定的な意見が多く挙がりました。

 

こうして、経営側と事務側の意見が一致する形で、弊社ではRPAの導入が決定することになりました。

 

 

 

Winactorの導入

弊社ではRPAソフトの中でNTT系Winactorを導入しました。

理由はより感覚的に操作ができるからです。

 

 

弊社では、システム担当の社員がRPAの開発に携わるのではなく、

事務員が全て対応するという方法をとりました。

 

会社によっては情報システム課のような部署がまとめてシナリオ作成をする場合もあれば、

弊社のように現場の社員が作成する場合もあるようです。

 

 

事務員は、基本的システム系は弱かったため(筆者も専門知識はない)、

とっつきやすいソフトを選択しました。

 

 

下の画像は、Winactorの画面です。

 

 

 

 

シナリオを作成する画面ですが、ご覧の通りプログラミングのような専門知識は不要で、

必要なパーツが予め用意されています(パーツは表示されている部品は一部です)。

 

その項目を繋ぎ合わせていくとシナリオが完成するというイメージです。

 

 

例えば、エクセルを開いてA2セルの数値をコピーし、A3セルにペーストしたい場合は、

 

「エクセルを開く」→「A2セルに移動」→「選択中のセルをコピー」

→「A3セルに移動」→「選択中のセルにペースト」

 

という5つのパーツで表現することができます。

 

 

複雑な操作をしたい場合にはパーツを改造する必要が出てきますが、

一般的な事務作業には充分対応できるパーツが揃っています。

 

 

 

シナリオ作成のtips

 

上述の通り、プロジェクトは4名で進められましたが、

各チームで仕事内容が異なるため、実際には各々が異なるシナリオ作成を進めることになりました。

 

 

弊社は3日間の保証プランに入ったため、

最初の3日間はWinactorの代理人の方にお越しいただきシナリオのベースを作成してもらいました。

(詳しい契約内容は把握しておりませんので割愛します。)

 

 

基本的に、Winactorは自分たちでシナリオを作成する(そのためにより感覚的な操作が可能)こと

をコンセプトとして商品を売り出しているため、代理人に作業してもらえる3日間は非常に貴重です。

 

自分たちでシナリオを作成するためのヒントをどれほどもらえるかが勝負になります。

 

 

保証期間に臨む際のポイントは下記の3点です。

① 自動化したい業務のフローを細部まで説明できるようにしておく
② 多くのシナリオに共通する部分を作成してもらう
③ より高度な操作を要するシナリオを作成してもらう

 

 

毎日何気なく行っている作業でも、機械にやらせようとすると

一つ一つの作業を順序だてて考える必要が出てきます。(人間がいかに優秀な動物であるかを実感します。)

 

 

例えば、Aのときは○をクリックし、Bのときは△をクリックするという簡単な操作も、機械だと次のように認識します。

 

「Aの場合→true」、「A以外の場合(つまり、ここではB)→false」、

「trueの場合→○をクリック」、「falseの場合→△をクリック」

 

このように、true/falseの場合分けのような部品が必要になります。

 

 

業務フローを細部まで理解しておくことで、代理人に的確な説明をすることができ、

短い保証期間を有効に使うことができます。

 

 

 

また、共通する事務作業の部分を作成してもらうこともおすすめします。

 

クライアント毎に異なるシステムを使用している場合もあると思いますが、

社内のデータベースの操作等は共通する部分だと思います。

 

その部分を作成してもらうことで、他のシナリオ作成時にインポートして再利用することができます。

 

 

 

最後に、より複雑なシナリオ作成を依頼することも重要です。

 

やはり、プロが作成するシナリオと初心者とでは雲泥の差です。

 

 

何が違うかというと、運用した際のエラーの数が全然違います。

プロのものは、エラー対策の工程が組まれているためです。

 

エラーの対策ができるまでにはWinactorの経験が必要となると言えます。

そのため、難関な作業は最初にプロに作成してもらうことが得策です。

 

 

 

RPA導入の効果

実運用から半年以上が経過しましたが、確実に業務負担の軽減が実現しました。

 

今まで、エクセルに入力し、その情報をクライアントのシステムに入力し、

二つに齟齬がないかダブルチェックをし・・・

 

と随分無駄なことをしていたと思い知らされる日々です。

 

現在は、入力箇所が一つとなり、そこから機械が自動で必要な情報をピックアップしてくれます。

 

弊社では、クライアント毎に異なるシステムやフォーマットを使用しているため、

運用方法を覚えるということも重要な仕事の一つでした。

 

しかし、現在ではクライアントを意識することなく業務を統一化できています。

 

作業がより単純になることでミスも大幅に減り

余った時間をより専門的な知識を要する業務に割くことができています。

 

残量時間でいうと半分になった人が大半です。

 

 

 

RPA操作の課題

RPA導入により、操作する側の教育は依然として課題が多く残ります。

 

筆者もなかなか忙しい毎日を過ごしています。

 

新しいシナリオの作成も必要ですし、運用中のシナリオのエラー対策も欠かせません。

何度やってもエラーがなくならない箇所もあり、素人が操作する限界を感じることもあります。

 

 

そこで、RPA教育用の教材や研修の参加を会社から勧められたので受講を検討しているところです。

また、使う側(事務員)の教育も日々進めなければなりません。

 

事務員は今までとやり方が変わる部分を覚える必要があり、

例えばファイルを格納するフォルダを間違え、機械がファイルを認識しない等、

慣れるまでは人的ミスが発生することがあります。

 

 

こうした課題を一つ一つクリアにしていき、安定したRPA運用を実現していくことが、

プロジェクトチーム使命であります。

 

 

 

 

 

 

 

RPAのクラウド化はどこまで進んでいるのか?クラウド型RPAのメリット・デメリット

2018.09.13

RPAツールの提供形態は、大きく分けて「開発型」「オンプレミス型」「クラウド型」の3つに分かれています。

 

これまで、多くのRPAツールは、オンプレミス型として提供されており、

一部が開発型で提供されていました。

しかし最近では、RPAの機能をクラウドサービスとして提供するクラウド型も増えてきています。

 

そこで、RPAのクラウド化はどこまで進んでいるのか、

クラウドで提供されるRPAツールにはどのようなものがあるのか、

メリット・デメリットにはなにがあるのか、などを解説していきましょう。

 

 

既存RPAは開発型かオンプレミス型

 

クラウド型RPAの話しをする前に、開発型RPAオンプレミス型RPAとはどのようなものなのかを説明します。

 

 

開発型RPAとは、汎用プログラミング言語とAPIを利用して自動化をしていく形態のことをいいます。

パッケージをそのままインストールしていくのではなく要件定義から設計していきます。

 

そのため、自社の環境に合わせて柔軟にカスタマイズできますし、

自動化できる業務範囲も広げられるメリットがあります。

 

一方、高度なプログラミング知識が必要となるほか、ある程度の人員も必要になります。

そのため、導入までの期間が長くなり、コストも高めになるといったデメリットがあります。

 

この開発型RPAには「ROBOWARE」などのツールが存在します。

 

 

オンプレミス型RPAとは、RPAベンダーが用意したパッケージをインストールして使用する形態のツールです。

このタイプは「ルールベース」「マクロ」「スクリプト」など、

ある程度決められたテンプレートをもとに業務の自動化を行っていきます。

そのため、テンプレート型RPAと呼ぶこともあります。

 

オンプレミス型RPAでは、複雑なプログラミングをする必要がないため、

現場のユーザー自らが業務の自動化を実現できます。

コスト的にも、開発型RPAより安価に導入ができるといったメリットが存在します。

 

ただし、

テンプレートが提供されている単純作業以外の複雑な作業には対応できない

可能性があるといったデメリットもあります。

 

また、「どの範囲までRPAを適用できるのか」「どこまでカスタマイズできるか」

といったことはツールに依存することになります。

 

「UiPath」「WinActor」「BizRobo!」など、

市場に存在する多くのRPAツールは、このオンプレミス型RPAとして提供されています。

 

 

クラウドサービスとして提供されるRPAの登場

 

 

クラウド型RPAとは、

インターネット上のサービス(=クラウドサービス)へとログインして、Webブラウザ上で行える業務を自動化

させるものです。

 

インターネット上で必要な機能だけを提供しますので、

SaaS(Software as a Service)型RPA」と呼ばれることもあります。

 

得意とする業務は、

Web上のデータ収集やリサーチ、Excel、CSV、Google Spreadsheetsファイルなどへ出力

他のクラウドサービスへのデータ入力

あるいは、その組み合わせになります。

 

そのため、Web上のデータを取得したり取り扱ったりする定型業務に向いています。

 

 

クラウド型RPAのメリット

 

クラウド型RPAのメリットは、クラウド上でサービスが提供されることで

初期導入コストも運用コストも低く抑えられることです。

導入までの期間も短いため、すぐに導入ができるのも特長です。

 

また、クラウド型RPAで自動化できるのはWebブラウザ上で行う作業ですから、

現場の担当者が日常的に行っている業務をすぐに自動化していくことができます。

 

担当者レベルでも、導入効果をすぐに感じることができるでしょう。

 

  • ロボットを稼働させながら他の作業ができる

 

デスクトップにインストールするタイプのRPAツールの場合、インストールしたパソコン上で動作します。

そのため、ロボットを稼働させている間はパソコンが占有され、他の作業は基本的にできなくなります。

 

しかしクラウド型RPAの場合、ロボットはクラウド上では稼働していますのでパソコン自体は占有しません。

RPAツールを稼働させていても通常業務を行えるということです。

 

それだけでなく、サービスからログアウトしたとしても、Webブラウザを閉じたとしても、

さらにパソコンの電源を落としたとしても、

クラウド上で365日24時間ロボットは稼働しているわけです。

 

したがって、RPAを稼働させるためのパソコンを用意するコストや設置するスペースは必要ありません。

 

  • 別のパソコンでもすぐ稼働できる

 

RPAツールをインストールしたパソコンが故障などで使えなくなった場合、

別のパソコンにRPAツールを再度インストールし、環境設定を行う必要があります。

 

その点、クラウド型RPAなら、インターネットへ接続できる環境さえあれば、

別のパソコンを使うことで作業を継続できます。

(クラウドサービスは全般的に同じだと思いますが)

 

クラウド型RPAは、端末にサービスが紐付いているのではなく、アカウントにサービスが紐付いています。

そのため、アカウントさえ持っていれば、

異なるパソコンでも、異なる拠点でも、すぐに同じ作業が続けられるわけです。

 

 

クラウド型RPAのデメリット

 

クラウド型RPAWebブラウザ上で動作するシステムです。

そのため、他のクラウドサービスを操作したり、Webサイトから情報を取得したりといった、

Web上での作業の自動化が得意領域です。

 

その反面、パソコン内のファイル閲覧やシステム操作といった

ローカル環境での作業はできませんので、導入にあたって注意は必要です。

 

 

クラウド型RPAのルーツ

 

クラウド型RPAが登場したのはここ最近のことですが、

広義のRPA”あるいは“クラウド型RPAのルーツ

ともいえるWebサービスの連携ツールは数年前から提供されていました。

 

その代表といえるサービスは、「IFTTT」(イフト)と「Zapier」(ザピア)です。

 

これらのサービスは、「●●●がされたら、×××をする」というような

「きっかけ」と「行動」のコンビネーションが基本となります。

 

例えば、

「ツイートしたら、その同じ内容を自動的にEvernoteに保存する」

「●●●(特定の相手)からメールを受信したら、SMSでプッシュ通知する」

というように複数のWebサービスを連携してくれます。

 

ただ、IFTTTZapierもインターフェイスが日本語化されていないのはネックです。

 

日本語化された同種のサービスには、

Yahoo! JAPANの「myThings」、

Microsoftの「Microsoft Flow

があります。

 

myThingsは個人ユーザー向けWebサービスとの連携が中心になっていますが、

Microsoft Flowは、Microsoft社製アプリケーション中心に連携できるアプリケーションも増加し、

仕事でも使えるようになってきています。

 

BizteX cobitを皮切りに続々登場するクラウド型RPA

 

Webサービス連携ツールと比べ、クラウド型RPAが登場したのはつい最近のとです。

国内で提供されるクラウド型RPAとしては、20177月に登場した「BizteX cobit」が初めてとなります。

 

2018年になってからはBizRobo!を採用したクラウド型RPACREO-RPA」や、

BizRobo!をクラウド化したRPAツール「BizRobo! DX Cloud」がサービスをスタートしています。

 

また、クラウド環境である「AWS」(Amazonウェブサービス)にRPAツール「UiPath Orchestrator

を導入できるクラウド型RPA導入支援サービス「RPA on AWS」も登場しています。

 

さらに、20189月からは注目に値するクラウド型RPAも登場します。その名は「Robotic Crowd」です。

 

Robotic Crowdは、UiPathの導入支援やRPAコンサルティングで実績を持つ

株式会社チュートリアルが自社開発したRPAツールです。

 

クラウド型RPAを前提として開発したツールであるRobotic Crowdは、

ドラッグ・アンド・ドロップで直感的に操作できるほか、テキストベース(YAML)での設定もサポート。

RPA入門者から熟練開発者まで対応しているのが特長です。

 

また、ディベロッパー向けのコミュニティが提供されているので、

公開されているワークフローを利用したり、わからないことの相談・質問をしたり、

といったことが無料でできるようになっています。

 

2018年8月まではクローズドβ版として提供されていましたが、

既に大手Web系企業で採用事例もありことから、注目すべきクラウド型RPAといえるでしょう。

 

まとめ

 

クラウド型RPAWebブラウザ上で動作するシステムです。

そのため、ローカル環境だけで行うファイルの閲覧やシステムの操作などは自動化できません。

当然、基幹システムに入りこんだ作業も不可能です。

 

そのため、自社の業務内容の棚卸しをしてから導入するかどうか決めることが大事です。

ただ、開発型RPAやオンプレミス型RPAなど、既存RPAツールとの共存も可能ですので、

すでにRPAを導入している企業でもクラウド型RPAを検討する余地はありそうです。

 

 

 

地方自治体におけるBPO【vol.4】・・・オペレーター側

2018.09.12

 

【前回記事】

地方自治体におけるBPO【vol.3】・・・委託側

 

 

これまで、BPOの委託業者と自治体側について述べてきました。

本ブログはRPAに関する情報サイトなので、RPAについて述べていきたいと考えていましたが、

オペレーター側のこともと要望があったため、オペレーター側について述べていきたいと思います。

 

 

1.改めてBPOとは

ネットなどで、「BPO」と検索すると、

 

Broadcasting Ethics & Program Improvement Organization(放送倫理・番組向上機構)

 

がヒットし、情報収取するとそちらのBPOの情報がヒットするため、

BPOに関係ない分野の方から『BPOって面倒』とご指摘を受ける場合があります。

BPO関連について検索する際は、【BPO 業務改善】など、単語と組み合わせて検索すると良いでしょう。

 

そもそもBPOとは、business process outsourcingの頭文字から取っているだけで、

BPO(ビーピーオー)と呼び人もいれば、アウトソーシングと呼ぶ人もいます。

BPOを受託する会社のことをBPO業者とも呼んだり、アウトソーサーなどと呼んだりもします。

 

 

業務委託といった方が通用する場合もあります。

中には派遣と勘違いされる方もいますが、派遣と業務委託には大きな壁があり、

実際、働く人にとっては、BPOでも常駐型BPOになると

BPO業者が一切入らない派遣では働き方は大きく異なります

 

給与計算代行サービスやNHKの収納代行サービスなどもBPOの一部として以前よりも定着してきましたが、

中々理解を得られないので、経済産業省でもBPO市場規模が一番大きい

としているコールセンターを例えに説明すると理解を得られやすいかと思います。

 

 

2.BPOの分類

 BPO業者がBPO業務を分類する際、直接業務や間接業務に分類が一般的ですが、

他にも様々な分類方法があります。

 

本ブログでは、

フロント業務(受付・窓口)バックヤード業務(事務)中間業務(コールセンター・カスタマーセンター)

と分類させていただきます。

 

確かに営業や研究開発もBPO業務の一種なのですが、雇用形態が正社員をメインとしているため、

BPO関連業務で働くオペレーター目線に立つと、

フロント業務、バックヤード業務(事務)、中間業務(コールセンター)が妥当なところかと思います。

 

一般的なBPO業務として、コールセンターが代表的なものであるというのは先で述べた通りです。

例えば、コールセンターで想像が付きやすいのは、通販業界の受注センターかと思います。

 

特にTV通販は電話での受注が多く、TV通販の番組など時間帯に合わせて増員をかけたりする必要があります。

名物社長がよくテレビに出ているような大きな会社はさておき、

中小規模の会社が受注センターを運営しようとするとかなり大変です。

 

TV通販は扇動的に商品アピールをし、なおかつ購買層が高めなので、

電話注文が多く、コールセンターに頼らなければいけません。

 

 

一方、世界的なネット通販の大手などでは、電話での注文を受けることはしません。

その要因としては、注文データのデジタル化までの時間にあります。

 

電話だと電話を受けたオペレーターが電話で聞いた注文情報を発注システムに登録するまでに10分程度、

短くても登録前のチェックも含めて5分程度かかります。

 

 

しかし、ネットだと顧客がデジタル化する作業や確認まで顧客自らがやってくれるため、

 

通販業者のデジタル化にかかる時間は0分になります。

 

世界的なネット通販の大手は効率性を重視し、その代わりに安い値段設定をするよう、企業努力をしています。

大企業が本気でやっている効率化というのは見習うべき点も多いと思います。

 

先ほど述べた世界的な通販サイトだと効率化が図られており、事務系職が極端に少ないと聴いています。

世界的な通販サイトの話は極端すぎますが、中小の通販サイトでも電話での受注を受ける場合、

電話での受注が多ければ受注センターを外部に委託したり、

受注事務があるようであれば、受注事務も合わせてアウトソーシングをしたりしています。

 

話はそれましたが、

日本のBPO業界というのは特殊なものを除けば、コールセンターを中心として回っていて、

それに付随しバックヤード業務(事務)があるという形態が比較的多いようです。

 

一方で内閣府から各地方自治体に対し、窓口業務を委託するようにと通達があり、

各地方自治体の担当者はアウトソーシングするにあたり、頭を悩ませているようです。 

 

 

3.働く側について

BPOで働く人達の雇用形態は、パート派遣契約、以上の3つの雇用形態に集約されるかと思います。

 

以前であれば、BPOの雇用形態のメインとなっていたのはパート社員でした。

特に多かったのは育児中の女性でした。

子育てをしているとどうしても時間的な制約があり、

サービス残業も少ない(ないとは言い切れないのが日本の実情です)仕事を探すと、

比較的BPO関連業務になります。

 

パート社員でも中小企業の直雇用だとサービス残業が多いため、

時間的融通が利く業種や業態を選ぶ傾向があります。

 

また、配偶者控除が変更され、BPO関連業務に従事する方の中でもフルタイムで働くより、

扶養の範囲内で働きたいという方が以前より増えています。

BPOを運営する事業者にとって、短時間勤務で就労する方をどのように戦力化するかは腕の見せ所となります。

 

 

4.働く側の動向について

実際、地方自治体BPO関連で応募をかけるとこの数年で応募状況はかなり様変わり

しました。

 

 

 

実際上記添付の資料を見ていただければすぐに分かるかと思いますが、

18歳未満の子供がいる世帯は年間1%ずつ減っています。

追い打ちをかけるように求人倍率がバブル期を超えており、

転職バブルという言葉もあるように求職者と企業のバランスは崩壊しています。

ただし、女性から人気がある事務職の有効求人倍率は0.5以下なので、

事務職に関しては競争率がかなり高いです。

事務系職の少ない地域で事務系の求人を出せば、

応募者が多くてBPO事業者が勘違いし、人が辞めても次に採用すればよいと安直に考えてしまいます。

 

 

業務によって数値はかなり異なりますが、BPO関連で働くパート社員1年以内の離職率は3割と言われています。

実際、次のステップに進む人もいれば、職場が嫌になって退職する方もかなりいます。

 

特に地方自治体BPOだと、BPO業者と自治体の契約が終われば雇用も終わるため、

将来的な雇用状態を考えると退職しやすい環境です。

 

 

5BPO関連で働く人のキャリア

BPO関連で働く人のキャリアモデルとしてコールセンターも事務センターも多くは下記の通りです。

 

OP(オペレーター)→LD(リーダー)→SSV(サブスーパーバイザー)

→SV(スーパーバイザー)→MGR(マネージャー)

 

LDかSSVぐらいで契約社員、SVかMGRぐらいで正社員、といった流れでなるのですが、

それはあくまでも民間BPOでかつ長期でセンター運営がなされている場合のみです。

 

自治体BPOだと委託の契約期間が1年や、中には半年ぐらいもあります。

また数名ぐらいの規模なので、上記のようなキャリアモデルが形成されているとは言い難い状態です。

民間BPOと違い、自治体(市役所内)に入っていることが多く、そのようなキャリアモデルが築くことができません。

怖いSVが圧政を敷いている現場が比較的多いです。

 

運営能力の低いBPO業者で働くと、すぐにSVになれることはあるかもしれませんが、

基本的にSV教育はほぼないと考えるとよいでしょう。

募集要項などに教育体制が充実していると表現している企業で

本当に教育体制が充実しているところは極稀です。

 

キャリア形成を考えて、この企業では無理だと判断して辞めるケースが多く、

優秀な人であればあるほど退職までの期間は短くなります。

 

 

BPOの目的はあくまでもコストカット目的です。

ノウハウの活用を目的にBPO業者に委託するというのは建前です。

コストカットを目的に委託しているので、教育に費用はかけません

 

BPOで教育が充実しているのは、金融業界生保業界です。

どちらも中途半端な教え方をすると間違った案内や処理をすると後で大問題になるからです。

 

採用企業もダイバーシティ(多様性)ということで雇用形態を多様化することで、

応募者の掘り起こそうとしていました。

その結果、BPO関連で働く人のメインの雇用形態はパート社員が一時増えました

最近は地方自治体BPOでも契約社員にするケースが増えましたが、

雇用情勢の変化の波も、遂に地方自治体BPOまで来たかというところだと思います。

 

 

6.雇用形態について

最近話題になった2018年問題もあり、有期契約社員(パートや契約)の正社員化が進んでいるようです。

どちらかというと契約社員を採用する企業は、

試用期間という意味合いキャリアアップ助成金の受給が目的だったりします。

BPO関連でも今後は契約社員から正社員化というキャリアアップが出来るような時代が来るかと思います。

 

 

7.まとめ

オペレーターで働く人の動向は今後かなりシビアになってきます。

BPO関連業務の市場規模は拡大する一方ですが、その現場で働くオペレーター不足がすでに起こっており、

比較的高収益な専業代行(給与計算代行・経理代行)を除けば、

コールセンターや事務センターなどの人的BPOの運営は過渡期に入ってきています。

 

次回、RPAについて述べていきたいと思います。

  

 

 

【次回記事】

地方自治体におけるBPO【vol.5】・・・RPA

 

 

 

RPAを現場に浸透させるために~RPA運用研修編~

2018.09.11

 今回のコラムでは、RPAを導入した後、運用フェーズを迎える前にどのようなことを

現場の社員に対して教育を行えばよいか、RPA導入プロジェクトの経験から紹介したいと思います。

 

RPA運用フェーズにおける論点

RPAの運用フェーズを迎えるにあたって考慮すべき点は大きく

RPA業務全体の運用ルール」、「ヘルプデスク窓口について」、「ID・権限管理のルール

3つあります。以下、順番に説明いたします。

 

<RPA業務全体の運用ルール>

RPAを業務で使用していくにあたり、まずはRPA業務運用の全体像を知る必要があります

RPAではロボットを構築しますが、

それを「誰が」「いつ」「どこで」「どの業務を」「どうやって」行うかを決めなければなりません。

 

  • ロボ構築の申請方法

 

ロボ構築は現場社員が自身で行うこともあれば、

IT部門が主導してRPAを推進する形をとる企業では、

ロボ構築の機能はIT部門に集約したりと、企業によってやり方が分かれます。

 

また、ロボ構築を自身で行わない場合は、

申請してからいつまでにロボを使用開始できるのか

どのくらいの規模のロボットまでなら何週間以内にロボが完成するか

といったことまで決める必要があります。

 

ロボット構築を依頼する際にどう申請したらよいか。

私が参画したRPA導入プロジェクトでは、

ロボ構築の依頼を保守チームにメールで申請する体制を組みました。

 

ロボット構築を申請する際は、

業務フローやマニュアルと合わせてロボット構築のための申請書をメールに添付し、

それを見た保守チームがロボット化の可否判断を実施後、ロボ構築を開始するといった手順でした。

 

 

  • ロボットの内容変更の申請方法

 

ロボットの内容を変更する申請を出す際は、

上記のように一度新規でロボット構築の申請が出ているはずですので、

細かいロボットの内容はそちらを参照できるような仕組み

(例えば、フォルダ名や申請書ファイルのネーミングルールを工夫して以前申請したロボ内容を簡単に参照できるようにする等)

を作り、変更申請の際はロボットの管理番号と変更内容、変更理由のみを申請する運用としていました。

 

 

  • ロボ構築における制約

 

また、どんな業務でもロボ化してよいわけではなく、ロボ化についての制約も明確にしておくべきでしょう。

例えば、

承認行為をロボにさせない

費用対効果が出ない業務はロボット作成の優先度を下げる

顧客に直接影響がある業務の自動化は極力避ける

社内システムに高負荷を与えてしまう業務の自動化は避ける

等です。

 

 

  • ロボット構築ルール

 

ロボット構築ルールについても社内できちんと議論する必要があるでしょう。

例えば、

ロボットの命名規則をどうするか共通部品をどう使いまわしていくか

などがあげられます。

共通部品とは、一度作成したロボットを他のロボットにも転用できるようにすることです。

社内システムのログイン作業等、ある程度共通した作業は一度ログインロボットを作ってしまえば、

あとはそれを他のロボットでも使いまわしができるようにすることで、

ロボットの作成が効率的に進みますし、ロボットの品質も担保されます

 

 

  • 申請書フォーマット

 

ロボ構築の申請の際、申請者ごとに申請内容に違いや漏れがあると非常に手間なため、

これを防ぐためにも申請フォーマットを運用開始前の段階で整備しておくことをお勧めします。

 

申請内容は

・申請者の情報(氏名、部署)

・使用する社内システム

・月当たりの作業時間ロボット化できる業務か否かの確認

(承認行為を行わせない、等あらかじめロボ構築における制約事項や基準を設けるべきでしょう)

等があります。

フォーマットを作成することで、

申請内容の漏れが防げるだけでなく、ロボ構築における確認ポイントが明確になります。

 

 

  • ロボットが故障しても場合でも業務が回る業務設計

 

ロボットは一度構築したら終わりではなく、改作が必要なケースがあります。

 

例えば、ある外部Webサイトから単価等の情報をインプットして、それをExcelに貼り付けるロボットの場合、

インプット元の外部Webサイトのインターフェースが変更されると、

ロボットのデータ取得位置の情報も変わるため、ロボットの内容も合わせて更新しなければなりません。

このことから、ロボットが上記のような理由によって

使用できなくなることをあらかじめ想定した上で業務設計をする必要があります

要するに、ロボットに頼り切った業務運用をせずに、

ロボットが万が一故障しても、業務運用は正常に回る仕組みを検討するべきでしょう。

 

私が参画したRPA導入プロジェクトでは、ロボットが故障した場合でも業務運用が担保される仕組みとして、

手動業務用のマニュアルを作成したり、

1週間のうち1日はロボットを使用せずにあえて手運用で業務を行う

などの工夫をしていました。

  

 

<ヘルプデスク窓口について>

ヘルプデスクでは、RPAの総合受付窓口のような位置づけで、主にロボットの構築申請の受付、

ロボットの内容変更についての申請窓口、

ロボット障害時の対応やそのたRPAに関する問い合わせ管理の機能を果たします。

 

RPAツールは、プログラミングの知識が無くてもロボットが作れるとよく言われていますが、

そんなことはありません。ある程度のプログラミングの知識は必要です。

したがって、プログラミングの素養がないがロボを作成したいという場合はヘルプデスクに申請を出します。

 

上記でも述べた通り、この時に業務マニュアルや業務フローがあるとヘルプデスクで申請を受け付けた際も

ロボ構築担当者が業務のイメージをしやすく、ロボットが完成した後の認識齟齬を防ぐことができます。

最近では、社内ヘルプデスクにチャットボットを導入している事例もあるようです(下記をご覧ください)。

 

<参考Webサイト>

アイテック阪急阪神 RPAで社内ヘルプデスク業務を効率化する「チャットボット」入門セミナーを開催

https://itec.hankyu-hanshin.co.jp/event/2018/04/20180417.html

RPA Bank RPAで社内ヘルプデスク業務を効率化するチャットボット入門セミナー

https://rpa-bank.com/event/8017/

 

 

<ID・権限管理>

RPAで使用するIDPasswordは大きく分けて3つあります。

RPAツールを使用するためのID・Password」「Windowsアカウント」「社内システムID・Password」です。

 

  • RPAツールを使用するためのID・Password

 

まずRPAツールを使用するにあたってユーザ登録を行うと、

RPAツール上でIDPasswordが発行されます。

これはRPAを初めて使用する際に必要となり、主に新入社員などが申請の対象となるでしょう。

 

 

  • Windowsアカウント

 

RPAツールによっては、業務担当者のWindowsアカウントと

ロボットの実行端末の紐づけの設定を行う必要があります。

 

 

  • 社内システムID・Password

 

RPAで動かす社内システムのIDPasswordをあらかじめ記憶させることで、

ロボットの起動の都度IDPasswordを入力するのではなく、自動でIDPasswordを呼び出し、

処理を行うことが可能です。

 

ここで注意しなければいけないのは、

ある社員が他人の社内ID・Passwordを使ってロボットを起動し、機密情報を得る

等のセキュリティの観点からこのID・権限管理方法について検討する必要があることです。

このあたりの詳しい情報は下記をご参照ください。

 

<参考Webサイト>

KPMG RPA導入に伴う内部統制の整備ポイント~想定されるリスクにどう対応するか?~

https://home.kpmg.com/jp/ja/home/insights/2018/04/rpa-internal-controls.html

Accenture RPARPAガバナンス~本格導入に向けてのガバナンス整備の必要性

https://www.accenture.com/jp-ja/_acnmedia/Accenture/jp-ja/Documents/DotCom/FS-Architect/45/Accenture-Finance-FSArchitect-vol.45-1.pdf

株式会社イーセクター RPA の盲点 IT ガバナンスの重要性

https://www.esector.co.jp/special/rpa/rpa6.html

 

 

まとめ

いかがでしたでしょうか。

今回はRPAの運用フェーズを迎えるにあたって考慮すべき点といたしまして、

RPA業務全体の運用ルール」、「ヘルプデスク窓口について」、「ID・権限管理のルール

3つを紹介いたしました。

 

企業の規模や思想等によって運用フェーズで実施する内容は異なりますが、

大きい部分はそれほど変わらないと考えています。

既にRPAを導入し、これから運用を開始される場合はこちらの記事がお役に立てれば幸いです。

 

 

 

地方自治体におけるBPO【vol.3】・・・委託側

2018.09.10

【前回記事】

地方自治体におけるBPO【vol.2】・・・受託側

 

 

全国に地方自治体はいくらあるかご存知ですか?

 

総務省の最新データによると合計で1718(市790745183)存在します。

地方自治体の分類で、人口50万人以上の政令指定都市、人口20万人以上の中核市、

人口20万人以上いるが中核市に移行しなかった特例市の3つがあり、

政令指定都市20市、中核市54市、特例市31市、

以上の合計105市が全国的に知名度の高い自治体になっています。

 

都道府県と市町村の公務員は270万人(都道府県約135万人、市町村135万人)ほどいます。

地方公務員の中には警察や消防を除き、

市役所などに勤務する一般行政に関わる勝因は70万人弱と言われています。

 

 

今回のコラムで中心に記述するのは地方自治体に勤務する一般行政職の職員の方です。

発注側でもある地方自治体側では実際どのような問題点があるのかを記述したいと思います。

 

 

 

人事制度

地方自治体が民間委託をする際に発生する問題の多くは、

短期ジョブローテーションという人事制度が原因だと考えられます。

 

地方自治体の多くの職員、行政事務という観点では民間人が及びもしない見識がありますが、

 

人事や広報など特定業務の知識においては民間レベルからすると不足している

 

と言わざるを得ない職員が多くいます。

 

それは職員の能力不足が起因しているわけではなく、

地方自治体の人事制度上、必ず発生する問題です。

むしろその短期間で良くそのレベルに達したと驚くこともあります。

 

地方自治体職員のジョブローテーションは3年ないし5年で異動となります。

私の知る限り、5年よりも3年で異動するケースが多いようです。

 

3年で異動するジョブローテーションは地方自治体職員が行政事務全般を覚えるためには必要な制度です。

 

経験を積んだ職員が別の部署に異動し、

その代わりに未経験の職員が新たに入ってくまた一から業務を覚えるということを繰り返す

 

という制度になっており、入庁し、10年もいれば様々部署を経験することができます。

 

自治体によって差はありますが、下記の行政組織が人口20万人の中核都市の一般的なモデルとなります。

この行政組織内全てが職員の異動先の対象となります。

 

議会事務局」、「総務局」、「企画財政局」、「観光文化スポーツ局」、「市民生活局」、

福祉保健局」、「こども未来局」、「観光局」、「商業振興局」、「建設局」、「都市整備局」、

水道局」、「教育委員会」、「選挙管理委員会」、「選挙管理委員会」、「農業委員会

 

更にこの局の中でも広報課人事課などに分かれており、多種多様な部署があります。

 

例えば、

農業委員会で農地等の政策に関わっていた職員が翌年には秘書課で市長のスケジュール管理をし、

更に4年後には、選挙管理委員会で資料作成をする。

 

そのようなジョブローテーションが実際に行われています。

 

そのようなジョブローテーションを行うことで行政事務全般が分かる職員が育成されます。

最近はそのようなゼネラリストではなく、スペシャリスト育成のため、

人事制度を設けている自治体も増えています。

ただし、制度としては機能していないとは聞いていますが。

 

 

そのようなジョブローテーションの目的は、

 

癒着防止」・「適性の見極め」・「人材育成

 

おおよそこの3つの目的に集約されていると言われています。

 

 

癒着防止については、

東京医科大学の贈賄罪事件でも報道されていたため、ご存知の方もいるかと思いますが、

昔と比べて公務員の収賄起訴件数は減っており、問題ないという風潮になっています。

コンプライアンスなどの整理がなされ、職員も火ないところに煙は立たない、

という風にかなり気を付けているようで、民間の人と飲みに行くのも大変だと言う職員もいます。

 

民間と比べて、コンプライアンス研修など徹底しているようですが、

公権力をバックに業務を行う地方自治体職員は何かと言動に気を付けなければなりません

 

 

適性の見極めについては、複数の業務を経験させ、

その中で適性を見極めることは確かに必要ですが、30代以上の職員には異動の必要ないという意見もあります。

 

地方自治体と同規模の民間企業の場合、総合職で入社し、

入社時に配属された部署を中心に異動となるケースが多く、

どちらが良いのかはその職場の風土によっても変わるかと思います。

 

3年で異動するジョブローテーションだと上司も異動となりますので、

嫌な上司でも最長3年我慢すれば別になるので、民間と違い、離職率が低めである要因かと考えられます。

 

 

人材育成については、公文書の作成など様々な業務を経験する必要があると言われてはいます。

公文書の作成などはある程度ノウハウ化出来ており、

ジョブローテーションで習得する必要はないかと考えられます。

 

ちなみに国の省庁は、地方自治体の局、例えば、「企画財政局」が、国では「財務省」になり、

深度が増しており、専門性が深くなるので、中央と地方で公務員は大きく変わるという意見もあります。

 

このような目的で短期ジョブローテーションが行われ、

民間委託する際にはマイナスとして作用することが多くなっています。

 

 

1.BPO業者の管理


特に問題となるのは、BPO業者の管理面です。

先ほど、記載した通り、職員は知識不足です。またBPO業者のことも詳しくありません。

そのため、BPO業者の管理が不十分な状態に陥ってしまいます

 

地方自治体が民間委託をする際、最初に仕様書を作成します。

その仕様書が悪いため、運営管理能力が低いBPO業者でも業務を実施し、

 

更にBPO業者のやりたい放題にしてしまう結果になることが多々あります。

 

委託する業務によっても変わりますが、

1人でできる事を4人でやるなど非生産的でも地方自治体側は発注元として、

発注先に何も言わないことがあります

 

NHKの集金をやっているBPO業者に聞いたところ、

NHKだと1日60件回るけど、地方自治体で訪問業務をやった場合、115件程度で十分だと聞いたこともあります。

 

特にアウトバウンド系業務の委託でBPO業者は手を抜きます

そもそもBPOの管理能力が弱い社員が管理して更に手を抜くのでとんでもないことになります。

 

私自身もそのような現場に入らされることが何度かあり、業務改善で生産性を上げても、

手を抜く体質は変わらないので、人の配置から変える必要があり、業務改革に入るケースが多くなります。

 

BPO業務では採用も大切な業務であり、問題のある職場は、採用フローにも問題があるため、

業務改革(BPR)は業務全体の見直しが一般的な定義ですが、

BPO業務では採用も大切な業務なので、業務改革の対象となり、見直しを実施します。

 

もしこのコラムをお読みの地方自治体の委託担当職員の方がいれば、

機会があれば是非どのような面接が行われたかを聞いてみてください。

面接の内容である程度BPO業者のレベルが測ることができます。

BPO業者の面接官によって変わりますが、衝撃的な内容に驚くことになる可能性が高いです。

 

 

2.職員側の引継ぎ


地方自治体職員から今まで委託業者が何をやっているのか分からないので

委託業務の「見える化」をして欲しいと要望を受けたことがあります。

 

なぜこのようなことが生じるかというと委託開始時の担当職員が異動でいなくなり、

引き継ぎがなされていないケースが多いからです。

 

地方自治体の委託担当職員がそもそもいない場合や

管理職が1名でBPO業者対応をしているところも多くあります

 

地方自治体BPOでよく行われる月例報告会に参加する職員が少なければ少ないほど、

BPO業者を野放しにすることになります。

 

更に毎年異動の時期になると委託担当職員が変更になり、前任者から引継ぎがなされていないことが多く、

どちらかというと地方自治体BPOで手を抜きたいBPO業者にとっては歓迎する状況になります。  

 

基本的に委託担当職員は2名で、異動時期が被らないよう1年目と2年目の職員を組み合わせるなどの工夫が必要です。

地方自治体職員は3年でベテランとなり、4年目にはその部署にはいない。

そしてBPO業者の受託期間は長くなると5年などになり、もはや何を委託しているのかも分からない状態になり、

どちらが発注しているのか分からない状態になるそうです。

 

 

 

まとめ

今回は発注側である地方自治体について記載しましたが、書けないことも多いのですが、

もう少し発注側が委託のための体制を構築すれば、より良い効果が出ると思います。

 

前回でお伝えした通り、民間のノウハウでと言って丸投げして、

公にはうまくいっているように謳っていても、実は失敗事例ばかりです。

 

もし、地方自治体の委託担当者になった場合、

委託検討段階で他の地方自治体への視察を何度もして自分なりの委託モデルを作り、

その上でBPO業者の選定に入るようにするなどした方が良いかと思います。

 

【次回記事】

地方自治体におけるBPO【vol.4】・・・オペレーター側

 

 

労働市場の人手不足が与える影響

2018.09.07

2018年上半期の企業倒産の傾向

 

2018年上半期(1月~6月)の全国の企業倒産は、件数が4,148件、負債総額が7,466300万円でした。

倒産件数は前年同期比2.7%減(119件減)で、上半期としては9年連続で前年同期を下回り、

1990年(2,948件)以来の低水準に留まりました。

 

都道府県別では前年同期を上回ったのが22府県、減少が18都道府県になり、

地区別では全国9地区のうち、5地区(東北、中部、近畿、四国、九州)で前年同期を上回りました。

 

また、産業別では10産業のうち、7産業で前年同期を下回りましたが、

サービス業他(前年同期比0.1%増)が3年連続の増加、

小売業(同0.5%増)が上半期としては2007年以来11年ぶりに増加に転じるなど、

個人消費関連業種を中心に今後の推移が注目されます。

 

上半期倒産企業の特徴は次のとおりです。

  • 従業員数別:従業員5人未満の構成比が74.49%、上半期では過去20年間で最高
  • 負債額別:負債10億円以上の大型倒産が90件、上半期としては28年ぶりの100件割れ
  • 資本金別:資本金1億円以上が31件、上半期では過去20年間で最少
  • 従業員被害状況:上半期としては28年ぶりの2万人割れ
  • 「人手不足」関連倒産が184件(前年同期164件)、このうち「求人難」型が19

 

従業員5人未満の構成比が74.49%で上半期では過去20年間で最高の水準となっている一方で、

負債10億円以上の大型倒産が28年ぶりの100件割れ、資本金1億円以上の倒産が過去20年間で最少となるなど、

企業規模によって倒産の傾向が異なっています

 

 

2018年上半期人手不足関連倒産の傾向

 

東京商工リサーチによる2018年上半期の「人手不足」関連倒産のコメントは以下のとおりです。

 

“ 2018年上半期(1-6月)の「人手不足」関連倒産は184件

(前年同期比12.1%増、前年同期164件)で、前年同期を上回って推移している。

 

 内訳をみると、「後継者難」型が145件(前年同期比11.5%増、前年同期130件)、

「求人難」型が19件(同18.7%増、同16件)、「従業員退職」型が10件(同25.0%増、同8件)、

「人件費高騰」型が前年同期同数の10件になり、「後継者難」型が約8割(構成比78.8%)を占めた。

 

 2018年上半期(1-6月)の産業別では、最多がサービス業他の50件(前年同期比25.0%増、前年同期40件)。

次に、卸売業35件(同75.0%増、同20件)、建設業32件、製造業31件、小売業14件の順。

 

 2018年上半期の地区別では、全国9地区のうち関東(71→81件)、中部(17→23件)、

東北(8→15件)、四国(4→8件)、北陸(1→2件)の5地区で前年同期を上回った。

一方、減少は近畿(23→17件)、中国(10→9件)、北海道(12→11件)の3地区。

九州は前年同期同数の18件。“

 

2015年の年間の人手不足倒産件数の内、

「後継者難」型の割合は87.7%2016年は88.8%2017年は78.7%2018年上半期は78.8%となっています。

後継者不足による、「後継者難」型の割合は低下している一方で、

「求人難」型・「従業員退職」型の割合が増加しています。

 

人手不足が叫ばれる中、人手不足による影響が具体的な数字となって表れてきています

 

人手不足倒産の類型

 

1.「後継者難」型

代表者、役員の死亡・引退などに際し、事業承継者(後継者)がいないことによる廃業・倒産

 

2.「求人難」型

人手確保が困難で事業継続に支障が生じ、廃業・倒産

 

3.「従業員退職」型

中核社員の独立、転職などの退職から事業継続に支障が生じ、廃業・倒産

 

4.「人件費高騰」型

賃金等の人件費のコスト増から収益が悪化し廃業・倒産

 

代表者等の高齢化に伴う「後継者難」型の廃業・倒産は引き続き高い水準で推移すると思われますが、

今後は「求人難」型・「従業員退職」型・「人件費高騰」型の廃業・倒産割合が増加していくことでしょう

 

人手不足の主な原因

1. 生産年齢人口の減少

国立社会保障・人口問題研究所の発表によると、日本の総人口は201510月時点で約127095000人。

そのうち、15歳~64歳までの生産年齢人口は約77282000人となっています。

しかし、少子高齢社会の影響により、この数字は今後急激に減少すると予測されており、

2040年における生産年齢人口は約59777000人、

2100年には約30737000人にまで減ってしまうと考えられています。

 

2.  求人倍率の上昇と失業率の低下

2018年6月の有効求人倍率は1.62倍と高い水準となっています。

また完全失業率は2.4%となっています。

求職者の選択の余地が増えることで労働環境やイメージが悪い業界はより人手が不足する状況になります

 

3. 賃金の向上が期待できない

厚生労働省は710日、今年の中小企業の賃金上昇率が1.4%だったと発表しました。

今年度の最低賃金の引き上げ幅の目安を決めるうえで重要な参考データとされるもので、

人手不足を背景に前年を0.1ポイント上回りました。

ただし、政府が目指す最低賃金の引き上げ幅の年率3%程度と比べると、伸びは小幅なものとなりました。

 

大企業に比べ財務基盤が弱い中小企業が人件費に投下できる資金は限られているため、

賃金向上に期待が持てなくなった社員が退職したり、

採用の優位性を保つことができず人材の確保で難しい状況になり、人手不足の状況となります。

 

 

業務効率化による人手不足対応

 

今のままで仕事は回っているのに、なぜ業務効率化が必要なのでしょうか。

業務効率化は企業活動において必要事項で、これを怠ると徐々に会社の業績が悪化してしまいます。

 

社会や経済は日々動いており、顧客のニーズも速いスピードで変化します。

その変化に対応できる企業が生き残っていき、成長もしていきます。

このような環境下で利益を積み重ねていくためには、現状維持では企業価値が低下していきます。

業務効率化を図ることで、業務効率を最適化し、利益を最大値まで引き上げることができます

最大化された利益を元に資金調達を行い、そのキャッシュを次の投資に回し、

投資回収することで魅力ある企業となり、採用優位性を高めたり、

人材の流出防止につながることが期待できます。

業務効率化に着手する際に効果的なシステムとして「SaaS」や「RPA」などがあります。

 

SaaSは、各業務の作業をシステム化し、人がそのシステムをクラウド上で利用します。

業務領域は業務特化されており、人がシステムに合わせるといった特徴があります。

メンテナンス等は全てSaaS提供会社によるものであるため、

自社でその必要はなく、常に最新の機能を搭載した状態で利用可能です。

 

RPAは、人がマウスやキーボードを使用した作業をRPAに覚えさせて対応させます。

基本的にすべてのオペレーションを自動化できるため、どの業務領域にも適応でき、SaaSに比べ柔軟性は高いです。

大量に同じことを繰り返すPCオペレーション作業についてはコストメリットを享受できます。

ただし、Web上のボタン位置が変更になるなど、

動作ルールが変更になった場合には適宜メンテナンスを行う必要があります

 

中小企業では手作業で行われているアナログ作業もまだまだたくさんあるのが現状です。

SaaSやRPAの特徴を踏まえ自社に最適な業務効率化システムを導入することで、

人材不足への対応を図ることができます。

 

SaaSやRPAなどのITツールの導入に際しては、

経済産業省で行っている「IT補助金」を活用することで、最大50万円が国から補助されます。

IT補助金で、SaaSRPA導入の心理的・資金的ハードルは下がると思いますので活用をおすすめします。

 

人手不足倒産の「求人難」型、「従業員退職」型、「人件費高騰」型は、今後増加していく見込みです。

人手不足によって、徐々に自社の財務内容が棄損し倒産に近づく前に、

RPA等を導入した業務効率化に取り組むことを考えてみてはいかがでしょうか。

 

 

 

 

【RPAは強い味方】士業こそRPAを活用しよう!

2018.09.06

AIにより10年後になくなる職業ランキングなるものが繰り返し報道、SNSシェアされています。

 

しかし、日本のほとんどを占める中小零細企業の社長さんが、

そもそもITリテラシーが低く、いまだにガラケーで電話のコミュニケーションしか取らないと言っている中、

そんな社長さんを相手にする士業がAIにリプレイスメントされるとは、私は思いません

(社長もどんどん若返っているという意見もあると思いますが、

私の周りの40代社長の多くはいまだにオールドファッション側にいます。

と、いうことは20年後くらいまで中小零細企業の社長はITオンチだと思います。)

 

AIを云々言うのは時期尚早かもしれませんが、RPAとなると話は別です。

私は、RPAこそ士業にマッチするテクノロジーだと考えています。

 

税理士の仕事を例に少しシミュレーションしてみましょう。

業界の方からすると「そんなことは分かっている」と言われそうですが、

あえて他の業界の方にも分かるよう、少し初歩的なことから。

 

税理士の仕事において、最もミニマムなのは顧問として、決算申告書を作成し税務署に申告を行うことです。

顧問料として、23万円毎月、決算時期には会社の規模にもよるでしょうが、

30万円程の作業料を取るというのが一社当たりの売上です。

まあ最近はWEB使ったお客さんの獲得なども盛んな為、

顧問料はどんどん安くなっていっている傾向があるようですね。

 

そこに記帳代行や給与計算、振込入力などの毎月のルーチン業務のアウトソーシングが加わり

プラス5万、10万と月々の一社当たりの売上が増えていく構造です。

 

ただ、このアウトソーシング業務は、税理士事務所によって捉え方が違うようで、

大きく3つに分かれるようなイメージです。

 

 

まず一つ目、出来るだけ顧問料だけでやっていきたい税理士事務所。

 

古くからある所長が高齢化している事務所はこのタイプが多いですね。面倒はしたくない。

街に必ず存在する管理物件の管理費だけで存続できるから

無駄なことをしたくない超ヒマそうな不動産屋さんと同じ原理ですね。

わざわざバイト雇ってアウトソーシングするにも、その管理も大変だし。

税理士法人化してない個人事務所の場合がほとんどですね。

まあ彼らは、そもそも成長しようという意欲がないので、あまり新技術の導入にもピンとこないでしょう。

 

残りの二つは、どちらもこれから成長しようという意欲的な税理士さん。

まずはコンサル志向。出来るだけ付加価値の高いサービスを提供したいという税理士法人。

 

コンサルティングとは、月次決算からの、それをベースにした資金繰り、

また事業成長の為の投資余力や、CF経営の意識づけなど、

クラアント企業がそこそこ大きくなってきて、社長が本気で経営したいという意識が芽生えてきてからのお手伝いです。

 

彼らにとっての一番の悩みはアウトソーシングの処理。

まずこれから成長しようという税理士は独立したばかりの方が多く、

クライアント企業も新規創業をとっていかざるを得ません。

そうすると、クライアント側に経理などいるはずもなく、勢い全て税理士事務所へ丸投げという状態になります

 

社長が何も考えずに使った訳のからない領収書、くしゃくしゃの請求書などが渾然一体と封筒に入れられ送られてく。

それを一つずつ社長に確認するが、適当に処理しておいてよという返事。

理想としていたコンサルティング業務からは程遠い作業に追われ、貴重な時間の90%は消えて行く。

コンサルティングやその為の自分の勉強に割ける時間はほとんど無いのが実情です。

 

 

最後が、この面倒なアウトソーシングを全て取っていこうという意欲的な税理士法人。

 

多くは顧問をメインとする税理士法人に加え、記帳代行や振込入力のBPOを別法人として独立させていたりします。

記帳代行、給与計算、振込入力、請求書発行、たくさんある経理業務も、その全ては恐ろしいほどの単純作業です。

 

必然的に規模の経済がものをいう世界。どんどんお客さんを獲得し、

どんどん仕事まわしていこうと考えるも、そこで壁にあたってしまうのが、「人不足」。

 

営業力はまだまだあるのに、人手不足で新規の仕事を全て断っている

という話を何人かのBPOに意欲的な税理士法人から聞きましたが、

 

まさにここが本記事におけるメインターゲット

RPAにより大きく飛躍できる士業だと思います。

 

そもそも士業の先生は、ITリテラシーがそれほど高くない。

これは、致し方ないことであって、

文系の最高分野である士(サムライ)業にとって、自身の分野の知識はまさに剣

昔のサムライが商いを忌避したように、分野以外の知識がなくともこれまで成り立ってきたのだと思います。

 

そんな先生たちにAIというと、自分の仕事を奪うかもしれない不穏な奴と思われるかもしれません。

ですが、RPAは違うんです。

 

RPAこそ、先生たちの強い味方。

 

AIと違って何にも考えないですが、真面目に単純作業を淡々とこなしてくれる可愛い奴なんです。

 

 

じゃあ、RPAで何ができるのか?

当社で開発した「クラウドRPA鉄腕経理」の紹介を兼ねて、お教えしましょう。

 

クラウドRPA鉄腕経理」は、記帳代行と振込入力の二つを行います。

(現在、給与計算や請求書発行など他のサービスも開発検討中ですが、

まずはメジャーなこの二つからローンチしました。)

 

記帳代行機能は、RPAが銀行のシステムから通帳データを自動で取得し会計システムへ入力していきます。

また領収書はデータ化(例えばエクセル)された状態から自動でデータを取得し、自動で会計システムへ入力していきます。

 

他、クレジットカードならば信販会社のシステムへ自動で入りデータを抽出し会計ソフトへ入力するなど、

パソコン内で完結する作業はブラウザでもメーラーでもオフィスでも各種システムでも

横断的にロボットが自由自在にデータを入手、入力できるのです。

 

そして、振込入力機能は、この会計システムに入ったデータを

自動的に銀行システムへ振込入力していき、承認の手前まで終えて承認確認をするという機能

 

これらの機能でどれだけ業務削減できるのか?

企業によって入力の量なども変わりますし一概には言えません。

 

ただ、当社の方で税理士法人の中心的なクライアントである13億円程度の中小企業をベースに試算したところ、

だいたい記帳代行が1日程度、振込入力が2日程度の作業量削減となりました。

経理担当者が3日程度楽になる試算ですね。

 

これが多いか少ないか、一企業にとってはたったの3日?となるかもしれません。

しかし、BPO100とか300社とかやっている会計法人にとっては、100社×3人日、

300社×3人日です。その業務削減効果は小さくはありません

 

またコスト削減効果以上に、このタイミングで業務を標準化し、

RPAによって自動化することの将来的な意味は計り知れません。

新規の業務を何の憂いもなく営業できるトップの安心は、

成長を目指す意欲的な税理士さんにとって最も大切なことでしょう。

 

当社では、この「クラウドRPA鉄腕経理導入費無料で税理士法人へ導入してもらっています。

実は、このRPA、導入が一番大変なんです。

導入の際の各種データの標準化、各社ごとの設定が一番の手間となり、

導入するのに数百万円の投資が必要という事も多くあります。何事も良い事ばかりではないですね。

 

しかし、当社では月々の一社当たりの御社アウトソーシング料の中から、

いくばくかを毎月の払っていただくだけで、初期投資ゼロ円のRPA導入を実現しました。

 

 

 

これからのテクノロジー社会、士業にとっての良質なテクノロジーパートナーでありたいと願って。

 

 

 

topへ
© RPA.biz