JP2022115738A - プログラム及び情報処理装置 - Google Patents

Abstract

【課題】ＲＰＡに対する修正の情報が担当者間で共有されない場合に比して、ＲＰＡの管理を効率化するプログラム及び情報処理装置を提供する。【解決手段】プログラムは、コンピュータに、ＲＰＡに対する修正の指示が検知された場合、修正に関連する他のＲＰＡをデータベースから抽出する機能と、指示の検知を、抽出された他のＲＰＡの関連先に通知する機能とを実現させる。コンピュータは、データベースに登録されている複数のＲＰＡのうち、修正の対象とする前記ＲＰＡと、構成上の情報が類似するＲＰＡを、他のＲＰＡとして抽出する。【選択図】図５

Description

本発明は、プログラム及び情報処理装置に関する。

現在、オフィスで実施される業務上のワークフローのうち、予め登録された作業の内容を人間に代わって実行する仕組みが実用化されている。この仕組は、ＲＰＡ（ロボティック・プロセス・オートメーション）と呼ばれる。ＲＰＡは、予め登録した作業の内容を、複数のシステムやアプリケーションの実行を通じて実現する。

特開２０１９－１５９５５６号公報

集中管理されていない独立型のＲＰＡでは、管理を担当する現場の担当者が、個別に開発し、修正している。また、自身が管理を担当するＲＰＡに影響する可能性がある修正の実行に気づく仕組みが存在しないため、修正の目的が同じでも、修正の内容が異なることが起こり得る。

本発明は、ＲＰＡに対する修正の情報が担当者間で共有されない場合に比して、ＲＰＡの管理を効率化することを目的とする。

請求項１に記載の発明は、コンピュータに、ＲＰＡに対する修正の指示が検知された場合、修正に関連する他のＲＰＡをデータベースから抽出する機能と、前記指示の検知を、抽出された前記他のＲＰＡの関連先に通知する機能と、を実現させるためのプログラムである。
請求項２に記載の発明は、前記コンピュータは、前記データベースに登録されている複数のＲＰＡのうち、修正の対象とする前記ＲＰＡと、構成上の情報が類似するＲＰＡを、前記他のＲＰＡとして抽出する、請求項１に記載のプログラムである。
請求項３に記載の発明は、前記コンピュータは、前記修正の対象と共通する構成上の要素を有するＲＰＡを、前記他のＲＰＡとして抽出する、請求項２に記載のプログラムである。
請求項４に記載の発明は、前記コンピュータは、前記修正の内容を、前記他のＲＰＡの担当者に通知する、請求項１に記載のプログラムである。
請求項５に記載の発明は、前記コンピュータは、前記他のＲＰＡの担当者から同意が得られるまで、検知された指示に対応する前記修正の実行を停止する、請求項４に記載のプログラムである。
請求項６に記載の発明は、前記コンピュータは、前記他のＲＰＡに関する情報を、前記修正を指示した担当者に通知する、請求項１に記載のプログラムである。
請求項７に記載の発明は、前記コンピュータは、前記他のＲＰＡに関する情報として、当該ＲＰＡの数を通知する、請求項６に記載のプログラムである。
請求項８に記載の発明は、前記コンピュータは、前記他のＲＰＡに関する情報として、当該ＲＰＡの特徴を通知する、請求項６に記載のプログラムである。
請求項９に記載の発明は、前記コンピュータは、前記指示が予め定めた条件を満たす場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、請求項１に記載のプログラムである。
請求項１０に記載の発明は、前記コンピュータは、前記指示が予め定めた期間に検知された場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、請求項９に記載のプログラムである。
請求項１１に記載の発明は、前記コンピュータは、前記関連先への通知の履歴と、前記他のＲＰＡにおける対応の履歴とを管理する、請求項１に記載のプログラムである。
請求項１２に記載の発明は、前記コンピュータは、前記通知から予め定めた時間が経過した後も、対応が記録されない前記他のＲＰＡを検出した場合、当該他のＲＰＡを特定する情報を、前記修正を指示した担当者に通知する、請求項１１に記載のプログラムである。
請求項１３に記載の発明は、コンピュータに、ＲＰＡに対する修正の指示が検知された場合、データベースに登録されている他のＲＰＡを読み出す機能と、読み出された前記他のＲＰＡに紐付けられている端末に対し、前記修正の内容を通知する機能と、を実現させるためのプログラムである。
請求項１４に記載の発明は、前記コンピュータは、前記修正の内容を外部から受信した場合において、当該修正の内容が自端末のＲＰＡに関連するとき、自端末のＲＰＡの担当者に、当該修正の内容を通知する、請求項１３に記載のプログラムである。
請求項１５に記載の発明は、前記コンピュータは、前記修正の内容の送信元に対し、前記修正の内容に対する前記担当者の同意を通知する、請求項１４に記載のプログラムである。
請求項１６に記載の発明は、前記コンピュータは、前記指示が予め定めた条件を満たす場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、請求項１３に記載のプログラムである。
請求項１７に記載の発明は、前記コンピュータは、前記指示が予め定めた期間に検知された場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、請求項１６に記載のプログラムである。
請求項１８に記載の発明は、前記コンピュータは、関連先への通知の履歴と、前記他のＲＰＡにおける対応の履歴とを管理する、請求項１３に記載のプログラムである。
請求項１９に記載の発明は、前記コンピュータは、前記通知から予め定めた時間が経過した後も、対応が記録されない前記他のＲＰＡを検出した場合、当該他のＲＰＡを特定する情報を、前記修正を指示した担当者に通知する、請求項１８に記載のプログラムである。
請求項２０に記載の発明は、プロセッサを有し、前記プロセッサは、ＲＰＡに対する修正の指示が検知された場合、修正に関連する他のＲＰＡをデータベースから抽出し、前記指示の検知を、抽出された前記他のＲＰＡの関連先に通知する、情報処理装置である。
請求項２１に記載の発明は、プロセッサを有し、前記プロセッサは、ＲＰＡに対する修正の指示が検知された場合、データベースに登録されている他のＲＰＡを読み出し、読み出された前記他のＲＰＡに紐付けられている端末に対し、前記修正の内容を通知する、情報処理装置である。

請求項１記載の発明によれば、ＲＰＡに対する修正の情報が担当者間で共有されない場合に比して、ＲＰＡの管理を効率化できる。
請求項２記載の発明によれば、影響が及ぶ可能性がある修正の情報を担当者間で共有できる。
請求項３記載の発明によれば、影響が及ぶ可能性が高いＲＰＡの絞り込みが実現できる。
請求項４記載の発明によれば、修正の内容の情報を担当者間で共有できる。
請求項５記載の発明によれば、修正が影響する範囲の全体で管理を効率化できる。
請求項６記載の発明によれば、影響の範囲を把握可能にできる。
請求項７記載の発明によれば、修正が影響するＲＰＡの数を担当者に提供できる。
請求項８記載の発明によれば、修正が影響するＲＰＡの特徴を担当者に提供できる。
請求項９記載の発明によれば、共有する情報と共有しない情報を分けることができる。
請求項１０記載の発明によれば、通知の多発による担当者への負担を減少できる。
請求項１１記載の発明によれば、他のＲＰＡの管理の状況を把握できる。
請求項１２記載の発明によれば、管理されていないＲＰＡを把握できる。
請求項１３記載の発明によれば、ＲＰＡに対する修正の情報が担当者間で共有されない場合に比して、ＲＰＡの管理を効率化できる。
請求項１４記載の発明によれば、影響が及ぶ可能性がある修正の情報を担当者間で共有できる。
請求項１５記載の発明によれば、担当者間で修正の影響に対する情報を共有できる。
請求項１６記載の発明によれば、共有する情報と共有しない情報を分けることができる。
請求項１７記載の発明によれば、通知の多発による担当者への負担を減少できる。
請求項１８記載の発明によれば、他のＲＰＡの管理の状況を把握できる。
請求項１９記載の発明によれば、管理されていないＲＰＡを把握できる。
請求項２０記載の発明によれば、ＲＰＡに対する修正の情報が担当者間で共有されない場合に比して、ＲＰＡの管理を効率化できる。
請求項２１記載の発明によれば、ＲＰＡに対する修正の情報が担当者間で共有されない場合に比して、ＲＰＡの管理を効率化できる。

