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

【決定版】ロボット(RPA)設計時に抑えておきたいポイント

2018.07.31

今回の記事では、業務のRPA化を行うための設計書を記載する際にどのような点に気をつければよいかをまとめます。

 

特にRPAのエンジニアではない人がRPAのロボットの設計書を作成する際に理解しておきたいポイントを中心に記載します。

 

そもそもRPAのための設計書ってどんなものなの?と思う方もいるかも知れませんが、

RPAの場合は通常のソフトウェアの開発よりも簡易的な仕様書を利用する場合が多く、

処理フローのようなガチガチのIT設計書を書かない場合もあります。

 

 

当然、プロジェクトによってどのような設計書を作成するかは異なりますが、

実際のプロジェクトで採用されている例としては、引き継ぎ時などに利用される業務マニュアルをベースに、

業務手順書を再作成するといった手段を取っています。

 

この記事内では具体的な設計書の内容については触れませんが、

設計書を書く際のポイントをいくつかの区分に分けて説明していきたいと思います。

 

 

【設計書に最低限記載されているべき内容】

 

そもそも何を書けばいいんだっけ?と、頭を捻らせてしまう方もいらっしゃるかもしれませんが、

難しく考える必要はありません。

 

設計書の基本は、人間が対象業務をどのような手順でやっているかをそのまま書き出していくだけです。

 

ただし、ロボットは文脈を理解することはできないので、どのファイルを開くのか、

どの対象画面を操作するのかを明確にする必要があります。

 

例えば、Excelであれば、コピーする範囲はどの列からどの列までで何行目までか

貼り付ける先はどこのセルか、といった点を具体的に設計書に記載する必要があります。

 

 

設計書に書いてある内容の適切な粒度としては、

まったくPCの操作を知らない新人が、その内容を見るだけで該当の業務をだれに質問することもなく業務を完了できる」といったレベルです。

 

すこしハードルを高く感じるかもしれませんが、このレベルまで記載ができていれば、

ロボットを開発するエンジニアに感謝されるでしょう。

 

またこのような形で明確に設計書に記載をすることで、目的が不明な作業や不要なステップに気づくことができるので、

このような面での見直しもついでにできるとなお良いですね。

 

 

【ロボットの起動の仕方について】

 

ロボットは通常のソフトウェアと同じなので、デスクトップのアイコンをダブルクリックするなどで動作を開始することができます。

 

またそれ以外にも自動起動という手段があります。

自動起動の一番メジャーなやり方は、

 

  • Windowsのタスクスケジューラーを設定し、毎日起動時間を指定する。
  • あるいは指定曜日を指定する。

 

が考えられます。

 

この方法はWindowsの基本機能を利用するので比較的柔軟にロボットにいつ動作してもらうかを指定することができます。

 

また基本的には月曜日から金曜日が起動だけれども、祝日は稼働してほしくない、といった場合は、

残念ながら祝日を自動判定する機能はロボットにはないので、

営業日の判定を行うロジックを作成する必要があるため、この判定が必要な旨を設計書に明記する必要があります

(RPAのソフトウェアによっては、サーバー側でロボットを一括監視し、

ロボットをどのタイミングで起動するかを管理する機能を持つものもありますのでご確認ください)

 

こちらは応用編ですが、基本は朝9:00に起動してくれるので良いのだけれど、

特定の曜日やある特定の日だけ(月末)は、朝10:00に開始してほしいんだよね、といった場合は、

以下の方法で対応します。

 

ロボットは9時で自動起動にするが、後続処理を実施するかしないかの判定をさせ、

後続処理を実施しない判断をした場合は一定の時間後にリトライさせるといった方法です。

 

もし事前に一定の法則で起動時間帯をずらしたい日付を決めることができるのであれば、

そのルールをロボットに組み込む必要があるので、これも設計書には記載する必要がでてきます。

 

事前に起動時間をずらす条件を決めることができないのであれば、特定のファイルの存在有無を確認させたのち、

特定のファイルの中身を読み込ませて、後続処理を実施するかどうかを判定させるといった設計方法が考えられます。

 

 

【初期処理と終了処理】

 

ロボットの設計書を書くにあたって、大事だけれども忘れがちな2つの概念、初期処理と終了処理について記載します。

 

システムを開発された経験がある方であればイメージがつくかもしれませんが、

ロボットが起動した最初にやる処理と、ロボットが終了したときに実施する処理のことを指します。

 

この初期処理と終了処理は、RPAの場合は、データベース接続を閉じる、メモリを開放するといったシステム開発の観点とは異なります

 

RPAでは、人間の処理の内容をロボットが変わりに代行するという機能なので、

画面に他のアプリケーションが表示されていたり、不要な画面が一番手前に来ていたりする場合に、

動作が意図通りに完了しないというリスクがあります。

 

このリスクを抑えるために必要なのが初期処理と終了処理で実施するプロセスの削除や開いているアプリケーションをクローズする処理です。

 

特にロボットをPC上で動作させて、そのパソコンを人間がほとんど触ることがない場合、

この初期処理・終了処理がきちんと設計できていないとしょっちゅう業務処理を失敗してしまうロボットになってしまいます。

 

そのため、設計時には今一度、このロボットが操作する可能性のあるソフトウェアはなにか、

それらを終了させる・画面を閉じる記載があるかを再確認してください。

 

 

【リトライできる設計】

 

将来的にはロボットも人間のように状況に応じた判断を自ら業務を遂行していくようになるのかもしれませんが、

現状のロボットは、人間が業務をするのと異なり、

なにか予期せぬエラーが発生してしまった場合に、動作できなくなってしまいます

 

この予期せぬエラーが発生した場合に役立つ概念がリトライ(再実行)です。

 

ただし、再実行するように設計書に記載するのは簡単ですが、再実行を記載する際には気をつけるポイントがあります。

気をつける最大のポイントは、その動作をそのまま再実行しても問題がないか、という点です。

 

ロボットを作成するソフトウェアの種類によっては、特定のステップのみを複数回実施するだけでなく、

特定のステップのまとまりを再実行する範囲として定めることができます。

 

 

例えば、

Step1. Excelを開く。

Step2. シート1の内容を全選択しコピー。

Step3. シート2に貼り付ける。

Step4. シート1の特定の条件を満たすデータを削除。

という処理だった場合に、Step 1のExcelを開くのみを再実行させる、という指定の仕方もあれば、

1-4を一つのまとまりとして考え、1-4のいずれかが失敗した場合に、

1.Excelを開くからやり直しさせるといったことが指定可能です。

 

筆者の経験したプロジェクトでは多くの場合すべてのステップにリトライ処理を入れるのは時間がかかるため、

1-4を一つのまとまりとして、そのまとまりの中で失敗したらリトライをするという設計になっています。

 

では、上記のようなプロセスの1-4をそのままリトライさせることの問題は何でしょうか

Step1のExcelを開くのに失敗した場合であればそのままリトライ処理しても、後続処理に影響がでることはありませんが、

Step4の特定の条件を満たすデータを削除の途中で予期せぬエラー(EXCELが固まってしまう・突然の強制終了等)により失敗した場合はどうなるでしょうか。

 

この場合、途中までデータが削除されているので、Step1からリトライしてしまうと、

Step2でコピーする内容とStep3でシート2に貼り付ける内容が意図した内容にはなりません

 

また同様に、もしStep2で予期せぬエラーによりリトライがかかってしまっても、

既にStep1でExcelを開いているため、Excelの2重起動になってしまいます。

(場合により、読み取り専用で開きますか?といったポップアップが表示され、

そのポップアップを認識できずにロボットが止まってしまいます。)

 

つまり、上記のようなトラブルを起こさないためにも、

「その動作をそのまま再実行しても問題がないか」という点を考慮した設計にする必要があります。

 

 

この場合、1-4の手順に以下のような工夫を加えることで、そのまま再実行しても問題ない設計にすることが可能です。

 

Step1.もしExcelが開いていれば終了する。

Step2.操作対象のExcelをコピーして別のフォルダに移動する。

Step3.別のフォルダに移動したExcelを開く。

Step4.シート1の内容を全選択しコピー。

Step 5.シート2に貼り付ける。

Step 6.シート1の特定の条件を満たすデータを削除。

Step7.コピーしたファイルを元のフォルダに戻して上書きする。

 

このように変更することで、1-7のどこのStepで失敗しても、1からやり直せば何度でも同じ結果になることがわかります

 

もしリトライの処理を設計に組み込む際には上記のような点を考慮してください。

 

 

おわりに

今回の記事はいかがでしたでしょうか。

できるだけ実践的な内容をお伝えできるようにかなり細かい内容になってはいますが、

実際にRPAの設計書を書く際にご参考になれば幸いです。

 

 

 

【WordPress】RPA_bizの記事をTwitterに自動投稿

2018.07.30

 

 

 

WordPressでRPA_bizの記事を書くにあたって、その書いた記事をFacebookやTwitterといったソーシャルメディアに上げる場合、

毎回毎回自分で記事を投稿するのはとても面倒なことです。

 

そのようなときにWordPressのRPA_bizの記事をそのままソーシャルメディアに自動的に投稿するということができれば、

とても簡単で楽になると思いました。

 

ですので、今回はWordPressの記事をTwitterに投稿するのを自動的にできるかどうかを見ていきます。

 

 

プラグイン

WordPressにはプラグインと呼ばれる拡張機能が存在します。

プラグインについて公式ではこのように説明されています。

 

 

プラグインは、WordPressの機能を拡張するためのツールです。

WordPress のコアは、柔軟性を保つため、不必要なコードでふくれあがってしまわないように設計されています。

ユーザーそれぞれが特定のニーズに合ったプラグインを利用して、カスタム機能を取り入れられるように作られています。

 

 

