DeNAのRPA運用方法

“永久ベンチャー”DeNAの社内リソース100%RPA運用ノウハウを完全公開!!

DeNAのRPA運用方法

最先端の文化を発信する渋谷の街の中心、渋谷ヒカリエにオフィスを構える株式会社DeNAは、今年で創業20周年を迎える。

EC事業からスタートしたDeNAは、主力とするゲーム事業を中心に、Eコマース・エンタメ・オートモーティブ・ヘルスケアなど幅広く事業を展開しているインターネット企業。

DeNAベイスターズというプロ野球チームでスポーツ事業も行なっているのは周知の通りだろう。

「インターネットやAIを活用し、永久ベンチャーとして世の中にデライトを届ける」というビジョンを掲げ、事業だけでなく社内でも常に新しい技術を取り入れてきた。

そうした中で、RPAの導入が決まったのだが、DeNAのRPA運用の特徴は、100%社内リソースで導入・運用を行なっているという点だろう。

普通だとコンサルを入れて進めるものだが、どうして自社のリソースだけで運用を進めることができたのか__

稀代のインターネット企業が独自開発した、RPA運用ノウハウや100%社内導入に至った理由を聞いた。

インタビュイーのお二人

DeNAのRPA推進部のお二人

大脇 智洋

経営企画本部企画統括部 IT戦略部部長。
新卒でSIerに入社し、商社や通信企業のシステム開発・運用などのプロジェクトに従事。
2006年より会計系コンサルファームにて、JSOX導入、IFRS導入、業務改革などのプロジェクトに従事。
2012年よりDeNA IT戦略部に参画。
グローバルでの経営管理基盤の統一プロジェクトに参画した後、「Slack」の全社展開や「RPA」を活用した業務改善のプロジェクトなどに従事。

原 隆幸

経営企画本部企画統括部IT戦略部業務改革推進グループ
新卒で都市銀行に入社し、海外部門の対顧客通知配信システム開発や運用などのプロジェクトに従事。
2016年より、会計コンサルティング会社にて、ITガバナンス強化や社外システムセキュリティ強化のプロイジェクトに従事。
2018年よりDeNA IT戦略部に参画した後、「RPA」を活用した業務改善のプロジェクトなどに従事。

主人公はIT戦略部

DeNAのRPA運用方法ー主人公はIT戦略部

——現在のRPA運用状況を教えてください

対象業務のところでいうと、自部署であるIT戦略部と人事領域の業務、経理などコーポレートの部署に適用していっています。

総削減時間帯は、現状としては年換算で4118時間となっております。

随時ロボットは増えていますので、あくまでも現状の数字という形で理解していただければと思います。

——推進チームの体制は?

RPAプロジェクトのトータルの人数としては、8名です。

このプロジェクトには、企画・開発・PMOという3つの役割があります。

企画チームが、ユーザー部門と連携しながら要件定義やユーザー部門のサポートを行い、開発チームでロボットを開発、PMOが成果物のレビューなどを行なってプロジェクト全体を統括するという形ですね。

基本開発を専門としている社員が現在3名ですが、企画の人がロボットを作ることもあります。

こうした形で作られたロボットが全部で19台動いております。

ロボット化する対象業務はコーポレート部門などを中心に部門単位でRPAに向いている定形業務を調査して選定していきました。

また、社内のヘルプデスクに業務改善の相談が寄せられるケースもあるので、そういった相談の中からもロボット化を進めている形です。

また、RPAプロジェクトの全メンバーはIT戦略部の別の業務と兼務しています。

つまり、会計システムの運用やユーザーのサポートなどRPA以外の業務も同時並行で行っているという状況です。

——お問い合わせがあるということは、社内でRPAが認識されている?

ある程度認識はされてきていると思っています。

こういったメディア等でも取り上げていただくこともあり、RPAのご相談やお問い合わせをヘルプデスクに頂いてます。

SaaS型のRobotic Crowdを導入した時にも、社内に説明会を開催する旨のアナウンスを出しているので、一定の知名度を獲得できていると思います。

実際にヒアリングしてみると、事業部では結構細かに業務が分かれていて、イレギュラー対応が多くなってしまうような少量多品種業務であることが多く、プロジェクト主導で工数をかけてロボット開発しても効果が小さくペイしないケースもあります。

そういったケースでは、Robotic CrowdやKintone等のツールを利用して、エンドユーザ自身が業務を効率化しています。

運用ルールは試行錯誤を経て

