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

【経理×RPA】交通費精算をRPA化する具体的な方法を考えた

2018.07.17

交通費の計上は、どのように取り組んでいますか?

 

RPA」という言葉を聞いて、どのようなことをイメージしますか?

 

実際に「RPA」に関わっている人は具体的なイメージを持っておられるでしょうが、

初めて「RPA」という言葉を聞く人からすれば、

 

「また新しい言葉が出てきたけど、もてはやすだけもてはやして、今回もきっとそのうち消えていくのだろう」

 

と思っている人がいるかもしれません。

 

確かに「RPA」という言葉自体はこなれていないイメージがありますが、

その実態は、今後の仕事の現場においてかなり浸透していく可能性を秘めています

 

 

例えば、交通費を計上する場面を想定してみましょう。

 

「交通費」は、大企業や中堅企業だけでなく、中小企業をはじめ、個人商店や個人事業主でも、仕事をしている限り、ほぼ確実に発生する「経費」です。

つまり、ほとんどの人が関わっているとても身近な「経費」と言えます。

 

交通費の代表例として「通勤手当」が考えられますが、ここでは「通勤手当」以外の交通費を考えていきます。

月末(または翌月初)に交通費伝票を提出するルールを導入している企業を想定しています。

 

それでは、営業部の社員の立場と、経理部の社員の立場にわけて、それぞれのホンネを探っていきましょう。

 

 

営業部の社員のホンネ

商談先へ向かう途中、どのような話をするか、どのようなことを聞かれ、どのように答えるかを考えることで精いっぱいで、

とても交通費のことまで考える余裕はないかもしれません。

 

また、取引先からクレームが入り、「すぐに来い!」と言われた場合、

取引先までの交通費の計算を考えている余裕があるでしょうか

 

なぜクレームになったのかを反省し、どのようにお詫びするか、

どこまで会社として対応できるかを事前に確認しておくことに集中せざるを得ないのではないでしょうか。

 

 

さらには、新規開拓することが仕事の営業社員の場合はどうでしょうか。

上司から「回る件数が少ない!数字が上がらないのは、動いていないからだ!もっと数を増やして回れ!」とプレッシャーをかけられていた場合、

果たして交通費のことを考えながら営業候補先を一日に何件も移動することができるでしょうか。

 

 

このように、営業の仕事に取り組んでいると、なかなか交通費のことまで頭が回らないのが正直なところではないかと思います。

でも、月末になると交通費を申請しなければならないとしたら、果たして正確に移動区間の交通費を申請することができるでしょうか。

 

 

もちろん、移動区間を毎日しっかりメモに残し、正確に交通費を申請する社員がいるかもしれませんが、

「こんな感じじゃないかな?」という内容で申請せざるを得ない社員も中にはいるかもしれません。

 

新幹線をはじめとする長距離の移動や、タクシー代等を除き、

交通費は領収証の添付を求められることはないでしょうから、「自己申告」をすることになります。

 

そのため、どうしても正確な申請をすることが難しくなってきます。

 

また、「月末のこの忙しい時期に、なぜいちいち交通費伝票を書かなきゃいけないのか!」と思うこともあるでしょう。

そうなると、ますます正確な交通費の計上は難しくなっていきます。

 

 

経理部の社員のホンネ

経理部で働いていると、会社が動かしている「お金」を正確に計上していく必要があります。

 

億単位の手形決済をはじめ、すべての「お金」は正確な数字しかなく、出金・入金のどちらにおいても、

金額に誤差が生じた場合は、その原因を追究していく作業が待っています。

 

 

出金や入金をはじめとした内容を一つずつ把握し、それぞれの動きを仕訳して正確な経費計上、売上計上、

原価計上等をしていくわけですが、一円でも金額が一致しなければ、その原因を探っていかなければなりません。

 

どうしても誤差の原因が把握できず、誤差の金額が少額である場合は「使途不明金」として「仮払金」や「仮受金」として計上せざるを得ないこともあるでしょう。

 

でも、「使途不明金」が積み重なっていくと、どうしても管理が甘くなっていくことから、

その都度全力で原因究明を求められるのが経理部の社員としての立場ではないでしょうか。

 

そのような緊張感で仕事をしているとき、月末(あるいは翌月初)に営業部をはじめとする各社員の「交通費伝票」が回ってきます。

 

交通費伝票を1枚ずつチェックし、計算は合っているか、区間と申請金額に大きな誤りはないかなどを見ていきますが、

中には正確性が疑われるものも混じっているかもしれません。

上司の印鑑やサインがない伝票があるかもしれません。

 

その場合は、その社員にその旨指摘し、伝票の再提出を要請せざるを得ないのですが、

「今は忙しいから、上司のサインはそっち(経理部)でもらっておいてよ」

と言い返されることもあるのではないでしょうか。

 

 

経理部としては、普段から正確性を要求される業務に取り組んでいるにもかかわらず、「交通費」だけは少し色合いが異なります

 

全体の経費のうち、交通費の占める割合が軽微であれば、上司の印鑑やサインがあれば「有効」とみなし、

そのまま計上せざるを得ないのが現状かもしれません。

 

さらには、せっかく社員一人ひとりに交通費の申請をしてもらっているにもかかわらず、

最終的には会社としてのその月の交通費、あるいは部署ごとのその月の交通費の合計金額を把握することに追われ、

社員一人ひとりがどのような動きをしてきたのかということまでは把握する余裕がないのも事実ではないかと思われます。

 

 

RPA」を導入することで…

交通費計上において、このような事態に陥っている会社に、「RPA」を導入することを想定してみましょう。

 

まずは、営業部の立場から考えてみます。

 

いろいろな取引先を回る際、「いちいち交通費を計算している暇はない」というホンネを取り上げ、

RPA」で問題解決を図っていきます。

 

例えば、「交通費専用メールアドレス」を設け、移動するごとにスマートフォンで「出発駅」と「到着駅」を入力し、

「交通費専用メールアドレス」に送信すればよいこととします。

 

営業部の社員とすれば、いちいち交通費を計算する手間も省けるし、月末にその月の移動区間をまとめて思い出す必要もなくなります

 

営業部の上司としても、担当する営業社員の交通費伝票が一人1枚ずつ回ってくるわけではなく、

「交通費専用メールアドレス」に送信され、「RPA」が自動集計した社員ごとの交通費一覧表が経理部から回ってくるので、チェックする作業が簡略化されます。

 

また、一覧表を確認することで、社員一人ひとりがその月にどのような移動をしていたのか、

誰が多く移動し、誰があまり移動していなかったのかなどをチェックしやすくなります。

 

次に、経理部の立場から考えてみましょう。

 

社員一人ひとりが「交通費専用メールアドレス」に移動のたびにメール送信し、

「RPA」が自動集計していきますので、他の経費と同じように、より正確な金額を把握していくことが可能となっていきます。

 

また、社員一人ひとりの交通費伝票をチェックする手間からも解放され、部署ごとの上司にその月の交通費一覧表を提出し、

まとめて1枚にサインしてもらえれば済みますから、作業自体がかなり簡略化されます。

 

さらには、それまでは「全体の交通費」の金額を把握するために社員一人ひとりに交通費伝票を提出してもらっていたわけですが、

RPA」を通して社員ごとの移動区間が比較検討しやすくなりますので、

 

「今月は、〇〇さんが一番動いていたのだな」といったことや、

「〇〇さん、だんだん移動が少なくなってきているけど、大丈夫かな?

もし、疲れていたり、やる気をなくしていたりしたらいけないから、

早めに上司に報告しておいたほうがよいかもしれないな」

 

といったことが見えてきます。

 

 

このように、「RPA」を通して交通費計上の数値を、社員ごと、月ごとなどで比較検討することが可能となり、

そのデータをもとに考える余裕が出てきます

 

RPA」という言葉自体はあまり馴染みがないかもしれませんが、

その実態は社会のインフラのような存在になる可能性を秘めています

 

 

今回は「交通費計上」について「RPA」の導入を考えてみましたが、

何か新しいことを始めなければ「RPA」と関わりを持つことができない、というものではありません。

 

今、目の前にある課題を解決できる可能性を秘めていることから、誰にでもお馴染みな存在になり得るのが「RPA」なのです。

 

 

 

地方自治体におけるRPA活用導入のポイント (3/3)

2018.07.13

本コラムでは、前回内容から続いて、自治体へRPAを導入する時の注意点、要諦について述べていきます。

今回が一連のシリーズの最後になりますが、前回のコラムを参照したい方は以下をご覧ください。

 

地方自治体におけるRPA活用導入のポイント (2/3)

 

前回、前々回のコラムでは、自治体におけるRPA導入のポイントとして、

「RPAを入れる前に業務フローを変えよ」

「手書き申請からの脱却≒入力時点での電子化を図るべし」という点について述べさせていただきました。

 

 

いずれもRPAを導入する前の下準備の大切さを訴えた内容です。

通常のBPRの視点やタブレットなどのITツールを含めて、よりRPAの効果が増大するための土台を整えておくことが重要です。

 

 

今回のコラムでは、いよいよRPAを導入する段階になった時の話になります。

 

RPAプログラミングの細かいテクニックは別コラムに譲るとして、

ここではRPA開発をする上でのシステム設計やメンテナンスを含めた人員体制といった「仕組み作り」に特に焦点を当てています。

 

もちろん、これだけがRPA導入の成功の鍵であるわけではありませんが、

特に自治体で取り組む際の重要ポイントとして詳述していきたいと思います。

 

 

  1. メンテナンスのしやすさを考慮した人員体制・システム設計を

 

 

自治体にRPAを導入する際の重要論点として、メンテナンスのしやすさを考慮した人員体制およびシステム設計の重要性について言及したいと思います。

 

こちらについては、RPAの開発・メンテナンスを誰が行うかによって変わってきます。

 

RPAはそもそもの由来として、大規模システム開発案件の対象となりにくい日々の細々とした定型業務にスポットをあてたツールであり、

思想としてユーザーサイドで自主的に開発・メンテナンスが行えるようなUIを謳っています。

 

ただその割には多少のプログラミング知識が求められるため、

いきなりゼロから自社職員で開発を遂行するのが難しく、最初の期間はベンダーに依頼するケースが多いのが実情です。

 

こと主要都市圏以外の地方自治体におけるRPA導入に目を向けると、

開発・メンテナンスの人員体制およびシステム設計の方向性は下記2つのいずれかの方針にすることを推奨します。

 

これは、現在RPAを手掛けられるベンダーが主に首都圏をはじめとした主要都市に未だ限定されているため、

追加開発や改修のたびにその地方自治体にベンダーを呼び寄せることが中々困難である事に起因します。

 

参考: 自治体RPAにおける人員体制・システム設計

 

 

 

 

(1)自治体内職員で最終的に開発・メンテナンスできるようにもっていく

自治体の場合、セキュリティーポリシーの関係上、

RPAロボットをローカルPC端末もしくはオンプレミスの庁舎内サーバーに置かなければならない場合、

誰がエラー時に改修対応するのか」という点が非常に重要になります。

 

前述しましたとおり、現在RPAに熟練したベンダーは都市部に存在することが多く、

それらの企業を頻繁に呼び寄せることは現実的ではありません

 

仮にできたとしても、ベンダーのエンジニアが訪問するまでに日数がかかり改修のリードタイムが長引くことになります。

 