実施の形態１で使用する情報処理システムの使用例を説明する図である。 実施の形態１で使用するＲＰＡ端末のハードウェア構成の一例を説明する図である。 構成情報ＤＢのデータ構造の一例を説明する図である。（Ａ）はメインテーブルを示し、（Ｂ）は構成要素に関連するサブテーブルを示す。 情報処理システムを構成する複数のＲＰＡ端末の１つに修正が指示される場合における他のＲＰＡ端末への修正の影響を説明する図である。 修正を受け付けたＲＰＡ端末で実行される処理動作の一例を説明するフローチャートである。 ステップ３で実行される処理動作の詳細を説明するフローチャートである。 修正を受け付けたＲＰＡ端末で実行される処理動作の他の例を説明するフローチャートである。 修正を受け付けたＲＰＡ端末で実行される処理動作の他の例を説明するフローチャートである。 実施の形態２で使用するＲＰＡ端末のハードウェア構成の一例を説明する図である。 修正を受け付けたＲＰＡ端末で実行される処理動作の一例を説明するフローチャートである。 修正を受け付けたＲＰＡ端末で実行される処理動作の他の例を説明するフローチャートである。 実施の形態３で使用するＲＰＡ端末のハードウェア構成の一例を説明する図である。 修正通知ログと修正ログのデータ例を示す図である。（Ａ）は修正通知ログのデータ例を示し、（Ｂ）は修正ログのデータ例を示す。 修正を受け付けたＲＰＡ端末で実行される処理動作の一例を説明するフローチャートである。 実施の形態５で使用するＲＰＡ端末のハードウェア構成の一例を説明する図である。 自端末構成情報のデータ構造の一例を説明する図である。 修正を受け付けたＲＰＡ端末で実行される処理動作の一例を説明するフローチャートである。 修正を受け付けたＲＰＡ端末で実行される処理動作の他の一例を説明するフローチャートである。 修正を受け付けたＲＰＡ端末で実行される処理動作の一例を説明するフローチャートである。 実施の形態５で使用するＲＰＡ端末のハードウェア構成の一例を説明する図である。 修正を受け付けたＲＰＡ端末で実行される処理動作の一例を説明するフローチャートである。

以下、図面を参照して、本発明の実施の形態を説明する。
＜実施の形態１＞
＜システムの全体構成＞
図１は、実施の形態１で使用する情報処理システム１の使用例を説明する図である。
図１に示す情報処理システム１は、ネットワーク１０及び１０Ａに接続された複数の情報機器で構成されている。

図１の場合、情報機器の一例として、画像形成装置２０と、画像形成装置２０や担当者端末５０が扱う文書の記憶やＯＣＲ（＝Optical Character Recognition）処理等を実行する業務サーバ３０Ａ及びクラウドサーバ３０Ｂと、定型化された作業等に対応する処理ルーチンで規定されるＲＰＡを実行するＲＰＡ端末４０と、ＲＰＡを使用して業務を行う担当者が操作する担当者端末５０を例示している。
本実施の形態における画像形成装置２０は、コピー機、プリンタ、イメージスキャナ、ファクシミリ等の複数の機能を備える。このため、「複合機」とも呼ばれる。

図１の例では、ネットワーク１０としてＬＡＮ（＝Local Area Network）を想定する。ＬＡＮは、有線でも無線でもよい。また、ネットワーク１０Ａとして、インターネットやクラウドネットワークを想定する。
なお、ネットワーク１０及び１０Ａの一部は、４Ｇ、５Ｇ等の移動通信システムでもよいし、ブルートゥース（登録商標）でもよい。

図１では、画像形成装置２０として、オフィス向けの製品を例示しているが、小規模オフィス用の小型の製品でもよい。
また、画像形成装置２０が設置される場所に制約はない。予め定めた条件を満たせば、画像形成装置２０は、コンビニエンスストア等に設置してもよい。換言すると、画像形成装置２０は、いわゆるキオスク端末でもよい。

業務サーバ３０Ａ及びクラウドサーバ３０Ｂは、例えば業務上の文書の保管、画像形成装置２０からアップロードされた画像イメージのＯＣＲ処理、ＯＣＲ処理後の画像イメージから抽出されたテキストデータのデータベースへの登録、登録された数値の計算、電子メールの送信その他を実行する。
これらの各処理の実行は、担当者の指示による場合とＲＰＡ端末４０からの指示による場合がある。

本実施の形態では、文書として、例えば申込書、請求書、納品書、伝票等の帳票を想定する。
帳票の記入欄には、手書きで文字が記入されていてもよいし、印刷で文字が記入されていてもよい。手書きの帳票の場合、事前に印刷された枠内に手書きの文字が記入される。
なお、文書は、帳票等の会計又は経理上の文書に限らず、人事データや福利厚生に関するデータでもよい。

また、文書は、ファクス、電子メール、文書作成用のソフトウェアで作成された文書、表計算用のソフトウェアで作成された文書、プレゼンテーション用のソフトウェアで作成された文書、写真を含む静止画像、動画像でもよい。
また、業務サーバ３０Ａ及びクラウドサーバ３０Ｂには、業務に関連する各種の情報を記憶するデータベースが記憶されていてもよい。データベースには、例えばＯＣＲ処理後の画像イメージから抽出されたテキストデータが登録される。

なお、例示した文書は一例に過ぎず、その全てを業務サーバ３０Ａ及びクラウドサーバ３０Ｂが扱う必要はない。また、業務サーバ３０Ａ及びクラウドサーバ３０Ｂが、追加のデータを扱ってもよい。
画像イメージは、画像形成装置２０から取り込まれる画像の他、スマートフォンやタブレットに設けられたカメラで撮像された画像でもよい。

ＲＰＡ端末４０は、業務サーバ３０Ａ及びクラウドサーバ３０Ｂとの連携により、ＲＰＡが実行される端末である。図１に示すＲＰＡ端末４０は複数台であり、各ＲＰＡ端末４０を「４０－１」、「４０－２」、…「４０－Ｎ」と表記する。
ＲＰＡ端末４０は、いわゆるコンピュータであり、例えばサーバ、デスクトップ型のコンピュータ、ノート型のコンピュータを想定する。

ＲＰＡ端末４０は、プログラム（以下「実行ルーチン」という）の実行を通じ、作業の代行を実現する。
例えばＲＰＡ端末４０は、文書の仕分けや特定の情報の抽出とテーブルへの登録の代行を実現する。
また例えばＲＰＡ端末４０は、担当者端末５０の設定やアプリケーションプログラムのインストール、ウェブサイトの検索や情報の収集、ウェブサイトの更新、画像形成装置２０を用いた印刷の実行、データの分析、加工、配布その他を実現する。

複数台のＲＰＡ端末４０を使用する場合、各ＲＰＡ端末４０は同じ実行ルーチンを実行してもよいし、それぞれが異なる実行ルーチンを実行してもよい。
また、１台のＲＰＡ端末４０は、１つの実行ルーチンを実行してもよいし、複数の実行ルーチンを実行してもよい。
実行ルーチンは、プログラム、シナリオ、スクリプト、マクロ等とも呼ばれる。

実行ルーチンを構成する構成要素は、その粒度により、サブルーチン、コマンド、パラメータ、リソース、ＡＰＩ（＝Application Programming Interface）とも呼ばれる。パラメータには、グローバルな変数とローカルな変数とが含まれる。なお、複数のＲＰＡが連携して１つのＲＰＡとして機能する場合もある。その意味において、ＲＰＡは、構成要素の一例でもある。
本実施の形態におけるＲＰＡ端末４０は、情報処理装置の一例である。

担当者端末５０は、情報処理システム１を用いて業務を行う担当者やシステムを管理する担当者が操作するコンピュータである。担当者端末５０は、例えばデスクトップ型のコンピュータやノート型のコンピュータである。
もっとも、担当者端末５０としてスマートフォンやタブレット型のコンピュータの使用を排除しない。また、担当者端末５０は、ウェアラブル型のコンピュータでもよい。
図１に示す担当者端末５０は複数台であり、各担当者端末５０を「５０－１」、「５０－２」、…「５０－Ｍ」と表記する。

＜ＲＰＡ端末の構成＞
図２は、実施の形態１で使用するＲＰＡ端末４０のハードウェア構成の一例を説明する図である。
図２に示すＲＰＡ端末４０は、データ処理部４００と、ハードディスクドライブ（すなわち「ＨＤＤ」）４１０と、通信モジュール４２０とを有している。
ここでの通信モジュール４２０には、ネットワーク１０及び１０Ａとの通信に使用するプロトコルに準拠したデバイスが使用される。

