2018.07.31
今回の記事では、業務のRPA化を行うための設計書を記載する際にどのような点に気をつければよいかをまとめます。
特にRPAのエンジニアではない人がRPAのロボットの設計書を作成する際に理解しておきたいポイントを中心に記載します。
そもそもRPAのための設計書ってどんなものなの？と思う方もいるかも知れませんが、
RPAの場合は通常のソフトウェアの開発よりも簡易的な仕様書を利用する場合が多く、
処理フローのようなガチガチのIT設計書を書かない場合もあります。
当然、プロジェクトによってどのような設計書を作成するかは異なりますが、
実際のプロジェクトで採用されている例としては、引き継ぎ時などに利用される業務マニュアルをベースに、
業務手順書を再作成するといった手段を取っています。
この記事内では具体的な設計書の内容については触れませんが、
設計書を書く際のポイントをいくつかの区分に分けて説明していきたいと思います。
そもそも何を書けばいいんだっけ？と、頭を捻らせてしまう方もいらっしゃるかもしれませんが、
難しく考える必要はありません。
設計書の基本は、人間が対象業務をどのような手順でやっているかをそのまま書き出していくだけです。
ただし、ロボットは文脈を理解することはできないので、どのファイルを開くのか、
どの対象画面を操作するのかを明確にする必要があります。
例えば、Excelであれば、コピーする範囲はどの列からどの列までで何行目までか、
貼り付ける先はどこのセルか、といった点を具体的に設計書に記載する必要があります。
設計書に書いてある内容の適切な粒度としては、
「まったくPCの操作を知らない新人が、その内容を見るだけで該当の業務をだれに質問することもなく業務を完了できる」といったレベルです。
すこしハードルを高く感じるかもしれませんが、このレベルまで記載ができていれば、
ロボットを開発するエンジニアに感謝されるでしょう。
またこのような形で明確に設計書に記載をすることで、目的が不明な作業や不要なステップに気づくことができるので、
このような面での見直しもついでにできるとなお良いですね。
ロボットは通常のソフトウェアと同じなので、デスクトップのアイコンをダブルクリックするなどで動作を開始することができます。
またそれ以外にも自動起動という手段があります。
自動起動の一番メジャーなやり方は、
が考えられます。
この方法はWindowsの基本機能を利用するので比較的柔軟にロボットにいつ動作してもらうかを指定することができます。
また基本的には月曜日から金曜日が起動だけれども、祝日は稼働してほしくない、といった場合は、
残念ながら祝日を自動判定する機能はロボットにはないので、
営業日の判定を行うロジックを作成する必要があるため、この判定が必要な旨を設計書に明記する必要があります。
（RPAのソフトウェアによっては、サーバー側でロボットを一括監視し、
ロボットをどのタイミングで起動するかを管理する機能を持つものもありますのでご確認ください）
こちらは応用編ですが、基本は朝9:00に起動してくれるので良いのだけれど、
特定の曜日やある特定の日だけ（月末）は、朝10:00に開始してほしいんだよね、といった場合は、
以下の方法で対応します。
ロボットは9時で自動起動にするが、後続処理を実施するかしないかの判定をさせ、
後続処理を実施しない判断をした場合は一定の時間後にリトライさせるといった方法です。
もし事前に一定の法則で起動時間帯をずらしたい日付を決めることができるのであれば、
そのルールをロボットに組み込む必要があるので、これも設計書には記載する必要がでてきます。
事前に起動時間をずらす条件を決めることができないのであれば、特定のファイルの存在有無を確認させたのち、
特定のファイルの中身を読み込ませて、後続処理を実施するかどうかを判定させるといった設計方法が考えられます。
ロボットの設計書を書くにあたって、大事だけれども忘れがちな2つの概念、初期処理と終了処理について記載します。
システムを開発された経験がある方であればイメージがつくかもしれませんが、
ロボットが起動した最初にやる処理と、ロボットが終了したときに実施する処理のことを指します。
この初期処理と終了処理は、RPAの場合は、データベース接続を閉じる、メモリを開放するといったシステム開発の観点とは異なります。
RPAでは、人間の処理の内容をロボットが変わりに代行するという機能なので、
画面に他のアプリケーションが表示されていたり、不要な画面が一番手前に来ていたりする場合に、
動作が意図通りに完了しないというリスクがあります。
このリスクを抑えるために必要なのが初期処理と終了処理で実施するプロセスの削除や開いているアプリケーションをクローズする処理です。
特にロボットをPC上で動作させて、そのパソコンを人間がほとんど触ることがない場合、
この初期処理・終了処理がきちんと設計できていないとしょっちゅう業務処理を失敗してしまうロボットになってしまいます。
そのため、設計時には今一度、このロボットが操作する可能性のあるソフトウェアはなにか、
それらを終了させる・画面を閉じる記載があるかを再確認してください。
将来的にはロボットも人間のように状況に応じた判断を自ら業務を遂行していくようになるのかもしれませんが、
現状のロボットは、人間が業務をするのと異なり、
なにか予期せぬエラーが発生してしまった場合に、動作できなくなってしまいます。
この予期せぬエラーが発生した場合に役立つ概念がリトライ（再実行）です。
ただし、再実行するように設計書に記載するのは簡単ですが、再実行を記載する際には気をつけるポイントがあります。
気をつける最大のポイントは、その動作をそのまま再実行しても問題がないか、という点です。
ロボットを作成するソフトウェアの種類によっては、特定のステップのみを複数回実施するだけでなく、
特定のステップのまとまりを再実行する範囲として定めることができます。
例えば、
Step1. Excelを開く。
Step2. シート１の内容を全選択しコピー。
Step3. シート２に貼り付ける。
Step4. シート１の特定の条件を満たすデータを削除。
という処理だった場合に、Step 1のExcelを開くのみを再実行させる、という指定の仕方もあれば、
1-4を一つのまとまりとして考え、1-4のいずれかが失敗した場合に、
1.Excelを開くからやり直しさせるといったことが指定可能です。
筆者の経験したプロジェクトでは多くの場合すべてのステップにリトライ処理を入れるのは時間がかかるため、
1-4を一つのまとまりとして、そのまとまりの中で失敗したらリトライをするという設計になっています。
では、上記のようなプロセスの１-４をそのままリトライさせることの問題は何でしょうか。
Step1のExcelを開くのに失敗した場合であればそのままリトライ処理しても、後続処理に影響がでることはありませんが、
Step4の特定の条件を満たすデータを削除の途中で予期せぬエラー（EXCELが固まってしまう・突然の強制終了等）により失敗した場合はどうなるでしょうか。
この場合、途中までデータが削除されているので、Step1からリトライしてしまうと、
Step2でコピーする内容とStep3でシート2に貼り付ける内容が意図した内容にはなりません。
また同様に、もしStep2で予期せぬエラーによりリトライがかかってしまっても、
既にStep1でExcelを開いているため、Excelの2重起動になってしまいます。
（場合により、読み取り専用で開きますか？といったポップアップが表示され、
そのポップアップを認識できずにロボットが止まってしまいます。）
つまり、上記のようなトラブルを起こさないためにも、
「その動作をそのまま再実行しても問題がないか」という点を考慮した設計にする必要があります。
この場合、1-4の手順に以下のような工夫を加えることで、そのまま再実行しても問題ない設計にすることが可能です。
Step1．もしExcelが開いていれば終了する。
Step2．操作対象のExcelをコピーして別のフォルダに移動する。
Step3．別のフォルダに移動したExcelを開く。
Step4．シート１の内容を全選択しコピー。
Step 5．シート２に貼り付ける。
Step 6．シート１の特定の条件を満たすデータを削除。
Step7．コピーしたファイルを元のフォルダに戻して上書きする。
このように変更することで、1-7のどこのStepで失敗しても、1からやり直せば何度でも同じ結果になることがわかります。
もしリトライの処理を設計に組み込む際には上記のような点を考慮してください。
今回の記事はいかがでしたでしょうか。
できるだけ実践的な内容をお伝えできるようにかなり細かい内容になってはいますが、
実際にRPAの設計書を書く際にご参考になれば幸いです。
また、RPA導入についてご検討の方は、2019年5月に東京ビッグサイトで開催されるRPA導入無料相談会にてご相談いただけます。
2018.07.30
WordPressでRPA_bizの記事を書くにあたって、その書いた記事をFacebookやTwitterといったソーシャルメディアに上げる場合、
毎回毎回自分で記事を投稿するのはとても面倒なことです。
そのようなときにWordPressのRPA_bizの記事をそのままソーシャルメディアに自動的に投稿するということができれば、
とても簡単で楽になると思いました。
ですので、今回はWordPressの記事をTwitterに投稿するのを自動的にできるかどうかを見ていきます。
WordPressにはプラグインと呼ばれる拡張機能が存在します。
プラグインについて公式ではこのように説明されています。
“プラグインは、WordPressの機能を拡張するためのツールです。
WordPress のコアは、柔軟性を保つため、不必要なコードでふくれあがってしまわないように設計されています。
ユーザーそれぞれが特定のニーズに合ったプラグインを利用して、カスタム機能を取り入れられるように作られています。”
つまり、ユーザーが必要な拡張機能のようなものを自分自身でカスタマイズできるといったことです。
また、プラグインは自身で開発することが可能でその際はこちらにプラグイン開発のリファレンスなどが載っていますので、
ご確認しながら開発をおこなってください。
今回は、Twitter投稿の自動化についてのプラグインはすでに含まれているものを使用するので、
開発についてはまた後ほどご覧になってください。
プラグインの実態について少し分かったところで、実際のプラグインを見ていきましょう。
実際にTwitterへの投稿の自動化についてのプラグインは多くはないですが、複数存在します。
これらにはそれぞれ特徴があって、場合によって使うべきプラグインが違うように思います。
それらについてゆっくり見ていきましょう。
Twitterへの投稿の自動化についてのプラグインには
・WP to Twitter
・NextScripts: Social Networks Auto-Poster
・Jetpack
主にこのようなプラグインが存在します。
これらの中からどれを使うべきかどうかを知るためにも、個々のプラグインの特徴について見ていきます。
個人的には、このプラグインの記事が他のプラグインよりも多かった印象を受けました。
ですので、何かわからないことが出てきた時にとても調べやすい状態にあるので始めやすいと思います。
ではまずメリットから説明していきます。
URLの短縮化とは、日本語が入ったURLのリンク切れをなくすことが可能であるのと、
短縮することで見やすくなり、ツイッターの文字制限に引っかからなくなりやすいというメリットが存在しています。
多くの利点がありますが、決定的なデメリットがあります。
このデメリットは結構痛い人が多いのではないでしょうか。
画像（サムネイル）を一緒に載せることで、クリック数は大きく跳ね上がると言われています。
ですので、サムネイルは現在とても重要な要素の一つになっているのです。
しかし、そこまで大規模に運用するつもりのない人にとっては、
サムネイルは手動で作成したりすることで対処することができるのではないでしょうか。
これより、大規模で運用しない人にはとても使いやすいプラグインになっていると思います。
このプラグインも比較的多くの日本語の記事が存在しました。
頭文字をとって”SNAP”と呼ばれていることもあるようです。
また、メリットから見ていきます。
細かい設定が可能であることと、アイキャッチ画像をそのままサムネイルにできることは
ここプラグインのとても魅力的な要素の一つです。
しかし残念ながら、デメリットもあります。
二つ目の初期設定の大変さはほかのどのプラグインよりもとびぬけているように見えました。
とても難しいことをしているわけではないのですが、とにかく設定に時間がかかってしまうのが欠点です。
しかし、細かく設定できる分大型の自動化を行う企業のような場合では
とても大きい威力を発揮するのではないでしょうか。
またメリットから見ていきます
このプラグインは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種類の拡張機能を使い分けをしないと
重くて遅くなることがあるので注意が必要です。
2018.07.27
どのような企業であっても欠かすことのできない重要な業務の一つが、「資金管理」です。
「黒字倒産」という言葉があるように、どんなに業績好調の企業であっても、資金繰りには常に神経を尖らせていることでしょう。
資金繰りがスムーズに流れていくよう管理するためには、出金の金額とタイミング、入金の金額とタイミングを、
できるだけ早く、できるだけ正確に、できるだけ漏れなく、情報収集する必要があります。
資金管理は、大企業であっても中小企業であっても、非常に重要な業務であることに変わりはありませんが、
ここでは「財務部」という独立した部署が存在しない中小企業を想定して考えていきましょう。
そのような場合、一般的には「経理部」の担当者が、日々の経理業務に追われつつ、資金管理にも対応していくことになります。
また、中小企業の場合、社長と一部の役員のみで企画開発や営業の業務に対応していることがあるかもしれませんが、
ここでは「事業部」として複数名の社員がいる企業を前提としています。
自社の商品やサービスを売り込むためには、さまざまな資料づくりに励まなければなりませんし、
より良い取引先を選定して部品等を仕入れていく必要があります。
取引先と進めているプロジェクトは、機密事項が多く、外部だけでなく、
社内でも関係者以外には情報漏洩しないように神経をすり減らしているかもしれません。
プロジェクトの対応を進めていく過程で、原価や経費の支払いが発生します。
その際、取引先から受け取った請求書の原本を経理部へ提出するだけで終わればそれほど煩わしくはないのですが、
請求書１枚ごとに「支払依頼伝票」を記入し、上司の印鑑やサインをもらった上で経理部へ提出しなければならないため、
これが意外と面倒な作業になっているのではないでしょうか。
「事業部」の社員からすれば、「支払依頼伝票」の作成にどれだけ時間を割いても、売上金額や取扱金額が増えるわけではありませんから、
できることならこのような社内業務は極力簡単に済ませたいものでしょう。
その上で、契約獲得のために時間を有効活用していきたいのではないでしょうか。
あるいは、取引先からいろいろな要望があれば、すぐにでもその対応に取り掛かりたいと思っているかもしれません。
逆に、ご契約をいただき、売上計上する場合はどうでしょうか。
「やっと契約までたどり着いたぞ！」と喜んでいると、上司からすぐに指摘されます。
「入金伝票を回しておいて」と。
「入金伝票」（あるいは「売上伝票」）を事業部から経理部へ提出することで、
経理部が請求書を発行し、角印を押した請求書原本を今度はこちらから顧客先へ持っていく必要があります。
事業部の社員からすれば、「出金伝票」にしろ「入金伝票」にしろ、それらは社内向けの業務ですから、
「こんな作業は、経理部のほうで対応してもらえないかなあ？」と思っているかもしれません。
あるいは、「できることなら、もっと簡単にしてほしい」と願っていても、
経理部もかなり少ない人数で対応していることから、なかなかそのことを相談する機会がないかもしれません。
「経理部」では、日々発生する資金の出金や入金を１件ずつチェックし、経理ソフトに入力していきます。
ときには、内容不明の入金があるかもしれません。
その場合は、まずは該当しそうな社員に聞いていきます。
社内で原因が特定できれば、その時点で追加仕訳や修正仕訳を行い、経理ソフト上の現金・預金の残高と、
実際の現金・預金の残高を一致させます。
でも、社内では原因を特定することができなければ、やむを得ず取引先の担当者に聞かなければならなくなります。
「申し訳ございませんが、この入金は、どのような内容のものでしたか？」と。
逆に、取引先から振込み手続きの催促を受けることがあるかもしれません。
急に取引先の担当者から経理部へ連絡が入り、
「昨日が期日の請求書を発行しておりましたが、まだ入金が確認できません。どうなっていますか？」と質問されます。
穏やかに催促されることもあれば、厳しく指摘されることもあるでしょう。
このような場合、経理部のミスであれば、速やかに振込み手続きを行い、
次から同じようなミスをしないように反省しなければなりませんが、
むしろ経理部に過失がない場合のほうがこのあとの対応が大変です。
日々の業務をいったん脇に置いて、速やかに社内で原因究明に取り掛からなければなりません。
ようやくある社員が請求書の提出を忘れていたことが判明したとき、
経理部担当者としては、まずは上司に至急振込みすべき内容であることの裏付けをとった上で、
取引先にお詫びの電話をしなければなりません。
「すみませんでした。こちらの手違いで、まだ振込みができていませんでした。明日中に、必ず振り込みます」と。
内心は「私は何も悪くないのだけどなあ」と思っていたとしても、会社としてのミスですからやむを得ません。
それでも、取引先から催促されることのほうがよい場合もあります。
手形決済日に万一資金ショートしていたら…。
想像するだけでも背筋が寒くなってきます。
このような企業の場合、どこに問題があるのでしょうか。
「慢性的な人手不足」と言えるかもしれませんが、仮に社員を増やしたとしても、
作業の流れが今までと変わらなければ根本的な問題解決には至らないかもしれません。
つまり、今までのやり方に慣れてしまっているため、社内業務の改革が後回しになっていることが問題と言えるのかもしれません。
多少作業効率が悪くても、大きな問題になり得ない社内業務であれば、むしろ「改革」などしないほうがよいこともあるでしょう。
でも、「資金管理」は失敗が許されませんので、
失敗するリスクを極力なくしていく工夫が一刻も速く求められているのではないでしょうか。
そこで、出金伝票（支払依頼伝票）、入金伝票（売上伝票）を自動集計するRPAを提案したいと思います。
「事業部」の社員からすれば、「内向き」なこれらの伝票作成業務は、できるだけ簡単なものであってほしいと願っています。
また、「経理部」の社員からすれば、これらの伝票が速く正確に、しかも漏れなく回収することができることを願っています。
RPAを導入することで、「事業部」の社員のところで情報を停滞させることがないように、
すぐに「出金」や「入金」を「経理部」へ知らせることができるようにしていきます。
具体的には、「出金」専用のメールアドレス、「入金」専用のメールアドレスを設置し、
それぞれに請求書や契約書等の画像を添付した上でメール送信することが考えられます。
あるいは、「メールの送受信」という行為にリスクがあると判断すれば、
クラウド上に「出金」専用ファイル、「入金」専用ファイルを立ち上げ、
「金額、期日、取引先、内容」をすぐに入力できるようにすることも考えられるでしょう。
出金と入金の情報はトップシークレットなものですから、
絶対に外部へ漏れることがないように細心の注意を払っていく必要があります。
これらの入力情報をRPAが自動集計することで、
「いつ、どれだけの金額を出金しなければならないか、入金されてくるか」をより早く、より正確に管理することが可能となります。
もちろん、これらの集計情報は権限のある一部社員のみが見ることができるように設定する必要がありますので、
一部社員の負担とならないよう、RPAでできることは極力RPAに委ねていくことが重要です。
また、取引先から事業部の担当者に渡された請求書原本は、経理部へ持っていくだけでよいこととします。
クラウド上に入力された情報をもとに、自動で「支払依頼伝票」が作成できるようにしておけば、
経理部としては「請求書原本が提出された伝票と、まだ提出されていない伝票」というように管理しやすくなります。
その上で、急ぎの案件でなければ、例えば一週間に一度、
事業部の上司にまとめて経理担当者から「支払依頼伝票」を提出し、上司にサインしてもらうことも可能となるでしょう。
「資金管理」のポイントは、いかに速く、いかに正確に、いかに漏れなく、
出金と入金の情報収集を行うことができるかどうかにあります。
これはまさに、RPAが得意とする分野です。
資金管理は失敗が許されない分、より多くの企業で導入する価値のある業務と言えるのではないでしょうか。
2018.07.26
BizRobo!は国内のRPAのパイオニア企業であるRPAテクノロジーズが展開しているRPAサービスで、
2008年よりサービス提供を開始しており現在国内で最も運用実績のあるRPAサービスです。
そしてSynchRoidはソフトバンクが2017年より提供しているRPAサービスで、
手厚いサポート体制で近年ユーザ数を急激に増やしています。
SynchRoidはRPAテクノロジーズと提携したOEMの形で販売しているので、実際使用しているRPAツールはどちらも一緒です。
本日はユーザ数の多いこちら２つのサービスで使用されているRPAツールについて徹底解説していきます。
BizRobo!はRPAツールの名前だと思われている方が多いと思いますが、
BizRobo!はあくまでサポート体制なども含めたRPAテクノロジーズのサービスブランド名でRPAツール名は「BasicRobo」となっています。
またRPAテクノロジーズがRPAツールを自社開発しているわけではなく、
米Kofaxが開発した「Kofax Kapow」の日本語OEM製品が「BasicRobo」です。
また、Kofaxの日本法人からライセンスを購入することも可能で日本では三菱UFJ銀行がそれにあたります。
便宜上、以下から呼称を「BasicRobo」に統一して説明していきます。
・開発環境がほぼ無制限に使える
BasicRoboはDesignStudio(以下DS)という開発ツールがあり1ライセンスあたり10端末までの同時稼働が可能です。
しかしこれはあくまで同時稼働の場合の制限であり、
同時稼働でなければ全社員の端末にインストールして全員がRPA開発を行えるようにするといったことも可能になります。
・ユーザーインターフェースを見ながら開発ができる
一般的なRPAツールでは開発フローの中にコマンドをドラックアンドドロップで配置して開発するものが多いですが、
BasicRoboではレコーディングでの開発がデフォルトになっています。
開発画面の中に対象となるインターフェースが専用ブラウザから見れるようになっているので、
プログラミングを組むという感覚よりはいつも行っている作業を専用ブラウザの中で行うといった感覚で実装することができるので、
非エンジニアの方にとってはかなり馴染みやすい開発インターフェースとなっています。
・日本語でサポートできるエンジニアが多い
BasicRoboは国内で最も運用されている歴史のあるRPAツールなので日本語でサポートができるエンジニアが最も多いとされています。
RPAツールを比較検討する際に単純なツールのスペックだけでなくこのようなサポート体制の充実度が重要な指標になります。
なぜなら、RPAツールの導入した段階ではまだ何も自動化されていない状態なので、
ツールを使ってどれだけ自動化していくかが重要だからです。
導入後に自動化を進めていく際に日本語サポートの多さは必ず必要になるはずです。
もちろん英語でのサポートでも構わないのであればUiPathやBluePrismも大差はありません。
・全体的に高額
BasicRoboは初期のトライアルや小規模導入・本格導入や運用に至るまで全体的に高額です。
まずトライアル段階ですが、基本的には無料のトライアルプランが用意されていません。
UiPathが無料のCommunityエディションを提供していたり、
WinActorが多くの企業に無料トライアルを実施しているのと比較するとトライアルが有償というだけでもハードルは高いです。
ライセンス費用ですが、ソフトバンクのSynchRoidのライトパックがデスクトップ単位で購入することができ、年間90万円となっています。
サーバ型ライセンスの場合は初年度770万円（うち、初期費用50万円）で2年目以降は年間720万円のライセンス料金です。
他のエンタープライズ向けのRPAツールでも年間500万円程度のライセンス価格が相場なのでこちらも割高だといえます。
サーバー版のライセンスを購入すると開発ツールが10ライセンスと管理機能、サーバーでのプロセス同時実行が可能になります。
プロセス同時実行はライセンスによって制限されており、だいたい４プロセスまでが目安になっています。
（実行するプロセスの負荷によって増減します）
同時実行の制限はサーバスペックによるものではなくライセンスによって制限されているので、
10～20のロボットを同時実行したい場合はそのぶんのライセンス購入が必要です。
・デスクトップアプリの開発が難しい
BasicRoboは元々WEBのクローリング用に開発されたツールです。
そのためWEBの自動化の際には専用ブラウザで対象インターフェースが確認できるなど非常に開発がしやすくなる機能が豊富です。
一方でWEB以外、つまりデスクトップアプリには対応していなかったのですが、
2017年にDevice Automation(以下DA)という機能をリリースしデスクトップアプリの自動化にも対応しました。
しかしこのDAのインターフェースがDSと違い開発の方法も異なるので、
開発者は全く別のツールを一から覚えなおす必要があります。
また、機能としてもできたばかりなので他のツールと比較するとデスクトップアプリの開発にはあまり向いていないといえます。
・対応できないシステムが多い
BasicRoboは専用ブラウザをもっているので開発しやすいのですが、
そのぶん対象システムがブラウザに対応していないといった場合がよくあります。
例えば自動化例の定番として事例の多いSlackなどはBasicRoboの専用ブラウザに対応しておりません。
また、画面の認識方法はソースコードを読み込んで認識するので安定性はあるのですが、
JavaScriptが多用されているシステムなどは相性が悪く認識できないことがあります。
具体例をあげるとGSuite系のサービスとは相性がよくありません。
・拠点をまたいで大規模導入する場合
基本的にサーバ型での運用が前提のツールなのでいくつも拠点をもつような大企業で導入を進める場合は、
BasicRoboを導入することで最初から管理運用フェーズを見据えたRPA導入を進めることが可能です。
また、DSがほぼ無制限に使えるため大規模に導入する場合はほかのツールより費用を抑えることができる場合もあります。
・現場作業者による開発を前提とする場合
前述のとおりBasicRoboは非エンジニアでも開発がしやすいツールなので、
現場で実際に作業をしている人が自動化を実現しやすいです。
なので現場開発を前提とする場合はBasicRoboの導入が有効だといえます。
逆に以下のような場合は利用するメリットがないかもしれません。
主な特徴は以下の通りです。
製品やサービスは今後アップデートされていきますので弱点が補われたり、
機能が追加される可能性があるので実際に導入を検討される際には販売店にお問い合わせください。
また、2019年5月に東京ビッグサイトで開催される展示会への出展が決定しました。
当日は、RPA導入に関する無料相談会を実施いたします。無料相談会をご希望の方は、是非こちらからご予約ください。
2018.07.25
現段階における国内のRPAの浸透はようやく一合目を超えた程度。
最近では、大手企業でなく、中堅企業の導入の検討もはじまり、
また地方自治体など公共における導入の話もちらほらと聞かれるようになりました。
私はこの中堅企業、公共のRPA導入までも山の中腹あたりと考えているのですが、
この一合目を超えた事実は、我々RPAの普及を願う業者にとって大いに奮い立つものである。
と言うのも、公共は横並び意識が強いため、どこかが始めたら全体がその道にならうであろうと誰もが思っている。
そして中堅企業にとっても、RPAが採算に合うと分かれば一気に導入が進む可能性が十分にある。
一合目から中腹までは意外と早いものである。
では、中腹から広がる原野は何か？
それは日本の大部分を占める中小企業群であり、
以前から訴えているようにRPAは本質的に中小企業を救う技術という信念を持ちRPA普及に努める私にとっては、そこからが本番。
そして最も困難な道のりの始まりということになる。
中小企業にとってのRPA導入についての障壁。
先日はその心理的障壁、中小企業社長のITリテラシーの低さと新しいビジネス技術への潜在的な不安を記事として取り上げたが、
今後一番のネックになるのは、もちろん導入コストであろう。
当社の導入コンサルティングの実績からも、大企業と違いスケールメリットが出にくい中小企業の場合、
例えば定番の経理業務で2～3名の経理スタッフで運用しているような典型的な規模であれば、月の業務効率化で0．5人工程度の場合が多い。
金額にして10～20万円ていどの削減か。
これがコスト削減として多いか少ないかは分からないが、RPAのライセンス費、最低限のメンテナンス費が毎月発生する中、
中小企業向けの安価なパッケージを開発し低価格化に挑戦したとして、
月のRPA導入金額として10万円を下回ることは現時点では大変な困難であると思われる。
そうすると、０．５人工削減の対価が１０万円では中小企業としては割りが合わないだろうし、
そもそも人であれば（あくまで個人の能力に大いに依存することになるが）マルチタスクを含む柔軟な活用があるだろうし、
この事実だけをもってしても中小企業がRPA化に前向きになることは当分ないのではと考えてしまう。
また最大の障壁として、仮にコスト削減できたとして、その人員をリストラすることはほぼ不可能であるという事実。
大企業であればリストラという名目で大量に解雇もあるのだろう。
しかし顔の通じた中小企業で事業順調の中でリストラというのは実はとてもハードルの高いものだ。
また０．５人工削減できたからと言って、うまく人間の半分だけ０．５人工分リストラすることなどもちろんのこと不可能だ。
そんな中小企業のRPA導入に対する一抹の不安を抱きながら、エンジニアと食事をしていた時だった。
現在当社では大手中堅向けのRPA開発受託が順調に進み、
また公共部門における入札の増加など、ポジティブな話が多く社内も盛り上がっている。
しかし、前述のようにもともと私の夢は、これからの人口減社会において、
本当に苦しい戦いを強いられる優良中小企業の為、働き方改革実現の為のRPA事業。
中小企業の導入という五合目以上の実現をいつも意識している。
何気ない会話の中で、エンジニアから出た一言が私の気を引いた。
「欧米では中小企業もインハウスエンジニアを持つのは当たり前ですし、社内システムは基本的には自社でつくるものですよ。」
システムと言えば外注が当たり前のこの国で会社経営している身にとっては、はじめて聞く情報。
だが、考えれば考えるほど、それが合理的であると思った。
特に大企業と違い業務の標準化が進んでない中小企業がパッケージを導入しようとして失敗するケースはよく聞くし、
そもそもITリテラシーが一般的に低い日本の中小企業の社長にとって外部のシステム業者と会話するのは、
その尊厳を脅かす多大な苦痛を得ることだろう。
そんな諸々の状況から日本の中小企業のIT化は遅れているのだが、それが社内で開発が出来るとなれば話が違う。
現在、情シス担当がいる中小企業は、IT系か、それでなければ上場準備の為の雇用か、
いずれにしろ一般的な中小企業の定義からは外れる。
なぜ欧米と違いインハウスSEが少ないのか？
技術者が足りないのだろうか？私はそうは思わない。
システムエンジニアの採用は、ここ２０～３０年絶え間なく行われ、アーリーな開発者は既に定年の年になっているほど。
もちろん最先端の技術を修得した若手となれば限られるが、国内におけるIT技術者の数は私たちが思っている以上に多い。
そして、そのキャリアのスタートとして大手企業に勤めた彼らも、その後は転職などを繰り返し、
中小企業でも十分に雇用できる状況、条件に身を置く技術者はたくさんいる。
むしろ、明日をも知れぬ開発プロジェクトの連続で流浪の民と化し年を重ねた彼らは、
中小と言えど事業会社の情シス、インハウスエンジニアという立場は願ったりかなったりの職ではないだろうか。
それでも増えない理由は、中小企業側にあるのだろう。
社内にIT技術者を抱えることに対するメリットが見えない。
そもそもIT技術者とか高そう。
ここでもハードルはやはり中小企業経営者のリテラシーの低さだ。
だったら、新規雇用をするのではなく、社内の誰かがITエンジニアになるのだったらどうだろうか？
社員の付加価値かは前向きな中小企業にとって受け入れられやすい提案である。
しかし誰がエンジニアになれるのか？
そもそも、そんなに簡単にエンジニアになんかなれないだろう。
いえ、RPAだったら、それが可能なのです。
RPAは文脈から、どうしてもこれまでのコンピューター言語の系譜でとらえられがちだが、
その実、技術としてはエクセルなどのオフィス製品に近い。
これはプログラムの素養がなくとも、エクセルが使える経理、もしくは総務スタッフなど、
どの中小企業にもいる社員で修得が可能なレベルの技術である。
だが、その先の出来ることの広がりは果てしない。
RPAを修得すれば、これまでただの経理だった女性が、会社の経営レベルで効率化を考え、
実践する強力なスタッフへ進化することも不可能ではないのだ。
人件費を削減する、のではなく、人材に付加価値をつける。
それも人件費は一切増えないままに。
中小企業の求めているのは、まさにそれだ。そしてRPAの未来だ。
２０年前、WEBサイトの構築は一大事業でした。
またWEB制作だけで大儲けというバブルな会社が一気に増えました。
しかし、今ではどうでしょう？
ワードプレスなどの発達によって、コーポレートWEBサイトは自分たちで作ってします会社も少なくない。
それこそ、WEBまわりの技術のインハウス化は規制の事実であるし、もちろん中小企業も同じくだ。
中小企業に対しては、RPAの開発を受託するというこれまでの発想では、普及は難しい。
だったら、中小企業のインハウスにRPAエンジニアを育てることで、RPAの普及を進めよう。
そう思った瞬間に、中小企業のRPA化、働き方改革についての道が開けた。
当社では、中小企業向けの「RPA自走化プログラム」を提供しています。
まずは教育、選抜の御社社員を３か月で立派なRPAエンジニアに育てます。
そして御社業務の効率化、RPAエンジニアに育った社員と共に、当社が提供する経理などの効率化パッケージを御社仕様にアップデート。
その後は格安の月数万円で御社にあったツールをお使いいただけます。
最後にアフターメンテナンス、御社社員からのRPAに関する問い合わせはいつでもお受けします。
これからは、社内ITエンジニアの時代。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ユーザ（従業員）と直接コミュニケーションを取りながら、
プロジェクト目標である業務削減時間についての管理・報告義務を担うため、非常に重要な役割を担います。
運用チームでは、RPA導入後の運用が定着するような仕組みを検討します。
例えば、開発したロボットが何らかの理由で故障した場合のユーザからの問い合わせ管理方法等があげられます。
ユーザから寄せられる問い合わせを管理し、それらを社内ノウハウとして蓄積するための仕組みを構築することも重要です。
こうした運用を検討するにあたっては、ユーザ部門になるべく負担のかからないようにする視点を持つことがポイントになります。
なぜなら、RPAを導入しても、その後のフォロー体制が煩雑だと、
結局従来通りの業務のやり方のほうがやりやすいと感じてしまい、その場合RPAは宝の持ち腐れとなってしまうからです。
環境構築チームでは、RPA導入に必要なサーバやロボットの開発/実行（起動）PCの設置、RPAのライセンス管理等を検討するチームです。
また、RPAツールによっては、①単体のPCにインストールして個別に管理する方法（いわゆるRDA=Robotics Desktop Automation）と、
②サーバで集中管理する方法（サーバー型RPA）があり、どちらを採用するかは企業の規模や管理方針に則って決める必要があります。
環境構築チームで検討する内容は、情報システム部門やセキュリティ部門と調整しながら進めていくことが多いです。
また、導入するRPAツールが決まっていない場合は、環境構築チームがRPAベンダーへのヒアリングからRPAツールの選定を行います。
参考として、RPAツールの選定ポイントをあげます（『まるわかり！RPA』（出版社名：日経BPムック）89頁より引用）。
大きく以下の4点が挙げられるようです。
保守チームでは、RPAの本格導入後の窓口業務としての役割を担います。
具体的には、新たにロボットを構築する場合や、何らかの理由でロボットが起動しなくなった場合の対応等を行います。
また、リリースチェックといって、構築/改作したロボットを使用する前に、
ロボットの内容をチェックする品質管理の役割も担います。
保守チームの運用方法として「アウトソーシングするパターン」と「社内人材を利用するパターン」がありますが、
後者の場合、保守を担当する社員はRPAの知見を有する必要がある為、事前に研修を計画するなどの検討が必要になります。
最後に、RPAの運用を定着化させるための各成果物について紹介します。
いかがだったでしょうか。
RPAを全社導入する前に心がけるポイントや
各チーム組織の概要、役割を中心にお伝えしました。
導入前のTIPSとしてお役立ていただければ幸いです。
2018.07.23
今回はRPAツールのひとつ、Automation Anywhereについて紹介します。
Automation Anywhereは、アメリカのサンノゼに本社を置くAutomation Anywhere社が提供するRPAサービスです。
創業は2003年。全世界で1000以上の企業に利用されており、大規模導入の実績を多く持ちます。
日本では2017年から日本IBM、日立ソリューションズなどのパートナー企業がサービス提供しているのに加え、
2018年3月にはAutomation Anywhere日本支社も開設、国内での本格展開が始まっています。
同社が提供するRPAサービスの名称は「Automation Anywhere Enterprise」です（2018年7月時点のバージョンは11）。
基本構成は以下の3つです。
ロボット作成はBot Creator上で行います。
レコーディング機能のほか用意されているコマンドからメッセージ表示などの動作を設定することもできます。
管理はControl Roomで行います。
RPAのロボットは、大きく分けて各PC上で動くタイプと、サーバ上で動くタイプの2種類あります。
サーバ上で動くタイプは管理のしやすさやユーザー管理ができるといったセキュリティ上の利点から大企業で多く導入されています。
Automation Anywhereはこちらに分類されます。
Automation Anywhereの特徴は、
といった点が挙げられます。
国内では、横河電機が2017年にシステム登録業務の自動化などを目的としてAutomation Anywhere Enterpriseを導入、
月30時間の作業工数を月4時間に削減したと発表しています。
参考：TIS、RPAを活用した横河電機の本社業務の生産性改革を支援（TISリリース）
https://www.tis.co.jp/news/2017/tis_news/20171121_1.html
サントリーグループでは2017年に働き方改革の一環としてAutomation Anywhere Enterpriseを導入、
データ収集・加工やメール作成に40体のロボットが稼働、定型業務を代行させています。
参考：ロボット40体がルーティンを代行！3.5万時間の削減を目指す、サントリーの働き方改革
出典
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
2018.07.23
直近で地方自治体におけるRPA導入のポイントについて述べられていたので、
地方自治体BPOとRPAがどのように繋がっていくのかを何回かに分けて述べていきたいと思います。
本日は概要部分です。
本日のコラム担当は複数の地方自治体での業務経験があるので、実例を交えていきますが、
あくまでも私が知っているその一面のみになりますので、
こういうケースもあるなどあれば、こちらよりお知らせいただければ幸いです。
地方自治体がBPOを積極的に活用するようになったのは、
２００６年に内閣府公共サービス改革推進室が中心となって制定された公共サービス改革法の交付が要因の一つであると言われています。
正式な名称は「競争の導入による公共サービスの改革に関する法律」と、
内容については想像しやすいと思いますが、総務省にある概略は下記の通りです。
“国の行政機関等又は地方公共団体が自ら実施する公共サービスに関し、その実施を民間が担うことができるものは民間にゆだねる観点から、これを見直し、民間事業者の創意と工夫が反映されることが期待される一体の業務を選定して官民競争入札又は民間競争入札に付することにより、公共サービスの質の維持向上及び経費の削減を図る改革（競争の導入による公共サービスの改革）を実施するため、その基本理念、公共サービス改革基本方針の策定、官民競争入札及び民間競争入札の手続、落札した民間事業者が公共サービスを実施するために必要な措置、官民競争入札等監理委員会の設置その他の必要な事項を定める。”
簡単にまとめると、民間競争入札によって透明かつ公正公平な競争と民間による創意工夫により良質な住民サービスが安価に提供できるための法律です。
もっと簡単に言えば、民間にできることは民間に任せたら、サービスも向上するし、経費も削減できるのではないかということです。
今まで地方自治体が民間委託をしていなかったわけでなく、アウトソーシングという形では民間委託していました。
例えば、給食センター運営やスポーツセンターの管理などです。
しかし、ビジネスプロセスアウトソーシング（BPO）という形では民間委託は少なかったかと思います。
地方自治体の職員が行う業務のうちでBPO化できる事とできない事の選別は難しく、
法律や住民も関係してくるので意外と悩ましいところです。
業務を大雑把に分類すると、単純業務と専門業務、定型業務と非定型業務、
それ以外に公権力の行使と政策立案など公務員しか出来ない専権業務の５つに分類することができます。
その中で単純定型業務をまず民間に委託するところからスタートしました。
余談ですが、アウトソーシングとBPOの違いを聞かれることがあります。
BPOはアウトソーシングの一部であり、例えていうなら、
出前を頼むとアウトソーシング、自分で作るけど材料だけは注文して配達してもらうとBPO、
そういう違いという説明を良くします。
BPO事業者に在籍していた筆者は、地方自治体の職員に対し、
「最高の材料を用意することはできますが、場合によっては下味まで付けることも出来ます。
でも最後に料理するのは職員の方なので、職員の方の腕次第です。」
と言ったことがあります。
それに対して地方自治体の職員の方が「それでも失敗するのが公務員、何から何まで準備されても何もしないのが公務員」と言われ、苦笑いをした記憶があります。
どのような業務が民間に委託されていったかというと代表的なものは窓口業務です。
ある自治体職員の方が言うには、「上（首長や局長など）の人間は、国鉄が民営化（JR）されて、駅員の対応が良くなったと評価されたから、それくらい期待したのでは？」と言っていましたが、皆様のお住まいの市役所や区役所はどうでしょうか？
この１０数年で対応が良くなったでしょうか？
民間委託している窓口と民間委託していない窓口の簡単な見分け方法としては制服です。
制服を着用している場合は民間委託している可能性が高いです。
制服を用意していない場合は、ネームホルダーなどで民間委託されているかどうか判断はしやすいかと思います。
全ての自治体が窓口業務を民間委託していることもなく、
案内（フロア）係だけを民間委託しているケースなど自治体によって窓口業務の民間委託は千差万別です。
ある地方自治体に行けば、時間帯によっては、案内（フロア）係の方が来庁している住民よりも多いようなこともあります。
ではなぜ窓口業務からなのかというと、下記リンクにある通り、内閣で閣議決定され、特に窓口業務については、民間委託を推奨しているからです。
「経済財政運営と改革の基本方針2015 ～経済再生なくして財政健全化なし～」（骨太方針）
内閣府のホームページには優良事例集まで作っています。
実際、現場で窓口業務の委託を行った地方自治体の職員の方に聞くと好評なことが多く、市民の方からも好評なケースが多いです。
ごく少数ですが、民間業者の人間に個人情報を見られたくないとの批判もあり、
地方自治体職員がBPO化するにあたって、民間委託して個人情報がちゃんと取り扱われるのだろうかという点を不安視しています。
実際に民間委託して、BPOオペレーターが友人の情報を見て、
その友人に教えたではないかということは過去にあったという話は何度か耳にしています。
情報の流出というのはどの業界どの分野でもゼロにすることは難しく、限りなくゼロに近づけるしかないのですが、
そういった点ではRPAをうまく活用することで防ぐこともできたかと思います。
窓口業務を委託する課としては、来庁者数が多い課、代表的なのは市民課です。
国民健康保険課も来庁者は多いのですが、国民健康保険課の窓口業務の民間委託は進んでいないのが現状です。
それは国民健康保険課の業務内容が単純ではなく専門業務に分類されるからです。
一般的に国民健康保険課は国民健康保険だけを扱う部署ではなく、後期高齢者医療保険も扱っており、
各保険で運営が異なっており、使うシステムも違い、更に制度も多い分野で、難易度が高い業務と言われています。
地方自治体によっては、国民健康保険課と後期高齢者医療保険課に分けている地方自治体もあります。
複数の地方自治体の職員に聞くと健康保険課は業務範囲が広く、覚えることも多い、
また窓口の対応も難しいから民間委託したいが、どのように民間に委託すればよいのか分からず、
民間委託が頓挫したなんて話も耳にします。
窓口業務以外にも単純で定型業務である事務だと封緘封入作業などもよく委託される業務の一つです。
探せば色々あり、地方自治体BPO業務は拡大の一途をたどることになり、
ある調査では2019年度の市場規模は3兆9,883億円になるとも言われています。
具体的にはどのような業務がBPO化されたかというと、税金や水道料金などの徴収業務です。
比較的最近だと各自治体に置かれたマイナンバー関連のコールセンターも民間委託されていました。
今まで述べてきた窓口業務や事務業務は単純業務の範囲内のもので、単純定型業務の一つとして委託されていました。
しかし、地方自治体BPO業務は拡大し、現在は、単純業務から専門業務、定型業務から非定型業務分野のBPO化をどのようにすべきか検討段階に入っています。
専門業務や非定型業務をどのようにBPO化すればよいのか悩んでいる自治体の職員の方からご相談を受けるケースは多々あり、
多くの地方自治体の職員はこのあたりで頭を悩ませているようです。
行政事務のノウハウはそもそも民間にはなく、民間委託して失敗した事例も良く聞きます。
RPAもBPOの一部ですが、RPAをどのように導入するのか考えるのも地方自治体職員の課題となりそうです。
次回へ続く
2018.07.20
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」などの
仮想化ソフトウェアもあります。
今回はシトリックスのデスクトップ仮想化について見てきました。
多くの人数でプロジェクトを進める際などに、デスクトップ仮想化を行うことでデスクトップの管理などが楽になります。
しかし、このデスクトップ仮想化には利点だけではなくて、
デメリット・注意点などもあるのでそこもしっかりと確認しておきたいところです。
2018.07.10
RPAによる業務の効率化は、ここ数年で飛躍的に普及しています。
今後もますます拡大していくことでしょう。
自社でもRPAを導入して業務の効率化を図ろう、と考えている方も多いと思います。
ですが、急速な拡大は大きなリスクも孕んでいるのが世の常であり、
RPAによる業務効率化も同様にリスクを伴っている、と私は考えています。
特に、RPAのロボットの管理・運用において社内での統制が取れていないと、せっかく業務の効率化のために作成されたシステムが有効に活用されず、宝の持ち腐れとなる可能性があります。
システムの開発を外部に委託できればいいかもしれませんが、運用を外部に丸投げできる会社はごく一部でしょう。
それらの会社を除けば、RPAの基本的な管理・運用は先ず自社の現場担当者が担うこととなることがほとんどです。
現場担当者になることで一から覚えようと前向きに考える人もいれば、面倒な業務が増えたと面倒に感じる人もいるでしょう。
担当者がどう思うかは人それぞれですが、確実に言えるのは、導入を決定した人、
あるいは現場担当者がRPAの構造を知らないと、導入は失敗に終わることとでしょう。
そうならないためにも、RPAに関する知識を身に着ける必要があると考えています。
以前、他の記事でも、RPAを導入したものの、管理体制の不備における、RPAの「野生化」として警鐘を鳴らしている記事がございました。
■参考記事
生保や銀行で急速に普及する事務作業「ロボット」 保守怠ると“野生化”の恐れもhttp://www.itmedia.co.jp/business/articles/1807/03/news023.html
この記事を拝見し、以前勤めていた会社のことを思い出しました。
以前の会社で事務処理の合間に現状の業務をマクロ・VBAを用いて業務効率化を進めてきましたが、
ほとんど個人で使用する為の開発しかしていませんでした。
他の社員が行っている業務の効率化のために開発したこともありますが、改修・管理はこちらで行っていました。
全員のPCにMicrosoft Office（Excel）が入っていたにも関わらず、実際にマクロやVBAを使って業務の効率化を考えていた人はわずかでした。
私個人としても、開発する時のルール等は特に考えずに作成しており、管理・運用のドキュメントも作成していませんでした。
ですが、転職先が決まって後任に業務を引き継ぐとなった時に、今まで作成したVBAの成果物も引き継ぐこととなりました。
マクロどころかExcelの関数も満足に扱えない人へ引き継ぐこととなりましたが、
とりあえず最低限の仕様変更の仕方を伝えることしかできませんでした。
後任者も、開発に関する知識がなかったこともあり、「ソースコードを見ただけで眩暈がする」と嘆いていました。
とりあえず体裁上は引き継ぎを完了としましたが、そのような形での引継ぎであったため、
もしかしたら、今はシステムが有効活用されておらず作業効率の低下を招いている業務があるかもしれません。
せっかく作成したシステムを管理・運用を怠って過去の遺産とさせないために、
現場等で適切に管理・運用する能力があれば、社内のシステムを最大限活用できるわけです。
新たにRPAの導入を考えている方だけでなく、今後プログラミングやシステム開発といった、
ITに携わりたいという方への心得として、システムの管理・運用に必要なことを取りまとめました。
すでにご存じの方には、自身の行動と照らし合わせて振り返ってみてもいいでしょう。
特に、丸ごとアウトソーシングするのが困難で、
システム開発を個人で行うことが多い中小企業の現場システム担当者の方は知っておいた方が良いと思います。
大規模プロジェクト等、複数名で開発する場合であれば必ず行っていることですが、
もし、一人で開発、運用する場合でも、必ずルールを決めて開発を進めてください。
自分なりのローカルルールでも構いません。
ルールを決めずに開発した場合、開発した当初は自分で把握していても、時間が経って改めてソースコードを見た時に、
そのソースコードが自分でも何をするためのプロジェクトかわからなくなってしまい、
最悪の場合一から作り直しになってしまいます。
これを防ぐために、個人で開発する時でも必ず自分なりのルールに基づいて開発をするようにしていきましょう。
もしルールを忘れてしまうようであれば、別途資料を作成しておくことも重要です。
当たり前のことと思いますが、意外とできていない方が多いように思います。
引き継がれたシステムは当時の担当者のルールの色が強くでています。
引き継ぎに関するドキュメントが丁寧に作られていたとしても、読むだけでも多くの時間を取られてしまいます。
個人で開発する場合、そのプロジェクトがどのような流れで遷移しているかを考えながら開発します。
その場合は、先ほどの「ルールを設けて運用する」ことが重要ですが、
今後社内の資産として適切に運用していきたいのであれば、どこかで必ず他の人に業務を引き継ぐ必要があります。
前任者は引き継ぐ時に、そのシステムがどのような流れを取っているかを説明する義務があります。
これができず、後任者が理解できなければそのシステムが適切に運用される可能性はかなり低くなるでしょう。
第三者へ説明するためのおすすめの方法としては、前述の、「ルールを設けて運用する」と合わせて、
開発と同時に第三者へ説明するためのドキュメントも作成してしまえば、
引き継ぎ時だけでなく、改修依頼等があった時も役に立つでしょう。
開発が終了したプロジェクトを長期間放置してはいないでしょうか。
大規模なプロジェクトや他社が開発したプロジェクトの見直しは困難ですが、
自社開発した小規模のプロジェクトを見直すことは、非常に重要であると考えています。
例えば、開発中に、必要な機能の中の一部がどうしても作成できなかった、あるいは妥協し、最終的に運用の仕方で解決してしまった機能というのがあったとします。
ユーザーが納得してくれれば会社としてはいいですが、エンジニア個人としては、非常に悔いの残る結果となります。
ですが、以前開発したプロジェクトのソースコードを改めて読み解くと、以前は妥協して作れなかった機能を実装したり、
煩雑化していたコードを改修して管理・運用しやすくなったというケースは多々あります。
たまたま、以前開発したVBAの改修の必要があったため、開発したプロジェクトのソースコードを一から見直したことがありました。
そのコードを読み解いていると、当時の自分が複雑な書き方をしていること箇所が多かった、と気づきました。
それらを改修することで、より理解し易く、管理しやすいプロジェクトとして回収することができました。
特に私の場合、以前自ら作成したソースコードを読んで改修できる個所を発見できると、
「俺も成長したなあ」と日々の成長を感じながら改修作業をしています。
完全に自己満足の領域ですね（笑）
上記いろいろと書きましたが、「どれもすべて、仕事をするうえで当たり前のことじゃないか。」と思う方も多いと思います。
まさにその通りで、システムの管理・運用といっても難しいことはほとんどなく、やり方さえ覚えてしまえば誰でもできるであろう業務なのです。
もし、それでもわからないという方がいましたら、まずはプログラミングをやってみることをお勧めします。
プログラミング言語は数多くありますが、一番なじみやすい、という理由からＶＢＡをやってみるといいでしょう。
業務用PCは一人一台がほぼ当たり前になっています。
また、WindowsのPCを使用していれば表計算ソフトはほぼMicrosoft Office Excelでしょう。
ＶＢＡはMicrosoft Office ExcelがPCに入っていれば誰でも学習することができます。
他の言語と違い、わざわざ開発環境を作成する必要はありません。
敷居が低いためか、ＶＢＡからプログラミングに興味を持つ方も多いです。
ＶＢＡをほんの少し学習するだけでも、プログラミングの構造やルールといったことは何となく理解することができます。
もし、システム管理の担当者になってしまった、と後ろ向きに考えているようであれば、
これを機に少し勉強してみてはいかがでしょうか。
きっと損はしないと思いますよ。
2018.07.09
RPAを導入して業務を自動化することで、
「労働時間や業務コストの削減を実現できた」
「定型業務に携わっていた人材を知的生産業務へと振り向けることができた」
など、さまざまな企業でRPA導入の成果がうたわれています。
その反面、RPAの導入に失敗する例も数多く存在します。
失敗の原因を大きく分けて考えると、
「RPA導入時の問題」と「RPA導入後の運用時における問題」という2つの側面があります。
そこで今回の記事では、
「RPA導入に失敗する理由」と「失敗しないためにはどうすればいいのか？」
という観点からご説明をしていきます。
RPAを導入しようとする際、いきなり全社で導入しようと考えると失敗する可能性があります。
まずは部署や業務を限定した簡易なロボットからスタートしてPoC（Proof of Concept/概念検証）を行い、RPAの導入効果を確かめながら適用範囲を広げていくことが大事です。
RPA導入は、スモールスタートして大きく育てていくことが基本になります。
「年間数千時間の業務削減に成功」「定型業務の●割削減を実現」といった大規模な成功事例に目が行きがちですが、
いきなり全社規模で運用をしたわけではなく、やはりスモールスタートで運用を開始し徐々に適用範囲を拡大、
その結果、大きな効果が得られたという事例が大半になります。
なぜRPAでいきなり全社規模での導入がタブーなのかというと、各部門の業務に対応した導入が必要となるからです。
RPAツール自体は標準的なものですが、使える環境や使い方はそれぞれ異なるわけです。
それだけでなく、RPAというテクノロジーが登場し注目されたのはごく最近のこと。
多くの企業にとってもRPA導入は初めての体験となります。
そのために、システム面だけでなく業務面も含めてすり合わせを行いながらベストプラクティスを見つけ、それを確立していくことが大事です。
そのほか、RPAに関わっていく人材を育成するにもある程度は時間がかかります。
RPAの適用範囲はスモールスタートすることが成功の近道というわけです。
また、PoCで導入効果が上がっている結果が検証できれば、その事実をもとにして、
経営層に対してRPA導入範囲拡大を促すこともしやすくなります。
RPA導入に当たってどのツールを採用するのかも重要なポイントです。
RPAベンダーのデモや資料だけでツールの採用を決めてしまうと、
どんな複雑な業務でも簡単にロボットを作成して自動化できてしまうという印象を受けてしまいます。
自社でRPAを導入しようとしている業務の内容や規模によって、向き不向きもあります。
また、初期導入コストという観点だけでツールを採択した場合、機能により自動化の範囲が中途半端になったり、既存IT環境で動作しきれなかったりといった場合もあります。
そうならないためには、初期導入コストだけを見るのではなく、
ランニングコストやツール導入により期待される効果（業務削減効果やコスト削減効果など）をシミュレーションしてツール選択の要素に加えていく必要があります。
たいていのツールであれば、1～2カ月は無料でトライアル利用ができますので、実際に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システムと同様に運用トラブルは起こる可能性はあります。
そのために、障害対応ルールも必要となります。
これらのRPA導入失敗例はITに疎い企業に起こるわけではありません。
とあるIT分野の専門商社でも社内業務のロボット化に一度失敗をしています。
同社では3カ間のPoC期間中に12業務で自動化をスタート。
30のロボットが稼働することになりました。
しかし顕在化してきたのは、会社組織の規律を乱すロボットが出現するリスクでした。
例えば、「出社していない従業員の出退勤記録を残す」といった悪用できるロボットを、勘のいい社員なら15分程度で作れると分かったのです。
また、RPAツールの研修を受けても殆ど手を付けない社員も存在することで、
「ほとんどロボット化が進んでいない部署」と「過剰にロボット化している部署」が生まれていました。
ロボット作成後の管理方法もあいまいだったため、担当者が部署異動するだけで混乱をきたす危険性も見えました。
そこで初めて、ロボット活用の成否を握るポイントとして、「ルール」に基づく「管理」と、その実行を担う「組織」づくりにあることがわかったといいます。
とにかくRPAを導入すれば、「単純作業はすべて自動化へと移行できる」と考えることは幻想でしかありません。
RPAはツールでしかありません。
ツールがうまく機能していくためには導入手順をきっちり決めなければなりませんし、RPAに対する意識改革から始めなければならないこともあります。
RPAは比較的安価に導入できるために、業務プロセスの可視化や標準化を疎かにした安易な導入で失敗してもその失敗が隠されてしまう恐れもあります。
ホワイトカラー業務へのIT適用である、RPA導入を成功に導くためには細部への注意も必要といえるわけです。
お困りの場合、RPAを成功に導くためのノウハウを蓄積した弊社にご相談ください。
2018.07.06
DeNA社は、非金融企業としては、いち早くRPAを導入した企業の1つです。
本稿では、DeNA社によるRPA導入をRPA業界からの視点でお届けしたいと思います。
株式会社ディー・エヌ・エーは、1999年3月に設立されました。
当初は「ビッダーズ」というオークション＆ECサイトを運営していました。
ビッダーズは現在「Wowma!」と名を変え、運営会社もDeNAからKDDIへと移管されています。
その後、オークションサイトである「モバオク」のヒットもあり、
2005年2月にマザーズへ上場を果たしました。
最も成功した事業は、2006年2月に開始した「モバゲータウン」（その後“Mobage”に改称）でしょう。
当時はまだスマートフォンではなく、いわゆる「ガラケー」がほとんどでしたが、
「怪盗ロワイヤル」「農園ホッコリーナ」といったタイトルが大ヒットを記録しました。
この恩恵もあり、東証一部上場を果たし、さらには横浜ベイスターズを買収するなど、
M&A等により事業を拡大していきました。
ただし、2018年3月期においても、ゲーム事業の売上高が70%以上を占めています。
直近で言うと、「ファイナルファンタジーレコードキーパー」「逆転オセロニア」、
任天堂との協業タイトルでは「スーパーマリオラン」や「ファイアーエムブレムヒーローズ」、
「どうぶつの森ポケットキャンプ」「マリオカートツアー」といった辺りがヒットしているようです。
2018年度の経営計画としては、インターネット×AIを大方針として掲げています。
DeNA社がRPAを早くに推進しているのも、うなずけますね。
DeNAの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案件でぜひとも真似をしていくべきポイントは以下の3点に絞れそうです。
これらは、どのRPAシステム開発案件でもつぶしの利きそうなポイントとなります。
ぜひ、DeNA社を見習って素晴らしいRPAシステムを構築していきましょう。
2018.07.05
資金繰り表とは、すべての現金預金収入と現金預金支出を分類・集計し、一定の区分、科目に基づき整理された表です。
家計簿と同じく、お金の出入りをあらわします。
試算表や決算書の損益計算書とは異なり、
実際の現金預金の入金・出金の事実に基づいて作成されるため、
実際の現金預金の入金・出金が把握できます。
資金繰り表には、作成期間に応じて、資金繰りの実績をまとめた「資金繰り実績表」、
将来の資金繰りの計画をまとめた「資金繰り計画表」があります。
また、作成単位に応じて、月々の資金繰りをまとめた「月次資金繰り表」と日々の資金繰りをまとめた「日次資金繰り表」があります。
企業は当期純利益が毎期赤字であっても現金預金が潤沢にあり、資金繰りがうまく行われていれば倒産することは少ないです。
一方で、当期純利益が毎期黒字であっても、現金預金が少なく、資金繰りがうまく行われておらず、
債権者（金融機関、仕入先など）への返済・支払が滞ると倒産又は倒産状態となります。
このように損益計算書上では黒字の状態でもかかわらず、資金繰りの関係で倒産又は倒産状態になることを黒字倒産といいます。
黒字倒産を防止するためには、損益計算書による利益管理をはじめ、資金繰り表作成による収支管理が重要です。
資金繰り実績表から自社の現金預金の入金・出金のトレンドを把握することに加え、資金繰り計画表で現金預金の入金・出金の時期と額を把握し、
それを管理することによって、現金預金が底をつくという状況を未然に防ぐことができます。
資金繰り表による資金繰り管理で最も重要な項目は、月末又は毎日の現金預金残高です。
資金繰り実績表の作成により、自社の通常必要な運転資金が把握できるため、最低限必要な現金預金残高もわかります。
その必要最低限の現金預金残高を下回らないように資金繰り表の月末又は毎日の現金預金残高の項目を管理していくことが重要です。
資金繰り計画表の作成により、設備投資や原材料の支払時期が明確になる為、
それに合わせて資金調達のために金融機関との交渉を計画的に進めることができます。
下図は、月次の資金繰り実績表と資金繰り計画表のフォーム例です。
青い項目の「実績」列が資金繰り実績表で、赤い項目の「計画」列が資金繰り実績表です。
一番右の「期間累計」は実績と計画を合わせた4か月間の合計金額です。
各項目の記載内容と分析例は以下のとおりです。
[売上収入]
現金売上の入金額、売掛金の入金額などの本業の売上入金額を記載します。
[雑収入、助成金収入]
本業の売上入金以外の臨時の入金額や助成金の入金額を記載します。
[その他経常収入]
普通預金利息入金額やその他金額が過少な入金額を記載します。
[経常収入合計]
経常収入の合計です。経常収入には営業活動で生じた収入が記載され、どれだけの現金預金が生み出されたのかを表しています。
家計簿で言うと、給料・賞与の収入などに該当します。
[仕入等支出]
現金払いの材料仕入金額、買掛金の支払額などの原価の支払額を記載します。
[給与賞与支出]
給与、賞与、社会保険料などの人件費の支払額を記載します。
どこまでを人件費に含めるかは、その会社の特性によって変更します。
給料、賞与は実際に支払った手取り額を記載します。
[販管費支出]
現金払いの販売費及び一般管理費、販売費及び一般管理費に係る未払金・未払費用の支払額を記載します。
[法人税支出、消費税支出]
法人税と消費税の支払額を記載します。
[源泉税・住民税支出]
源泉所得税と個人住民税の支払額を記載します。
[その他経常支出]
金額が過少な臨時的な支払額を記載します。
[経常支出合計]
経常支出の合計です。経常支出には、営業活動のために必要となる支出が記載され、どれだけの現金預金が消えていくのかを表しています。
家計簿でいうと、賃貸物件の家賃の支払いや水道光熱費の支払い、食費の支払い、保険料の支払いなどが該当します。
[経常収支過不足]
経常収入合計から経常支出合計を差し引いた収支差額が記載されます。
経常収支過不足がプラスの場合は、営業活動により現金預金が増加したことになります。
経常収支過不足はある一定期間（一年間の事業年度など）で見たときに、プラスである必要があります。
経常収支過不足がマイナスであれば現金預金が社外に流出していることを意味するため、経常収支過不足のマイナス金額が多かったり、
そのマイナスが続くような場合は、事業継続が困難になる場合があります。
[経常収支率]
経常収支過不足が0円の場合、経常収支過不足は100%になります。
経常収支率が100%を超えるような資金繰り計画を作成することが重要です。
[借入金収入]
金融機関などからの借入金の収入額を記載します。
[借入金返済支出]
金融機関などからの借入金の返済額を記載します。
[敷金支出]
賃貸物件の保証金・敷金の支払額を記載します。
[設備投資支出]
製造用機械の購入、店舗内装工事代金の支払い、営業用車両の購入などの設備投資支払額を記載します。
[財務等収支過不足]
財務等収入合計から財務等支出合計を差し引いた収支差額が記載されます。
財務等収支過不足がプラスの場合は、資金調達などの財務等活動により現金預金が増加したことになります。
財務等収支過不足はある一定期間（一年間の事業年度など）で見たときに、プラスであることが望まれます。
設備投資支出が予定されている場合は、自己資金（経常収支で生じた現金預金）で設備投資等を行わずに金融機関からの資金調達することにより、
資金繰り悪化を防ぐことができます。
手許の現金預金が潤沢にある場合は自己資金で設備投資等を行っても問題ない場合が多いです。
[総合収支過不足]
総合収支過不足は、経常収支過不足と財務等収支過不足を加算して算出します。
総合収支過不足は、すべての収入と支出の収支差額が記載されます。
総合収支過不足がプラスであれば現金預金が増加したことになります、マイナスであれば現金預金が減少したことになります。
[月初現金預金残高]
月初の現金預金残高を記載します。
[月末現金預金残高]
月初現金預金残高に総合収支過不足を加算して算出されます。
資金繰り表が間違いなく作成されていれば、月末現金預金残高と実際の現金預金の金額が一致します。
上記の資金繰り表フォームに沿って、資金繰りの分析例を紹介します。
経常収入は18,300千円あったものの、経常支出が24,750千円あったため経常収支は6,450千円のマイナスになりました。
また、借入金返済支出が500千円あり、総合収支は6,815千円のマイナスになりました。
月初に50,000千円の現金預金がありましたが、6,815千円の現金預金が減少したため5月末現金預金残高は、43,185千円になりました。
助成金収入が3,000千円あったものの、A部門及びB部門の売上収入が少なかったことが総合収支がマイナスになった大きな要因です。
なぜ売上収入が少ないのかはいくつか仮説を立ててそれを検証していきます。
売掛金の回収漏れがあったのか、前月以前の掛売上高の不振によるものなのか、毎期の季節性のためなのか、などを検証します。
経常収入は、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,000円／（貸方）普通預金1,000円
資金繰り出力項目：人件費支出0円 前払金・未払金支出1,000円
資金繰り表の機能としては問題ありませんが、分析するためには不十分な出力結果となっています。
資金繰り表で「人件費支出1,000円」と出力された方が資金繰りの分析をする上で有益になります。
このように会計ソフトでは機械的に集計されてしまうため、自社に合わせた必要な情報がうまく設定することができない場合があります。
設定できる場合でも非常に煩雑なことが多いです。
②商品・サービス別の資金繰り表が作成できない
損益計算書を作成時には、例えば売上高勘定の補助科目として「A商品売上」や「Bサービス売上」などを設定しているケースは多いと思います。
しかし会計ソフトの資金繰り表では、補助科目の集計・分類ができない場合が多いです。
会計ソフトの仕訳データを使用しエクセルで資金繰り実績表を作成する手順は以下のとおりです。
①仕訳は総額で入力し、現金預金勘定の相手勘定科目は必ず入力します。
相手勘定を諸口や、空欄にはせず、必ず相手勘定科目を入力します。
[一般的な仕訳例]
（借方）長期借入金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で作成することにより、業務時間に資金繰り予定表の作成に注力できるため、
会社の資金繰り安定化の実現や、金融機関との上手いつきあい方につながることが期待できます。
2018.07.04
今回はUiPathのセレクタについてお話していこうと思います。
セレクタは少々分かりにくく、理解するのに時間がかかるかもしれません。
実際に、筆者はこのセレクタには何回も悩まされています。
ここでしっかりとセレクタについてまとめておいて一緒に理解していきましょう。
まずはセレクタとは何なのかについて見ていきます。
論より証拠ということで、実際のセレクタをまずは見ましょう。
<wnd app=’explorer.exe’ cls=’Progman’ title=’Program Manager’ />
これがセレクタです。
一体なにを言っているのかよくわからない呪文のようなものに見えます。
これを今から理解していきましょう。
私のイメージではセレクタとは処理対象がどこにあるのかを指すためのものと認識しています。
実際に、セレクタはUi elementを識別するものでありますからそのように捉えて問題ないと思います。
Ui elementという分からない単語が出て来たので見ていきます。
Ui elementとは以下のようなものです。
Ui elementはウィンドウ、チェックボックス、テキストフィールド、ドロップダウンリストなど、アプリケーションを構成するすべてのGUI(グラフィカルユーザーインターフェース)のことです。（UiPathガイド参照）
みなさんは作業の自動化などを行う際に、ウィンドウを開いたり、チェックボックスをクリックしたり、テキストフィールドに文字を入力したりすることがよくあると思います。
このようなGUIを総称してUi elementと呼びます。
このUi elementを操作するのを手助けするのがセレクタなのです。
つまり、GUIなどがどこにあるのかを探すときに、場所を教える手助けをしてくれるのです。
セレクタは多くの場合はUiPathによって自動で生成されます。
特にユーザーインターフェイスが静的に操作するものならば基本的には自動で生成されるので問題ないように思います。
先ほどから少し抽象的な話になってきていますので、具体的な例を見ていきましょう。
| 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の行を探してそこの列をみていくことができるようになりました。
他にも例を見ていきましょう。
<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での自動化をしていく上ではセレクタは切っても切れないものになると思います。
特に、レコードをする際などにエラーが出た場合などは、一度セレクタがあっているかどうかを確認するのもありでしょう。
セレクタは何回もつかっていくことで慣れていくと思うので頻繁に見ていくことをおすすめします。
2018.07.03
こんにちは、Oといいます。
6月よりRPAエンジニアとして、RPAツール「UiPath」を活用したソリューション業務に携わっております。
前職では食品の営業事務に携わっており、日々の受注処理を中心に業務に携わっておりました。
当コラムでは、実際に営業事務経験のある私が、UiPathについての学習を通じて感じ取ったことを伝えていければと考えています。
先ほどもお伝えしたように、私自身、営業事務として業務に携わっていた経験がある中で、日々の業務効率を上げることがに努めてまいりました。
その中で、社内の主要なツールがMicrosoftのエクセル・ワードであったため、
マクロ・VBAといったシステムの使い方を覚え、業務に活用することで社内業務の効率化を進めてきました。
しかし、近年ではwebやクラウドを活用した受注システムの増加・取引先の増加による受注方法の多様化により、
各アプリケーション上での業務効率化しかできないというジレンマを抱えておりました。
そんな中、RPAという言葉を知り、業務の効率化に対して、より高い水準で貢献したいという志を持って飛び込んできました。
まずはRPAを導入することで何ができるのか、ということを、元営業事務から見てどう感じるか、
また、どのような効率化に結び付けられるかに焦点を当ててお話しできればと思います。
そもそも、RPAとは「Robotic Process Automation」の略称で、「ソフトウェアによるロボットを用いて業務の効率化を行うための技術」を指します。
その特性から、業務の中で発生する単純作業を自動化することで業務の効率化を図ることができます。
以前に実際に行った業務ですが、取引先がwebの受発注サービスを使用しており、
そのwebサービス上で請求書のPDFを発行し、取引先にメールで送付する、という業務がございました。
その業務を行う際に、どのような作業を行っていたかを以下の通り取りまとめました。
一つの業務を行うだけでも、これだけの作業が発生してしまいます。
作業に慣れてくればある程度の手間は省くことができますが、
すべての作業を自動で行ってくれるサービス・システムはほぼ存在しません。
しかし、RPAであれば、以上の業務を全てロボットに行わせることができます。
その結果、業務時間の短縮につながります。
上記作業を人間が行う必要がある、ということも注意する必要があります。
作業する人が普段と違う人の場合、抽出データの範囲を間違えてしまい、違う期間の取引データをダウンロードしてしまうかもしれません。
各取引先へのメールとなると、作業者の不注意によって取引先へのメールに違う企業の請求書を添付して送信してしまうかもしれません。
これらのエラーは、人間が作業をする以上必ずついて回る問題であり、
作業者は日々注意して作業を行うか、あるいは第三者によるダブルチェックをしてミスを防がなくてはなりません。
私は以前、日々の受注処理業務をこなしていましたが、単価チェック等で必ず他者の確認を取る必要がございました。
この場合、自分のタスクが終わっても確認してもらう第三者の作業の合間か、あるいは作業中であることを承知の上で確認を取る必要がございました。
その為、作業の合間に待ち時間が往々にして存在しており、その度に作業が停止してしまうといったことがございました。
RPAの技術を用いれば、ロボットは毎回同じ動きをしてくるので、迅速かつミスなくタスクをこなすことができます。
その結果、単純作業を行っている時間を、他の業務のために使うことができ、生産性の向上に繋がります。
エクセル関数・マクロを活用した処理を考えると、元データとして.csvや.txt等のテキストデータがなければ自動化できませんでした。
業務で頻繁に使用するPDFのような書類からデータを抜き出す際に
「そのPDFファイルを開き、必要な情報をエクセルに打ち込む」という作業を毎日行っている方もいると思います。
この作業も、RPAを活用することで、PDFファイルを読み込み、テキストとして出力することが可能です。
Web上の操作をトレースしてくれるだけでなく、毎月変動する数値も取得することができます。
これらのことから、RPAは非常に有用なシステムですが、以下のようなデメリットもございます。
RPAの大きな特徴は、業務の自動化ができることです。
素晴らしい技術ですが、実は大きなデメリットにもなっています。
例えば、取引先から単価100円の商品が3000個の発注があったとします。
もし単価が10円違う90円で計上されていたらどうなるでしょうか？
ベテランの事務員であれば気づくことができ、処理を行う前に各所へ確認してトラブルを未然に防ぐことができるでしょう。
もし、同様の処理をロボットが行った場合、単価の間違いに気づかずにそのまま処理を行ってしまいます。
また、発注数量が大きく違っていた場合も、同様に気づかずに処理してしまう可能性がございます。
ロボットは定型業務が得意であるが故に、間違った情報が入っていた場合の修正や、判断を必要とされる業務への適正は低いです。
もちろん、エラーの定義を決めればある程度の判断は可能となりますが、
微妙な場合の判断・細かな箇所への対応等には適しておりません。
また、機能の追加によるシステムの複雑化の原因にもなってしまいます。
RPAの場合、一度設定した業務を自動で行ってくれます。
ですが、もし業務フローが追加・変更となった場合は注意を要します。
毎月の業務において月ごとに変更の発生する可能性がある業務をロボットに行わせようとすると、
毎月機能の追加、変更を行う必要がでてきます。
そのため、業務フローが定まっていない業務の場合、業務フローを固定化するまでは、人が作業したほうが効率的な場合もあります。
定期的な改修も必要となるため、結果的にコスト増になってしまう可能性もあります。
これまで、RPAに関するメリットとデメリットを挙げてきました。
現時点では定型業務の効率化が大きな役割となるでしょう。
しかし、RPAとは業務効率化のためのテクノロジーであり、今後もアップデート等で対処可能な範囲が拡大していくと考えられています。
ただし、決してRPAを導入しなくてはいけない、というわけではないと考えております。
業務の改善といっても様々な手段があります。
今回は、業務の改善のためにRPAが最適か、ということを考えるための要素として捉えていただきたいと思います。
それよりもまず、このようなテクノロジーがあるということを知っている方が一人でも多くなることが重要であると考えています。
私も、以前の職場では、エクセルやワードの使用が業務の中心であり、
それらを有効活用することで、作業をいかに効率化するか、という考えの中で業務に努めておりました。
RPAという単語も、今年に入ってから初めて聞きました。
どのようなサービスでも言えることですが、それらのテクノロジーを必要としている業界ほど、
そのようなテクノロジーがあることすら気づいていないことが多いと感じます。
必要なテクノロジーを与えることで、会社の生産性が上がり、業務を効率化することができるにも関わらず、
ただ知らないからという理由だけで、多くの企業が現代社会の最先端のテクノロジーの恩恵を得られていないように思えます。
生産効率の向上のため、RPAを活用した作業の自動化という選択肢があるということを、頭の片隅にでも覚えておいていただければ良いと思います。
営業事務として現場の業務に携わった者として、作業時間の短縮は至上命題だと考えています。
RPAという技術を、作業効率を高め、生産性を向上させるための一つの手段として考えていただける方が一人でも多くなれば、と願っています。
2018.07.02