つまり、ユーザーが必要な拡張機能のようなものを自分自身でカスタマイズできるといったことです。

 

また、プラグインは自身で開発することが可能でその際はこちらにプラグイン開発のリファレンスなどが載っていますので、

ご確認しながら開発をおこなってください。

 

今回は、Twitter投稿の自動化についてのプラグインはすでに含まれているものを使用するので、

開発についてはまた後ほどご覧になってください。

 

プラグインの実態について少し分かったところで、実際のプラグインを見ていきましょう。

 

 

Twitter投稿自動化を可能にするプラグイン

実際にTwitterへの投稿の自動化についてのプラグインは多くはないですが、複数存在します。

 

これらにはそれぞれ特徴があって、場合によって使うべきプラグインが違うように思います。

それらについてゆっくり見ていきましょう。

Twitterへの投稿の自動化についてのプラグインには

WP to Twitter

NextScripts: Social Networks Auto-Poster

Jetpack

 

主にこのようなプラグインが存在します。

これらの中からどれを使うべきかどうかを知るためにも、個々のプラグインの特徴について見ていきます。

 

<WP to Twitter>

 

 

個人的には、このプラグインの記事が他のプラグインよりも多かった印象を受けました。

ですので、何かわからないことが出てきた時にとても調べやすい状態にあるので始めやすいと思います。

 

ではまずメリットから説明していきます。

 

  • 多くの記事が存在し、調べやすい
  • 新規作成時や更新時に自動でTwitterへ投稿することができる
  • WordPressのタグをそのままTwitterのハッシュタグにすることができる
  • 編集時にもTwitterへ投稿できる
  • URLの短縮設定をすることができる
  • カスタムの投稿タイプにも対応している

 

URLの短縮化とは、日本語が入ったURLのリンク切れをなくすことが可能であるのと、

短縮することで見やすくなり、ツイッターの文字制限に引っかからなくなりやすいというメリットが存在しています。

 

多くの利点がありますが、決定的なデメリットがあります。

 

  • アイキャッチ画像などをそのままサムネイルとして投稿することができない

 

このデメリットは結構痛い人が多いのではないでしょうか。

画像(サムネイル)を一緒に載せることで、クリック数は大きく跳ね上がると言われています。

ですので、サムネイルは現在とても重要な要素の一つになっているのです。

 

しかし、そこまで大規模に運用するつもりのない人にとっては、

サムネイルは手動で作成したりすることで対処することができるのではないでしょうか。

 

これより、大規模で運用しない人にはとても使いやすいプラグインになっていると思います。

 

<NextScripts: Social Networks Auto-Poster>

 

 

このプラグインも比較的多くの日本語の記事が存在しました。

頭文字をとって”SNAP”と呼ばれていることもあるようです。

 

また、メリットから見ていきます。

 

  • アイキャッチ画像などをそのままサムネイルとして投稿することができる
  • 過去の記事をランダムに投稿することができる
  • 新規作成時や更新時に自動でTwitterへ投稿することができる
  • 連携できるSNSの種類が豊富
  • 記事ごとに細かく設定を変えられる

 

細かい設定が可能であることと、アイキャッチ画像をそのままサムネイルにできることは

ここプラグインのとても魅力的な要素の一つです。

 

しかし残念ながら、デメリットもあります。

 

  • 電話番号認証済みのTwitterアカウントを持っている必要がある。
  • FacebookがSSL(https)化されたサイトでないと連動できない(次に紹介するJetpackでは解決されています)
  • 細かい設定が可能な分、初期設定が大変

 

二つ目の初期設定の大変さはほかのどのプラグインよりもとびぬけているように見えました。

とても難しいことをしているわけではないのですが、とにかく設定に時間がかかってしまうのが欠点です。

 

しかし、細かく設定できる分大型の自動化を行う企業のような場合では

とても大きい威力を発揮するのではないでしょうか。

 

<Jetpack>

 

 

またメリットから見ていきます

 

  • FacebookがSSL(https)化されたサイトでも連動することができる
  • アイキャッチ画像などをそのままサムネイルとして投稿することができる
  • view数などの統計データがとれる
  • 共有ボタンの作成が可能

 

このプラグインはWordPress公式のプラグインとなっていてます。

パブリサイズ共有機能というものを使って、Twitterの投稿の自動化をすることができます。

このプラグインは、サムネイルの画像を自動で載せてくれるのでとても便利です。

 

他同様にデメリットもあります

 

  • プラグインのアップデートが頻繁に行われる

 

アップデートされるということは機能が強化されたり不具合が改善されたりと良いことなのですが、

他のプラグインとの相性などによっては不具合が発生する可能性もあるので注意が必要です。

 

今回、RPA_bizの記事をTwitterに自動投稿するのに、このJetpackを使用します。

理由としましては、設定が極端に複雑ではなくサムネイルを自動で上げてくれることです。

 

 

投稿の自動化

では、具体的にRPA_bizの記事の自動投稿までやっていきたいと思います。

 

Jetpackのインストール

まずは、インストールを行います。

 

1.左のウィンドウからプラグイン>新規追加 をクリックします

 

 

2.キーワードに「Jetpack」と入力して、「今すぐインストール」をクリック

 

 

3.「Jetpackを設定」をクリック

 

 

 

インストールが終わったら次は有効化を行います。

 

4.「有効化」をクリックします

 

 

5.WordPressのURLを「Site Address」に入力します

 

 

6.(WordPress.comのアカウントをお持ちでない方は)メールアドレス・ユーザー名・パスワードを設定します

 

 

7.設定は終了です

 

 

最後に、Twitterのアカウントを連携させます

 

8. Jetpack>設定>共有 から「ソーシャルメディアアカウントを接続する」をクリックします

 

 

9.連携>連携アプリを認証>連携 の順でクリックします

 

 

 

10.無事にアカウントと連携することが出来ました。

 

 

終わりに

これでRPA_bizに投稿すると自動でTwitterにも投稿することができました。

インストールからの流れはそのまま従えばいいので簡単だったと思います。

 

しかしこれ以降に、約30種類の拡張機能を使い分けをしないと

重くて遅くなることがあるので注意が必要です。

 

 

 

 

【経理×RPA】出金伝票、入金伝票を自動集計するRPAを考えた

2018.07.27

どのような企業であっても欠かすことのできない重要な業務の一つが、「資金管理」です。

 

「黒字倒産」という言葉があるように、どんなに業績好調の企業であっても、資金繰りには常に神経を尖らせていることでしょう。

 

資金繰りがスムーズに流れていくよう管理するためには、出金の金額とタイミング、入金の金額とタイミングを、

できるだけ早く、できるだけ正確に、できるだけ漏れなく、情報収集する必要があります。

 

 

資金管理は、大企業であっても中小企業であっても、非常に重要な業務であることに変わりはありませんが、

ここでは「財務部」という独立した部署が存在しない中小企業を想定して考えていきましょう。

 

 

そのような場合、一般的には「経理部」の担当者が、日々の経理業務に追われつつ、資金管理にも対応していくことになります。

 

また、中小企業の場合、社長と一部の役員のみで企画開発や営業の業務に対応していることがあるかもしれませんが、

ここでは「事業部」として複数名の社員がいる企業を前提としています。

 

 

「事業部」の社員の悩み

自社の商品やサービスを売り込むためには、さまざまな資料づくりに励まなければなりませんし、

より良い取引先を選定して部品等を仕入れていく必要があります。

 

取引先と進めているプロジェクトは、機密事項が多く、外部だけでなく、

社内でも関係者以外には情報漏洩しないように神経をすり減らしているかもしれません。

 

 

プロジェクトの対応を進めていく過程で、原価や経費の支払いが発生します。

その際、取引先から受け取った請求書の原本を経理部へ提出するだけで終わればそれほど煩わしくはないのですが、

請求書1枚ごとに「支払依頼伝票」を記入し、上司の印鑑やサインをもらった上で経理部へ提出しなければならないため、

これが意外と面倒な作業になっているのではないでしょうか。

 

 

「事業部」の社員からすれば、「支払依頼伝票」の作成にどれだけ時間を割いても、売上金額や取扱金額が増えるわけではありませんから、

できることならこのような社内業務は極力簡単に済ませたいものでしょう。

 

その上で、契約獲得のために時間を有効活用していきたいのではないでしょうか。

あるいは、取引先からいろいろな要望があれば、すぐにでもその対応に取り掛かりたいと思っているかもしれません。

 

 

逆に、ご契約をいただき、売上計上する場合はどうでしょうか。

「やっと契約までたどり着いたぞ!」と喜んでいると、上司からすぐに指摘されます。

「入金伝票を回しておいて」と。

 

「入金伝票」(あるいは「売上伝票」)を事業部から経理部へ提出することで、

経理部が請求書を発行し、角印を押した請求書原本を今度はこちらから顧客先へ持っていく必要があります。

 

 

事業部の社員からすれば、「出金伝票」にしろ「入金伝票」にしろ、それらは社内向けの業務ですから、

「こんな作業は、経理部のほうで対応してもらえないかなあ?」と思っているかもしれません。

 

あるいは、「できることなら、もっと簡単にしてほしい」と願っていても、

経理部もかなり少ない人数で対応していることから、なかなかそのことを相談する機会がないかもしれません。

 

 

「経理部」の社員の悩み

「経理部」では、日々発生する資金の出金や入金を1件ずつチェックし、経理ソフトに入力していきます。

ときには、内容不明の入金があるかもしれません。

 

その場合は、まずは該当しそうな社員に聞いていきます。

 

社内で原因が特定できれば、その時点で追加仕訳や修正仕訳を行い、経理ソフト上の現金・預金の残高と、

実際の現金・預金の残高を一致させます。

 

でも、社内では原因を特定することができなければ、やむを得ず取引先の担当者に聞かなければならなくなります