データ処理部４００は、プロセッサ４０１と、ＲＯＭ（＝Read Only Memory）４０２と、ＲＡＭ（＝Random Access Memory）４０３とを有している。
ＲＯＭ４０２とＲＡＭ４０３は、いずれも半導体メモリである。ＲＯＭ４０２には、ＢＩＯＳ（＝Basic Input Output System）等が記憶されている。ＲＡＭ４０３は、プログラムの実行に使用される主記憶装置として用いられる。ＲＡＭ４０３には、例えばＤＲＡＭ（＝Dynamic RAM）を使用する。

プロセッサ４０１は、例えばＣＰＵ（＝Central Processing Unit）で構成される。プロセッサ４０１は、プログラムの実行を通じて各種の機能を実現する。
図２に示すプロセッサ４０１には、機能の一例として、ＲＰＡ実行部４０１Ａと、修正受付部４０１Ｂと、修正実行部４０１Ｃと、関連ＲＰＡ抽出部４０１Ｄと、修正通知部４０１Ｅとを表している。

ＲＰＡ実行部４０１Ａは、実行ルーチン４１１の実行により実現される機能部である。
修正受付部４０１Ｂと、修正実行部４０１Ｃと、関連ＲＰＡ抽出部４０１Ｄと、修正通知部４０１Ｅは、修正共有プログラム４１２の実行により実現される機能部である。

修正受付部４０１Ｂは、担当者等による実行ルーチン４１１の修正を受け付ける機能部である。修正受付部４０１Ｂは、修正の内容が反映された実行ルーチン（以下「新ファイル」という）を受け付ける他、現行の実行ルーチン（以下「旧ファイル」という）に対する修正の指示を受け付ける。

修正実行部４０１Ｃは、実行ルーチン４１１を旧ファイルから新ファイルに入れ替えることにより又は上書き保存することにより、実行ルーチン４１１を実行可能な状態にする機能部である。
関連ＲＰＡ抽出部４０１Ｄは、構成情報データベース（以下「構成情報ＤＢ」という）４１３から、修正に関連するＲＰＡを抽出する機能部である。

修正通知部４０１Ｅは、抽出されたＲＰＡが実行される他のＲＰＡ端末４０又は関連する担当者に対し、関連する修正の発生を通知する機能部である。
本実施の形態における修正通知部４０１Ｅは、関連する修正の発生だけを通知し、修正の内容は通知しない。もっとも、修正の内容を通知してもよい。修正の発生の通知には、例えば修正の対象であるＲＰＡの名称やＲＰＡの識別に用いる識別子を含めてもよい。

ハードディスクドライブ４１０は、磁気ディスクを記録媒体とする補助記憶装置である。本実施の形態では、補助記憶装置としてハードディスクドライブ４１０を使用するが、不揮発性の書き換えが可能な半導体メモリを使用してもよい。
ハードディスクドライブ４１０には、オペレーションシステムやアプリケーションプログラムがインストールされる。

図２の場合、アプリケーションプログラムの一例として、実行ルーチン４１１と修正共有プログラム４１２が記憶されている。
この他、ハードディスクドライブ４１０には、情報処理システム１を構成する全てのＲＰＡ端末４０の構成情報を集約した構成情報ＤＢ４１３が記憶されている。
構成情報ＤＢ４１３は、ネットワーク１０及び１０Ａに接続されている全てのＲＰＡ端末４０の間で共有される。

構成情報に修正が生じた場合、修正が発生したＲＰＡ端末４０（図１参照）から他の全てのＲＰＡ端末４０に対し、修正後の構成情報が通知される。通知を受けた他のＲＰＡ端末４０は、ハードディスクドライブ４１０に記憶されている構成情報ＤＢ４１３の構成情報を更新し、最新の状態を維持する。
もっとも、構成情報に修正が生じたＲＰＡ端末４０が更新した構成情報ＤＢ４１３を、他のＲＰＡ端末４０にブロードキャストすることにより、最新の情報の共有を維持してもよい。

図３は、構成情報ＤＢ４１３のデータ構造の一例を説明する図である。（Ａ）はメインテーブルを示し、（Ｂ）は構成要素に関連するサブテーブルを示す。
図３（Ａ）に示すメインテーブルは、「ＲＰＡ名」、「ＩＤ」、「バージョン」情報、「連携するＲＰＡ」情報、「構成要素」、「通知先」、「関連文書」、「関連端末」により構成される。

「ＲＰＡ名」は、ＲＰＡに付されている名称であり。図３（Ａ）では、「ＲＰＡ名」として、「住所管理」と「ダイレクトメール送信」が例示されている。
「ＩＤ」は、ＲＰＡの識別子であり、図３（Ａ）では、「Ｒ００１」と「Ｒ００２」が例示されている。
「バージョン」情報は、バージョンの違いを表す情報であり、例えば「１．０」や「２．０」、「１．１」や「１．２」が記録される。バージョンは、修正が加えられるたびに更新される。

「連携するＲＰＡ」情報には、「ＲＰＡ名」により特定されるＲＰＡの前工程や後工程で使用されるＲＰＡが存在する場合に記録される。
ここで、前工程とは、修正の対象であるＲＰＡを呼び出す関係をいう。後工程とは、修正の対象であるＲＰＡから呼び出す関係をいう。
なお、前工程と後工程は、既存の関係に限らず、システム内に新たに追加されるＲＰＡにも適用される。すなわち、新たに追加されるＲＰＡを呼び出すＲＰＡと新たに追加されるＲＰＡから呼び出すＲＰＡも、ここでの前工程と後工程の関係に含まれる。

なお、前工程と後工程には、直前のＲＰＡと直後のＲＰＡに限らず、更に上流又は下流のＲＰＡを含めてもよい。
「構成要素」は、ＲＰＡを構成する部品であり、プログラム、サブルーチン、コマンド、パラメータ、リソース、ＡＰＩ等を含む。「構成要素」は、それぞれ視覚的なオブジェクトとして提供され、これらを画面上で順番に並べると実行ルーチンが生成される。

「通知先」には、ＲＰＡの管理を担当する担当者やシステムの管理者等のメールアドレス等が記録される。図３（Ａ）では、「Ｆｕｊｉｔａｒｏ＠ｘｘｘ．ｃｏ．ｊｐ」が記録されている。
「関連文書」には、例えば修正の履歴や参照先のＵＲＬ（＝Uniform Resource Locator）が記録されている。なお、参照先はＵＲＬに限らず、オンプレミスのＳＮＳ（＝Social Networking Service）やＤＮＳ（＝Domain Name System）、ＣＲＭ（＝Customer Relationship Management）、オンプレミスのデータストレージ、パブリッククラウドデータストレージ等でもよい。

「関連端末」には、対応するＲＰＡが実行されているＲＰＡ端末４０を特定する情報が記録されている。ＲＰＡ端末４０を特定する情報には、例えば管理上の名称やネットワーク上のアドレスがある。例えば「住所管理」ＲＰＡが、ＲＰＡ端末４０－１とＲＰＡ端末４０－２で実行される場合、各端末を特定する情報が記録される。

図３（Ｂ）に示すサブテーブルは、メインテーブルの要素である「構成要素」に紐付けられている。図３（Ｂ）に示すサブテーブルは、「構成要素名」、「ＩＤ」、「プログラム構成」、「属性値」、「特徴情報」で構成される。
「構成要素名」には、例えば「住所管理」用のＲＰＡを構成する構成要素の名称が記載される。「住所管理」ＲＰＡを構成する構成要素が複数の場合、複数の構成要素名が列記される。

「ＩＤ」は、構成要素の識別子である。ＲＰＡが複数の構成要素で構成される場合、構成要素毎に「ＩＤ」が付与される。
「プログラム構成」には、実行ルーチンを組み立てる際に使用した部品、部品の組み合わせパターン、標準的なテンプレート、共通ライブラリ、プログラムの名称等がある。
換言すると、「プログラム構成」は、実行ルーチンの具体的な材料に対応する。「プログラム構成」には、担当者が再利用を目的としてライブラリ化したモジュールも含まれる。
図３（Ｂ）では、「プログラム構成」として、「顧客会社ＤＢ参照」と、「ＨＰ記載住所抽出」と、「Ｅｘｃｅｌ登録」の３つを例示している。

「属性値」は、実行ルーチンがアクセスするＲＰＡの内外のリソースの属性情報であり、例えば参照先の名称、参照先のアドレス、ログイン情報、アクセスキー等がある。アクセスキーは、認証用の情報である。
図３（Ｂ）では、「顧客会社ＤＢアドレス」と「郵便番号検索ＵＲＬ」の２つが記録されている。