そのようなロボット配置≒システム体制の場合、簡易的な改修や追加開発は職員自らの手でできるようになることが最善の策となります。

 

こちらの方針では、最初の開発についてはベンダーのサポートを受けながら行いますが、

その期間中、一部のITリテラシーのある職員を特命大使としてRPA研修を積ませ、

最終的には自社リソースで追加開発や改修作業ができるようにもっていく事を狙います。

 

この場合、ベンダーに対して、RPA開発だけでなくトレーニングを含めた契約を予めしておくことが肝要となります。

 

 

それでもやはり、自庁舎職員でメンテナンスをしていくのに不安を感じる自治体もあると思います。

 

その場合は、ベンダーとの契約で予め、自治体地域在住のエンジニアを育成しメンテナンス業務にあたらせることを盛り込んでおくことをお勧めします。

 

首都圏などにいるベンダーとしては、個別自治体に自社エンジニア、特にRPAエンジニアを最初から抱えてはいないはずです。

 

よって最初の段階は既存エンジニアに出張させ常駐させますが、それと同時に地域内で採用活動をし、

開発後のメンテナンス人材を準備しておくことを自治体側としても意識して契約仕様を設計するのです。

 

自庁舎職員でRPA人材候補を見つける自信のない自治体にとっては検討の価値のある施策だと考えられます。

 

 

(2)ベンダーが改修できやすいところにロボットを配置し、ベンダーに開発・メンテナンスを委託する

先ほど、自治体においてはロボットを庁舎内に配置することが求められるケースがある、と述べましたが、

全ての自治体がそうであるとは限りません。

 

セールスフォースのPAASが自治体内でも存在感を示している通り、

最近では自治体側としてもクラウドサービスの利用にオープンなところも少なくありません

 

その場合、民間企業のRPA事例では実際にあることですが、

ベンダーが管理できる場所(AWS等クラウドのケースが多い)にロボットを配置し作業させることができます。

 

遠隔のクラウド上にあるロボットに自治体庁舎内にあるPCやサーバー内システムにアクセスさせる方法は幾つかありますが、

庁舎内にあるローカルPCを遠隔操作する場合はリモートデスクトップの技術が使われます。

(但し、リモートデスクトップについては既存の庁舎ネッワークによって可否が変わるため事前の検証が必要です)

 

 

上記のようなシステム体制ができれば、例えベンダーがその自治体近辺の会社でなくても、

比較的容易にメンテンスをすることが可能になります。

 

実際には、細かい設定などは現場PC上での動作等を参照する必要があるのですが、

少なくとも最小限のコストでメンテナンスを賄うことができ、

地方自治体にとっても都市圏にいるRPA熟達ベンダーに自分たちのRPA活用を任せられるという安心感を得ることができます。

 

 

今回、自治体におけるRPA開発・メンテナンスの人員体制・システム設計について方策案を提示させていただきましたが、

何もこれらが唯一解ではなく、自治体の状況によって他のパターンがありえます。

 

ただ、ここで言いたいのは、

「開発後のメンテナンスについて何の方針もなく、徒に導入を進めてしまうのは非常に危険」

ということです。

 

「一度RPAを作ったら、メンテナンスなど要らないのではないか」という意見をお持ちの方もいるかもしれませんが、

これは断言できます、多くのRPAプログラムには恒常的なメンテナンスが必須となります。

 

それは、RPAというものが、もともと既存のシステムやOS、アプリなどの「橋渡し役」として使われることが多く、

故にそれらの外的要因に強く依存してしまうからです。

 

例えば、既存の庁舎内システムの改変があれば、もちろんそこにアクセスするRPAロボットも改修が必要になり、

またインターネットサイトの構成が変われば、その情報を扱うロボットは修正を求められます。

 

従って、RPA導入を決めるのと同時に「メンテナンスをどうするか」というのはセットで考えるべきものなのです。

 

 

このコラムでは、特に地方自治体においてRPAを導入する上で気を付けるべき点を挙げさせていただきました。

 

自治体のRPA普及は正に始まったばかりで、今後ますます浸透していくことが予想されます。

 

もともと自治体業務はRPAと非常に相性が良く、

自治体職員の負荷低減およびそこで産まれた余剰時間をより重要な対市民へのサービスに回すための理想的なソリューションとも言えます。

 

今後ますます発展する自治体RPA化ですが、本コラムで書いたような要点を抑えることで、成功の確度を少しでも上げる事ができれば幸甚です。

 

 

 

地方自治体におけるRPA活用導入のポイント (2/3)

2018.07.12

本コラムでは、前回コラムの内容から引き続き、自治体におけるRPA導入のポイント、最大限の効果を狙うための要諦について述べていきたいと思います。

前回のコラムを参照したい方は以下をご覧ください。

 

地方自治体におけるRPA活用導入のポイント (1/3)

 

前回のコラムでは、自治体におけるどのような業務がRPAの対象となりうるのか、「窓口業務」「内部管理業務」に分けて列挙し、

また、RPA導入におけるポイントの一つとして「RPAを入れる前に業務フローを変えよ」ということを述べさせていただきました。

 

 

一見、RPA導入となると、「現行の業務フローをそのままにロボットに移管できる」という妄想に囚われがちになりますが、

ロボットと人間、それは勿論、特性が違います。

 

その人間とは異なるRPAロボットなるものの性向、得意分野に合わせて人間側が業務フローを再設計する工夫が求められます。

 

もちろん、業務フローを変えずともRPAの導入は原理上可能ではありますが、

その場合、効率化の果実、つまり人間側で生まれるはずの余剰時間が限定的になってしまい、

人間にとってもロボットにとってもハッピーな結果とはなるとは言えません。

 

現行の業務フローを変えることは確かにリスクです。

ただ、その苦しみを乗り越えないと、RPAの果実は萎んでしまう、

それは厳然たる事実であり、自治体側においてもその覚悟をもってRPA導入を図るべきだと考えます。

 

 

では、今回のコラムでは、それ以外の点で、特に自治体にRPA導入する際に気を付けるべき点を述べていきます。

 

 

  1. 手書き申請からの脱却≒入力時点での電子化を図るべし

 

 

自治体業務では、市民、法人などの様々な所から、多種多様な申請を受けることになります。

これらの「申請書」について、現状は手書きで書かれることが多く、職員の方々がその申請書を読み取って、システム等に登録していきます。

 

その業務をRPAロボットにさせようとする場合、OCRの技術、つまり画像として文字を電子上のテキスト情報に変換する技術が必要になってきます。

 

実際に、金融業界が先鞭をつけた、日本におけるこのRPA化のトレンドにおいても、

まずは消費者からの契約書関連の入力業務がOCRの導入とセットで取り上げられることが多かったものです。

 

 

ただ、ここで注意が必要です。現行の技術ではOCRの精度は100%ではなく、必ず職員による目視チェック業務が発生します。

 

確かに、このOCRの技術は日進月歩であり、AI技術と合わさることによって手書き文字の認識率も随分と向上しました。

しかし、それでも認識率は100%では無いために、必然、人間による目視確認チェック工程が入ります。

 

また、OCRと申請書等帳票の相性にもよるのですが、精度を上げるためにチューニング作業であったり、

学習データの蓄積といった作業が必要になるケースもあります。

 

その場合、OCR精度を上げるためにかかる労力が甚大になるため、

例えば扱う帳票種類が膨大な数となった場合、リードタイム非常に長くなってしまいます

 

 

従って、これは何もRPAに限ったことではないですが、省力化・自動化の取り組みをするのであれば、

入力時点で電子化させるのが何よりも一番効率的になりますし、手っ取り早いです。

 

具体的には、タブレット等の端末を用意してそちらに市民の方に入力してもらう施策が考えられます。

 

中には押印が必要なものもあると思いますが、

それはテキスト入力後印刷してその上に押すことで済ましたり、タブレット上での署名で代替するなど解消方法はいくらでも考えられます。

 

もちろん、中にはタブレット端末の操作に不慣れなご高齢の方もいるでしょう。

そのような場合は、特別対応として、職人が代替して入力してあげればよいのです。

 

ただ、この特別対応が蔓延すると、職員の負荷増大になり本末転倒になりますので、基本的には自力で入力するように促すことが求められます。

 

 

この申請・帳票類のペーパーレス化は、民間企業でもトレンドとなっています。

 

分かりやすい例で言えば、来訪者の受付記入業務のペーパーレス化です。

 

近年、ACALLに代表されるような商談や入管管理の電子化ソリューションが普及していますが、

そこでは今まで来訪者が紙に社名、名前、商談対象者などの情報を記入して受付に提出していたのが、

タブレット上で入力できるようになりました。

 

リンク:商談プロセスの自動化ソリューションACALL

 

