2018.12.28
近年のECサイトの普及と利用増に伴って、輸送量が大幅に増えているのに比例して、運送業での人手不足が極めて深刻な状況に陥っています。
何を隠そう原因は、2009年の規制緩和に始まる過当な低運賃競争と、それによる「低賃金・重労働」の就業環境・待遇の悪さから「物流の担い手」たるドライバーの求人が思うように伸びないこと。
厚生労働省が今年1月に発表したレポートによると、トラックドライバーを含む自動車運転者の有効求人倍率は、3.03倍と全業種平均である1.59倍を大きく上回っており、人手不足は深刻さの一途をたどっていることが伺えます。
宅配便だけで見ても、年間の取り扱い個数は約43億個（2017年度）まで増長し、業界全体への負荷に拍車がかかっている状態です。
現在、日本の物流の約9割がトラック輸送に頼っているといわれており、日本経済にも大きなダメージを与えかねない状態になっています。
かつては「稼げる職業」のひとつとして挙げられていたトラックドライバー。
原因は先に挙げた点であるとして、なぜ解決の糸口が見えないのでしょう。
ECサイトの発展により、急増した物流サービス需要。
関連業界では数多くの対応策を講じ、また国交省も「労働力不足対策のアクションプラン」を打ち出すなどして、解決を目指してきましたが、やはり総合的な国内労働人口の減少もあり、なかなか抜本的な改革ができていないといわれています。
また輸送業特有の問題も原因として挙がっています。
ひとつは、トラックの積載効率の悪化。
国交省によるとトラック1台当たりの積載率は、約41%(平成29年度)で、近年徐々に減少しています。
実に荷室の半分以上のスペースを無駄にしながら運行していることになります。
もうひとつは、「荷待ち」、「ラストマイル問題」による業務効率の悪化。
「荷待ち」とは、荷物の積み下ろしの際に、ドライバーが待機している時間のこと。
ドライバーがいくら効率よく運んでも、荷送先・荷受先で必ず発生してしまうもので、ドライバーの長時間労働問題の観点からも大きな原因となっているものです。
「ラストマイル」とは、配送センターから個人宅までの物流における最下流の部分を指します。
近年社会問題にもなっている「再配達」によりドライバーが何度も繰り返し往復する羽目になり、業務非効率の大きな要因として挙がる課題です。
こうした業界全体の問題、はたまた業界全体の旧態依然とした体質そのものが、人手不足や長時間労働問題の根源にあるため、遅々として改革が進まないといった側面もあるようです。
今回はAI/RPAといったテクノロジーを利活用して、これら諸問題を解決しようとする取り組みを中心にご紹介してまいります。
再配達に悩まされる宅配業者を助けるアプリとして開発された「自動家電サービス」（株式会社トレイル）は、トラックにGPSのついたスマートフォンを積み、配達先に近づくと、クラウド上の架電サーバーから自動で電話をかけて配達先の在宅・不在を知ることができるというスグレモノ。
電話を受けた側は、自動音声案内で配達時間帯を知らされ、受け取れる場合は「はい」と答えるだけで、配達可能先として判断されます。
受け取れない場合は「いいえ」と答え、さらに同じ電話で再配達希望日時を伝えることができ、その情報がドライバーのスマホに反映される仕組みになっています。
もし電話をとれず折り返した場合は、トラックの現在地と配達先との距離に応じてAIが応答内容を変えて自動で対応することも可能。
AIによる音声認識を搭載しているため、荷物の受け取り手、ドライバー双方がプッシュボタンで操作する必要がないという利点を最大限生かしたサービスであるといえます。
実は、不在通知を受け取った人のうち、約50%がドライバーに直接電話をかけるといわれており、18時以降電話が鳴りやまないといった問題も抱えていたため、配送の効率化に大きく寄与できるサービスであると期待されています。
こうした再配達解消に向けた取り組みは、日用品のECサイト「LOHACO（ロハコ）」（株式会社アスクル）でも。
配送サービス「Happy On Time」では、配送時間指定を午前6時から午前0時まで、1時間刻みで対応。
アプリのプッシュ通信機能を利用し、受け取り手へ30分前、10分前と配送時間の事前通知を行っています。
こうして一般的な宅配の不在率が約20%に達する中で、きめ細やかな同サービスでは約3%まで低減させることに成功しました。
こうしたサービスのベースとなるのは、配送計画や配送車輌の運行状況をリアルタイムで管理・更新する独自システム。
アスクルの保有する物流ビッグデータを配送計画に組み込むため、人工知能「Hitachi AI Technology/H」（日立製作所）を導入。
自動学習によって「到着時刻の精度に影響を与える要因」を特定し、配送時間の誤差の極小化と配送効率の最大化を図っているのです。
富士運輸では、ドコモの「AIインフォテイメントサービス」とRPAサービス「WinActor」を活用したツールを実証実験中です。
ドライバーの日報作成から事務員の各種確認業務、請求データ発行業務といった運送業界で生じている一連のルーティン業務を効率化・自動化する試みで、人手不足や労働時間の長時間化などが課題を解決し、経営効率化を図っています。
音声エージェントの問いかけにドライバーが応えるだけで、日報作成・業務記録が可能で、作成されたデータは特定クラウド上にアップロード。帰着後に日報を作成・修正する手間が省けるため、この部分にかかる稼働時間の約80%を削減できるとしています。
また、これまで運送会社の事務員が目視で行っていた、ドライバーの手書き日報と積み荷や配送先の情報を定めた運行計画書の照合作業。
「WinActor」を導入することで、先の作成されたクラウド上の日報データと運行計画書の自動照合が可能になり、最終的な請求データの確定まで、ほぼ人力を介さずに業務を遂行できるシステムになっています。
これにより、事務員に付帯する事務作業の稼働時間を約50%までに削減に成功しています。
ドコモと富士運輸は、これまでも空車回送の削減を目指した、運送業特化の車両位置情報管理サービス「DoCoMAP」や、それを活用したからにトラックと配送ニーズを結びつける「docomap JAPAN」を相次いで開発。
「運送業向け働き方改革ソリューション」の提供により、業界全体の体質改善や労働環境の整備に寄与することを目指しています。
先にご紹介した2つの他にも、様々なソリューションが登場しています。
「AI配車ソリューション TOMAS」（株式会社ジェイ・ビー・クラフト）は、企業から企業への配送スケジュール組み立て、配車を行うソリューション。
また、荷台の温度管理や積み荷の防犯対策、トラックそのものの車両整備を助けるAI構築を提案する「AIさくらさん」（ティファナ）なども登場しており、運送業×AI/RPAの動きはより活発になっていくものと思われます。
運送業界の過酷さや窮状は、筆者の親族にも何名か長距離トラックドライバーがいることもあり、非常に身近な課題として痛感してきました。
運送業は、日本経済の根幹ともいうべき物流の担い手であります。
各種技術の発展・活用により、労働者の負担が少しでも軽減できれば。
AI/RPAの今後の展開に注目です。
2018.12.27
UiPath のステートマシンとステートアクティビティについて調べます。
UiPath Studio のスタート画面から、
Robotic Enterprise Framework を選択してプロジェクトを作成すると、
このようなテンプレートが表示されます。
一見、複雑に見えますが、落ち着いてアクティビティのアイコンをよく見てみると、２種類しかありません。
アクティビティのアイコンの中に、♂マークをひっくり返したような絵が描かれているのが、ステート (State) アクティビティ、四角を円で囲んだ絵が描かれているのが、最終ステート (Final State) アクティビティです。
ステートマシンは、これら２つのアクティビティにより構成される、特殊なフローチャートのようなものです。
まずは、アクティビティの使い方から調べていきましょう。
UiPath Studio の新規メニューから、ステートマシンを選択してプロジェクトを作成します。
アクティビティ検索ボックスに「state」と書くと、目的のアクティビティが表示されます。
ステートアクティビティをドラッグ・アンド・ドロップして、Start につなげます。
テンプレートにあったステートアクティビティとは少し見た目が違いますが、気にせずダブルクリックして、中身を確認します。
ステートアクティビティが、Entry、Exit、Transition(s) の３つの要素で構成されていることがわかります。
ステートアクティビティの Entry の部分には、フローがこのアクティビティに到達したときに最初に行うアクションを書きます。
Entry にアクティビティを設定すると、省略形の方のステートアクティビティの見た目に、変化が現れます。
左下に、円に矢印が入っていくようなアイコンが追加され、Robotic Enterprise Framework テンプレート内のステートアクティビティと同じ見た目になりました。
このアイコンがあるということは、Entry に、何かアクションが設定されている、ということになります。
次は、Exit の部分です。
Exit には、このアクティビティから抜けていくときに実行するアクションを設定します。
Entry のときと同じように、Exit にアクションを設定した場合も、ステートアクティビティの見た目が変化します。
円から矢印が出ていくようなアイコンが表示されます。
Robotic Enterprise Framework テンプレートでは、どのステートアクティビティも Exit が空になっていたため、このアイコンは表示されていませんでした。
ステートアクティビティにマウスをかざして動かすと、他のアクティビティと線をつなぐためのソケットがたくさんあることがわかります。
試しに、ステートアクティビティ自身に線をつなげてみましょう。
つなげた線に、T1 という名前が自動的に付けられました。この線が Transition です。
ステートアクティビティをダブルクリックして、Transition(s) の部分を見ると、
先ほど作成した T1 が表示されています。
T1 をクリックして、中身を見てみます。
Transition には、トリガー、条件判定、条件を満たしたときに実行するアクションを設定できます。
最初に見たテンプレートでは、ひとつのステートアクティビティから Transition が何本も出ていました。
ここでも、いくつか追加してみて、それらがどのように表示されるか確認します。
T2 を追加してから Transitions(s) を見ると、T1 の下に T2 が追加されました。
このように、新しいものほど下に表示されます。
ちなみに、線の接続位置をずらすと、「再設定された」とみなされるらしく、その Transition は一番下に移動してしまいます。
次は、線の根元が T2 と同じようになるように T3 を追加してみます。
T3 をダブルクリックして、中身を確認します。
T3 だけでなく、T2 の遷移条件判定とその後のアクションも表示されています。
このように、複数の Transition の根元を同じにすると、Trigger を共有することができます。
Trigger を共有している場合、Condition の右上あたりに、青い矢印(↑、↓)が表示されます。
この矢印をクリックすると、順番を入れ替えられます。
条件と順番をうまく調整すれば、最後の Transition を Switch アクティビティの Default のように扱うことも可能です。
ステートアクティビティでは、次のような順番で処理が行われます。
Entry → Transition Trigger → Transition Condition → Exit → Transition Action
Exit が最後ではないという点に注意しましょう。
最終ステートアクティビティは、フローの最終地点に配置するアクティビティです。
他のステートアクティビティの Transition の宛先として設定できます。
とてもシンプルで、Entry しかありません。
ちなみに、フローの開始地点となる Start から出る線は、Transition ではないので、Start と最終ステートアクティビティを直接つなぐことはできません。
【練習】
アクティビティに慣れるため、以下のようなステートマシンを作成します。
UiPath Studio の新規メニューから、ステートマシンを選択します。
フローを作るときの順番はいろいろあると思いますが、今回は、すべてのステートアクティビティを並べてから、中身を編集することにしました。
先頭の「フォルダー選択」ステートから編集していきます。
Entry に、「フォルダーを選択 (Select Folder)」アクティビティを追加します。
後続の処理で、フォルダー名を利用することになるので、ここで取得しておきます。
Exit に、選択されたフォルダーをエクスプローラーで開く設定を行います。
Transition には何も設定せず、ただの線として使用します。
「イベント監視」ステートでは、イベントが発生したら、次のステートに遷移するように設定します。
「ファイル変更トリガー (File Change Trigger)」と「システムトリガー (System Trigger)」を使用します。
ファイルの新規作成を監視するトリガーから作っていきます。
Trigger に「イベントを監視 (Monitor Events)」アクティビティを追加し、「無限に繰り返す」オプションを False にします。
ファイル変更トリガーを追加し、対象フォルダーのテキストファイルに関する Created イベントだけを検知させます。
イベントハンドラーの中では、次のステートに渡すメッセージを設定します。
名前変更と削除のトリガーも同様に作成します。
フロー終了のきっかけとなる、クリックイベント検知も作成しましょう。
システムトリガーを使って、マウスやキーボードの入力に反応できるようにします。
「メッセージ表示」ステートは、「イベント監視」ステートから受け取ったメッセージを表示するだけなので、Entry にメッセージボックスを追加したら終わりです。
「フォルダー存在確認」ステートでは、選択されたフォルダーが、表示されていることを確認します。
Entry に「要素の有無を検出 (Element Exists)」アクティビティを追加し、選択されたフォルダーが存在するか調べ、結果をBoolean 型変数に格納します。
タイムアウト値を好みの値に設定します。
この結果を、Transition Condition で使用します。
最終ステートに、「メッセージ表示」ステートで設定したメッセージボックスをコピペすれば完成です。
処理の流れを状態の遷移として捉えて作成していくのが、面白かったです。
開始から終了まで状態が変わっていく様を、あらかじめイメージしておくことが、大事です。
練習で作ったステートマシンを実際に動かしてみると、ファイルを作成したりするたびに、「メッセージ表示」ステートの部分で毎回 OK ボタンを押すことになるのが、面倒くさく感じました。
メッセージは表示してほしいけれど、いちいち OK ボタンを押したくない、そんなときは、メッセージボックスの代わりに、「吹き出し (Callout)」アクティビティを使います。
セレクタや要素で指定したところから漫画の吹き出しのようなものを出し、メッセージを表示する機能で、表示時間をミリ秒単位で設定できます。
表示時間中でも、OK ボタンを押せば、消えてくれます。状況によってメッセージボックスと使い分けましょう。
2018.12.26
参考記事）銀行窓販の事務を支える「ロボ美ちゃん」―日本生命のRPA
（出典：RPABANK 銀行窓販の事務を支える「ロボ美ちゃん」―日本生命のRPA）
日本生命保険相互会社（本社：大阪府大阪市中央区、代表取締役社長：清水 博、以下日本生命）は2014年度12月から導入しているロボットを「日生ロボ美」と名付けている。
日本生命は自国の大手生命保険会社であるが、デジタルプロセスビジョンの実現に向けて非常に早くから敏感に反応している。
その中の一つが「ロボ美」なのである。
「ロボ美ちゃん」はRPAテクノロジーズ株式会社（本社：東京都港区、代表取締役社長：大角 暢之、以下RPAテクノロジーズ）の提供する「BizRobo!」であり、2018年3月には東京本部を中心に合計2種類6台が26業務を担当している。
これら6台の「BizRobo!」は20人分の働きをしているとされており、RPAロボットの最大のメリットの一つである夜間勤務も行う予定のようだ。
さらに、RPA化における壁ともいえる他社員との融和性についてもしっかりと対策をとっている。
「ロボ美」は従来のような、システムとしてのロボットとして考えられているのではなくて、一人の社員として迎えられているようだ。
以下の記事にもあるように一社員として迎えられるような取り組みを行っている。
「その時のRPA女子の取り組みとしては、ロボの入社式をしたり、ロボのキャラクターを作ったりして、事務現場が“新しい仲間”を迎え入れる時と同様の演出をした。また簡単なヒアリングで事務作業を代替するロボをパッと作って、目の前で実際に動かして見せる。事務の現場には女性が多いため、こうしたソフトなやり方が非常にマッチした。」
「日本生命のRPA活用術、AIやBPMN でどう効果を最大化させようとしたのか」（ビジネス+IT）
このような取り組みは、多くの人が誤解している「ロボットに仕事を奪われる」という感覚をなくし、「一緒に働いている」という仲間意識が生まれる。
これにより人間のが本来行うべきであった仕事を行うことができ、仕事の質が向上することで効率化が進むようになるだろう。
今後の取り組みにも目が離せない。
2018.12.25
2018年分の所得税確定申告（以下、「確定申告」）から適用される税制改正内容と会計事務所における確定申告業務でRPAが活用できる作業を紹介します。
確定申告業務ボリュームはその事務所によってばらつきはありますが、ボリュームが多い事務所だと社員一人当たり、40件（40人分の確定申告）程度を担当する場合もあります。
社員10名前後の事務所の場合400件前後の確定申告を2月18日から3月15日まで（2018年分の確定申告の場合）に申告する必要があります。
確定申告業務の中には単純作業もある為、RPAの活用機会があります。
2018年分確定申告から適用される法改正と併せて紹介します。
働きたい人が就業調整を意識しなくて済む仕組みを構築する観点から、配偶者控除・配偶者特別控除の見直しが行われました。
改正ポイントは次の2点です。
・配偶者の給与収入の上限 103万円 → 150万円へ引き上げ。
・納税者本人の収入金額により、控除額を減額。合計所得金額が1,000万円を超える場合は、適用なし。
①納税者本人の受ける控除額
所得控除額38万円の対象となる配偶者の給与収入の上限を、150万円に引き上げられました。
（現行の配偶者控除の対象となる配偶者の給与収入の上限は103万円）
（出典：財務省 平成29年度税制改正）
②納税者本人の所得制限
配偶者控除等の適用される納税者本人に収入制限を設けることとし、給与収入（合計所得金額）が1,120万円（900万円）を超える場合には以下の表のとおり控除額が逓減・消失する仕組みとなりました。
（出典：財務省 平成29年度税制改正）
家計の安定的な資産形成を支援する観点から、少額からの積立・分散投資を促進するための「積立ＮＩＳＡ」が新たに創設されました（現行ＮＩＳＡと同様、口座内で生じた配当及び譲渡益について非課税）。
2018年1月1日以後の投資について適用されます。
（出典：財務省 平成29年度税制改正）
生命保険料控除や地震保険料控除、寄附金控除について控除の適用を受けるためには保険会社等が発行した控除証明書原本の添付が必要でしたが、改正により「電磁的記録印刷書面」もその範囲に加えられることとなりました。
「電磁的記録印刷書面」とは、保険会社等から紙で送られてくる控除証明書に代えて、電子メール等で交付を受けた証明書等の内容を印刷した書面のことです。
電磁的記録印刷書面には証明等の情報の内容と、その内容が記録された二次元コードの両方が印刷されている状態になります。
（出典：国税庁 控除証明書等の電子的交付について）
国税庁では、マイナンバーカードに標準的に搭載される電子証明書やマイナポータルの連携機能の活用などにより、個人納税者の方のｅ-Tax利用をより便利にするためのシステム改修を進めており、平成３１年１月から「マイナンバーカード方式」「ＩＤ・パスワード方式」の２つの方式が利用できる予定です。
①マイナンバーカード方式
マイナンバーカードを用いてマイナポータル経由又はe-Taxホームページなどからe-Taxへログインするだけで、より簡単にe-Taxの利用を開始し、 申告等データの送信ができるようになります。
・e-Taxを利用するためには、事前に税務署長へ届出をし、e-Tax用のID・パスワードの通知を受け、これらを管理・入力する必要がありますが、マイナンバーカード方式では、そのような手間がなくなります。
・e-Taxを利用するために事前準備として必要であった電子証明書の登録が不要となります。
②ID・パスワード方式
「ID・パスワード方式の届出完了通知」に記載されたe-Tax用のID・パスワードを利用して、「確定申告書等作成コーナー」からe-Taxを行う方法です。
マイナンバーカードとICカードリーダライタは不要です。
「ID・パスワード方式の届出完了通知」の発行は、税務署で職員による本人確認を行った上で発行しますので、運転免許証などの本人確認書類を持参の上、近くの税務署で手続きを行います。
なお、平成30年1月以降、確定申告会場などで既に「ID・パスワード方式の届出完了通知」を受け取られた方は、平成31年１月からご利用いただけます。
・マイナンバーカード及びICカードリーダライタが普及するまでの暫定的な対応です。
・ID・パスワード方式は確定申告書等作成コーナーでのみ利用できます。
（出典：国税庁 e-Tax利用の簡便化の概要について）
クライアントへ確定申告のお知らせを郵送やメールで送付している場合が多いと思います。
郵送する場合には、プリントし郵送する手間がかかります。
メールでお知らせする場合も、そのクライアントに応じた「確定申告準備書類の一覧」を添付するなどしますので、一斉送信メールなどのシステムは使用できません。
クライアント専用の書類を添付してメール送信する業務をRPAにより行うことが可能です。
数百通のメールをクライアントオリジナルの書類を添付して送る作業の作業時間削減が期待できます。
申告に必要な、申告の種類や予定納税額などが記載された「申告のお知らせ」は、e-Taxのメッセージボックスに格納されます。例年、1月中旬から1月下旬にかけて格納されます。
確定申告を行う際は、「申告のお知らせ」を取得し、取得するためには以下の手順を踏む必要があります。
１ ブラウザ立ち上げ
２ e-Taxサイトにアクセス
３ メッセージボックスにログイン（利用者識別番号と暗証番号の入力）
４ 該当するメッセージを選択
５ 詳細を表示させる
６ 印刷 or PDF保存
単純作業ではありますが、利用者識別番号と暗証番号は各クライアント専用のため、クライアントの数だけ、同じ作業を繰り返す必要があります。
RPAは上記１～６すべての工程を行うことができるため、人が関わることなく「申告のお知らせ」の取得業務が完結できます。
医療費控除の集計対象が数多くある場合は一度エクセルに入力・集計し、それを申告書作成ソフトの該当箇所に入力している場合が多いと思います。
医療費領収証のエクセルへの入力は人が行う必要がありますが、その後の申告書作成ソフトへの入力はRPAで行うことができます。
会計ソフトと申告書作成ソフトが異なる場合（会計は弥生会計で、申告書はミロク情報など）は、会計ソフトの決算書内容を申告書作成ソフトに手入力する必要があります。
一般的な勘定科目を、会計ソフトと申告書作成ソフトで紐づけることによりRPAで決算書の入力が可能になります。
RPAが会計ソフトを起動し、試算表や決算書のデータをエクスポートします。
その試算表や決算書のデータを申告書作成ソフトの該当箇所に入力します。
人がPCで行う操作と同じことがRPAにより実現できます。
事業所得で、売上先数が多い場合は所得の内訳に記載すべき事項も多くなります。
会計ソフトに入力する際、売上高に補助科目を設定し会計記帳することにより、申告書の「所得の内訳」はRPAにより入力することができます。
作成が完了した申告書の電子送信と、申告書の印刷・PDF保存もRPAで自動化可能です。
電子送信後のメール詳細に取得・印刷・PDF保存も同様に可能です。
2018.12.21
前回は、「業務選定の観点」まで書いたので、それ以降について述べたいと思います。
【前回の記事はこちらから】
◆つくば市のお知らせ
http://www.city.tsukuba.lg.jp/jigyosha/oshirase/1003854.html
◆共同研究実績報告書
http://www.city.tsukuba.lg.jp/_res/projects/default_project/_page_/001/003/854/rpa_report0510.pdf
◆記者発表資料（2017年5月10日）
http://www.city.tsukuba.lg.jp/_res/projects/default_project/_page_/001/003/854/rpa_pr0510_vo2.pdf
つくば市で選定された業務については下記の通りです。
①個人住民税 事業所の新規登録業務
②個人住民税 回送先情報の登録業務（eLTAX 給報）
③法人市民税 法人市民税の電子申告印刷業務
④法人市民税 法人市民税の電子申告審査業務
⑤個人住民税 納税通知書・更正決議書・宛名封筒の印刷業務
⑥市民窓口業務 異動届受理通知業務
⑦財務関連業務 債務負担行為に基づく契約状況・支出状況等の実績入力業務
⑧勤怠関連業務 退勤データ集計、時間外データ集計業務
①の事業所の新規登録業務などについては、分析結果の中に含まれていませんが、業務内容を鑑みれば、RPA化の対象業務になりえる業務のうちの一つかと思います。
職員から解決したい課題として、下記の通りあります。
繁忙期には新規登録が必要な事業所のデータが 1 日あたり 100 件以上発生することがあり、個人住民税システム（基幹系システム）の画面遷移が多いため、入力の手間が非常に煩雑である。また、個人住民税システムと宛名管理システムの画面遷移があり、入力後、宛名管理システムにデータが正しく入力しているか確認したい。
登録業務をやっている人にとっては、画面遷移が多いとストレスフルになります。
またストレスを感じると入力ミスも増え、入力ミスが増えるとストレスが増え、と無限ループに入ってしまいます。
特に単純入力で良い業務は好きな人もいますが、画面遷移が多いとストレスフルな業務になります。
業務改善が好きな人にとっても業務フローの効率化を図ると、画面遷移に関しては手の出しようがない部分でもあります。
しかし、そのような業務でもロボットはストレスフリーであるため、画面遷移が多い業務についても選定するポイントの一つになります。
処理件数や処理時間を見ると、年間3,900件、年間146時間とありますが、個人住民税の事業所登録の繁忙期は、課税する時期に多くなるかと思いますので、恐らく２月～6月ぐらいまでが多そうな感じがします。
地方自治体の仕事の繁忙期の多くは4月前後に固まっていることが多く、一方で職員の異動時期も４月であるため、３月は生産性が高く、異動のため、新たに異動してきた職員がいるため、4月の生産性はかなり低いと言えます。
業務選定のポイントにロボットの適性に合った業務、いわゆる単純・反復業務が向いていると言われていますが、人間にとってストレスフルかどうかという観点から選ぶことも大切かもしれません。
つくば市ではRPAの導入において下記のように検討しました。
今回の実証実験が他の自治体でも使えるような汎用的なものというのを意識しているのだと思います。
個人住民税システムの画面遷移が多く時間を要するため、登録すべき情報を紙媒体の総括表はFilemaker（データベースソフト）に事前登録し、RPA 作業用の一覧表（Excel）を出力する。また、eLTAXから出力可能なデータは出力後に住所分割して一覧表を作成する。なお、つくば市においては既存のデータベースソフトを活用し一覧表の作成を行ったが、RPA において本ソフト利用は必須ではなく、Excelでの作成も可能である。
その一覧表の情報を基に、個人住民税システムの事業所入力・更新から宛名管理システムでの登録確認までを RPA に代行させるシナリオを作成した。
システムに直接入力するのではなく、ExcelやFilemakerというデータベースに入力し、ロボットが自動的にデータベースからシステムに転記してくれるので、画面遷移の時間やマウスを動かしているなどの操作ラグ分の効率化が図れることができるという流れです。
現在のRPAの運用で良くあるパターンですが、システムに直接入力するよりも、人が入力しやすいフォーマットに出来るので、単純な入力スピードも相当速くなります。
どのようなフォーマットに打ち込むことで間違いが減るなどはPDCAを回したことがある業務改善経験者の十八番とするところです。
①の事業所の新規登録業務については、人間が作業する時間が146時間から約40時間と大幅に減っています。
一方でロボットが作業する時間が76時間発生しています。
人間がシステムに入力するのをやめて、ロボットにシステムに入力させるために、人間がFilemakerに入力するだけで、大幅な時間削減ができます。
人間が入力する業務を、OCRを使ってできないものかと考えてしまいますが、使っているシステムによっては、OCRを使わずとも、Excelなどのデータベースに打ち込むだけで大幅な削減効果が出ることが実証されたのだと思います。
他の業務も含め、削減率が実施業務の平均が84％とRPA化を行って満足のえる結果と言えます。
課題については凡そどこの自治体とも変わらないように思います。
①システム面については、タブレット端末の普及は難しいとかと思いますが、OCRについては今後導入が進むかと思います。
②体制面と③運用面については、全庁横断プロジェクトチームという大きなものでもなく、情報政策系や企画政策系で外部委託をすることが一番簡単かと思います。
ただし、RPA関連のサポートデスク系事業者はまだまだ充実していないため、従来のサポートデスク事業者と比べると不十分な可能性があります。
①システム面
課題：入力元となる申請書（紙）の電子化が未整備
対応策：申請書の電子化対応（タブレット端末やOCR の採用）
②体制面
課題：RPAのシナリオ作成が可能かつ業務に精通した人材の育成、RPA導入・展開時に庁内をリードできる部門や人材のリソース不足
対応策：各課RPA導入リーダーの任命、各課 RPA 導入リーダーと導入主幹部署との全庁横断プロジェクトチームの発足
③運用面
課題：効果的・効率的なRPAシナリオ運用管理方法の整備、RPA関連スキルを有する人材を継続的に配置するための教育・研修制度の整備
対応策：RPA 共有サイトの作成（シナリオ共有、FAQ、E-Learning 等）
つくば市の考察では、①担当課職員によるRPA内製化、②職員のRPA人材育成、③紙への対応、以上の３点について述べられていました。
内製化や人材教育についての課題というのは数年後には解決できるようになるかと考えています。
なぜなら、RPA関連の人材育成は今年から盛り上がってきており、RPAのシナリオ作成できる人材が増えれば、RPAのシナリオ作成が特別すごい事でもなく、ExcelやAccessのように少しトレーニングすれば誰でもできるように定着化もしていくかと思われます。
現在RPAベンダー各社の思惑としてはRPAツールの普及を目指しており、より使いやすいツールに変化しています。
業務コンサルタントが行うRPA導入コンサルティングというのは、業務を知らない人間が行っており、導入効果が思ったほどでないケースもあります。
現場の業務を熟知している職員が主体となって導入することで、RPA導入効果を大幅に上げることができるかと思います。
今回、つくば市の記事を書きながら思ったのは、業務選定のポイントとツールとしての使い方がかなり勉強になる部分が多かったように思います。
プログラミングもそうですが、複雑にすることよりもシンプルにすることが大切なことだと思います。
2018.12.20
本日は、茨城県つくば市で行った「RPAを活用した定型的で膨大な業務プロセスの自動化」共同研究の報告書を紹介したいと思います。
つくば市は、全国の地方自治体で初のRPAによる働き方改革を実施したことで、全国の地方自治体の方々がベンチマークしている自治体です。
2017年度に実施した内容なので、前回の一宮市と比べると物足りないような感じを受ける方はいるかもしれません。
しかし、RPA、特に地方自治体のRPAが置かれている環境は日進月歩、日々新しい情報が出てきます。
◆つくば市のお知らせ
http://www.city.tsukuba.lg.jp/jigyosha/oshirase/1003854.html
◆共同研究実績報告書
http://www.city.tsukuba.lg.jp/_res/projects/default_project/_page_/001/003/854/rpa_report0510.pdf
◆記者発表資料（2017年5月10日）
http://www.city.tsukuba.lg.jp/_res/projects/default_project/_page_/001/003/854/rpa_pr0510_vo2.pdf
「RPA（注１）を活用した定型的で膨大な業務プロセスの自動化」
市役所の業務には、単純で定型的な作業ではあるが、量が多いため多くの労働時間を費やしているものがある。
特に確定申告時期の税務処理には多くの時間外労働が担当課職員に課せられている状況にあります。
これらの課題解決のためにRPAを活用することで「作業時間の短縮（効率化）」と「ミスの少ない正確で的確な処理」の効果を研究しました。
■市民税課（５業務）
新規事業者登録や電子申告の印刷作業等の全５業務にRPAを導入し、結果として、３カ月で約 116 時間の削減、年間換算で約 336 時間の削減見込み。
424 時間 44 分 ➡ 88 時間 18 分（削減率 79.2％、43.4 日削減換算）
■市民窓口課（１業務）
異動届受理通知業務にRPAを導入し、結果として、３カ月で約 21 時間の削減、年間換算で約71 時間の削減見込み。
85 時間 ➡ 14 時間 10 分（削減率 83.3％、9.1 日削減換算）
【職員の声】
・「処理件数が年々増えていく一方で、対応できる職員数は限られており、RPA によって簡易な入力、確認作業が軽減できてとても助かった。」（市民税課）
・「単純な事務作業にかける時間が他の業務に回せるようになるので、ぜひ早期導入を期待します。」（市民窓口課）
・共同研究成果を踏まえ、今年度にRPAの本格導入を目指します。
・市議会での審議も必要になりますが、今年度は、市民税課・市民窓口課に加え、納税課・資産税課への導入を予定し、来年度以降効果が見込まれる部署を対象に順次導入を行う予定。
・例えば、市民税課業務全体の５％にRPAが適用できた場合、年間で約 1,400 時間の作業時間が削減でき、約 370 万円相当の時間外勤務手当が削減できる見込み。
■共同研究の概要
公募 ：平成 29 年 10 月 5 日～31 日
契約締結：平成 29 年 12 月 8 日 ※選定会議を経て共同研究者を決定
検証期間：平成 30 年 1 月～4 月上旬
研究対象課：市民税課、市民窓口課、ワークライフバランス推進室、財政課
※財務関連業務、勤怠関連業務についてはＲＰＡの適応可能性調査のみ
共同研究者：株式会社ＮＴＴデータ、株式会社クニエ、日本電子計算株式会社
共同研究報告書には研究目的は下記の通りにあります。
『本研究では、行政における「働き方改革」の実現を念頭に、RPA を活用した業務プロセスの見直しによる生産性の向上、RPA の効果的な導入に必要な環境整備（正規職員、非正規職員等の新たな役割分担の検討含む）のほか、具体的な指標を設定して、RPA 導入による職員の残業時間の削減効果を算出する。
また、単なる業務削減ではなく、定形作業の負荷軽減・効率化を行い、市民からの相談や窓口業務等に職員がより時間を割り当てることで市民サービス向上を目的とする。』
民間企業でもそうですが、『RPA の効果的な導入に必要な環境整備（正規職員、非正規職員等の新たな役割分担の検討含む）』にひっかかる方が多いかと思います。
RPAが導入されることで仕事がなくなるという不安、テレビなどではAIが仕事を奪うなどコメンテーターが発言を耳にする機会が増えてきました。
民間企業だとこのあたりは人件費をカットするということを主としていますが、公共団体には雇用創出ということもしなければいけないので、RPA導入によって、職員からの役割がどのように変わったのかなども含めて知りたいところです。
つくば市の実験では明確に『市民からの相談や窓口業務等に職員がより時間を割り当てることで市民サービス向上を目的』を掲げており、職員の声ではなく、市民の声を拾って欲しいと思います。
実際、RPA導入で窓口サービスが向上したのかどうか、市民がどう感じたのかが集計が必要かと思います。
全国各地の自治体で、『市民サービスの向上』を謳い、様々な施策を行っています。
比較的多いのは、案内係や市民センターの充実などです。
そのような施策を行う場合、アンケートで市民から窓口対応の充実度を測っており、RPAについても同様の測定が必要かと思います。
今回、つくば市を選んだ最大の理由は業務選定にあります。記者発表資料には記載されていませんが、共同研究実績報告書に下記の通りあるからです・
つくば市の業務は市民や事業者からの申請届出等に基づく事務処理を行う「基幹系業務」と市役所内の職員を対象とした「内部事務系業務」に大別される。基幹系業務及び内部事務系業務において、複数の RPA 候補を選定した。
さらに、今後の全庁導入や全国の自治体でのモデルケースとなるため、汎用性の高い業務を候補とすることで、他市導入時の参考となり得るよう業務選定を行った。
実際、地方自治体業務のうち、何にどれくらいの時間がかかっているか報告書のP.13からP.14にかけて具体的に記載されています。
こういった参考になる資料は少ないため、かなり参考になるかと思います。
全体的に入力（投入）業務が多く、入力業務はRPAを導入するにあたり、最大の課題であり、AI-OCRの技術力の進化が人間の思うレベルに達するまでを待つのか、現在の技術力で運用を工夫するのかがポイントかと思います。
当社はどちらかというと前者ですが、後者の企業も増えてきており、効果を出しているという話は聞いています。
筆者が以前訪問させていただいた企業ではOCR×RPAを既に導入しており、生産性を大幅に上げて効果を出しているまでは伺いましたが、具体的にどのような運用をしているかまでは教えていただけませんでした。
つくば市の報告書には業務選定の観点として下記の通りあります
「全庁職員アンケート」及び「個別業務調査」により業務削減ニーズや削減効果の高い業務プロセスの中から、「業務量」「難易度」「RPA の技術特性」「他自治体への汎用度」の観点にて RPA 対象業務候補として選定した。
「業務量」、「難易度」、「RPAの技術特性」というのは、一般的な観点です。
「RPAの技術特性」とはRPA化するにあたり、大量反復で行う業務かどうかという観点で判定されるポイントです。
つくば市では、「他自治体への汎用度」を踏まえており、他の自治体関係者が参考になる点を意識しており、その効果などは無視できないものでもあります。
次回へ続く
2018.12.19
皆様、こんにちは。
本日は、最近気になったRPA関連の記事を紹介しつつ、コメントしたいと思います。
https://japan.cnet.com/release/30278547/
CTC教育サービスを提供するCTCテクノロジーは、UiPathによるシナリオの作成や実行を通して業務を自動化する教育コース「業務自動化 UiPath初級編(RPA)」を提供しており、この度、UiPathに習熟し質の高いトレーニングを提供できる企業としてUiPath社のパートナープログラム「トレーニング・アソシエイト」契約を締結しました。
「働き方改革」を推進するうえで生産性向上は必須要素です。従来手作業で行っていたPCを利用した定型業務を自動化し、「業務の品質向上」「作業時間の短縮」を実現するためにはRPA(Robotic Process Automation)の活用が有効です。
RPAエンジンにて各業務に最適な「シナリオ」を作成、実行することにより、業務の自動化を実現します。
「業務自動化 UiPath初級編(RPA)」では世界3大RPAエンジンの一つである「UiPath」のシナリオ作成（初級編）および「RPA導入の落とし穴に陥らないための解決策」を学習します。
現在、私もトレーニングを行っていますが、改めて人に教えることは難しいと感じます。
研修で教えることで私が大切にしていることは目的と目的意識です。
私が行っている研修の内容はUiPathのシナリオ作成のトレーニングですが、研修の目的は業務の効率化に置いています。
UiPathのシナリオ作成は、あくまでも手段であり、目的ではないという認識で教えています。
このニュースの中にある「RPA導入の落とし穴に陥らないための解決策」という点で、恐らくRPA適用業務の業務選定を行うコツなどを参考にしたいと考えています。
https://japan.zdnet.com/article/35127754/
アイ・ティ・アール（ITR）は、国内のRPA（Robotic Process Automation）市場規模推移および予測を発表した。
2017年度のRPA市場は売上金額で35億円、前年度比約4.4倍の急速な伸びを示した。
2018年度も引き続き同2.5倍の高い伸びを予測している。2022年度には400億円市場となり、2017～2022年度の平均成長率は62.8％を予測している
同社では、2017年度はそれまで金融・保険業など一部の業種で先行していたRPAツール導入の動きが他業種へも広がった年だったとし、2018年度は試行段階にある企業での本格稼働が進むことから、市場規模は大きく拡大するとしている。
また、2018年に入ってからは手作業によるデータ入力業務において、RPAと連携する形でOCR（光学認識）を活用し、業務の効率化を目指す企業が増え始めているとしている。
OCRの歴史は長いものの、その認識精度の問題から企業での導入は限定的だったが、近年の人工知能の活用による認識精度やデータの自動抽出機能の向上により、OCRが見直されているという。
さらにRPA導入を機に業務システム全体の見直しを検討する企業も増えつつあり、これに伴いBPM（Business Process Management）やBRMS（Business Rule Management System）の導入を検討する企業も出始めているとした。
RPA市場の広がりは、RPAの開発現場で働いている人達から聴くと千差万別です。
現在、私が担当しているプロジェクトは、現場で働く人達の声を受けてRPAを導入し、効果が出ているため、別の業務もRPA化しようという声が出て、開発の延長を受けています。
一度導入し効果が出ると別の業務も導入したいという風になります。
一方、10人などの少人数の零細企業では、業務の1件1件が少ないため、RPAを導入しようという気すらありません。
零細企業に対し、RPAで力になれることがないかと考えますが、中々良いアイデアが浮かんできません。
これは自分自身に対する今後の課題かと考えています。
https://www.sankei.com/life/news/181029/lif1810290022-n2.html
（一部省略）
損保ジャパン日本興亜は、すでに導入されている顧客情報印刷などを自動化するRPA（ロボティック・プロセス・オートメーション）を７月に強化。
事務処理の自動化の領域をさらに拡大することで、被災地の保険金支払いまでにかかる時間を短縮している。
RPAの効果が保険金の支払い迅速化に役立っているとは、RPAに関わるものとして大変喜ばしい限りです。
リードタイムが短縮できることによって、保険の加入者もそうですうが、消費者へ還元できることは他にも色々あるかと思います。
また、金融業界における業務のRPA化は他の業界と比較して早くから取り組んでいる企業も多く、効果も高いため、今後も金融業界を中心にRPA化が拡大していくと思われます。
https://www.sankei.com/west/news/181024/wst1810240006-n1.html
大津市は２３日、ＡＩ（人工知能）やＩｏＴ（モノのインターネット）などの本格導入に向け、若手職員による「チーム“未来都市おおつ”」プロジェクトの成果発表会を行った。
ＡＩを活用した書類の自動作成などの具体例が説明され、幹部職員らが聞き入った。
プロジェクトは４月に立ち上げた企画調整課内の部署で、技術革新の調査を行う「データラボ」が主導。
さまざまな課の若手職員２５人が５班に分かれ、９月から行政サービスにＡＩやＩｏＴなどの先端技術を導入する具体策を練ってきた。
この日の発表会には、越直美市長も出席。若手職員が、行政相談に自動対話ロボット（チャットボット）で対応することや、市民からの申請書類を電子化することで、関係書類を自動的に処理して印刷まで行うＲＰＡ（ロボットによる業務自動化）などを提案した。
出席した幹部職員からは「具体的にどの部署でできるのか」「ロボットが補えない部分の対応はどうするか」との質問が上がった。
越市長は「先端技術を導入すれば、市民サービスの向上や職員の負担軽減につながると感じた。来年度にも、できるものからやっていきたい」と話した。
行政が行政サービス向上のため、先端技術を導入することは大変喜ばしいことです。
私が市役所に行くとデジタル化されていない点が多く、開発者としてこうすればもっと良くなるのにと思うことがよくあります。
RPAの対応についてもやはり民間と違い、遅れている部分も多々あります。行政関連だと外字対応をどうするのかということも気になります。
またOCRを導入してもどうなるのだろうというには一開発者として気になります。
例えば「渡辺」という名字は、渡邊・渡邉など様々な「辺」があり、規格として認識されない場合、エクセルなどで「■」で表示されることがあったりします。また、OCRで読み取ることは出来るのだろうかと気になることです。
先端技術を先端技術として導入すると「先端技術」が「陳腐化」した場合、どうするのかという問題が生じます。
例えばペッパー君なんていうのはペッパー君には申し訳ないけど、「先端技術」で物珍しさもあったので、商業スペースで活躍していましたが、今ではどうでしょう？
先端技術というのはメリットばかりではないという認識は必要かと思います。
RPAが今後どのようになるのかはまだまだ発展途上なため、新しい機能なども追加されるかと思いますので、どうなるかは今RPAに関わる技術者の腕にかかっています。
◆ペッパー君さようなら 8割超が“もう要らない（週刊朝日2018）
https://dot.asahi.com/wa/2018102400011.html
今回は４つの記事にコメントしましたが、RPA関連はtwitterなどのSNSにも情報が挙がっており、情報収集するととても面白い発見があります。
今回はあくまでもメディアで発信された内容ですが、SNSは個人で発信しており、実際開発している人達の生の声を聴けて、開発者としてはとても参考にもなるし、刺激にもなります。
皆様もTwitterなどで♯RPAや♯UiPathなどで検索すると意外な発見があるかと思います。
2018.12.18
今回は、RPAを使用したウェブブラウザの操作方法およびシナリオの作り方の記事を書きたいと思います。
RPAを導入する前の読者の皆様が、RPAを導入すると具体的にどのような作業が楽になるのかの参考にしてください。
前提として・・・
筆者は一事務員であります。
そのため、パソコンに精通しているわけではありません。
偶々RPAのシナリオ作成者に抜擢され、他の通常業務の傍で作業を進めていますが、筆者の作成したシナリオのおかげで事務員全体の業務効率は確実にあがりました！！！
従いまして、パソコンの知識に貧しい事務員でもRPAを操作し、効果を出すことは充分に可能です。
「これならうちの事務員でもできるな」と言う目線で読んでいただけたら幸いです。
また、弊社ではRPAソフトの中でもWinactorを使用しているため、この記事の中ではRPA＝Winactorであることをご承知おきください。
Winactorは、RPAソフトの中でも直感的に作業ができると言われており、知識のない人が担当になる場合に検討すべきソフトの一つです。
ウェブブラウザ（IE、Safari、Firefox等）の操作は事務業務の中でも使用する機会が多い仕事だと思います。
従って、ウェブブラウザの操作をRPAにより自動化することで事務業務の効率化ができます。
では、RPAで自動化できるウェブブラウザの操作とは、どのようなものが対象なのでしょうか？
結論から申しますと、一般事務レベルの仕事はほとんど自動化できます！！！（本当です！！！）
ボタンのクリック、リストの選択、テキストボックスへの入力、画面サイズの変更、印刷・・・
どの操作も自動化可能です！！
ちなみに、筆者の会社ではIEを使用しているため、IEに特化した記事になります。
他のウェブブラウザも基本的に操作方法は同じであると思いますが、機能に制限がある場合がありますのでご購入の前にはご確認ください。
＜サンプル＞
ここで、説明をより具体的にするため、ネットショッピングの例をあげます。
読者の皆様が、白いワイシャツ（Mサイズ）を１着ネットで購入するとします。
その時のウェブブラウザ操作が全て自動化できる、と考えていただいて間違いありません。
購入までの操作はおおよそ下記のようになると思います。
①購入したいワイシャツを選択する（対象商品をクリック）
②数量（１）を入力する（テキストボックスへの入力）
③色（白）・サイズ（M）を選択する（リストの選択）
④カートへ入れる（ボタンをクリック）
⑤配送先・支払い情報を入力する（テキストボックスへの入力）
⑥購入ボタンをクリックする（ボタンをクリック）
括弧内がRPAの操作に使用するパーツになります。
これらのパーツを使用すれば大方の事務作業は完了するはずです。
それでは、上述したパーツの作り方、および、パーツを用いて実際にシナリオを作成する工程を説明したいと思います。
但し、パーツとパーツの間の細かな作業（繰り返しやエラー対策等）は割愛しますので、イメージを掴んでいただけたらと思います。
ボタンのクリック、リストの選択、テキストボックスへの入力、画面サイズの変更、印刷も、まずIEの対象のページを指定する必要があります。
この作業はとても簡単です。
Winactorの中に“記録対象アプリケーションの選択”という機能が予めに備わっているので、それを使うだけです。
図１は実際のWinactorの画面になります。
（図１）
図１のターゲットマークをクリックした後に、IEの対象ページをクリックすれば完了です。
Winactorへ「このIEのページを今から作業しますよ」と記録させることができます。
次に、実際の作業を憶えさせます。図２をご覧ください。
（図２）
赤い丸のマークがあります。これは録画を意味するマークになります。
この赤丸をクリックすると“記録”が開始されます。
“記録”を開始したら、実際にIEの作業を行います。すると、IEの作業が自動的に録画されます。
それでは、先ほどのネットショッピングの例に当てはめて考えていこうと思います。
まず、図１のターゲットマークをクリックし、購入したいウェブサイトのページを指定します。
次に、図２の赤丸をクリックし、下記を実際に作業し、操作を録画します。
①購入したいワイシャツをクリックする
②数量（１）を入力する
③色（白）・サイズ（M）を選択する
④カートへ入れる（ボタンをクリック）
⑤配送先・支払い情報を入力する（テキストボックスへの入力）
⑥購入ボタンをクリックする（ボタンをクリック）
以上で、RPAは白・Mサイズ・ワイシャツ・１着の購入作業を自動化できたことになります。非常に簡単です。
それでは、同じワイシャツだけれど、水色・Sサイズ・２着と、黄色・Lサイズ・５着を購入したいときはどうすればいいのでしょうか。
基本編で作成したシナリオを応用することで、自動化が可能になります。
ここでは簡単に作れるエクセルを使用します。（図３）
|
番号 |
色 |
サイズ |
数量 |
|
１ |
水色 |
S |
２ |
|
２ |
黄色 |
L |
５ |
エクセルへ、予め購入したいワイシャツの表（図３）を作成します。
番号１を購入し、次に番号２を購入するとします。
その時、シナリオは下記のようになります。
これで、自動的に水色と黄色のワイシャツを一度に購入できることになります。
今回はネットショッピングの例で説明し、サンプルを２行しか用意していないので、自動化するより人手で購入した方が早いと思われるかもしれませんが、「エクセル上の大量のデータをウェブブラウザ上へ入力し、クライアントへ連絡する」という事務作業に置き換えたらいかがでしょうか。
また、「エクセル上に入力している数値を使って、ウェブブラウザ上で発注作業をする」という場合にも効果を発揮すると思います。
劇的に業務効率化をすることができますし、人手のように転記のミスがなく入力されるという副産物もあります。
予想される問題として、“シナリオを作成してみる（基本編）”で説明した記録の方法がうまく機能しない場合があります。
記録をとることが出来ない場合には、“画像マッチング”という機能を使うことで解決することが出来ます。
“画像マッチング”とは、その名の通りRPAに覚えさせた画像と、パソコン上に表示されている画面を比べて、マッチングするかどうかを判定する機能です。
この機能を使うことで、記録機能が使用できない場合にもウェブブラウザの作業を自動化できることになります。
つまり、自分たちの使っているサイトが特別な仕様で自動化ができないかもしれない・・・という不安を払拭してくれる機能と言えます。
実際に、筆者も記録機能であるボタンがどうしてもクリックできない、という場面に直面することがあります。
その場合は、画像マッチングを使用してシナリオを作成しています。
今回は、ウェブブラウザ作業の自動化の仕方を説明しましたが、簡単にできそうだと考えていただいて間違いありません。
とても簡単です。
RPAに予め備わっている記録機能を使うことで、誰でも簡単にシナリオを作ることが可能です。
また、記録機能が万が一うまく機能しない場合でも、画像マッチングという第２に手を使うことで、シナリオの作成は可能です。
ウェブブラウザ作業を自動化することで、読者の皆様の事務員の業務負担を減らすことができるはずです。
2018.12.17
私たちの職場では、多くのバックヤード業務が担当者によってブラックボックスと化しており、そのままではRPA化できません。
ポイントとなるのは上手なワークフローの作成です。
なぜならRPAは自ら考えることはできない、ワークフロー通りに処理を進めるからです。
ではどのようにワークフローを創るのか、担当者からフローを如何に引き出すか、全部を自動化すべきかといった点について経験を踏まえて解説します。
昔から生産現場では、あらゆる工程が「標準書」によって可視化されてきました。
例えば飲料メーカーで中味を製造するとき、事前準備（各設備の点検・投入原料の秤量）や工程（攪拌時間と温度・原料の投入順序等）といったこまごまとした手順が標準書に記載されています。
ものづくりは、1人ではできません。
チームを組んで分業制で作業し、常に一定の品質を保証し続けるために、「標準書」は必須なのです。
一方、スタッフ業務は、どちらかといえばパソコンに向かって行う作業も多く、どちらかといえば個人プレーが主体です。
経理・総務・人事などのスタッフ業務を経験された方はお分かりかと思いますが、人事異動や担当変更で仕事を引き継ぐとき、前任者から業務フローやマニュアルを渡されるケースは、どちらかといえば稀です。
あったとしても、担当業務が箇条書きされ、手順や要領が記述されている、といった類が大部分です。
前任者から渡されるのは、過去のメールのやり取りや提出資料（紙やPCファイル）で、業務推進のポイントを口頭で1時間ほど説明を受けて終了です。
こんな引継ぎでも、2-3か月すればこなせるようになってしまうのですから、人間は順応性が高いのです。
RPAによる自動化を進めるためには、ワークフローは必須です。
ロボットは人間と違って臨機応変には対応できないからです。
ワークフローの目的は、業務の「みえる化」です。
業務の中で「属人化」しているプロセスをあぶりだし、「共有化」していきます。
同時に、手順やスケジュールがあいまいで個人の経験に頼っていたようなプロセスを「ルール化」します。
例えば給与の源泉徴収業務において、給与支払いデータのダウンロード・集計から税務署提出資料（源泉徴収票）への転記まで、一連の業務プロセスと留意点（他部署からデータをもらう場合の入手要領・給与データと会計データの照合等）を整理し、だれが見てもわかる形に「共有化」します。
同時に、他部署からのデータ提出期限（給与センターからの給与実績など）があいまいだったりする場合には、これを機会に提出期限を明確にします。
この「共有化」「ルール化」が、RPAの円滑な推進に役立つのです。
ワークフロー作成の進め方は、まず業務を棚卸しし、次にワークフロー作成、最後に業務プロセスを見直す、という順番です。
ワークフローがRPAに役に立つといっても、作成には手間がかかります。
すべての業務についてワークフローを作成するのは効率的ではありません。
そこで、業務を棚卸したうえでRPA化の対象とする業務を絞り込み、対象業務に限ってワークフロー化するのです。
業務棚卸リストは後々の検索性・加工性を考慮し、エクセルファイルで作成します。
リストの横軸は、以下のような項目で構成します。
・部署・担当者名、業務分類
・業務名・簡単な業務手順
・業務マニュアルの有無
・業務ボリューム（作成時間・作成頻度・複数の事業所や担当者で同じ業務を行う場合にはその数）
・RPA展開する上での業務ステップ
（コピーペーストまたは参照・ファイルダウンロード・集約・メール送信・メール受信・照合・アップロード・ファイル保存など）
・使用するシステム（基幹システム・業務システム・市販ソフトウエアなど）
事務局は各部署からリストを集め、以下の項目を勘案してRPA化対象業務に優先順位をつけます。
まずはプロセスがシンプルなワークフローを作りやすい業務からスモールスタートし、次のステップで複雑な業務にもチャレンジしていくのが、RPA化の定石です。
・業務ボリュームが比較的大きくRPA化効果を発現しやすい
・整備された業務マニュアルをベースにワークフローを組める
・（最初は業務ステップがシンプルかつ関連する部署が少なく、ワークフローを組みやすい
・（シナジー効果が期待できるので）極力基幹システムを使っている業務を選ぶ
次は絞り込んだRPA化対象業務について、ワークフローを作成します。
ワークフローとは一定の約束事により定められた図形記号と矢印により業務の流れを記述するフローチャートです。
（ワークフロー作成の約束事）
1部署が作成したワークフローはRPA推進事務局に提出された後、シナリオ編成部隊・ベンダーやコンサルなどのサポート部隊も目を通します。
関係者全員が判別できるようにするためには、以下に示すようなの約束事が欠かせません。
・フローチャートの横側に詳細記述欄を設け、同時に図形記号にナンバリングし詳細記述と紐づけします。
・業務の成果物・ダウンロードデータ・規定類・帳票類・システム入力画面など関連情報・資料をリンクさせます。
・横軸を組織、縦軸を時系列とするマトリクスシートに記述します。
（記号の種類）
フローチャートで使う必須の記号は、以下の3つです。その他に必要に応じて接続・帳票といった記号を追加したうえでルール化します。
特に業務がいくつかの工程に分かれる場合、サブプロセス記号を使えばワークフローをいくつかに分割できます。
ただし、図形記号の数はあまり増やさずシンプルにとどめておくことが基本です。
基本以外の図形記号は、読み手に意味が伝わりにくいのです。
凡例を付ければ判別はできますが、判読性は確実に落ちます。
（分岐の使い方）
分岐は業務プロセスを表現する上で欠かせませんが、わかりやすくするためには極力シンプルさを心掛けると同時に、やたらと使うのは避けなければなりません。
・頻度が高い補正処理は分岐とせず標準ステップとしてのワークフローに組込む
・分岐が細かくなりそうな場合には小さめの文字の箇条書きで代用する
・2連分岐はわかりづらいので1つの分岐記号にまとめる
業務プロセスを正確に記述するのがワークフローの目的ですが、作成過程で様々な不整合や非効率が見えてきます。
例えば、入力原票のエクセルフォーマットが事業所毎に異なるようなケースでは、この機会にフォーマットを統一するのが得策です。
ただし業務見直しが目的ではないので、見直しが難しいような業務に関しては特記事項欄にその旨とどめておくようにしましょう。
ワークフローの作成は、基本的に社内のリソースで対応すべきです。
それは、実務をもっともよく知っているのは現場の社員であり、作成は彼らに任せるべきなのです。
ただし、最初は自己流で進めるのではなくサポートを受けることをお進めします。
RPAベンダーの多くも、実践を兼ねたワークフロー作成研修の提供や、作成指導を提供しています。
こうした支援を積極的に活用すべきでしょう。
最後まで目を通していただき、ありがとうございました。
この記事が、ワークフロー作成に少しでも役立ち、RPAの円滑な推進に少しでもつながれば幸いです。
2018.12.14
【検索エンジン「スタンバイ」調べ】
検索エンジン「スタンバイ」（ https://jp.stanby.com/ ）による「RPA」関連の求人の調査によると、「RPA」を含む前年度求人比が6.4倍であると発表した。
「スタンバイ」は株式会社ビズリーチ（本社：東京都渋谷区、代表取締役社長：南 壮一郎、以下ビズリーチ）が運営している検索エンジンである。
「RPA」のワードを含む求人件数は1961件にのぼり、最高提示年収は3000万であった。（上表参照）
さらに、「RPA エンジニア」が含まれる求人に関しては前年度比9.1倍まで伸びた。
「RPAコンサルタント」を含む求人は前年度比6.0倍となっているが、絶対数では698件と「RPA エンジニア」の556件よりも100件以上多くあり、年収も「エンジニア」の2000万円に比べて1.5倍増の3000万円と増かしている。
現在、RPAに関するスキルや経験を有する人材へのニーズが高くなっているのが明らかに分かる。
特に、エンジニアはコンサルタントに比べて絶対数が低いにもかかわらず前年度比が大きいということで、今現在、ニーズが活発に高まってきていることが分かるだろう。
特に、金融機関や大手企業、さらには中小企業まで幅広くRPAを導入する企業が多くなってきた現代では多くのエンジニアやコンサルタントが求められている。
そんな中、大手ベンダーでもRPA人材の育成のためのツールの開発やRPA勉強会なども開かれているようだ。
2018.12.13
【前回の記事はこちらから】
人材開発が着目するのは「その人」「個人」であるのに対して、組織開発が対象とするのは人と人との「関係性」になります。
この関係性の変化が組織を変化させていくという考え方になります。
具体的な例を見ていきたいと思います。
「営業マネジメント力の強化」という課題があったとします。
人材開発のアプローチでは、マネジメントする立場の社員本人に問題があると捉えます。
そのため、本人に対して「マネジメント研修」や「モチベーション研修」といったような施策を講じるのが一般的です。
これに対して組織開発のアプローチでは、本人とその職場メンバーとの「関係性」に問題があると捉えます。
そして、その関係性の改善を図ります。
マネージャーと部下の間で協力関係が築けていなかったり、期待する目標や課題認識にずれがあったりすることが多いためです。
施策としては個人に対する研修等ではなく、本人と組織メンバー全員参加のワークショップを通して、ファシリテーションして問題点を浮き彫りにしたり、組織の間でコミュニケーションを活発化させるようにコーディネートしたりします。
関係性に良い変化を起こそうとすることが、組織開発型のアプローチです。
組織開発の目的とは、「組織が環境に適合しながら変化し、健全に、効果的に機能すること」といえます。
現代においては同じプロジェクトメンバーだからといっても滅多に顔を合わせないことも多く、ちょっとした意見の相違や勘違いが業務上の大問題へと発展することも少なくありません。
当事者だけで議論を尽くせば解決するかというと、内部からだけでは見えにくい事も多く、第三者が外から客観的的に観察し分析をすることで、問題が解決できることも少なくありません。
今までの人材開発のアプローチは研修の場をセッティング・企画して、その社員に対してトレーニングを行うといった形式が一般的でした。
つまり、社員が人事の領域へ来てもらう方向になります。
これに対して組織開発のアプローチでは、実際の業務が行われている現場に人事の方から飛び込み、組織内の会議体に積極的に参加したり、業務上の課題などを把握したり、人事が存在感を示す事で変化をもたらす事が求められます。
例えば、「個人としてはすごい優秀な社員のはずなのに組織上でその能力が発揮できていない」というケースや、「十分な処遇をしているはずなのに、組織へのコミッションが低く、離職のリスクがある」というようなケースがあるのではないでしょうか。
そのような時には、個人へのアプローチではなく組織全体へのアプローチが必要なのかもしれません。
組織開発のパイオニアともいえるリチャード・ベッカードの定義によると、組織開発とは以下の7項目を実践していくこととされています。
目標としたものは漠然としたものではなく、「何を、いつまでに、どのような状態にしたいのか」を明確にしなければなりません。
詳細な目標設定はその効果を予想しやすく、ビジョンとしてもとらえやすいため、大きな成果を生み出します。
いきなり組織全体で組織開発をしようとするのは無理が生じます。
特定の部署から徐々に始めて、組織全体に波及させるほうが効果的とされています。
その時、特定の部署を設定する際は、ある程度意欲的に変化を受入れる組織を選ぶと効果的です。
組織のトップである経営者が組織開発にコミットして、メッセージを発信していきます。
この際のメッセージは、組織全体に同じ方向を向いてもらうために、企業理念や会社としての目標などを織り込み共有します。
トップが積極的に下部組織と関わることで、必要としている支援も見え、経営者としての行動も起こしやすくなります。
組織開発はすぐに結果が出るようなものではありません。
長期的な継続の間、変革に対する強い志を持った関係者の協力が欠かせません。
現場での変革に対する動機づけや方向性、具体的な取り組みについての意見交換や、組織への積極的な関与が必要です。
組織開発の長期的な取り組みの過程において、その効果の測定や再評価が必要となります。
目標との乖離が大きいことが分かった場合、その乖離の理由を分析して目標の再設定や指標の変更を行います。
組織開発においても、目標に対する結果の共有が重要となります。
フィードバックの際には、成果が出ている具体例を示すことで、自分の組織が変革していく、仕事が楽しくなる、といった実感を持ってもらうことが出来ます。
これらのことを長期的に行うことが組織開発の成功に結び付きますが、短期的で目先を重視した取り組みになると、構成員はついていけず組織開発自体が失敗してしまいます。
また、組織開発は「一貫した思想」を心掛けなければ「信頼」に結び付かないため、組織開発を進めようとする経営者は覚悟と経営に対する確固たるビジョンを持つ必要があります。
組織改革は短期でその効果が表れることはありません。
現代の環境変化が激しい状況にも耐え、社員の多様化にも着目した組織つくりが必要となります。
これまでの組織風土や個人への意識改革を伴うため長期的に、そして着実に実施していくことが重要です。
経営者は組織に対してどのような組織にしたいのか、常に「一貫した組織への思想」を持って組織開発を実践していきましょう。
少子高齢化が進む日本の人口は、2040年には1億人になると予測されています。
政府は新しい働き方を推進することで、より多くの労働者が働きやすい環境を整備し、「1億総活躍社会の実現」を目指しています。
新しい働き方を実現するためには、環境を整備するだけではなく、個々の能力やスキル、そして適切なマネジメントが求められます。
単に新しい働き方の形をなぞったとしても、自社に合わなかったり、社員のニーズにマッチしなければ成果を実感することはできないでしょう。
ICTの進化により、働き方や働く人の意識が変わった今、大切なのは「選ばれる職場」であり「選ばれる人」であることです。
企業と働く人、双方がよりよい働き方を模索し努力をすることで、新しい働き方が生きてくるといえます。
新しい働き方を導入することで魅力付けを行い、多彩な働き方を奨励する企業が多くなってきました。
しかし、単に施策を取り入れるだけではなく、優秀な人材に「選ばれる職場」になるためには大切なポイントがあります。
女性の社会進出や共働き世帯の増加、シニア世代の再雇用が進んでいます。
労働人口が少なくなっていく中、多彩な人材を起用し積極的に活用していくことは、大企業だけではなく、採用に悩む中小企業にとっても重要なポイントといえます。
また、多様な価値観を認め、尊重しあいながら意見を交換することは、イノベーションにもつながるというメリットもあります。
そのためには、企業が率先して多様な個性を認める教育・研修を行い、全社員に浸透させることが大切です。
そして、取り組みをしっかりと社外にも示すことも重要なポイントといえます。
終身雇用制の崩壊が叫ばれる中で、働く人の考え方も変化してきています。
従来のような年功序列を前提とした教育・研修体制は時代にそぐわないものになりつつあります。
画一的ではなく、多彩なニーズに応えられるような教育・研修体制の構築が必要なのです。
そのためには、次世代リーダーの育成やマネジメント層の研修なども行う必要がありますが、大企業でない限り企業が主体ですべてをゼロから行うとコストがかかってしまいます。
そこで、単に業務上必要なスキルだけではなくマネジメントなど多彩なスキルを学ぶことができるオンライン講座のスクーなどを活用。
ロールモデルとなる人材を複数設定し、組織全体の活性化に役立てるなど、すぐに取り組める施策からスタートするのがおすすめです。
先ほどご紹介したように、「新しい働き方」にはたくさんの施策があります。
しかし、全てを取り入れるのは不可能です。
大切なことは、人材採用のフックとするのではなく、人材が定着するための施策を起用し、社員がきちんと活用することです。
折角施策を取り入れたとしても、十分に活用されないケースは多々あります。
効果測定をきちんと行って、より社員のニーズに沿ったものにしましょう。
例えば、折角在宅勤務を認めたとしても、評価体制が整わず、出勤しないと評価が下がってしまうのでは積極的な利用には繋がらないですよね。
利用率だけではなく利用者の声やフィードバックを参考に、定期的に見直しを行うことが大切です。
既に多くの企業が新しい働き方を導入していますが、大切なことは、新しい働き方を導入することで、働く人と企業双方に良い影響があることです。
そのためにも、制度ありきではなく、チームメンバーと一緒になってより良い方向を模索したらいかがでしょうか。
2018.12.12
RPAテクノロジーズ株式会社（本社・東京都港区、代表取締役社長・大角 暢之、以下RPAテクノロジーズ）は管理部門にフォーカスしたロボットサービス「事務ロボ（β版）」の提供を開始しました。
RPAテクノロジーズは、今までも様々なサービスを提供してきている企業で、代表のサービスに「BizRobo!」などがあります。
その辺りを詳しく知りたい方は、以下の記事をご覧ください。
今回発表された「事務ロボ（β版）」は経理や経営、人事や情報システムなどの管理部門にフォーカスしたサービスとなっています。
経理部門においては、アカウントの登録や請求書の制作、税理の支払いなどの自動化を行うことが出来ます。
RPAは経理との相性が抜群にいいので、この分野で活躍していくことも多いのではないでしょうか。
経理でのRPAの具体例を見たい方はこちらをご覧ください。
さらに、「事務ロボ（β版）」は月額30万円から始められ、簡易トレーニングやセットアップ、インフラなども包含したSaaS型の課金体制となっています。
また、動作不良などで動かなかった場合の保証もあり、その場合は費用を払う必要がないようです。
ここから、2019年夏までに100業務のロボットアプリを順次リリースしていく予定のようです。
2018.12.11
一つの業務をRPA化するには、どのような順番で行う必要があるのか？
普通に考えると、最初に何をRPA化すべきか、つまり「業務選定」を行うだろう。
その後、当然RPAプログラムの開発が不可欠だ。開発終わったら、テストし、実運用を行うだろう。
大まかにいうとほぼすべてのシステム導入もこのように行うが、RPA自身の特徴があり、導入ステップをもっと細分化しないといけない。
図1のようにまず業務選定をし、その後は現在の業務フローを見直さなければならない。
RPAは人間のように作業することはできないので、現行手作業のフローのままでRPAできる業務はかなり少ないだろう。
そのため、RPAが対応可能な業務に変えないといけない。
その後、「開発設計」もとても重要な部分だ。
そもそも「開発設計」は何かから言うと、いかにRPAのプログラムを作っていくかの設計図となるものだ。
基本的に、開発者が見てRPA開発を行う。
その後の開発とテストは一般的な意味の開発とテストになる。
運用マニュアル作成については基本的にはRPA化後の業務はいかに運用するかについてのもので、ユーザーが見ることになる。
これを見て、ユーザー、あるいは業務担当者は普段RPAに合わせて業務を遂行する。
では、タイトルの問題に戻ると、「RPA開発にはどんなドキュメントが必要なのか」という問題は「どの段階にドキュメントが必要なのか」ということになる。
ここでの「ドキュメント」というのはRPA化する際に各プロセスを分析、記録、管理するために作るものだが、どの段階に必要かというと、答えはシンプル：「すべて」だ。
一見当たり前なことに見えるが、実際運用時ドキュメント管理の問題でRPA導入プロジェクトがトラブルや非効率的の原因となった事例もある。
今回は特に省略される傾向のあるステップの例を挙げて見てみよう。
業務選定段階では、まず業務フローを一通りヒアリングし、その他と評価した上で、各業務の中からROIの高い業務を選定するのが基本だ。
一般的に、業務の複雑さ、RPAとの相性、削減可能な時間、開発難易度などの指標から一つの業務をヒアリングする。
ある大手会社A社が候補となる業務が非常に多いため、早く業務の初期ヒアリングを行った上で、RPAにあまり向いてない業務を排除しようとした。
もちろんこれは一般的な考え方だが、A社の問題は時間節約のために評価の書類を全部残していなかった。
A社のやり方は、まず各部署から書面のRPA化リクエストが上がってくる。
リクエストの中では基本「何についての業務」、「月何時間かかっている」など簡単なものしか記載しない。
その後、RPA導入のヒアリング担当が約30分から1時間程度の業務フローの初期ヒアリングを行う。
ヒアリングの間に「人間の判断がたくさんある」、「VPNが使われている」、「RPA非対応のブラウザが必要」などの情報があれば、とにかくこれを理由として後回しとした。
そして、目標業務に時間を集中したため、記録のドキュメントをまとめて管理しなかった。
しかし時間を立つと、新しくヒアリングした業務より、以前後回ししたXX業務のほうがROIがよいと気づいた。
この時、当時ヒアリングしたメモや評価のドキュメントが集中管理していないため、整理するには時間がかかったし、災厄の場合、もう一度ヒアリングすることもあった。
あまりにも効率に重視し、逆に非効率が起きていた。
ロボットは人間のような能力がないため、RPA化するには、業務フォローを必ずロボットのロジックに合わせないといけない。
これはすでによく知られている事実なので、やらないでいきなり開発に入ることはないだろう。
そして、「業務フローの見直し」を重視するあまり、「開発設計」を軽視してしまう場合がある。
「業務フローさえ直せばそのままロボットが作れる」という発想はA社がRPA導入プロジェクトの早期に存在していた。
実際A社が使っているRPAソフトに「開発設計書」のフォーマットが存在していたが、あらゆる事情でとにかくいくつかの業務を早くオンラインさせたく、なおかつ開発設計書が書ける従業員が社内にいなかったため、とりあえず派遣のRPAエンジニアと一緒にヒアリングをしながら開発を進めていた。
「開発設計書」の作成は時間がかかるので、この進め方は一見開発期間を短縮されているように見えるが、実際はその逆だ。
開発設計書がないため、エンジニアは業務のフローを全部理解しないといけない。
A社の場合はヒアリングと同行させた。もちろん、業務が少なく、あるいはエンジニアが十分の人数がいればこれも不可能ではない。
しかし、A社の場合は開発エンジニアのリソースも少なく、待の業務が多いという状況だった。
仮に見てすぐ開発できる「設計書」があれば開発に時間を短縮することは可能になるのと、エンジニアはヒアリングに行かなくて済む。
A社もこの問題に気づいた、設計書を作成するリソースを調達して、開発設計のドキュメントを作成するようになった。
また、開発設計書の作成は後日のメンテナンスにとっても大きいメリットがある。
開発設計書が正しく管理されていれば、ロボットの開発に関する詳細や仕様変更履歴まですべて記載されているはずだ。
メンテナンスが必要となる際に、開発した本人ではなくても、どのエンジニアが見ても早く分かるようになるので、非常に効率よい。
ロボットが開発完了し、オンラインになったら、開発チームがほっとする気分になるが、ユーザーにとってはそうではない。
知れているように、RPA化する際に、基本業務フローの見直しが発生する。
そのため、今までの作業と比べて、従業員が毎日しないといけない業務も変わる。
例えば、どのようなデータを何時までどこに格納するか、このようなエラーが起きる場合はどのように対応すべきか、RPAが止まった場合どうなるか、なども問題が出てくるだろう。
通常、このような問題業務フロー見直しの段階で既にある程度決めていたはずだが、運用向けのマニュアルがないと、ユーザー側でトラブルが発生する場合がある
A社の運用に関するマニュアルはドキュメント化されているわけではなく、各案件によってやり方が異なる。
Excelベースのマニュアルを作った開発担当者もいれば、メール程度でユーザーとやり取りしている開発担当者もいる。さらに、そこに含まれている内容も異なる。
A社はこの現象に気づいて、各担当者は普段どのようにユーザーに運用手順などを説明しているのかを調査した。
そして、統一した運用マニュアルフォーマットが作成できた。
内容としては、RPA化後業務のフロー、こと業務に関連するすべての部署および従業員の役割、業務手順の詳細、RPAエラー一覧および対処マニュアル、リカバリーマニュアルなどが含まれていた。
そして、運用マニュアルの新フォーマットが普及後、ユーザーから好評された。
今までRPAに関する不安などが解消され、より効率よくロボットを利用できた。
今回は失敗事例が多いが、反面教師として、RPA化する際にドキュメント作成と管理の重要性を説明した。
特に大企業の場合、部署間のコミュニケーションがすぐできない場合があるかもしれないので、ドキュメントは運用の信頼性を高めるための良い手段だ。
一部のRPAソフトはオフィシャルで推奨するドキュメントフォーマットもある。
少々面倒くさいものや「意味のない」ものもあるかもしれないが、本文にあった失敗事例にならないように、大事にドキュメント管理したほうがよいだろう。
2018.12.10
参考記事；ゆうちょ銀行、投資信託の口座開設業務をRPAで自動化 作業時間を3分の1に――富士通の業務自動化システムを導入
（富士通ホームページより引用）
富士通株式会社 （ 本社：神奈川県川崎市、代表取締役社長 ：田中 達也、以下富士通）は株式会社ゆうちょ銀行（本社：東京都千代田区、社長：池田 憲人、以下ゆうちょ銀行）に自社のOCR技術を提供することを発表した。
ゆうちょ銀行では、これまで投資信託の口座開設業務を銀行の行員自らが行っていた。
日々の業務は数百名分に上り、ゆうちょ銀行の行員がすでに開設された普通口座やそこから把握できる顧客の個人情報を再確認したのち、投資信託システムに手入力していた。
ゆうちょ銀行は、富士通の提供するOCRとRPAを用いたシステムを利用することで、従来手作業で行ってきたこの手作業業務を自動化する試みである。
早くも自動化の結果は出ているようだ。
ゆうちょ銀行はこのシステムを９月に導入し、運用を開始してから業務時間を３分の１に短縮できることが確認されている。
富士通が提供するシステムの詳細については、富士通ホームページより引用する。
１．申込書の高精度な読み取りを実現（OCR）
富士通グループの株式会社PFUのOCRソフトウェア「DynaEye（ダイナアイ）」を活用し、申込書をスキャナーで読み取るだけで、印字や行員が手書きした書類を高精度に認識します。文字のつぶれや未記入部分などに対してのみエラーをあげるため、ゆうちょ銀行様の行員は該当部分のみ目視して確認するだけでよく、作業効率化が図れます。
２．顧客情報のデータ登録から完了通知までを自動化（RPA）
Kofax Japan株式会社のRPAパッケージ「Kapow（カパウ）」を活用し、OCRで読み取った情報と、普通口座の顧客情報を登録処理し、内容にミスがないかを突き合わせて確認します。確認後、投資信託システムへの入力や、完了通知を行うところまでを一貫してRPAで実施し、正確性の向上や大幅な時間短縮を実現します。
申込書の読み取りには、PFUのOCRソフトウェアである「DynaEye」を使用。
スキャンすることで印字されてある文字や手書きの文字を高精度に認識する。
これにより、ゆうちょ銀行の行員はエラーの確認だけをすればよく、効率が向上した。
RPAパッケージには、Kofax Japanの「Kapow」を使用。
OCRからの流れや顧客情報の入力などの自動化を行っている。
地銀もどんどんRPA化を行っている中で、今後もRPAと銀行の関係は目が離せないようになっていくだろう。
銀行とRPAの親和性などについては以下の記事で詳しく紹介しているのでぜひ読んでほしい。
2018.12.07
弊社がパートナー契約を結んでいるUiPath社のRPAツールには、「Community Edition」という無料でRPAのプログラム作成を行うことができるツールがあります。
簡単にダウンロードできますので、初期投資を気にせずにRPAの体験を簡単に行うことができます。
その為か、プログラミングの経験が少ない人やExcelでマクロ機能を使ってプログラムを組んだことがある人といった、所謂ノンプログラマー、ライトプログラマーの人達が業務を円滑に進めるために使用されることが増えてきたと感じています。
ですが、実際にUiPath Studioを起動してプログラムを組もうとすると、意外と難しいと感じるかと思います。
特に、今までプログラミングの経験をしていない人には、使いこなすまでにはかなりの勉強が必要です。
UiPathには「UiPath Academy」というeラーニング教材もございますが、こちらをこなすことで一通りの知識は手に入ります。
ただ、使いこなすとなるとStudioで実際にプログラムを組んでみて、失敗を繰り返して少しずつ上達していくしかありません。
プログラムを組んでいく中で、特に初心者が陥りがちな問題が、プログラムを組んで動かしてみたけど、途中でエラーが出て止まってしまうことです。
よくわからない単語が並んでいること、若干危険そうな感じがしてしまうことから、あまり動かさずに開発をやめてしまいたくなります。
原因を探ろうとしても、そもそも何が原因でエラーとなっているのかわからないため、諦めてしまう人もいるでしょう。動くところまでいかずに挫折してしまう方もいるかと思います。
しかし、そこで諦めてしまっては非常にもったいないのです。
シンプルに動くようにするためには、シンプルなエラー処理のアクティビティを追加することで、簡単に動くようになります。
また、より深くエラーの原因を探りたい、またはエラーの内容によって分岐させたい場合には各エラーの内容とその対策を理解することで、より強固なプログラムを作成することができるでしょう。
エラー処理の対処をする際に最も使用するアクティビティが、「Try-Catchアクティビティ」です。
これは、まずTry内の処理を実行して、もし処理途中でエラーが発生したらCatch内の処理を行う、というものです。
また、Try内でエラーになる、ならないに関わらず、Finally内の処理を最後に必ず行います。
エラー内容での分岐は考慮せず、且つとりあえずエラー処理の制御を行いたい場合は、Try内に作成したプログラムを入れ、Catch内のExceptionを「System.Exception」にすれば、エラーが発生しても途中で停止することなくプログラムが走ります。
ですが、エラーの内容がわからないため、エラー内容で分岐させる処理を行いたい場合は、各エラー内容に応じた処理を行う必要があります。
エラーの中でも、特にメジャーな内容について、以下に列挙します。
参照先が見つからない、あるいは参照先が対象範囲外の場合に、このエラーが発生します。
特に、Excel等でセル範囲から値を取得するときに空欄のセル（Null）を取ってしまい、その変数を使って他の操作をしようとしてしまい、結果エラーとなってしまいます。
このエラーは、参照先の設定を適切に設定することで回避することができます。
Argumentとは、引数のことです。指定した引数が無効な場合にこのエラーとなります。
指定した引数が無効の場合、このエラーが返されます。
Invoke Workflowを使って別のxamlファイルを参照しているときに発生することが多いようです。
IOとは、In/Outのことであり、入力/出力の際にエラーとなった場合にエラーとなります。
ファイルやディレクトリへの読み取り/書き込みを行う場合に、参照先は正しいが抜き出すときに読み取り/書き込みができない場合に発生します。
このエラーが発生した場合は、参照しているファイルやディレクトリが何らかの理由で読み取り/書き込みができていないため、ファイルやディレクトリの参照値あるいはそれらの内容を再度確認することで、エラーの原因を突き止めることができると思います。
セレクターエラーで最も発生する可能性の高いエラーです。
その名の通りセレクターで選択したエレメントが見つからなかった場合にこのエラーとなります。
レコーディング・アクティビティ等で選択したセレクターが取れない場合、特にレコーディングでwebの情報を取得するプログラムを組んだ時に多く発生します。
原因は、webページの読み込みに時間がかかってしまい、セレクターの要素が出現する前にプログラムが走ってしまうため、要素が見つからずエラーとなることがほとんどです。
RPA特有のエラーである、NotFoundElementExceptionについての改善点をまとめました。
Webページから特定の要素を取得するためには、セレクターを使いこなす必要があります。
セレクターのタグ要素がうまく取得できているのにも関わらず、要素が見つからないエラーとなってしまう場合には、以下の方法で問題なく動作するようになる可能性があります。
Delayアクティビティは、指定した時間が経過するまで待機するアクティビティです。
ページの読み込みに３秒程度かかるが終了するまでの時間を指定することで、webページの読み込み時間より長く待機させることで、要素を安全に取得することが可能です。
セレクターを取得するアクティビティのプロパティにDelay AfterとDelay Beforeがあります。
これらを使用することで、Delay アクティビティと同様に指定の時間待機することが可能となります。
Delay Afterがアクティビティ実行後、Delay Beforeがアクティビティの実行前となります。
使用時の注意として、ミリ秒で表記する必要があります。（３秒の場合は3000と表記する）
上記のDelayアクティビティの場合、いずれも、「次のアクティビティ実行まで待機する」ため、必ずしも要素が取得できない可能性があります。
また、想定よりも早く要素が出現したとしても、指定した時間になるまで待機してしまうため、次のアクティビティの実行まで無駄な時間が発生してしまうことがあります。
これらを解決したい場合に、このOn Element Appearを使用することで解決できます。
このアクティビティは、「要素が出現してからその動作を実行する」アクティビティです。
このアクティビティを使用すれば、要素が出現した時点で指定の動作を実行してくれますので、読み込みに時間がかかっても要素が取得でき、且つ無駄な待機時間も削減することができます。
Retry Scopeアクティビティは、Conditionに指定されたアクティビティ状態になるまでプログラムを繰り返す処理を行います。
ConditionにElement Existアクティビティを指定することで、選択したい要素が出現するまで同じ動作を繰り返し実行してくれます。
厳密にいえば、Try-Catch文でセレクターの取得ができるようになるわけではありません。
ただ、もしセレクターの要素が取得できなかった場合に、プログラムをエラーで終了させたくない場合は、このアクティビティを使用することで解決できます。
この場合、注意してほしいのは、要素が取得できなかった場合に、要素が取得できないまま先に進んでしまうことです。
もし、セレクターで取得した要素を使って以降のプログラムを走らせた場合、必ず要素が取得できなかった場合の代替案で重大なトラブルにならないように注意して設定することが求められます。
2018.12.06
RPAの導入事例が増えるにつれ、RPAに関するリスクについて懸念の声が目立つようになってきたように感じます。
今回のコラムでは、RPAのリスク管理支援サービスについて紹介したいと思います。
RPAリスク管理サービスとは、コンサルティング会社等が開発したリスク管理フレームワークを使って、RPA導入における各種リスクに対して管理を行うサービスのことを言います。
RPAのリスク管理へのニーズの高まりの背景の1つには、導入時に、RPAによる業務自動化のメリットのみが注目され、導入後に起こり得る課題やリスクの管理の重要性が認識されていなかったことが挙げられます。
RPAの運用におけるリスクには、以下の
「①法令等への違反」「②不正アクセス・情報漏洩」「③業務の停止」「④不十分な管理・非効率な管理」
の４種類のリスクのほか、さまざまなものが考えられます。
内部統制報告制度・米国SOX法404条の対象企業では、RPA導入に合わせて、報告対象業務における内部統制を、マニュアル統制からIT統制に置き換える必要があります。
個人情報を取り扱う業務へのRPA導入の場合も、セキュリティ管理対策の再構築が必要です。
こうした取り組みを怠ると、関連法令・規則等への違反につながる恐れがあります。
個人情報など機密性の高い情報を処理する業務では、RPA導入による情報の形態、記録媒体、処理方法の変化に合わせて、セキュリティ管理対策の見直しが必要です。
見直しが遅れると、セキュリティ管理水準の低下を招き、不正アクセスや情報漏洩の発生等につながる可能性があります。
停止が許されない業務や許容停止時間が短い業務でRPAを使用する場合、RPA停止時の対応について、しっかりとしたプランを用意しておく必要があります。
万が一のRPAの停止に対して適切な対応ができていないと、後続業務の遅延・停止などを含め、社内や取引先に大きな影響を与える恐れがあります。
RPAを大規模に導入する場合、全社共通の方針、ルールの下で管理を行うことが必要です。
部門ごとに分散して導入が進められた場合、無駄や重複の発生による管理コストの増大、内部統制・情報セキュリティ対策水準の低下などの問題につながる可能性があります。
さらに、組織が運用する既存のリスク管理の取組みをどのようにRPAに適用させるのかといった問題に加え、内部統制報告制度に対応していくための有効な内部統制の見直しや再整備も、重要な課題として浮上しています。
（KPMGコンサルティングWebサイトより引用：
https://home.kpmg.com/jp/ja/home/media/press-releases/2018/04/rpa-risk-governance.html ）
＜参考＞
株式会社イーセクター：RPA の盲点 IT ガバナンスの重要性
https://www.esector.co.jp/special/rpa/rpa6.html
KPMGコンサルティング：RPA導入に伴う内部統制の整備ポイント～想定されるリスクにどう対応するか？～
https://home.kpmg.com/jp/ja/home/insights/2018/04/rpa-internal-controls.html
Accenture：RPAとRPAガバナンス ～本格導入に向けてのガバナンス整備の必要性
PwCコンサルティング：RPAのガバナンスとセキュリティ
https://www.pwc.com/jp/ja/japan-knowledge/archive/assets/pdf/rpa-governance-security1608.pdf
EYアドバイザリー・アンド・コンサルティング：RPAを監査する RPAのリスクを低減する内部監査
https://www.eyjapan.jp/services/advisory/risk-transformation/pdf/RT-03_rpa-audit.pdf
ここでは、現在リスク管理サービスを提供している事例について３つ紹介します。
[サービス名]
RPA導入におけるガバナンス／リスク管理態勢 評価・整備支援サービス
[サービス開始時期]
2017年12月18日
[サービス内容]
同社は、RPAの導入、利用に当たって必要な、リスク管理やガバナンス面での対応事項を洗い出すフレームワークを開発。
同フレームワークは、個々のロボットの重要度とリスク評価、ロボットに対するIT全般統制などのセキュリティ確保、内部統制監査対応などの「守り」の部分と、RPAの導入、目標、戦略達成や人材育成などの「攻め」の部分を含んでいるという。
同社は、同フレームワークを活用し、RPAの組織への浸透や定着化、各プロセスのモニタリング、評価など、ガバナンスの維持、改善のための仕組み作りを支援するとしている。
[サービスプロセス]
１．概要調査：評価実施にあたっての概要把握を実施
・RPA導入によって解決すべき経営課題、導入の目的・目標の確認、RPA導入状況の概要把握
・評価アプローチの検討
２．評価：フレームワークを活用した評価実施
・フレームワークを活用したRPA導入に係るガバナンス/リスク管理態勢の評価
・RPAニオケルIT全般統制整備状況の評価
３．構築計画支援：ガバナンス/リスク管理態勢構築に向けた計画策定
・評価結果より課題の整理・対応方針策定
・ガバナンス/リスク管理態勢構築・展開に向けたロードマップの策定、体制の策定
・SOX対応に係る計画策定
・報告書作成/報告実施
４．構築実施：RPA導入に伴うガバナンス/リスク管理態勢構築
・RPA推進組織（全社組織）の立ち上げ
・RPAの棚卸・リスク評価、重要なRPAの特定
・RPA導入に係る方針
[URL]
[サービス名]
RPAリスク管理支援サービス
[サービス開始時期]
2017年4月24日
[サービス内容]
KPMGコンサルティングは、RPAの導入対象、範囲、管理要件、ライフサイクル、既存の内部統制やシステムリスク管理の状況、および個別のニーズに応じてRPAに対する柔軟で効果的なリスク管理とガバナンスの構築・運用を支援しています。
①財務報告に関連する重要な業務へのRPAの導入を計画・実施している
⇒効果的で有効性の高い、RPAにかかわる内部統制の整備と運用、継続的な維持・改善・評価を支援
②個人情報、重要情報の取り扱い業務へのRPAの導入を計画、実施している。
⇒既存のセキュリティ管理の枠組みを活かした、RPAに関わる効果的な情報セキュリティ対策の導入と運用を支援します。
③ 中断・停止による影響が大きい業務へのRPA導入を計画、実施している
⇒業務の重要性や許容停止時間などを踏まえて、RPA導入対象における効果的で実行可能な業務継続計画の立案、訓練を支援します。
④ RPAの大規模な導入を計画、実施している
⇒既存の枠組みと整合した、RPAの導入・展開・運用にかかわる全社的なリスク管理の方針・ルールの設計と運用を支援します。
[リスク管理フレームワーク]
KPMGコンサルティングは、RPAのライフサイクル全体をカバーするフレームワークに基づいて、RPAに関わる「戦略リスク」「導入展開リスク」「運用リスク」の各要素に対して、「RPAの戦略」「RPAの導入」「RPAの運用」「RPAのリスク管理とガバナンス」の観点から対応します。
[URL]
[サービス名]
RPA導入におけるガバナンス構築支援コンサルティング
[サービス開始時期]
2018年（月は不明）
[サービス内容]
日立コンサルティングでは、RPA導入で必要となるガバナンス構築時の対応事項をフレームワークとして定義し、それをベースにRPAの導入、開発・保守、運用を円滑かつ安全に使うための規定類をテンプレート化しています。
これらのフレームワークとテンプレートを用いることで、短期間でお客さまのガバナンス構築を支援します。
[サービスプロセス]
日立コンサルティングのフレームワークとテンプレートを用いて、お客様へのヒアリングと打ち合わせを行いながら、RPAガイドラインと規定類（テンプレート）の整備を支援します。
１．現状確認：RPAの検討状況と現状のガバナンスのないようを確認する。
２．RPAガイドライン（全体方針）の初版のまとめ：RPA導入におけるガバナンス方針と対応項目を検討し、RPAガイドライン（全体方針）の初版をまとめる。
３．規定への改定内容検討：規定類への改訂内容を検討し、改定（ドラフト）を作成する。
４．規定への改定内容レビュー：改定（ドラフト版）を確認する。
５．既定の整備：改定した規定類を展開する。
[URL]
http://www.hitachiconsulting.co.jp/solution/digital/rpa_governance/index.html
2018.12.05
近年、業務の自動化を実現するツールとしてRPA（Robotic Process Automation)が注目を集めています。
では、実際に導入を検討しようと検討しているが、どの業務へ導入すれば良いのかわからない、または、導入したが思ったような結果が出なかったというケースが多々見受けられます。
本記事では、今後のRPA導入の手助けになるような「最初に選ぶべき業務を5つ」紹介することで、これらの課題の解消に一助出来ればと考えています。
RPAはAIやビックデータと並ぶ、最先端の技術であるという認識が世間ではあるように思います。
RPAを使えば、とんでもなく凄いことが出来るという勘違いが要因の1つにあるようです。
しかし、RPAはそれ自体がまったく新しい付加価値をわたしたちに提供してくれるものではありません。
あくまでも、個々の業務単位で自動化を手助けしてくれるツールに過ぎないのです。
その意味では、RPA自体はたいしたことないと言っても過言ではないと考えています。
もちろん、基幹システムなど他のシステム、そしてAIなどとの組み合わせにより、大きな革新が生まれる可能性はありますが、これは将来的な話しです。
現時点では、将来的な全体業務最適化の1部分を担当するツールとしてRPAを捉えるべきです。
前述にて、RPAは「将来的な全体業務最適化の1部分を担当するツール」としましたが、RPA導入当初においては、これをしっかりと見据えることは非常に困難だと言えます。
RPA自体、大手企業を中心に導入実例が出始めたばかりであり、まだまだノウハウを積み重ねている発展途上です。このノウハウが結集した結果、当初導入したRPAはレガシー、つまり過去の遺産になってしまう可能性があります。
これを回避するためには、RPAの導入は「小さく始めること」、後々の全体業務最適化を手探りで進めることが重要です。
幸いなことに、RPAはこれらの要件を兼ね備えたツールです。比較的安い費用でしかも簡単に扱うことが出来るものです。
それでは、初めてRPAを導入するにあたり、最初に選ぶべき業務を紹介致します。
最初の1歩となることに適した業務であり、ここからRPAを発展させていくことになります。
また、RPA導入の結果、人の削減や配置転換など企業内部の仕組みを変える結果となることがあります。
つまり、一定の社内抵抗勢力が存在してしまう結果となる場合があります。
その為、削減効果をしっかりと出す業務を選ぶことで社内でのPRAの認知度を高めることが重要です。
・単純作業だが作業量及び作業時間の絶対量が多い業務
＜例＞
〇 売掛などの入金額照合作業
概要：銀行入金情報とExcel上で管理している入金管理表を自動化。
・時間効率の悪い業務
＜例＞
〇 営業日報の印刷作業
概要：Excelやシステム画面などに表示される営業日報の印刷を自動化。深夜など人がいない時間帯
に行うことで、印刷機を占領する必要もなくなる。
・業務時間外に発生する業務
＜例＞
〇 システムエラー発生時のログ収集
概要：システムエラーが発生した時、その対象となるログを自動的に収集して担当者へメール。
・同じ作業が続く業務
＜例＞
〇 メールでの問い合わせ内容をシステム登録
概要：メールで問い合わせがあった記録を対象システムへ自動的に転載し登録を行う。
・RPAに強い関心を持った担当者の業務
＜例＞
〇 なし
概要：RPAは万能ツールでは無いため、トライ＆エラーで導入を進めるものである。
その為、RPAに理解や関心がある担当者と取り組むことで最初のRPA導入が容易になる。
RPAは人間が行っていた業務をそのまま置き換えることが出来るツールです。
しかし、予め命令（設定）された動きしか行うことが出来ません。
つまり、イレギュラーが発生する可能性が高い、業務に判断を必要とするケースが多くある場合は、RPA導入のハードルになります。
それらの情報を全て洗い出して、RPAに命令（設定）をする必要がある為です。
漏れの無い業務の洗い出しは大きな負担となる上、漏れは必ずと言ってよいほど発生します。
それを人間がしっかりと監視してRPAが正しい業務を行っているか確認をする必要があります。
とりわけ、導入当初は、RPAの業務結果も含めた全般的なチェックが必要となります。
RPAの流行とともに、RPA導入を支援する会社が多数生まれました。
大手ベンダから中小企業まで様々なRPA導入コンサル事業を行っている企業があります。
日本を代表する大手ベンダのRPAコンサルタントに御社の強みは何かと聞いたところ、「現時点ではどのRPAコンサルティング会社も似たようなソリューションしか提供出来ていない。正直なところ、自社での導入が一番の実績。」と言っていた記憶があります。
これは2017年末頃のことで、2018年は既に状況も変わっているかもしれませんが、RPA導入コンサルタントに過度な期待を寄せることは難しいかもしれません。
しかし、実際問題、RPAを導入して全体業務最適化を図っていきたいといった場合は別です。
一業務を自動化させたいというくらいの要件であればRPAコンサルタントは必要ないかもしれませんが、「他のツールやシステムとの連携を考えたい」「複雑な業務に適用を将来的に考えたい為、RPAを作り込みたい」といった場合は、RPA導入コンサルタントは有効だと言えます。
とりわけ、業務の洗い出しは自社のみで無く、外部からの客観的な視点が重要と言われている為です。
つまり、ゴールをどこに設定するのかという大方針によって、RPA導入コンサルタントの必要性の有無が分かれると考えています。
もちろん、そのゴールをどこに設定するのかをRPA導入コンサルタントを活用することで探っていくことも良いと思います。
RPAを言い換えると、言われたことはしっかりと行うが、珍しいケースや判断を必要とするケースに対応できない真面目な新卒の新入社員のようなものだと言えます。
しかし、この新入社員は24時間365日働くことが可能で、なお且つ反抗をすることはありません。
この新入社員を今後育てる上で、最初にやらせる業務は何かと考える視点を持つと面白いと思います。
初めてのRPA導入における選ぶべき業務を中心に書きましたが、既に多くの発展的な導入事例が大企業を中心に存在します。
それらの事例を研究しながら自社の要件に合ったRPAを考えていくべきではないでしょうか。
つまり、自社のゴールをどこに設定するのかを事前にしっかりとした検討が最重要となります。
2018.12.03
日々の業務にすぐに取り入れることができる、業務改善や目標達成のためのフレームワークを紹介します。
問題の多面的把握、思考整理
6W2Hは6つのWと2つのHの計8つ疑問詞を用いて、物事やテーマ、問題、課題などを多面的な切り口から考察するためのフレームワークです。
テーマに対してさまざまな角度から問いを投げかけることで、思考が広がり、それまで気付いていなかった視点を得ることができます。
思考を広げた先にあいまいな情報がある場合は、その情報についても考えるきっかけになります。
Who（だれが）：人物や組織、役割、グループなど、主語を明らかにする。
What（なにを）：問題や事象、商品やサービスなど、考察する対象について事実や構造を明らかにする。
Whom（だれに）：ターゲットや関係人物など、対象者を明らかにする。
When（いつ）：実行日や納期など、時間軸（期間やタイミング）を検討する。
Where（どこで）：場所や位置、地理情報やエリアなどを検討する。
Why（なぜ）：目的や原因、意義や前提条件、狙い、意図を明らかにする。
How（どのように）：手段やプロセス、方法、手順、構造などを明らかにする。
Hom much（いくらで）：時間やお金、人材など資源を検討する。
①テーマ（問題）を決める
②情報を広げる
テーマに対して、8つの疑問詞のそれぞれに回答しながら思考を広げていきます。
情報の整理、全体像の把握
物事を分解して考えていくことで、全体と部分を網羅的に整理するフレームワークです。
何か問題が起こっている場合、そこには必ず原因が存在します。
その問題、あるいは解決策を「因果関係」という切り口で発想を広げていくことにより、より的確で網羅性のある原因リスト、あるいは解決策リストが出来上がります。
その出来上がったリストに優先順位をつけて、実行するものを決めていくことで、限られた時間と資源を有効に配分することができます。
①問題を設定する
ロジックツリーの頂点となる問題を設定します。
②主な原因を書き出す
設定した問題に対して「なぜ？」を問いかけ、主な原因と考えられる要素を書き出します。大きな分類を把握することがポイントです。
③原因を細分化する
上記②で書き出した原因に対して、さらに「なぜ？」を問いかけ、各原因を細分化して掘り下げていきます。
視点や論点に偏りがなく、網羅的に情報を書き出せているかがポイントです。
④ツリーを整理する
情報を出し切ったら、各要素のつながりが理論的であるかどうか、上位概念・下位概念の関係に間違いがないかなどチェックします。
9つの問いを用いて新たな視点を得る、課題解決のためのアイデアを練る
アイデアが浮かばない際に発想する切り口として利用する為のリストです。
9つの問いで新たな視点を得るフレームワークです。テーマに対して新たな問いの視点うぃ得ることができているか、テーマに対する理解が深まっているか、アイデアを発展させる方向性を複数見出すことができているかがポイントになります。
転用：転用できないか、他の方法で使えないか、新しい使い道はないか
応用：応用できないか、似たようなアイデアはないか、他のアイデアを応用できないか
変更：変更できないか、色・形・デザイン・仕様・利用目的・意味付けを変えてみたら
拡大：拡大できないか、大きく・高く・長くしたら、付加価値や頻度、割合を高めたら
縮小：縮小できないか、小さく薄く、短くしてみたら、機能や情報を減らしたら
代用：代用できないか、素材や人、物、場所、方法を代用できないか
置換：置換できないか、要素や順序、配置、パーツ、プロセスなどを置き換えたら
逆転：逆転できないか、上下や左右、前後、内と外、順序、考え方を逆にしたら
結合：結合できないか、セットにしたり、新旧や真逆の要素を組み合わせると
①テーマを設定する
②9つの問いでアイデアを広げる
（５）フレームワーク図
目標管理、戦略立案、組織開発
「Objective and Key Result（目標と主な結果）」の略で、企業のチームメンバーそれぞれの目標と期待されている結果を明確にし、組織のオペレーションとコミュニケーションを効率化するためのシステムです。
OKRを組織に導入するメリットはいくつかありますが、一番大きなメリットはゴール（目標）を明確にすることによって何にフォーカスするべきなのか、何を無視しても良いのかをクリアにできることです。
そして、OKRは会社全体に公表されるのでコミュニケーションの効率化にも繋げることができます。
OKRの定量的な効果測定である目標達成度指標（Key Results）と類似している業績管理手法として、KPI(Key Performance Indicator：重要業績評価指標）が挙げられます。
KPIは「最終目標を達成するための必要なプロセスを経過目標」と定義され、それらが適切に実行されているかどうかを順次チェックしていくことで、最終目標を達成していきます。
KPIはプロセスチェック、OKRはコミュニケーションの促進が目的となっており、性質が異なります。
①Objective（目標）を決める
Oは次の条件を満たす一つの文とする
例）イベントを成功させる
②Key Result（主な結果）を決める
KRではOの感覚的な言葉を定量化します。難しいが不可能ではない範囲で1から最大4つのKRを設定します。
例）イベントページUU10,000人 イベント来場者数3,000人
③OKRの評価
仮に四半期で期間を設定した場合、四半期が終わったら、個人で設定したOKRの達成率を個別に振り返ります。全社メンバーを集めて、チームや部署そして会社全体の達成率を評価します。
業務を振り返り、今後のアクションを考える。
KPT（ケプト、ケーピーティー）とは、「Keep（継続すること）」「Problem（改善すること）」「Try（新たに挑戦すること）」の3つの要素から、現状の業務状況を振り返るフレームワークです。
よかったところと悪かったところを整理して今後のアクションを考えます。
業務中に個々人が感じている課題や気づきを、チームとしての課題や気づきに変えることが目標です。
週ごと月ごとなど、定期的に実施することが理想です。改善が必要な要素をはっきり書き出せているか、Tryがアクションとして書き出せているかなどがポイントとなります。
①前回のTryを確認する
②継続することを書き出す
前回設定したTryの内容と、現在の業務状況を踏まえて、継続する要素（Keep）を書き出します。よかった点や成功したことが該当します。
③改善点を書き出す
改善点（Problem）を書き出します。
④新たに挑戦することを書き出す
KeepとProblemを踏まえて、今後新たに挑戦すること（Try）を考えます。
2018.11.30
参考記事：https://news.mynavi.jp/article/20180928-698714/
近年、日本国内労働力の不足へ対応や生産効率を向上するために、RPAを導入する企業が急増しています。
民間企業はもちろん、地方自治体での導入も多く聞かれています。
それらの事例は、すでに記事で多く紹介せていただいておりますので、ご参考にしてください。
さらに、近日、東京都葛飾区も源泉徴収精算処理業務に対するRPA導入に本格的に展開しました。
9月27日、みずほ情報総研は東京都葛飾区源泉徴収精算処理業務に対するRPA導入支援業務を受注したことを発表しました。
“同区のテスト環境下で源泉徴収精算処理業務のRPAロボット構築から効果検証までを実施した結果、RPAによる自動化で、年間444人日の作業工数の削減効果が見込まれ、職員の労働時間削減による生産性の向上、事務ミス削減による事務品質の向上、既存システム改修のコスト削減などの効果が得られたことから、本番環境での受注に至ったという。
”
実際に、昨年同じテスト環境において、葛飾区は、すでにRPAによる自動化で、大きな実証効果が得られたそうです。
これから、葛飾区はみずほ情報総研と協力し、今まで得られた実験結果に基づいてさらなる効果の高い実施法へ進んでいきます。
2018.11.29
参考記事：大津市、市役所業務などでRPA・AI活用–富士通と有効性を共同検証
地方自治体のRPA導入が進んでいます。
下記記事では、茨城県つくば市や、京都府の事例をご紹介しています。
そんな中、滋賀県大津市も、RPA導入へ向けてPoC（概念実証）に動き出したことが紹介されています。
滋賀県大津市と富士通は11月8日、「政策検討・立案へのデータ利活用」「保育所入所選考へのAI活用」「市役所業務へのRPA適用」の3分野で連携協定を締結したと発表した。2018年11月から2019年3月まで、有効性を共同で検証する。
大津市は、上記の3分野について、富士通と契約を締結し、RPAでは特に市役所業務への適用を検証するようです。
市役所業務へのRPA（Robotic Process Automation）適用では、大津市が業務を洗い出し、その業務の中から富士通がRPA適用する業務を選定。RPAツールによるシナリオとロボットを作成し、両者で効果を検証する。具体的には、内部事務システムに臨時・嘱託職員の勤務記録データを入力する業務での業務改善効果の検証を行うほか、国民健康保険料に関する所得申告書のデータから公的年金収入および給与収入の金額を基幹システムにデータ入力する業務での効果などを検証する。
業務洗い出し部分については、コンサルタントが担うこともありますが、
本件では大津市自身が行ったようです。
その業務洗い出し結果をもとに、富士通が業務選定のコンサルティングを行ったようです。
具体的なPoC業務としては、臨時職員や嘱託職員の勤怠管理システムへの入力業務や、基幹システムへの保険料収支の入力業務となっているようです。
どちらも、OCRなどの高度なRPA施策ではなく、
データ入力業務において検証していることから、PoCとして、一旦大津市役所内でRPAが馴染むかどうかを検証していることが窺えます。
自治体のRPA施策の進捗状況としては、PoCフェーズが今後とも増えていくものと考えられます。
2018.11.28
千葉県内の地方銀行、京葉銀行は今年度10月から主に住宅ローンの審査業務でRPAを導入しています。
RPAとはロボティック・プロセス・オートメーションの略で、人間に変わりロボットが単純作業を行うことで効率化を図ろうというものです。
今回京葉銀行で導入された住宅ローンの審査業務ですが、従来であれば仮審査に必要な顧客の勤務先や収入などの個人情報を銀行の行員が手作業で入力していました。
具体的には、一件当たり約40~60分の作業時間が必要であると日本経済新聞は報じています。
この業務をRPA化することで、結果的には一件当たりの作業時間は半減しました。
さらに、今までこの作業に当たっていた行員を営業やコンサルなどに配置しなおすことにより、それらの業務の強化を図るようです。
コンサルタント業務の強化に当たり、コンサルタントや営業の行員を2021年3月までには200人増やす見込みです。
将来的には、住宅ローンにおける審査だけではなく、ファックスなどによる申し込みなどもRPAによって自動化する予定で、年間5333時間の業務時間削減を目指しています。
銀行業務のRPA化は他の地方銀行などでも行われていることです。
京葉銀行と同じ千葉県の地方銀行だけでも、千葉銀行や千葉興業銀行もRPA化を推進しています。
今回の京葉銀行のように住宅ローンの審査のような業務だけではなく、取引の照会業務やオペレーター業務なども自動化を行っている銀行もあります。
業務のRPA化によって、人員削減やミスの低下など多くのメリットが生まれています。
銀行とRPAの関連性については以下の記事に事例なども含めて説明しておりますのでぜひご覧ください。
これからのIT化社会においては、特に銀行の形態は変化していくことが求められます。
フィンテックやブロックチェーン、人工知能などの登場によって今後、銀行の役割自体が変化していく可能性があります。
それらに対応していくためには、まずは業務の見直しや標準化などが大切になってくるでしょう。
時代の流れに取り残されないためにも、今ある業務をもう一度見直すときが来たのかもしれません。
2018.11.27
目次
【前回の記事はこちらから】
前回は実験の概要を紹介するまでの流れだったので、本日は具体的な実験結果に対し考察したいと思います。
下記に実証実験のURLを載せていますので、参照にしていただければ幸いです。
※日本電気株式会社＿RPA実証実験結果 （PDF 3.8MB）
RPAを導入することとは、ロボット中心の運用フローが必要となります。
日本のアニメに慣れ親しんだ人にとって、ロボットを人間に近い姿形をしたものを想像しますが、
RPAはどちらかというと産業ロボットの事務バージョンと考えた方が良いかもしれません。
産業ロボットは、工場の組み立て業務を人間に代わってやってくれる、
一方、RPAはオフィスで事務作業を人間に代わってやってくれます。
産業ロボットを導入すれば、組み立て方も変わることがあります。
同様に、RPAを導入すれば、運用フローも変わります。
今回の実証実験の流れは
※運用前
個人を特定（人）
↓
住民税システムへ入力（人）
↓
確認帳票の出力（人）
↓
入力内容の確認（人
※導入後
OCR装置でのイメージファイル化（人+OCR）
↓
OCRソフトウエアでデータ化（ロボット）
↓
個人を特定（ロボット）
↓
住民税システムシステムへ入力（ロボット）
↓
未処理分の特定、入力（人）
↓
確認帳票の出力（人）
↓
入力内容の確認（人）
となります。
一見、RPAを導入すると行程が増えているように見えますが、
NEC者の担当も処理時間が短くなるように組み立てているかと思います。
例えていうなら、昔のマヨネーズ工場などの卵を大量に使用する工場では、
はるか昔、人間が卵を割りつつも血や殻が入っていないか確認していました。
現代では、割卵機で割れた卵をセンサーと人がチェックするという流れに変わりました。
卵割機やセンサーが取りこぼしたものを人がチェックするだけになります。
人の役割として、ロボットやセンサーの取りこぼしをチェックするだけになります。
RPAを導入すると似たような感じ、ロボットの取りこぼしを人間がフォローするような結果になります。
この流れの中で、ロボットが取りこぼした「未処理分の特定、入力（人）」、
この作業をいかに減らすのか、いかに人が業務時間を減らすかがポイントとなります。
ここで発生する業務はOCRの精度などが原因のため、費用対効果も含めて考察する必要があるかと思います。
精度の高いOCRというのはかなり高額になるため、中々購入しようという決断は難しいかと思います。
実験結果では、特定方法を、
A個人を特定する番号
B事業所を特定する番号
C上記以外（職員による確認）、
と３つに分けて実施したとあり、結果的にRPAが検索できたものの内訳がRPA60%、人力40%とあり、
自動検索できたものが少ないように思われます。
「個人を特定する番号」とありますが、個人番号（マイナンバー）なのか、それとも氏名・住所・生年月日なのか、
具体的にどの情報で特定したのかが不明なので、因果関係は不明です。
実証実験の個人特定フローでは検索結果が１件かどうかで分岐しています。
1件になるまで特定したのかどうか、どのように絞ったのか気になる所であります。
住民税システムで検索する場合、宛名番号ですることも多いのですが、個人番号（マイナンバー）を記載しているのであれば、
個人番号で特定するのが一番ですが、個人を特定する番号での検索率40％だとするとなぜ40％しか検索できなかったのか、
検索できなかった理由を明確に知りたいところではあります。
OCRの課題については、OCRの性能に基づく点が多いので、
他社のものを使えばより精度が上がるようになるかと思います。
今回の実証実験で使用したOCRは、手書きに対応しているもののAI-は搭載されておらず、
精度が上がっていかないものかと思います。
他社のAI-OCRはAIが学習することで読み取り精度が上がっていくので、40％の精度が更に上がっていく可能性があります。
記入する枠がせまい問題や点線については、異動届の様式の問題なので、
本導入する際に変更すれば対応できるようになる問題です。
しかし、市民課などの窓口業務でOCRを導入するにあたり、住民票などの申請書の多くは、
A4を半分にカットしたA5であるので、文字が小さくても読み取れる性能が良いかと思います。
RPA×OCRの導入ハードルは比較的高いようですが、効果は出ると思いますので、
RPAを導入するにあたり、業務フローの見直しを含めて検討する価値はあるかと思います。
異動届の仕訳については、1週間あたり340件の処理で職員の作業時間が15分なので、
RPA化をあえてしなかったように思えますが、個人的にはここもRPA化してもいいかなとは思います。
15分の時間を短縮する目的というよりは、
人間による仕訳ミスをなくすという意味ではRPA化した方が仕訳のミスそのものはなくなるかと思います。
未処理分の特定及び入力の職員の作業時間が436分、これについては多いという印象を受けます。
この436分を減らしていくこと、PDCAを回しながら工夫していくことが一つの課題かと思います。
NECの報告でも帳票定義の追加で436分が312分に短縮されるような提案がなされています。
今回の目的は実証実験なので問題はないかと思いますが、RPA関連に関わる方で、RPA導入を目的となり、
作業時間を減らすことをおざなりになっているような人達を多く見受けます。
また、ユーザーが継続的に利用することを念頭に置かず、複雑なフローにしてしまうことも多く存在します。
今後、そういった技術者、コンサルタントがRPAの未来を奪わなければ良いのにとは強く願います。
実際ユーザーであるお客様の声として大変貴重な意見ですが、好意的な意見が多いので、
ネガティブなこともあればと個人的には思いますが、NECの担当者が開発や対応も含めてよかったのであろうかと思います。
あくまでも実証実験なので、期間も短く、PDCAを回すような余裕もない中、裁量の結果が出たのかと思います。
RPAとは大げさなものでなく、Excelなど同じで、少し手を伸ばせば誰でもある程度は使えこなせるツールの一種です。
現在、RPAは百花繚乱時代で色んなRPAが出てきており、
ユーザーにとってはどのツールが良いのか分からない時代かと思います。
まだまだ各社でRPAの開発がなされており、今後も新たなRPAが出てくるかと思います。
ある程度出揃えば、RPAも淘汰されていくのではないかと思っています。
そうなった時は、ユーザーがシナリオ作成しにくいものというのは淘汰される対象になりやすいので、
ユーザーが使いやすい点も考慮しなければなりません。
現在、導入時には開発事業者に委託することが多いのですが、
開発事業者はユーザーでもあるクライアントがRPAを使用しやすい環境づくりも求められると思います。
今回の実験はRPA×OCRという実験だったので、大変意義のあるものです。
OCRはRPAが今後ツールの一種として認知されるためには必須のものかと思います。
実際、RPA導入を検討する方々にお会いするとOCRについてはかなり意識しています。
手書き対応のOCRについては、近年商用化されてきてはいるものの読み取り精度がユーザーの期待度を大きく超えないため、
もう少し定着に時間がかかるであろうかと思います。
OCRを導入するにあたっては、運用も含めた業務改善が必要になるかと思いますが、
手書きに拘らず、活字の帳票があるのであれば、活字帳票からRPA化を進めるのも良いかと思います。
2018.11.26
ご存知のとおり、RPAの大きい特徴としては明確なルールがり、かつ大量重複な作業に向いていると言わている。
また、ソフトによっても異なるが、導入時が発生する導入費用やランニングコストがあるため、当然RPAの作業量が多ければ多いほど費用対効果が優れるだろう。
そのため、現在多くの大中企業が積極的にRPAを導入しようとし、RPAのメリットを最大限活用しようとしている。
勿論、RPAの導入により、大中企業の場合特にインパクトが大きいが、大中企業の特性により、RPA導入時が起こるかもしれないトラブルもある。
今回のコラムでは、ある大企業がRPA導入にあたって起きているトラブルを紹介し、読者の参考になれればと思う。
今回事例となった企業は日本国内の大手企業A社だ。
業員数は約15,000人を超え、ITのメイン業務以外、金融などにも進出している総合グループだ。
この規模になると、当然RPAに向いている業務はたくさんある。
例えば、A社社内に複数の情報を確認システムが使われているため、特定の業務を遂行するためにシステム間のデータ交換が頻繁に発生する。
また、各グループ会社から特定な情報を集めて、集中て処理結果したりする業務もたくさんある。
これらの業務は今まですべて従業員がマニュアルで行っているが、すべてRPA化の良い業務だとA社が判断し、今年から全社範囲の大規模RPAプロジェクトを始めた。
しかし、プロジェクト組織体制のところでトラブルが起きた。
A社のRPAプロジェクトの組織体制がとても複雑な事になっている。
プロジェクトを担当するのは社内のIT部門になっているが、表1をご覧になると、IT部門以外に、とにかく色んな会社がこのRPAプロジェクトに関わっていることがわかる。
それぞれの役割を簡単に説明する。
RPAソフト選定するために、B社のコンサルティングを受けた。
RPAソフトを選定後、導入がよりスムーズにできるのと社内IT部門がRPAソフトを取得するためにC社と契約し、顧問を入れた。
そして、開発目標業務の選定やヒアリングなどは極めて工数がかかる業務なので、元々契約していたB社と社内IT部門以外、D社とE社と契約し、業務ヒアリングを入れた。
ヒアリングのあと、如何でRPAを開発するかというRPA開発設計をする必要があるが、A社内にリソースがないため、B社とE社が担当するとなった。
最後の開発段階だが、B社がヒアリング、設計をした業務を自らのチームで開発をしている。
それ以外は元々C社の指導を受けて、自社IT部門が開発するという方針だったが、社内IT部門のトレーニングスピードが遅くかつリソースが足りないため、単価の安い海外F社にアウトソーシングしている。
ただし、F社は選択されたRPAソフトの開発経験が足りないため、C社の指導のもとで開発をしている。
ここで、まずとして、外部からの組織が多い。
もちろん、一つの会社にすべての段階をサポートしてもらうのが良いが、様々な原因があって、特に大企業の場合、実際複数の外部会社と契約している場合も多い。
複数と会社と契約するほうがコストが安い場合もある。
A社の大きい問題点は複数の会社と契約していることではなく、これらの会社を統括できていないところにある。
B社はヒアリングから開発までのリソースを持っているため、チーム内で完結をしている。
D社は業務ヒアリングや書類作成が得意な会社なので、その部分のみを担当する。
E社はRPA開発設計ができるが、D社と社内IT部門のヒアリング結果に基づいてRPA開発設計を行う。
最後E社が開発設計書類をF社にレビューし、開発を行う。
各社が自らの部分を担当しているが、プロジェクト全体の進捗などを共有する場がないため、各社も実際どこまで進んでいるかも把握していないのが結果になっている。
また、各社のコミュニケーションはA社のIT部門経由で行っているため、非効率な場合がある。
例えば、D社は業務ヒアリングなどは得意だが、RPAに対する理解度が浅いため、ヒアリング時RPA開発に必要な情報が揃っていない場合やそもそもRPA開発が困難な場合がある。
そして、この情報がE社のところに届いたら、開発設計がスムーズに進められず、D社に再度の問い合わせが必要となる。
もしD社がヒアリングしている際にE社との連携がうまくできていれば、効率がよくなるだろう。
もう一つ統合できていないのは書類の管理だ。
開発ラインを大きく分けるとB社が一つチームで、DEF社が一つチームになるが、この二つのチームが使っている書類のフォーマットもそろっていなければ、保存場所も異なる。
要するに、同じプロジェクトで同じステップの業務をしているにも関わらず、ノウハウなどはあまり共有されていない。
RPA開発では、異なる業務でも似たような操作などがあり、とても参考になるだろう。
また、書類フォーマットが統一されていないと、後日のメンテナンスも大変なことになり得る。
解決策として、もちろん、外部組織をすべて統合するPMを設けるのもできるが、外部と契約する場合構造を変えることも方法の一つだと思う。
表2のように、各機能層ごとに一つの会社と契約し、そして社内IT部門は勉強しながら外部の会社と一緒に業務を行う。
この場合責務もはっきりしているし、各機能を担当する会社が内部でリソース調整やノウハウ共有もよりスムーズにできるだとう。
RPA化業務選定の段階から、各部署にヒアリングしに行くことか必ず発生する。
ヒアリング対象は基本選定された業務の担当者が適任だが、A社の場合もこの方針だ。
ただし、問題点としては、各部署にRPA化に対応する担当者を明確には設けていなかった。
勿論RPA対応担当者が必要ではない。
例えば、部門間のコミュニケーションが簡単に取れれば、IT部署が他部署にヒアリングしに行くことも簡単だろう。
そして、実際開発する際に、色々と追加の確認事項や仕様変更の相談も必ずあるので、随時に確認することも難しくない。
ただし、A社の場合、規模が大きいため、部門間のコミュニケーションは普段十分にとられていない。
A社の業務ヒアリングは通常ユーザー部署が対象業務のマニュアルを用意し、会議の形で開発部署にプレゼンする。
しかし、ユーザー部署はあくまでRPAに詳しくないため、RPAに合わせて業務フローを修正することが十分にできないだろう。
したがって、追加の確認事項がたくさん出てくるが、ユーザー部署の従業員が自分の業務が忙しく、それ以外のことを対応しきれないなどの原因で、なかなか確認取れない。
これの対策としては、一定期間で特定な従業員をRPA対応担当者に指定し、期間内でRPA開発に必要なことを優先的に協力するようにしたら効果的だろう。
すると、例えば、RPAに合わせて現在業務フォローの改正やファイル書式変更などRPA対応担当者が集中に対応し、業務ヒアリングと開発がよりスムーズにできると予想する。
今回はA社がRPA導入時発生したトラブルのもとに、大中企業特に起こり得る組織体制問題を紹介した。
外部組織と複数契約する場合最大限各組織を活かすためにうまく統合するか、役割別の組織構造を作る必要がある。
内部に関して、各部署間のコミュニケーションがうまくいかない場合、RPA推進する役を各部署に選定したほうが有効だろう。
全てのRPA導入プロジェクトが起きる問題ではなければ、これらの対策も正解ではないが、参考になれれば幸い。
2018.11.22
本コラムでは、RPAの導入機会を増やすために有効な、周辺ITツール／ソフトウェアの話をします。
RPAはその性質上、PC上で行われる作業しか対象となりえず、すなわち扱うデータ・情報は「電子化」されているものが基本的には前提となります。
今日のコラムでご紹介するITツール／ソフトウェアの数々は、通常の業務上で扱う情報を電子化する意味合いをもっており、それにより今まで紙等で行われた状況ではRPAの対象となりえなかった業務に対し、RPAによる自動化の機会を増やすことに繋がります。
このITツール／ソフトウェアはかなり広範囲の業務について、既に各ベンダーが製品を提供しております。
ただ、今回のコラムでは、特にRPAの対象として初手をつけやすい経理、人事、総務周りの業務で使われるものを紹介します。
また、奉行や弥生といった会計ソフトなど、通常どの企業様も使っているものについてはここでは割愛させていただきます。
今回紹介するITツール／ソフトウェアについても、既に「うちでは既に使っているよ。。」というものも多いかもしれません。
ただ、RPA導入コンサルティングの現場での経験から、実際にまだ未導入で紙や簡易的なメールのやりとりで済ましている企業様も多くいるものを選んでみました。
参考： RPAの導入を促進させるITツール／ソフトウェア
まず最初に取り上げたいのは、有給申請や婚姻などの各種申請を電子化するツール、通称ワークフローツールです。
これらの申請は後述する経費申請や勤怠管理のツールでも同様の機能をもっていたりしますが、「経費」や「勤怠」というカテゴリーには含まれない、社内申請も多く世の中には存在します。
例えば、総務に対する名刺の新規・追加印刷の申請や、保養所などの社内施設の利用の申請、そして、お客様の弔事に送る電報や花の申請というように、数多い細かな申請が世の中に存在します。
これらの申請は、通常はサイボウズなどのグループウェアを使っている企業様であれば、その機能から電子化することは可能です。
そのようなものは使っていない企業様の場合であってもGoogleのG Suiteと連携したワークフローツールを使用したりもできます。
RPAへの活用例としては、このワークフローツールで来た電子化された情報をもとに、担当者が承認ボタンを押せば、名刺や花の会社などに自動で発注メールが飛ぶように仕組みをつくることができます。
また、企業によっては受注案件や諸々の決裁について稟議書を回しているところもあります。
そのような稟議書もワークフローツールにより情報を電子化することで、転記作業などを自動化することは可能です。
次に取り上げたいのは、社員の旅費・交通費などの経費申請についてです。
社員が立て替えて支払うもの代表は出張等に付随する交通費、宿泊費などですが、企業によってはそれ以外の諸々の経費申請が発生するケースもあります。
このような申請を簡易化するためのツールとして有名なのはコンカーや、楽楽精算といったサービスになります。
特に、コンカーでは、社員は領収書をスマートフォンで撮り、その画像で申請をすることも可能になります。
紙の証書も規則上、提出することが求められますが、電子帳簿保存法の施行により、かなり領収書管理の手間を省くことが可能になります。
これはRPAによる効果とは別の話になりますが、経費精算はどの企業も負担に頭を悩ます業務ですので、一考の余地はあるかと思います。参考までに横浜ゴムでの事例を紹介します。
参考： 領収書電子化を急げ！電子帳簿保存法対応の先陣を切る横浜ゴムの狙いとは
(https://www.concur.co.jp/newsroom/article/case-study_yokohama-rubber-ebunsho )
この経費精算ツールとRPAの連携についてですが、主に会計ソフトへの転記作業が中心となります。
経費申請をするときに、社員番号や、費目情報、そして部門コードやプロジェクトコードも入れさせることにより、会計ソフトへの転記が自動化できる余地が広がります。
もちろん、何でもかんでもチェックなしで申請を認めるわけではないので、上長など担当者による承認がなされたもののみを転記対象とします。
社員の日々の勤務時間や、有給消化、代休や振休の管理は、ほぼ全ての企業が行っている業務と言えます。
これらの企業活動に欠かせない業務を扱うのが勤怠管理ツールです。
これらのツールには打刻システムと連動したり、シフト管理や労務時間を案件ごとに割り振ったりできる機能もついていたりします。
これらのツールで有名なのは、チームスピリットやジョブカンといったサービスになります。
筆者の所感でいうとチームスピリットは案件管理に強く、B2B向けの事業を行う会社に有効、ジョブカンはシフト管理等ができやすいので小売業などB2C向けの印象です。
RPAの活用シーンとしては、これらの勤怠情報から残業手当などの金額を算出したり、残業過多の社員のリストを作ったりしますが、それらの作業を自動化する際によく使われます。
こちらも先述の勤怠管理と同様、所轄で言うと人事部周りのツールになります。
人事評価の管理であったり、各社員の所属、組織変更などに対応して人材管理を行うためのツールです。
既に社内にいる人材についてはワークデイやカオナビといったツールが存在しますが、その他にも数多いソフトウェアが存在します。
特にワークデイは、統合型であるので組織図や従業員の管理もできますが、その他に給与明細や休暇申請、そして経費や財務の管理なども行えます。
また、その他に人事部の業務の大きなものとして採用活動が挙げられると思います。
このように新卒や中途などの応募者の管理については、現状リクナビやマイナビといった採用活動支援サイト運営事業者が提供するツールを使うことが一般的です。
特にマイナビはAOL（アクセスオンライン）と呼ばれる採用管理システムを持っており、多くの企業が利用しています。
RPAの活用シーンとしては、これらの人事管理ツールへの情報入力や抽出・エクセルへの転記といった作業が挙げられます。
特に、採用活動については、多くの企業がリクナビとマイナビを併用しており、両者のデータ連携作業、例えばリクナビのデータからマイナビのAOLへの打ち込み作業といったものが発生しています。
このような単純ですが量の多い業務はまさにRPAに打ってつけの領域となっています。
最後に、ご紹介するのはOCRです。
OCRは紙面上にある文字情報を電子テキスト化する技術を指します。
このOCRの技術は筆者経験上、どのRPAプロジェクトでも必ず一度は話題に挙がるトピックです。
バックオフィスでのパソコン業務の多くが、実はこの紙の帳票にある情報を入力することであったりするからです。
例えば、お客様からの申込書や、各種ベンダーから請求書、そして先述した社員の経費精算からの領主書などなど、紙上の情報は日本で溢れています。
もっとも良い方法は、これらの紙を電子請求書システムや、電子申込システムに置き換えることですが、慣例上、印鑑の捺印が求められたりするとなかなか難しかったります。
筆者がコンサルティングの現場でまずおすすめするのは、紙情報での申し込み・届出自体を電子化することですが、それが上記の理由により難しい場合は、OCRの検討を提案します。
このOCRの読み取り精度は日進月歩の世界であり、どの会社の製品を選ぶかが非常に重要になります。
特に、お客様からの申し込みなどの「手書き」を読み込ませたいのか、ベンダーから請求書などの「活字」を読み込ませたいのかで適したソフトウェアは異なります。
例えば「手書き」であればAIインサイドなどの手書き読み取りにAI-OCRがお勧めです。
また「活字」の場合、重要なのは一文字一文字の読み取り精度というよりか、帳票フォーマットの特定や、その中にある必要情報の抜き出し技術になりますので、ABBYY社のような製品が適していると言えます。
このOCRツールとRPAの連携シーンについては言わずもがなでしょう。
OCRにより電子化されたテキスト情報を各種システムに入力するところをRPAが担います。
お分かりの通り、このOCRとRPAの相性は非常に良く、今後もRPAのプロジェクトが世の中に浸透するにつれて、同時にOCRの取り扱いノウハウもコンサルタントに求められてくると予想されます。
今回は経理・人事・総務周りで使われるツールを紹介しましたが、営業事務ではセールスフォースなどのCRM、SAPなどのERPツールのようなものもよくRPAの対象となります。
ただこれらのCRMやERPは事業の根幹を担うものであり、既に導入されている企業は多いです。
一方、今回ご紹介した経理・人事・総務周りのツールは導入が後手になっている、もしくは導入済であっても使っている部署とそうでない部署が混在していたりと標準化が不十分なケースが散見されるものです。
業務効率化、働き方改革の推進に興味を持つ企業様はこの機会にぜひ導入を検討し、RPAと併せて業務負荷低減の果実を狙うことをお勧めいたします。
2018.11.21
RPA業界で最大手の一つであるUiPathは11月15日に中国北京市内にて初の顧客向けセミナーを開催した。
UiPathは日本でも多くの企業に導入されているRPAツールである。
そのツールの使いやすさと、教育ツールを無料で開放しており開発者の育成コストが低いことがUiPathが多くのユーザーを取り込んでいる点の一つだ。
さらに、限定的ではあるが「UiPathコミュニティエディション」を使用する際は導入コストが0円で使用することができる。
これにより、まずは試験的にRPAツールを使用することが可能な点もメリットの一つだろう。
もっと詳しくUiPathについて知りたい場合は、弊社のエンジニアが二か月間UiPathを使用しての感想やメリットなどをまとめているので以下の記事をご一読願いたい。
さて、今回中国でUiPathはセミナーを行ったわけだが、ここには中国での市場拡大が狙いであるという見方ができる。
実際、UiPathのアジア太平洋地域の営業を統括している金少陵バイスプレジデントは「この1年間で、アジア太平洋地域で500社以上のユーザーを新規開拓し、このうち160社以上が中国のユーザーだ。」と紹介し、今後中国市場はますます大きくなっていくとの見方を示している。
確かに、現在ではアリババもRPAに意欲的な見方をもっており、「アリクラウドRPA」という名のロボットも開発している。
他にも、国営最大手航空会社である、中国南方航空もコスト削減のため、Ernst & Youngとコラボをし、車内の財務システムをRPA化することを図っている。
それ以外にも多くのRPA化を行っている企業が存在する中国。
中国国内でRPA化した企業の詳しい業務内容や他の企業については以下の記事にて記載しているのでよろしければ読んでいただきたい。
従来は人件費が他の先進国の国々に比べて低かったため、削減できる費用には限界があった中国。
しかし、今後人件費が上昇することにより企業側も何かしらの対策を必要とするのではないだろうか。
今回のセミナーでも現在の中国の人件費が毎年上がってきており、そこにRPAの入り込む余地があるのではないかという意見も出ているようだ。
今後、日本の人口減少や移民の受け入れによって社会情勢が変化していく中で、中国でのRPA市場も目が離せない。
2018.11.20
今年可決されたばかりの「働き方改革法案」。
以前から「日本人は働き過ぎ」と言われてきましたが、なかなか改革が進みませんでした。
しかし、ここにきて労働環境が一気に変わろうとしています。何故、労働環境が変わろうとしているのでしょうか。
そもそも、働き方改革は何故始まったのでしょうか。
具体的な事例を紹介しながら「働き方改革とは何か？」改めて考えていきたいと思います。
2016年頃から政府主導による働き方改革が進みだしました。この改革の背景にあるのは、今日本の置かれている状況にあります。
日本の総人口は今後も減少が予想されており、2050年には国内人口が1億人を下回ると言われています。
人口の減少にともない、労働人口も当然急速な勢いで減っていきます。
労働人口が減るとどのようなデメリットが発生するのでしょうか？
想像しやすいことだと、「働き手」が若者を中心に減っていくので、我々の実生活にも影響が出てくることが挙げられると思います。
さらに、働き手が減少することで国の生産力も落ち「世界から見た日本の経済力」という観点でも非常に悪い状況になります。
他国が経済的に伸長する中、日本だけが取り残されていってしまうかもしれません。
働き方改革とはこのような背景から、「総人口が減り、少ない労働人口の中でも効率的に日本の経済を回す方法」を考えています。
もちろん少子化対策や社会福祉制度もあわせて考えていかなくてはいけませんが、働き方改革では労働における効率化を中心に議論されています。
①労働の効率化：残業して長時間働くのではなく、労働生産性を上げる
②労働の多様化：ITやクラウドツール等を利用しオフィス以外で仕事ができる環境をつくる
③労働の一般化：高齢者の雇用、育児中の女性の労働参加促進
という３つの視点で働き方が見直されています。
それでは、具体的な事例をご紹介しながら働き方改革を考えていきましょう。
かつて日本では「モーレツ社員」といって長時間働く者が優秀とされてきました。
極端な例ですが「10時間働いて10万円分の成果を出す人」と「6時間働いて10万円分の成果を出す人」では、前者の方が「残業をしていてがんばっている」と評価されました。
しかし、これは本来の評価の視点では不公平です。
「長時間残業をしている人が偉い」という考えを無くし、どれほど効率よくアウトプット（＝成果物）を生み出せているのかを図ろうという動きに変わってきています。
労働生産性を上げる方法のひとつとしてテレワーク(在宅勤務)の制度を導入する企業が増えつつあります。
オフィスでなければできない仕事なのか？という視点で仕事を見直します。
例えば営業先の店舗からオフィスに戻り、日報を書いて提出する。
当たり前のように行っている業務ですが、日報を書く業務は本当にオフィスでなければできない仕事なのでしょうか？
最近では、クラウドを使いオンラインで日報を作成して共有できるツールもあります。
訪問先からオフィスに戻らず家で日報を作成することも可能です。
さらに、訪問の予定が無ければ、ビデオ会議やチャットツール等を使って出社せずとも仕事をする事が可能です。
企業にとってもアウトプットだけを評価すれば良く、交通費の削減などのメリットもあります。
既に大部分の企業で取り組まれている制度ですが、女性だけではなく男性へ育児休暇取得を促進する企業が増加しています。
男性社員が育児休暇を取得し子育てに参加することで家族とのコミュニケーションも高まります。
また、女性の活躍という視点でも男性の育児休暇取得は有効です。
日用品の大手メーカーである花王では子どもの生まれた男性社員に対して、育児休暇取得の促進を行っています。
対象の男性社員本人だけではなく、その上長に対しても育児休暇のリーフレットを配布して取得を啓発しているようです。
育児休暇と同様に既に多くの企業で制度導入が見られていますが、この制度でも男性社員への時短勤務も視野に取り入れてみましょう。
制度自体は多くの方が知っている内容だと思いますが、育児や介護にたずさわる社員を対象にして勤務時間を通常より何時間か短縮する制度です。
通常は8時から17時までの就業時間だった場合、例えば8時から15時までになるなど、就業時間が短くなる制度です。
現在は小さい子どもがいる女性社員の取得が圧倒的に多いのですが、今後は男性の育児参加も視野に入れて取り組む制度となりそうです。
また、8時から15時までと固定するのではなく、10時から16時までの勤務であったり、午前中までの勤務であったりと柔軟に設定する企業も多いようです。
近年では小さい子どもを育てる社員だけではなく、社員の両親の介護を目的とした時短勤務取得者も増えていくことが予想されます。
フレックスタイム制度も働き方改革が進む前から浸透している制度ですが、今後より一層期待される制度です。
時短勤務と異なり総労働時間は短くなりません。
しかし、1ヶ月の範囲内で始業の時刻と終業の時刻を柔軟に変更できる仕組みです。
9時～18時までが終業時間だった場合、1時間早く出社して1時間早く帰宅することも可能ですし、昨日1時間残業したから今日1時間早く帰るというように日を跨ぐことも可能です。
「昨日頑張ったから今日仕事早く終わってしまったけど、18時までが終業時間だから座ってないといけない。」という非生産的なことが減少します。
本当に毎日9時に全社員が集まる必要があるのか、18時に全員で終礼を行って業務を終える必要があるのか今一度考えてみると良いかもしれません。
（https://work-holiday.mhlw.go.jp/material/category1.html#subcategory1）
身近なITを使った働き方改革への取り組み例をよく聞きますが、ハードなツールだけじゃなく、企業風土に合わせて活用していかなければなりません。
ノー残業デーを導入してみたが形だけで終わっている、男性の育児休暇取得推進も人事が盛り上がっているだけで実態としては誰も取らないという声が多く聞かれます。
そのためにはまず管理職自ら率先して行動する事で、組織に制度を馴染ませてあげる必要があります。
他社から転職してきた部下、年下の上司、外国人の同僚など、従来の年功序列型日本企業には無かった社員の多様化が進んでいます。
また、ITを利用することで直接相手と話をしたり、議論したりする機会も減り、組織内で個人間の意思のすれ違いが発生しています。
こうした状況の中、人事が現場に入り個人と個人の関係に着目した「組織開発」に注目が集まっています。
近年の環境変化の激しい状況の中、企業は生産性の高い機動的な組織の構築が求められています。
経営者は持続的に成長できる「組織力」をどう作り上げるか、という事に大きな問題意識をもっています。
組織開発に注目が集まる背景には、働き方が変化したことにあります。
従来の日本企業では一度新入社員として入社すると、その企業だけでキャリアを過ごす事となるため、社員の同質性が高く価値観がずれるなどは発生しにくい環境にありました。
いわゆる「同じ釜の飯」を食べる、家族に近い組織で構成されていました。
しかし、現代においては社員の多様化が進み、転職してくるもの、上司が年下や女性、あるいは外国人が同じ組織に所属している、というケースも珍しくありません。
こうした環境の変化を背景として、個人ではなく、個人と個人の関係性に着目し、組織全体の変化に対応するにはどう変革すべきか、というアプローチが組織開発です。
2018.11.19
参考記事）スカイコムとRPAテクノロジーズ、OCR不要のBizRobo! Paper-free
RPAテクノロジーズ株式会社（以下「RPAテクノロジーズ」）は、株式会社スカイコム（以下「スカイコム」）と協業を行い、新サービス「BizRobo! Paper-free」を2018年11月14日より提供開始しました。
RPAテクノロジーズはRPA業界最大手の一つである、RPAホールディングス株式会社（以下「RPAホールディングス」）の子会社であり、RPAのベーステクノロジーを提供している企業です。
RPAテクノロジーズが提供しているサービスの一つに「BizRobo!」があります。
従来の「BizRobo!」のサービスについて詳しく知りたい方は、以下の記事で細かく説明していますのでよろしければご覧ください。
スカイコムは自社開発のPDF技術を保有する純国産のPDF産業メーカーです。
スカイコムが提供している製品シリーズには「SkyPDF」「SkyAgent」「SkyPAS」が存在し、それぞれの製品ごとに特徴があります。
その中でも、今回「BizRobo!」と連携するシステムは「SkyPDF」というサービスです。
「SkyPDF」は様々な状況に想定したオプション製品も提供しており、ワードやエクセル、パワーポイントなどへの変換やWindowsタブレットによる手書きの文字入力の補助など、他にも多くのオプション製品が存在しています。
そして今回新しく提供されるのが「BizRobo!Paper-free」です。
その内容は多岐にわたり、従来の申告書などの仕分け作業の代行業務だけでなく、その先のシステム管理から二次・三次利用に至るまでを人間の手から解放してロボットが代行してくれるという内容です。
（引用：RPAホールディングス株式会社、BizRobo!Paper-freeによる文書関連業務のデジタル化イメージより）
具体的な業務内容としては、経理業務などによる請求書からの記帳や紙媒体から電子データへの移行という業務内容が想定されます。
簡単に言うと「（紙をやめるなど）BPRを先にやろうぜ、そしたらRPA化しやすいからさ」というサービスのようです。
経理や税理の業務については以下の記事にて詳しく説明しております。
経理・税理の業務内容の中でRPAをフルに活用できる分野を説明しておりますのでよろしければご覧ください。
さらに、筆跡鑑定可能なストローク情報を暗号化して保存する技術によって電子サインとしての機能も実装しているようです。
2018.11.16
本コラムでは、RPAの導入をする上で欠かせないコンサルタントの話をします。
筆者自身もそのような仕事をしている人間の一人でありますが、果たしてRPAコンサルタントの仕事とはどういうものでしょう。
エンジニアとの違いも含めて説明したいと思います。
まずRPAの導入プロジェクトの工程ですが、以下になります。
参考：RPA導入プロジェクトの工程
このうち、RPAコンサルタントが支援するのは主に最初の対象業務選出からプログラム設計書作成までです。
プログラム設計書については、一見エンジニアの仕事だろ。。。と思われるかもしれません。
確かに、大規模プロジェクトの場合、リソースにも余裕がありますので通常はエンジニア側の仕事になりますが、中規模・小規模になるとエンジニアには開発に専念してもらったほうが良い場合があります。
その場合、コンサルタントが設計書まで書き、開発エンジニアにロジックを説明する、といったこともしばしば起こるのです。
また、プログラム（RPAのシナリオロジック）の設計をする際に、都度、業務側つまりユーザー側との仕様変更やフロー変更等を詰めていく必要があります。
その場合、エンジニア→コンサルタント→ユーザーと重層的なコミュニケーションをとるよりか、コンサルタントがプログラム設計書まで書いてしまい、都度、ユーザーと確認するほうがスピードも増します。
それでは、RPAコンサルタントとしてプロジェクトを回すためには、どのような知識・スキルが必要でしょうか。
それは大きく言って３つあります。
RPAコンサルと、通常の業務改善を試みる業務コンサルタントとの大きな違いとして、まずロボットに関する理解が挙げられます。
RPAというのは、一種のITツールでしかありませんが、それを導入するとなった場合には、
ITシステムとして捉えるよりか、ロボットという一個の特殊な人格が入社してきたと思ったほうがイメージがつきやすいことがあります。
このロボットは融通が利かなく、全くもってして決められたマニュアル通りの作業しかできませんが、ただその代わり、処理速度は高速でかつ正確無比、そして24時間働けるといった特徴を持っています。
このような特徴を持った人格が最大限にパフォーマンスを出すためには、既存の人間達はどのように彼／彼女に接すればいいのか、指示の出し方はそうするのか、仕事の分担・棲み分けはどうすればいいのか、考えることになります。
あたかも動物園の職員たちがライオンはどういう生態をしているのか、キリンはどういう生態をしているのかを熟知して飼育をしているのと同じように、RPAコンサルタントもロボットというものがどのような特徴をもっているのか知る必要があります。
既存の業務フローをロボット用のシナリオに解釈しなおす必要があり、その時には最低限のプログラム知識が必要です。
また、先述したように、コンサルタントがプログラム設計書を書くケースも増えています。
RPAコンサルタントとして自身の市場価値を高めたいと思うのであれば、やはり自身の手である程度のRPAの設計が行える程度の知識はあったほうが良いと言えます。
次に、RPAの対象業務の選定等を行う際に、ユーザー部署の業務知識が求められます。
これは現実的にはユーザーとのアリング前に100％知識武装して臨むのは難しいですが、ある程度の一定水準の業務知識が求められます。
特に以下の業務/業界についてRPA化を進めるのであれば事前の知識があったほうがヒアリングは捗ります。
これは相手との話を円滑にスピーディーに進めるためだけでなく、業務選定をするためのヒアリング段階で相手の抜け漏れや、追加業務の存在を気付かせる上でも有効になります。
専門知識のいる業務（経理・財務業務など）： 経理の関係の業務はRPAにおける一大分野となっています。
「まず試しに一部署から。。。」というクライアント企業が、経理部を対象に挙げることも多いです。
そして、この経理部の業務というのは、大きな流れでいうと各社で差ほど業務内容の相違がない領域でもあります。
従って、RPAコンサルタントがまず業務知識を習得しようとする場合、真っ先にこの経理業務の知識を増やすことをお勧めしております。
経理・財務では、買い掛け・売り掛けの計上やその消込、源泉徴収などの専門用語が良く出てきます。
このあたりの言葉の理解、そして一般的な経理業務のフローを聞き手側のコンサルタントが抑えておくと、ユーザー部門側のストレスも減じると思われます。
専門知識のいる業界（医療／金融／不動産など）： これは、これらの業界の全ての業務で必要なわけではないですが、例えば、製薬会社の治験業務のRPA化を図る場合、PMDAへの申請のための標準フローなどを知っておくことが求められます。
また、不動産や金融機関のRPA化の場合、ローン審査などが対象業務に挙げられることが多いですが、そのあたりの規約や届出に必要な書類の知識も事前にあったほうが望ましいです。
最後に、これはコンサルタントとしての必須の素養ではありますが、ユーザー部門の相手から情報を聞き出し整理するためのヒアリングスキルが挙げられます。
ユーザー部門の方々は、日々自身が行っている業務は誰よりも詳しいはずですが、必ずしも整理されている訳ではありません。
例えば、最初にRPA対象業務の選定をする段階で、大まかに各ユーザー部門の方々から自身の部署が行っている現業務項目を洗い出してもらいます。
その時に、大きな括りから小さな括りまでバラバラの形で自身の業務を話される方もいます。
このようなときに業務項目を大・中・小レベルくらいに構造化して頭の中で整理しておかないと後で、エクセルに業務リストとして落とした時に非常に読みにくいものになってしまいます。
また、このRPAのプロジェクトは大きな範疇で言うと「業務改善」の施策の一つになります。
業務改善というものは、本来なら現場職員の方々の負荷を軽減するためのものですが、一つ情報の見せ方を間違えると「人減らし」の施策にも映ってしまいます。
また、現場で日々目の前の業務に勤しんでいる方々からすると、良きにしろ悪しきにしろ自分が今までしていた仕事のやり方を変えられるのは抵抗を生むものです。
そのあたりの人間心理を理解し、円滑に現場ユーザー部門の方々と話をし、一緒にロボット向けの仕事のアイデアを考えていくような協力的な関係を構築するには高いコミュニケーション能力が求められます。
それでは、RPAコンサルタントとして必要な各知識・スキルの習得の仕方について述べたいと思います。
こちらについては弊社の社員のトレーニングプログラムでも使っている実績のある手法をご紹介します。
こちらについては、まずは各種RPAソフトが出しているチュートリアル・トレーニングツールを活用することをお勧めします。
弊社では、RPAソフトの中でもUiPathに特に力を入れておりますが、そちらではUiPath Academyというサイトがあり全14レッスンを受けることで資格取得ができます。
参考： UiPath Academy （https://www.uipath.com/ja/rpa/academy から登録）
こちらは動画でのチュートリアルがありますが、基本的に「自主学習」で進める内容になっています。
これはプログラマーの方は全員同意していただけると思いますが、特にプログラミングの世界ではこの「自主学習」の姿勢こそが大事になります。
自分でプログラミングしてみて、うまく動かない時に、仮説を持ち検証し、それでも分からなければ外部サイト等を参照しながら別の打ち手を考えます。
その工程を繰り返すことで、知識が身につくことになるからです。座学形式の聞くだけ講座では決して身につきません。
例えば、Web画面からSelectorを使って情報取得する場合や、PDFやエクセルの帳票から情報を取得するの為のロジックを想像するには自身でプログラミングした経験をつけることが一番です。
えてして同じ帳票タイプ（同じ会社からの請求書など）であっても物によって微妙に記述内容が変わったりします。
その法則性を見つけ、ロジックに落とし込むといったことはコンサルタントであっても身に着けるべき素養であると考えます。
次に、コンサルタントとして習得すべきは、「業務選定」のやり方です。
ここでは、ある程度の業務知識も求められるので、比較的使いまわし良い「経理業務」についてのヒアリングを想定します。
最初に一般的な経理業務というものを棚卸したひな型テンプレートを用意し、それをもとにトレーナーをクライアントに見立てて、ヒアリングしていく練習をしていきます。そして最終的にそのクライアントに合った業務リストを再整理・精緻化していきます。
また、その際に①で培ったプログラミング知識を活かして、結局どの業務がRPAに向いているのか評価する練習も重要になります。
また、RPAの効果を最大限化するためには既存のフローの変更も提案しなければなりません。このあたりのスキルは一朝一夕で見につくものではありませんが、まずは果敢に自身で考えて提案していく姿勢を醸成していくことが肝要になります。
最後に、To-Beのフローについてクライアントと話した結果を設計書にフロー図として落とし込む作業です。
正確には、前述の業務選定と設計書作成の間にAs-IsとTo-Beフローの作成を行うのですが、最終的にプログラム設計書が書けたらこれらのものも同様にできるので割愛しています。
プログラム設計書の場合は、よりロボットの深い知識に基づいたフローの作成が必要です。
でないとエンジニアが開発できないからです。最終的には成果物としては以下のようなものができます。
参考： プログラム設計書例
以上が、RPAコンサルタントになるための必要知識・スキルについての説明になります。
正直、このあたりの知識・スキルは簡単即席で見につくものではないと思いますが、とはいえOJTに任せてばかりだと習熟のスピードが神頼みとなってしまいます。
コンサルタントを目指す個人にしろ、コンサルタントを育てる企業側にしろ、受注案件だけに頼らない育成の仕組みが求められます。
2018.11.14
RPA(ロボティック・プロセス・オートマティック）は、既存システムと異なり、
比較的低コストで業務プロセス自動化を実現できるのが最大の強みです。
RPAを活用すれば、従来はROI（投資収益率）面で見合わないなどの理由で
IT導入が見送られ人海戦術でカバーしてきた業務プロセスにも光が当たります。
イギリスのブルー・プリズム社がRPAを立ち上げて15年、ようやく日本国内でも普及が進んできました。
総務省のレポートによると国内では20.4％が導入済又は導入中、19.1％が検討中です。
企業もバックヤード業務の生産性向上のため、重い腰を上げつつあるのです。
とはいうものの、RPAは万能ツールではありません。
今回の記事ではRPAで効率化できる（又はすべき）業務と難しい業務について、経理業務を事例に解説します。
事務の派遣さんを使ったことがある方はお分かりだと思いますが、派遣さんは契約により定められた業務をこなすのが仕事です。
勝手にお茶くみやコピーをお願いしてはいけません。
定型業務をマニュアル通りに進めるのが原則で、マニュアルに載っていないような事態には対応できません。
突発的に判断を要する場合、派遣さんは必ず正社員に指示を仰ぎます。
派遣会社から、そうするように厳しく指示されているからです。
RPAも、派遣社員と同じです。
ここでは、仮に「ロボ山さん」としましょう。
ロボ山さんが担当するのは、「単純なパソコン操作」だけで、他の業務は指示できません。
ペーパーを扱う業務も、NGです。
その代わりパソコン操作、例えば複数システムの立ち上げ・ログイン・エクセルファイルへのデータ抽出・転記・金額の照合・共有フォルダーへの保管や更新・添付ファイルのメール送信といったタスクは大の得意です。
人間が数時間かかるような一連の作業を、ロボ山さんは2-3分でこなします。
しかも、他の派遣さんと違ってミスしません（指示が間違っていれば別ですが）。
残業規制も関係ないので、夜中でも働けます。
風邪をひいて休んだり、ある日突然会社に来なくなる、なんてこともありません。
まとめると、RPAとは「パソコン操作」中心の「定型的な業務」を、ソフトウエアロボットにより代替するソフトウエアなのです。
RPAベンダーのプレゼンでたまに紹介されるのが、以下のような事例です。
確かにこうした業務は、定型的な業務ですのでRPAには向いています。
ただし、こうした業務は処理件数が膨大で高いROIが期待できるので、すでにIT化している企業も多いのです。
むしろRPAに向くのは、処理件数が少ないようなニッチな仕事です。
例えば、経費精算で過剰請求があった場合の返金処理です（ちなみに経理は、過少請求を見つけてもそのままスルーします）
最近の経費精算は、担当者が申請し所属長が承認したら即転記・振込みというケースが多く、経理のチェックは事後というケースが増えています。
ですから、過剰請求があった場合、経理担当者は申請者に過剰分の返金を求めなければいけません。
経費精算システムはこうした事態に対応していないので、以下のようなハンドリングの処理が必要です。
一連の作業は、全て人手でカバーせざるを得ません。
経費精算業務は、業務負荷が膨大ではないにしても、そこそこ手間がかかる「IT化されていないプロセス」を数多く抱えています。
そうしたプロセスこそ、RPAに適しています。
消費財メーカーでいえば、得意先に対する一連の取引、受発注・納品・請求回収といった業務はEDI（電子的データ交換）により自動化されています。
一方で、返品（売れ残りや不良品）処理に関しては、EDIには乗っているものの、入力データの不整合・返品データ処理と現物返品タイミングの不一致・返品ルートの輻輳などの問題があり、照合・返品データ登録に関しては手作業に頼っているのが現実です。
もちろん照合・登録したデータは会計システムにインターフェースされていないので、こちらもハンド入力せざるを得ません。
その他、メーカー側から供給する販促ツールの費用処理も、システム化が難しい業務の1つです。
販促物といっても、商品サンプル・販売什器・カレンダーなどの配布物など実に多種多様です。
ツール・得意先によって供給ルートがさまざま、費用負担（得意先請求またはメーカー負担）もケースバイケース、社内決裁が必要な場合もあり、システム化が難しいのです。
こうした「統一処理が難しい業務プロセス」こそ、RPAによる自動化に向いています。
一方、RPAにも苦手とする業務プロセスがあります。紙を取り扱う業務です。
ここ数年、政府や税務当局によるアナウンス効果もあり、決算帳票（決算書・補助簿・伝票等）の大部分はペーパーレス化が進みました。
一方で、領収書・請求書は昔から殆ど変わっていません。
スマホによる画像がタイムスタンプ付という前提で証憑として認められるようになりましたが、領収書を見ながら申請データ（支払日・使用目的・発生部署・予算区分等）を入力するやり方は同じです。
最近のRPAベンダーはスマホ撮影・文字認識API（アプリケーションプログラミングインターフェース）をセットで提供し、領収書の自動申請を売り込んでいます。
最近の文字認識は性能が良く、手書き文字でない限りはほぼ完ぺきにテキスト化できます。
ただし、領収書のフォーマットは多種多様です。
フォーマットがバラバラのデータを「非構造化データ」と呼びます。
残念ながら現状のRPAは非構造化データを認識できないので、さすがに完全自動申請とはいきません。
しかも経費精算自動化の決め手は、文字認識の高度化ばかりではありません。
現金大国日本でも、最近ようやくキャッシュレス化の機運が高まっています。
社員にスマホを支給しているケースでは、スマホ決済を通じた支払いデータの自動取り込みも視野に入ってきます。
そうした点を踏まえると、今慌てて文字認識APIを導入するのが得策かどうかは、よくよく考える必要があります。
現状のRPAは「第1世代」と呼ばれ、テリトリーは定型業務に限られます。
前述の領収書のような非構造化データ認識や例外対応の自動化は、第2世代によって可能になるとされています。
さらに第3世代では、例えば予算編成・売上損益実績のモニタリング・差異分析といった管理会計分野や、決算報告資料のドラフト作成や適正性チェックといった監査・ガバナンス分野など、人の判断を要する処理も可能になると言われています。
将来的にはこうした進化も期待できますが、それはAI（人工知能）のコグニティブ（認識系）機能を飛躍的に向上することができるかにかかっています。
ただし第2世代・第3世代の主役はAIであり、RPAは補完的な1機能に過ぎなくなりますが。
経理部門としては、将来世代の登場も想定しつつ、当面は第1世代RPAをフル活用して定型業務の自動化に注力するのが賢明です。
2018.11.13
RPA(Robotic Process Automation)は現在、「RPA女子」などのワードがgoogleのトレンドに載るなど、RPAを現在の資源と組み合わせることで推進していこうという流れがあります。
そんな中、株式会社アーネストキャリア（以下アーネストキャリア）は株式会社RPA NEXT（以下RPA NEXT）との提携によって、「発達障害者×RPA」の人材育成を行っていくと発表しました。
RPA NEXTは2017年に創設された企業で、RPAの人材育成を目的としたカリキュラム構築を行っています。
主にホワイトカラー系業務の効率化を図るために導入するRPAですが、
多くの場合、RPAのエンジニアでない一般の人々にも簡単にわかりやすいプラットフォームが多いです。
そのため、非エンジニアの方々がいくらか研修のプログラムを受けて、シナリオを書いている方も実際いらっしゃいます。
そこに、シニアの方々や地方勤務を希望する方、さらには障害者の方々にもRPA技術を学んでもらおうと考えているのがRPA NEXTの方針のようです。
障害者の方々は何かしらの機能や能力を欠如、または不得意とする人たちのことだというのが多くの人の認識だと思います。
しかし、そこには多くの見えていない部分があります。
例えば、視覚障害をお持ちの方は生活していく上で他の感覚器官によって情報を得ていますので、音に関する情報を非常に精密に扱うことができます。
全身赤い服の人を見て、自己主張の激しい人だなと思うことは出来ないですが、声のトーンの細かい変化や言葉の選び方で相手の情報を得ることができるでしょう。
この特性を活用しようというのが今回の取り組みです。
アーネストキャリアは特に「自閉症スペクトラム障害」という特性を持っている人材に目を付けました。
自閉症スペクトラム症とは、脳の一部の異常などによって社会性が伴わない、コミュニケーションがうまく取れない、想像力の欠如のような症状が現れる障害です。
RPAのシナリオ設定において、業務の標準化なども勿論大切ですが、シナリオ自体をあいまいに設定してしまうとうまくいきません。
そのような側面で見えれば、あいまいなことが苦手である自閉症スペクトラム障害者と高い親和性があります。
さらに、自閉症スペクトラム障害をお持ちの方の中には、自分では自覚していないケースもあるようで、アーネストキャリアではそのような人材の発掘と正当な評価を得られるシステム作りを課題としています。
また、日本の企業の中にはある一定数障害者を雇用する枠がある企業があり、そこに企業の利益をもたらすことができる優秀な人材として雇用してもらうことを目指しているようです。
このようにターゲットを明確にした人材育成はこれからも様々なものが出ていくでしょう。
それらの先にはRPAの多くの普及、さらには人間の雇用に対する新しい形態が生まれてくるでしょう。
参考記事）発達障害者の特性を活かしたRPAエンジニアの育成プログラムを開始
