200名超のユーザーが参加、みずほ情報総研やメットライフ生命のRPA担当者によるLTも

RPAユーザーが再び金曜夜に大集合！RPA Community勉強会Vol4

2018年09月07日 08時00分更新

文● 大塚昭彦／TECH.ASCII.jp

　2018年8月10日夜、RPAユーザー主体の勉強会「RPA勉強＆LT会！RPALT vol4 with Tech Night！」が東京・汐留で開催された。

東京・汐留のソフトバンクセミナールームで開催された「RPA勉強＆LT会！RPALT vol4 with Tech Night！」

　4回目の今回は、RPA Communityとエンジニア向け勉強会「Tech Night @Shiodome」による共催となり、用意していたセミナールームが200名を超える参加者であふれたため“サテライト会場”まで設けられるほどの盛況ぶりだった。その模様をダイジェストでお届けしよう。

「自分に合ったやり方」を見つけるためのコミュニティ

　前回記事でも紹介したとおり、RPA CommunityはRPAに興味のある／RPAを学ぶ／RPAを活用するユーザーを主体としたコミュニティだ。Connpass上のメンバー数は本稿執筆時点で970名を超えており、おそらくは日本最大のユーザーRPAコミュニティとなっている。

　RPA Communityは、特定ベンダーのRPAツールについて学ぶ集まりではない。実際にRPA導入に取り組んでいるユーザー自身が、そこで得たノウハウやアイデア、悩み、意見などを共有し、参加者一人ひとりが「自分に合ったやり方」を見つけていくためのコミュニティである。「最善の手段はRPAではないかもしれない、最終目的は『RPA化』ではない」というスタンスも、前回ご紹介したとおりだ。

　冒頭の挨拶に立った運営メンバーのMitzさんは、前回の参加者アンケートから「RPAとプログラミング」に対する意識調査結果を取り上げた。RPAツールを使う（RPAのロボットを開発する）ためにプログラミングのスキルが必須かどうか、また今後もそれは変わらないかどうか、意見は参加者間で大きく分かれているという。しかしRPAの取り組みをきっかけとして、プログラミングのスキルがない人も「プログラミングを学んでみよう」と考えることはできるのではないか、それは“ものづくり”にも通じる「楽しいこと」なのではないか、というのがMitzさんの見方だ。

司会の“チャラ電Mitz”ことMitz（ミッツ）さん

初めての試みとしてYouTube Liveによる中継も行われた

　もうひとつ、MitzさんはASCII.jpから1本のニュース記事を取り上げた。IDC Japanによる「働き方改革関連ICTツール」の利用動向調査で、従業員が今後も使いたいツールとして挙げた1位は「ノートPCに接続するPCディスプレイ」、2位は「ビジネスチャット」だったという記事だ。この調査結果からMitzさんは、業務改善や働き方改革につながる方策を、RPAにこだわることなく広い目線で見る意識を常に持っていてほしい、と語った。

RPA導入後の稼働安定化、社内定着を支える「RMO」チームとは

　セミナーセッションで登壇した一戸寿哉さんは、毎回恒例となっているシリーズものの「10分間 RPA概論」最新編として「運用・保守編」を披露した。

RPAコンサルタントの一戸寿哉さん。豊富なRPA実務経験の中から得た気づきを共有

　大規模／全社的なRPA導入を推進する組織においては、従来のシステムコンサルチームや開発チーム、インフラチームに加えて、新たに「RMO」と呼ばれるチームの設置が提唱されているという。RMOとは「Robotic Management Office（ロボット管理組織）」の略で、RPA開発／導入を支援するだけでなく、運用や保守、基盤提供、利用分析といった導入後の各フェーズで「導入後の稼働安定化」や「社内定着化」を推進する役割も担う。

RPAの社内展開を促すRMO（ロボット管理組織）。KPMGコンサルティングなどが提唱している

　一戸さんは、この各フェーズにおいてRMO（またはそれに準ずるチーム／担当者）が行うべき業務を紹介していった。たとえば「運用」においては、ロボット開発スケジュールの調整のほか、RPAを実行するための新しいPCやライセンスの調達といった「資源管理」、社内ユーザーからの問い合わせ対応やロボット実行時のエラー監視、障害管理などの「利用促進」といった業務も必要だという。