「申し訳ございませんが、この入金は、どのような内容のものでしたか?」と。

 

逆に、取引先から振込み手続きの催促を受けることがあるかもしれません。

 

急に取引先の担当者から経理部へ連絡が入り、

「昨日が期日の請求書を発行しておりましたが、まだ入金が確認できません。どうなっていますか?」と質問されます。

穏やかに催促されることもあれば、厳しく指摘されることもあるでしょう。

 

 

このような場合、経理部のミスであれば、速やかに振込み手続きを行い、

次から同じようなミスをしないように反省しなければなりませんが、

むしろ経理部に過失がない場合のほうがこのあとの対応が大変です。

 

日々の業務をいったん脇に置いて、速やかに社内で原因究明に取り掛からなければなりません。

ようやくある社員が請求書の提出を忘れていたことが判明したとき、

経理部担当者としては、まずは上司に至急振込みすべき内容であることの裏付けをとった上で、

取引先にお詫びの電話をしなければなりません。

 

「すみませんでした。こちらの手違いで、まだ振込みができていませんでした。明日中に、必ず振り込みます」と。

 

内心は「私は何も悪くないのだけどなあ」と思っていたとしても、会社としてのミスですからやむを得ません。

 

それでも、取引先から催促されることのほうがよい場合もあります。

手形決済日に万一資金ショートしていたら…

想像するだけでも背筋が寒くなってきます。

 

 

RPAを導入してみましょう!

このような企業の場合、どこに問題があるのでしょうか。

「慢性的な人手不足」と言えるかもしれませんが、仮に社員を増やしたとしても、

作業の流れが今までと変わらなければ根本的な問題解決には至らないかもしれません。

 

つまり、今までのやり方に慣れてしまっているため、社内業務の改革が後回しになっていることが問題と言えるのかもしれません。

 

多少作業効率が悪くても、大きな問題になり得ない社内業務であれば、むしろ「改革」などしないほうがよいこともあるでしょう。

 

でも、「資金管理」は失敗が許されませんので、

失敗するリスクを極力なくしていく工夫が一刻も速く求められているのではないでしょうか。

 

 

そこで、出金伝票(支払依頼伝票)、入金伝票(売上伝票)を自動集計するRPAを提案したいと思います。

 

「事業部」の社員からすれば、「内向き」なこれらの伝票作成業務は、できるだけ簡単なものであってほしいと願っています。

 

また、「経理部」の社員からすれば、これらの伝票が速く正確に、しかも漏れなく回収することができることを願っています。

 

 

RPAを導入することで、「事業部」の社員のところで情報を停滞させることがないように、

すぐに「出金」や「入金」を「経理部」へ知らせることができるようにしていきます。

 

具体的には、「出金」専用のメールアドレス、「入金」専用のメールアドレスを設置し、

それぞれに請求書や契約書等の画像を添付した上でメール送信することが考えられます。

 

あるいは、「メールの送受信」という行為にリスクがあると判断すれば、

クラウド上に「出金」専用ファイル、「入金」専用ファイルを立ち上げ、

「金額、期日、取引先、内容」をすぐに入力できるようにすることも考えられるでしょう。

 

出金と入金の情報はトップシークレットなものですから、

絶対に外部へ漏れることがないように細心の注意を払っていく必要があります。

 

 

これらの入力情報をRPAが自動集計することで、

「いつ、どれだけの金額を出金しなければならないか、入金されてくるか」をより早く、より正確に管理することが可能となります。

 

もちろん、これらの集計情報は権限のある一部社員のみが見ることができるように設定する必要がありますので、

一部社員の負担とならないよう、RPAでできることは極力RPAに委ねていくことが重要です。

 

 

また、取引先から事業部の担当者に渡された請求書原本は、経理部へ持っていくだけでよいこととします。

 

クラウド上に入力された情報をもとに、自動で「支払依頼伝票」が作成できるようにしておけば、

経理部としては「請求書原本が提出された伝票と、まだ提出されていない伝票」というように管理しやすくなります。

 

その上で、急ぎの案件でなければ、例えば一週間に一度、

事業部の上司にまとめて経理担当者から「支払依頼伝票」を提出し、上司にサインしてもらうことも可能となるでしょう。

 

 

「資金管理」のポイントは、いかに速く、いかに正確に、いかに漏れなく、

出金と入金の情報収集を行うことができるかどうかにあります。

 

これはまさに、RPAが得意とする分野です。

 

資金管理は失敗が許されない分、より多くの企業で導入する価値のある業務と言えるのではないでしょうか。

 

 

 

【徹底解説】BizRobo!(BasicRobo)&SynchRoidとは?

2018.07.26

BizRobo!は国内のRPAのパイオニア企業であるRPAテクノロジーズが展開しているRPAサービスで、

2008年よりサービス提供を開始しており現在国内で最も運用実績のあるRPAサービスです。

 

そしてSynchRoidはソフトバンクが2017年より提供しているRPAサービスで、

手厚いサポート体制で近年ユーザ数を急激に増やしています。

 

SynchRoidはRPAテクノロジーズと提携したOEMの形で販売しているので、実際使用しているRPAツールはどちらも一緒です。

 

本日はユーザ数の多いこちら2つのサービスで使用されているRPAツールについて徹底解説していきます。

 

ツールの概要

 

BizRobo!はRPAツールの名前だと思われている方が多いと思いますが、

BizRobo!はあくまでサポート体制なども含めたRPAテクノロジーズのサービスブランド名でRPAツール名はBasicRoboとなっています。

 

またRPAテクノロジーズがRPAツールを自社開発しているわけではなく、

米Kofaxが開発したKofax Kapowを日本向けにローカライズした製品が「BasicRobo」です。

 

また、Kofaxの日本法人からライセンスを購入することも可能で日本では三菱UFJ銀行がそれにあたります。

便宜上、以下から呼称を「BasicRobo」に統一して説明していきます。

 

BasicRoboの強み

・開発環境がほぼ無制限に使える

BasicRoboはDesignStudio(以下DS)という開発ツールがあり1ライセンスあたり10端末までの同時稼働が可能です。

 

しかしこれはあくまで同時稼働の場合の制限であり、

同時稼働でなければ全社員の端末にインストールして全員がRPA開発を行えるようにするといったことも可能になります。

 

 

・ユーザーインターフェースを見ながら開発ができる

一般的なRPAツールでは開発フローの中にコマンドをドラックアンドドロップで配置して開発するものが多いですが、

BasicRoboではレコーディングでの開発がデフォルトになっています。

 

開発画面の中に対象となるインターフェースが専用ブラウザから見れるようになっているので、

プログラミングを組むという感覚よりはいつも行っている作業を専用ブラウザの中で行うといった感覚で実装することができるので、

非エンジニアの方にとってはかなり馴染みやすい開発インターフェースとなっています。

 

 

・日本語でサポートできるエンジニアが多い

BasicRoboは国内で最も運用されている歴史のあるRPAツールなので日本語でサポートができるエンジニアが最も多いとされています。

 

RPAツールを比較検討する際に単純なツールのスペックだけでなくこのようなサポート体制の充実度が重要な指標になります。

 

なぜなら、RPAツールの導入した段階ではまだ何も自動化されていない状態なので、

ツールを使ってどれだけ自動化していくかが重要だからです。

 

導入後に自動化を進めていく際に日本語サポートの多さは必ず必要になるはずです。

もちろん英語でのサポートでも構わないのであればUiPathやBluePrismも大差はありません。

 

 

BasicRoboの弱み

・全体的に高額

BasicRoboは初期のトライアルや小規模導入・本格導入や運用に至るまで全体的に高額です。

 

まずトライアル段階ですが、基本的には無料のトライアルプランが用意されていません

 

UiPathが無料のCommunityエディションを提供していたり、

WinActorが多くの企業に無料トライアルを実施しているのと比較するとトライアルが有償というだけでもハードルは高いです。

 

 

ライセンス費用ですが、ソフトバンクのSynchRoidのライトパックがデスクトップ単位で購入することができ、年間90万円となっています。

サーバ型ライセンスの場合は初年度770万円(うち、初期費用50万円)で2年目以降は年間720万円のライセンス料金です。

 

他のエンタープライズ向けのRPAツールでも年間500万円程度のライセンス価格が相場なのでこちらも割高だといえます。

 

サーバー版のライセンスを購入すると開発ツールが10ライセンスと管理機能、サーバーでのプロセス同時実行が可能になります。

 

プロセス同時実行はライセンスによって制限されており、だいたい4プロセスまでが目安になっています。

(実行するプロセスの負荷によって増減します)

 

同時実行の制限はサーバスペックによるものではなくライセンスによって制限されているので、

10~20のロボットを同時実行したい場合はそのぶんのライセンス購入が必要です。

 

 

・デスクトップアプリの開発が難しい

BasicRoboは元々WEBのクローリング用に開発されたツールです。

 

そのためWEBの自動化の際には専用ブラウザで対象インターフェースが確認できるなど非常に開発がしやすくなる機能が豊富です。

 

一方でWEB以外、つまりデスクトップアプリには対応していなかったのですが、

2017年にDevice Automation(以下DA)という機能をリリースしデスクトップアプリの自動化にも対応しました。

 

しかしこのDAのインターフェースがDSと違い開発の方法も異なるので、

開発者は全く別のツールを一から覚えなおす必要があります。

 

また、機能としてもできたばかりなので他のツールと比較するとデスクトップアプリの開発にはあまり向いていないといえます。

 

 

・対応できないシステムが多い

BasicRoboは専用ブラウザをもっているので開発しやすいのですが、

そのぶん対象システムがブラウザに対応していないといった場合がよくあります。

 

例えば自動化例の定番として事例の多いSlackなどはBasicRoboの専用ブラウザに対応しておりません。

 

また、画面の認識方法はソースコードを読み込んで認識するので安定性はあるのですが、