DeNAのRPA運用方法

——RPAを使うに至ったプロセスを教えてください

2016年の後半からRPAが国内でも話題になりはじめまたので、弊社としても注目しており、2017年から本格的な調査を始めました。

基本的には、メジャーなツールを中心に調査を進め、WinActorとBizRobo!のPoCを行いました。

しかしながら、当時のWinActorはクライアントアプリであるが故にロボットの一元管理が難しいこと・BizRobo!は社内のWEBアプリケーションで動かせないものがあったという点で難しいと判断することになりまして。

さてどうするかと悩んでいたところで、Blue Prismだと上記二点を解決できるということが判明し、PoCをしたところ問題がなかったので、導入するに至りました。

PoCにはそれぞれ1〜2週間しかかけていないので、全体として一ヶ月程度でツールの導入まで完了しましたね。

実際、Blue Prismはログ管理の部分や、細かな権限設定などエンタープライズ向けの機能が豊富で助かっています。

——導入後は、どのように進めていったのか

一度導入した後は、スモールスタートということで、IT戦略部内の業務をRPA化するところからはじめました。

RPA化する業務の選定は全社展開でのフローと同じであり、全体として2ヶ月間くらいだったと思います。

この中で主眼においたのは、試行錯誤をしながら、開発の標準ルールなどをRPAプロジェクト方針として取りまとめること。

これを固めてから他部署に展開する形を取りました。

作成したRPAプロジェクト方針は二部構成になっていて、第1部はロボット化する対象業務選定の進め方やRPA導入可否判断の基準、RPA以外の選択肢などを定めたRPAプロジェクトの進め方のルール。

第2部は開発標準ルールを定義したもの。変数の書き方や名前の付け方、開発した成果物のレビューチェックシートなどを定め、操作対象の変化に強いロボット作りのための開発マニュアルを作っていきました。

全部で70〜80ページになりますね。

定量ベースで自動化可否判断

——他部署への展開はどのように進めたのですか?

基本的には、バックオフィス業務からスタートしました。

まずは、RPAの動画を現場の社員に見せて、どんなことができるのか具体的にイメージしてもらい、対象となりそうな業務を調査票に書いてもらってリストアップします。

そしてこの後、リストアップされたものの優先順位付けを行う形です。

調査票では、業務内容や利用システム、現状どれくらいの作業工数がかかっているのか、業務の変更頻度などを聞いています。

この時見る観点としては、ロボット開発の難易度とロボットの長期使用可能性、そしてどれくらいの工数を削減できるのかという3点です。

つまり、例外の多い処理や扱うアプリケーションなどが多くロボット開発が難しいかどうかや、業務フローの頻繁な変更や操作対象となるアプリケーションやサイトの変更頻度などから総合的に判断して、そのロボットが長く使い続けられるのか、という点を見ています。

工数削減効果だけで見るとロボットを作る側の工数が見落とされがちなので、開発難易度や長期使用可能性は重視していますね。

また、大した効果がない業務を開発して要件定義するのは無駄なので、ロボット化するしないの基準を定量的にしっかりと持っています

具体的には、平均するとロボットを一台作るのに45時間かかってしまうので、これを一年間で回収できるかどうかという部分ですね。

月に3.5時間くらいの削減効果がないとそもそも着手する必要がないという判断を下しますね。

どうして一年間でなのかいうと、一年以上経つと業務が変わってきてしまうので、ある程度見えている範囲でかけた開発工数を回収できないといけないよねという考え方がベースにありますね。

このように、RPAの対象業務を、ヒアリングを重ねることで優先順位付けし、より重要度の高いものからRPA化することで、効率的な運用を行うことができています。

現状と理想〜As-IS&To-Be〜

DeNAのRPA推進方法ーインタビュー

——どのようなフローで開発を進めるのですか?

As-Isの分析とTo-Beを定義してから開発します。

As-Isは、現状の業務をヒアリングや業務マニュアル等を入手することによって理解し、どこにロボットを組み込んでいくのかユーザーと一緒にしっかりと議論すること。

ここでは、例外処理なども含めて業務をフローチャートとして可視化することが大事です。

そして、エラーが起きた場合、代わりに人間が業務を代行する仕組みを整えておくのも大事です。

そして、自動化した後の業務フローがどうなるのかがTo-Be。

ただ、このTo-Beに関しては、RPAを使うことにこだわっている訳ではないです。