参考: ACALL 受付アプリの画面(出所: https://www.acall.jp/features/reception/

 

 

 

この機能により、来訪者はタブレット上から面会対象者を探して選択し、かつ電子上で自社や自身の情報入力を済ますことになります。

 

この来訪者受付のペーパーレス化によって、(今まで受付の社員が行っていた)来訪者情報の入力作業が全て自動で電子化されることになり、

人間による紙からの手打ち業務の削減に繋がっています。

 

同様の受付業務ペーパーレス化は防衛省等の官公庁でも取り入れられています

 

 

ここで取り上げた事例はあくまで来訪者の受付業務の話ですが、

同様の思想は自治体の申請書・帳票受付業務にも敷衍できるものであると考えられます。

 

タブレットやアプリの初期費用がかかることになりますが、それにより、OCRの導入コストが抑えられます。

また、最初の市民の方々からの入力時点で電子情報となっているので、RPAでのシステム登録も正確にでき、

職員によるチェック工数の削減に繋がり、より大きな効率化効果が望めることになります。

 

 

実際に、現在様々な自治体でこの窓口業務におけるペーパーレス化・タブレット活用が取り組まれています。

会津若松市等、まず手始めとして行っている自治体で多いのが、

住民票の写し、印鑑登録証明書、戸籍事項証明書におけるタブレット申請の取り組みです。

マイナンバーカードや住基カードを用いて申請ができます。

 

 

参考: 会津若松市におけるタッチパネル受付サービス

https://www.city.aizuwakamatsu.fukushima.jp/docs/2014022700037/

 

 

特にマイナンバーカードは、20173月時点で、交付枚数は1,000万枚を超え、国としては更なる利活用を進めています。

その一つの方策として、自治体窓口における証明書交付等の入力負荷低減として、マイナンバーカードの活用に着目しています。

この会津若松市の事例も、まさにそのトレンドに沿った施策と言えます。

 

 

ただ、住民票写しなどの申請省力化は、特に新規性のあるものではなく、

一部の自治体では既に専用機械を導入、印鑑登録カード等を活用して同様の仕組みは実現していました。

 

そこで近年では更に、出生・転入・転出・転居・結婚・離婚・死亡といった際の届出・申請にまで踏み込んだ取り組みも出てきました。

 

例えば、DNPが2017年5月にプレスリリースした情報では、

出生・転入・転出・転居・結婚・離婚・死亡といったライフイベントにおける届出・申請に対応するプロトタイプシステムの開発を発表しています。

 

マイナンバーカードをから、氏名・住所・性別・生年月日の基本4情報を取り出し、

届出・申請書に入力、その内容を自治体の基幹システムと連携させることもできることを目指しています。

 

参考: DNPによる自治体への申請手続き支援システム

http://www.dnp.co.jp/news/10135590_2482.html?from=rss

 

 

このような取り組みがもっと進展すれば、多種多様に存在する自治体の紙による届出・申請は、

ペーパーレス、つまり電子入力に切り替わっていくことが予想されます。

 

もともと自治体の届出・申請書は紙による手続きが残っている分野ではあり、今までの慣習を変えるのは大変骨の折れることではあります。

しかし、よくよく考えれば紙への書き込み作業は、市民にとって負荷でありますし、

そして何よりも窓口職員にとっても多くの市民に接しサービス提供する機会を棄損することにもつながります。

 

そこで、RPA導入を検討されている自治体におきましては、

この機会に「紙からの脱却」も併せて検討することでRPA効果の最大化を狙うことをお勧めします。

 

 

次回コラムでは、自治体におけるRPA導入について、最後の重要なポイントを述べていきたいと思います。乞うご期待ください。

 

地方自治体におけるRPA活用導入のポイント (3/3)

 

 

 

地方自治体におけるRPA活用導入のポイント (1/3)

2018.07.11

 

本コラムでは、2017年頃から活発化し、

まさに近年大きなトレンドとして勃興している自治体向けRPAの導入Tipsについて述べていきたいと思います。

 

実際の地方自治体の導入事例については以前書いたコラムをご参照ください。

そちらではつくば市や京都府といった先進的な自治体における取り組み事例について報道資料を基に考察しています。

 

地方自治体におけるRPA活用事例

 

 

今回のコラムは、その自治体において具体的にどのような業務が対象になっているのか、

またRPA導入する際にどのような点に特に注意すべきかをまとめていきたいと思います。

 

そもそも確かにこの自治体業務というものは定型作業の宝庫であり、潜在的にRPA化できる余地は非常に大きいのが特徴です。

 

ただ、一般の民間企業のRPA導入と違って使用しているシステムがクラウド型ではなくオンプレのシステム

さらには旧型のスクラッチ開発した独自システムも現存していることも多いです。

 

また、内部事務処理のバックオフィス業務だけでなく、フロントの窓口業務での活用も求められ、

即時対応できる、フロントの人間とリアルタイムで協業できるようなロボットの設計が必要です。

 

 

地方自治体におけるRPA対象業務

まず、具体的にどのような業務が自治体においてRPA対象になるのでしょうか。

そのためには、自治体の業務を大きく「窓口業務」「内部管理業務」に分ける必要があります。

 

 

窓口業務:

窓口業務は、市役所等庁舎に訪れた市民に対して行うサービスです。

 

近年では住民票や戸籍謄本などの証明書発行業務は機械による自動化がなされていますが、

各種の届け出等についてはまだ人間の事務員が対応しています。

 

 

一部の例にとどまりますが、具体的な業務を挙げますと以下があります。

  • ライフイベント関連
    • 住民異動届
    • こども/その他児童手当
    • 戸籍届
    • 印鑑登録
    • 住民基本台帳カード手続き
    • 転入手続き
    • 婚姻届
    • 死亡手続き/埋葬・火葬許可
  • 税金・年金関連
    • 国民健康保険手続き
    • 国民年金手続き
    • 地方税の各種届出手続き
  • 福祉関連
    • 身体障害者手続き
    • 予防接種関連手続き
    • 介護保険/高齢福祉/後期高齢医療制度手続き
  • 公共サービス関連
    • スポーツ施設の受付・管理事務
    • 図書館運営業務
    • 各種催事・イベント業務

 

 

特徴としては、実際に市民の方に相対しての業務となっており、自動化するにしても即時対応が求められることです。

 

RPAがよく活用される民間事例に例えると、コールセンターでの導入に近いかもしれません。

 

ロボットが定刻にバッチ処理のように起動するようなやり方は、通常フローを遵守するのであればここではできません

 

 

内部管理業務:

次に、内部管理業務について述べます。市民の方と接する窓口業務とは別に、自治体業務には事務所内で行われる様々な定型業務が存在します。

 

こちらについては各自治体個別の業務ももちろん多く存在するのですが、

一般的に多くの自治体で行っているもので特にRPAに向いている定型業務を挙げると以下になります。

 

 

  • 会計業務
    • 会計審査・出納業務
    • 物品管理
  • 契約関連業務
    • 入札参加資格審査申請に関する業務
    • 契約事務手続き、調達先登録業務
  • 総務・経理業務(職員に対する業務)
    • 職員給与
    • 旅費・経費精算
    • 保険手続き
    • 職員研修
  • 情報管理
    • 情報端末管理
    • 統計業務(データ整理・活用に係る資料作成業務等)
    • 自治体HPの運営、更新
  • 教育関連業務(小学校など自治体の教育機関に関する業務)
  • 観光関連業務
  • その他自治体サービス
    • ふるさと納税事務処理
    • 催事・自治体施設に関する事務処理

 

 

ここで取り上げた業務は、自治体に存在する事務処理の一部でしかありませんが、

自治体では、法人、市民問わず多くから各種申請を受けています。

 

その入力作業であったり、審査、そして契約手続き等、多岐に渡った定型業務が存在します。

また、調達関係は特定の課で事務処理をまとめていますが、補助金関係になると各担当部署に事務作業が分散する傾向にあります。

 

 

地方自治体においてRPAを導入する際の重要検討項目

 

それでは、実際に地方自治体にRPAを導入するに際して、どのような点を特に考慮する必要があるでしょうか。

これらの点は正直、自治体特有のものだけではなく、民間企業でRPA導入する際にも言える事も含まれています。

 

ただ、やはり、今までのコンサルティングの経験上、自治体でのプロジェクトでこれらの点は特に顕著に言えるのではないかと考えられます。

 

 

  1. RPAを入れる前に業務フローを変えよ

 

まず初めにこれは声を大きくして訴えたいところですが、

RPAを導入する前に、BPRに多くの労力をかけたほうが断然、効果が高まります

 

ここでは例として、先ほど説明した「窓口業務」についての事例を紹介していこうと思います。

 

一般的に、窓口業務は、市民の方からの申請受付をしたあと職員がそのままシステム入力をして、

その入力結果を終えて、市民に各種証明書等の交付するフローを取ります。

 

この場合、申請書の種類によっては交付が必要ないものもあります。

また、窓口対応終了後、事後に事務所内で再チェックをするケースも多いです。

凡そのフローをまとめると以下になります;

 

 

<窓口業務の一般的な業務フロー>

  • 窓口受付
  • 内容確認
  • システム登録
  • システム登録内容確認
  • 証明書等の交付(申請の種類によっては交付がない場合も有り)
  • 会計
  • 申請書再チェック

 

 

一般的に、自治体の窓口業務では、この窓口受付から証明書等の交付までを毎件一連の業務として行います。

 

このような「一件ごとに一連の流れで最後まで行う業務」というのは、実はRPAに差ほど適した領域ではありません。

本質的に、RPAが一番業務効率化の貢献ができるのは、複数件を定刻にまとめて処理する「バッチ処理系」になります。

 

もちろん、上記のような「一件ごとに一連の流れで最後まで行う業務」でもRPAを導入することはできます。

ただ、この場合、RPAによる業務効率化効果が限定的になってしまう恐れがあります。

 

 

ロボットをシステム上のどこに置くのかにも影響を受けますが、一件ごとに職員とロボットがシームレスに連携して流れ作業を行う場合、

理想となるのはローカルの職員が扱っているPCの中にロボットを入れる形態です。

 

ただ、ここで問題が生じます。

そのロボットが動作している最中、職員はそのPCを操作することができず

結果、その職員は他の活動ができず実質待機の状態になります

 

これでは、ロボットにより生まれた余剰時間を有効活用できているとは言えません。

 

もちろん、ロボットによる1件の作業自体が、職員が行うより高速であれば、

例えその間職員は待機であったとしても処理時間の短縮は図れます。

 

これはコールセンターの例になりますが、コールセンターのオペレーターは、

電話をしたきた顧客の情報の精査、与信の計算など複数のシステムに即時にアクセスして情報処理をする必要があります。

 

この「複数システムを使用する」手間を省くためにRPAでコンソールを作り、

ロボットが自動で複数システムにアクセスして結果を返す事例があります。

 

その場合、確かに、人間のオペレーターが作業するよりも時間の短縮が望まれ

結果、1オペレーターあたりの処理速度・件数の増加の効果があります

 

ただ、このような接客中に複数システムにアクセスしなければいけないような事例は果たして自治体の窓口業務でどれほどあるでしょうか。

 

 

そこで、自治体でRPAの導入効果を最大にしたいと思うならば、業務フローの再設計、つまりBPRの取り組みが事前に必要となります。

 

要諦となるポイントは、ロボットが最も効率的に動けるように、「複数件まとめて一気に片付ける(≒バッチ処理)」様な業務フローに再設計することです。

 

証明書の交付をその場でしないといけない業務については、システム登録を1件1件個別に済ます必要があるかもしれませんが、

そうではなく、申請の受付だけでその場は完結する、もしくは完了の通知は後日でも良い業務についてはシステム登録業務を後日にまとめてしまい、

RPAによるバッチ処理(手書き申請書であればOCRの技術も必要ですが)にしてしまう方策が考えられます。

 

交付が必要な申請についても、本当に即日、その場での交付が必要なのか、後日郵送でもいいのかは真剣に検討する必要があります。

内容確認の必要については、後日の電話・メールで処理することもできます

 

実際に民間の契約関連ではそのようなケースも多いのが事実であり、

自治体としても「何か何でも窓口受付のその場で完了まで済ます」というポリシーを見直す必要があるのではないでしょうか。

 

 

自治体におけるRPA導入ポイント1:業務フローの改善(BPR)

 

 

 

 

次回コラムでは、更に自治体におけるRPA導入する上でのポイント・コツについて言及していきます。乞うご期待ください。

 

次の記事:

地方自治体におけるRPA活用導入のポイント (2/3)

 

 

 

RPAの運用・管理のために担当者が意識しておくこと

2018.07.10

RPAによる業務の効率化は、ここ数年で飛躍的に普及しています。

今後もますます拡大していくことでしょう。

自社でもRPAを導入して業務の効率化を図ろう、と考えている方も多いと思います。

 

ですが、急速な拡大は大きなリスクも孕んでいるのが世の常であり、

RPAによる業務効率化も同様にリスクを伴っている、と私は考えています。

 

特に、RPAのロボットの管理・運用において社内での統制が取れていないと、せっかく業務の効率化のために作成されたシステムが有効に活用されず、宝の持ち腐れとなる可能性があります。

 


 システムの開発を外部に委託できればいいかもしれませんが、運用を外部に丸投げできる会社はごく一部でしょう。

それらの会社を除けば、RPAの基本的な管理・運用は先ず自社の現場担当者が担うこととなることがほとんどです。

 

 現場担当者になることで一から覚えようと前向きに考える人もいれば、面倒な業務が増えたと面倒に感じる人もいるでしょう。

 

担当者がどう思うかは人それぞれですが、確実に言えるのは、導入を決定した人、

あるいは現場担当者がRPAの構造を知らないと、導入は失敗に終わることとでしょう。

 

そうならないためにも、RPAに関する知識を身に着ける必要があると考えています。

 

以前、他の記事でも、RPAを導入したものの、管理体制の不備における、RPAの「野生化」として警鐘を鳴らしている記事がございました。

 

 

■参考記事

生保や銀行で急速に普及する事務作業「ロボット」 保守怠ると“野生化”の恐れもhttp://www.itmedia.co.jp/business/articles/1807/03/news023.html

 

 

この記事を拝見し、以前勤めていた会社のことを思い出しました。

 

以前の会社で事務処理の合間に現状の業務をマクロ・VBAを用いて業務効率化を進めてきましたが、

ほとんど個人で使用する為の開発しかしていませんでした。

 

他の社員が行っている業務の効率化のために開発したこともありますが、改修・管理はこちらで行っていました。

 

 

全員のPCMicrosoft Office(Excel)が入っていたにも関わらず、実際にマクロやVBAを使って業務の効率化を考えていた人はわずかでした。

私個人としても、開発する時のルール等は特に考えずに作成しており、管理・運用のドキュメントも作成していませんでした。

 

 

ですが、転職先が決まって後任に業務を引き継ぐとなった時に、今まで作成したVBAの成果物も引き継ぐこととなりました。

マクロどころかExcelの関数も満足に扱えない人へ引き継ぐこととなりましたが、

とりあえず最低限の仕様変更の仕方を伝えることしかできませんでした。

 

 

後任者も、開発に関する知識がなかったこともあり、「ソースコードを見ただけで眩暈がする」と嘆いていました。

とりあえず体裁上は引き継ぎを完了としましたが、そのような形での引継ぎであったため、

もしかしたら、今はシステムが有効活用されておらず作業効率の低下を招いている業務があるかもしれません。

 

せっかく作成したシステムを管理・運用を怠って過去の遺産とさせないために、

現場等で適切に管理・運用する能力があれば、社内のシステムを最大限活用できるわけです。

 

 

新たにRPAの導入を考えている方だけでなく、今後プログラミングやシステム開発といった、

ITに携わりたいという方への心得として、システムの管理・運用に必要なことを取りまとめました

 

すでにご存じの方には、自身の行動と照らし合わせて振り返ってみてもいいでしょう。

特に、丸ごとアウトソーシングするのが困難で、

システム開発を個人で行うことが多い中小企業の現場システム担当者の方は知っておいた方が良いと思います。

 

 

・ルールを設けて運用する

 大規模プロジェクト等、複数名で開発する場合であれば必ず行っていることですが、

もし、一人で開発、運用する場合でも、必ずルールを決めて開発を進めてください。

 

自分なりのローカルルールでも構いません。

 

 

ルールを決めずに開発した場合、開発した当初は自分で把握していても、時間が経って改めてソースコードを見た時に、

そのソースコードが自分でも何をするためのプロジェクトかわからなくなってしまい、

最悪の場合一から作り直しになってしまいます。

 

 

これを防ぐために、個人で開発する時でも必ず自分なりのルールに基づいて開発をするようにしていきましょう。

もしルールを忘れてしまうようであれば、別途資料を作成しておくことも重要です。

 

 

・自作のプロジェクトの流れを説明できるようにする

当たり前のことと思いますが、意外とできていない方が多いように思います。

引き継がれたシステムは当時の担当者のルールの色が強くでています。

引き継ぎに関するドキュメントが丁寧に作られていたとしても、読むだけでも多くの時間を取られてしまいます。

 

個人で開発する場合、そのプロジェクトがどのような流れで遷移しているかを考えながら開発します。

その場合は、先ほどの「ルールを設けて運用する」ことが重要ですが、

今後社内の資産として適切に運用していきたいのであれば、どこかで必ず他の人に業務を引き継ぐ必要があります。

 

前任者は引き継ぐ時に、そのシステムがどのような流れを取っているかを説明する義務があります。

これができず、後任者が理解できなければそのシステムが適切に運用される可能性はかなり低くなるでしょう。

 

第三者へ説明するためのおすすめの方法としては、前述の、「ルールを設けて運用する」と合わせて、

開発と同時に第三者へ説明するためのドキュメントも作成してしまえば、

引き継ぎ時だけでなく、改修依頼等があった時も役に立つでしょう。

 

 

・プロジェクトの中身を定期的に見直し、必要に応じて改修する。

 開発が終了したプロジェクトを長期間放置してはいないでしょうか。

大規模なプロジェクトや他社が開発したプロジェクトの見直しは困難ですが、

自社開発した小規模のプロジェクトを見直すことは、非常に重要であると考えています。

 

 

 例えば、開発中に、必要な機能の中の一部がどうしても作成できなかった、あるいは妥協し、最終的に運用の仕方で解決してしまった機能というのがあったとします。

ユーザーが納得してくれれば会社としてはいいですが、エンジニア個人としては、非常に悔いの残る結果となります。

 

ですが、以前開発したプロジェクトのソースコードを改めて読み解くと、以前は妥協して作れなかった機能を実装したり、

煩雑化していたコードを改修して管理・運用しやすくなったというケースは多々あります。

 

 

たまたま、以前開発したVBAの改修の必要があったため、開発したプロジェクトのソースコードを一から見直したことがありました。

そのコードを読み解いていると、当時の自分が複雑な書き方をしていること箇所が多かった、と気づきました。

 

それらを改修することで、より理解し易く、管理しやすいプロジェクトとして回収することができました。

 

 

 特に私の場合、以前自ら作成したソースコードを読んで改修できる個所を発見できると、

「俺も成長したなあ」と日々の成長を感じながら改修作業をしています。

完全に自己満足の領域ですね(笑)

 

 

 上記いろいろと書きましたが、どれもすべて、仕事をするうえで当たり前のことじゃないか。と思う方も多いと思います。

まさにその通りで、システムの管理・運用といっても難しいことはほとんどなく、やり方さえ覚えてしまえば誰でもできるであろう業務なのです。

 

もし、それでもわからないという方がいましたら、まずはプログラミングをやってみることをお勧めします

プログラミング言語は数多くありますが、一番なじみやすい、という理由からVBAをやってみるといいでしょう。

 

業務用PCは一人一台がほぼ当たり前になっています。

また、WindowsPCを使用していれば表計算ソフトはほぼMicrosoft Office Excelでしょう。

 

VBAはMicrosoft Office ExcelPCに入っていれば誰でも学習することができます。

他の言語と違い、わざわざ開発環境を作成する必要はありません。

敷居が低いためか、VBAからプログラミングに興味を持つ方も多いです。

 

VBAをほんの少し学習するだけでも、プログラミングの構造やルールといったことは何となく理解することができます。

 

もし、システム管理の担当者になってしまった、と後ろ向きに考えているようであれば、

これを機に少し勉強してみてはいかがでしょうか。

きっと損はしないと思いますよ。

 

 

失敗事例から学ぶ。RPA導入に失敗しないためには?

2018.07.09

RPAを導入して業務を自動化することで、

「労働時間や業務コストの削減を実現できた」

「定型業務に携わっていた人材を知的生産業務へと振り向けることができた」

など、さまざまな企業でRPA導入の成果がうたわれています。

 

その反面、RPAの導入に失敗する例も数多く存在します。

 

失敗の原因を大きく分けて考えると、

「RPA導入時の問題」「RPA導入後の運用時における問題」という2つの側面があります。

 

そこで今回の記事では、

「RPA導入に失敗する理由」「失敗しないためにはどうすればいいのか?」

という観点からご説明をしていきます。

 

RPA導入時の問題点

 

□スモールスタートが大事

 

RPAを導入しようとする際、いきなり全社で導入しようと考えると失敗する可能性があります。

 

まずは部署や業務を限定した簡易なロボットからスタートしてPoCProof of Concept/概念検証)を行い、RPAの導入効果を確かめながら適用範囲を広げていくことが大事です。

 