JavaScriptが多用されているシステムなどは相性が悪く認識できないことがあります

 

具体例をあげるとGSuite系のサービスとは相性がよくありません。

 

利用シーン

・拠点をまたいで大規模導入する場合

基本的にサーバ型での運用が前提のツールなのでいくつも拠点をもつような大企業で導入を進める場合は、

BasicRoboを導入することで最初から管理運用フェーズを見据えたRPA導入を進めることが可能です。

 

また、DSがほぼ無制限に使えるため大規模に導入する場合はほかのツールより費用を抑えることができる場合もあります

 

 

・現場作業者による開発を前提とする場合

前述のとおりBasicRoboは非エンジニアでも開発がしやすいツールなので、

現場で実際に作業をしている人が自動化を実現しやすいです。

 

なので現場開発を前提とする場合はBasicRoboの導入が有効だといえます。

 

逆に以下のような場合は利用するメリットがないかもしれません。

  • 中小企業での導入
  • エンジニアによる集中開発をする場合

 

 

まとめ

 

主な特徴は以下の通りです。

  • 国内運用実績No.1
  • 非エンジニアでも開発しやすい
  • 高額

 

また、製品やサービスは今後アップデートされていきますので弱点が補われたり、

機能が追加される可能性があるので実際に導入を検討される際には販売店にお問い合わせください。

 

その他、RPA製品の選定、導入につきましては、弊社にご相談ください。

CONTACT

 

 

 

【社長が語る】RPAのインハウス化がもたらす中小企業のあたらしい未来

2018.07.25

現段階における国内のRPAの浸透はようやく一合目を超えた程度。

 

最近では、大手企業でなく、中堅企業の導入の検討もはじまり、

また地方自治体など公共における導入の話もちらほらと聞かれるようになりました。

 

私はこの中堅企業、公共のRPA導入までも山の中腹あたりと考えているのですが、

この一合目を超えた事実は、我々RPAの普及を願う業者にとって大いに奮い立つものである。

 

と言うのも、公共は横並び意識が強いため、どこかが始めたら全体がその道にならうであろうと誰もが思っている。

 

そして中堅企業にとっても、RPAが採算に合うと分かれば一気に導入が進む可能性が十分にある。

一合目から中腹までは意外と早いものである。

 

 

では、中腹から広がる原野は何か?

 

それは日本の大部分を占める中小企業群であり、

以前から訴えているようにRPAは本質的に中小企業を救う技術という信念を持ちRPA普及に努める私にとっては、そこからが本番。

そして最も困難な道のりの始まりということになる。

 

中小企業にとってのRPA導入についての障壁。

 

先日はその心理的障壁、中小企業社長のITリテラシーの低さと新しいビジネス技術への潜在的な不安を記事として取り上げたが、

今後一番のネックになるのは、もちろん導入コストであろう。

 

当社の導入コンサルティングの実績からも、大企業と違いスケールメリットが出にくい中小企業の場合、

例えば定番の経理業務で23名の経理スタッフで運用しているような典型的な規模であれば、月の業務効率化で0.5人工程度の場合が多い。

金額にして10~20万円ていどの削減か。

 

これがコスト削減として多いか少ないかは分からないが、RPAのライセンス費、最低限のメンテナンス費が毎月発生する中、

中小企業向けの安価なパッケージを開発し低価格化に挑戦したとして、

月のRPA導入金額として10万円を下回ることは現時点では大変な困難であると思われる。

 

そうすると、0.5人工削減の対価が10万円では中小企業としては割りが合わないだろうし、

そもそも人であれば(あくまで個人の能力に大いに依存することになるが)マルチタスクを含む柔軟な活用があるだろうし、

この事実だけをもってしても中小企業がRPA化に前向きになることは当分ないのではと考えてしまう。

 

 また最大の障壁として、仮にコスト削減できたとして、その人員をリストラすることはほぼ不可能であるという事実。

 

大企業であればリストラという名目で大量に解雇もあるのだろう。

しかし顔の通じた中小企業で事業順調の中でリストラというのは実はとてもハードルの高いものだ。

 

また0.5人工削減できたからと言って、うまく人間の半分だけ0.5人工分リストラすることなどもちろんのこと不可能だ。

 

 

 そんな中小企業のRPA導入に対する一抹の不安を抱きながら、エンジニアと食事をしていた時だった。

 

現在当社では大手中堅向けのRPA開発受託が順調に進み、

また公共部門における入札の増加など、ポジティブな話が多く社内も盛り上がっている。

 

しかし、前述のようにもともと私の夢は、これからの人口減社会において、

本当に苦しい戦いを強いられる優良中小企業の為、働き方改革実現の為のRPA事業。

 

中小企業の導入という五合目以上の実現をいつも意識している。

何気ない会話の中で、エンジニアから出た一言が私の気を引いた。

 

「欧米では中小企業もインハウスエンジニアを持つのは当たり前ですし、社内システムは基本的には自社でつくるものですよ。」

 

 システムと言えば外注が当たり前のこの国で会社経営している身にとっては、はじめて聞く情報。

だが、考えれば考えるほど、それが合理的であると思った。

 

特に大企業と違い業務の標準化が進んでない中小企業がパッケージを導入しようとして失敗するケースはよく聞くし、

そもそもITリテラシーが一般的に低い日本の中小企業の社長にとって外部のシステム業者と会話するのは、

その尊厳を脅かす多大な苦痛を得ることだろう。

 

 

そんな諸々の状況から日本の中小企業のIT化は遅れているのだが、それが社内で開発が出来るとなれば話が違う。

 

 現在、情シス担当がいる中小企業は、IT系か、それでなければ上場準備の為の雇用か、

いずれにしろ一般的な中小企業の定義からは外れる。

 

 なぜ欧米と違いインハウスSEが少ないのか?

 

 技術者が足りないのだろうか?私はそうは思わない。

 

システムエンジニアの採用は、ここ20~30年絶え間なく行われ、アーリーな開発者は既に定年の年になっているほど。

 

もちろん最先端の技術を修得した若手となれば限られるが、国内におけるIT技術者の数は私たちが思っている以上に多い。

 

 

そして、そのキャリアのスタートとして大手企業に勤めた彼らも、その後は転職などを繰り返し、

中小企業でも十分に雇用できる状況、条件に身を置く技術者はたくさんいる。

 

 むしろ、明日をも知れぬ開発プロジェクトの連続で流浪の民と化し年を重ねた彼らは、

中小と言えど事業会社の情シス、インハウスエンジニアという立場は願ったりかなったりの職ではないだろうか。

 

 それでも増えない理由は、中小企業側にあるのだろう。

 

社内にIT技術者を抱えることに対するメリットが見えない。

そもそもIT技術者とか高そう。

 

ここでもハードルはやはり中小企業経営者のリテラシーの低さだ。

 

 だったら、新規雇用をするのではなく、社内の誰かがITエンジニアになるのだったらどうだろうか?

社員の付加価値かは前向きな中小企業にとって受け入れられやすい提案である。

 

しかし誰がエンジニアになれるのか?

そもそも、そんなに簡単にエンジニアになんかなれないだろう。

 

 

 いえ、RPAだったら、それが可能なのです。

 

RPAは文脈から、どうしてもこれまでのコンピューター言語の系譜でとらえられがちだが、

その実、技術としてはエクセルなどのオフィス製品に近い。

 

これはプログラムの素養がなくとも、エクセルが使える経理、もしくは総務スタッフなど、

どの中小企業にもいる社員で修得が可能なレベルの技術である。

 

 

だが、その先の出来ることの広がりは果てしない。

 

RPAを修得すれば、これまでただの経理だった女性が、会社の経営レベルで効率化を考え、

実践する強力なスタッフへ進化することも不可能ではないのだ。

 

人件費を削減する、のではなく、人材に付加価値をつける。

それも人件費は一切増えないままに。

 

中小企業の求めているのは、まさにそれだ。そしてRPAの未来だ。

 

20年前、WEBサイトの構築は一大事業でした。

またWEB制作だけで大儲けというバブルな会社が一気に増えました。

 

しかし、今ではどうでしょう?

ワードプレスなどの発達によって、コーポレートWEBサイトは自分たちで作ってします会社も少なくない。

 

それこそ、WEBまわりの技術のインハウス化は規制の事実であるし、もちろん中小企業も同じくだ。

 

 

中小企業に対しては、RPAの開発を受託するというこれまでの発想では、普及は難しい。

 

だったら、中小企業のインハウスにRPAエンジニアを育てることで、RPAの普及を進めよう。

そう思った瞬間に、中小企業のRPA化、働き方改革についての道が開けた。

 

当社では、中小企業向けの「RPA自走化プログラム」を提供しています。

 

まずは教育、選抜の御社社員を3か月で立派なRPAエンジニアに育てます。

そして御社業務の効率化、RPAエンジニアに育った社員と共に、当社が提供する経理などの効率化パッケージを御社仕様にアップデート。

 

その後は格安の月数万円で御社にあったツールをお使いいただけます。

最後にアフターメンテナンス、御社社員からのRPAに関する問い合わせはいつでもお受けします。

 

これからは、社内ITエンジニアの時代。RPAの自走化で働き方改革を!

 

 

■RPA自走化プログラムのお問い合わせはこちら

RPAトレーニング

 

 

RPA全社導入前の心得 ~RPAプロジェクト推進体制編~

2018.07.24

今回はRPAのプロジェクト推進体制に関する内容です。

 

RPAの導入方法は「特定部門の導入」と「全社導入」の大きく分けて2パターンあります。

 

前者では、新たな技術導入という視点で淡々とプロジェクトを進めていけばよいのですが、

後者の場合ですと、多くの部門や業務を意識していく必要があり比較的ハードルが高いと言えます。

 