例えば、会計システムからCSVファイルをダウンロードして帳票作成する業務のロボット化の相談がありました。この場合は既存システムにアドオンレポート機能を開発して解決しました。

業務の内容と自分たちの持つソリューションを総合的に判断して、業務自動化を行っている形です。

事業部のユーザー部門で立ち上げた場合、RPA以外のソリューションを持っていないので、RPAを使わずに業務自動化を行えないですが、DeNAではIT戦略部が中心だから、RPA以外のソリューションを多数持っているというのは強みです。

一般的にRPAプロジェクトは非ITの業務部門が中心となって立ち上げるケースもあると思います。

ITの専門家でない方の場合はRPA以外のソリューションを持っていないので、RPAを使わずに業務自動化を行えないですが、DeNAではIT戦略部のITを活用した業務改善のプロが中心となってプロジェクトが組成されており、RPA以外にも提案できるソリューションを多数持っているというのは強みです。

RPAは業務自動化を検討する上できっかけに過ぎないのだという認識ですね。

実際、ロボット化の相談が来た場合、4割くらいRPA以外のソリューションを提案しています。

その一例としてあげられるのは、セキュリティカードのエラー対応ですね。

DeNAでは共連れ防止の為アンチパスバックという方式を採用しており、セキュリティカードを入室時と退室時にかざす必要があります。そのため、意図せずカードがエラーになることがあります。

以前はエラーになるとヘルプデスクのある部屋に行ってエラーを解除してもらう必要がありました。

そこで、これに対する解決策として、2017年に導入したSlackを使ったんですね。

つまり、エラーが起きたユーザーがSlackでメンションをつけてヘルプデスクのエラー解除担当を呼び出すことで解除してもらうというフローにしたんです。

これが好評だったんですが、その裏で、総務の社員の方がメンションされたらその時の業務を中断して入退室管理システムにログインし、エラー解除ボタンを押すという業務の負荷がかなり高いという状態になっていて。

これをRPAで解決できませんか?という依頼がIT戦略部に舞い込んできたんです。

しかし、これをRPAでやろうとすると、24時間Slackを見張ってなくてはいけないため、RPAのマシンのライセンスを丸々一個使ってしまうというところがコストが高いという判断になって。

ここで、内製の自動化ロボットを開発して、RPAを使わずに自動化したりという事例もありました。

他にもエクセルでの作業なら、マクロやxoBlosというエクセル特化の作業効率化ツールで対応したりといった例もありますね。

ノウハウは社内に、徹底した内製主義

DeNAのRPA運用方法-外注しないカルチャー

——コンサルを入れない意思決定をしたのはなぜ?

元々DeNAに、コンサルタントを入れるという発想がないんですよね。

自分たちで考えるというカルチャーがあるんです。

実際、コンサルを入れるメリットとして、導入体制のベストプラクティスや開発標準・マニュアルなどを提供してくれるということがあげられると思うんですが、これを自分たちで考えて内製できるなら必要ないのではってなりますよね。

それと、失敗できる環境、すなわち試行錯誤ができる環境があったのも大きな理由でした。

申し上げた通り、IT戦略部内で色々と試して開発ルールを作り込んでいったんで。

このようにツール導入に際して、PDCAを回せる人材・環境が揃っていたので、100%社内リソースでRPAを導入できたんですよね。

——なぜそのような考え方を持つように?

そもそも外注しないという文化が創業時からあります。

弊社はEC事業から創業していったんですが、その最初のECサイトのシステム開発を外注したところ、リリース一週間前になっても全然できていなかったという経験があるんです。

その時夜を徹して開発を行うことで、なんとかリリース日に間に合わせたのですが、これがかなり教訓になっていて。

事業の重要な部分に関しては、内部でノウハウをしっかりと作ってやっていこう、自分たちでしっかりと考えてやっていこうというカルチャーが強いんですよ。

外注してしまうと、ノウハウが向こうにあるままだから、自社にノウハウが蓄積していかないですからね。

——ノウハウを自社に貯めることが重要なんですね

実際、RPA以外のシステム開発も内部のメンバーでできるんで、一番ベストな選択肢を選べるんです。

そうしたシステム開発のノウハウがないと、アドオン開発がベストなソリューションだったとしても、外注で数百万円の追加的コストがかかってしまうから、なんとかRPAで間に合わせようという発想になってしまう。

自社にノウハウがあるからこそ、ベストソリューションを選ぶことができるんですよね。

社員に浸透する本質思考

——その他にあげられるもので、コンサルを使わない優位性とは何か?

