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

【UiPath】アクティビティパッケージまとめ 1/2

2018.08.20

UiPathは、様々なアクティビティやレコードなどを使用して作業の自動化を行うことができるように開発された

RPAツールの一つです。

 

このUiPathには初めからインストールされているアクティビティ以外にも、アクティビティを追加することができます。

その際に、インストールするのがアクティビティパッケージです。

 

今回はそのアクティビティパッケージの用途に分けた使い方をまとめていこうと思います。

 

 

アクティビティパッケージとは


アクティビティパッケージとはパッケージ化された様々なアクティビティのことを指します。

分かりやすく言うと、様々なアクティビティが一つの袋に集められているようなものです。

 

UiPathの場合にはその袋が用途ごとに別けてまとめられています。

ですので、必要なアクティビティのみをインストールして使用することが可能です。

 

様々なアクティビティがある中で自身の必要なアクティビティを確認して初期設定を行うことをおすすめします。

そのために今回はアクティビティパッケージを一つずつ中身を確認して、初期設定に役立てていただけたらと思います。

 

インストール・アンインストール方法


どのようなパッケージがあるかどうかを見る前に、

パッケージのインストール・アンインストール方法を確認しておきましょう。

ここでは、現在の自身の環境でどのアクティビティパッケージをインストールしているかどうか

確認できますので便利です。

 

1.UiPath Studioを起動する

 

2. 左側にあるアクティビティ一覧から「Manage Packages」と書かれるアイコンをクリック

これで新しいウィンドウにパッケージマネージャーを開くことができます。

(ショートカットキーとしてCtrl+Pも用意されています。)

 

 

 

 

3. 左のInstalledの下矢印をクリック

 ここで現在ご自身の環境でどのパッケージがインストールされているのかがわかります。

(ここでInstalledに表示されているのが、現在ご自身の環境でインストールされているパッケージです。)

 

また、ここでは必要がなくなった・間違えてインストールしてしまったパッケージをアンインストールすることもできます。

その場合は、Uninstallをクリックすればアンインストールできます。

 

 

 

 

 

4. 新しくインストールしたい場合は「Available」からインストールしたいパッケージをインストールします。

(すでにインストール済みのものにはチェックマークがついています)

 

 

 

 

このように自身の環境確認とインストールとアンインストールの手順を確認したところで、

実際にアクティビティパッケージについて見ていきましょう。

 

 

アクティビティパッケージ


 

UiPath.Core.Activities

 

 

この、コアアクティビティパックには、ユーザーインターフェイス(UI)の自動化の作成に必要な

基本的なアクティビティがすべて含まれています。

 

基本的にこのパッケージはインストールしておくことをおすすめします。

 

<主に含まれているアクティビティ>

 

・「Get Text

指定したUI要素(*注1)からテキストを読み込みます。

 

*注1

UI要素:ウィンドウ、チェックボックス、テキストフィールドのようなGUIを総称してUI要素と呼びます。

 

・「Type Into

指定したUI要素にテキストなどを送信します

 

・「Hover

指定した UI 要素の上にカーソルを置きます (UI 要素の上でホバーします)。

 

・「Click」「Double Click

指定したをUI要素をクリック、ダブルクリックします。

 

・「Get OCR Text

OCR の技術であるスクリーンスクレイピングを使用する際に、

指定した UI 要素から文字列とその情報を抽出します。

このアクティビティは、スクリーンスクレイピングの実行時にコンテナーと一緒に自動的に生成することもできます。

既定では、Google OCR エンジンが使用されます。

 

・「Hover OCR Text

OCR の技術であるスクリーンスクレイピングを使用する際に、指定した UI 要素の中で指定の文字列を検索し、

文字列の上にカーソルを置きます (文字列の上でホバーします)。

既定では、Google OCR エンジンが使用されます。

 

 

 

ここまで具体的なアクティビティを見て気づかれた方もいるかもしれませんが、

このアクティブパックによって、簡単なキーボードやマウスの自動化だけではなくて、

OCRや画像認識の技術を使っての、画像およびテキストの自動化を実行することが可能となります。

 

また、情報を抽出してデータテーブルを作ったり、

PC上のディレクトリやファイルを直接操作して必要な操作を自動化することもできます。

 

UiPath.Cognitive.Activities

 

 

このアクティビティにはGoogleやMicrosoft、さらにIBMといったAPIを使用して

情報を取り出すときに役に立ちます。

 

このアクティビティパックには様々なAPI操作における自動化を助けるアクティビティが入っています。

 

<主に含まれているアクティビティ>

 

・「Google Text Analysis

Googleのテキストついて機能することができるアクティビティです。

指定したてテキストについて、言語、長さなどを取り出すことができます。

さらに、テキストが肯定的か否定的かどうかも分かることができます。

注)このアクティビティが機能する言語は、英語とスペイン語さらに日本語の3か国語だけです。

 

・「IBM Watson Text Analysis」「Microsoft Text Analysis

これらも指定したテキストを解析するのに使うアクティビティです。

上の「Google Text Translate」と違うところは、解析するテキストの種類が異なるだけです。

 

・「Google Text Translate

Googleのテキストを他の言語に翻訳することができるアクティビティです。

 

このようにこのアクティビティパックにはテキストを別の言語に翻訳するだけではなくて、

感情やキーフレーズを抜き出すこと可能です。

他にも発生している可能性のあるエラーや使用されている言語の解析なども可能です。

 

UiPath.Database.Activities

 

 

このアクティビティパックには、

データベースに接続してトランザクションやクエリなどを自動かすることができます

 

<主に含まれているアクティビティ>

 

・「Connect」「Disconnect

これらのアクティビティは、データベースに接続することや、

接続を切断することを実行するアクティビティです。

Connect」で接続し、「Disconnect」で切断することができます。

 

・「Start Transaction

このアクティビティはデータベースに接続し、複数のアクションを実行してから切断できるようにすることが可能です。

データベースに接続し、データベースで複数のトランザクションを実行できるシーケンスを持っています。

 

UseTransaction という変数 が True に設定されている場合、

含まれている操作は単一のトランザクションで実行され、それらのどれもが失敗しなかった場合は最後に適用されます。

 

同様のUseTransaction 変数が False に設定されている場合、

すべての操作は個別に実行されます。

 

このアクティビティが終了すると、データベースへの接続が終了します。

このアクティビティパックにはデータベースと接続とその切断やトランザクションの分割などを行うことができます。

 

 

 

 

完全無料のRPAツールWorkFusionとは

2018.08.17

RPAツールは基本的に高額なものが多く、

エンタープライズ向けだと年間数百万円以上かかり小規模でも年間数十万円といった価格帯です。

 

なので中小企業やベンチャーでは価格がネックとなり導入に踏み切れないケースも多くあります。

 そのため無料のRPAツールは多くの企業で求められており、

Google検索でも「RPA」と一緒に「無料」「フリー」などのワードが非常に多く検索されています。

 

 

みなさんはWorkFusionというRPAツールご存知でしょうか。

このツールはなんと無料で提供されています。

 

UiPathのCommunity Editionのように小規模事業者のみなどの制約はなく商用で堂々とRPAを無料で使うことが可能です。

今回はそのWorkFusionの特徴・メリット・デメリットなどを解説していきます。

 

WorkFusionはなぜ無料なのか

 

「無料より怖いものはない」という言葉がある通り、

日本ではまだあまり浸透していないWorkFusionを無料という理由だけで使用するにはかなり不安がありますし、

すこし高くても有名なWinActorやUiPathを選ばざるを得ないのが現状かと思います。

 

まずはその不安を取り払う為に、なぜ無料で提供しているのかを解説します。

 

 

WorkFusionは2012年マサチューセッツ工科大学発祥の比較的歴史の浅い企業です。

 

さらにWorkFusionの提供するRPAツール「RPA Express」は2017年にリリースされたばかりで、

まだリリースから1年ほどしか経っていません。

 

しかし、本拠地のアメリカではすでにRPAのBIG3といわれる、

Automation Anywhere, Blue Prism, UiPathのポジションに最も近い存在とも言われるほどユーザ数を急激に伸ばしています。

 

全世界でのユーザ数は現在3万以上と発表されおり、単に無料というだけではこれほどの利用はされないはずです。

 

 

WorkFusionはRPA×AIを前提として捉えており、

現在普及しているRPAは既存の技術のみしか使用していないので廉価版として無料で提供しています。

 

廉価版といえど他のUiPathなどと管理機能など含め引けをとらない機能を有しています。

これに加えて上位版が用意されており、こちらが年間150ドルで提供されています。

 

上位版を購入するとOCRや機械学習を活用した機能が使用できるようになります。

 

つまりWorkFusionはフリーミアムのビジネスモデルで収益を得ているので、

無料の機能を安心して使用することができます。

機能面の特徴

 

 

RPA Expressの開発画面

 

・Xpathまたはイメージ認識で画面認識

自動化の対象となるシステムのインターフェースをどのように認識するかはRPAツールの個性がでるところです。

 

WorkFusionはAIを活用したイメージ認識技術に強みを持っている企業なので、

今まで画像のマッチングで場所を特定するイメージ認識が中心でした。

 

しかしどれほど優れたイメージ認識でもユーザインタフェースは変化が多いので稼働が不安定になることが多いのも事実です。

 

WorkFusionは2018年5月のメジャーアップデートにイメージ認識に加えて、

システムの構造解析をして場所を特定するいわゆるオブジェクト認識が可能になりました。

 

オブジェクト認識にも種類がいくつかありますがウェブの場合Xpathによる指定方式を採用しています。

 

すこし、技術的な知識が必要ではありますが本格的につくりこめばUiPathやBizRobo!と同レベルの安定性をもったロボット開発も可能です。

 

 

・Chrome、FireFoxと相性が良い

RPAツールはInternet Explorerにしか対応していなかったり、独自ブラウザしか使用できないといったものが多いです。

拡張機能としてChromeなどが使えるといったツールもあります。

 

しかしWorkFusionはデフォルトでChrome, Fire Fox, Internet Explorerをサポートしている為、

特定のブラウザでの操作が必要な場合WorkFusionは非常に相性が良いです。

 

 

・管理機能がデフォルトで搭載

通常RPAの管理機能を導入しようすると安くても200万円以上はしますが、

WorkFusionではControll Towerという管理機能までもが無料で使用できます。

 

しかし、無料版だと他のデバイスとの連携がとれないため実質社内のRPA全体管理に活用するのは難しいですが、

スケジュール稼働などの機能は無料版で使用することができます。

 

有償版を購入する他のデバイスと連携がとれるようになります。

有償版は日本円で約180万円程度なのでこれでも十分に安いです。

 

 

日本でのサポート体制

 

・販売代理店

本格的のアメリカでのシェア拡大に注力している為か、日本での販売代理店は現状ありません

導入や活用をサポートできる企業も限られています。

 

・オンライントレーニング

すべて英語のコンテンツですが、Automation Academyという無料のe-ラーニングサイトと、

WorkFusion ForumというFAQサイトがあります。

 

 

WorkFusionをつかうメリット

 

・無料で使える

言うまでもありませんが、無料で使えるというのは非常に大きなメリットです。

RPA活用において、ツールに費用をかけるよりも、

ツールを活用して自動化していくことにお金や人材を投資することが成功のカギです。

 

したがってツールの費用を最小限に抑えることは決して消極的ではなく合理的な選択といえるでしょう。

 

 

・将来性がある

WorkFusionはまだまだ発展途上のRPAツールでありながらユーザ数を急激に伸ばし、機能の拡充も早いスピードで進んでいます。

もともと高い技術力を持った企業でありRPA×AIを前提として開発を進めているので、

近い将来RPAのBIG3を上回るハイスペックなRPAツールに成長する可能性を秘めています

 

 

WorkFusionのデメリット・注意点

 

・細かい使い勝手では劣る

やはり細かい使い勝手ではUiPathなどに劣ります。具体的な例をあげれば、

  • バリデーションチェックがない
  • デバッグ時にスローで実行したりターゲットをハイライトすることができない
  • レコーディングでXpath指定できない
  • エラーメッセージがわかりにくい
  • ワークフローの可視性が低い

などなど多いですが、無料ということを考えれば致し方無いのかもしれません。

 

 

・エンジニアがいないと使いこなせない

まず、WorkFusionは日本でほとんど展開していない為ソフトウェアはじめマニュアルやe-ラーニングなどすべてが英語です。

さらに今後日本展開といった噂もないので日本語化される見込みも低いです。

 

 

また、レコーディングやコマンドのドラッグアンドドロップなど業務部門でも基本的な自動化だけなら使いやすいです。

しかし、作りこもうとすると手打ちでのXpath指定などが必要になるので業務部門だけでRPA活用するといったイメージだと導入は厳しく、

エンジニア中心での活用または、その中間で業務部門とエンジニアが連携して進めていく形になります。

 

一方で、コードベースで開発できる機能もあるのでエンジニアにとっては相性がよいかもしれません。

 

 

まとめ

WorkFusionの導入に向いている企業は

  • 新しいものに抵抗がない
  • 社内にエンジニアがいる
  • 将来的には非定型業務も自動化していきたい

といったものにあてはまる企業だといえます。

 

 

 

【必見】大規模RPAプロジェクトの進め方 (4/4)

2018.08.16

今回のコラムでは、前回に引き続き、大規模なRPA導入プロジェクトにおける成功の鍵について述べていきたいと思います。

 

「組織体制」と「運営」の2つに分けて説明させていただきましたが、本コラムでは後者に焦点を当てています。

 

前回コラムを参照したい方は下記のリンクを参照してください。

 

 

