目的ごとにツールを分ける エラー対応しやすい構成を自ら考えRPAの開発に挑むディップのインターンエンジニア
dip Roboticsの取り組みを紹介するシリーズの第一弾です。
dip Roboticsはディップのデジタル改革専門組織です。その組織内にRPAチームがあり、ディップ社内外の業務の自動化に日夜取り組んでいます。
ディップでは社員入社時の各種データ登録はほとんどが手作業だったため、ヒューマンエラーにより生じるデータの齟齬や反映のタイムラグによってトラブルが多発し、対応に時間がかかっていました。そこでRPAを導入し自動化することでヒューマンエラーをなくす施策をdip Roboticsが行うことになりました。複雑なプロセスの自動化にあたり、ツールを目的ごとに分けることでトラブル発生時の対応のしやすさも両立したようです。
今回そのプロジェクトを担当したdip Roboticsインターンの新田に話を聞きました。
新田比呂志 プロフィール
商品開発本部 次世代事業統括部 dip Robotics Biz dev課 インターン
(※掲載当時の部署です)RPA推進チーム内の進捗管理やコードおよび資料のレビュー、既存RPAの改修や新規RPAのフルスタック開発
手作業によるエラーでトラブルが頻発していた
――取り組み前の状況、運用方法を教えてください。
社員は入社後に各種連携サービスを使用することができますが、入社データの各種サービスへの登録は手作業であり、反映のラグやヒューマンエラーにより、入社後にサービスが使用できないトラブルが頻発していました。
――どのような課題をお持ちでしたか。
このトラブルの原因を探っていくと課題は大きく分けて2つ見つかりました。
1つ目は各サービスで必要としている入社データの中身や、データの形式、アップロード方式が異なっていたこと。
2つ目は全体をカバーするには1つのRPAツールの実装だけでは不可能だったということでした。
――システム導入検討の経緯について教えてください。
入社データが正しく登録されないだけでなく、トラブル対応にも工数がかかるため悪循環になっており、業務改善のプロジェクトが発足しました。
目的ごとにツールを分け、組み合わせることでエラー対応のしやすい自動化を実現
――どのような施策を選びましたか。
一つの目的に特化した複数のRPAツールを組み合わせてシステムを構築しました。
例えばデータの加工を行うツールと、アップロードを行うツールは別にするなどしています。
――その施策のポイントになったところはどこですか。
この施策の大きな特徴はエラー対応がしやすいところだと思います。部分ごとにそれぞれのシステムの保守が必要になるものの、一方で例えばアップロード部分だけが障害で止まってしまっても、データ自体は完成しているので手動での対応が可能です。
開発は1人でもチームの手厚いサポートがあり開発に集中できた
――どのような体制で取り組みましたか。
メインのフロントや開発は私1人で行いました。大きいプロジェクトであったため、他部署との連携が必要なことが多くあり、その際にはチームリーダーにつないでもらって進行しました。
また、レビューの際にはチーム全体でアドバイスをもらい、改善しながら進めました。
――プロジェクト推進体制や環境のよかった点について教えてください。
他部署との連携が必要になった際にチームリーダーから連絡をつないでもらうのが早かったところが非常に助かりました。
そのおかげでメインのデータの整理や開発に集中することができました。
――本取り組みで困難だったことについて教えて下さい。
主に2点です。
1つ目は先にも述べましたデータの整理です。各サービスで参照しているファイルが異なると、どこに基準を置くかといったことを決定しなければなりませんでした。同時にデータの連続性など既存のシステムの理解をしながら要件を満たす必要がありました。
2つ目は環境の構築です。過去に例がないRPAツールの構成や利用方法だったため、意図しないトラブルやエラーが頻発しました。
――どのように問題解決しましたか。
データの整理に関しては、何度も担当者の方とデータ形式や出力、定義のすり合わせを行いながら一個一個解決していきました。
そして環境構築の方の課題は、まずチーム内で解決できるか意見をもらい、解決しない場合は知見を持っていそうな関連チームにアドバイスをいただきながら解決していきました。
エラー対応しやすいシステムの開発に成功。狙い通りの効果をあげた
――現在の運用を教えてください。どのような利用方法をしていますか。
定期的にデータを自動で登録するように設定して運用しています。
――どのように課題が解決されましたか。
定期的に正しいデータがサービスに登録されるようになりました
また万が一エラーが起きても、ヒューマンエラーの原因で最も工数のかかる部分だったデータ加工の部分は安定して動いているので、エラー対応の工数は少なくなっています。
――導入してよかったと思う点や今回のプロジェクトのやりがいだった点を教えてください。
ボトルネックであったデータの定型的な加工や抽出が自動化されたところが、メインの導入メリットとして挙げられます。
プロジェクトとして面白かったのは、データをまとめるところや、データについてのロジックを考えているときでした。
――運用上で生じている課題などはありますか。
システムの中で1か所だけ連携がうまくいかないところがあります。原因は明確ですが解決できていません。
これは導入時に検討を重ねましたが、すぐに導入できる回避策がなかったため改善のタスクとして残っています。
システムを切り出し他の場所での業務効率化に応用していきたい
――今後取り組みたい改善はありますか。
2つあります。
1つは改善のタスクとして先述した連携がうまくいかない箇所です。回避策の候補があるので、問題がないことを確認して提案しようと思っています。
2つ目は今回のシステムを部分的に使用して、他のRPAとして推進することです。
――RPAチームの中で今後取り組んでいきたいことはありますか。
開発をいくつか経てナレッジが蓄積してきたので、どの部署の方でも作成できるように、RPAツールの体系的な使い方や、開発の進め方、複雑な業務でも保守しやすいRPAとして開発する方法などを資料としてまとめていきたいです。
ありがとうございました!