コンサルに頼ってしまうと、離れられなくなるっていうのは聞きますよね。

さらに、コンサルタントからもらったルールだと、担当者によってはしっかり読み込むことなく使ってしまい、形骸化したルールができてしまうこともありますが、自社でしたらそういったことは無くなります。

要らなくなったら自分たちでルールを削除して、という柔軟さは強みですね。

あともちろんコストがかからないという点ですよね。

他社さんだと、こうした開発ルール自体や、それを作る時間をお金で買っているというイメージだと思います。

実際弊社でも2ヶ月くらいかかったので。

——コンサルという第三者が入ることで、RPAへの反発を抑えられるという効果については

そもそも反発がないです(笑)

むしろやってくれという声しかないですね。(笑)

いわゆる自分の仕事が奪われることに対する反発だと思うんですが、

「うちの業務はロボットなんかでできねぇよ」という声は一度も聞いたことがないです。

やっぱり、DeNAのミッション・ビジョンである本質的な価値を提供することに集中するという考え方が、従業員まで浸透していて。

本質的には業務時間が減った方がありがたいですからね。

やりたい仕事があるのに、時間食ってる仕事があってできない!という社員の助けになっているという実感があります。

——業務プロセスの効率化が自社だけだとうまく進まないという声もありますが

それに関しては、開発方針として、To-Beのところでロボット化をするにしても業務フローを効率化してからだという考え方があって。

例としては、IT戦略部での購買データを会計システムに入れ込むという業務があるんですが、Kintoneでの購買のワークフローにおいては人事用の部門コードを使うんですが、会計システムでは会計用の部門コードを入れなくてはいけなかったんです。

こうしたコード体系の違いをまとめるために、エクセルで変換表を作っていたんですが、ここの変換表をメンテナンスをする工数がかかっていたんです。

これをそのままRPA化すると、毎回変換表を挟むフローを開発プロセスに入れ込む必要がある上、エクセル表のメンテナンスを欠かすことができなくなってしまうので、無駄だよねってなりまして。

キントーン側に変換コードを持たせて、RPA化するという部分から業務プロセスの見直しを行なった事例はありますね。

こうした効率化をすでにやっているので、第三者が入ったからといって、こうしたプロセスがより効率化されるという思考はないです。

こうした業務フロー全体の効率化をすでにやっているので、うまく進まない、ということはないと思っています。

実際、DeNA Qualityという行動指針の中に「コトに向かう」というものがあって、これは本来成し遂げなくてはいけないコトを常に考えて行動を行おうということなんですよね。

だから誰それがこう言ってるからとか、今までずっとこうやってきたから、などの理屈が通るわけではないというのはあります。

一括管理とEUCの併用でスケールへ

DeNAのRPAーEUC

——現状ある運用上の課題を教えてください

課題としてパッと思いつくのは、2つ。

1つ目は、Blue Prismの開発ハードルが高いということですね。

Blue PrismというRPA製品に一定習熟しないとなかなか開発ができないという現状があります。

2つ目は、RPAをアドホックに、即時に動かしたいという要望があるということですね。

サーバー型で一元管理しているので、プロジェクトメンバーじゃないとロボットの即時実行ができないように設定していて。

もちろんユーザー側のサイクルをヒアリングした上で、事前に決めたスケジュールで実行しているのですが、ユーザーのニーズに応じたロボットの即時実行はできないというのが現状です。

——対策は?

1つ目に関しては、SaaS型のRPA製品であるRobotic Crowdを入れることで解決しています。

やはりBlue Prismよりは開発のハードルがいくぶん下がりますので、全社向けに説明会を行なったり、マニュアルサイトを社内に共有するということで、業務を自動化してみませんかという呼びかけを今までよりやりやすくなったというのはありますね。

RPA以外にも、Kintoneなどでも、EUCを行えるような仕組み作りを行なっています。

2つ目に関しては、SaaS型のRPAなら解決できるというのがまず1つ。

そしてBlue Prismに関しても、Slackでメッセージを送ることで、即時実行できるような仕組みを作ろうと考えていて、開発チームの中で絶賛試行中という状況です。

——仰ったBlue Prismの難しさとは?

できることの幅が広い、自由度が高い反面、選択肢が多く、設定を絞り込むのが大変だ、というところですかね。

フローチャートやパラメータ指定などの仕組みを理解するために、我々は丸五日相当の研修課題に取り組んでいますし、研修後の開発経験を積んでいるから対応できるんですが、エンドユーザーにそれを課すのも難しいので。