当コラムでは、特定部門のRPA導入に加え、

大手金融グループ企業での全社的なRPA導入のどちらをもコンサルタントの立場として経験して来た筆者の目線から、

RPAの全社導入におけるプロジェクト推進体制についてのポイントを紹介します。

 

 

 

 

RPA専門組織の立ち上げ

これまでのシステム導入の推進体制としては、従来から存在する情報システム部門が推進することとなりますが、

ことRPAを導入するとなる場合は、新たに立ち上げられた専門組織の役割が大きくなっています

(ここでは、この組織のことを「RPA推進部」と呼びます)。

 

RPA推進部は各部門へのRPA導入支援も含めてワンストップで推進する役割を担います。

このような組織はたいていの場合、経営企画部等の経営戦略や企画に携わる部門の中に位置づけられています。

 

実際にこのような体制をとる企業は増えています。

 

参考として、私が参画したRPA導入プロジェクトでの組織体制は以下のような形でした。

 

 

 

 

 RPA開発チーム

RPA開発チームでは、各部署の従業員に担当業務の詳細ヒアリングを行い、

RPA化が期待できる業務の選定や各業務とRPAの適合性評価、さらにロボット開発等を担います。

 

また、RPA開発後は、開発したロボットが各部署に定着するよう、

マニュアルや業務フローといったドキュメントの作成も行うことが多いです。

 

 

RPA導入プロジェクトでは、プロジェクトの目標として月当たりの業務削減時間が指標としてあげられることが多く、

こちらをRPA化の業務の選定基準とすることが多いです。

 

また、顧客との接点のある業務、すなわち、いわゆるフロント業務の場合ですが、

万が一ロボットにエラーが起こった場合の顧客への影響度を考えるとリスクが高く、

これらの業務をRPAで自動化するか否かも論点の1つになるでしょう。

 

RPA開発チームでは、RPAユーザ(従業員)と直接コミュニケーションを取りながら、

プロジェクト目標である業務削減時間についての管理・報告義務を担うため、非常に重要な役割を担います。

 

 

運用チーム

運用チームでは、RPA導入後の運用が定着するような仕組みを検討します。

例えば、開発したロボットが何らかの理由で故障した場合のユーザからの問い合わせ管理方法等があげられます。

 

ユーザから寄せられる問い合わせを管理し、それらを社内ノウハウとして蓄積するための仕組みを構築することも重要です。

 

こうした運用を検討するにあたっては、ユーザ部門になるべく負担のかからないようにする視点を持つことがポイントになります。

 

なぜなら、RPAを導入しても、その後のフォロー体制が煩雑だと、

結局従来通りの業務のやり方のほうがやりやすいと感じてしまい、その場合RPAは宝の持ち腐れとなってしまうからです。

 

 

環境構築チーム

環境構築チームでは、RPA導入に必要なサーバやロボットの開発/実行(起動)PCの設置、RPAのライセンス管理等を検討するチームです。

 

また、RPAツールによっては、①単体のPCにインストールして個別に管理する方法(いわゆるRDA=Robotics Desktop Automation)と、

②サーバで集中管理する方法(サーバー型RPA)があり、どちらを採用するかは企業の規模や管理方針に則って決める必要があります。

 

環境構築チームで検討する内容は、情報システム部門やセキュリティ部門と調整しながら進めていくことが多いです。

 

また、導入するRPAツールが決まっていない場合は、環境構築チームがRPAベンダーへのヒアリングからRPAツールの選定を行います。

 

参考として、RPAツールの選定ポイントをあげます(『まるわかり!RPA』(出版社名:日経BPムック)89頁より引用)。

 大きく以下の4点が挙げられるようです。

 

  1. 自社環境で使える製品か?
  2. デスクトップ型かサーバー型か?
  3. 自社の開発・保守体制に適しているか?
  4. 自社にとって経済的なライセンス形態か?

 

 

 

保守チーム

保守チームでは、RPAの本格導入後の窓口業務としての役割を担います。

 

具体的には、新たにロボットを構築する場合や、何らかの理由でロボットが起動しなくなった場合の対応等を行います。

 

また、リリースチェックといって、構築/改作したロボットを使用する前に、

ロボットの内容をチェックする品質管理の役割も担います。

 

保守チームの運用方法として「アウトソーシングするパターン」と「社内人材を利用するパターン」がありますが、

後者の場合、保守を担当する社員はRPAの知見を有する必要がある為、事前に研修を計画するなどの検討が必要になります。

 

 

各チームにおける想定成果物

最後に、RPAの運用を定着化させるための各成果物について紹介します。

 

RPA開発チームの成果物

  • ロボット構築ガイド:ユーザー(従業員)向けに作成する、簡易的なロボット作成マニュアルです。ロボットの構築ルール(命名規則等)を記載したり、簡単な操作ガイドを記載します。
  • ToBe業務マニュアル:従来のAsIs業務フローとは別に、RPAを使用した場合の業務マニュアルを作成します。例えば、あるWebサイトから単価等の情報を抽出(コピー)し、Excelフォーマットにその値を貼り付けるといった作業を行う場合、具体的にWebサイトのどの箇所から値を取ってきてExcel上のどのセルに貼り付けるのか、といったことをここで明記します。情報を外部のWebサイトから取得する場合、Webサイトの画面構成が変わる度にロボットの改作やマニュアルの内容を変更しなくてはいけないため注意が必要です。
  • ToBe業務フローToBe業務マニュアルの補完的な役割を担います。ここでは、大まかな業務の流れを記載します。業務フロー上で人間が手作業で行う部分とRPAで行う作業の部分を明示的に示すことが重要です。

 

運用チームの成果物

  • ロボット構築/改作フロー:新たにロボットを構築する場合や、何らかの理由でロボットが起動しなくなった場合にロボットの構築/改作を保守チームに依頼するための手順を定義します。上記で述べましたが、このフローはなるべくユーザ(従業員)に負担をかけさせないような仕組みを設計する必要があります。
  • RPAユーザ(従業員)向け研修実施要項:社内でのRPA人材育成を目的とした研修のカリキュラムや開催方針等を記載します。

 

環境構築チームの成果物

  • RPA導入方針:例えばRPAツールの機能上の制約条件や禁止事項、社内システムIDや権限設定のルール等を定義します。
  • RPAツール構成資料RPA用のサーバやロボットの実行/起動PCの設定方法等を定義します。

 

保守チームの成果物

  • QA窓口の運用ルール:ロボ構築方法に関する相談窓口への連絡方法等を定義します。
  • リリース手順書:ロボットの品質を担保するために、保守担当が従業員により構築されたロボットの中身をチェックします。

 

おわりに

いかがだったでしょうか。

 

RPAを全社導入する前に心がけるポイントや

各チーム組織の概要、役割を中心にお伝えしました。

 

導入前のTIPSとしてお役立ていただければ幸いです。

 

 

 

【RPAツールの一角】Automation Anywhereとは

2018.07.23

今回はRPAツールのひとつ、Automation Anywhereについて紹介します。

 

【サービス概要】

Automation Anywhereは、アメリカのサンノゼに本社を置くAutomation Anywhere社が提供するRPAサービスです。

 

創業は2003年。全世界で1000以上の企業に利用されており、大規模導入の実績を多く持ちます。

 

日本では2017年から日本IBM、日立ソリューションズなどのパートナー企業がサービス提供しているのに加え、

2018年3月にはAutomation Anywhere日本支社も開設、国内での本格展開が始まっています。

 

 

【構成】

同社が提供するRPAサービスの名称は「Automation Anywhere Enterprise」です(20187月時点のバージョンは11)。

 

基本構成は以下の3つです。

 

  • Bot Creator:ロボット開発環境(ロボットの作成)
  • Bot Runner:ロボット実行環境(ロボットの実行)
  • Control Room:ロボット管理環境(ユーザーやロボットの管理、ログ収集)

 

ロボット作成はBot Creator上で行います。

 

レコーディング機能のほか用意されているコマンドからメッセージ表示などの動作を設定することもできます。

 

 

管理はControl Roomで行います。

 

RPAのロボットは、大きく分けて各PC上で動くタイプと、サーバ上で動くタイプの2種類あります。

 

サーバ上で動くタイプは管理のしやすさやユーザー管理ができるといったセキュリティ上の利点から大企業で多く導入されています。

 

Automation Anywhereはこちらに分類されます。

 

 

【特徴】

Automation Anywhereの特徴は、

 

  1. 大規模導入に適している(サーバ型でユーザー・ロボット管理が容易)
  2. 非定型業務にも適用可能(機械学習技術のIQ Botを提供)
  3. 連携サービスに強み(RPA効果測定・分析エンジンのBot Insight、作成済みロボットを共有できるBot Storeを提供)

 

といった点が挙げられます。

 

 

【導入事例】

国内では、横河電機が2017年にシステム登録業務の自動化などを目的としてAutomation Anywhere Enterpriseを導入、

30時間の作業工数を月4時間に削減したと発表しています。

 

参考:TISRPAを活用した横河電機の本社業務の生産性改革を支援(TISリリース)

https://www.tis.co.jp/news/2017/tis_news/20171121_1.html

 

 

サントリーグループでは2017年に働き方改革の一環としてAutomation Anywhere Enterpriseを導入、

データ収集・加工やメール作成に40体のロボットが稼働、定型業務を代行させています。

 

参考:ロボット40体がルーティンを代行!3.5万時間の削減を目指す、サントリーの働き方改革

https://seleck.cc/1182

 

出典

https://news.mynavi.jp/article/20180416-rpa_aa/

https://www.ibm.com/blogs/solutions/jp-ja/getting-start-ibm-rpa-withaa/

http://www.bit-corp.co.jp/business/business.php

 

 

 

地方自治体におけるBPO【vol.1】・・・概要

2018.07.23

