意外と難しいロボットの追加開発のポイントについて

現在RPAを運用している中で、もっと多くのデータを処理させたい、処理が遅い部分がある等、もっとよくできるかもと感じる部分はありませんか。

今回はそういった気になる部分に対して、より効果的なロボットを新規で作成するのではなく、現在運用中の既存ロボットを利用してより効果的なロボットに進化させる追加開発に関してご紹介いたします。

1 RPAロボットの追加開発とは？
2 既存RPAロボットの追加開発が難しいと思われる理由は？
3 既存RPAロボットの追加開発を行う手順
4 既存RPAロボットの追加開発を行った事例紹介

RPAロボットの追加開発とは？

追加開発とは現行のRPAの運用をさらに良いものにするためのもの

RPAを運用していく中で、業務自体の規模が拡大して、今のロボットでは足りないと感じたり、現状の要件をクリアできなくなったりするケースがあります。

追加開発とは、そういった稼働中の既存ロボットに新たな追加要件を加えたい、大きくしていきたいと考えた場合に起こります。

例えば、さらにスピードアップして作業効率を向上させたい、より多くのデータを処理できる大規模なロボットにしていきたいなど、追加する要件については目的によって様々になります。

では、実際にどうすればその追加要件をロボットに加えていけるでしょうか。

これは既存のロボットがエラーを起こしたり、環境の更新で動かなくなったりした際に行う改修とは違います。

ですので、今あるフローの中に、新たに出てきた追加要件をどのように落とし込むかを現状の設計から見直す必要があります。

具体的にどのように進めていくのがいいか考えていきましょう。

既存RPAロボットの追加開発が難しいと思われる理由は？

追加開発の際にはロボットが抱える現状の問題点を正確に把握した上で課題へのアプローチを検討することが重要です。

自分が作成したロボットが追加開発対象とは限らない

追加開発する際には、そもそも自分が開発したロボットに対して追加開発するとは限りません。

自分で作成したロボットには当たり前ですが知見があり、追加する際にロボットの処理のどこに何を加えればいいのか、ある程度イメージできるかと思います。

しかし、これが他人の作成したロボットだとどうでしょう。

設計書とロボットの内容を見て、まず全体の仕様を理解した上で、どこに何を追加するのがベストプラクティスなのかを検討する必要があります。

なぜ全体の仕様を理解する必要があるかというと、追加開発にあたって、すでにリリース済みの現行のロボットの仕様を損ねることがあってはならないからです。

追加開発の場合は、あくまで「現行ロボットの設定に仕様を追加するもの」なので、現行の仕様に弊害が出ないように、他人が開発したロボットこそ全体の仕様を理解することが大切になります。

そのため、「自分が作成したロボットとは限らない」ことは追加開発で一番初めに乗り越えなければいけない試練といえるでしょう。

設計を見直し、追加要件をクリアできたとしても、それが元々の要件とかけ離れてしまったり、現実的な規模に見合っていなかったりするのであれば、追加ではなく、新規で開発することを考えるべきでしょう。

稼働中のロボットが対象である

稼働中のロボットはユーザー受入テストを終えて、業務ユーザーとの合意の上で既に納品されたものになります。

そのため、追加開発では稼働中のロボットが追加開発起因でエラーになってしまうことがないように、追加の設計をする必要があります。

設計の際にロジックに不安な部分はないか、入出力データや変数に不備がないか、今あるものと、これから作成するもの両方を考慮しましょう。

稼働中のロボットに影響しない追加開発をするためには、上記でも述べた通り、全体の仕様を理解して、それを設計に落とし込んでいく必要があります。

依頼する側と開発する側の課題の認識を合わせる必要がある

追加開発をするにはある程度の工数を要します。

開発する側は、
今抱えている課題の本質はどこにあるのか？
本当に考えている対応策が課題を解消、あるいは改善できるのか？

といったプロジェクトの到達点について依頼する側と認識を合わせ、追加開発の方針に合意をとる必要があります。

追加開発をする必要がそもそもあるのか、新規で開発した方がプロジェクトの到達点により近いのか、依頼する側も開発する側も、追加開発の必要性という部分を深く考えていく必要があります。

実際に、どのくらいの規模で追加開発を行うのか。
それに伴う工数や、運用に関する問題がどのくらいあるのか。
どのように進めていけばいいのか。

ここに関してご説明していきましょう。

既存RPAロボットの追加開発を行う手順

追加開発する際にも、RDLCに準じて考えていくことが重要です。

この章では、「追加開発を成功に導く手順」をご紹介したいと思います。

そこで重要になるのが、RDLCという考え方です。