加えて、他のRPA製品にあるレコーディング機能がBlue Prismにはないので、エンドユーザーにとっては、なかなかとっつきにくいかもしれないですね。

オブジェクトとプロセスで2階層構造になっていて、再利用がしやすいという面で非常に合理的なんですが、その概念がエンドユーザーからすると分かりにくいというのは事実ですね。

プログラミングが必要とかそういうことではないんですがね。

——EUCを進める意思決定をしたのはなぜ?

業務調査の結果、やはり少量多品種の業務が多いよねという現状があって。

少量多品種はやりませんとしてしまうと、結局それがボリュームゾーンなので、効率化の効果が薄くなってしまう。

だからこそ、ここを救える手段を用意したかったというのが大きい理由です。

また、少量多品種の業務を、全てBlue Prismで開発するとなると、IT戦略部のリソース的に厳しいというのがあって。

こうした業務は、それをやっている人たちが自分で開発する進め方なら、業務のヒアリングをする工数はいらないし、IT戦略部での一括開発より効率的だと考えています。

開発も覚えるハードルが低いというか、比較的簡単に学べるものであれば、そんなに時間もかけずに開発ができるようになるので、コスト的にも圧倒的に優位になりますよね。

ただ、もちろんこれは野放しにするぞっていうことではなくて。

一定の守るべき権限やルールなどを定めて、決められた箱の中であとはどうぞご自由に、という形でEUCを行うこととしています。

——エラー対処などは?

EUCで開発したロボットのエラーは現場で対処してもらうようにしています。

もともと人の手でやっていた業務なので、現場ならリカバリーも簡単ですから。

もちろん、サーバー側のエラーや権限の問題など、エラーの種類によってはIT戦略部で対応すべきものもあるので、Slackでエラーの問い合わせを随時受け付けていて、必要なものはしっかりと対応するようにしています。

——使い分けの基準は?

Robotic Crowdって基本Webベースなので、 社内ネットワーク上にあるファイルやシステムを扱えないんです。

なので、社内ネットワークを使う業務なら、Blue Prismを使う俎上に載せる形になっています。

社内のデータなので、セキュリティも重視する必要がありますし。

その後、前述の業務選定の判断基準を通して、その業務を自動化するか否かを決めていくので、Blue Prismで作らない場合も、RPA以外のところを含めて考えるようにしています。

弊社はバリエーションに富んだSaaS型ツールを入れているので、何らかのツールで救えるようになっていますね。

ただ、事業部の方で大規模にEUCが動いているかというと、まだそこまでではないです。

これからEUCでの開発もスケールさせていければと思っています。

——将来的なRPAの運用像

ChatOps(※)という言葉があって。

(※編集部注:チャット系のツールと、サービスやプログラムを連携することによって業務改善を行うこと)

RPAもそこにもれず、Slack(チャット)を使って、Blue PrismでもEUC側でもチャットをより活用していきたいなと思っています。

実際、チャットになるだけでユーザーの抵抗感ってだいぶ下がるので。

オペレーションの部分をチャットに近づけていけたらなと思います。

我々としては、たくさんのソリューションを提供して、それぞれ自分の業務を自力で効率化していくというように持っていければと思っています。

本質思考で進めたRPA

RPAは、仕事を自動化して社内の生産性を上げる反面、従業員の反発・不信感など感情の面とどう折り合いをつけていくかが難しいツールだ。

しかしながら、カルチャーとして身に染みついた本質思考をする社員たちは、RPAという業務効率化ソリューションを反発なく受け入れることができる。

さらに、試行錯誤を繰り返し、仮説と結果をすり合わせながら、より良いルールを作り出していくノウハウ。

RPAを一手段と捉え、本来の目的である業務効率化のためのベストソリューションを追求していくIT戦略部の姿勢。

インターネットという競争激しい市場を勝ち残ってきた企業の、地力となっているカルチャーを目の当たりにすることができた。

彼らが作り上げた本質的なノウハウを、是非ともRPA導入・運用における参考にしてほしい。

DeNAのRPA運用方法
最新情報をチェックしよう!
>「RPATIMES」へのお問い合わせ

「RPATIMES」へのお問い合わせ

タイアップ記事を投稿してほしい。 インタビューを受けたい。 プレスリリースを送付したい。などのご意見・ご要望がありましたら、こちらまでお問い合わせください。

CTR IMG