直近で地方自治体におけるRPA導入のポイントについて述べられていたので、

地方自治体BPOとRPAがどのように繋がっていくのかを何回かに分けて述べていきたいと思います。

 

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

 

本日は概要部分です。

本日のコラム担当は複数の地方自治体での業務経験があるので、実例を交えていきますが、

あくまでも私が知っているその一面のみになりますので、

こういうケースもあるなどあれば、こちらよりお知らせいただければ幸いです。

 

 

1.国が推進

地方自治体がBPOを積極的に活用するようになったのは、

2006年に内閣府公共サービス改革推進室が中心となって制定された公共サービス改革法の交付が要因の一つであると言われています。

 

正式な名称は「競争の導入による公共サービスの改革に関する法律」と、

内容については想像しやすいと思いますが、総務省にある概略は下記の通りです。

 

 

国の行政機関等又は地方公共団体が自ら実施する公共サービスに関し、その実施を民間が担うことができるものは民間にゆだねる観点から、これを見直し、民間事業者の創意と工夫が反映されることが期待される一体の業務を選定して官民競争入札又は民間競争入札に付することにより、公共サービスの質の維持向上及び経費の削減を図る改革(競争の導入による公共サービスの改革)を実施するため、その基本理念、公共サービス改革基本方針の策定、官民競争入札及び民間競争入札の手続、落札した民間事業者が公共サービスを実施するために必要な措置、官民競争入札等監理委員会の設置その他の必要な事項を定める。

 

 

簡単にまとめると、民間競争入札によって透明かつ公正公平な競争と民間による創意工夫により良質な住民サービスが安価に提供できるための法律です。

 

もっと簡単に言えば、民間にできることは民間に任せたら、サービスも向上するし、経費も削減できるのではないかということです。

 

 

.地方自治体の業務分類

今まで地方自治体が民間委託をしていなかったわけでなく、アウトソーシングという形では民間委託していました。

 

例えば、給食センター運営やスポーツセンターの管理などです。

しかし、ビジネスプロセスアウトソーシング(BPO)という形では民間委託は少なかったかと思います。

 

 

地方自治体の職員が行う業務のうちでBPO化できる事とできない事の選別は難しく、

法律や住民も関係してくるので意外と悩ましいところです。

 

 

業務を大雑把に分類すると、単純業務専門業務定型業務非定型業務

それ以外に公権力の行使と政策立案など公務員しか出来ない専権業務の5つに分類することができます。

 

その中で単純定型業務をまず民間に委託するところからスタートしました。

 

 

余談ですが、アウトソーシングとBPOの違いを聞かれることがあります。

 

BPOはアウトソーシングの一部であり、例えていうなら、

出前を頼むとアウトソーシング、自分で作るけど材料だけは注文して配達してもらうとBPO

そういう違いという説明を良くします。

 

 

BPO事業者に在籍していた筆者は、地方自治体の職員に対し、

「最高の材料を用意することはできますが、場合によっては下味まで付けることも出来ます。

でも最後に料理するのは職員の方なので、職員の方の腕次第です。」

と言ったことがあります。

 

それに対して地方自治体の職員の方が「それでも失敗するのが公務員、何から何まで準備されても何もしないのが公務員」と言われ、苦笑いをした記憶があります。

 

 

.地方自治体の実際のBPO

 

どのような業務が民間に委託されていったかというと代表的なものは窓口業務です。

 

ある自治体職員の方が言うには、「上(首長や局長など)の人間は、国鉄が民営化(JR)されて、駅員の対応が良くなったと評価されたから、それくらい期待したのでは?」と言っていましたが、皆様のお住まいの市役所や区役所はどうでしょうか?

この10数年で対応が良くなったでしょうか?

 

 

民間委託している窓口と民間委託していない窓口の簡単な見分け方法としては制服です。

制服を着用している場合は民間委託している可能性が高いです。

 

制服を用意していない場合は、ネームホルダーなどで民間委託されているかどうか判断はしやすいかと思います。

 

全ての自治体が窓口業務を民間委託していることもなく、

案内(フロア)係だけを民間委託しているケースなど自治体によって窓口業務の民間委託は千差万別です。

 

ある地方自治体に行けば、時間帯によっては、案内(フロア)係の方が来庁している住民よりも多いようなこともあります。

 

 

 ではなぜ窓口業務からなのかというと、下記リンクにある通り、内閣で閣議決定され、特に窓口業務については、民間委託を推奨しているからです。

「経済財政運営と改革の基本方針2015 ~経済再生なくして財政健全化なし~」(骨太方針)

 

内閣府のホームページには優良事例集まで作っています。

窓口業務の民間委託に係る先進・優良事例集

 

 

.地方自治体のBPOにおける課題

 

実際、現場で窓口業務の委託を行った地方自治体の職員の方に聞くと好評なことが多く、市民の方からも好評なケースが多いです。

 

ごく少数ですが、民間業者の人間に個人情報を見られたくないとの批判もあり、

地方自治体職員がBPO化するにあたって、民間委託して個人情報がちゃんと取り扱われるのだろうかという点を不安視しています。

 

実際に民間委託して、BPOオペレーターが友人の情報を見て、

その友人に教えたではないかということは過去にあったという話は何度か耳にしています。

 

情報の流出というのはどの業界どの分野でもゼロにすることは難しく、限りなくゼロに近づけるしかないのですが、

そういった点ではRPAをうまく活用することで防ぐこともできたかと思います。

 

 

窓口業務を委託する課としては、来庁者数が多い課、代表的なのは市民課です。

 

国民健康保険課も来庁者は多いのですが、国民健康保険課の窓口業務の民間委託は進んでいないのが現状です。

それは国民健康保険課の業務内容が単純ではなく専門業務に分類されるからです。

 

一般的に国民健康保険課は国民健康保険だけを扱う部署ではなく、後期高齢者医療保険も扱っており、

各保険で運営が異なっており、使うシステムも違い、更に制度も多い分野で、難易度が高い業務と言われています。

 

地方自治体によっては、国民健康保険課と後期高齢者医療保険課に分けている地方自治体もあります。

 

複数の地方自治体の職員に聞くと健康保険課は業務範囲が広く、覚えることも多い、

また窓口の対応も難しいから民間委託したいが、どのように民間に委託すればよいのか分からず、

民間委託が頓挫したなんて話も耳にします。

 

 

.その他

 

窓口業務以外にも単純で定型業務である事務だと封緘封入作業などもよく委託される業務の一つです。

 

探せば色々あり、地方自治体BPO業務は拡大の一途をたどることになり、

ある調査では2019年度の市場規模は3兆9,883億円になるとも言われています。

 

具体的にはどのような業務がBPO化されたかというと、税金や水道料金などの徴収業務です。

比較的最近だと各自治体に置かれたマイナンバー関連のコールセンターも民間委託されていました。

 

今まで述べてきた窓口業務や事務業務は単純業務の範囲内のもので、単純定型業務の一つとして委託されていました。

 

 

しかし、地方自治体BPO業務は拡大し、現在は、単純業務から専門業務、定型業務から非定型業務分野のBPO化をどのようにすべきか検討段階に入っています。

 

専門業務や非定型業務をどのようにBPO化すればよいのか悩んでいる自治体の職員の方からご相談を受けるケースは多々あり、

多くの地方自治体の職員はこのあたりで頭を悩ませているようです。

 

行政事務のノウハウはそもそも民間にはなく、民間委託して失敗した事例も良く聞きます。

 

RPABPOの一部ですが、RPAをどのように導入するのか考えるのも地方自治体職員の課題となりそうです。

 

次回へ続く

 

 

 

RPA教育・研修サービスを行っている会社まとめ

2018.07.20

RPAサービスといえば、ライセンス販売、またはシステムインテグレーションと相場が決まっていましたが、

このところ、新たな潮流が渦巻いているようです。

 

それが、RPAトレーニングサービスです。

RPAトレーニングの実態は様々なようです。

 

第一に挙げられるのは、

SIerにおけるRPA開発者として、または派遣・業務委託のRPA開発者として一人前になることを目的としたトレーニングです。

 

このトレーニングは現在、最もニーズがあると考えられます。

 

なぜなら、RPAエンジニアは、ただでさえ不足しているエンジニアの中でも、

さらに目立って需要と供給がマッチしていない職種だからにほかなりません。

 

もう1点挙げられる目的としては、業務担当(ユーザー側)を対象としたトレーニングです。

RPAは、SIerに開発を委託するほか、独自に開発できるところもメリットの一つとなっています。

 

そこに着眼し、ユーザー側を直接トレーニングしてしまおうというサービスもあるようです。

 

ここでは、このようなトレーニングサービスの具体例を挙げながら、サービスの詳細や意義を論じていきたいと思います。

 

 

パーソルテクノロジースタッフ社

 

■RPAトレーニング講座

https://persol-tech-s.co.jp/it/seminar/rpa.html

 

 

Bizrobo!(Basic robo)を使用したRPAトレーニングとのことです。

 

1日ミッチリとトレーニングしてくれるサービスで、5名までですが、なんと無料とのことです。

 

ただ、パーソルテクノロジースタッフへ登録している人のみが対象となっています。

つまり、どちらかというと「社内研修」に近いサービスと言ってよいのではないでしょうか。

 

それ以外にも、受講から2ヶ月以内に仕事が開始可能であり、

VBAマクロの開発経験または何かしらのシステム開発経験のあるエンジニアのみが受講可能だということです。

 

 

これは、パーソルテクノロジースタッフに登録しているエンジニアにとっては願ってもないトレーニングと言ってもよいのではないでしょうか。

 

なぜなら、RPAエンジニアのスキルを得ることにより、自身の単価が上がり、延いてはキャリアアップにつながる可能性が非常に高いからです。

 