RPA導入は、スモールスタートして大きく育てていくことが基本になります。

 

「年間数千時間の業務削減に成功」「定型業務の●割削減を実現」といった大規模な成功事例に目が行きがちですが、

いきなり全社規模で運用をしたわけではなく、やはりスモールスタートで運用を開始し徐々に適用範囲を拡大、

その結果、大きな効果が得られたという事例が大半になります。

 

 

なぜRPAでいきなり全社規模での導入がタブーなのかというと、各部門の業務に対応した導入が必要となるからです。

RPAツール自体は標準的なものですが、使える環境や使い方はそれぞれ異なるわけです。

 

それだけでなく、RPAというテクノロジーが登場し注目されたのはごく最近のこと。

多くの企業にとってもRPA導入は初めての体験となります。

 

 

そのために、システム面だけでなく業務面も含めてすり合わせを行いながらベストプラクティスを見つけ、それを確立していくことが大事です。

 

そのほか、RPAに関わっていく人材を育成するにもある程度は時間がかかります。

RPAの適用範囲はスモールスタートすることが成功の近道というわけです。

 

また、PoCで導入効果が上がっている結果が検証できれば、その事実をもとにして、

経営層に対してRPA導入範囲拡大を促すこともしやすくなります。

 

 

RPAツール選定も大事

 

RPA導入に当たってどのツールを採用するのかも重要なポイントです。

 

RPAベンダーのデモや資料だけでツールの採用を決めてしまうと、

どんな複雑な業務でも簡単にロボットを作成して自動化できてしまうという印象を受けてしまいます。

自社でRPAを導入しようとしている業務の内容や規模によって、向き不向きもあります。

 

 

また、初期導入コストという観点だけでツールを採択した場合、機能により自動化の範囲が中途半端になったり、既存IT環境で動作しきれなかったりといった場合もあります。

 

そうならないためには、初期導入コストだけを見るのではなく、

ランニングコストやツール導入により期待される効果(業務削減効果やコスト削減効果など)をシミュレーションしてツール選択の要素に加えていく必要があります。

 

たいていのツールであれば、12カ月は無料でトライアル利用ができますので、実際にRPAを使う部署で試してみて使い勝手を比較しましょう。

 

 

RPAへの過剰な期待は禁物

 

RPAに対し過剰に期待をし過ぎて失敗へとつながるケースもあります。

 

RPAの成功事例が喧伝されていることで、当然のことながらRPAへの期待値は高くなっていくでしょう。

事実、大半はその期待に応えることができると思いますが、過剰過ぎる期待はいけません。

 

なぜかといえば、RPAは「システム」ではなく、あくまでも「デジタルレイバー(仮想知的労働者)=人材」という位置づけで考えなければいけないからです。

 

導入するだけで業務改善などにつながるシステムとは異なり、RPAはあくまで行っている業務の処理や作業をそのままなぞって自動化する仕組みです。

 

RPAとはシステム環境を変化させるツールなのではなく、「既存システムを使う側」を置き換えるソフトウェアなわけであるため、

RPAのロボットを「同僚」の延長線上として捉えながら、業務を継続的に教えていくことでその真価を発揮するわけです。

 

RPAで業務自体が大きく改善する」という考えで導入を進めると、導入後に「期待外れ」という感想を抱いてしまうわけです。

 

RPAを適用する現場に対して、導入の意義をきちんと伝えられていないことも失敗へとつながります。

 

RPA導入の意義が現場につたわっていないことで、

「ロボットに仕事を奪われる」といった警戒感が生まれ、現場から正しい情報が得られず

RPA適用対象を洗い出しきれずに導入に踏み切る結果となる場合があります。

 