「特徴情報」は、対象とするＲＰＡの特徴に関する記載であり、ＲＰＡの属性情報や類似性の判定に使用される。
図３（Ｂ）では、「特徴情報」として、説明文、キーワード群、属性名と属性値の組（ＫＶ）等が例示されている。
因みに、キーワード群には、例えば名称、バージョン、タイムスタンプ、作成者、運用者がある。
図３（Ｂ）では、「特徴情報」として、「会社名でＨＰを検索して住所を抽出し、Ｅｘｃｅｌにリスト化する」との説明文と、「地域：日本国内」の２つが記録されている。

＜処理動作１＞
図４は、情報処理システム１を構成する複数のＲＰＡ端末４０の１つに修正が指示される場合における他のＲＰＡ端末４０への修正の影響を説明する図である。図４には、図１との対応部分に対応する符号を付して示している。
図４では、情報処理システム１のうちＲＰＡ端末４０と担当者端末５０を抜き出して表している。

図４の場合、担当者が担当者端末５０－１を操作してＲＰＡ端末４０－１に修正を指示している。図４に示すＲＰＡ端末４０－２は、ＲＰＡ端末４０－１に対する修正と関連性があるが、ＲＰＡ端末４０－３はＲＰＡ端末４０－１に対する修正と関連性がない。
修正との関連性の有無は、例えば実行ルーチンとしての類似性、前工程や後工程としての連携の有無、バージョンやコピーの履歴が存在する時系列情報を用いて判定される。

図５は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の一例を説明するフローチャートである。図５においては、ステップの意味で記号のＳを使用する。
以下の処理は、プロセッサ４０１（図２参照）による修正共有プログラム４１２（図２参照）の実行を通じて実現される。

まず、ＲＰＡ端末４０－１は、ＲＰＡの修正を受け付ける（ステップ１）。
ＲＰＡ端末４０－１に対する修正の指示には、修正する箇所と修正の内容とを個別に指示する方法と、修正済みの実行ルーチン４１１（図２参照）をアップロードする方法とがある。
本実施の形態の場合、ＲＰＡ端末４０－１は、受け付けた修正を実行する（ステップ２）。

修正の実行は、例えば即座に実行する場合、夜間や休日等の業務時間外に実行する場合、受け付けた修正を蓄積し、週１回等の予め定めたタイミング実行する場合がある。いずれにしても、本実施の形態の場合、受け付けた修正は全て実行される。
次に、ＲＰＡ端末４０－１は、自端末が受け付けた修正と関連する他のＲＰＡがあるか否かを判定する（ステップ３）。この判定は、関連ＲＰＡ抽出部４０１Ｄ（図２参照）が実行する。図４の例であれば、ＲＰＡ端末４０－２が、関連性を有する他のＲＰＡとして抽出される。

図６は、ステップ３で実行される処理動作の詳細を説明するフローチャートである。
まず、ＲＰＡ端末４０－１は、修正の内容を抽出する（ステップ３１）。修正の内容は、例えば新ファイルと旧ファイルの比較や修正履歴のページから取得される。
次に、ＲＰＡ端末４０－１は、構成情報ＤＢ４１３（図２参照）を使用し、修正の対象であるＲＰＡが他のＲＰＡ端末４０でも実行されているか否かを判定する（ステップ３２）。

例えばＲＰＡ端末４０－１は、構成情報ＤＢ４１３の「ＲＰＡ名」の欄や「関連端末」の欄を参照し、修正の対象であるＲＰＡと同じ名称のＲＰＡが登録されている他のＲＰＡ端末４０の有無を判定する。
ステップ３２で肯定結果が得られた場合、ＲＰＡ端末４０－１は、ステップ４に進む。
一方、ステップ３２で否定結果が得られた場合、ＲＰＡ端末４０－１は、構成情報ＤＢ４１３を使用し、時系列の関係がある他のＲＰＡがあるか否かを判定する（ステップ３３）。時系列の関係には、例えばバージョン違い、複製の履歴がある。複製の履歴には、複製元となったＲＰＡの情報や複製先となったＲＰＡの情報が記録されている。

ステップ３３で肯定結果が得られた場合、ＲＰＡ端末４０－１は、ステップ４に進む。
ステップ３３でも否定結果が得られた場合、ＲＰＡ端末４０－１は、構成情報ＤＢ４１３を使用し、連携するＲＰＡの登録があるか否かを判定する（ステップ３４）。連携の関係には、前工程と後工程の関係がある。
ステップ３４で肯定結果が得られた場合、ＲＰＡ端末４０－１は、ステップ４に進む。

ステップ３４でも否定結果が得られた場合、ＲＰＡ端末４０－１は、構成情報ＤＢ４１３を使用し、修正された箇所と同じ又は類似する箇所を有する他のＲＰＡを検索する（ステップ３５）。
類似性の判定には、例えば「ＲＰＡ名」の類似性、「特徴情報」に記録されている説明文、キーワード群、ＫＶに含まれる単語の類似性を使用する。例えばＵＲＬが修正された場合、修正前のＵＲＬを有するＲＰＡが「類似性あり」と判定される。

また、オブジェクト指向によりＲＰＡを構成する部品が管理されている場合、「クラス」と呼ばれるオブジェクトのひな形又はテンプレートの利用により、「インスタンス」と呼ばれるＲＰＡ及び構成要素が生成される。オブジェクト指向のＲＰＡの場合、インスタンスの生成に使用したクラスの種類や数との一致度を使用して類似性が判定される。

ステップ３５で「類似性あり」が得られた場合、ＲＰＡ端末４０－１は、ステップ４に進む。
一方、ステップ３５で「類似性なし」が得られた場合、ＲＰＡ端末４０－１は、処理を終了する。
図５の説明に戻る。

ステップ３で肯定結果が得られた場合、ＲＰＡ端末４０－１は、関連する他のＲＰＡの担当者に対し、関連する修正の発生を通知する（ステップ４）。本実施の形態の場合、関連する他のＲＰＡの担当者にのみ修正の発生が通知される。換言すると、関連性がない修正の発生の通知を受けずに済む。このため、関連性の有無に関わらず、全ての修正の発生が他のＲＰＡの担当者に通知される場合に比して、他のＲＰＡの担当者の負担が軽減される。

本実施の形態の場合、担当者への通知は、構成情報ＤＢ４１３の「通知先」に記録されている情報が使用される。本実施の形態の場合、関連するＲＰＡの名称や関連するＲＰＡが登録されている他のＲＰＡ端末４０の情報も通知される。
なお、ステップ３で否定結果が得られた場合、ＲＰＡ端末４０－１は、そのまま処理を終了する。
図５の場合、ステップ３の判定は、ステップ２の実行後に行っているが、ステップ１によるＲＰＡの修正の受け付けを条件として実行してもよい。前述したように、ステップ２における修正の実行は、修正の受け付けと同時に実行されるとは限らないためである。

もっとも、修正が待機される時間が長い場合、判定の実行後に構成情報ＤＢ４１３に修正があると、ステップ４の通知に漏れや誤りが生じる可能性がある。
このため、自端末における修正の待機中にステップ３の判定を実行し、関連する他のＲＰＡの担当者に通知する場合には、自端末の修正の実行後に改めてステップ３の判定とステップ４の通知を実行してもよい。

本実施の形態の場合、他のＲＰＡ端末４０のＲＰＡの修正の適用は、通知を受けた担当者が決定する。
このステップ４の通知が存在することにより、修正されたＲＰＡと同じ名称で管理している別の担当者に対しても、修正の必要性に気づかせることが可能になる。その結果、各担当者が同じタイミングで修正の必要性や修正の内容を検討することが可能になる。複数人の担当者が情報を共有して修正の内容を同時に検討することで、ＲＰＡの保守や開発の効率化が実現される。

さらに、実行済みの修正の内容を、自身が担当するＲＰＡにも適用することが可能になり、複数の担当者が個別に修正の内容を検討する等の重複した労力が削減される。特に、同じ目的で実行された修正の間で内容に差異が生じる可能性が低減される。
また、本実施の形態の場合、修正箇所の前工程や後工程等、修正の内容が影響する可能性があるＲＰＡの担当者に対しても、別の実行ルーチンで実行された修正の影響を検討する機会を与えることが可能になる。すなわち、副作用が事象として現れる前に修正の内容を検討することが可能になる。

例えば修正されたＲＰＡとの間でのデータのやり取りに使用される名や値等が変化した場合には、整合性の観点から自身が担当するＲＰＡの修正が必要であることを気づかせることも可能になる。
例えばローカルな業務上の必要性から、現場の担当者が担当するＲＰＡを修正することがある。

