RPAを導入する企業が増える中で、「RPAを導入することになったけど、これから作るロボをどうやって管理すればよいのか？」企業のRPA担当の方が悩むポイントだと思います。悩むポイントである一方、なかなかロボをどう管理するか？といった点について語っている人が少ないのが現状です。
そこで今回は、「RPAロボットの管理・統制の仕方」というテーマで、ニコニコ動画で有名な株式会社ドワンゴの情報システム部でRPA導入推進チームのリーダーをされている鰐渕智宣さんにお話を聞きました。
鰐渕さんは会計士のキャリアもお持ちであり現在ドワンゴでロボット作成をする傍ら、RPAに関するさまざまなルール整備をされています。また、情シス部員のRPA導入日記というブログで、ロボの管理の仕方について積極的に発信されています！
鰐渕さんのtwitterフォローはこちら→Follow @twanifuchi
RPA導入×システム統制のスペシャリスト
ーーまずは最初に鰐渕さんのこれまでのキャリアについて教えてください。
私は学生のときに会計士試験に受かり1社目で監査法人に入社しました。そして３年程度、会計士として会計監査や内部統制監査、IT統制監査などをやっていました。そのあとニコニコ動画が大好きで、ニコニコ動画に関わりたい！との思いから株式会社ドワンゴに転職しました。最初は会計士の経験を活かして経理部にて開示資料を作ったり法人税関連の業務をやったりしていました。経理部にて3年半経験をしたあと情報システム部に異動し、会計システムをリプレイスするプロジェクトのシステムチームのリーダーなどをやったのち、現在はRPAに携わっています。
ーーとても良い意味でユニークなキャリアですね。RPA導入に携わりはじめた頃のこと、詳しく教えてください。
RPAを導入しようと考えているというタイミングで声がかかったのが1年ちょっと前です。経理BPRという業務改善プロジェクトの中で、「RPAを使おう！」というプロジェクトでした。このプロジェクトでは監査法人にコンサルとして入ってもらい、RPAの導入ノウハウなどを教えてもらいながら進めました。
私個人の思いとしては、効果も出したいけど将来の負債になるようなシステム導入にはしたくなかったので、RPA導入する際のルール整備をしていきました。
ーー熱いですね！最初からルール整備に意識が向いていたのはなぜなのでしょうか？
私が会計士としてのバックグラウンドがあったからだと思います。会計士はしっかりとルールを作って、そのルール通りに運用することを、特に大切にする職種なんですよね。
もちろん情シス畑の人もルール遵守を大切にしますが、それ以外にも技術的な効率性などを重要視する傾向があると思うので、純粋な情シス畑の人とは、私は少し違った感性を持っているのかなと思います。
情シス部員のRPA導入日記（鰐渕さんのノウハウがつまっている）
ロボの管理・統制で出てくる問題
ーーロボの管理・統制でよく出てくる問題は何なのでしょうか？
よく言われているのは野良ロボという問題です。現場が勝手にロボットを作っていてその後作った社員が異動や退職をしてしまった場合には、ロボットが止まってしまった時に直せなかったり、仕様変更をしたくても出来なかったりという問題があります。また、野良ロボでなくて情シスで作ったものであっても、正しく変更管理を行わず場当たり的にリリースをしていくとうまく動かなくなる可能性があります。そのため、適切にロボを運用管理していく必要がありますが、ちゃんとした管理をしようとすると手間がかかりすぎてしまい手軽に導入できるロボの良さが死んでしまう。その辺りのバランスをとりながら必要最低限の管理をするというのが大切だと考えています。
ルールを作る際の考え方
ーー管理ルールを作るときに意識したほうが良いポイントはありますか。
既存のIT統制の仕組みがあるところへ、RPAのような新しいものを導入しようとして、RPAに対しても既存の仕組みと同様のものを適用してしまうと大変になりすぎる可能性があります。しかし、だからといって既存のものとは別の新しいルールを作ってしまうとダブルスタンダードになり、運用が複雑となる可能性もあります。そこで、大切なのは既存の仕組みの中において、RPAを正しく整理して位置づけてあげることだと思います。また、これを行うことは既存のルールを更に良いものに変えられる契機になるのでは？と考えています。
ーー既存の仕組みの中でRPAを整理して位置づける…なるほど。ドワンゴさんでは具体的にどのような整理位置づけをしたのでしょうか？
ドワンゴでいえば、RPA以外のシステムは初回リリースのときには計画書、要件定義書、テスト結果、リリース許可という４つのワークフローの承認を必要としています。システム変更のときにも要件定義書、テスト結果、リリース許可という３つを必要としています。厳格にこの流れをRPAに適用すると、RPAは修正リリースを行うことが多いので、とても大変になってしまいます。そこで簡単にリリースできるひとつの区分けを作ることにしました。軽微な変更のリリース案件（変更、バグ修正など）については、テストなどは裏で行いつつもワークフローを１本あげるだけで、その日中、あるいは翌日にはリリースできるといった手続きを簡素化する統制の仕組みを作りました。良かったことはこのルールはRPAに対してだけでなく、既存の他のシステムにも適用していて、軽微な変更を簡易に済ませられるようになり、統制レベルを下げずに手続を簡素化することができました。
またバージョンという考え方が重要で、当社のバージョンはメジャーバージョン、バージョン、リビジョンという３つの区分けにしています。今まではシステム変更する際には、どのような変更でも真ん中のバージョンあげるという対応をしていて、その際に３点セット（要件定義書、テスト結果、リリース許可）が必要となっていました。リビジョンはほとんど使われていなかったのです。このリビジョンの概念を運用していこうと会社のルールを整備し、リビジョンアップをバグ修正などの簡単な修正で使うようにしたら、リリースのスピードが上がるなどメリットがありました。
バージョン管理（情シス部員のRPA導入日記より）
ーーとはいえ、RPAの管理ルールを決める前に会社によってはえいやー！でRPA導入してしまうというケースもありますよね？
たしかにそうですね。上場企業だと内部統制の仕組みのなかにＩＴ統制の仕組みがあるので、そのルールを逸脱しないようにルールを決めるというのが大前提であり、最低限守るべきポイントです。ただ繰り返しになりますがRPAの特色を加味して手間にならないように簡素化していくことが大切です。「気軽に早くRPAいれちゃいたい！」という会社であれば、ルールは後回しにして導入スピードを優先するケースもあると思いますが、ルールを決めないまま拡大していくのは危険だと思います。RPAの導入拡大を急ぎたい場合でも、最低限必要な部署とのコミュニケーションをとりながら進めていくべきでしょう。各会社の中でルールを統制している部署、例えば内部監査室や内部統制部などがあり、そういう人たちと適切にコミュニケーションを取りながら、必要な統制レベルを担保しつつも、面倒になりすぎないようなルールを決めていくことが大切です。
ドキュメントはルールだから作るではなく、意義があるから作る！
ーー管理するにあたりどういったドキュメントを作っているのでしょうか？
ロボを作るにあたり、各フェイズ（要求定義、要件定義、開発、テスト、リリースなど）や必要となるワークフローにおいて、何のドキュメントを作成・添付すべきかをよく考えましたね。作ったロボの仕様があとになって分からないなどの問題が起こらないように、ロボを作成する際にはどんなドキュメントを用意するかをまとめたドキュメント一覧というものを最初に作りました。ドキュメント作成は面倒臭くなりがちなので、最小限の必要なドキュメントのみを作るということを意識しました。
ドキュメントとしては、主なものとしてロボ一覧、ロボバージョン一覧、ロボ概要図、業務フロー図、ロボI/O表、開発標準、エラー一覧、開発TIPSを作っています。
ーーとてもしっかりと作っている印象です。
どのようなドキュメントを作ろうか考えたときにはコンサルで入っていた監査法人にも助言を受けながら進めました。他社の事例なども紹介してもらいましたが、とてもしっかりとドキュメントを作っている会社の事例であったりして、とてもじゃないけどドワンゴのような少人数の導入チームで運用できるようなものではなかったので、頂いた事例から作成ドキュメントを大胆に削ったりして、自分たちにあったルールに作り上げました。
ーードキュメントを作るメリットはどんなところですか？
必ず作ろうというドキュメントは、ルールだから作るではなく、作る意義があるから作る、本当に必要なものだけ作るようにしています。そのなかでもロボ概要図はかなり作ってよかったなと思うドキュメントです。
ロボが真ん中にいてロボへのインプット/アウトプットを矢印で表現するビジュアルです（以下の図）。分かりやすいと好評で、ユーザーとのコミュニケーションが円滑に進むようになり、業務フロー図も作りやすくなりました。また他の部署にRPAを新たに展開するときにも、このドキュメントは説明しやすく使いやすいのでおすすめです。
ロボ概要図（情シス部員のRPA導入日記より）
ーーとても勉強になりました！ありがとうございました！ぜひ次回は別のテーマでお話いただければと思います！
まとめ
鰐渕さんのお話になったように、既存のシステム開発と比較するとRPAはスピーディーに開発できるメリットがあるものの、既存のシステム開発と同様の管理をしていくとRPA本来の良さを殺してしまう可能性があります。
そんな中で、ダブルスタンダードのルールを作るのではなく、既存のルールの中で整理位置づけをするという考え方は、皆さんの会社でも参考になるのではないでしょうか。
鰐渕さんのノウハウは、おしげもなくブログで公開されていますので、ぜひこちらも見てみてください！
コメントを残す