一方、パーソルテクノロジースタッフ社側としても、エンジニアの単価が上がってくれたら利益も大きくなるので、win-winです。

そこが、受講料無料のからくりと言えるでしょう。

 

毎回5名までに制限を設けておきつつも、

1週間ごとのように、かなり頻繁に開催しているあたり、結構本気でトレーニングをやってくれそうな印象は受けます。

 

パーソルテクノロジースタッフ社に登録しているエンジニアで、キャリアアップを考える方は、受講しない理由はないでしょう。

 

 

NOCアウトソーシング&コンサルティング社

 

■RPAエンジニア キャリアアップ支援プログラム

https://www.noc-net.co.jp/rpa_engineer/index.html

 

 

こちらは打って変わってWinActorを使用したトレーニングとなります。

 

受講料はなんとこちらも無料

 

しかも、NOC社もエンジニア派遣業、特にRPAエンジニアの派遣業務もされているようですが、

見たところだと、NOC社への登録は必須ではないのかもしれません(要確認)。

 

ただし、それ相応にハードルが高くなっているかもしれません。

入学テストなるものが存在するようで、これに合格しなければトレーニングを受講することはできないようです。

 

また、業務改善プロジェクトに参画したことがあり、

Excelでマクロが組め、

VBAの知識が一定程度ある者のみが受講可能とのことです。

 

 

この条件さえ突破すれば、かなり手厚いトレーニングが受講できそうです。

RPAに関する基礎研修、実技、それらに対するテストを受講したのち、

2週間もの現場研修を経験を積むことができるとのことです。

 

その後、再びスキルを判定するテストを受験したうえで、晴れて飛び立つことができるというシナリオのようです。

こちらも、NOC社に登録している・していないにかかわらず、非常にありがたいキャリアアッププランですね。

 

ヒューマンリソシア社

 

■教育研修

https://resocia.jp/corporate/solution/rpa/traning/index.html

 

 

こちらもWinActorを使用したトレーニングとなっています。

 

初級・中級・上級コースに分かれていますが、いずれも目的・ゴールとしてはシナリオの作成ができることとなっています。

各レベルによりますが、上級でも「シナリオの作成が自立的に可能」といった程度です。

 

受講期間は、初級が7時間×1日、中級が7時間×2日、上級が7時間×3日となっており、

受講料は、初級が3万円/人、中級が5万円/人、上級が5万円/人となっています。

 

こちらは費用がかかるだけに、特にこれといった受講条件はなさそうです。

あるとすれば、法人のみが対象、といった辺りでしょうか。

上記までのトレーニングと異なり、トレーニングそのものを商材としているサービスとなります。

 

 

MAIA社

 

■RPAラーニング for Business

https://www.maia.co.jp/rpa-learning-for-business

 

 

Bizrobo!(Basicrobo)を使用したトレーニングです。

オンライン会議で有名なブイキューブ社が提供するオンライントレーニングサービスを利用しているようです。

 

ということで、対面ではなくオンラインといったところが、上記までのトレーニングとは一線を画すようです。

 

ただし、オンライン教材でどこまで学べるかは疑問もあります。

元々エンジニアだった、パソコンに強い、というような人であればともかく、

パソコンすらまともに触ったことがないような人には厳しい気がしますね。

 

費用感としては、ライトコースが20万円/月、スタンダードコースが40万円/月となっています。

オンライントレーニングだけと考えると少し値がさ感が残ります。

RPAテクノロジーズと業務提携している強みがある故の強気の価格設定かと推測できます。

 

オプションで、開発支援なども行っているとのことです。

 

 

日本CFO協会

 

■RPA体験 トレーニング講座(1日コース)

http://www.cfo.jp/seminar/rpa_training/

 

 

WinActorおよびロボ・オペレータというRPAツールを教材としているようです。

 

面白いのは、対象者を「経理・財務の業務についての理解がある若手・中堅クラスの方」と、

業務内容でかなり絞っている点です。

 

プログラミングスキル、開発経験で絞っている他社とは趣を異にしています。

 

WinActorのトレーニングについては、

3時間半の講義で、一般価格4万円(会員価格3.2万)となっており、

ロボ・オペレータのトレーニングについては、

2時間半の講義で、一般価格3万円(会員価格2.4万)となっております。

 

ロボ・オペレータは初耳のRPAツールですが、

フル機能版の通常価格で12万円/月とそこそこ強気の価格設定ですね。

 

 

パソナ

 

■RPAエキスパート育成講座

https://www.pasona.co.jp/careerup/rpa.html

 

WinActorを利用したトレーニングです。

パソナ登録スタッフ向けですが、10,800円かかります。

 

「RPAエキスパート育成講座 Learningコース」は、

用意された要件定義書をもとにWinActorでシナリオを構築し、

テスト、保守面までのRPA構築の流れを2日間で行うというかなり実践的、実務的なトレーニングであるとのことです。

 

 

アーツアンドクラフツ

RPAトレーニング

 

弊社でも教育トレーニングを実施しております。

上記では登場しなかった「UiPath」という優れたRPAツールを教材としたトレーニングとなっております。

確かな実績をあげている、確立されたメソッドでRPAエンジニアを着実に育成しています。

 

 

おわりに

いかがでしたでしょうか。

ターゲット層、使用RPAツールの違いなど、独自色のあるものが多かったように思われます。

皆様も、ご自分に合ったRPAトレーニングの受講を検討されてはいかがでしょうか。

 

 

 

Citrix環境の仮想化とそのメリット・デメリット

2018.07.19

UiPathのオートメーションについて学んでいると多くの場合に出てくるのがCitrix(以下シトリックス)と呼ばれるものです。

シトリックスやシトリックスレシーバーという言葉は何回か聞くことはあると思うですが、

しっかりと、どういったものなのか全容を理解している人も多くはないかと思いましたので

今回はシトリックス環境やその活用法についてまとめていきたいと思います。

 

シトリックス・システムズ株式会社について

シトリックスとは多くの場合、シトリックス・システムズの略称として書かれています。

シトリックス・システムズとはコンピューターの仮想化や遠隔操作のソフトウェアやネットワークの開発、

他にもクラウドコンピューティング技術などの製品を開発・販売しているアメリカのITの企業です。

 

シトリックス・システムズ株式会社はアメリカのフロリダ州に本社が置かれており、

日本にも霞が関にシトリックス・システムズ・ジャパン株式会社という支社がおかれています。

 

シトリックスの企業方針としては、

いつでも、どこでも、あらゆるデバイス、ネットワークから、

世界中のアプリケーションおよびデータへのセキュアかつ容易なアクセスを実現する

というものです。

この一つの方針をシトリックスでは尽力して取り組んでいます。

 

シトリックスはテクノロジーを”great liberator(大いなる解放者)“であるべきであると考えてます。

 

企業の生産性などを向上させるためにテクノロジーを用いるべきであり、

それにより人々には時間や場所にとらわれない働き方を可能にするようにしていくべきであると考えているようです。

 

また、IT分野においてはセキュリティの面でも常に安全性を保つことで安心感を与えるべきだと考えています。

 

これらのために、人・組織・モノがしっかりと連携し、

相互でアクセス可能な世界を実現することを課題としているようです。

つまり、シトリックスはすべてのビジネスがデジタルで処理され、

その顧客がその可能性をさらに引き出すことができる世界を目指しているのです。

 

また、シトリックスは生産性の向上と効率の単純化を行うことを推進しています。

今後、仕事の個人化が進むにつれて、2020年までに労働者の50%の人がリモート勤務に変わると予想しています。

個人作業にともなって、場所に関係なく仕事していくようになると

インフラストラクチャ、デバイス、およびデータのセキュリティ保護に関する課題を突き付けられます。

この課題についてもシトリックスはソフトウェアなどによって解決をしようと考えているようです。

 

仮想化とは

単に、仮想化といってもいくつかの仮想化がありますが、

今回お話するのはシトリックスも開発している、デスクトップ仮想化についてです。

 

デスクトップ仮想化

デスクトップ仮想化とは、その名の通りデスクトップの仮想化をおこなうものです。

オペレーションシステム(OS)やアプリケーションのような作業を行う際に、

使用するであろうデスクトップの環境を仮想化技術を用いてサーバー上に集約する作業のことです。

 

利用者はディスプレイの画面や信号送信機器のみを必要とし、

デバイス機からネットワーク越しの遠隔地のパソコン本体を呼び出して操作します。

つまり遠隔地にある仮想マシンをあたかも手元にあるように操作し、利用するといった方法です。

 

一般的な普通のパソコンでは、デバイス機器とOS、アプリケーションとが一体となっていますが、

仮想化においてはこれらが分離されて実行されます。

そのような環境やシステムを「VDI」(Virtual Desktop Infrastructure:仮想デスクトップインフラ)と呼びます。

ここまでデスクトップ仮想化の内容について触れてきましたが、

次からは仮想化における利点についてお話していきます。

 

デスクトップ仮想化における利点

デスクトップ仮想化にはどのような利点があるのでしょうか。

 

・ユーザーが利用する端末が、キーボードやマウスなどの信号を送る機器、そして画面表示のためのディスプレイのみ

OSなどはサーバーで管理しているため、

利用者は、手元のキーボードやマウスを用いて遠隔のサーバーに信号を送るのみで構いません。

利用者にとって、周辺機器がとてもシンプルになります。

また、従来のパソコンよりも低スペックの機器でも可能なので、環境構築が安価でコストを削減することができます。

 

・ユーザーがパソコンを管理する必要がない

OSやアプリケーションなどが分離されていることにより、

利用者は複雑なOSのアップデートやセキュリティの導入などをする必要がなくなります。

他にも、ソフトウェアの追加や変更、メンテナンスもする必要がありません。

これらはすべてサーバー側の管理者がすべて行うことになります。

 

・セキュリティが強固