この修正の内容が他のＲＰＡとの連携時に使用される情報であった場合、修正された名や値等を使用する前工程や後工程のＲＰＡでも修正が行われないと、ＲＰＡの実行が途中で停止する事象が発生する。
しかし、本実施の形態の場合には、前工程や後工程のＲＰＡの担当者でも、他のＲＰＡについて関連する可能性がある修正の発生が通知される。

このため、他のＲＰＡの修正と同時期に、他のＲＰＡの担当者に修正の必要性を気づかせることが可能になる。
その結果、ＲＰＡの動作が途中で停止する事態の発生を未然に回避することが可能になる。
また、障害が発生した時点でも、修正を要する箇所の発見が容易になる。

＜処理動作２＞
図７は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の他の例を説明するフローチャートである。図７には、図５との対応部分に対応する符号を付して示している。
図７に示す処理動作は、ステップ２の実行後に判定処理が追加される点で、図５に示す処理動作と相違する。

図７の場合、ステップ２の実行後に、ＲＰＡ端末４０－１は、指示が予め定めた条件を満たすか否かを判定する（ステップ１０１）。予め定めた条件には、例えば運用を開始してからの経過時間が予め定めた期間内であることがある。予め定めた期間には、例えば１４日や３０日を使用する。運用を開始した直後は手直しも多く、修正した内容が正しいとも限らない。また、頻繁な通知を他のＲＰＡの担当者が望まない場合もある。もっとも、図５で説明したように、全ての修正を通知の対象としてもよい。

ステップ１０１で肯定結果を満たす場合、すなわち予め定めた条件を満たす場合、ＲＰＡ端末４０－１は、修正を通知する必要がないので、そのまま処理を終了する。
一方、ステップ１０１で否定結果が得られた場合、ＲＰＡ端末４０－１は、ステップ３に進み、自端末が受け付けた修正と関連する他のＲＰＡがあるか否かを判定する。以下の処理動作は、図５と同じであるので説明を省略する。

＜処理動作３＞
図８は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の他の例を説明するフローチャートである。図８には、図５との対応部分に対応する符号を付して示している。
図８に示す処理動作は、ステップ３で肯定結果が得られた場合の動作が、前述した処理動作１（図５参照）の動作と相違する。

図８の場合、ＲＰＡ端末４０－１は、ステップ３で肯定結果が得られると、関連する他のＲＰＡに関する情報を、ステップ１で受け付けた修正を指示した担当者に通知する（ステップ１１１）。
他のＲＰＡに関する情報には、例えば他のＲＰＡの数、他のＲＰＡの名称、他のＲＰＡの担当者、他のＲＰＡの特徴がある。この通知により、修正を指示した担当者は、同種のＲＰＡの共通化や統合化の必要性を判定することが可能になる。
なお、関連する他のＲＰＡの修正は、通知を受けた担当者が自身で修正する場合と、他のＲＰＡの担当者を通じて修正を実行する場合がある。

＜実施の形態２＞
＜システムの全体構成＞
実施の形態２も、実施の形態１と同じ情報処理システム１（図１参照）を使用する。
本実施の形態の場合、ＲＰＡ端末４０に機能が追加される。

＜ＲＰＡ端末の構成＞
図９は、実施の形態２で使用するＲＰＡ端末４０のハードウェア構成の一例を説明する図である。図９には、図２との対応部分に対応する符号を付して示している。
図９に示すＲＰＡ端末４０の場合、ハードディスクドライブ４１０には、実行ルーチン４１１と、修正共有プログラム４１２Ａと、構成情報ＤＢ４１３が記憶されている。

また、プロセッサ４０１による修正共有プログラム４１２Ａの実行により実現される機能に、修正応答部４０１Ｆが追加されている。他の構成は、実施の形態１と同じである。
本実施の形態で追加する修正応答部４０１Ｆは、他のＲＰＡ端末４０からの修正の通知を受け付けた場合に、通知元である他のＲＰＡ端末４０に応答の内容を送信する機能を提供する。

＜処理動作１＞
図１０は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の一例を説明するフローチャートである。図１０には、図５との対応部分に対応する符号を付して示す。
図１０の場合も、ＲＰＡ端末４０－１は、ＲＰＡの修正を受け付ける（ステップ１）。

次に、ＲＰＡ端末４０－１は、ステップ３を実行する。すなわち、ＲＰＡ端末４０－１は、受け付けた修正を実行する前に、自端末が受け付けた修正と関連する他のＲＰＡがあるか否かを判定する。
この判定において否定結果が得られた場合、ＲＰＡ端末４０－１は、受け付けた修正を実行する（ステップ２）。

なお、ステップ３で肯定結果が得られた場合、ＲＰＡ端末４０－１は、ステップ４を実行する。すなわち、ＲＰＡ端末４０－１は、関連する他のＲＰＡの担当者に対し、関連する修正の発生を通知する。
この後、修正を受け付けたＲＰＡ端末４０－１は、通知先である他のＲＰＡの担当者から合意を受信したか否かを判定する（ステップ１２１）。
ステップ１２１で肯定結果が得られた場合、ＲＰＡ端末４０－１は、受け付けた修正を実行する（ステップ２）。一方、ステップ１２１で否定結果が得られた場合、ＲＰＡ端末４０－１は、受け付けた修正を実行することなく処理を終了する。

すなわち、本実施の形態の場合、修正を受け付けたＲＰＡ端末４０－１であっても、全ての修正を実行するとは限らない。
修正が実行されるのは、関連する他のＲＰＡが存在しない場合と関連する他のＲＰＡの担当者から同意が得られた場合である。
そして、関連する他のＲＰＡの担当者から同意が得られない場合には、受け付けた修正が実行されない。

本実施の形態の場合、他の担当者の合意を条件に修正が実行されるので、誤った内容の修正や整合性等が要求される内容の修正を未然に防ぐことが可能になる。
また、複数の担当者による修正の実行前に検討が加えられることで、より汎用性や網羅性を高めた修正や開発が可能になる。

＜処理動作２＞
図１１は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の他の例を説明するフローチャートである。図１１には、図１０との対応部分に対応する符号を付して示す。
図１１の場合も、ＲＰＡ端末４０－１は、ＲＰＡの修正を受け付ける（ステップ１）。

次に、ＲＰＡ端末４０－１は、自端末が受け付けた修正と関連する他のＲＰＡがあるか否かを判定する（ステップ３）。
ステップ３で否定結果が得られた場合、ＲＰＡ端末４０－１は、受け付けた修正を実行する（ステップ２）。他のＲＰＡへの影響を考慮する必要がないためである。
一方、ステップ３で肯定結果が得られた場合、ＲＰＡ端末４０－１は、関連する他のＲＰＡに関する情報を、ステップ１で受け付けた修正を指示した担当者に通知する（ステップ１３１）。

このステップ１３１の内容は、実施の形態１におけるステップ１１１（図８参照）と同じである。本実施の形態の場合、指示した修正が実行される前に、関連する他のＲＰＡに関する情報が通知される。すなわち、自身が指示した修正の影響を把握した上で、それでも修正を実行するかを判定する機会が与えられる。
この後、ＲＰＡ端末４０－１は、実行の最終指示を受け付けたか否かを判定する（ステップ１３２）。

ステップ１３２で肯定結果が得られた場合、ＲＰＡ端末４０－１は、受け付けた修正を実行する（ステップ２）。
ステップ１３２で否定結果が得られた場合、ＲＰＡ端末４０－１は、受け付けた修正を実行せずに処理を終了する。
処理動作２の場合には、修正を指示した担当者に対し、指示した修正を実行するか否かを見直す機会が与えられる。この点が処理動作１（図１０参照）との違いである。
この処理動作の場合、影響が大きい修正が実行される前に修正の実行を再考する機会が確保される。

＜実施の形態３＞
＜システムの全体構成＞
実施の形態３も、実施の形態１と同じ情報処理システム１（図１参照）を使用する。
本実施の形態の場合、ＲＰＡ端末４０に機能が追加される。

＜ＲＰＡ端末の構成＞
図１２は、実施の形態３で使用するＲＰＡ端末４０のハードウェア構成の一例を説明する図である。図１２には、図２との対応部分に対応する符号を付して示している。
図１２に示すＲＰＡ端末４０の場合、ハードディスクドライブ４１０には、実行ルーチン４１１と、修正共有プログラム４１２Ｂと、構成情報ＤＢ４１３と、修正通知ログ４１４と、修正ログ４１５が記憶されている。
また、プロセッサ４０１による修正共有プログラム４１２Ｂの実行により実現される機能に、通知管理部４０１Ｇが追加される。他の構成は、実施の形態１と同じである。