(参考)前回コラム:大規模RPAプロジェクトの進め方 (3/4

 

 

まず、おさらいになりますが、RPA導入プロジェクトをする上での成功の鍵として、

前回コラムからの再掲になりますが、以下のような要点が挙げられます。

 

 

  • 組織体制
    • 分散と集中
    • コーポレートで専任チームを作り、ユーザー側の担当者を明確に
    • 分業のススメ
  • 運営
    • パイプライン管理でボトルネックを探せ
    • 教育も並行で
    • ナレッジシェアリングの仕掛け
    • テスト環境に配慮を

 

 

本コラムでは、2の「運営」について詳述していきます。

 

 

2 運営

2.1 パイプライン管理でボトルネックを探せ

RPAの技術自体が目新しいものなので、

多くの導入企業にとってRPAプロジェクトに対する経験値が未だ十分に足りていない事が多いと思います。

 

金融業界でまずRPA化の先鞭をつけた形となりましたが、その他の多くの業界では、未だPOCの段階であったり、

ようやく2018年になって開発体制の準備、実行フェーズに入ったところが大多数ではないでしょうか。

 

 

そのように不慣れなプロジェクトにおいて、人員リソースの最適配分は喫緊の命題となります。

 

もともとRPAに詳しい人材が未だ市場に十分にいない状況ですので、

開発工程のうちのどこかのプロセスがボトルネックとなり、

目標とする開発ロボット数や業務負荷低減時間に到達できずに苦労している企業も多いように見受けられます。

 

 

従って、特にRPA導入プロジェクトにおいては、

ボトルネックを探し出すためのプロジェクトマネジメント技術が求められることになります。

 

そのようなスキルは、正にPM/PMOにとって腕の見せ所の領域です。

特に大規模なRPA導入プロジェクトとなった場合、

それこそ数多のロボット案件・アイデアが浮上していくことになるので、それらを捌き、整理し、

管理するための高度な技術およびシェアリングの環境が待望されています。

 

その中の一つとなる有効な手法が「パイプラインの見える化」です。

 

(参考:パイプラインの管理)

 

 

パイプライン管理は、システム開発の用語というよりかは、

歴史的に営業であったりR&Dの領域で発展してきたマネジメント手法です。

 

簡単に説明すると、営業にしろR&Dにしろ、システム開発でも構いませんが、

特定の業務を個別プロセスに分解し、各プロセス上に現在どのくらいの案件があるのか可視化する手法です。

工場生産の現場で言うと、歩留まりを把握するのに近しい手法です。

 

 

何故、RPA導入プロジェクトの現場で「パイプライン管理」が重要になるのかというと、

それはRPAプロジェクトならではの特性に起因します。

 

RPAというものは、そもそも大型のシステム開発案件とは違い、

「システム開発するにはペイしない」細々とした業務の自動化が前提となります。

 

 

そもそも大きな業務負荷低減が見込める領域であれば、

RPAでなくて抜本的なスクラッチでのシステム開発を選ぶケースが圧倒的であり、多くの企業はそうしています。

 

 

つまり、企業にとってそれなりの業務負荷低減効果を狙うのであれば、

それこそ数多のロボットを生成する可能性が出てくるということです。

 

即ち、通常のシステム開発と比べ、RPAというものは、一つ一つは小粒な、

でも数だけは膨大なロボット開発案件の集合体となるわけです。

 

そこに、パイプライン管理の重要性が屹立してくることになります。

 

 

上記にあるチャートで、RPA導入プロジェクトにおけるパイプライン管理の事例を紹介していますが、

それでは例えば其処から何が読み取れるでしょうか。

 

この例で、まず目につくのは「業務フロー設計(To-Be)」が完了しているのに次の段階に移れていない案件が多く、

その割に次フェーズの「プログラム設計書作成」で仕掛中の案件が少ないことです。

 

これは、プログラム設計書作成の人的リソースが足りないが故に全体として動脈硬化が起きている現象を示しています。

つまり、この時点で「プログラム設計書作成」が明らかなボトルネックになっているということです。

 

 

このような極端な例は無いだろう、、、と思われる方も多いと思いますが、

不慣れなRPA導入のプロジェクトの場合、現実的に起こりうる事象です。

 

おそらくPMとしては、もちろん薄々は問題を理解していることなのですが、

いかんせんそのボトルネック工程を補填する人的リソースが見当たらず、打開策が取れない状態に陥っている、

そのようなことが現実的にRPAの開発現場では起きています。

 

 

このあたりの具体的な解決策については、

次のポイントである「教育」に大きく関与してくるところではあるので次節以降に譲りますが、

いずれにせよ重要なのは、このようなパイプライン管理をすることで「迅速に」ボトルネックを洗い出し、

打ち手を講じることができることです。

 

それにより、納期と目標が決められたプロジェクトを完遂し達成する確度を上げることができるのです。

 

 

2.2 教育も並行で

次に、RPAプロジェクトにおける「教育」の重要性について語りたいと思います。

なぜRPAプロジェクトにおいて教育、つまりトレーニングが重要となるのか。

 

それは、RPAの持つ2つの特徴に起因します。

1つ目は「RPA人材の不足」2つ目は、その割には「RPAの技術自体は差ほど難しくない」ということが挙げられます。

 

 

前述しました通り、RPAは比較的新しい技術領域であり、

そのプロジェクトに精通している人材の確保が難しい状況にあります。

 

従って、プロジェクトスタート時では十分なビジネスアナリスト/業務コンサルタントおよびエンジニア双方において十分な知見を有する人材を欠いたままスタートせざるを得ないケースもまま存在します。

 

このような状況でプロジェクトを運営せざるを得ない場合、大事なのは開発と同時に「教育」も進めていく事です。

 

RPAプロジェクトの場合、小型のロボット開発を積み重ねていく進め方になるので、

最初のリソース不足の段階では、少数の案件に着手し、後のフェーズで教育を経て人材を揃えていくやり方でも進めていく事ができます。

 

 

教育に焦点を当てる領域を特定する上で、前述したパイプライン管理が役立ちます。

定期的に、各工程の歩留まりをチェックすることで、

リソースが枯渇しそうなプロセスの人員を特に重点的に教育して増やしていく柔軟性が求められます。

 

一般的に、RPAのプロジェクトでは、プログラム設計書作成やRPA開発といった下流工程がボトルネックになりがちであり、

トレーニングをして人員体制を整えることが求められます。

 

 

2.3 ナレッジシェアリングの仕掛け

上述した教育を促進させるために、KMの観点は非常に重要になります。

 

特にRPAのプロジェクトでは、ユーザー側の担当部署・担当者が多種多様に広がる可能性が高く、

またプロジェクトフェーズごとに人員体制を柔軟に変動させる必要があるため、

コアとなる知識・ノウハウを共有する工夫が開発の非効率を防ぐために必要です。

 

先進的な企業ではRPA専用の社内ポータルサイトを作り、ナレッジ共有に努めています。

 

ポータルサイトでなくとも、Slack等の社内SNSを活用していくのも有効です。

SNSを使えば、コミュニケーションの迅速化が図れ、ユーザーと、ビジネスアナリストおよびエンジニア間で、

仕様の確認や、RPAに合わせた業務フロー・ロジックの提案および承認といった、細々な点で開発スピードの向上が狙えます。

 

 

ただ、そのような大層な仕掛けがなくとも、

普通に共有フォルダを関係メンバーに公開するようなやり方でも、もちろん一向に構いません。

 

 

それでは、具体的にどのような情報コンテンツをナレッジシェアリングの対象とすべきでしょうか。

具体的な例として以下をご覧ください。

 

複数のステークホルダーが関与することになりますので、

それ毎に分けてコンテンツを用意することが見る側にとってもストレスなく使ってくれることに繋がります。

 

また、ユーザーサイドであったり、ビジネスアナリスト/業務コンサルタントに対しても、

RPAロボットの動き方を理解してもらうことは重要になりますので、

エンジニア以外にもRPAツールの紹介をする工夫がポイントとなります。

 

 

<全体>

  • 組織体制図、各コンタクトポイント
  • 案件リスト、パイプライン管理表
  • スケジュール

 

<対ユーザー部署>

  • RPAの基本の紹介(初級編。動画コンテンツ等が有効です)
  • RPA対象業務選定のコツ・ポイント
  • 業務評価リストひな型と記入例
  • 現在の完成/仕掛中業務評価リスト

 

<対ビジネスアナリスト/業務コンサルタント>

  • RPAの基礎トレーニングプログラム(簡単なプログラムを実際に自分でさせるのが理想)
  • As-Is業務分析用シートひな型・記入例
  • To-Be業務フロー設計書ひな型・記入例
  • 現在の完成/仕掛中のAs-Is/To-Be資料

 

<対エンジニア>

  • RPAの中級・上級トレーニングプログラム
  • プログラム設計書ひな型・記入例
  • 現在の完成/仕掛中のプログラム設計書
  • 開発ルール説明
  • モジュール管理リスト(複数案件に使いまわしのきく基礎プログラムを整理&説明したもの)
  • テスト設計書ひな型・記入例
  • 現在の完成/仕掛中のテスト設計書
  • ユーザー担当者/ビジネスアナリスト/業務コンサルタント側とのQAリスト

 

 

2.4 テスト環境に配慮を

RPAプロジェクトの運営面でのポイントをお伝えしましたが、

最後にテスト環境の配慮を早い段階でしておくことの重要性をお伝えしたいと思います。

 

 

RPAでは、日々の定型業務の自動化がターゲットとなりますので、メール受信や、既存社内システム、

外部アプリケーションの操作をRPAでプログラミングしていくことになります。

 

また、ロボットと人間の間のやり取りの仕方として、特定共有フォルダに人間が必要ファイルをアップロードして、

ロボットが定期的にその共有フォルダを巡回、ファイルが合ったら処理を開始する、といった方法が取られることが多いです。

 

そのような、メール、社内システム、外部アプリケーション、共有フォルダといったものに対して、

テスト用と本番用を予め設計しておくことがスループットの向上につながります。

 

必ずしもテスト用と本番用の環境を別々にする必要はありませんが、

例えば、今でも社員が使っている共有フォルダやメーリングリスト、

およびシステム・アプリケーションのアカウントをテスト用で使うのは問題になりますので、

状況に応じて環境を分ける判断が必要です。

 

その場合、例えば、システムやアプリケーションのアカウントで起こりがちですが、

権限の設定がテスト用と本番用で齟齬があると障害の元となりますので、予め設計書で指示しておく必要があります。

 

また、このようなテスト用・本番用の環境設定は、RPA開発エンジニアの仕事という訳ではありません。

環境設定と言っても、大げさなものではなく通常業務で使うアプリ等の設定の話ですので、

このあたりの役回りは開発エンジニア以外の担当でも構いません。

 

 

RPAでは、一つ一つのロボット案件は小さいので、大規模システム開発と違い、

このあたりのテスト環境の整備がなおざりになりがちで、

いざ開発する段階になって「どうするんだっけ?」となることが散見されます。

 

予めプログラム設計書のフォーマットにテスト環境と本番環境を分けて記述できるように欄を設けるなど、

工夫をすべきだと考えます。

 

  

以上、今回の一連のコラムでは、

比較的大規模なRPAプロジェクトにおいて気を付けるべきポイントを組織体制と運営の側面から俯瞰してご紹介しました。

 

プロジェクトの要所は、会社およびRPA対象部署などによって変わってくるものではありますが、

今回でご紹介した点を咀嚼し、応用していただければと思います。

 

 

 

【必見】大規模RPAプロジェクトの進め方 (3/4)

2018.08.15

今回のコラムでは、比較的大規模なRPA導入プロジェクトにおいて特に注意すべき点を述べていきたいと思います。

前回のコラムまでは、一般的な各開発工程における留意点を挙げさせていただきました。

 

 

(参考)前回コラム:大規模RPAプロジェクトの進め方 (2/4

 

 

複数の部署に跨る大規模なRPA導入プロジェクトの場合、特に組織体制と運営手法が重要になってきます。

このあたり、幾つか要点をまとめてみました。

 

  • 組織体制
    • 分散と集中
    • コーポレートで専任チームを作り、ユーザー側の担当者を明確に
    • 分業のススメ
  • 運営
    • パイプライン管理でボトルネックを探せ
    • 教育も並行で
    • ナレッジシェアリングの仕掛け
    • テスト環境に配慮を

 

 

1 組織体制

1.1 分散と集中

分散と集中とは、各工程のタスクを事業部等の個別部署に分散してお願いするのか、

コーポレートで中央管理するのかの切り分けの話になります。

 

もともと、RPAの思想として、ユーザーである現場部署が自らの力で自動化できることを謳ってはおりますが、

こと大規模なプロジェクトの場合は、開発工程に進むほど中央管理することが求められます

 

(参考: RPA導入プロジェクトの工程)

 

 

前回コラムで、上記の一般的な開発工程ステップをお見せしましたが、

理想論から言うと、最初の「対象業務選出」のところまではユーザーである現場部門主導で行い、

その後の現状業務分析(As-Is)以降は、コーポレートに所属するビジネスアナリストもしくは外部の業務コンサルタントが主導して現場ヒアリングをベースに策定していくのが望ましいと言えます。

 

 

これは、As-Isの分析資料や、To-Beの設計書というものが、

次の実開発フェーズに進むうえで標準化された仕様であることが望まれるからです。

 

個別現場部門にお願いする場合、フォーマットを規定したとしてもどうしても書き方の統一が難しく、

標準化されていないと開発チームが混乱をきたすリスクが高まります。

 

 

ただ、これはあくまで理想論であって、

中にはビジネスアナリスト/業務コンサルタントのようなリソースの十分な確保が困難である会社も多く存在すると思います。

 

その場合、百歩譲って、As-Isの現状業務分析のところはフォーマットを決めてユーザー側である現場担当者に任せることも可能です。

 

非常に単純な作業をRPA化するのであればTo-Beのところも任せられるケースもあります。

ただ、プログラム設計書作成とのころは、開発チームに標準化された仕様書を渡す最後の砦となりますので、

その工程だけはしっかりとセントラルで品質管理できるようなチーム体制は必須となります。

 

 

1.2 コーポレートで専任チームを作り、ユーザー側の担当者を明確に

(参考:RPAプロジェクト体制例)

 

 

次にRPAを推進していく上でのチーム体制についてですが、こちらについては、

もちろんリソースが許す範囲でのことになりますが、PM/PMOのみならず、

ビジネスアナリスト/業務コンサルタントおよびエンジニアまで含めて専任チームを組めることが理想です。

 

これは、おそらくどの企業にとってもRPAというものが未だ馴染みがなく、独特の注意点を要するプロジェクトとなるため、

早めにナレッジを吸収しそして歩留まりを良くするためには専任チームのほうが効率的になるからです。

 

 

また、ユーザーとなる現場部門についても、このRPAプロジェクトにおいて担当窓口となる人間は各部署で特定すべきです。

 

ここで特に言っておきたいことは、PM/PMOの役回りも、

可能であればその期間だけはRPAにほぼ特化した形で業務を遂行できるように環境を整えてあげる事です。

 

このPM/PMOの役回りは、現状だと経営企画室やもしくはコーポレートのIT部門が担うケースが多いですが、

今まで見たケースだと、どうも他業務との兼務で指示されることが多いようです。

 

もちろん、最初のPOCや、As-Isの業務分析あたりまでは、兼務であっても進めることはできると思います。

ただし、より開発に近づいたフェーズになると、より開発環境の標準化やリソースアロケーションといった点で、

漏れのない管理が必要となり、そのためにはPM/PMOがRPAに特化した専任チームであることが望まれます。

 

 

1.3 分業のススメ

システム開発の分野において、一概に「分業」が全て正しいという訳ではありませんが、

ことRPAに関して言えば、リソースの有効活用という側面において、組織設計に織り込む必要があります。

 

 

現状、社内リソースにおいてRPAの知見を十分有している社員は、

ビジネスアナリストおよびエンジニア双方において限定的である企業が多いと思います。

 

特にRPAに最も精通しているエンジニアを如何に開発業務に注力させられるか

そして意思疎通の齟齬による出戻りを如何に減らせるかがプロジェクト管理上、重要になります。

 

 

開発そのものではないのですが、エンジニアとの関係の深い工程としてプログラム設計書作成と、テストがあります。

 

一般のシステム開発であれば、SEがその工程に携わる事も多いのですが、

RPAエンジニアが限られている現状を鑑みると彼らをその工程に全投入するのは賢いやり方とは言えません。

 

そこで、開発エンジニアとは別に、プログラム設計書作成とテストを行うチームを設立し分業させるのが有効です。

 

そのチームのメンバーには初期はRPAエンジニア1~数名を入れるのもよいですが、

ゆくゆくはビジネスアナリストの人材を教育してできるようにさせる事が理想です。

 

(参考:分業体制にした場合のRPAプロジェクト体制)

 

 

このプログラム設計書&テストチームですが、

これはRPA開発を担当するエンジニアリソースの確保の観点からも重要ですが、もう一つ別の目的もあります。

 

ビジネスアナリスト/業務コンサルタント側にRPAの動き方・仕様の視点を学ばせて、

To-Beの業務フロー設計のところに役立たせることが狙いとしてあります。

 

このRPAというものは、通常の人間の作業員とは全く異なる「働き方」をするロボットです。

まとまった計算処理は早いですし、24時間働くこともできます。

 

しかし、あいまいな指示系統だとうまく動きませんし、

エクセル内の処理だけでしたらVBAによるマクロのほうが早かったりします。

 

 

このユニークな「RPAロボット」の特徴をしっかり掴んだうえでTo-Beのフローを描いたほうが、

より実現性の高いものが出来、結果出戻りも少なくなることは自明です。

 

特に複雑な業務フローにおいてRPAを導入する段になると、

人間スタッフとRPAロボットとの協業、すみ分け、分担の仕方が、非常に重要になってきます。

 

その時に、しっかりとRPAの仕様を理解したビジネスアナリスト/業務コンサルタントがいるかどうかが、導入成功の鍵を握ると言えます。

 

 

本コラムでは、大規模RPA導入プロジェクトにおける成功の鍵を、「組織体制」の面から述べさせていただきました。

 

それぞれ導入企業によって既存人的リソースの状況も違うので一概には言えないところもありますが、

あとは応用の話になりますので、要点をうまく掴んでいただけたらと思います。

 

多くの会社は、最初のRPA導入業務として経理財務、人事総務、営業事務といったあたりから始めることが多いですが、

まず直面するのがRPAならではの細々とした課題の解決と環境設定、そしてRPAエンジニアのリソース不足です。

 

この点を如何に解消できるかがポイントとなりますが、それには、コーポレートの専任チームを組成することと、

RPAエンジニアを最大限開発にリソース投入できるようにするための人員配置が重要となります。

 

 

本コラムでは「組織体制」からの話となりましたが、

次回コラムでは「運営手法」の面から成功の鍵を探っていきたいと思います。

乞うご期待ください。

 

 

【必見】大規模RPAプロジェクトの進め方 (4/4)

 

 

 

【必見】大規模RPAプロジェクトの進め方 (2/4)

2018.08.14

今回のコラムでは、前回に引き続き、大型RPAプロジェクトを行う際の工程詳細について述べていきたいと思います。

 

前回では、RPA開発プロジェクトならではの特徴と、最初の工程となる「対象業務選出」について簡単に説明させていただきました。

 

(参考)前回コラム:大規模RPAプロジェクトの進め方 (1/4

 

本コラムでは、それ以外の工程についてまずは順を追って説明していきたいと思います。

 

 

RPAプロジェクトの工程

 

参考: RPA導入プロジェクトの工程

 

 

 

工程2. 現状業務分析(As-Is

「現状業務分析」では、選出されたRPA化候補業務について深掘りしていきます。

 

具体的には、現状の作業フローや、発生頻度、リードタイム、業務量等を精査していくことになります。

 

 

このフェーズでは、社内のビジネスアナリスト、外部リソースであれば業務コンサルタントが活躍するフェーズになります。

 

もちろん、実業務を日々行っている現場担当者も知識レベルではできうることではありますが、

フローの書き方など不慣れなところもあるので、ビジネスアナリスト等が担うケースが多いです。

 

 

ただ、こちらのAs-Isと呼ばれる現状の業務分析フェーズですが、あまりにも簡易な作業が対象となる場合、

飛ばしてしまい、次の「業務フロー設計(To-Be)」に飛んでしまうケースもしばしばあります

 

 

例えば、社内システム上の一部入力操作のみをRPA化しようとするような単純なケース場合、

To-Beとなるロボットのフローも容易に想像がつきます。

 

このAs-Isの業務分析は、あくまで次のTo-Beを描くための基礎情報として使うものであり、

To-Beが容易に描けるのであれば、わざわざAs-Isに時間をかける必要はありません

 

PMとしてはこのあたりの柔軟性をもって各案件に接することが求められます。

 

 

一方、人間とロボットの入り混じった、かなり複雑な一連の業務をRPA化しようとする場合

例えば、消費者からの申請書を受け取り、それをシステム入力、さらに上司によるチェック工程が入る、

といった業務となると、やはりAs-Isからしっかりと精査したほうが良いです。

 

上記のような業務となると、OCRといったRPAとは異なる別ツールの導入を併せて検討することになり、

また人間とロボットの分担もしっかりと整理する必要があります。

 

また、そのように複雑な、いくつか作業が繋がってできる業務の場合は、

ロボットを入れることで業務フロー自体が大きく変わる可能性も高いです。

(例えば、人間による都度システム入力から、ロボットによる夜間のバッチ入力に変わる、等)

 

そのようなケースの場合は、やはり手を抜かず、まずは現状の整理から一歩一歩進めていく必要があります。

 

 

工程3. 業務フロー設計(To-Be

こちらのTo-Beの業務フロー設計では、RPAロボット導入後の業務フローを描くことになります。

ここではより分解して述べると、以下に分かれます。

 

3-1. 対象業務のTo-Be業務フロー全体の設計

3-2. 個別システム/IFの画面遷移・操作設計

 

3-1.は、工程2As-Isの業務分析のところでも述べた事と同様で、

対象業務がかなり単純であれば敢えてする必要はありません。

 

この工程が必要となるのは、人間とロボットが複雑に連携するような業務に対してです。

アウトプットのイメージとしては、通常の業務フロー図にロボットの領域が加わったものになります。

 

 

3-2.については、これはほぼどのような対象業務であっても必要になってきます。

会計システム、Webサイト、またはExcelの管理帳票といった、

RPAロボットが触ることになるインターフェースの画面操作、遷移の指示書となります。

 

 

この指示書のイメージですが、各画面の画像を切り取ったものが遷移順に並び、横に補足説明が書いてあるようなものです。

使用されるドキュメントはExcel/PowerPoint/Word等、様々ですが、

こちらの資料を基に、次の工程4.であるプログラム設計書が書かれることになります。

 

 

工程4. プログラム設計書作成

To-Beの仕様が決まったら、次はいよいよプログラムに落とし込む準備に入ります。

工程3までの業務フローでは、まだ「人間側」の設計書であり、「ロボット向け」の設計書とはなっていません

 

前工程で決められたTo-Be業務フローをロボットのロジックに合わせて書き直す必要があります。

 

簡単な例で言うと、forループやif分岐、データテーブル/コレクションと呼ばれる表形式のデータセットの作成、

入力、抽出の仕方などを具体的にイメージしたフローに直すのです。

 

 

また、この工程で、次に必要となる開発/テスト環境の設計も行う必要があります。

実は、RPA開発プロジェクトの現場では、この工程がボトルネックになることが多いです。

 

何故でしょうか。

通常のこのプログラミング設計書の作成はエンジニアの領域であり、システムに詳しい専門職が担当すべき工程です。

 

しかし、前コラムで述べたように、RPA開発エンジニア自体が枯渇している状況になると、

このプログラム設計書作成にリソースを宛がうことが難しくなるのです。

 

 

そうなると、この工程4を飛ばして、

To-Beの業務フローができたらそのままRPAエンジニアに開発依頼をしてしまう誘惑が擡げてきます。

 

しかし、それは後々の不具合の種となり、非常に危険な行為となりますのでお勧めできません。

 

 

このプログラム設計書作成のプロセスは、高度なRPAプログラミング技術は要しません。

しかし、開発に使用するRPAツールの最低限の知識は求められます

 

UiPathであれば、UiPathの仕様、BluePrismであればBluePrismの各機能の基礎知識が求められます。

 

ツール間でそれほど違いはないのですが、やはり、そのあたりを踏まえているのと踏まえていないのとでは、

その後の開発者にとってやり易さが変わります。

 

特に、RPA開発エンジニアが枯渇している昨今の現状においては、ビジネスアナリスト、

外部だと業務コンサルタントと呼ばれている人たちが、この領域まで手掛ける必要もあると考えるべきでしょう。

 

 

工程5. RPA開発/設定

プログラミング設計書ができたら、RPAエンジニアによる開発に進みます。

 

この工程はRPAの世界の中では開発とは呼ばずに「設定」と呼ぶケースもあります。

 

ここで注意する点としては、実際に業務行う現場環境と開発/テスト環境への配慮が挙げられます。

 

何度も言っていますが、RPAは、最終的に現場の業務担当者の代わりにロボットが行うソリューションです。

 

つまり、現場環境で動作できる事が必須要件となります。

しかし、実際にRPAを開発するエンジニア部隊が必ずしも業務担当者と同じシステム環境にいるとは限りません

 

 

そもそも、開発をアウトソースやオフショア等別環境で行う場合、ネットワーク環境も違いますし、

端末(ローカルPC)作動型のRPAを作るのであればPC自体の設定も異なります。

 

このあたりは、何回か開発をすれば小慣れてくると思いますが、最初は特に出戻りが無いように注意が必要です。

 

 

この開発工程については、自社で行わずに、外部のベンダーの活用を検討している企業も多いと思います。

 

それ自体は、否定はしませんが、RPAのプログラムは、

そもそも、一旦開発した後もちょっとした改修が頻繁に発生するものです。

 

 

小さな修正・メンテナンスレベルまで外注しているとコスト面での負担が増えることになりますので、

大なり小なり社内リソースでプログラミングできる体制があったほうが望ましいと言えます。

 

この際に、前工程のプログラム設計書作成において「設計書フォーマットの標準化」が為されていると、

各段に効率が上がりますので、ベンダーや社内開発チームなど複数の開発チームが存在する場合であっても、

設計書フォーマットは統一化することを心がけてください。

 

 

工程6. テスト/修正

開発が終わったら、テスト段階に入ります。

 

これは開発者自身で行うべき単体テストのレベルから、現場担当者が検証すべきユーザーテストまで渡ります。

ここでも重要なのは、先述したように、テスト環境と、実際に動かす現場環境が合っているかどうか気を付けながら進めることになります。

 

 

また、納期重視でクイックな開発がRPAは求められますので、自然と、テスト段階での微修正が発生してしまいがちです。

その場合、やはりクイックにテスト後直せるように事前にコミュケーションをとっておくことも重要です。

 

 

今回のコラムでは、比較的大きなRPA開発プロジェクトにおいて、

各工程の説明および、留意点を述べさせていただきました。

 

次回コラムでは、いよいよ、

開発プロジェクトを効率よく進めるために特にRPAならではで気を付けるべきことを挙げていきたいと思います。

 

乞うご期待ください。

 

 

【必見】大規模RPAプロジェクトの進め方 (3/4)

 

 

 

【必見】大規模RPAプロジェクトの進め方 (1/4)

2018.08.13

今回のコラムでは、比較的大規模にRPAの導入を検討しているケースにおけるプロジェクト進行の要点をまとめていきたいと思います。

 

 

大規模プロジェクトとなった場合、求められるRPA対象業務数(案件数)も膨大となり、

また関係してくる各部署ステークホルダーも複雑になります。

 

小さな目のプロジェクトであれば、まずは一部の部署だけでPOCを行って、

徐々に対象領域を増やしていく、、といった順序でも許容されますが、

大規模プロジェクトとなった場合、「●月まで●●案件のRPAプログラムを完成し、●●時間を削減せよ

というような命題が既定としてあり、その目標を完遂するための効率的なプロジェクト運営が求められる傾向にあります。

 

 

RPA開発プロジェクトの特徴

 

基本的にRPAの開発プロジェクトも、他のシステム開発案件と同様の工程を経ます。

従って、このRPAプロジェクトを進める上での要諦も、通常のシステム開発プロジェクトと大きな差はありません。

 

ただ、いくつかのポイントについてはRPAならではの特徴が存在します。

 

 

特徴1: 早期実現の要請

一つは、RPAというものが早期の実行を要求される傾向にあることです。

 

他の大規模システムと違い、RPAというものは、そもそも今までローカルPCで行っていた単純作業を自動化させるのに特化したツールであり、

経営者側とすれば早期の実行による社員の業務負荷軽減を期待してしまうものです。

 

RPAは大規模システムのような高度で入り組んだシステム設計を必要とせず、

それよりも納期の速さが故にいかに簡略化してクイックに開発を進められるかが肝になります。

 

もちろん、要件定義やプログラム設計書レベルのものは必要ではありますが、

例えば、テスト仕様書等時間をかけてじっくり作って準備するよりかは、

ユーザーテストをして早めに修正点を洗い出し完成に持っていくような柔軟性が求められます

 

 

特徴2: 低コストで開発 & 社内教育の必要性

もう一つの特徴は、RPAの案件というものは、開発予算が低めに抑えられる傾向にあり、

エンジニア人材の確保がボトルネックになりがちだということです。

 

RPAはもともと、システム要件とならないような細々とした多種多様な業務の自動化が求められる領域であり、

開発対象となる案件は一つ一つは簡易で小さなものであってもその数は膨大となる傾向にあります。

 

一案件で見るとそれによる人間の業務低減効果は限定的であり、一件一件低予算で開発をこなさなければ、

経済合理性が成り立たない状況になります。

 

従って、RPAのプロジェクトの場合、最初の時期は外部パートナー会社の協力を仰ぐことになりますが、

ゆくゆくはユーザー自社の社員で開発・運用をしていくことが求められるケースが多いです。

 

 

そうなると、社内エンジニアの「教育」という点が重要になってくるわけですが、このRPA、世の中に出回る多くのツールは、

そもそもの思想として現場担当者レベル(人事や経理など)でも自分達で「作れる」ことを目指し、

そのためのUIになってはいますが、その割には難しいのが、何と言いますか、絶妙なところです。

 

特に大規模RPAプロジェクトになると、オブジェクト指向に基づいたモジュール管理、統一ルールの徹底などが求められるため、

やはり社内リソースに任すにしてもIT部門の様な専門のエンジニア職のほうが望ましいと言えます。

 

 

特徴3: エンジニア/RPAに強いビジネスアナリストの人材枯渇

上記で述べた、エンジニアによる開発予算が抑えられがちであることとも関係していますが、

もう一つのRPAの特徴として、人材、特にエンジニアの人材の確保がボトルネックとなる傾向が挙げられます。

 

 

RPAは比較的新しい技術であり、現在世の中には、UiPathBluePrismBizRoboWinActorといったツールが出回っておりますが、

その扱いに熟練した技術者、エンジニアは、まだその需要に対して十分な供給を果たせていません。

 

エンジニアとしてもRPA開発ツールが複数存在するために、

UiPathはできるけどBluePrismはできない。。。

といったケースが出てきてしまい、ますます特定のツールに特化した技術者を確保するのが難しい状況にあります。

 

 

また、この人材の枯渇でいうと、To-Beの業務フローを書くビジネスアナリストにも同様のことは言えます。

 

ビジネスアナリストは厳密な意味ではエンジニアではありませんが、ことRPAのプロジェクトの場合、

業務フロー設計者もRPAロボットの知識が求められます

 

これは考えてみれば当然で、RPAでは今までの通常の人的リソースとは全く異なった特徴を持つ「ロボット」に業務を肩代わりさせることになる訳であり、

つまり、その「ロボット」の動き方について専門の知識を十分持っていないとTo-Beのフローが書けないからです。

 

そのような「RPAのエンジニア知識」を有したビジネスアナリストは、残念ながら、現在まだ多くは育っておらず、

リソースの確保が課題となっています。

 

このビジネスアナリストのリソース問題は、RPAの対象が簡易な単純作業だけの段階であれば、顕在化しないと思います。

 

しかし、そのような小さな単純作業のRPA化フェーズが終わり、

より高度な、ロボットと人間の分担が入り組んだ複雑な業務フローを組むようなケースになってくると、

切実な問題として直面することになると思います。

 

 

RPAプロジェクトの工程

 

次に、より具体的にRPAを導入する際の個別工程について話していきたいと思います。

比較的大規模なプロジェクトにおけるRPA導入のステップと関係ロールを下記に記しました。

 

まず、こちらの各工程について簡単に説明したいと思います。

RPAでは先述したように、早期の実行が求められることもあり、

大きめのプロジェクトであっても通常のシステム開発よりも簡略化される傾向にあります。

 

 

参考: RPA導入プロジェクトの工程

 

 

工程1. 対象業務選出

ここでは、RPA対象となる業務をリストアップする、アイデアジェネレーションのフェーズになります。

 

この工程では、実業務をしているユーザー部門の担当者が主役となりますが、

RPAの知識が無いケースが殆どですので、事前にビジネスアナリストもしくは業務コンサルタントが入って、

RPAとはどのようなものか、どのような業務がRPAに向いているのか事前に勉強会を開いておくことをお勧めします。

 

 

一旦、コツがつかめれば、現場担当者から能動的に様々なロボット化のアイデアが出て来ると思います。

 

ただ、それでもやはりアイデアが出てこない場合は、まず各現場部署に自身の業務の棚卸し(リスト化)をさせて、

そのリストをもとにビジネスアナリスト/業務コンサルタントとディスカッションセッションを設けても良いかもしれません。

 

 

あと、この工程で大事なことは、「ざっくり」で構いませんので、

月間業務量、頻度、定型作業の割合、使用アプリケーション等、「RPA化との相性を測れる情報」も記載しておくことです。

 

その情報により、挙げられたリストの内どの業務からRPA化の手をつければいいのか判断ができます。

もちろん、最初に手をつけるべきは「簡単な割に削減効果の大きい業務」からになります。

  

  

今回のコラムでは、比較的大きなRPA開発プロジェクトの特徴と、

最初の「RPA対象業務の選出の工程」について説明をさせていただきました。

 

次回のコラムでは、さらに他の工程の説明および、留意点を述べていきたいと思います。乞うご期待ください。

 

 

次のコラム:【必見】大規模RPAプロジェクトの進め方 (2/4)

 

 

 

【BPO×経理】経理業務とBPOにおける直近の情勢と課題

2018.08.10

BPOサービス市場

 

経済産業省が2015年にBPO(アウトソーシング)サービスに関する資料を公表していますが、

それによると日本におけるBPO市場規模は、1,600,000百万円となっています。

 

業務別の市場規規模は以下のとおりとなっています。

 

 

(間接業務)

コンタクトセンター 360,000百万円:コールセンター

ヘルプデスク 126,240百万円:問い合わせ対応

フルフィルメント 30,400百万円:EC販売、在庫管理、ピッキング

人事 80,000百万円:給与計算、社会保険手続き

福利厚生 36,800百万円:福利厚生業務

総務 12,480百万円:備品管理、文書管理

経理 41,280百万円:記帳代行、支払管理、債権債務管理

 

(直接業務)

購買・調達 3,520百万円:購買調達

営業 68,800百万円:営業代行

コア部門単純業務 564,800百万円:企業のコア部門が行う業務

業界固有業務 62,400百万円:特定業界の独自業務

その他 213,280百万円:包括的なサービスなど

 

 

市場規模は2022年までの年間平均成長率は3%前後という調査結果もあります。

 

また日本はアメリカに比べ、コア業務への集中を意図したBPO等の活用が遅れているため、

日本でのBPO市場は拡大を続ける見込みです。

 

 

なぜBPOサービスの必要性が高まっているかというと、働き方が変わったからということに尽きると思います。

これまでの、一人当たりのアウトプット量を最大化させる、高度成長期の製造業のような働き方から、

クリエイティビティが求められる働き方に変化しつつあります。

 

 

2014年に経済産業省から「サービス産業の高付加価値化に関する研究会の報告書」が公表されました。

 

この報告書が作成された背景として次の記載があります。

 

 

我が国のサービス産業は、GDPの約7割を占め、雇用の面からも大きなウェイトを占めており、経済全体に与える影響が高まっています。我が国経済の再生やデフレ脱却のためには、サービス産業の生産性向上・高付加価値化が必要です。日本再興戦略(平成256月閣議決定)においても、「付加価値の高いサービス産業の創出を図る」との方針が示されています。

 

 

また、サービス産業の生産性向上・高付加価値化の実現に向けた主な検討事項の一つとして、

「ビジネス支援サービスの活用促進」が掲げられています。

 

その調査報告コメントとして次の記述がありました。

 

 

企業においては、BPO サービス等の外部リソース(ビジネス支援サービス)を戦略的に活用することで、当該業務のコスト削減のみならず、ビジネスプロセス全体の見直し等につながると言われている。実際、ビジネス支援サービスを利用したサービス事業者の多くは、経営資源のコア業務への集中、コスト削減、業務の効率化といった生産性・付加価値向上の効果を得ている。ビジネス支援サービスは、それ自体が成長の期待できる一つのサービス産業であるとともに、他の産業の生産性への波及効果も大きく、これを促進していくことはサービス産業の高生産性・高付加価値化のための重要な手段の一つと考えられる。

 

 

事業を進める上では様々な「やるべきこと」が出てきますが、時間は有限です。

BPOサービスによって優先順位を明確化し、「しないこと」を積極的に決めることが重要です。

 

 

BPO導入の目的(経理財務業務の場合)

 

経理財務業務にBPOを導入する目的は、

「経営資源(人的リソース)をコア業務に集中させる」

「コスト削減」

「業務プロセスの標準化」

「社員退職などに対する業務継続性の確保」

などがあります。

 

どの目的も重要ですが、BPO導入の際は、どの目的を最重要目的とするのかを明確に決めておくことが大切です。

 

 

「経営資源(人的リソース)をコア業務に集中させる」という目的の場合、

経理財務部門におけるコア業務、ノンコア業務の分類は概ね以下のように区分できると思います。

 

 

(コア業務)

  • 管理会計による経営分析
  • 原価計算制度の構築
  • 予実管理
  • 事業計画作成
  • 資金調達戦略策定
  • 投資戦略策定など

 

(ノンコア業務)

  • 会計ソフトへの会計記帳
  • 請求書発行
  • 取引業者への支払
  • 経費精算など

 

 

現状の業務ではノンコア業務をこなすことで手一杯で、

コア業務を行えない又はコア業務を習得するための時間がないなどの課題がある場合、

BPOを導入することでコア業務に集中できたり、コア業務を習得するための時間が確保できます

 

これによって、経営判断を行うために必要な情報を管理会計で整備する、

原価管理を適切に行うための原価計算制度を構築する、

企業価値をあげるためのファイナンスなどのノウハウが社内に蓄積するため、

他社との競争優位性が高められることが期待できます。

 

 

経理財務部門の課題

人材不足は他の業種同様、経理財務部門にとっても生じています。

 

経理財務部員が1人程度の中小企業、経理財務部員育成途中の新興上場企業、大企業の子会社で経理財務部員が少数の会社などの会社で、

ベテラン人員が退職すると、経理財務部門は混乱し、在職者に過度の負担がかかることになります。

 

特に中小企業などは、業務が標準化されておらず、マニュアルも十分に整備されていないブラックボックス化状態であることが多いです。

 

十分な引継ぎを受けないまま、在職者によってさらなるブラックボックス化が図られ、

ルーティンワークに飽き、他の会社に転職を考えるようになる悪循環が生まれます。

 

退職者の穴埋めで社員を採用する場合、ある程度の経理財務知識がある社員を採用するには、

多額のコストがかかることが多いです。

 

 

このような課題を解決するソリューションの一つにBPOがあります。

 

BPOを導入するために業務の標準化を図り、マニュアルを整備する、

そしてノンコア業務であるルーティンワークはBPOすることで、経理財務部員がコア業務に注力できる環境が整います。

 

 

コア業務に注力できれば、本人のスキルアップや、やりがいにつながり、

経理財務部門の悪循環から解放されることが期待できます。

 

 

経理財務部門で発生する不正

経理財務部門で発生する不正行為の一つに現金預金の横領があります。

 

横領事件で逮捕されることが多いのは、「経理」として働いていた人です。

 

ニュースになる横領事件では、億単位の金額が横領されていることが多いですが、

その金額がすべて返済されることは少ないようです。

 

横領被害は会社にとって大きな損失になり、取引先や利害関係者への信頼にも影響することになります。

 

 

大企業などでは、経理財務部門の職員が複数人いるため、

「複数の人が業務を行っている」

「一定期間で配置転換がある」

「上司の適正なチェックが入る」

「経理(会計記帳など)と財務(現預金の入出金)が分離されている」

などの環境があるため、比較的横領などの不正は発生しにくいです。

 

 

一方で中小企業などの経理財務部門は1人で経理と財務を兼任しているケースが多いため、

他の人の目が届かず、チェック機能が働かないことがあります。

このような環境下では、横領などの不正が発生しやすくなります

 

 

このように不正が発生しやすい環境から不正が発生しにくい環境にする場合にもBPOは有用であると考えます。

 

例えば、経理(会計記帳など)は経理職員が行い、その承認は顧問の会計事務所に依頼します。

 

一方財務は、BPO会社職員が行い、その承認はBPO会社職員の上席者が行うことにより、

経理と財務が分かれさらに承認者も異なるので統制が働き、不正が発生しにくい環境になります

 

このように不正防止策の一つとしてもBPOは活用できます。

 

上記のように、BPOを経理財務部門における課題解決や不正防止策とし活用しつつ、

コア業務に注力することによって、他社との競争優位性を高めたり、

経営効率を上げていくことが大きく期待できます。

 

 

 

【導入事例】大企業人事業務におけるRPA活用事例

2018.08.09

 今までのコラムでは、中小企業経理業務のRPA活用事例を紹介しましたが、今回は異なる視点でRPAの活用を見ていきたいと思います。

 

中小企業経理業務におけるRPAの活用事例(二)

 

 業界や具体的な業務にかかわらず、RPAが最も得意な業務は大まかに二つ共通の特徴があります。

 

すなわち、

①大量に繰り返される作業

②ルールが明確化されている作業

です。

 

 

更に、365日×24時間稼働可能、人間より精度が高くコストが低いなどのメリットも挙げられます。

 

経理業務の中に、RPA導入にとても向いている業務がたくさんあるのことを既に過去のコラムで紹介しました。

 

経理業務をRPA化すれば、費用対効果は抜群であることは言うまでもないでしょう。

 

では、「せっかくRPA導入するのであれば、経理以外の業務もRPA化すればよいのではないか?」という考えも自然に出てくるはずです。

そして、今回は人事業務のRPA活用事例を見ていきましょう。

 

 

 企業Aは国内の総合ITグループです。

業務範囲はECサイト、金融、保険など様々で、従業員数5,000人以上の規模になります。

このような規模にもなると、たとえとてもシンプルな業務であっても毎月大量に単純・定型作業が発生することは想像しやすいですね。

 

例えば、「異動情報登録」という作業は月に2,000~3,000件発生しています。

この「異動情報登録」業務は自然、A社のRPA導入対象業務となります。

では、まずこの業務から見ていきましょう。

 

 

異動情報登録業務

 A社は従業員が多いため、毎月人事異動が頻繁に発生しています。

特に毎年3月や9月は集中的に発生するため、異動情報をシステムに登録するだけで人事部門は大量なリソースを割かれます。

 

業務内容を簡単にいうと、以下の図1のようになります:

 

 

まず、毎月各部門から異動情報が人事部あてに届きます(人事稟議などもありますが、本業務では考慮しません)。

 

人事部が各部門からの情報を全てまとめて、その後一項目ずつ人事システムに入力します。

 

これがこの業務のすべての内容です。

 

業務の内容はとてもシンプルで、イメージしやすいでしょう。

ただし、量が多くなると、とてもハードな作業になります。

 

従業員のスキルによって、一件の登録は5分~10分かかります。

 

A社の場合、月に2,000件あると計算すると、毎月優に300時間を超える作業時間が発生するでしょう。

 

この業務をRPA化すると、300時間が10時間以内になると予想されます。

RPA化すると、業務の流れは以下の図2のようになります:

 

 

各部門がもともと人事部あてに送信していた異動情報を共有フォルダーに入れることになります。

 

そして人事部の代わりに、RPAが毎日決まった時間で共有フォルダーの中のファイル(エクセルファイル)をチェックし、

それに基づいて、自動的に人事システムにログインして、一行一行、項目を入力していきます。

 

 

もちろん、処理できないイレギュラーな事態が発生することも想定します。

 

例えば情報が間違っていることや、そもそも必要な情報がそろっていないなどがあると考えられます。

この場合、RPAが自動でイレギュラーの情報を保存しておき、処理が終わった後に人事部の担当者にメールを送信します。

 

このプロセスはすべてRPAが実行するので、人間による関与は全く必要ありません。

人事部の担当者がRPAからの通知メールを受け取った後、イレギュラーになっている項目をチェックし、

手入力が必要か該当部署に再度確認する必要があるかなどを見て、それぞれ実行します。

 

処理時間はおよそ10時間以内で終わるでしょう。

 

 

 もちろん、実際RPAを導入する際には色々と細かい点に注意しなければなりません。

例えば、元々人間が入力していた時は、各部署からの異動情報の書式は少しずれても大した問題にはなりません。

 

情報さえ合っていれば人がそれを認識し、修正することが簡単にできます。

ただし、RPAとなると、この人間にとって簡単なことができないのです

 

そこで、フォーマットに合わせた書式を使ったり、RPAが読みやすいフォーマットを作ったりすることが必要です。

 

 ここで、もう一つの疑問があります。

A社の人事システムに「まとめてインポート」のよう機能はないでしょうか?

あるとしたらなぜ使わないでしょうか?

 

実際のところ、A社が使っている人事システムは「まとめてインポート」機能はあります。

 

ただし、この機能を使うには非常に複雑なマクロが含まれるフォーマットを作る必要がありますし、

インポートする際にうまくいかない場合が多発します。

 

システムを変える考え方ももちろんありますが、コストの問題があるだけでなく、

この膨大なシステムを変えること自体が極めて難しいでしょう。

 

こういう状況では、RPAによりロボットが人の代わりに作業することが最も現実的な選択肢になるでしょう。

 

 

契約更新業務&兼務発令業務

 「契約更新業務」というのは文字通り、A社の契約社員とアルバイト従業員の契約期間を更新するたびに発生する業務のことです。

 

「兼務発令」はA社の従業員が自分自身のメイン業務以外、他の業務も兼務する場合発生する業務のことです。

本来であれば別業務だが、ここで一緒に紹介する理由はこの二つの業務の基本フローは極めて似ているからです。図3をご覧ください:

 

 

 

この二つの業務がすることは同じフローで表現できます。

さらに、よく見ると、図1と酷似していませんか?

実は、上で紹介した「異動情報登録」ともほぼ同じ流れになります。

 

 

まず各部署から契約更新の情報や兼務発令の情報を人事部がまとめて、

その後同じ人事システムに入力するのです。

 

ここまで来れば、RPA化の基本的な考え方もイメージつくでしょう:

 

 

 

こちらも「異動情報登録業務」と同じ流れになります。

 

まず、各部署が契約更新と兼務発令の情報が記載されているエクセルファイルを共有フォルダーにアップします。

 

そして、RPAが指定された時間にフォルダーからエクセルファイルの情報を読み取り、これらの情報を人事システムに入力します。

 

処理が全て完了したら処理結果やイレギュラー情報をメールで人事部の担当者に送信をします。

最後に、担当者はRPAが処理し切れなかった項目を手作業でカバーします。

 

 

ここで、RPAの一つの大きいメリットをお伝えいたします。

それは、ロボットの「再利用」です。

 

業務フローが共通しており、操作対象となるシステムも同じため、ロボットの設計図もほぼ変わりません。

 

そのため、例えば「異動情報登録業務」のロボットをまず開発したら、

その次の「契約更新」と「兼務発令」業務の開発がより簡単になります。

 

なぜなら、「異動情報登録業務」ロボットの「パーツ」を改造すれば、

「契約更新」と「兼務発令」のロボットにも使えるからです。

 

改造するポイントとしては、例えば、入力する項目、ボタンの位置、アクセスするページなどがあります。

 

もちろん、各業務に対してそれなりの工夫は必要ですが、ゼロから開発するよりは簡単になります。

ここの「簡単」はコストが低くなることと、時間の短縮を意味する場合が多いです。

 

 

まとめ

 今回は三つの人事業務を中心にRPAの運用を紹介しました。

 

ポイントとしてはまず、単純な業務でも大企業にとって大きい削減効果があります

 

また、類似する業務を多くRPA化すればするほど、1業務当たりの導入コストが低くなり、さらに費用対効果が高くなります

 

本文のA社のように、異なる業務で開発済のロボット「パーツ」を再利用することができるからです

 

A社の場合は最初からこの3つの業務をRPA化前提で導入し、

その後「パーツ」が活用できることに気づきましたが、もちろん、まず1業務をRPA化し、

他に類似した業務を社内で探すこともできるでしょう。

 

この場合、ロボットの「パーツ」が様々な部門と業務で活かせるようになると思います。

 

 

 

経理財務業務におけるRPA導入機会vol.3

2018.08.08

はじめに

RPARobotic Process Automation-ロボットによる業務自動化)は、近年のBPOの最前線でよく聞かれるワードの一つです。

 

これまで人間が行ってきた定型の作業や業務をPC内のロボットが仮想知的労働者(=Digital Labor)として代行することで、

業務効率と品質の向上、コストダウンが期待できます。

 

ただひと口に「自動化」といっても、

抽象的すぎてどんな業務にRPAを導入できるのかいまひとつ想像がつきにくいかもしれません。

 

今回は多くの企業で実際にRPAの導入が進められている業務のうち、

経理財務業務でのRPA導入機会を前回に引き続いてご紹介させていただきます。

 

■前回記事

経理財務業務におけるRPA導入機会【vol.2】

 

 

導入が検討できる業務

今回はこれまた手作業が多く発生しがちな「請求書発行~入金消込業務フロー」の自動化を検討してみます。

 

この部分は債権管理の観点において重要な業務ですが、その実多くの手作業が発生し、

ヒューマンエラーのリスクを抱えている会社様もいらっしゃるのではないでしょうか。

 

この手のヒューマンエラーは会計上の問題だけでなく、顧客からの信用問題に直結するため、

業務の正確性が多分に求められます。

 

 

また請求書の性質上、作業が月末/月初に集中し業務の偏りが発生しやすいため、

現状のフローの中だけでは業務効率化が難しい部分でもあります。

 

このような【請求書発行~入金消込】業務はRPAを駆使して、効率化してしまいましょう!

 

 

 

 

  • 請求書発行~送付

各部署から日々発行される請求書。

 

11件には大した労力がかかりませんが、期日前になって申請が集中し、

その分一時的な労働力がつぎ込まれていることが多いのが事実。

 

その業務を効率的かつ正確に処理するには、自社の請求書発行の仕組みとそれに適合するロボットの開発が肝要です。

 

 

【請求書発行システムを利用している場合】

手軽かつ安価な業務効率化の手段として活用されることの多いクラウド型請求書システム

導入を進めている企業様も多いのではないでしょうか。

 

近年の請求書発行システムは、作成から送付まで安価で手広いサービスをウリにしているところが多く非常に便利です。

 

サービスの内容は各社とも様々。

中にはWEBバンキングや会計ソフトとの連携が可能なアプリケーションも存在しますが、

高価であったり、対応ソフトが限られていたり(全ワークフローを同系列のシステムに組み替える必要があるなど)するため、

今回は請求書発行~送付まで対応した一般的なクラウドサービスの利用を想定します。

 

 

各社員が販売明細書や売上報告書を基に顧客宛ての請求書を発行します。

多くのアプリケーションでは請求書が発行された段階で送付手続きが進行するため、

非常にスムーズに請求書を作成/送付することができるでしょう。

 

後段でロボットが参照し、そのデータを基に入力/照合を進めていくため、

請求書フォーマットはある程度統一されたものを使用できるように、あらかじめ各部署ですり合わせが必要です。

 

また、入力時も金額差異などが発生しないように、細心の注意を払って入力を進めていきましょう。

 

 

【紙ベースの請求書を発行している場合】

中小企業の中には請求書を紙ベースで発行し、直接顧客のもとへ発送しているところも多いでしょう。

 

自動化を検討する際は「Excelで請求書を作成し、電子ファイルで送付する」という手段が考えられます。

 

Excelで作成すれば、各請求書をロボットが確認し後段の作業に必要なデータを抽出しやすく、

また電子ファイル送付なら、自動メールをロボットにプログラムしておけば、簡単に発行~送付までを効率化できます。

 

具体的には、まずフォルダを作成し、そこに当月分の請求書をまとめて保管しておきます。

次にロボットが決められた日時にそのフォルダを巡回するように設定し、請求書内容を確認。

 

顧客IDなどから別途作成する「顧客マスタ」と自動で紐づけ、

送付先アドレスを抽出し自動的にメールを送付させる仕組みを作ります。

 

仕組み自体は簡単なので、手っ取り早く業務効率化が図れますが、

反面請求書データ送付を認めない(あるいは推奨されていない)企業が一定数存在するのも事実。

 

前提として請求書送付について双方の合意が必要になります。

電子ファイルでの送付が困難な顧客へは、郵送での対応をするなどしましょう。

 

 

  • 仕訳(売掛金計上)

発行された請求書を参照し、会計ソフトに売掛金として計上します。

 

 

【請求書発行システムを利用している場合】

発行の手続きが完了した請求書をロボットが確認し、会計ソフトに1件ずつ売掛金を計上していきます。

(この時点で請求書内容に不備がないように、あらかじめシステム上に承認機能を付与しておけば安心です。)

 

この際会計ソフトと連動するようにあらかじめ、

システムマスタ上と会計ソフト上の企業名などの表記を統一しておく必要があります。

 

 

自社独自の決まりで、より詳細な情報を会計ソフトに入力する必要がある場合(例えば金額の内訳入力など)は、

システムのフォーマットを変更させる、あるいは「顧客マスタ」から追記情報を取得/入力するなどで対応が可能です。

 

ただし、あまりに多くの例外的処理をロボットに実行させようとすると、必要なロボット数が増えてしまいます

 

費用対効果を考え、場合によっては例外処理を手作業業務として残し

定型化が可能な大部分の業務を自動化する方法をとるなどして、検証を進めていく必要があります。

 

 

【紙ベースの請求書を発行している場合】

フォルダに集約された請求書から必要情報を取得し、会計ソフトに転記していきます。

基本的にはシステムを利用している場合と同様です。

 

売掛金計上が済んだ請求書には、請求書内に「計上済みフラグ」を自動的に立てておきます。

これは次回以降ロボットが作動しても、二重計上をしないようにするためのロジックに必要となってきます。

 

 

  • 集計

発生月ごとに請求書発行一覧を作成します。

この請求書発行一覧上で債権管理を行います。

 

後段の「入金消込」時には、入金のあったものから明細を消し込んでいきます。

 

 

【請求書発行システムを利用している場合】

各社が展開するサービスの中には、WEBバンキングと連動し、

システム上で入金消込を実施できる機能を持ったものも登場しています。

 

しかし自社システムでそういった機能がない場合は別途一覧形式で集計する必要があります

幸い多くのクラウドサービスにおいて、任意の期間で発行された請求書情報をCSVファイルで取得できるので、作成自体は手間になりません。

 

その他必要な情報は「顧客マスタ」を参照し、付与させます。

 

 

 

 

【紙ベースの請求書を発行している場合】

こちらでは、フォルダに集められた請求書の内容をロボットが確認して一覧表を自動作成します。

 

売掛金計上が済んだ請求書から「金額」「顧客ID」「顧客名」などを抜き出し、Excelに反映していきます。

 

 

  • 入金消込

WEBバンキングを参照し、入金のあった請求書を消し込んでいきます

 

 

【請求書発行システムを利用している場合/紙ベースの請求書を発行している場合】

ロボットがWEBバンキングの入金情報を取得し、

請求書発行一覧から該当請求書を入金済みとして消し込んでいきます(入金日を入力)。

 

この際注意しなければならないのは、WEBバンキングに登録されている口座名の表記です。

 

口座名の多くは半角カナで表記されていることが多いので、

そのままではロボットが請求書発行一覧と照合することができません。

 

そのため、あらかじめ「顧客マスタ」にそれぞれWEBバンキングでの名称を入力しておき、

入金消込実施時に参照させる必要があります。

 

 

また、請求書内容によっては手数料のやり取りから振込金額が不一致となる場合もあります。

 

そういった場合は、ある程度の金額幅をロボットに設定し、

入金消込を実施させることも検討する必要があるかもしれません。

 

一定期日を以っても入金がない請求書については、自動でアラートを飛ばし通知し、

催促対応を実施することも可能です。

 

 

  • 仕訳(売掛金計上)

 

【請求書発行システムを利用している場合/紙ベースの請求書を発行している場合】

請求書発行一覧を参照し、入金消込が済んだ明細から、売掛金消込を実施していきます。

 

こちらは、②で計上した売掛金を消し込んでいくだけなので、同様のロジックでロボットに実施させることが可能です。

 

ただし一連の業務において、都度人間の目で適切な処理がなされているか確認し、正確性を担保することが肝要です。

 

 

さいごに

今回のコラムでは経理財務業務におけるRPA導入機会をご紹介しました。

 

このほかにも人事/総務部門などのバックオフィスでの活用が進んでいます。

RPA導入時まず検討するべきは、

 

  • 手作業で多くの業務時間を要しているところはどこか
  • 一連の業務を定型化できるか、例外処理はあるか
  • 自動化によりどれだけの労力/業務時間を削減できそうか

 

という観点での業務内容の見直しです。

 

そのため開発の前段階として「業務の棚卸」を実施していくことになります。

 

今すぐロボット開発/導入は無理でも、一度自社の業務フローを可視化することは、

業務効率化の第一歩です。

 

この際にぜひ一度検討してみてはいかがでしょうか。

 

 

 

【UiPath小ネタ集】開発で使用する関数Tips

2018.08.07

今回はUiPath開発中によく使用するアクティビティや関数を紹介しようと思います。

 

 

A.ファイル操作関連

ファイルやフォルダを操作するアクティビティは、アクティビティツリーの「System―File」の中にあります。

 

 

これらのアクティビティを扱うためには、ロボットが現在どのフォルダ上で作業をしているか

また、対象となるファイルが、どのフォルダ内に存在するか、意識する必要があります。

 

 

A-1 カレントフォルダ取得

ロボットが現在どのフォルダ内で作業をしているかを調べるには、Directory.GetCurrentDirectory関数を使用します。

この関数は、現在ロボットが作業場所としているフォルダのパスを、String型で返してくれます。

下図は、「C:\tmp」フォルダ内のXAMLでロボットを動かしている例です。

 

 

Dirctory.GetCurrentDirectory関数で得られたカレントディレクトリパスが、

Write Lineアクティビティにより、Outputパネルに出力されました。

 

 

A-2 フォルダ移動

Directory.SetCurrentDirectory関数に、引数でフォルダパスを与えてあげると、ロボットの作業場所をそのフォルダに変更することができます。

 

この関数は、別のフォルダに移動するだけで、値を返すことはしないので、

先ほどのGetCurrentDirectory関数と同様にAssignアクティビティで使用しようとすると、エラーになってしまいます

 

このような場合は、Assignアクティビティの代わりに、Invoke Codeアクティビティを使用するとよいです。

 

 

1つめのWrite Lineアクティビティでは、「C:\tmp」というカレントディレクトリパスが表示されています。

 

Invoke Codeアクティビティ内で実行されたDirectory.SetCurrentDirectory(“Folder A”)関数により、

カレントディレクトリが「C:\tmp\Folder A」に変更されたことが、2つめのWrite Lineアクティビティにより確認できます。

 

 

A-3 ファイル一覧、フォルダ一覧取得

ファイルの一覧を取得するときは、Directory.GetFiles関数を使用します。

 

対象となるフォルダを引数で与えれば、そのフォルダの中にあるフォルダは除いて、ファイルのみを取得してくれます。

 

ファイルは1つとは限りませんから、ストリング配列型で結果を受け取ることになります。

下図のようにファイルとフォルダが複数存在するフォルダで実行してみましょう。

 

 

Directory.GetFiles(“C:\tmp”)関数で得られた複数の結果を、For Eachアクティビティにより、

ひとつずつ取り出して、Write LineアクティビティでOutputパネルに出力しています。

「C:\tmp」の中のファイルのみが表示されていることがわかります。

 

 

引数を追加することにより、取得するファイル名を指定することもできます

このとき、ワイルドカードを使用できます。

 

 

Directory.GetFiles(“C:\tmp”,”*docx”)関数により、「C:\tmp」フォルダの中で、

ファイル名が「docx」で終わるものだけが表示されました。

 

第2引数は、あくまでファイル名の指定であって、検索ワードではありません

そのため、「*」を外して、Directory.GetFiles(“C:\tmp”,”docx”)としてしまうと、上記のケースでは、何も表示されなくなります。

「docx」に一致するファイル名しか該当しなくなるからです。

 

 

Directory.GetDirectories関数は、Directory.GetFiles関数とは逆に、フォルダの一覧だけを取得してくれます。

 

 

対象フォルダの指定の仕方や、名前を指定する方法は、Directory.GetFiles関数と同じです。

 

 

B.文字列操作関連

Webやファイルから読み込んだ文字列を操作するときに役に立つ関数を紹介します。

 

 

B-1 トリミング

文字列の前後に余分な空白があるときは、Trim関数で除去できます。

 

下図の例では、最初、「い」と「は」が、それぞれ半角スペースと全角スペースで挟まれていますが、

Trim関数により前後の余分なスペースが削除されることがわかります。

 

 

結果がわかりやすくなるように、Trim関数によりトリミングされた文字列の前後を、「@」で挟んでいます。

 

文字列の前後にあったスペースだけが削除され、文字列の中に含まれているスペースは残されていることがわかります。

 

 

B-2 部分指定

文字列のうち、一部だけを使用したい場合は、Substring関数を使用します。

使用する部分が、X文字列目からY文字だとすると、Substring(X, Y)となります。

ただし、最初の文字は一番目ではなくゼロ番目と解釈されるので、注意が必要です。

 

 

「一二三四五六七」という7文字の文字列の、2番目(ゼロからカウントするため、指定する数字は1)から3文字だけが表示されました。

文字列の最後のZ文字だけを使用したい場合は、Substring関数とCount関数を組み合わせて使用します。

Countは、文字列の長さを計算してくれる関数です。

 

 

「一二三四五六七」は7文字なので、Count関数の結果は7になります。

Substring(4,3)が実行されたため、5、6、7文字目、つまり、最後の3文字が表示されました。

 

 

C.Excel、データテーブル関連

Excelやデータテーブルを扱う際に役立つ関数を紹介します。

 

 

C-1 Excelシート指定方法

通常は、Read Rangeアクティビティを使用する際、

対象ワークシートをワークシート名で指定することが多いと思いますが、ワークシート番号で指定することもできます。

 

 

上図のようなExcelファイルの、すべてのワークシートに対して、同じ作業を行う場合を考えます。

 

下図の例では、for eachアクティビティでワークシート名を順番に指定しながら、

読み込んだワークシートの内容を、output data tableアクティビティでString型に変換してから表示しています。

 

 

同じことをワークシート番号で行ってみましょう。

事前準備として、Excel Application Scopeアクティビティで、対象ワークブックの変数を取得しておきます。

 

Excel Application ScopeアクティビティのプロパティのOutput―Workbookの欄に、

ワークブック変数(WorkbookApplication型)を設定して、値を取得します。

 

取得したワークブック変数に対し、GetSheets関数を使用すると、総ワークシート数を取得したり、

N番目のワークシートを指定したりできるようになります。

 

 

Excel Application ScopeアクティビティのプロパティのOutput―Workbookの欄に、

ワークブック変数(WorkbookApplication型)を設定して、値を取得します。

 

 

C-2 Build data tableアクティビティの列の入れ替え

Build data tableアクティビティで列名を指定しながら表を作成している最中に、

列の順番を入れ替えたくなったりすることがあります。

 

しかし、このアクティビティでは、列を追加することはできても、途中に挿入することはできません。

このようなときは、一度UiPath StudioでXAMLを保存して閉じてから、テキストエディタでXAMLを直接編集してしまうと楽です。

 

 

上図のデータテーブルの「失点」列と「得点」列をテキストエディタで入れ替えてみましょう

XAMLをテキストエディタで開き、該当箇所を検索します。

 

 

ちょっとわかりづらいですが、オレンジ色の部分の「失点」と「得点」を入れ替えて保存します。

 

 

UiPath StudioでXAMLを開いてみます。

 

 

「得点」と「失点」が入れ替わりました

 

今回のケースでは、入れ替える列のデータ型やオプションがまったく同じだったので、列名を入れ替えるだけで済みましたが、

データ型やAllow Null等のオプションが違う列を入れ替える際は、それらも入れ替えてあげる必要があります。

 

Build data tableアクティビティで最初から作り直すほうが早い場合もあります。

ケースバイケースで楽な方法で修正するとよいでしょう。

 

 

C-3 データテーブルのソート

データテーブルをソートするときは、DefaultView.Sort関数と、DefaultView.ToTable関数を使用します。

 

 

上図のデータテーブルを、総得点の降順、総距離の昇順、の順でソートしてみましょう。

 

 

上図の2つの式により、ソートされたデータテーブルが作成されます。

 

 

 

C-4 インデックス指定によるデータテーブルの値の取得

データテーブルのX行、Y列目の値を取得する場合、データテーブル変数に対し、Rows関数とItem関数を使います。

XとYはゼロから始まることに注意して使用します。

 

 

 

おわりに

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

UiPathで使用できる各種関数、アクティビティの使い方をご紹介しました。

開発のお役に立てれば幸いです。

 

 

 

日本型RPAとは――考察と事例

2018.08.06

ここ数年で欧米を中心に浸透し、日本でも2017年には導入企業が相次いだ「RPARobotic Process Automation)」。

 

労働人口の減少に直面している日本にとって、

ロボット(デジタルレイバー)による業務自動化技術であるRPAはぜひとも取り入れたいシステムです。

 

 

産業界からの注目度や導入実績では、依然として海外が先行していますが、

RPAの扱い方には国や地域によって違いがあります

 

理由として、世界各国のビジネス環境や企業文化は当然ですが大きく異なっており、

自動化を求められる作業内容や、それを実現するためのソリューションも同様ではないためです。

 

今回は日本型と呼ばれるRPAと海外との違いについて考察し、具体的な事例についてご紹介していきます。

 

RPAの基本的な仕組み

まず初めに、RPAの基本的な仕組みについて、触れておきます。

 

RPAは、簡単に言うと、人間が行っている定型業務を記憶し、

自動的に24時間365日働き続けることができるロボットです。

 

マクロと違う点として、RPAは複数アプリケーションを使った作業を得意としています

 

例えば、取引先から届いたメールの発注書ファイルを取り出し、データを会計ソフトに反映したり、

販売管理システムへ反映したり、ということが可能となります。

 

 

ただし、イレギュラーに対しては、あらかじめ設定された判定基準、

対処方法によるもののみにしか対応することができず、

導入時の設定やリスクの洗い出しを十分に行う必要があります。

 

人事・経理・総務・情報システムなどの間接部門(バックオフィス)の事務・管理業務、

販売管理や経費処理、アプリケーションをまたがった入力処理などに向いていると言えます。

 

では、具体的に欧米と日本との違いはどのようなものがあるのでしょうか。

 

 

欧米におけるRPA

欧米におけるRPA導入のキーワードは「業務の標準化」です。

 

例えば、多民族国家であるアメリカは多様なバックグラウンドを持つ人々が共通して理解できることが伝統的に重視されます。

 

そのため、ビジネスの場面ではできるだけ文字要素を減らして視覚的にわかりやすく作られたツールや、

業務手順を標準化するといった配慮がなされており、RPAに関してもそうした傾向が見られます。

 

 

具体的には「オペレーター1,000人の入力画面操作を1カ月間すべて記録し、その結果をベースに標準化した手順を整備してRPAで自動実行する」というような導入パターンが多くあります。

 

 

また、欧州は言語の異なる国家の集合体であり、

各国でこれまで運用されてきたシステムを一体化する必要に迫られています。

 

この場合の導入では、システム統合のための時間と費用があまりにも大きすぎると見込まれた際、

各システムの連携を自動化するツールとして、RPAが検討されます。

 

このため、欧州でのRPAは人が介在しない完全自動のシステムとなることが大半です。

 

 

日本におけるRPA

反対に、日本でのRPA導入では「ロボットと人間の共存」が求められます。

 

理由としては、日系企業では“現場”が力を持つとされており、

その背景には絶え間ないカイゼンで品質向上を図っている設計・生産工程や、

個別の事情にきめ細かく応じる受発注業務など、職人芸が尊敬される日本の文化が深く関わっていると考えます。

 

 

また、加えて「終身雇用制のもと、職務内容を厳密に取り決めることなく採用された従業員が、実際の必要に合わせて柔軟に対応してきたこと」なども理由の一つとして挙げられています。

 

現在の仕事を「人間+RPA+機械」という3層構造にしてRPAを使いこなしていくには、

企業全体でRPAに任せられそうな業務を洗い出し、どの業務にRPAを使うのかを決めておくことが重要です。

 

例えば、経理業務で言うなら、日々の伝票入力などのルーチンワークはRPAを導入し、

人間の仕事は収支表をもとにした経営戦略の考察など、企業の経営において本当に必要な情報を提供することに注力させることなどです。

 

ここで、日本におけるRPAと人間の共存事例をいくつかご紹介します。

 

 

・日本生命保険

RPAの導入事例として最も有名なのは、大手生命保険会社である日本生命保険の「日生ロボ美」です。

 

日生ロボ美とは導入されたRPAの名前で、請求書データのシステム入力作業を担当する社員として配属されています。

 

同社では、保険契約者から保険金の請求書が郵送されてくると、

記載されている10桁近くある証券記号番号などを入力して処理しなければならず、現在ではその業務をロボ美が担当しています。

 

ロボ美が入社したことで、それまで業務にあたっていた社員は、証券記号番号をスキャンするだけで良くなりました

 

RPAが社内システムを横断し、データの収集から業務システムへの入力までを代行できるようになった結果、

1件あたり数分かかっていた処理時間が、20秒程度に短縮

 

それで浮いた人的リソースを振り分けて、パターンに応じた柔軟な対応が必要な業務など、

人間でなければできない仕事にマンパワーを割けるようになりました。

 

 

・サッポロビール

サッポロビールでは、国内各エリアに取引先小売業への提案営業支援を行うリテールサポート担当者を配置しています。

 

POSデータの分析は、営業担当者や取引先小売業に対して販売チャンスの発掘や実施した施策の検証などの情報提供を行う上でリテールサポート担当者には欠かせない営業ツールの一つであり、

これまでは各担当者が1社当たり1日約1時間かけて、POSデータを手作業でダウンロードしていました。

 

手作業のためヒューマンエラーもまれに発生しており、さらに当初は数社だったPOSデータ開示も、現在は十数社に増加。

タイムリーな分析を必要とする半面、手作業では追いつかない状況となってきていました。

 

 

そこで、同社ではPOSデータの読み込みにRPAの導入を決定。

その結果、現在は1社当たり平均約30分でダウンロードが可能になりました。

 

 

さらに、手作業では作業工数抑制の観点から一部カテゴリーは週次取得にとどめていましたが、

導入後はすべてのカテゴリーで日次取得が可能となったため、日程が固定している催事についても、

よりきめ細やかな分析や提案が可能となりました。

 

 

RPA導入の注意点

前述のように導入メリットの多いRPAですが、その成功のためには、実際にそのRPAを動かす“現場の理解”が不可欠です。

 

いくつもの企業で導入の成功事例が相次ぎ、その名が普及してきたRPAですが、

企業で働く社員ひとりひとりが、その効果を十分に理解しているとは限りません。

 

しかし、RPAを最大限活用するのに何よりも大事なのが、これまでその業務を行ってきた社員ひとりひとりの知識・経験なのです。

 

 

そのため、導入を決めるにあたっては、RPAに任せる業務内容の洗い出しと同時に、

現場の社員全員への丁寧な説明も必須事項と言えます。

 

「RPAが従業員の作業を奪うのではなく、単調な作業や時間外の作業をRPAに代行させることで、従業員をより付加価値の高い業務へ移行させてくれる」ということをしっかりと時間をかけて説明し、

決してリストラへの布石など、マイナスの効果をもたらすものではないということを理解してもらって初めて、RPAと人間の共存が叶うのです。

 

 

これまで、日本の大手企業を中心に「ロボットと人間の共存」を実現してきた日本型RPAは、

今後中小企業や地方の企業・団体へと、徐々にその活躍の場を広げていくと予測されます。

 

人事、経理、営業サポート……etc. どのような業務においても、

これまで現場で働いてきた社員の方々の知識・経験をRPAによって最大限に活用し、

より働きやすい環境で社員ひとりひとりが輝ける職場になることを期待します。

 

 

 

働き方改革から考えるRPA(Robotic Process Automation)について

2018.08.03

 日本経済再生に向けて、働き方改革がなされている今、働き方改革について学ぶとともに、

それらの動きからRPA(Robotic Process Automation)を生かしていく方法について検討していきたいと思います。

 

働き方改革とは?

 首相官邸「働き方改革の実現」の冒頭には、

 

働き方改革は一億総活躍社会実現に向けた最大のチャレンジ。多様な動き方を可能とするとともに、中間層の厚みを増しつつ、格差の固定化を回避し、成長と分配の好循環を実現するため、働く人の立場・視点で取り組んでいきます。

 

と書かれています。

 

働き方改革は、日本経済再生に向けて、最大のチャレンジであり、

これにより企業文化や風土を含めて改革させるものと考えられています。

 

 

 これらの改革を計画している背景としては、前述の通り日本経済再生に向けてというところが大きいと思われます。

 

日本の労働人口は想定以上に減少していると言われており、生産年齢人口が総人口を上回ると言われています。

 

総人口については、2050年には9000万人前後、2105年には4500万人まで減少すると考えられています。

 

労働力人口については、第二次ベビーブームに生まれた団塊世代のジュニアが労働力として加わったときにピークを迎え、

2060年にはピークの半分に減少すると言われています。

 

 つまり、これらの背景から政府が考えていることは、労働力を増やすために女性や高齢者の積極的な雇用などから働き手を増やすこと。

出生率を上昇させ、未来の労働人口率を高めること。

一人あたりの労働生産率を高めることなどの対策が挙げられています。

 

 

ここで具体的な課題とされているのは、

①正規・非正規の不合理な処遇の差について

②長時間労働ついて

③単線型の日本のキャリアパスについて

などが挙げられます。

 

 ①正規・非正規の不合理な処遇の差については、正規・非正規の不合理な処遇の格差を埋めていければ、

自分の能力を評価されている納得感が醸成され、労働者が働くモチベーションを高め、

それによって労働生産性も向上されると考えています。

 

②長時間労働については、大きくニュースにも取り上げられました。

当時24歳の広告大手新入社員が、過労自殺したことについては、みなさんもご存知かと思います。

残業時間が過労死ラインと言われている月80時間を大きく超える105時間だったと言われている。

また、その大手広告企業では、1991年にも2年目の社員が過労自殺をしており、

2010・2014・2015年と労働基準監督署から数回にわたって是正勧告を受けていました。

 

 このような長時間労働を解決することにより、健康の確保だけでなく、仕事と家庭生活との両立、

つまりワーク・ライフ・バランスが改善し、女性や高齢者も仕事に就きやすくなり、

労働参加率向上に結びつくと考えられています。

 

また、経営者はどのように働いてもらうかに関心を高め、単位時間あたりの労働生産性向上にもつながると考えられています。

 

 ③単線型の日本のキャリアパスについては、ライフステージにあった仕事の仕方を選択できるようにすることによって、

働きやすさや労働人口を高めることができるようになります。

 

例えば、日本における広義のフリーランスは、推計1,122万人に達しているとランサーズ株式会社の調査により発表されています。

2016年と比べてフリーランス人口は5%増となっており、今後も増加傾向にあると思われる。

 

ちなみに、アメリカでは2016年に5,370万人から、2017年には5,500万人へと増加すると考えられている。

日本でも若干、浸透しつつあるが、プロフェッショナルな人材がフリーランスとして、働く市場が拡大しており、

日本においてもナレッジの持った主婦や高齢者が週5とは言わずに、

企業と労働者がそれぞれニーズに合わせた形で、働くことができるようになっていくと考えられている。

 

 このように総理が自ら議長となり、労働界と産業界のトップと有識者が集まって、議論を繰り広げて、

施策を進めているわけです。

 

また、その働き方改革の施策として、最近話題にあがっているのが、高度プロフェッショナル制度です。

これについて次に話していきたいと思います。

 

高度プロフェッショナル制度

 高度プロフェショナル制度は、残業代ゼロ法案・脱時間給制度などとも呼ばれており、

年収1075万円以上の一定の業種の労働者を労基法による労働時間、休日等の規制対象から外すというものです。

 

つまり、残業代を労働者に支払う必要もありません

一方、時間などに縛られないため、成果を出せば数時間で帰宅することができるなど、

働き方を柔軟にするとも言われています。

 

この高度プロフェショナル制度について詳しく調べていきましょう。

 

 

 まず、ある業種とは厚労省によって決められており、

「高度の専門的知識等を必要とし、その性質上従事した時間と従事して得た成果との関連性が通常高くないと認められる業務」

とされており、金融商品の開発、ディーリング、企業・市場のアナリスト・コンサルタント、研究開発などが念頭に置かれています。

 

 

 また、年収が1075万円以上であることに加えて、職務内容が明確、労使委員会の5分の4以上の多数議決、本人の同意などが必要です。

 

これらの条件を見ると、ごくわずかな人にしか対象とならないように見えますが、

実は年収1075万円以上と言われている金額は、法案の条文には書かれていません。

 

なぜそのような具体的な数値が出てくるかというと、労基法改正案41条の2第1項2号ロによれば、

 

労働契約により使用者から支払われると見込まれる賃金の額を1年間当たりの賃金の額に換算した額が基準年間平均給与額(厚生労働省において作成する毎月勤労統計における毎月きまつて支給する給与の額を基礎として厚生労働省令で定めるところにより算定した労働者一人当たりの給与の平均額をいう)の3倍の額を相当程度上回る水準として厚生労働省令で定める額以上であること

 

と書かれており、「3倍の額」や「相当程度上回る水準」というのが、

曖昧であるためその金額を上げ下げできる恐れがあります。

 

 他には、この制度のメリットである「成果を出せば数時間で帰宅することができる」という点に疑問を生じる声を聞きます。

なぜなら長時間労働を前提とした、成果給の制度を意味しており、そもそも長時間労働であるがゆえという事実が抜けているからです。

 

また、収入においても時給に換算すると、実は高額収入とは言えず、さらなる長労働時間を助長してしまうとも言われています。

 

 

RPA(Robotic Process Automation)の活かし方

 高度プロフェショナル制度についても連日ニュースで流れるように、働き方について多くの人が敏感に感じており、

とくに労働時間について非常に注目されるところです。

 

つまり、これらの問題に多くの経営者も、自社の働き方や労働時間について考えていかなければなりません。

 

それに貢献するのが、RPAです。

 

RPAはRobotic Process Automationを言われるように、PCの動作全てを自動化することができるようになるツールです。

 

多くの労働者が、事務作業つまり、ルーチンとなっている単純業務を持っており、労働時間が増幅し、

作業からの考える時間が持てないのが現状かと思います。

 

しかし、RPAを導入すれば単純作業は全て自動化され、より高度な作業に集中することができます。

 

 これらのことからも、労働時間が長いような業種や企業においては、RPAの導入を検討してみてはいかがでしょうか

 

それにより、自社の働き方改革に貢献することができ、社員の労働生産性を高めることにも繋がるかと思います。

 

 

 

【RPA導入事例】イチ事業部員の私がRPAを提案・導入してみた。

2018.08.02

この記事では私が、自分が勤める会社にRPAを導入し、運用を始めた一連の流れを書きます。

 

私の実体験になりますので、思いがこめられすぎて、少し読みにくい部分もあるかもしれませんが、熱が伝われば幸いです。

 

 

について

  •  社会人歴約14年。営業中心
  •  最新技術はとても興味あり、広範囲に収集。
  •  プログラミングは早々に挫折。せいぜいがエクセル関数を駆使する程度
  •  最近はBIツールの活用のため、クエリ周りを勉強中。
  •  自分の会社のことは割と好き。
  •  自分と関わった人は、関わる前より少しでも良くなってほしいと思うタイプ。

 

 

当社について

 創業60年をこえた専門商社

 属人的に業務が進行しており、書類・データの残し方は人それぞれとなってしまっている。

 

 ここ数年、標準化を目指し改善活動を進めており機運は高まっているがまだまだ。

 多数のお客様と仕入れ先を抱えているため、それぞれのフォーマットがあり標準化は難しい

 

 

RPA導入のきっかけ(1か月目)

 事業部門トップが顧客に訪問した際に、「RPA導入を計画している」旨を聞き、私に調査を指示したことがきっかけ。

 

<Point>

 RPA導入のきっかけが欲しい方は、このパターンが良いかもしれません

 

 決裁権保有者に対し、まず第三者(できればお客様偉い人”)から情報を伝えてもらう事により、

その決裁権保有者は『良い情報を得られた』となりますので、

そこで時間をあまりおかずに整理された情報を伝えることにより、うまく進められるのではないかと。

 

いろいろなパターンはあると思いますが、一つの成功事例です。

 

なお、この時私は、RPAという単語は知っていたが詳しくは知らず、1から調査を開始しました。

 

 

▼調査結果はこちら↓

  •  RPAテクノロジーズ:Bizrobo
  •  ソフトバンク:SynchRoid ←当初、RPA テクノロジーズと出どころが同じということも知らず!笑(結果的にこれが採択)
  •  NTT:WinActor

 

 

▼調査条件

  •  基幹システムに対応していること(黒い画面に緑の文字のアレです)
  •  開発が容易であること (BluePrismはデモも見ていません)
  •  ランニングコストが100万円/月未満であること(派遣社員1名分のイメージ)

 

 

この時の、下記所感を持ちました。

 

 

「思っていたより色々と対応できそう」

「自分でロボットを作るにはしんどそうだけど、社内からはかなり喜ばれそう」

「基幹システムはいつ刷新するかわからないため、今をそのまま改善できるRPAが地に足着いた現実的な解決案かも」

 

 

これらを、RPA調査を指示した上司に説明し、導入に向けて本格的に動くことを決意。

 

同時に、ソフトバンク様にデモを依頼し、社内の複数部門、グループ会社のメンバーが出席、

それぞれが好印象を持ったことも導入に向けて推進力を高められたきっかけだったと思います。

 

 

<Point>

 思いさえあれば、情報システム部門でなくても、社内に新たなシステムを導入することができます。

 

逆に、事業部門からの方が、具体的な導入効果を表現できるためRPAについては事業部門からの発信が向いていると思います。

 

 また、調査を広範囲に行うことはお勧めしません。ただ時間と労力を浪費するだけです。

 上記のように、調査条件をシンプルにすることでかなり絞れるはずです。

 

 

RPAロボット化できそうな対象業務の調査(2か月目)

 

 普段から、若手社員と話すと(飲みながら)、“テンションが上がらない業務”、“自分以外の誰でもできる業務”など細かなものが非常に多く、

本来の営業活動ができていない。と愚痴を聞いていました。

 

 そこでRPA導入の費用対効果を出すためにこれらの調査を本格的に始めたところ、

自部門所属の数人へのインタビューだけで、ライセンス費用(60万円/月)は十分に回収できると分かったため、上申資料の作成に移りました。

 

 

▼対象業務の一例(自事業部門のみ)

  •  図面管理
  •  基幹システムへの登録作業
  •  見積作成
  •  お客様のEDIサイトから定期的な注文情報取得
  •  インボイスの作成

など

 

 

導入した後の社内体制を検討、関係者の合意を取る(3か月目)

 

 RPAの導入・運用には、サーバー環境が必要です(サーバー型RPAの場合)。

 

そのため、情報システム部門との連携を求めました。

幸い、情報システム部門も独自でRPAの調査をしており、会話はスムーズに進めました。

 

 当社では、事務局機能、サーバー周りの保守は情報システム部門。

 ロボット作成、運用は各事業部門にキーマンを置くという形で進めることとしました。

 

 

Point

 スモールスタートの場合はサーバー環境を必要としませんが、

当社では対象のロボット案がすぐに多数出てきたため、最初からサーバー環境を要するプランで進めることにしました。

 

 

社長への説明、上申!(4か月目)

 

 説明内容のストーリーはこうです。

 

  • RPAとはこういう事ができるものですよ
  • 発展させれば、こんなことだってできるんですよ

YouTubeにいくつか上がっているRPA関連の動画を使いました。お勧めはSoftBank Worldの講演動画です)

  • 各事業部門での適用例はこうです。これだけの時間が削減できる効果が望めます
  • とはいえ、業務の1から10までがRPAにできるわけではありません。例えばこの業務では、3から9までの部分がロボット化できます
  • 社内体制は、最初はこうです。これをどんどん発展していくようにします。
  • 費用の説明

 

これで当社の場合は十分に理解を頂き、導入に向けて決済を頂きました

 

 

Point

 お気づきの方もいらっしゃると思いますが、RPAロボット作成ツール自体の説明はほとんどしませんでした

 

 上層部は、そもそも“RPA”の事自体を正確に理解していないため、

BizroboWinActorだと説明しても、結局どちらも“RPA”です。(質問は受けますので、準備は必要です。)

 

 SynchRoidの柔軟性を確認できましたので、私はこの一本で上申しました。

 (よくあるいくつかの製品を並べて〇×表はあえて作りませんでした

 

 また、キメの文句は「これを導入しないと、若手社員はどんどん辞めていきますよ。」です笑

 

 

 導入の構成準備(5か月目)

 

▼必要なもの(サーバープラン)

 ・サーバー(クラウドサーバーでOK

 ・開発用のPC  *開発者の人数分

(通常、会社から配布されるPCではスペックが足りない場合が多いと思います。最低でもメモリ8GBが必要です。)

 

▼あった方が良いもの

 ・遠隔操作先用のPC

  *サーバー上に仮想PCを設けても良いですが、サーバーへの要求スペックが高まってしまうため、1台手元に置いた方が開発が楽です。

 ・外付けモニタ

  *できれば4Kモニタが良いです。開発画面では、実行ウィンドウ、タグなどいくつも

並行してみなければならず、フルHDモニタでも事足りないくらいです。

 

Point

 社内に情報システム部門があれば、このあたりは任せた方が良いと思いますが、

上記に書いた開発用のPCや、遠隔操作先のPC4Kモニタなどは“後から気づく”類のものです。

 

ぜひ参考になれば幸いです。

 情報システム部門が無ければ、必要スペックをRPAベンダーにまるまる用意していただくことも可能ですので、それもお勧めです。

 

 

ということで、予算の申請は余裕を持った方が良いです笑

決して、ライセンス費用のみで申請しないことをお勧めします。

 

 

 導入、スキルトレーニングの実施(6か月目)

 

 まず当社ではスキルトレーニングを申し込み受講しました。

 これ一回でRPAツールのことを理解するものではなく、ロボットを作る一連の流れを把握する程度と捉えた方が良いです。

 それでも、受講をしないよりはした方が良いです。

 

 

各部門への説明(6か月目*5と同時進行)

 

 これは絶対にさぼってはいけません。全部門に回るべきです。

 また、会社によっては部門に回る順番も意識した方が良いでしょう。

 

 RPA導入までの努力、労力は誰も理解してくれません。

 

逆に、メンバーは風の噂でRPA導入を知っていますので、期待を持つ人、疑心的な人などいろいろいます。

 

 私はこういったスタンスで臨みました。

 

 

  •  「業務を標準化してから…」ではなく、今困っているものを”そのまま”教えてください
  •  作成依頼に特別な申請を設けない
  •  ロボット候補の業務を、スマホで動画撮影することで要件定義作成の手間をシンプルにする
  •  仕事(ロボット案)をください!

 

あくまで、「一緒に作り上げていきましょう。」「あなたの味方です」というスタンスです。

 

 

社内からの反応(7か月目)

 

 私が直接説明をした当事業部では、比較的に業務担当者からの「これもロボット化できる?」が多かったです。

 説明の仕方が良かったのだと自負しています笑

 

 

 

運用における苦労(7~8か月目)

 

 今現在、リアルタイムに起きている問題はこちらです。

 

  1. ロボット化の案は多数上がってくるも、RPAロボット制作が追い付かない
  2. RPAロボット製作者側に回りたいという声がなかなか無い
  3. 当社(商社)では、プログラム開発に強い者が少ないため、RPAロボット制作において不明点が生じても社内での解決に時間がかかってしまう。
  4. お客様毎に特別対応している業務のRPA化が難しく、業務担当者の期待値が下がってしまう。

 

 おおよそこれらが上がっています。

 

  1. は予算に余裕を持ち、RPA技術者の派遣を考慮すればスムーズにいったでしょう。
  2. すでに自身が抱えている業務が忙しい中、新たなものに取り組むモチベーションを持つ方はやはりなかなか少なく、しばらくこの問題は抱えそうです…。
  3. これも、1.の解決策同様で解決できると思います。
  4. まず、「すべてをRPAでやらなくてはいけない」という思い込みを捨て、Excelが得意なことはExcel(マクロ)にやらせる。BIツールの方が得意ならばそれに。RPAは下処理を行う。と、時によって割り切りが絶対に必要です。

 

  

 当社でのRPAロボット制作事例

 

 まだまだ数は少ないですが、今運用しているロボットの一例を紹介します。

 

  • お客様発行の書類データ(PDF)に当社情報を加える *従来は手書きで行っていた業務です
  • インボイス作成
  • 業務用サイトへのデータ入力

 

 

総括_RPAについて

 

 当社ではまだ導入したてですが、すでにいくつかの業務で実績を上げておりすでになくてはならないものになっています。

 

なにより漠然と他の誰かでもできる作業時間と労力さえあれば行える作業をしていた社員の方にとっては、

RPAは一筋の光であり意欲の向上に一役を買っていることが私にとっては一番の効果です。

 

 しかし、RPAを導入した他の企業と話をしますと、当社の進みは早いケースのようです。

RPA導入メンバーとなった方は、しばらくはつらい時期が続くと思いますが、

その先に必ず成果が表れるものですので、ぜひ頑張ってほしいと思います。

 

ここまで駄文を読んでいただき誠にありがとうございます。

RPA導入に向けて困っている方にとって何か一つでもお役に立てれば幸いです。

 

 

 

【RPAツールの一角】BizRobo! とは

2018.08.01

はじめに

RPAに関する情報をチェックしていると、「BizRobo!」という名称を良く目にするかと思います。

しかしサービスそのものについては詳しく知らないという方も少なくないでしょう。

そこで本記事では、BizRobo!について解説します。

 

BizRobo! とは

BizRobo! とは、RPAテクノロジーズ社が提供するRPAサービスの名称です。

 

事務業務を自動化する技術であるRPARobotic Process Automation)では、

自動化を実行するプログラムのことをロボットと呼び、ロボットを作成するためのソフトウェアが必要になります。

BizRobo! は、複数のロボット作成ソフトウェアと運用サポート、導入時のアドバイスをセットで提供しています。

 

大手銀行をはじめ導入企業も多く、国内シェアNo1を謳うNTTデータのWinActorと並び知名度も高いRPAサービスです。

国内400社以上での導入実績があります。以下のような導入例があります。

 

 

【大和ハウス工業】

基幹業務の効率化を目的としてアビームコンサルティング社の支援のもとBizRobo!を導入。

情報収集やデータ整理業務、会計レポート生成等に活用し、外注費削減などを目指す。

https://www.abeam.com/am/jp/ja/about/news/20170720

 

 

【日本生命保険(ニッセイ)】

RPAロボットを擬人化した「日生ロボ美ちゃん」を社のスタッフとして正式採用し話題に。データ検索やシステム入力を担当することで1件あたり数分かかっていた作業を20秒程度で処理し時間削減を実現。

http://rpa-technologies.com/about/#07-01

 

 

RPAとRDA

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

 

PC上で動くタイプはRDARobotic Desktop Automation)と呼ばれ、導入費用が安価に済むというメリットがあり小規模導入用途で人気があります。

 

一方で一元管理ができない、ログの把握が困難といったデメリットもあります。

 

サーバ上で動くタイプのロボットが狭義のRPAです。

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

 

BizRobo! はこちらに分類されます。

 

 

BizRobo! シリーズの製品群

BizRobo! には、複数のロボット作成ソフトウェアが含まれています。

それぞれ特徴があり、利用企業の用途に合わせて適したソフトウェアを組み合わせることができるようになっています。

 

  • Basic Robo!
  • Document RPA
  • Blue Prism
  • NICE

 

Basic Robo! の操作

BizRobo! 中でも導入数が多いソフトウェアがBasic Robo!で、提供元のRPAテクノロジーズでも国内導入実績No.1を謳っています。

 

開発環境、ロボット監視環境、ロボット実行環境など複数のソフトウェアから構成されており、

ロボットを開発するソフトウェアはDesign Studioという名称です。

 

 

Basic Robo! におけるロボット作成は、プログラムの知識がなくてもできるのが特徴で、容易にループ(繰り返し)やファイル書き出しができます。

 

Excelのマクロと同様にレコーディング機能を備えており、ユーザーがクリックしたりテキスト入力したりする操作をソフトウェアが記録していきます。

 

 

一般的にプログラム言語では変数を宣言しますが、

Basic Robo!ではタイプと呼ばれる変数セットを作成し、タイプの中に複数の変数を作成します。

 

ロボットを作成する場合には、ロボットのなかにタイプを設定した後、右クリックで操作を記録しながらデータを取り出して変数に保存していきます。

記録した操作はフロー図のように表示されます。

 

Excelマクロでは実現が難しいような、Webからのデータ取得や他アプリケーションとの連携ができるのも利点です。

 

BizRobo! のよくある誤解

BizRobo! は知名度が高い反面、意外と誤解されていることもあります。ここではBizRobo! のよくある誤解を紹介します。

 

 

誤解その①:国産RPAサービスである

提供元のRPAテクノロジーズが日本企業のため、BizRobo! も日本企業が開発したサービスだと誤解されがちですが、

BizRobo! が提供しているロボット作成ソフトウェアはいずれも海外製です。

 

メイン製品のBasic Robo!はアメリカ企業のKofax社が提供しているKofax Kapow 10がベースになっています(Basic Robo!のソフトウェアを起動するとKofax Kapowという名称が表示されます)。

 

 

誤解その②:BizRobo! という単体のソフトウェアが存在する

前述のとおり、BizRobo! は単体のアプリケーション名称ではありません

 

RPAサービスを提供している多くの企業がソフトウェアとしてサービスを提供しているのに対し、

BizRobo! 提供元のRPAテクノロジーズ社では、BizRobo! をロボットの導入・運用を支援するためのサービスプラットフォームと位置付けています。

 

 

同社ではロボットのことを「デジタルレイバー(仮想知的労働者)」と呼び、人と同じように労働力として扱います。

ソフトウェアを販売するのではなく、複数のソフトウェアやOCR機能などを組み合わせたデジタルレイバーを作成、

提供するサービス全般をBizRobo! というサービス名で提供しているという位置づけです。

https://rpa-bank.com/interview/7196/

 

 

誤解その③:大企業向けのサービスである

ニュースなどで取り上げられるのは有名企業の事例が多く、

また導入費用が高額なことからも大企業向けのサービスだと考えられがちです。

 

しかしサーバ不要で初期投資を抑えられるクラウドサービス「Bizrobo! DX Cloud」をリリースするなど地方、中小企業向けのサービスも提供しはじめています。

 

 

他社との連携サービスについて

BizRobo! が競合他社と異なる点として、パートナー企業と連携したRPAサービスを提供していることが挙げられます。

 

たとえばAI開発・データ分析を行うブレインパッド社では、

自社のAI技術データマイニング技術を付加したRPAサービス「ブレインロボ(BrainRobo)」を開発・提供しています。

 

自治体向けのシステム開発を行う大崎コンピュータエンヂニアリングでは、

今まで培った自治体向けシステム開発のノウハウを生かした自治体向けRPAサービス「OCEVISTAS」を提供しています。

 

いずれもBizRobo! Basic Robo! をベースに、自社が持つ強みを組み合わせてサービス化することで差別化しています。

サービスごとにオリジナルのキャラクターを作成しています。

 

まとめ

BizRobo! は、RPAにおけるロボットを作成するために必要なソフトウェアやサポートをセットにしたサービスのことです。

 

複数のロボット作成ソフトウェアが含まれていて用途に合わせて適した組み合わせができるほか、

ベースとなるソフトウェアにAI技術などを付加した連携サービスも多数存在し、

EC運営業務代行に特化したロボットや自治体業務に適したロボットなど、

さまざまな特徴を持ったロボット提供サービスが派生しています。

 

 

BizRobo! の提供元であるRPAテクノロジーズ社は、RPA操作スキルを持った女性スタッフを育成する「RPA女子プロジェクト」や、

ロボットを売買する「RPAマーケットプレイス」の提供(運営は子会社のセグメント社)など新たな取り組みにも積極的です。

 

 

RPAツールのデファクトスタンダードが存在しないなか、

「サービス提供社が多い」、「操作できる人材の育成を支援」、「ロボットの売買ができる」、「安価なクラウドサービスを提供」などを武器に、

BizRobo! の導入企業は今後も増えていくと予測されます。

 

 

出典

http://rpa-technologies.com/products/first/

https://rpa-bank.com/column/11305/

 

 

また、Basicrobo、SyncRoidについては以下の記事も併せてご覧ください。

https://rpa-biz.com/?p=1652

 

 

 

【決定版】ロボット(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をほんの少し学習するだけでも、プログラミングの構造やルールといったことは何となく理解することができます。

 

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

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

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

 

 

topへ
© RPA.biz