手元のパソコンに大切なデータを管理するのではなく、

サーバー上のデータセンターやマシンルーム内で管理するため情報の漏洩などが比較的防ぎやすくまります。

また、USBストレージによるウイルス感染なども防ぎやすくなります。

 

さらに、管理を管理者が一元的に行えるので、

様々なところでプロフェッショナルな人材を雇う必要がなくなり、コストを削減することができます。

 

・どこでも同じ環境をつくりやすい

物理的なパソコンと違って、サーバー上にデスクトップ環境があるため、

自宅でも出先でも同じ環境を設定することができ、作業効率が落ちることがありません。

 

・管理者の作業が減る

従来の管理では、分離された複数のパソコンを一台ずつ管理しないといけませんでした。

何百何千のデスクトップを管理して、そこでバックアップを取る必要がありましたが、

デスクトップ仮想化においては、各アプリケーションもOSもコピーがそれぞれひとつずつで済みます。

 

デメリット・注意点

・オフラインでは利用不可

今までの説明で明らかですが、デスクトップ仮想化はサーバーを経由して行うので、

ネットワーク環境がない場合だと作業をおこなうことができません。

 

また、ネットワーク環境の障害などが起きた場合などでも作業の効率は落ちてしまいます。

つまり、使っているネットワーク環境に依存するということです。

 

・通信帯域の効率化

デスクトップ仮想化においてはOSやアプリケーションなどがサーバー側で実行されます。

ここで重要になってくるのが、通信帯域の効率化です。

理由としては、ネットワークの帯域を複数のユーザーで共有して共有するので

接続するユーザーの数によってはネットワークの帯域を圧迫してしまい、

スムーズな作業を行えない可能性があるという面です。

特に画像などのデータを転送する場合などにおいては、この効率化がとても重要になってきます。

 

そのためにも、VDI(Virtual Desktop Infrastructure:仮想デスクトップインフラ)を開発・販売

している企業は効率の高い通信プロトコルを提供しています。

例えば、シトリックスが提供しているCitrix XenDesktop」は「Citrix ICA」を実装しています。

実際には、シトリックス以外にも

ヴイエムウェアーの「VMware Horizon」やマイクロソフトの「Microsoft VDI」などの

仮想化ソフトウェアもあります。

 

最後に

今回はシトリックスのデスクトップ仮想化について見てきました。

多くの人数でプロジェクトを進める際などに、デスクトップ仮想化を行うことでデスクトップの管理などが楽になります。

しかし、このデスクトップ仮想化には利点だけではなくて、

デメリット・注意点などもあるのでそこもしっかりと確認しておきたいところです。

 

 

 

【RPA導入のために】推奨する業務システムの作り方

2018.07.18

業務システムの導入を検討しているみなさんは、

おそらく繁雑で複雑な業務をコンピューターにやらせて楽したい!って想いがあるかと思います。

 

そこで、業務システムを導入する前にやっておいたほうが良いことについて、書きたいと思います。

 

業務システムを作る際のフローは大まかに、以下の工程に分解されます。

 

  1. システム化する作業を整理し、 
  2. その業務のどの部分をシステム化するか検討し、 
  3. どのようなシステムにするか検討して 
  4. 実際に作ります。

 

上記13をお客様の言う通りにシステム化しても何の問題もないように思えます。

 

しかし、その手作業でおこなっている業務に無駄な作業や、実はやらなくてもいい作業が含まれていたらどうでしょう。

 

システム化した際にも同じようにシステムにも無駄が残ります。

 

このような不具合が起こるケースとして2種類あります。

 

  • システムでの処理プロセスを、人間の手作業のプロセスそのままに移管してしまっているケース

 

例えば、RPAのプロジェクトで、何かの情報ソース(Excel等)から、一件一件情報を参照して、システムに入力する作業を自動化するプログラムを組むとします。

 

その場合、人間の既存の作業工程だと、一件Excelから情報を見たら、それをシステムに入力していくことになりますが、

これはロボットの動作ロジックとしては効率的ではありません

 

ロボットで動かす場合、まずExcel等の情報ソースから「全件」情報を取得してしまい、

それを一気にシステムに入力するほうが効率的ですし、ロボットの処理速度も速くなります。

 

このような点は些細なことに思えるかもしれませんが、処理件数が膨大になると致命的な問題になりえます。

 

 

だがしかし、このような処理のプロセスの詳細までは、お客様側としては、差ほど注意をしておらず、結果だけを見る傾向です。

なので、重要なのは、お客様が仕様で伝えたことをそのまま鵜呑みにせずに、

SEの観点からシステム上で動作に適した処理プロセスを提案していくことです。

 

過去に、お客様からの依頼で、既存のシステムの改修を頼まれて、コードを見ることがありますが、

意外とそのような配慮がなく、(プログラム上最適ではなくても)お客様が言った通りの処理ロジックにしてしまっているな、、、という感じを受けることが多々ありました。

 

 

(2)人間側の作業プロセスを頑なとして変えないケース

また、システム開発をしても、人間側の作業は多少なりと残ることになりますが、

その人間側のフローをシステムに合わせて変えるのではなく、今までのやり方を頑なに踏襲してしまうケースもあります。

 

例えば、受付業務に対してRPAを導入するケースで、もともとの既存の業務フローでは、

1件1件訪問者からの申請書類を受付担当が目視チェックし、システムに入力していました。

 

ただ、この業務をRPAで自動化する場合、本来もっとも効率がいいのが、

受付では一旦紙での申請書受領に留め、1日の最後にバッチ処理のようにRPAがOCRをかけてまとめてシステム入力処理をする方法になります。

 

この場合、業務フロー自体の変更が求められるわけですが、お客様側としては、今までのフローを変えるのに抵抗があり、

本来RPAの観点からすると最適なやり方に変えきれないケースが多いです。

 

ただ、それだと本来RPAを含めたシステム導入の目的である、効率化の効果が限定的になってしまいます。

 

このあたりは、システム導入するまでに業務を行う現場側でしっかりと意識合わせをするのが重要なのではないでしょうか。

 

まぁ、お客様がそれで満足するならそれはそれで良いのではありますが。。。。

 

 

しかし、後になってから無駄作業を取り除きたい!となった場合、人に対しては口頭で言えば済みますが、コンピュータは万能ではありませんので、

いったん作ってしまったシステムを修正するには、多くのお金と時間が必要になります

 

 

現在ベンダー経由でシステム構築をされた企業様においも、このような理由で本来必要のなかった改修を行わざるを得なく、多大な改修費用が発生しまったケースをよく聞きます。

 

そこで、システム化する前に業務フローの見直しをしてみましょう!という提案です。

 

少なからず 1.のタイミングで意識しなくても、それっぽい業務フローの見直しは行われるかとは思いますが、改善や効率化とまではいかないのではないでしょうか。

 

改善や効率化を考えた業務フローの見直しは、なかなか難しいし、めんどうですが、システム化を機に取り組むチャンスです。

 

システム化する作業の担当者は、自身の行っている業務がベストだと考えている場合も少なくありませんので、

 開発プロジェクトに参加するSEPGは客観的にロジカルに物事を整理することが得意な人たちですので、

彼らの能力をフルに活用し、業務フローの見直しを行ってみてもいいかもしれませんね。

 

外部の意見も聞きながら業務フローを見直すことで、新しい発見もあるかもしれません。

 

ですが、SEPGはシステムを作ることについてはプロですが、その業務については無知識です。

実際に作業される方がその業務において、プロですから、あくまでも参考程度でしょうけどね。

 

1.の部分で必要な業務の手順を整理出来たら、次は2.のどの部分をシステム化するかです。

 

例えばシステム化対象の作業の、この部分は自動化したほうがいいな、この部分は人の手が入ったほうがスムーズだな、などに切り分けをします。

 

専門用語で1.2.は仕様決めですかね。何を作るか?のフェーズです。

 

次に3.ですが、画面はどういった画面でどのように遷移するや、出力結果を誰々にメールするや、出力結果をほかのシステムに投入する、などどういったことを技術的に検討します。

 

ここではどうやって作るか?のフェーズになりますので、設計のフェーズですね。

 

 

ここまできて、システム化が現実味を帯びてきます。実際に作っていくフェーズですね。

 

本当であれば、1.で、業務フローを見直した後に、手作業による運用を行い、

手順などの検証をしてからシステム化したほうが、リスクも抑えられて、良いシステムができるような気がしますが、

 この後は作りながら、直しながら作っていくことになるでしょう。

 

こうして完成した業務システムをテスト運用していただいて、初めて完成となります。

 

 

こうした業務フローの見直しをせずに、開発した場合、すくなからず、意思疎通がおろそかになり、プロジェクトがうまくいかないことがあります。

 

お客様の頭の中のイメージと実際出来上がったシステムの乖離が大きい場合ですね。

作り手は言われたとおりにもちろん作ります。

でも実際はお客様のイメージとは違う場合があるんですね。

 

こうしたことにならないよう、我々SEは提案するための選択肢を多く持ち、

物事を決定してから作業に取り掛かる必要があるでしょう。

 

ただ、合理的に考えれば、そうなるはずなのですが、実際のシステム開発現場では、

往々にして合理的な判断にならないことが多いのも事実です。

 

それは、しがらみというか、業務を行っている現場の人たちが本質的に「変化」を忌避する性向があるからです。

合理的に正しかろうが、間違っていようが関係なく、今までの自分のやり方を変えたくない

今のやり方がベストプラクティスだ、、、そういう偏見をもともと持っているのだと思います。

 

 

高いお金と時間をかけて開発する業務システムです。

無駄の少ないシステムを作ったほうが、発注側も受注側もお得なのではないでしょうか。

 

 

 

【経理×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を成功に導くためのノウハウを蓄積した弊社にご相談ください

 

 

 

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