修正通知ログ４１４は、修正通知部４０１Ｅによる修正の通知の履歴を記録するデータである。
修正ログ４１５は、実行された修正の内容を記録するデータである。
通知管理部４０１Ｇは、修正の通知先である他のＲＰＡの担当者による修正への対応の状況を管理する機能を実現する。通知管理部４０１Ｇは、「通知時刻」からの経過の時間が予め定めた時間を経過しても「対応の履歴」が空欄の場合、通知先である他のＲＰＡを野良ロボとみなし、アラームを出力する。アラームの出力先は、例えばシステムの管理者とする。「予め定めた時間」は予め定めた期間の一例である。なお、予め定めた期間は、予め定めた条件の一例である。

また、通知管理部４０１Ｇは、修正の通知後に運用が開始される他のＲＰＡであって、修正との関連性が認められた他のＲＰＡの担当者への関連する修正の存在を通知する機能を実現する。換言すると、通知管理部４０１Ｇは、構成情報ＤＢ４１３（図２参照）に新たなＲＰＡが登録された場合や既存のＲＰＡの記録に変更が生じた場合に、修正ログ４１５との関連性を判定し、関連性が認められた場合、関連する修正の確認を求める通知を出力する。

図１３は、修正通知ログ４１４と修正ログ４１５のデータ例を示す図である。（Ａ）は修正通知ログ４１４のデータ例を示し、（Ｂ）は修正ログ４１５のデータ例を示す。
図１３に示す修正通知ログ４１４は、「通知ＩＤ」、「通知時刻」、「修正箇所」、「内容」、「対応の履歴」により構成される。
「通知ＩＤ」は、通知を区別するための識別子であり、図１３（Ａ）では、「１０００１」が例示されている。なお、１つの修正に対して複数の通知先がある場合、各通知先への通知毎に通知ＩＤが発行される。

「通知時刻」は、他のＲＰＡの担当者への通知の時刻を表す情報であり、通知ＩＤ毎に記録される。
「修正箇所」は、修正の箇所を表す情報である。
「内容」は、修正の内容を表す情報である。
「対応の履歴」は、通知後の他のＲＰＡが修正されたか否かが記録される。他のＲＰＡの対応は、構成情報ＤＢ４１３の更新により確認が可能である。修正が確認されない場合、空欄のままとなる。

図１３に示す修正ログ４１５は、「修正ＩＤ」、「修正時刻」、「修正箇所」、「内容」により構成される。
「修正ＩＤ」は、修正を区別するための識別子であり、図１３（Ｂ）では、「５０００１」が例示されている。
「修正時刻」は、修正が実行された時刻を表す情報であり、修正ＩＤ毎に記録される。
「修正箇所」は、修正の箇所を表す情報である。
「内容」は、修正の内容を表す情報である。

＜処理動作＞
図１４は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の一例を説明するフローチャートである。
以下の処理は、プロセッサ４０１（図２参照）による修正共有プログラム４１２Ｂ（図１２参照）の実行を通じて実現される。
まず、ＲＰＡ端末４０－１は、修正通知ログ４１４を参照し、修正の通知から予め定めた時間が経過したか否かを判定する（ステップ１４１）。

ステップ１４１で否定結果が得られている間、ＲＰＡ端末４０－１は、ステップ１４１の判定を繰り返す。なお、ステップ１４１の判定は、修正通知ログ４１４に記憶されている通知毎に判定される。
ステップ１４１で肯定結果が得られた場合、ＲＰＡ端末４０－１は、他のＲＰＡに対応の履歴があるか否かを判定する（ステップ１４２）。ここで、対応の履歴があるとは、例えば同じ修正を実行する場合をいう。

ステップ１４２で肯定結果が得られた場合、ＲＰＡ端末４０－１は、判定の対象である他のＲＰＡは野良ロボでないと判定し、処理を終了する。
一方、ステップ１４２で否定結果が得られた場合、ＲＰＡ端末４０－１は、担当者に未対応のＲＰＡの情報を通知する（ステップ１４３）。未対応のＲＰＡの情報には、例えばＲＰＡ名や担当者の情報も含まれる。この通知により、野良ロボを整理する機会が与えられる。

＜実施の形態４＞
本実施の形態では、ネットワーク１０及び１０Ａに接続されている全てのＲＰＡ端末４０の構成情報を集約した構成情報ＤＢ４１３（図２参照）を用いない。
＜システムの全体構成＞
実施の形態４も、実施の形態１と同じ情報処理システム１（図１参照）を使用する。
本実施の形態の場合、修正を受け付けたＲＰＡ端末４０に、受け付けた修正を同じネットワーク上の他の全てのＲＰＡ端末にブロードキャストする機能が設けられる。

＜ＲＰＡ端末の構成＞
図１５は、実施の形態５で使用するＲＰＡ端末４０のハードウェア構成の一例を説明する図である。図１５には、図２との対応部分に対応する符号を付して示している。
図１５に示すＲＰＡ端末４０の場合、ハードディスクドライブ４１０には、実行ルーチン４１１と、修正共有プログラム４１２Ｃと、自端末構成情報４１６が記憶されている。
また、プロセッサ４０１による修正共有プログラム４１２Ｃの実行により実現される機能として修正ブロードキャスト部４０１Ｈと関連性判定部４０１Ｊが追加され、関連ＲＰＡ抽出部４０１Ｄ（図２参照）が削除される。

本実施の形態では、自端末構成情報４１６を使用する。自端末構成情報４１６は、自端末で動作するＲＰＡの構成情報だけで構成される。換言すると、自端末構成情報４１６は、他のＲＰＡ端末４０で動作するＲＰＡの構成情報は含まない。
本実施の形態では、修正との関連性を、修正の内容のブロードキャストを受けた他のＲＰＡ端末４０が判定するためである。

図１６は、自端末構成情報４１６のデータ構造の一例を説明する図である。図１６には、図３との対応部分に対応する符号を付して示している。
図１６に示すデータは、「ＲＰＡ名」、「ＩＤ」、「プログラム構成」、「属性値」、「特徴情報」により構成される。
「ＲＰＡ名」は、ＲＰＡに付されている名称であり。図１６では、「ＲＰＡ名」として、「住所管理」が例示されている。
「ＩＤ」は、ＲＰＡの識別子であり、図１６では、「Ｒ００１」が例示されている。

「プログラム構成」には、実行ルーチンを組み立てる際に使用した部品、部品の組み合わせパターン、標準的なテンプレート、共通ライブラリ、プログラムの名称等がある。
「属性値」は、実行ルーチンがアクセスするＲＰＡの内外のリソースの属性情報であり、例えば参照先の名称、参照先のアドレス、ログイン情報、アクセスキー等がある。
「特徴情報」は、対象とするＲＰＡの特徴に関する記載であり、ＲＰＡの属性情報や類似性の判定に使用される。
これらは、図３で示した構成情報ＤＢ４１３（図３参照）の項目と共通である。ただし、自端末構成情報４１６は、前述したように、各ＲＰＡ端末４０で実行中のＲＰＡに関する構成情報だけで構成される。

図１５の説明に戻る。
修正ブロードキャスト部４０１Ｈは、自端末で動作するＲＰＡの修正を受け付けた場合に、ブロードキャストアドレスを使用して、修正の内容を同じネットワーク上に存在する他のＲＰＡ端末４０にブロードキャストする機能部である。すなわち、関連性の判定は、ブロード先に委ねられる。

関連性判定部４０１Ｊは、他のＲＰＡ端末４０からブロードキャストを受けた修正の内容と自端末で動作するＲＰＡとの関連性を判定する機能部である。
関連性の判定には、自端末構成情報４１６が用いられる。
関連性判定部４０１Ｊによる関連性の判定は、関連ＲＰＡ抽出部４０１Ｄ（図２参照）と同様に実行される。具体的には、関連性判定部４０１Ｊは、自端末構成情報４１６に記録されている情報との照合により、通知を受けた修正の内容と自端末で動作するＲＰＡとの関連性を判定する。

本実施の形態で使用する関連性判定部４０１Ｊは、自端末との関連性を認めた場合、該当するＲＰＡの担当者に通知する機能を含んでいる。すなわち、本実施の形態の場合も、担当者の確認を経ることなしに、他のＲＰＡの担当者が行った修正を適用することはない。もっとも、システムの管理者など、システム上の全てのＲＰＡの保守等を管理する担当者からの通知の場合には、受信した修正の内容を自端末のＲＰＡに適用してもよい。