そうなるとRPA導入後の成功は見込めません。RPA利用部門現場への事前教育も必要となるわけです。

 

 

RPA運用時における問題点

 

RPA利用のルールを決める

 

RPAを無事に導入し運用フェーズへと移行したときに「導入に失敗した」となるケースもあります。

 

まず、RPA利用のルールを決めずに運用を行うと導入失敗となりかねません。

ルールを決めずにRPAを導入しツールのマニュアルだけを配布した場合、利用する部門が勝手にロボットを次々と作りかねないからです。

 

そうなると、ロボットが既存システムに対して負荷をかけてしまう可能性もあります。

ルールを整備してから利用部門でのRPA導入をスタートさせることが大事です。

 

それだけでなく、利用部門が勝手に作成したロボットはブラックボックス化し、担当者がいなくなった後はメンテナンスが不可能となる可能性もあります。(=野良ロボット化

属人化をなくすために導入したRPAで新たな属人化が発生してしまうわけです。

 

そうならないためには、ロボットが実行しているプロセスがどのような手順を踏んでいるのか、担当者以外でもわかるようにマニュアルにまとめておく必要があります。

 

 

□人間でないとできない作業には注意

 

定型業務をロボットに移行する際にも注意が必要です。

定型業務のなかには、「電話確認する」「目視で確認を行う」といったパソコンを使用しない人間でないとできない作業もあります。

 

そのため、既存の業務手順やルールを踏襲してそのままRPAを適用した場合、人が介在するところも残る可能性があります。

 

その場合、人間がExcelファイルを加工する作業を自動化するには、

ロボットのオペレーションをひとつなぎにする工夫が必要になってきますが、そこへと至らないケースも存在します。

 

結果として、ロボットによる業務効率向上は不完全に終わる可能性もあります。

 

 

□ある程度の習熟は必要

 

RPAの大半はプログラミングの知識などが不要で、既存のITシステムよりも簡易に使えます。

 

とはいえ、ある程度は使い方を習熟しておくことが必要になります。

そこで、RPAツールの教育・研修方法やマニュアルなどを整備しておくことが求められます。

RPAを教育する担当者の育成も必要になります。

 

また、RPAを適用して自動化した業務でも、一般的なITシステムと同様に運用トラブルは起こる可能性はあります。

そのために、障害対応ルールも必要となります。

 

 

IT専門商社でもRPA導入失敗を犯している!

 

これらのRPA導入失敗例はITに疎い企業に起こるわけではありません。

とあるIT分野の専門商社でも社内業務のロボット化に一度失敗をしています。

 

同社では3カ間のPoC期間中に12業務で自動化をスタート。

30のロボットが稼働することになりました。

 

しかし顕在化してきたのは、会社組織の規律を乱すロボットが出現するリスクでした。

例えば、「出社していない従業員の出退勤記録を残す」といった悪用できるロボットを、勘のいい社員なら15分程度で作れると分かったのです。

 

また、RPAツールの研修を受けても殆ど手を付けない社員も存在することで、

「ほとんどロボット化が進んでいない部署」と「過剰にロボット化している部署」が生まれていました。

ロボット作成後の管理方法もあいまいだったため、担当者が部署異動するだけで混乱をきたす危険性も見えました。

 

そこで初めて、ロボット活用の成否を握るポイントとして、「ルール」に基づく「管理」と、その実行を担う「組織」づくりにあることがわかったといいます。

 

 

おわりに

 

とにかくRPAを導入すれば、「単純作業はすべて自動化へと移行できる」と考えることは幻想でしかありません。

 

RPAはツールでしかありません。

 

ツールがうまく機能していくためには導入手順をきっちり決めなければなりませんし、RPAに対する意識改革から始めなければならないこともあります。

 

RPAは比較的安価に導入できるために、業務プロセスの可視化や標準化を疎かにした安易な導入で失敗してもその失敗が隠されてしまう恐れもあります。

 

ホワイトカラー業務へのIT適用である、RPA導入を成功に導くためには細部への注意も必要といえるわけです。

 

 

RPA業界から見る「DeNA」のRPAの凄さ

2018.07.06

DeNA社は、非金融企業としては、いち早くRPAを導入した企業の1つです。

 

本稿では、DeNA社によるRPA導入をRPA業界からの視点でお届けしたいと思います。

 

 

DeNAとは――なぜDeNAが“RPA”か

株式会社ディー・エヌ・エーは、1999年3月に設立されました。

当初は「ビッダーズ」というオークション&ECサイトを運営していました。

 

ビッダーズは現在「Wowma!」と名を変え、運営会社もDeNAからKDDIへと移管されています。

 

 

その後、オークションサイトである「モバオク」のヒットもあり、

2005年2月にマザーズへ上場を果たしました。

 

 

最も成功した事業は、2006年2月に開始した「モバゲータウン」(その後“Mobage”に改称)でしょう。

 

当時はまだスマートフォンではなく、いわゆる「ガラケー」がほとんどでしたが、

「怪盗ロワイヤル」「農園ホッコリーナ」といったタイトルが大ヒットを記録しました。

 

この恩恵もあり、東証一部上場を果たし、さらには横浜ベイスターズを買収するなど、

M&A等により事業を拡大していきました。

 

ただし、2018年3月期においても、ゲーム事業の売上高が70%以上を占めています。

 

直近で言うと、「ファイナルファンタジーレコードキーパー」「逆転オセロニア」

任天堂との協業タイトルでは「スーパーマリオラン」や「ファイアーエムブレムヒーローズ」、

「どうぶつの森ポケットキャンプ」「マリオカートツアー」といった辺りがヒットしているようです。

 

 

2018年度の経営計画としては、インターネット×AIを大方針として掲げています。

DeNA社がRPAを早くに推進しているのも、うなずけますね。

 

 

“DeNAのRPA”とは

DeNAのRPAは、下記サイトに詳しく述べられています。

 

 

ルーティンワークはロボットに、創造的な仕事は人間に。月128時間の事務作業を減らしたRPA導入の全貌

https://fullswing.dena.com/rpa/

 

 

DeNAでは2017年4月からRPA導入のプロジェクトをスタートし、社員データの登録や稟議申請などを自動化して業務効率化に繋げています。

 

 

2017年4月からRPAプロジェクトをスタートしているとのことで、これはかなり早いタイミングであると言って良いでしょう。

概して、昨年から導入している非金融企業は早いと分類できます。

 

 

DeNA社はRPAツールとしてBlue Prismを使用しているようです。

 

上記サイトのロボット例を見てみると、

「変数・定数をBlockで囲む」「シナリオは上から下へ流れていく」といったBlue Prism開発あるあるは踏襲されていることが確認できます。

 

 

まずは各部署のメンバーに対して、RPAの概要や得意・不得意な業務を説明しました。そのうえで、担当している業務のうちRPAに任せたらうまくいきそうなものをリストアップしてもらったんです。

 

 

ここで特筆すべきは、「業務選定をユーザ部門が行っている」ことでしょう。

 

業務選定は、RPAコンサルタントでも、かなり骨が折れる作業です。

業務を一つ一つ、事細かにやり方をヒアリングし、RPAに適用できるかどうか、費用対効果はどうかなどを分析しなければなりません。

 

 

なお、業務選定のやり方は色々あります。

DeNAでは、ユーザ部門がRPAの特性をある程度つかんだうえで、RPA化できそうな業務のみを挙げています。

 

実務上で多いのは、「すべての対象業務を一覧化し、その中でRPAできそうかどうか一つずつ〇×をつけていく」方法です。

 

 

この情報をもとに、自動化の難易度や削減できる工数などを判断し、RPAを導入するための優先順位を決めていきました

 

 

とありますが、実際には、自動化の難易度や削減工数なども一つの表にまとめることが多いでしょう。

 

 

自分たちの部署の作業で試してみようという方針に沿って、「新入社員のアカウント作成」を自動化しました。作業自体は、「サイボウズ デヂエ8」の入力フォームに貼りつけていくだけです。工数自体はそれほど多くないのですが、例外的な処理がほとんどないため自動化しやすく、RPA導入の手始めとして試すにはちょうど良かったんです。

 

ここでは、非常に大切なポイントが語られています。

削減工数を度外視して、まず動くものを作っています。

 

これは、RPA開発でしばしば用いられる「PoC」(Proof of Concept:概念実証)フェーズであると言えます。

 

「一体全体、RPAってどんなもんなの??」というものの把握に、PoCは大変役立ちます。

 

サイボウズというWebサイト形式のデータベースサービスを利用し、そこのフォームに文字列を入力する――

 

RPAで必要な作業の多くを取り込みつつも、開発自体は単純であるこの業務は、

PoC的立ち位置の業務選定としては、ベストプラクティスと言って良い選択だったと思います。

 

 

判断基準は、1年でロボット開発のコストを回収できるかどうかです。開発には平均で45時間ほどが必要でした。それを12か月で割ると、1か月あたり3時間半程度かかることになります。その時間以上を削減できる工数のタスクを、自動化していったのです。

 

 

RPA化する業務の基準は「3.5時間/月」以上の手間がかかっている業務ということです。

月で3.5時間というと、かなりハードルが低い印象です。

FTE(人月)でいうと、0.021875FTEです。

この程度の数値であれば、複数人での単純作業はもちろん、1人作業でも対象業務は多くありそうです。

 

これは、社内開発での強みと言って良いでしょう。

 

一方で、SIerなどに委託する場合、社内開発よりは開発コストがかかる可能性が高いため、

RPA化対象業務は、0.5FTEくらいの削減効果のある業務であって欲しいというのが本音です。

 

 

クラウドツールの操作を自動化するのには、注意が必要だと思っています。というのも、クラウドツールは定期的に改善されていくのが良い点ですが、画面の仕様が急に変わった場合、ロボットが動かなくなるケースがあるからです。

 

 

これは、RPA開発および保守上で最も懸念すべき事項でしょう。

あるボタンの位置がズレた場合、人であればすぐにズレたボタンを押すことができるでしょうが、

RPAシステムの場合は、ズレたところに照準を合わせてあげる必要があるのです。

 

 

この作業を自動化しようとすると、変換のためのマスタ情報をずっとメンテナンスする必要があり効率が悪い。そのため、kintone側に会計の情報も持たせるような作りに変更しました。

 

 

このように、RPA化に際しては、業務プロセス自体の変更もしばしば発生し得ます。

DeNA社のように柔軟な会社であれば、業務プロセスの変更も可能でしょうが、

長らく同じ業務プロセスでやってきた会社の業務を変更することは容易ではありません。

 

 

経理や人事などバックオフィス系の業務で時間がかかっているものを、今後は自動化していきたいです。

 

 

経理、人事はRPA化業務の宝庫です。

弊社でも当該業務のRPAソリューションを提供していますので、

ぜひともお問い合わせください。

 

まとめ――DeNA案件で真似するべきポイント

 

DeNA案件でぜひとも真似をしていくべきポイントは以下の3点に絞れそうです。

 

  • 業務選定をユーザ部門が行っている
  • PoCを(ユーザ主体で)行っている
  • 業務プロセスをRPAに寄せている

 

これらは、どのRPAシステム開発案件でもつぶしの利きそうなポイントとなります。

ぜひ、DeNA社を見習って素晴らしいRPAシステムを構築していきましょう。

 

 

【RPA×経理】資金繰り表とRPA

2018.07.05

資金繰り表とは

資金繰り表とは、すべての現金預金収入と現金預金支出を分類・集計し、一定の区分、科目に基づき整理された表です。

家計簿と同じく、お金の出入りをあらわします

 

試算表や決算書の損益計算書とは異なり、

実際の現金預金の入金・出金の事実に基づいて作成されるため、

実際の現金預金の入金・出金が把握できます。

 

 

資金繰り表の種類

資金繰り表には、作成期間に応じて、資金繰りの実績をまとめた「資金繰り実績表」

将来の資金繰りの計画をまとめた「資金繰り計画表」があります。

 

また、作成単位に応じて、月々の資金繰りをまとめた「月次資金繰り表」と日々の資金繰りをまとめた「日次資金繰り表」があります。

 

 

資金繰り表の必要性・重要性

(1)収支把握による黒字倒産の防止

 

企業は当期純利益が毎期赤字であっても現金預金が潤沢にあり、資金繰りがうまく行われていれば倒産することは少ないです。

 

一方で、当期純利益が毎期黒字であっても、現金預金が少なく、資金繰りがうまく行われておらず、

債権者(金融機関、仕入先など)への返済・支払が滞ると倒産又は倒産状態となります。

 

このように損益計算書上では黒字の状態でもかかわらず、資金繰りの関係で倒産又は倒産状態になることを黒字倒産といいます。

 

 

黒字倒産を防止するためには、損益計算書による利益管理をはじめ、資金繰り表作成による収支管理が重要です。

 

資金繰り実績表から自社の現金預金の入金・出金のトレンドを把握することに加え、資金繰り計画表で現金預金の入金・出金の時期と額を把握し、

それを管理することによって、現金預金が底をつくという状況を未然に防ぐことができます。

 

 

(2)現金預金の残高管理

資金繰り表による資金繰り管理で最も重要な項目は、月末又は毎日の現金預金残高です。

資金繰り実績表の作成により、自社の通常必要な運転資金が把握できるため、最低限必要な現金預金残高もわかります。

 

その必要最低限の現金預金残高を下回らないように資金繰り表の月末又は毎日の現金預金残高の項目を管理していくことが重要です。

 

 

(3)資金調達タイミングの把握

資金繰り計画表の作成により、設備投資や原材料の支払時期が明確になる為、

それに合わせて資金調達のために金融機関との交渉を計画的に進めることができます

 

 

資金繰り表のフォーム例

下図は、月次の資金繰り実績表と資金繰り計画表のフォーム例です。

 

青い項目の「実績」列が資金繰り実績表で、赤い項目の「計画」列が資金繰り実績表です。

一番右の「期間累計」は実績と計画を合わせた4か月間の合計金額です。

 

 

各項目の記載内容と分析例は以下のとおりです。

 

[売上収入]

現金売上の入金額、売掛金の入金額などの本業の売上入金額を記載します。

 

[雑収入、助成金収入]

本業の売上入金以外の臨時の入金額や助成金の入金額を記載します。

 

[その他経常収入]

普通預金利息入金額やその他金額が過少な入金額を記載します。

 

[経常収入合計]

経常収入の合計です。経常収入には営業活動で生じた収入が記載され、どれだけの現金預金が生み出されたのかを表しています。

家計簿で言うと、給料・賞与の収入などに該当します。

 

[仕入等支出]

現金払いの材料仕入金額、買掛金の支払額などの原価の支払額を記載します。

 

[給与賞与支出]

給与、賞与、社会保険料などの人件費の支払額を記載します。

どこまでを人件費に含めるかは、その会社の特性によって変更します。

給料、賞与は実際に支払った手取り額を記載します。

 

[販管費支出]

現金払いの販売費及び一般管理費、販売費及び一般管理費に係る未払金・未払費用の支払額を記載します。

 

[法人税支出、消費税支出]

法人税と消費税の支払額を記載します。

 

[源泉税・住民税支出]

源泉所得税と個人住民税の支払額を記載します。

 

[その他経常支出]

金額が過少な臨時的な支払額を記載します。

 

[経常支出合計]

経常支出の合計です。経常支出には、営業活動のために必要となる支出が記載され、どれだけの現金預金が消えていくのかを表しています。

家計簿でいうと、賃貸物件の家賃の支払いや水道光熱費の支払い、食費の支払い、保険料の支払いなどが該当します。

 

[経常収支過不足]

経常収入合計から経常支出合計を差し引いた収支差額が記載されます。

経常収支過不足がプラスの場合は、営業活動により現金預金が増加したことになります。

 

経常収支過不足はある一定期間(一年間の事業年度など)で見たときに、プラスである必要があります。

経常収支過不足がマイナスであれば現金預金が社外に流出していることを意味するため、経常収支過不足のマイナス金額が多かったり、

そのマイナスが続くような場合は、事業継続が困難になる場合があります。

 

[経常収支率]

経常収支過不足が0円の場合、経常収支過不足は100%になります。

経常収支率が100%を超えるような資金繰り計画を作成することが重要です。

 

[借入金収入]

金融機関などからの借入金の収入額を記載します。

 

[借入金返済支出]

金融機関などからの借入金の返済額を記載します。

 

[敷金支出]

賃貸物件の保証金・敷金の支払額を記載します。

 

[設備投資支出]

製造用機械の購入、店舗内装工事代金の支払い、営業用車両の購入などの設備投資支払額を記載します。

 

[財務等収支過不足]

財務等収入合計から財務等支出合計を差し引いた収支差額が記載されます。

財務等収支過不足がプラスの場合は、資金調達などの財務等活動により現金預金が増加したことになります。

 

財務等収支過不足はある一定期間(一年間の事業年度など)で見たときに、プラスであることが望まれます。

設備投資支出が予定されている場合は、自己資金(経常収支で生じた現金預金)で設備投資等を行わずに金融機関からの資金調達することにより、

資金繰り悪化を防ぐことができます。

 

手許の現金預金が潤沢にある場合は自己資金で設備投資等を行っても問題ない場合が多いです。

 

[総合収支過不足]

総合収支過不足は、経常収支過不足と財務等収支過不足を加算して算出します。

総合収支過不足は、すべての収入と支出の収支差額が記載されます。

 

総合収支過不足がプラスであれば現金預金が増加したことになります、マイナスであれば現金預金が減少したことになります。

 

[月初現金預金残高]

月初の現金預金残高を記載します。

 

[月末現金預金残高]

月初現金預金残高に総合収支過不足を加算して算出されます。

資金繰り表が間違いなく作成されていれば、月末現金預金残高と実際の現金預金の金額が一致します。

 

資金繰り表の分析例

上記の資金繰り表フォームに沿って、資金繰りの分析例を紹介します。

 

[2018年5月の実績について]

経常収入は18,300千円あったものの、経常支出が24,750千円あったため経常収支は6,450千円のマイナスになりました。

 

また、借入金返済支出が500千円あり、総合収支は6,815千円のマイナスになりました。

 

月初に50,000千円の現金預金がありましたが、6,815千円の現金預金が減少したため5月末現金預金残高は、43,185千円になりました。

 

助成金収入が3,000千円あったものの、A部門及びB部門の売上収入が少なかったことが総合収支がマイナスになった大きな要因です。

 

なぜ売上収入が少ないのかはいくつか仮説を立ててそれを検証していきます。

売掛金の回収漏れがあったのか、前月以前の掛売上高の不振によるものなのか、毎期の季節性のためなのか、などを検証します。

 

[2018年7月の計画について]

経常収入は、A部門の売上収入が多かったこともあり、37,102千円を計上しました。

経常支出は、賞与の支払い5,000千円があったこともあり、30,615千円となりました。

 

経常支出が30,615千円あったものの経常収入がそれを上回る37,102千円あったため経常収支は6,487千円のプラスになりました。

 

7月は15,000千円の設備投資支出が計画されているにも関わらず、借入金収入が7,000千円に留まっているため、

財務等収支は8,500千円のマイナスになっています。

 

財務等収支のマイナスが経常収支のプラスを上回ったため、総合収支は2,013千円のマイナスになりました。

 

設備投資支出15,000千円が計画されているのであれば、金融機関等からの資金調達も同額の15,000千円を調達することで、資金繰りは安定します。

 

資金繰り表を作成することで、金融機関との交渉も早めに行うことができ、資金調達をスムーズに進めることが期待できます

 

 

資金繰り表作成方法

(1)会計ソフトの機能を使用する方法

 

会計ソフトには資金繰り実績表を作成できる機能がついていることが多いです。

しかし、この資金繰り機能を使用している会社をほとんど見たことがありません。

会計ソフトの資金繰り作成機能には以下のような問題点があります。

 

①勘定科目毎の資金収支項目の設定が煩雑

ある会計ソフトでの仕訳と資金繰り表出力結果は以下のとおりです。

 

仕訳:(借方)未払費用給与1,000円/(貸方)普通預金1,000

資金繰り出力項目:人件費支出0円 前払金・未払金支出1,000円

 

資金繰り表の機能としては問題ありませんが、分析するためには不十分な出力結果となっています。

資金繰り表で「人件費支出1,000円」と出力された方が資金繰りの分析をする上で有益になります。

 

このように会計ソフトでは機械的に集計されてしまうため、自社に合わせた必要な情報がうまく設定することができない場合があります。

設定できる場合でも非常に煩雑なことが多いです。

 

②商品・サービス別の資金繰り表が作成できない

損益計算書を作成時には、例えば売上高勘定の補助科目として「A商品売上」や「Bサービス売上」などを設定しているケースは多いと思います。

しかし会計ソフトの資金繰り表では、補助科目の集計・分類ができない場合が多いです。

 

 

(2)会計ソフトの仕訳データを使用し、エクセルで作成する方法

会計ソフトの仕訳データを使用しエクセルで資金繰り実績表を作成する手順は以下のとおりです。

 

①仕訳は総額で入力し、現金預金勘定の相手勘定科目は必ず入力します。

相手勘定を諸口や、空欄にはせず、必ず相手勘定科目を入力します。

 

[一般的な仕訳例]

(借方)長期借入金1,000円/(貸方)普通預金1,025円 〇〇銀行 借入金返済

(借方)支払利息25円 〇〇銀行 借入金利息支払

 

[資金繰り表作成を前提とした仕訳例]

(借方)長期借入金1,000円/(貸方)普通預金1,000円 〇〇銀行 借入金返済

(借方)支払利息25円/(貸方)普通預金25円 〇〇銀行 借入金利息支払

 

②現金預金勘定の元帳をエクセル又はCSVでダウンロードします。

 

③フィルターを設定し相手勘定科目ごとに資金繰り表の区分コードを入力します。資金繰り表の区分コード例は以下のとおりです。

100:売上収入(A商品)

101:売上収入(Bサービス)

200:仕入等支出

201:給与賞与支出

300:借入金収入

400:借入金返済支出

区分コードの100番台は経常収入、200番台は経常支出などとしておくと便利です。

 

④区分コードを入力した後、ピボットテーブルで集計し、集計結果を資金繰り表のフォームに入力します。

 

⑤資金繰り表の月末現金預金残高と実際の現金預金が合っていれば完成です。

 

資金繰り作成とRPA

資金繰り表の作成は、会計ソフトの機能を使用する場合も、エクセルで作成する場合もある程度手間がかかります。

 

エクセルで作成する場合には、自社の業態に合わせた項目の設定や表現が容易にできる一方で、上記作成手順に示したようにデータの取得操作や入力操作などの工程が多くあります。

 

エクセルでの資金繰り表作成にRPAを組み合わせることにより、インターネットバンキングからの入出金情報の取得・仕訳入力・資金繰り表の作成までRPAで行うことが可能です。

 

資金繰り実績表をRPAで作成することにより、業務時間に資金繰り予定表の作成に注力できるため、

会社の資金繰り安定化の実現や、金融機関との上手いつきあい方につながることが期待できます。

 

 

【初心者がつまずきやすい】セレクタとは

2018.07.04

今回はUiPathのセレクタについてお話していこうと思います。

セレクタは少々分かりにくく、理解するのに時間がかかるかもしれません。

 

実際に、筆者はこのセレクタには何回も悩まされています。

ここでしっかりとセレクタについてまとめておいて一緒に理解していきましょう。

 

 

セレクタとは


まずはセレクタとは何なのかについて見ていきます。

論より証拠ということで、実際のセレクタをまずは見ましょう。

 

<wnd app=’explorer.exe’ cls=’Progman’ title=’Program Manager’ />

 

これがセレクタです。

一体なにを言っているのかよくわからない呪文のようなものに見えます。

 

これを今から理解していきましょう。

私のイメージではセレクタとは処理対象がどこにあるのかを指すためのものと認識しています。

実際に、セレクタはUi elementを識別するものでありますからそのように捉えて問題ないと思います。

 

 

Ui element

Ui elementという分からない単語が出て来たので見ていきます。

 

Ui elementとは以下のようなものです。

 

Ui elementはウィンドウ、チェックボックス、テキストフィールド、ドロップダウンリストなど、アプリケーションを構成するすべてのGUI(グラフィカルユーザーインターフェース)のことです。(UiPathガイド参照)

 

みなさんは作業の自動化などを行う際に、ウィンドウを開いたり、チェックボックスをクリックしたり、テキストフィールドに文字を入力したりすることがよくあると思います。

このようなGUIを総称してUi elementと呼びます。

 

このUi elementを操作するのを手助けするのがセレクタなのです。

つまり、GUIなどがどこにあるのかを探すときに、場所を教える手助けをしてくれるのです。

 

 

生成の方法とセレクタの変更について

セレクタは多くの場合はUiPathによって自動で生成されます。

特にユーザーインターフェイスが静的に操作するものならば基本的には自動で生成されるので問題ないように思います。

 

 

「セレクタ変更例1(テーブル)」

先ほどから少し抽象的な話になってきていますので、具体的な例を見ていきましょう。

 

 

A B
身長 140 170
体重 40 60
合計 180 230

 

 

このような表にある合計値を取り出す場合を考えます。

UiPathの Screen Scrapingを使うことで簡単に合計値を取得することができます。

今回はBの合計値をとりだします。

 

この時のセレクタを見てみましょう。

 

<webctrl tableCol=’3′ tableRow=’4’tag=’lbl’/>

 

のように書かれていました。

これは3列、4行目にあるデータを取りだしていますよという意味になります。

 

すこし実験してみましょう。

 

 

A B
身長 140 170
体重 40 60
年齢 14 20
合計 194 250

 

 

先ほどの表に年齢の行を挿入してみました。

このまま先ほどと同じフローを実行してみましょう。

 

すると、合計値ではなくて20という値が取り出されました。

これは20が3列、4行目にあるデータであるからです。

合計値が欲しかったので間違ったデータを取り出してしまいました。

 

ではどのようにすれば変化したデータに対しても、合計値を取り出すことができるようになるのでしょうか。

 

こういう時に便利な機能がUiPathには搭載されています。

UiExplorerというものです。

今までは行と列を固定でスクレイピングしてきましたが、UiExplorerを使って変えていきましょう。

 

tableRowが固定にしてあるはずなのでそこのチェックボックスを外して、rownameの合計にチェックをいれてください。

 

これで行を固定にせずに、rownameの行を探してそこの列をみていくことができるようになりました。

 

「セレクタ変更例2(メモ帳)」

他にも例を見ていきましょう。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’無題 – メモ帳’ />

 

これはメモ帳を開いた時のセレクタです。

titleのところに注目しておいてください。

このあと、このメモ帳を名前を付けて保存し、test.txtとしました。

 

次に、今新しく保存したテキストファイルを開いてみます。

すると、セレクタは次のように変わります。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’test.txt – メモ帳’ />

 

どこが変化したかおわかりでしょうか。

そうです。titleのところが無題⇒text.txtと変わりましたね。

 

ここまでは大丈夫だと思います。

でもメモ帳というものは新しく開いたときは必ず無題で始まります。

 

なので新しく始めた時にはtest.txtを見つけられず、エラーになることがあります

 

 

ワイルドカード

このような状況でに便利なのがワイルドカードと呼ばれるものです。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’*- メモ帳’ />

 

のように書きます。

titlleのところが*に変わっています。

このアスタリスクはどんな文字でも入るということで、ほかの無題以外にもtest.txtであったり、temp.txtであったりと様々なものが入ることができます。

 

これにより、どちらであっても操作可能になりました。

 

このように名前の分からないファイルを探す際に、UiPathには二つのワイルドカードが用意されています。

一つ目は先ほど使った *(アスタリスク)です。

もう一つは ?(はてな)です。

 

これらの違いは明確で、アスタリスクは複数の文字に置き換えられるのに対して

ハテナは一つの文字にしか置き換えることができません。

 

つまり、

title=test.txt

を置き換えたい場合には

title=*

は大丈夫ですが、

title=?

は置き換え不可能です。

もしもハテナを使おうと思うのならば、

title=????????

八個のハテナが必要となります。

 

このワイルドカードの使い道は様々で、先ほども述べた名前の分からないファイルなどを探すのに使用したり、

日付などが入っており名前が永続的に変化していくものにも対応することができます。

また、webの検索バーなどの動的なものに関してもワイルドカードを使用することで対応できると思います。

 

また、このワイルドカードが使われた際に複数の一致するファイルが存在する場合はどのようになるのでしょうか。

 

例えば、

title=*

とセレクタで指定されている場合に

title=test.txtというものと、temp.txtのふたつのファイルが対象の範囲内に存在するとします。

 

その場合は、一番手前にあるもの、今アクティブになっているもののみ実行されます。

つまり、UiPathが一番初めに見つけたもののみに処理を実行するということです。

 

 

セレクタの中身

最後に、セレクタの中身について少しだけ見ていきましょう。

また、メモ帳を例にして見ていきます。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’*- メモ帳’ />

 

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’*- メモ帳’ />

初めのwndはwindowということで要素の種類を示しています。

他にもHTMLやJavaやControlなどがあります。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’*- メモ帳’ />

次のappはアプリケーションの名前が書いてあります。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’*- メモ帳’ />

clsにはクラスの名前が書かれています。

 

<wnd app=’notepad.exe’ cls=’Notepad’ title=’*- メモ帳’ />

titleにはタイトルの名前が書かれています。

 

このすべてが一致しないと、セレクタはエラーとして目的のものを見つけることができません。

 

最後に


UiPathでの自動化をしていく上ではセレクタは切っても切れないものになると思います。

特に、レコードをする際などにエラーが出た場合などは、一度セレクタがあっているかどうかを確認するのもありでしょう。

セレクタは何回もつかっていくことで慣れていくと思うので頻繁に見ていくことをおすすめします。

 

 

 

 

元営業事務員が、RPAのエンジニアになって思ったこと

2018.07.03

こんにちは、Oといいます。

6月よりRPAエンジニアとして、RPAツール「UiPath」を活用したソリューション業務に携わっております。

 

前職では食品の営業事務に携わっており、日々の受注処理を中心に業務に携わっておりました。

 

当コラムでは、実際に営業事務経験のある私が、UiPathについての学習を通じて感じ取ったことを伝えていければと考えています。

 

RPAを学ぼうとしたきっかけ

 

 先ほどもお伝えしたように、私自身、営業事務として業務に携わっていた経験がある中で、日々の業務効率を上げることがに努めてまいりました。

 

その中で、社内の主要なツールがMicrosoftのエクセル・ワードであったため、

マクロ・VBAといったシステムの使い方を覚え、業務に活用することで社内業務の効率化を進めてきました。

 

 

しかし、近年ではwebやクラウドを活用した受注システムの増加・取引先の増加による受注方法の多様化により、

各アプリケーション上での業務効率化しかできないというジレンマを抱えておりました。

 

そんな中、RPAという言葉を知り、業務の効率化に対して、より高い水準で貢献したいという志を持って飛び込んできました。

 

まずはRPAを導入することで何ができるのか、ということを、元営業事務から見てどう感じるか、

また、どのような効率化に結び付けられるかに焦点を当ててお話しできればと思います。

 

 

メリット1:業務の自動化

 

 そもそも、RPAとは「Robotic Process Automation」の略称で、「ソフトウェアによるロボットを用いて業務の効率化を行うための技術」を指します。

その特性から、業務の中で発生する単純作業を自動化することで業務の効率化を図ることができます。

 

 

以前に実際に行った業務ですが、取引先がwebの受発注サービスを使用しており、

そのwebサービス上で請求書のPDFを発行し、取引先にメールで送付する、という業務がございました。

 

その業務を行う際に、どのような作業を行っていたかを以下の通り取りまとめました。

 

 

  1. 請求書を発行するシステムのトップページに飛ぶ
  2. ログインパスワードを打ち込む
  3. メニューから、請求データ発行の画面に行く
  4. 該当月、該当施設等といった請求データ発行に必要な項目を設定する
  5. 発行ボタンを押す
  6. 必要であれば、発行されたデータを加工し、保存する
  7. メールソフトを立ち上げる
  8. 送信先のメールアドレスを入力する
  9. 本文を入力する
  10. 送信ボタンを押す

 

 

一つの業務を行うだけでも、これだけの作業が発生してしまいます。

 

作業に慣れてくればある程度の手間は省くことができますが、

すべての作業を自動で行ってくれるサービス・システムはほぼ存在しません。

 

 しかし、RPAであれば、以上の業務を全てロボットに行わせることができます

その結果、業務時間の短縮につながります

 

 

メリット2:作業ミスが発生しない

 

上記作業を人間が行う必要がある、ということも注意する必要があります。

 

作業する人が普段と違う人の場合、抽出データの範囲を間違えてしまい、違う期間の取引データをダウンロードしてしまうかもしれません。

 

各取引先へのメールとなると、作業者の不注意によって取引先へのメールに違う企業の請求書を添付して送信してしまうかもしれません。

 

これらのエラーは、人間が作業をする以上必ずついて回る問題であり、

作業者は日々注意して作業を行うか、あるいは第三者によるダブルチェックをしてミスを防がなくてはなりません。

 

私は以前、日々の受注処理業務をこなしていましたが、単価チェック等で必ず他者の確認を取る必要がございました。

 

この場合、自分のタスクが終わっても確認してもらう第三者の作業の合間か、あるいは作業中であることを承知の上で確認を取る必要がございました。

 

 その為、作業の合間に待ち時間が往々にして存在しており、その度に作業が停止してしまうといったことがございました。

 

RPAの技術を用いれば、ロボットは毎回同じ動きをしてくるので、迅速かつミスなくタスクをこなすことができます

 

 その結果、単純作業を行っている時間を、他の業務のために使うことができ、生産性の向上に繋がります

 

 

メリット3:必要な情報の取得が自動で可能

 

エクセル関数・マクロを活用した処理を考えると、元データとして.csv.txt等のテキストデータがなければ自動化できませんでした。

 

業務で頻繁に使用するPDFのような書類からデータを抜き出す際に

「そのPDFファイルを開き、必要な情報をエクセルに打ち込む」という作業を毎日行っている方もいると思います。

 

この作業も、RPAを活用することで、PDFファイルを読み込み、テキストとして出力することが可能です。

Web上の操作をトレースしてくれるだけでなく、毎月変動する数値も取得することができます

 

これらのことから、RPAは非常に有用なシステムですが、以下のようなデメリットもございます。

 

 

デメリット1:重要な判断を伴う業務への適正が低い

 

RPAの大きな特徴は、業務の自動化ができることです。

素晴らしい技術ですが、実は大きなデメリットにもなっています。

 

例えば、取引先から単価100円の商品が3000個の発注があったとします。

もし単価が10円違う90円で計上されていたらどうなるでしょうか?

 

ベテランの事務員であれば気づくことができ、処理を行う前に各所へ確認してトラブルを未然に防ぐことができるでしょう。

 

もし、同様の処理をロボットが行った場合、単価の間違いに気づかずにそのまま処理を行ってしまいます。

また、発注数量が大きく違っていた場合も、同様に気づかずに処理してしまう可能性がございます。

 

ロボットは定型業務が得意であるが故に、間違った情報が入っていた場合の修正や、判断を必要とされる業務への適正は低いです。

 

もちろん、エラーの定義を決めればある程度の判断は可能となりますが、

微妙な場合の判断・細かな箇所への対応等には適しておりません。

 

また、機能の追加によるシステムの複雑化の原因にもなってしまいます。

 

 

デメリット2:変更・修正が頻繁に発生する業務が苦手

 

RPAの場合、一度設定した業務を自動で行ってくれます。

ですが、もし業務フローが追加・変更となった場合は注意を要します。

 

毎月の業務において月ごとに変更の発生する可能性がある業務をロボットに行わせようとすると、

毎月機能の追加、変更を行う必要がでてきます。

 

そのため、業務フローが定まっていない業務の場合、業務フローを固定化するまでは、人が作業したほうが効率的な場合もあります

定期的な改修も必要となるため、結果的にコスト増になってしまう可能性もあります。

 

 

RPAという新たなテクノロジーの有効活用に向けて

 

これまで、RPAに関するメリットとデメリットを挙げてきました。

現時点では定型業務の効率化が大きな役割となるでしょう。

 

しかし、RPAとは業務効率化のためのテクノロジーであり、今後もアップデート等で対処可能な範囲が拡大していくと考えられています。

 

ただし、決してRPAを導入しなくてはいけない、というわけではないと考えております。

業務の改善といっても様々な手段があります。

 

今回は、業務の改善のためにRPAが最適か、ということを考えるための要素として捉えていただきたいと思います。

 

 

それよりもまず、このようなテクノロジーがあるということを知っている方が一人でも多くなることが重要であると考えています

 

私も、以前の職場では、エクセルやワードの使用が業務の中心であり、

それらを有効活用することで、作業をいかに効率化するか、という考えの中で業務に努めておりました。

 

RPAという単語も、今年に入ってから初めて聞きました。

 

どのようなサービスでも言えることですが、それらのテクノロジーを必要としている業界ほど、

そのようなテクノロジーがあることすら気づいていないことが多いと感じます。

 

必要なテクノロジーを与えることで、会社の生産性が上がり、業務を効率化することができるにも関わらず、

ただ知らないからという理由だけで、多くの企業が現代社会の最先端のテクノロジーの恩恵を得られていないように思えます。

 

生産効率の向上のため、RPAを活用した作業の自動化という選択肢があるということを、頭の片隅にでも覚えておいていただければ良いと思います。

 

 

営業事務として現場の業務に携わった者として、作業時間の短縮は至上命題だと考えています。

 

RPAという技術を、作業効率を高め、生産性を向上させるための一つの手段として考えていただける方が一人でも多くなれば、と願っています。

 

 

量子コンピューターが“RPA”を加速する

2018.07.02

次世代コンピューターである「量子コンピューター」がRPAに与える影響とは何でしょうか?

本ページでは、そのシナジー効果による発展可能性を書いていきたいと思います。

 

 

量子コンピューターとは

従来の古典的なコンピューターは「01010101001101……」のような2進数(ビット)で計算処理されています。

一方、量子コンピューターでは、ビットを組み合わせ、重ね合わせた量子ビットで計算することができます。

 

 

結局のところ、量子コンピューターの登場でどうなるの?というのは、

実運用レベルの量子コンピューター自体がほとんどないため、よく分かっていません。

 

 

ただ、理論的には「劇的な処理能力の向上」が期待できると言われています。

 

文部科学省も、量子コンピューターに対して今後10年間で300億円を投ずると発表しています。

 

文部科学省はスーパーコンピューターをしのぐ「量子コンピューター」を実用化するため、2018年度から10年間に約300億円を投じる方針だ。現在のコンピューターと動作原理が全く異なり、スパコンで1千億年かかる膨大な計算が数時間で済むとされる。優れた計算能力を創薬や新材料開発、人工知能などの分野に生かす。

 

■量子計算機、実用化へ300億円 文科省方針 

https://www.nikkei.com/article/DGXLZO20057110W7A810C1EE8000/

 

 

量子コンピューターで出来ること。変わる未来。

株式投資の前線に身を置いていると、「量子コンピューター関連銘柄」というものが目に入る機会が増えました。

 

 

大企業では量子コンピューターの研究投資をしている富士通<6702>

小型株では量子コンピューターにおける超電導デバイスの信号増幅装置を手掛けるエヌエフ回路設計ブロック<6864>といった辺りがよく物色されます。

 

 

一方、量子コンピューターの恩恵を受ける企業として、医薬品業界が挙げられます。

 

 

これは、創薬において、バーチャル・スクリーニングによるあらゆる「組み合わせ」を計算しなければならないためです。

現在は、従来型の性能の良いコンピューターで行われています。

 

 

参照:創薬とスパコン

http://www.r-ccs.riken.jp/jp/post-k/pi/drugdiscovery

 

 

もし、これが量子コンピューターに置き換わり、劇的に計算処理速度が速くなったら、

難治・不治とされてきたあらゆる病の治る薬の作られる日が来るかもしれません。

 

 

そうなれば、量子コンピューターを先んじて導入した企業の恩恵は大きく

一方で、量子コンピューターの導入が遅れた企業は、むしろ築いて来たシェアを奪われかねません

 

 

ビットコインなどの仮想通貨にも影響?!

量子コンピューターは、世間を賑わせている仮想通貨にも影響を及ぼしそうです。

 

 

仮想通貨は決済等で用いる暗号方式として、公開鍵暗号方式というものを利用していますが、

量子コンピューターの性能により、この暗号方式を突破されてしまう可能性があるのです。

 

 

この突破リスクを軽減するために、仮想通貨に導入されている機構として「ランポート署名」というものがあります。

 

 

■【図解】量子コンピュータ耐性のあるLamport(ランポート)署名とは?導入が検討される4つの仮想通貨を紹介

https://moblock.jp/articles/17845

 

 

NEOSHIELDといった耳慣れない仮想通貨には導入されていますが、

ビットコインには導入されていません。

 

 

仮想通貨はしばしば、決済速度の遅延が問題視されます。

ビットコインなどは、決済に10分程度かかるとも言われています。

現金からの脱却が一つのメリットである割に、現金払いどころか小銭をチャラチャラ探している方が、まだスムーズな速度ですね。

 

 

暗号方式の複雑化と決済速度は比例し、また、決済速度と処理するコンピューターの性能も比例しています。

 

量子コンピューターの処理能力は一説に、従来型コンピューターと比して「1億倍」とも言われ、

加えて消費電力も少ないとも言われています。

 

仮想通貨の価格と電力料金の価格には、損益分岐点があるとされ、

例えばビットコインであれば30万~150万ドルだという説もあります。

 

 

■ビットコイン、「採掘」電気代に見合う価格は30万-150万ドル

https://www.bloomberg.co.jp/news/articles/2017-11-12/OZ754R6TTDSC01

 

 

なんだか、石油の価格と、シェールガスの採掘における損益分岐点が50ドルなので、

石油の価格が上がらないなどと言われる話と似通っているように思えますね。

 

 

コンピューターの性能上昇と暗号のセキュリティ力上昇のどちらが上回るかが、今後の仮想通貨の趨勢を左右しそうです。

 

 

『量子コンピュータが人工知能を加速する』

 

 

人工知能においてはディープラーニング(深層学習)が利用されています。

 

ディープラーニングにはスパコンが不可欠であり、

そのスパコンを凌ぐとも言われる量子コンピューターの登場が、

人工知能の進化を加速させることは論を俟ちません。

 

 

IBMのダリオ・ジル副社長(人工知能・量子コンピューター担当)は、量子物理学の難解な現象を活用した量子コンピューターが、テック業界の最も白熱した領域の1つである人工知能(AI)に大きな影響を与えるかもしれないと語った。

 

 

■量子コンピューターはAIにも有効、IBM副社長が実験結果を披露

http://ascii.jp/elem/000/001/655/1655263/

 

 

量子コンピューターがRPAを加速する

人工知能進化の加速はRPA進化の加速と言っても過言ではありません。

人工知能による処理判断の自動化により、RPAの裾野が大きく広がるためです。

 

これは、RPA Class2、RPA Class3などと呼ばれますが、

詳しくは下記のページをご覧ください。

 

■RPA2.0とは?

RPA2.0とは?

 

 

現在、RPAの技術水準はRPA Class1という、

全く人工知能と結びついていない状態にあります。

 

 

結びつかない大きな原因は、人工知能の技術水準が、実務に搭載するレベルまで昇華できていないことが挙げられるでしょう。

 

 

“RPA・AI”または“RPA・AI-OCR”ともなれば、

RPAロボットがカバーできる業務領域はとてつもなく広がることになるのです。

 

 

現状は、大きく以下の2通りで対応されています。

すなわち、RPAの中のどこかに手作業が入るか、

手作業が必須の部分はRPA化しないか、になります。

 

 

殊に業務のRPA化を妨げるものに「目視確認業務」「紙媒体確認業務」という二大勢力が存在します。

こやつらをどうにか出来る可能性があるのは紛れもなく人工知能なのです。

どちらも解決できるのは“RPA・AI-OCR”になります。

“RPA・AI-OCR”については、以下の記事で詳述しています。

 

 

■AI-OCRの概要とベンダーの動向まとめ

https://rpa-biz.com/?p=1204

 

 

おわりに

量子コンピューターが即、RPAと結びつくことはないにせよ、

量子コンピューターの進化による人工知能の進化、

延いてはRPAの進化というステップが現実的に有り得そうです。

 

 

このように、

今後の量子コンピューターの進化には我々のようなRPA業界も注目しているのです。

 

今後の量子コンピューターの進化に注視したいと思います。

 

 

topへ
© RPA.biz