　「ほかの業務システムと同じで、RPAも『作ったら終わり』ではなく、どうやってユーザーに使ってもらうかを考えなくてはいけません」（一戸さん）。実際に、ロボットをリリースしても、なかなか使ってくれないユーザーもいるという。1カ月ほどの試用期間を設けてユーザーの意見をしっかり聞き、仕様の齟齬や使いにくい部分を改善していく必要がある。さらに、どうしてもユーザー部門で使ってもらえない場合には「完全に自動化できる業務ならば、いっそ業務ごとRMOで巻き取ってしまうことも視野に入れて考えるとよいと思います」（一戸さん）。

社内へのRPAリリース後の“あるある”。ユーザーに使ってもらうための取り組みも重要だ

　「保守」に関しては、ロボット実行時のエラー発生率をKPIとして、障害対応とエラー改善に努める。開発チームが新規案件の開発に注力できるように、RMOが主となって改善に当たるのがベターだ。なお、エラーの原因にはさまざまなものがあるが、システムエラーとユーザーに起因するエラー（ユーザーが入力ファイルの使い方を間違えた、など）がエラーログ上で区別できるように例外処理を実装しておくと、改善作業の際に役立つという。

　開発／保守／運用業務をスムーズに回すための「基盤」づくりでは、開発標準を定めるとともに、台帳管理やチケット管理などのツール、サンプルやテンプレートなどのナレッジを共有する。また、外部システム連携など新たなチャレンジとなる案件は、RMOが中心となってPOCを実施しノウハウを蓄積する。

　RPA展開が大規模なものになると、利用状況の「分析」も重要な業務となる。どのロボットが、どの部署で使われているのか、またどのくらい使われている（いない）のか、エラーがどのくらい多い（少ない）のか、といったことをRMOが一元的に把握し、それに応じてロボットの改修やライセンス撤去といった対応を行う。このとき、BIツールなどで自動的にレポートが生成されるようにすると便利だと、一戸さんはアドバイスした。

セミナーセッションとしてもう一人、ブルーフィールド代表の青野正道さんも登壇。RPAを適用する業務の選定ポイントからツール選定、「UiPath」を使った簡単なロボットの作成手順などを紹介した

ボトムアップで開発するRPAは「現場の要望に応えることが楽しい」

　1人5分間のLT（ライトニングトーク）パートには合計で9名が登壇した。

　メットライフ生命で“ロボット・エンジニア”を務めるみやともひでさんは「今日は『めちゃ楽しい』働き方の話をシェアします」と宣言して、LTをスタートした。みやさんは4～5年前からRPAのPOCやパイロット導入を手がけており、現在は生命保険の契約管理業務において、RPA（BluePrism）の本格導入に取り組んでいる。

メットライフ生命のみやともひでさん。これまでRPAだけでなくPepperのエンジニアリングを手がけた経験もあり、肩書きは“ロボット・エンジニア”

　みやさんはRPAについてよく指摘される弱点、たとえば「社内方針の変更やシステム改修に弱い」「既存業務を見直したほうが早い」「自動化できているようでできていない」といったものは、実はこれまで現場の業務担当者が感じていた苦痛そのものではないか、と指摘する。業務プロセスの変更やシステム開発が、経営層やマネージャー層の意向に基づいてトップダウンで行われる結果、現場の実情にマッチしない“不可解なアウトプット”がなされ、結局は現場担当者が苦労するというおなじみのストーリーだ。

　「一方で、RPAの場合は現場からのボトムアップであり、だからこそ業務担当者にとっていちばんいいものが作れる。これがめちゃくちゃ面白いと思っています」（みやさん）

RPAはボトムアップで「担当者層にとって良いもの」が開発できるので面白い、とみやさん

　みやさんは「現場の要望に応えることが楽しい」と語り、どんなささいな要望でもなるべく対応していると語る。たとえば「レポートの色や罫線をきれいにする」「Excelのマクロ実行を自動化する」といった、本来はRPAでカバーしなくてもよいような要望、あるいは繰り返される仕様変更／追加の要望にも、嫌がらず積極的に対応しているそうだ。「こうした対応を続けているうちに、業務担当者から『みやさん心強いです』と言われて嬉しかった」（みやさん）。

　ほかの業務システム開発と同じように、RPA開発においても現場担当者との意識の食い違いから、現場ニーズに合っていないものができてしまうことはやはりある。ただ、RPAの仕様追加／変更は小さなものがほとんどであり、対応も比較的簡単で要望に応えやすいものが多い。だからこそ、現場との密な連携を通じて「爆速で」実装とミスを繰り返し、改善を重ねていくべきだとみやさんは語った。