＜処理動作＞
＜ブロードキャスト側の処理動作１＞
図１７は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の一例を説明するフローチャートである。以下の処理は、プロセッサ４０１（図２参照）による修正共有プログラム４１２Ｃ（図１５参照）の実行を通じて実現される。
まず、ＲＰＡ端末４０－１は、ＲＰＡの修正を受け付ける（ステップ１５１）。ＲＰＡ端末４０－１に対する修正の指示には、修正する箇所と修正の内容とを個別に指示する方法と、修正済みの実行ルーチン４１１（図１５参照）をアップロードする方法とがある。

次に、ＲＰＡ端末４０－１は、受け付けた修正を実行する（ステップ１５２）。本実施の形態の場合も、修正の実行は、例えば即座に実行する場合、夜間や休日等の業務時間外に実行する場合、受け付けた修正を蓄積し、週１回等の予め定めたタイミングに実行する場合がある。いずれにしても、本実施の形態の場合、受け付けた修正は全て実行される。
その後、ＲＰＡ端末４０－１は、修正の内容をブロードキャストする（ステップ１５３）。前述したように、ブロードキャストの宛先は、自端末を除く、システム上の全てのＲＰＡ端末４０である。
以上で、修正を受け付けたＲＰＡ端末４０の処理動作が完了する。

＜ブロードキャスト側の処理動作２＞
図１８は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の他の一例を説明するフローチャートである。図１８には、図１７との対応部分に対応する符号を付して示している。
図１８に示す処理動作は、ステップ１５１の実行後に判定処理が追加される点で、図１７に示す処理動作と相違する。

図１８の場合、ステップ１５１の実行後に、プロセッサ４０１は、指示が予め定めた条件を満たすか否かを判定する（ステップ１６１）。予め定めた条件には、例えば運用を開始してからの経過時間が予め定めた期間内であることがある。予め定めた期間には、例えば１４日や３０日を使用する。運用を開始した直後は手直しも多く、修正した内容が正しいとも限らない。また、頻繁な通知を他のＲＰＡの担当者が望まない場合もあるためである。

ステップ１６１で肯定結果を満たす場合、すなわち予め定めた条件を満たす場合、プロセッサ４０１は、修正の内容をブロードキャストすることなく、そのまま処理を終了する。
一方、ステップ１６１で否定結果が得られた場合、プロセッサ４０１は、ステップ１５２に進み、受け付けた修正を実行する（ステップ１５２）。
その後、ＲＰＡ端末４０－１は、修正の内容をブロードキャストする（ステップ１５３）。
以上で、修正を受け付けたＲＰＡ端末４０－１の処理動作が完了する。

＜ブロードキャストを受ける側の処理動作＞
図１９は、修正を受け付けたＲＰＡ端末４０－２及び４０－３（図４参照）で実行される処理動作の一例を説明するフローチャートである。以下の処理は、プロセッサ４０１（図２参照）による修正共有プログラム４１２Ｃ（図１５参照）の実行を通じて実現される。以下では、ＲＰＡ端末４０－２（図４参照）の動作として説明する。
まず、ＲＰＡ端末４０－２は、他のＲＰＡ端末４０－１（図４参照）から修正の内容を受け付ける（ステップ１７１）。
修正の内容を受け付けたＲＰＡ端末４０－２は、通知を受けた修正の内容が、自端末で動作するＲＰＡと関連するか否かを判定する（ステップ１７２）。

修正の内容に関連するＲＰＡが見つからない場合、ＲＰＡ端末４０－２は、ステップ１７２で否定結果を得て、そのまま処理を終了する。
一方、修正の内容に関連するＲＰＡが見つかった場合、ＲＰＡ端末４０－２は、ステップ１７２で肯定結果を得て、関連するＲＰＡの担当者に修正の内容を通知する（ステップ１７３）。この通知により、他のＲＰＡの担当者は、自身が担当するＲＰＡに関連する可能性がある修正の発生に気づくことが可能になる。
本実施の形態の場合、通知を受けた担当者は、修正の内容に「合意する」、「合意しない」、「放置する」等の対応をとる。

続いて、ＲＰＡ端末４０－２は、担当者から合意を受け付けたか否かを判定する（ステップ１７４）。
ステップ１７４で否定結果が得られた場合、ＲＰＡ端末４０－２は、通知を受けた修正を適用することなく処理を終了する。
一方、ステップ１７４で肯定結果が得られた場合、ＲＰＡ端末４０－２は、通知を受けた修正を実行する（ステップ１７５）。この修正の実行により、ＲＰＡ端末４０－１側のＲＰＡとＲＰＡ端末４０－２側のＲＰＡとの整合性が保たれることになる。

なお、ステップ１７４の判定の結果は、修正の内容をブロードキャストしたＲＰＡ端末４０－１に送信されてもよい。
例えばこの送信は、実施の形態２で説明したように、ＲＰＡ端末４０－１における処理の実行の可否の判定に使用される。
本実施の形態の場合、各ＲＰＡ端末４０が記憶する構成情報は、自端末で動作中のＲＰＡに限定されるので、他のＲＰＡについての修正との関連性を判定する場合にも、処理上の負荷が小さく済む。

＜実施の形態５＞
本実施の形態では、ブロードキャスト後も未対応のＲＰＡの通知やブロードキャストの後で関連するＲＰＡが登録される場合への対応するための技術について説明する。

＜システムの全体構成＞
実施の形態５も、実施の形態１と同じ情報処理システム１（図１参照）を使用する。
本実施の形態の場合、ＲＰＡ端末４０に機能が追加される。

＜ＲＰＡ端末の構成＞
図２０は、実施の形態５で使用するＲＰＡ端末４０のハードウェア構成の一例を説明する図である。図２０には、図１５と図１２との対応部分に対応する符号を付して示している。
図２０に示すＲＰＡ端末４０の場合、ハードディスクドライブ４１０には、実行ルーチン４１１と、修正共有プログラム４１２Ｄと、修正ログ４１５と、自端末構成情報４１６と、ブロードキャストログ４１７が記憶される。このうち、ブロードキャストログ４１７は、図１２の修正通知ログ４１４が対応する。

また、プロセッサ４０１による修正共有プログラム４１２Ｄの実行により実現される機能として、修正受付部４０１Ｂ、修正実行部４０１Ｃ、修正ブロードキャスト部４０１Ｈ、関連性判定部４０１Ｊ、通知管理部４０１Ｋが実行される。換言すると、図１５に示す機能に、通知管理部４０１Ｋが追加される。

なお、通知管理部４０１Ｋは、通知管理部４０１Ｇ（図１２参照）に対応する。もっとも、本実施の形態における通知管理部４０１Ｋは、ブロードキャスト後における他のＲＰＡの担当者による修正への対応の状況を管理する。
また、通知管理部４０１Ｋは、「通知時刻」からの経過の時間が予め定めた時間を経過しても「対応の履歴」が空欄の場合、対応が確認されない他のＲＰＡを野良ロボとみなし、アラームを出力する。アラームの出力先は、例えばシステムの管理者である。

＜処理動作＞
図２１は、修正を受け付けたＲＰＡ端末４０－１（図４参照）で実行される処理動作の一例を説明するフローチャートである。
以下の処理は、プロセッサ４０１（図２参照）による修正共有プログラム４１２Ｄ（図２０参照）の実行を通じて実現される。
まず、ＲＰＡ端末４０－１は、ブロードキャストログ４１７を参照し、修正をブロードキャストしてから予め定めた時間が経過したか否かを判定する（ステップ１８１）。

ステップ１８１で否定結果が得られている間、ＲＰＡ端末４０－１は、ステップ１８１の判定を繰り返す。なお、ステップ１８１の判定は、ブロードキャストログ４１７に記憶されているブロードキャスト毎に判定される。
ステップ１８１で肯定結果が得られた場合、ＲＰＡ端末４０－１は、他のＲＰＡに対応の履歴があるか否かを判定する（ステップ１８２）。ここで、対応の履歴があるとは、例えば同じ修正を実行する場合をいう。

ステップ１８２で肯定結果が得られた場合、ＲＰＡ端末４０－１は、判定の対象である他のＲＰＡは野良ロボでないと判定し、処理を終了する。
一方、ステップ１８２で否定結果が得られた場合、ＲＰＡ端末４０－１は、担当者に未対応のＲＰＡの情報を通知する（ステップ１８３）。未対応のＲＰＡの情報には、例えばＲＰＡ名や担当者の情報も含まれる。この通知により、野良ロボの整理の機会が与えられる。