RDLCとは、「RPA Development Life Cycle」といい、「RPAの自動化導入を効果的に実現するための枠組み」のことを指します。

追加開発すること際にはもちろん、新規開発でも改修でも基本概念として持っておくことが重要です。

追加要件を含めたロボット全体が、無理、無駄、ムラのない設計になっているか、改めて

RDLCを活用して見直すことで、効率的に、かつ、品質のいい追加開発を実現し、プロジェクト成功の確率を上げることができます。

RDLCは基本的に、目的や役割を持つ各フェーズで構成されています。RDLCがもたらすメリットや各フェーズの目的や役割について詳細を知りたい方は以下の記事をご参照ください。

<参照>RPA展開に必要なRDLCとは？RDLCを利用する目的と事例を紹介！

それでは早速「追加開発を成功に導く手順」をフェーズごとに紹介していきます。

課題の要件整理

追加要件によって出てきた課題を、削減時間やミッションクリティカル業務が効率化されるか、顧客満足度の向上に繋がるかなど、要件一覧の要素と照らし合わせて考えていき、追加開発のゴールを定めましょう。

スプリント計画

ここでは通常の開発とは大きく違う部分があり、As-Is業務から自動化対象範囲を検討するのではなく、すでに自動化している部分に対して考えていきます。

どこに何を追加すればより課題に対して高い効果を得ることができるのか、要件整理でゴールと定めた部分をクリアできそうか検討し、ここで追加開発の規模を決定します。

ロボットの設計・開発・UAT・リリース

すでに開発済み、稼働中のロボットに対して、できるだけ最小限の追加開発で実現できるように設計していきましょう。

追加要件によっては、今の規模では実現が難しく、新たなロボットを追加する開発が必要な場合は、特に注意が必要です。

全体の設計に大きく影響を与える恐れがないか、共通部品はそのまま使用できるのか、変数は既存のものを使用できるのか、新しい変数を作成する必要があるのか。

細部まで検討し、追加ロボットによって発生する新しいパターンを洗い出し、すみずみまで検証をして、追加開発を実現させましょう。

ロボット運用

追加開発に伴う運用の変更がある場合は運用担当者に引継ぎを行います。

この時、検証をしっかり行うことができていれば引継ぎに関してはスムーズに行うことができるでしょう。

既存RPAロボットの追加開発を行った事例紹介

弊社で自動化したETRMシステムに対する追加開発の事例をご紹介

既存RPAの追加開発を行った成功事例として、弊社で自動化したETRMシステムを使用したロボットの追加開発の事例をご紹介します。

<参照>RPAｘETRMシステム（Allegro）

業務概要

Allegroに登録された出力データを基にSAPやSCM等のシステムを使用して伝票や実績を登録する。
登録済みのAllegroデータをダウンロードし、他システムから出力した登録データを添付して申請書を提出する。

課題

そもそもなぜ追加開発が必要になったのか。

それは、もともと要件として出ていた処理スピードの部分がその要件に満たしていないことが運用していく中で判明しました。

では、その処理スピードを上げるためにどのように追加開発していったのかを解説していきます。まずは今回特に課題となっていた処理が2点ありました。

Allegroのデータが出力されてから処理完了までに時間がかかる

処理対象フォルダにあるデータを1度の稼働ですべて処理していたため、データ数が多い場合に処理時間が長くなってしまっていました。

端末1のみで行うデータ振り分け作業が詰まった場合、端末1の後処理と端末2の処理が遅れる

このロボットは、データの種類によって、端末1と2のどちらで処理するのかを端末1で判断する仕様になっていました。
そのため、月末や月初めなどの処理データが多い場合に、端末1は振り分け処理のために長時間稼働しているにも関わらず、端末2は端末1の振り分け処理が終わるのを待たないといけなかったため、2つの端末を効果的に使用できておらず非効率的になっていました。

改善案

処理対象データを1度の稼働で3つまでに制限。

データ処理数を制限することにより、処理時間を読めるようになります。
これによりスケジュール実行を効率化することにつながり、データ振り分け中に端末2が待機していることが多かったという課題の解消にもつながります。

端末3のロボットを新規作成。端末3で、データ振り分け作業と、端末1と端末2両方の処理を行えるようにする。

データの処理数に制限をかけるだけだと処理するデータを処理するスピードは端末2が少し動きやすくなった以外は変わりません。
このデータ処理速度、処理数の大規模な改善を行うために端末3が誕生しました。
端末1が行っている業務を、端末1と時間をずらしてスケジュール実行させることにより、より効率的に処理を進めることにつながります。

では実際にどのように改善されたのか見てみましょう。