＜他の実施の形態＞
（１）以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の修正又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

（２）前述の実施の形態においては、ＲＰＡに対する修正を受け付けたＲＰＡ端末４０又は他のＲＰＡ端末４０からブロードキャストを受けた側のＲＰＡ端末４０が、受け付けた修正の内容との関連性を自律的に判定しているが、ユーザが関連性を指示してもよい。
例えば専用のユーザインタフェースを用意してもよい。新たなＲＰＡを開発する場合、専用のユーザインタフェースに予想される構成要素を検索キーとして入力すると、構成情報ＤＢ４１３（図２参照）を検索した結果が担当者に提示されるようにしてもよい。

修正を指示する前に、関連性があるＲＰＡの数等が分かれば、既に稼働しているＲＰＡをひな形として利用することも可能になる。
また、稼働中のＲＰＡに変更を加えたい場合にも、ほぼ同等の処理を有する他のＲＰＡが事前に見つかった場合、他のＲＰＡを稼働中のＲＰＡに統合することにより、システム内から野良ロボが削減される。結果的に、信頼性の向上と保守コストの低減が実現される。

（３）前述の実施の形態においては、ＲＰＡが実行されるＲＰＡ端末４０において修正の内容との関連性を判定する機能を用意する場合について説明したが、関連性の判定を一括的に実行する管理用のサーバをネットワーク１０やネットワーク１０Ａ上に配置してもよい。この場合、構成情報ＤＢ４１３（図２参照）もＲＰＡ端末４０とは別の端末に記憶してもよい。

（４）前述の実施の形態１～３においては、修正を受け付けたＲＰＡ端末４０が、関連性が認められた他のＲＰＡの担当者に対して修正を通知しているが、他のＲＰＡが実行される他のＲＰＡ端末４０に修正を通知してもよい。その場合、修正の通知を受けた他のＲＰＡ端末４０が、通知の対象である他のＲＰＡの担当者に、関連する修正の発生を通知してもよい。ここでの他のＲＰＡ端末４０は、関連する他のＲＰＡの担当者と同じく、関連先の一例である。

（５）前述の実施の形態においては、最初に修正を行った担当者に対して、関連するＲＰＡの数等を通知する場合について説明したが、関連するＲＰＡを担当する担当者の人数を通知してもよいし、ＲＰＡ端末４０の台数を通知してもよい。

（６）前述した各実施の形態におけるプロセッサは、広義的な意味でのプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ等）の他、専用的なプロセッサ（例えばＧＰＵ（＝Graphics Processing Unit）、ＡＳＩＣ（＝Application Specific Integrated Circuit）、ＦＰＧＡ（＝Field Programmable Gate Array）、プログラム論理デバイス等）を含む。
また、前述した各実施の形態におけるプロセッサの動作は、１つのプロセッサが単独で実行してもよいが、物理的に離れた位置に存在する複数のプロセッサが協働して実行してもよい。また、プロセッサにおける各動作の実行の順序は、前述した各実施の形態に記載した順序のみに限定されるものでなく、個別に修正してもよい。

１…情報処理システム、１０、１０Ａ…ネットワーク、２０…画像形成装置、３０Ａ…業務サーバ、３０Ｂ…クラウドサーバ、４０、４０－１、４０－２、４０－３、４０－Ｎ…ＲＰＡ端末、５０、５０－１、５０－２、５０－Ｍ…担当者端末、４０１Ａ…ＲＰＡ実行部、４０１Ｂ…修正受付部、４０１Ｃ…修正実行部、４０１Ｄ…関連ＲＰＡ抽出部、４０１Ｅ…修正通知部、４０１Ｆ…修正応答部、４０１Ｇ、４０１Ｋ…通知管理部、４０１Ｈ…修正ブロードキャスト部、４０１Ｊ…関連性判定部、４１１…実行ルーチン、４１２、４１２Ａ、４１２Ｂ、４１２Ｃ、４１２Ｄ…修正共有プログラム、４１３…構成情報ＤＢ、４１４…修正通知ログ、４１５…修正ログ、４１６…自端末構成情報、４１７…ブロードキャストログ

Claims (21)

1. コンピュータに、
   ＲＰＡに対する修正の指示が検知された場合、修正に関連する他のＲＰＡをデータベースから抽出する機能と、
   前記指示の検知を、抽出された前記他のＲＰＡの関連先に通知する機能と、
   を実現させるためのプログラム。
2. 前記コンピュータは、
   前記データベースに登録されている複数のＲＰＡのうち、修正の対象とする前記ＲＰＡと、構成上の情報が類似するＲＰＡを、前記他のＲＰＡとして抽出する、
   請求項１に記載のプログラム。
3. 前記コンピュータは、
   前記修正の対象と共通する構成上の要素を有するＲＰＡを、前記他のＲＰＡとして抽出する、
   請求項２に記載のプログラム。
4. 前記コンピュータは、
   前記修正の内容を、前記他のＲＰＡの担当者に通知する、
   請求項１に記載のプログラム。
5. 前記コンピュータは、
   前記他のＲＰＡの担当者から同意が得られるまで、検知された指示に対応する前記修正の実行を停止する、
   請求項４に記載のプログラム。
6. 前記コンピュータは、
   前記他のＲＰＡに関する情報を、前記修正を指示した担当者に通知する、
   請求項１に記載のプログラム。
7. 前記コンピュータは、
   前記他のＲＰＡに関する情報として、当該ＲＰＡの数を通知する、
   請求項６に記載のプログラム。
8. 前記コンピュータは、
   前記他のＲＰＡに関する情報として、当該ＲＰＡの特徴を通知する、
   請求項６に記載のプログラム。
9. 前記コンピュータは、
   前記指示が予め定めた条件を満たす場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、
   請求項１に記載のプログラム。
10. 前記コンピュータは、
    前記指示が予め定めた期間に検知された場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、
    請求項９に記載のプログラム。
11. 前記コンピュータは、
    前記関連先への通知の履歴と、前記他のＲＰＡにおける対応の履歴とを管理する、
    請求項１に記載のプログラム。
12. 前記コンピュータは、
    前記通知から予め定めた時間が経過した後も、対応が記録されない前記他のＲＰＡを検出した場合、当該他のＲＰＡを特定する情報を、前記修正を指示した担当者に通知する、
    請求項１１に記載のプログラム。
13. コンピュータに、
    ＲＰＡに対する修正の指示が検知された場合、データベースに登録されている他のＲＰＡを読み出す機能と、
    読み出された前記他のＲＰＡに紐付けられている端末に対し、前記修正の内容を通知する機能と、
    を実現させるためのプログラム。
14. 前記コンピュータは、
    前記修正の内容を外部から受信した場合において、当該修正の内容が自端末のＲＰＡに関連するとき、自端末のＲＰＡの担当者に、当該修正の内容を通知する、
    請求項１３に記載のプログラム。
15. 前記コンピュータは、
    前記修正の内容の送信元に対し、前記修正の内容に対する前記担当者の同意を通知する、
    請求項１４に記載のプログラム。
16. 前記コンピュータは、
    前記指示が予め定めた条件を満たす場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、
    請求項１３に記載のプログラム。
17. 前記コンピュータは、
    前記指示が予め定めた期間に検知された場合、前記指示の検知を前記他のＲＰＡの関連先に通知しない、
    請求項１６に記載のプログラム。
18. 前記コンピュータは、
    関連先への通知の履歴と、前記他のＲＰＡにおける対応の履歴とを管理する、
    請求項１３に記載のプログラム。
19. 前記コンピュータは、
    前記通知から予め定めた時間が経過した後も、対応が記録されない前記他のＲＰＡを検出した場合、当該他のＲＰＡを特定する情報を、前記修正を指示した担当者に通知する、
    請求項１８に記載のプログラム。
20. プロセッサを有し、
    前記プロセッサは、
    ＲＰＡに対する修正の指示が検知された場合、修正に関連する他のＲＰＡをデータベースから抽出し、
    前記指示の検知を、抽出された前記他のＲＰＡの関連先に通知する、
    情報処理装置。
21. プロセッサを有し、
    前記プロセッサは、
    ＲＰＡに対する修正の指示が検知された場合、データベースに登録されている他のＲＰＡを読み出し、
    読み出された前記他のＲＰＡに紐付けられている端末に対し、前記修正の内容を通知する、
    情報処理装置。

Images