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

Description

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

特許文献１には、ワークフローで定めた経路に従って電子文書を回覧して承認又は決裁を行うワークフローシステムにおいて、電子文書のワークフロー処理が滞留期限を超過している場合に承認者又は決済者の上長を代行者に設定する機能を設けることが記載されている。

特開２００７－１５６６７８号公報

しかし、承認等を行えるユーザが特定の個人に限定される場合や代行による決済が許されない場合には、特許文献１に記載の技術によっても、回覧の滞留は解消されない。

本発明は、滞留する回覧の検知後に承認等の代行が可能なユーザを探す場合に比して、回覧の滞留を未然に予防できるようにすることを目的とする。

請求項１に記載の発明は、プロセッサを有し、前記プロセッサは、ワークフローシステムに登録されているユーザのスケジュールを取得し、申請を処理する特定のユーザについての不在の予定が検出された場合、当該特定のユーザの不在の予定を、申請の履歴が予め定めた条件を満たすユーザに通知する、情報処理装置である。
請求項２に記載の発明は、前記条件を満たすユーザは、申請の回数又は申請の頻度が予め定めた閾値を超えるユーザである、請求項１に記載の情報処理装置である。
請求項３に記載の発明は、前記条件を満たすユーザは、申請から希望する納期までの期間の長さの平均値が予め定めた閾値より短いユーザである、請求項１に記載の情報処理装置である。
請求項４に記載の発明は、コンピュータに、ワークフローシステムに登録されているユーザのスケジュールを取得する機能と、申請を処理する特定のユーザについての不在の予定が検出された場合、当該特定のユーザの不在の予定を、申請の履歴が予め定めた条件を満たすユーザに通知する機能とを実現させるプログラムである。

請求項１記載の発明によれば、申請を行う可能性が高いユーザに通知できる。
請求項２記載の発明によれば、不在の影響を受ける可能性が高いユーザに通知できる。
請求項３記載の発明によれば、不在の影響を受ける可能性が高いユーザに通知できる。
請求項４記載の発明によれば、申請を行う可能性が高いユーザに通知できる。

実施の形態で使用するワークフロー管理システムの構成例を示す図である。 実施の形態で使用するスケジュールサーバの構成例を説明する図である。 実施の形態で使用するワークフローサーバの構成例を説明する図である。 アプリ別利用状況ＤＢに格納されるデータの構造例を説明する図である。 アプリ別利用状況ＤＢの具体例を説明する図である。 ユーザ権限ＤＢに格納されるデータの構造例を説明する図である。 連携アプリの定義の一例を説明する図である。 ワークフローサーバで実行される処理動作の一例を示すフローチャートである。 予め定めた条件を満たすユーザが使用する情報端末に表示される画面の一例を説明する図である。 ワークフローサーバで実行される他の処理動作の一例を示すフローチャートである。 申請の履歴が存在しないユーザが使用する情報端末に表示される画面の一例を説明する図である。 ワークフローサーバで実行される他の処理動作の一例を示すフローチャートである。 処理動作３で想定する申請後の処理の流れと承認者であるユーザＥの不在期間との関係を説明する図である。 ユーザＡによる見積書の申請を説明する図である。 承認者に回覧する申請の事務を担当するユーザが操作する情報端末に表示される画面の一例を説明する図である。

以下、図面を参照して、本発明の実施の形態を説明する。

＜実施の形態＞
＜システム構成＞
図１は、実施の形態で使用するワークフロー管理システム１の構成例を示す図である。
図１に示すワークフロー管理システム１は、ワークフローを使用する権限を有するユーザが操作する情報端末１０Ａ～１０Ｅと、ユーザのスケジュールを管理するスケジュールサーバ２０と、ワークフローとして定義された業務の流れを制御するワークフローサーバ３０とを有している。
これらの端末は、いずれもネットワーク４０に接続されている。本実施の形態の場合、ネットワーク４０は、ＬＡＮ（＝Local Area Network）である。もっとも、ネットワーク４０の全部又は一部は、インターネット又はクラウドネットワークでもよい。

本実施の形態においては、「ワークフロー」との用語を、複数人のユーザが関与する業務の流れの意味で使用する。
本実施の形態におけるワークフローは、例えば申請、承認、決裁、保管等の各工程の組み合わせにより規定されている。もっとも、ワークフローを規定する各工程の内容や組み合わせは、ワークフローを運用する目的やワークフローを運用する事業者により異なる。
ワークフローで扱う電子文書には、例えば業務に使用するアプリケーションプログラムで作成された文書、電子メール、紙文書を電子化した文書、写真、画像その他が含まれる。以下、アプリケーションプログラムを「アプリ」という。
本実施の形態の場合、ワークフローと連携して、ユーザの業務上の作業を支援するアプリを「業務支援アプリ」ともいう。

図１の場合、情報端末１０Ａは、ユーザＡが操作する端末である。情報端末１０Ｂは、ユーザＢが操作する端末である。情報端末１０Ｃは、ユーザＣが操作する端末である。情報端末１０Ｄは、ユーザＤが操作する端末である。情報端末１０Ｅは、ユーザＥが操作する端末である。なお、不特定のユーザが操作する端末を情報端末１０という。
図１では、５名のユーザを想定しているがユーザの人数は任意である。
ユーザが操作する情報端末１０は、特定のユーザに専用の端末である必要はない。本実施の形態の場合、ログインに用いたアカウントにより、情報端末１０を操作するユーザを特定する。
情報端末は、例えばデスクトップ型のコンピュータ、ノート型のコンピュータ、タブレット型のコンピュータ、スマートフォンである。

スケジュールサーバ２０は、ワークフローを使用する権限を有するユーザのスケジュールを管理するサーバである。本実施の形態の場合、スケジュールは、出勤日のスケジュール、出張等の外出のスケジュール、休暇のスケジュール等を含む。なお、スケジュールには、会議の予定を含めてもよい。
本実施の形態では、ユーザがワークフローにアクセスして業務を行う予定がない期間を「不在期間」という。例えば休日やユーザが個人的に申請した休暇日は、不在期間の一例である。

ワークフローサーバ３０は、ワークフロー上における電子文書の受け渡しや処理の進捗を管理するサーバである。
本実施の形態の場合、ワークフローを規定する各工程には、それぞれに対応する業務支援アプリが用意されている。業務支援アプリには、例えば属性を管理するアプリ、属性を設定するアプリ、電子文書を管理するアプリ、電子文書の活用に関するアプリがある。

属性を管理するアプリは、例えば電子文書からタイトルを抽出してデータベースに登録する機能を提供する。属性を設定するアプリは、電子文書を解析してデータベースに属性を登録する機能を提供する。ここでの登録には、属性の追加も含まれる。電子文書を管理するアプリは、規則に従って電子文書にファイル名を付与する機能や電子文書を保管するフォルダを規則に従って決定する機能を提供する。電子文書の活用に関するアプリは、規則に従って電子文書を送信する機能を提供する。業務支援アプリの内容は、ワークフローの内容によっても異なる。
本実施の形態におけるワークフローサーバ３０は、情報処理装置の一例である。

本実施の形態では、スケジュールサーバ２０とワークフローサーバ３０を、それぞれ独立したサーバとして説明するが、スケジュールサーバ２０とワークフローサーバ３０は、単一のサーバでもよい。
図１の場合、スケジュールサーバ２０とワークフローサーバ３０は同じネットワーク４０に接続されているが、異なるネットワーク経由で接続されていてもよい。
また、図１に示すワークフロー管理システム１の場合、スケジュールサーバ２０とワークフローサーバ３０はそれぞれ１台であるが、複数台のサーバの連携により各サーバの機能を実現してもよい。

＜スケジュールサーバの構成＞
図２は、実施の形態で使用するスケジュールサーバ２０の構成例を説明する図である。
図２に示すスケジュールサーバ２０は、装置全体の動作を制御する演算ユニット２０１と、ハードディスク駆動装置（＝HDD：Hard Disk Drive）２０２と、入出力（＝I/O：Input/Output）ポート２０３と、外部装置との通信を実現する通信ユニッ２０４とを有している。これらの各部は、各種の信号線により接続されている。

演算ユニット２０１には、プロセッサの一例であるＣＰＵ（＝Central Processing Unit）２０１Ａと、ＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）２０１Ｂと、ワークエリアとして用いられるＲＡＭ（＝Random Access Memory）２０１Ｃとが設けられている。
演算ユニット２０１は、いわゆるコンピュータであり、業務支援アプリその他のプログラムの実行を通じて各種の機能を提供する。

ハードディスク駆動装置２０２は、不揮発性の記憶媒体である磁気ディスクを駆動する装置であり、各種のデータを保管するデータベースとして用いられる。
図２の場合、各種のデータの一例として、スケジュール管理テーブル２０２Ａが示されている。本実施の形態におけるスケジュール管理テーブル２０２Ａは、ユーザ別にスケジュールを管理している。

＜ワークフローサーバの構成＞
図３は、実施の形態で使用するワークフローサーバ３０の構成例を説明する図である。
図３に示すワークフローサーバ３０は、装置全体の動作を制御する演算ユニット３０１と、ハードディスク駆動装置３０２と、入出力ポート３０３と、外部装置との通信を実現する通信ユニット３０４と、指示等の入力に用いる入力ユニット３０５と、情報の表示に用いる表示ユニット３０６とを有している。これらの各部は、各種の信号線により接続されている。

演算ユニット３０１は、プロセッサの一例であるＣＰＵ３０１Ａと、ＢＩＯＳ等が記憶されたＲＯＭ３０１Ｂと、ワークエリアとして用いられるＲＡＭ３０１Ｃ等が設けられている。
演算ユニット３０１は、いわゆるコンピュータであり、プログラムの実行を通じて各種の機能を提供する。
ハードディスク駆動装置３０２は、不揮発性の記憶媒体である磁気ディスクを駆動する装置であり、ワークフローの管理に関連する各種のデータを保管するデータベース（＝DB：DataBase）として用いられる。

図３では、ハードディスク駆動装置３０２が格納するデータの一例として、ワークフローテーブル３０２Ａ、ユーザリスト３０２Ｂ、申請者リスト３０２Ｃ、電子文書３０２Ｄ、アプリ別利用状況ＤＢ３０２Ｅ、ユーザ権限ＤＢ３０２Ｆを表している。
本実施の形態の場合、業務支援アプリは、情報端末１０にインストールされている。もっとも、業務支援アプリがワークフローサーバ３０上で実行される場合、業務支援アプリもハードディスク駆動装置３０２に格納される。

ワークフローテーブル３０２Ａには、ワークフローの管理で使用する各種のデータが格納される。各種のデータには、例えば過去に実行された処理の履歴も含まれる。処理の履歴には、処理を行ったユーザの属性に関する情報、処理の対象となった電子文書に関する情報、処理の内容等が含まれる。
ユーザリスト３０２Ｂは、ワークフローを使用する権限を有するユーザのリストである。前述したユーザＡ～Ｅは、ユーザリスト３０２Ｂで管理される。
申請者リスト３０２Ｃは、承認等を求める電子文書を申請したユーザのリストである。申請者リスト３０２Ｃのデータは、申請を受け付けるたびに更新される。
電子文書３０２Ｄは、ワークフローで扱われる文書であり、例えば契約書、見積書等である。

アプリ別利用状況ＤＢ３０２Ｅは、業務支援アプリ別に、ユーザの利用状況を管理するデータを格納する。
図４は、アプリ別利用状況ＤＢ３０２Ｅに格納されるデータの構造例を説明する図である。
図４には、複数の業務支援アプリの１つである業務支援アプリＸのデータ構造が示されている。もっとも、他の業務支援アプリのデータ構造も、業務支援アプリＸのデータ構造と同じである。

図４の場合、アプリ別利用状況ＤＢ３０２Ｅには、業務支援アプリ毎に、ユーザ別の利用頻度の平均値と申請から希望の納期（以下「希望納期」という）までの期間の平均値が格納されている。希望納期とは、申請の際に申請者が指定する納期である。
利用頻度の平均値と申請から希望納期までの期間の平均値は、ワークフローテーブル３０２Ａに格納される処理の履歴に基づいて算出される。
本実施の形態では、利用頻度を申請の頻度の意味で使用する。本実施の形態では、申請する可能性が高いユーザを発見する目的で、利用頻度の情報を用いるためである。従って、申請された電子文書に関する事務作業のためにユーザが業務支援アプリを利用した回数は、利用頻度の平均値の算出から除外される。

ただし、計算される平均値の信頼性を高めるためには、予め定めた回数以上の申請を行ったユーザに限り、平均値を計算してもよい。勿論、１回でも申請の履歴があれば、平均値の計算は可能である。
平均値を計算する期間は、予め定めた期間について設定される。予め定めた期間には、例えばワークフロー管理システム１の使用を開始した時刻から現在時刻までの期間、現在時刻までの直近１年の期間、現在時刻までの直近半年の期間、管理者が任意に指定した期間がある。いずれの期間を使用するかは、初期設定により指定されてもよいし、管理者が指定してもよい。

平均値の計算に使用する対象期間が長くなると、以前は利用の回数が多かったが最近は利用の回数が少ないユーザと、以前は利用の回数が少なかったが最近は利用の回数が多いユーザとで計算される平均値が同じになる可能性がある。
しかし、平均値の計算に使用する対象期間として、直近１年や直近半年の期間を用いれば、現在の利用の状況に近い平均値を算出することが可能になる。
平均値の計算に使用する対象期間は、ユーザによる設定が可能である。

本実施の形態では、利用頻度の平均値を計算しているが、利用頻度の平均値に代えて又は一緒に、予め定めた期間内における申請の回数を使用してもよい。
予め定めた期間には、ワークフロー管理システム１の使用を開始した時刻から現在時刻までの期間を用いてもよいし、現在時刻までの直近１年の期間を用いてもよいし、現在時刻までの直近半年の期間を用いてもよいし、管理者が任意に指定した期間を用いてもよい。
もっとも、現在時刻までの直近１年の間に行われた申請の回数や現在時刻までの直近半年の間に行われた申請の回数は、同期間に行われた申請の回数の平均値と同じである。

図５は、アプリ別利用状況ＤＢ３０２Ｅの具体例を説明する図である。図５に示すテーブルは、業務支援アプリＸに関する利用状況を表している。
図５の場合、ユーザＡによる業務支援アプリＸの利用頻度の平均値は１箇月に４回の割合であり、申請から希望納期までの期間の平均値は５日である。
また、ユーザＢによる業務支援アプリＸの利用頻度の平均値は１箇月に１回の割合であり、申請から希望納期までの平均値は３日である。ユーザＣによる業務支援アプリＸの利用頻度の平均値は１年に１回の割合であり、申請から希望納期までの期間の平均値は７日である。
図５の場合、ユーザＡによる業務支援アプリＸの利用頻度が最も高く、ユーザＣによる業務支援アプリＸの利用頻度が最も低い。一方、業務支援アプリＸを利用するユーザの中では、ユーザＢによる申請から希望納期までの期間が最も短く、ユーザＣによる申請から希望納期までの期間が最も長い。

図３の説明に戻る。
ユーザ権限ＤＢ３０２Ｆは、業務支援アプリを利用する権限の有無や参照する権限の有無に関するデータを格納する。
図６は、ユーザ権限ＤＢ３０２Ｆに格納されるデータの構造例を説明する図である。図６に示すユーザ権限ＤＢ３０２Ｆにおいては、各ユーザが権限を有する業務支援アプリに○印を付して示している。
例えばユーザＡとＢは、業務支援アプリＸ、Ｙ、Ｚ、連携１を利用する権限を有している。ユーザＣは、業務支援アプリＸ、Ｙ、Ｚ、連携１、連携２を利用する権限を有している。ユーザＤは、業務支援アプリＸ、Ｙ、Ｚ、ＸＸ、連携１、連携２を利用する権限を有している。ユーザＥは、業務支援アプリＸ、Ｙ、Ｚ、ＸＸ、ＸＹ、ＸＺ、連携１、連携２を利用する権限を有している。

前述したように、業務支援アプリは、ワークフローを規定する個々の工程に対応する業務上の作業の支援を目的に用意されたアプリである。
これに対し、連携１や連携２に対応する連携アプリは、複数の業務支援アプリの組み合わせとして定義される。換言すると、連携アプリは、ワークフローの全体を構成する複数の工程の一部分に対応する。
図７は、連携アプリの定義の一例を説明する図である。図７に示す連携アプリは、業務支援アプリＸ（すなわち「アプリＸ」）、業務支援アプリＹ（すなわち「アプリＹ」）、業務支援アプリＺ（すなわち「アプリＺ」）等の組み合わせとして定義されている。

連携アプリは、ユーザや管理者による定義が可能である。例えばアプリＸは申請の受け付け事務を担当するユーザが使用するアプリであり、アプリＹは承認者としてのユーザが使用するアプリであり、アプリＺは承認後の事務作業を担当するユーザが使用するアプリである。
図７に示す連携アプリは、複数の業務支援アプリが実行順に直列に連結されているが、分岐路や結合路を含んでもよい。

＜ワークフローサーバの処理動作＞
＜処理動作１＞
以下では、ワークフローを用いた申請に滞留が発生する可能性が相対的に高いユーザに対し、承認者の不在を積極的に通知する処理動作について説明する。
図８は、ワークフローサーバ３０で実行される処理動作の一例を示すフローチャートである。なお、図中に示す記号のＳはステップを意味する。
処理動作１は、ユーザによる申請とは無関係に実行される。むしろ、処理動作１は、ユーザが申請する前に実行される。

本実施の形態の場合、ワークフローサーバ３０は、スケジュールサーバ２０に対し、ユーザのスケジュールを定期的に要求する（ステップ１）。
ワークフローサーバ３０は、承認者の不在の予定を通知する必要性が高いユーザを検知するため、予め定めた周期で、各ユーザのスケジュールを要求する。
予め定めた周期には、例えば１０分毎、３０分毎、１時間毎、２時間毎、６時間毎、１日毎を使用する。
もっとも、より短い周期でスケジュールを要求することも可能である。また、１日や予め定めた特定の曜日の予め定めた時刻に、各ユーザのスケジュールを要求してもよい。例えば月曜日～金曜日の９時、１２時、１５時、１８時、２１時に、スケジュールを要求してもよい。

要求を受信したスケジュールサーバ２０は、要求に対する応答として各ユーザのスケジュールを送信する（ステップ２）。もっとも、スケジュールサーバ２０が、予め定めた周期や時刻に、各ユーザのスケジュールをワークフローサーバ３０に通知してもよい。
次に、ワークフローサーバ３０は、受信した各ユーザのスケジュールを参照し、承認者に不在期間が予定されているか否かを判定する（ステップ３）。
ここでの承認者は、申請を処理する特定のユーザの一例である。図８では、承認者となるユーザの不在の予定を判定しているが、申請の事務作業を担当するユーザの不在の予定を判定してもよい。この場合は、申請の事務作業を担当するユーザも、申請を処理する特定のユーザの一例となる。

本実施の形態では、１日の不在も不在期間として扱うが、予め定めた日数以上連続した不在期間だけを、ステップ３における検出の対象としてもよい。例えば実働日の３日以上連続した不在期間だけを検出の対象とし、１日にだけの不在期間は検出の対象外としてもよい。
また、不在期間の予定を検索する期間は、現在時刻を基準として例えば２箇月先までの範囲に制限してもよい。例えば１年後に不在期間が予定されていても、直近の申請には影響しないためである。本実施の形態におけるワークフローサーバ３０は、現在時刻から１箇月先までの範囲で不在期間を検索する。
ステップ３で否定結果が得られた場合、ワークフローサーバ３０は、ステップ１に戻る。
一方、ステップ３で肯定結果が得られた場合、ワークフローサーバ３０は、アプリ別利用状況ＤＢ３０２Ｅ（図３参照）から申請の履歴を取得する（ステップ４）。

次に、ワークフローサーバ３０は、取得した申請の履歴について、予め定めた条件を満たすユーザを検索する（ステップ５）。
本実施の形態の場合、予め定めた条件として、申請の頻度が閾値を超えること、又は、申請の回数が閾値を超えること、又は、申請から希望納期までの期間が閾値よりも短いことを採用する。
例えば申請の頻度についての閾値には１箇月に３回を用いる。例えば申請の回数についての閾値には１年間に３６回を用いる。例えば申請から希望納期までの期間の平均値についての閾値には４日を用いる。

ここでの閾値は、例えば近日中に申請を行う可能性が高いユーザとみなす基準に応じて選択される。閾値は、初期設定で与えられてもよいし、管理者が定めてもよい。
予め定めた条件を満たすユーザの検索が終了すると、ワークフローサーバ３０は、該当するユーザに承認者の不在の予定等を通知する（ステップ６）。ここでの通知は、電子メールを用いてもよいし、プッシュ通知でもよい。プッシュ通知の場合、ユーザがワークフローのホーム画面等を開いていない状態でも、ユーザの操作とは無関係にメッセージが表示される。

図９は、予め定めた条件を満たすユーザが使用する情報端末１０に表示される画面３１０の一例を説明する図である。
画面３１０は、ステップ５（図８参照）の条件を満たすユーザが操作する情報端末１０に表示される。本実施の形態の場合、画面３１０は、利用頻度の平均値が閾値を超えるユーザＡが操作する情報端末１０Ａ（図１参照）と、申請から希望納期までの期間の平均値が閾値より短いユーザＢが操作する情報端末１０Ｂ（図１参照）に表示される。
画面３１０の表示は、過去の申請の履歴に基づいて実行されるので、ユーザＡとユーザＢが近日中に申請を行う予定があるかは分からない。

画面３１０には、条件を満たすユーザへのメッセージ３１１として、申請が滞留する原因となる承認者の不在の予定と、申請を促す文面と、不在の期間が提示される。
図９の場合、メッセージ３１１には、「承認を担当するＥ部長は、次の期間不在になります。」と、「申請の予定がある場合は申請をお急ぎください。」と、「期間：３／３１～４／１０」が提示されている。
この画面３１０の表示により、承認を担当するＥ部長に不在の予定があることを、申請の可能性が高いユーザＡとユーザＢに知らせることが可能になる。
なお、画面３１０が表示されるユーザは、申請を行う可能性が他のユーザに比して高いユーザである。換言すると、画面３１０が表示されるユーザは、申請の滞留の影響を受け易いユーザである。

画面３１０の表示により、ユーザＡは、予定されている申請の時期を早めて申請の滞留を避けることが可能になる。
一方のユーザＢは、申請の頻度はユーザＡより少ないが、申請から希望納期までの期間が他のユーザに比して短いユーザである。換言すると、ユーザＢは、Ｅ部長の不在により、他のユーザに比して希望納期の前に承認を得られないリスクが、他のユーザに比して高いユーザである。ユーザＢは、他のユーザに比して、申請から承認までの日数が平均的に少ないためである。
しかし、本実施の形態の場合、ユーザＢは、事前にＥ部長の不在に気づけるので、普段よりも申請を早める可能性が高くなる。結果的に、申請の滞留により希望納期前に承認が得られ易くなる。

本実施の形態の場合、現在時刻から１箇月先までの期間を対象として承認者であるユーザＥの不在期間の予定を申請の可能性が高いユーザに通知するので、何らの通知を行わない場合に比して、不在期間の前に申請の承認が終わる可能性が高くなる。
もっとも、現実には、急な不在の予定がスケジュールに登録される可能性もある。その場合でも、不在の予定が事前に通知されることで、不在を原因とする申請の滞留の可能性が低減される。
なお、画面３１０の表示の後に行われた申請の履歴は、アプリ別利用状況ＤＢ３０２Ｅ（図３参照）における申請から希望納期までの期間の平均値の計算から除外してもよい。画面３１０の表示後の申請は、ユーザに固有の行動を反映しない例外的な行動を含む可能性が高いためである。もっとも、除外するか否かは設定可能としてもよい。

本実施の形態の場合には、画面３１０に不在の期間も提示しているが、不在の予定の存在だけを画面３１０に提示してもよい。この場合でも、申請を予定しているユーザは、事前にＥ部長の不在の予定に気づいてスケジュールを確認する等の行動が可能になる。
また、画面３１０には、不在の理由が含まれてもよい。理由が分かることで、不在の期間の変更等を予想することが容易になる。
また、画面３１０には、不在の期間の間にＥ部長の代わりに承認を行うユーザの情報が表示されてもよい。

＜処理動作２＞
前述した処理動作１による通知には、少なくとも１回は、申請の履歴が存在することが必要となる。申請を行ったことが無いユーザには、申請の履歴が存在しないためである。
このため、前述した処理動作１の場合、過去に申請を行ったことがないユーザには、承認者の不在の予定を通知し得ない。
処理動作２は、処理動作１の手法では承認者の不在の予定を受け取れないユーザへの通知を実現する処理動作について説明する。
図１０は、ワークフローサーバ３０で実行される他の処理動作の一例を示すフローチャートである。図１０には、図８との対応部分に対応する符号を付して示している。

本実施の形態における処理動作も、ユーザによる申請とは無関係に実行される。
処理動作２の場合も、ステップ１～ステップ４までの動作は、処理動作１と同じである。
すなわち、ワークフローサーバ３０は、スケジュールサーバ２０に対し、ユーザのスケジュールを定期的に要求する（ステップ１）。
要求を受信したスケジュールサーバ２０は、要求に対する応答として各ユーザのスケジュールを送信する（ステップ２）。

次に、ワークフローサーバ３０は、受信した各ユーザのスケジュールを参照し、申請等を承認する承認者に不在期間が予定されているか否かを判定する（ステップ３）。ステップ３で否定結果が得られる間、ワークフローサーバ３０は、ステップ１に戻る。一方、ステップ３で肯定結果が得られた場合、ワークフローサーバ３０は、アプリ別利用状況ＤＢ３０２Ｅ（図３参照）から申請の履歴を取得する（ステップ４）。
この後、ワークフローサーバ３０は、申請の履歴がないユーザを検索する（ステップ１１）。処理動作２は、申請の履歴がないユーザを通知の対象とするためである。もっとも、申請の回数が閾値を満たないことを理由として処理動作１の通知の対象から除外されたユーザが存在する場合には、当該ユーザもステップ１１で検索する。

次に、ワークフローサーバ３０は、該当するユーザが存在するか否かを判定する（ステップ１２）。
ステップ１２で否定結果が得られた場合、通知すべきユーザが存在しないので、ワークフローサーバ３０は、ステップ１に戻る。
一方、ステップ１２で肯定結果が得られた場合、ワークフローサーバ３０は、該当するユーザに承認者の不在の予定等を通知する（ステップ６）。
図１０の場合には、ユーザＤが操作する情報端末１０Ｄに情報が通知されている。ユーザＤが操作する情報端末１０Ｄには、例えば画面３１０が表示される。

もっとも、処理動作２で通知の対象となるユーザＤは、過去に申請を行ったことがないユーザである。このため、画面３１０の表示が、ユーザＤには迷惑になる可能性もある。
そこで、本実施の形態におけるワークフローサーバ３０には、通知の対象であるユーザＤがワークフローのホーム画面を開いた場合に、承認者であるＥ部長の不在を通知する機能も用意する。
図１１は、申請の履歴が存在しないユーザが使用する情報端末１０に表示されるホーム画面３２０の一例を説明する図である。

図１１に示すホーム画面３２０には、ワークフローのホーム画面３２１が表示されている。
ホーム画面３２１の左側には、申請する文書の選択欄３２２が表示されている。選択欄３２２には、選択肢として、「すべての文書」、「契約書」、「見積書」、「発注書」、「請求書」、「その他の文書」が示されている。図１１の場合、見積書が選択されている。
図１１に示すホーム画面３２０の右側には、ユーザＤが使用する権限を有する業務支援アプリのアイコン３２３及び３２４が表示されている。図１１の場合、アイコン３２３は、連携アプリの１つである「連携１」に対応する。アイコン３２４は、業務支援アプリＸＸ（すなわち「アプリＸＸ」）に対応する。なお、ユーザＤが使用する権限を有する他の業務支援アプリＸ、Ｙ、Ｚに対応するアイコンの表示は紙面の都合により省略している。

図１１の場合、承認者であるユーザＥの不在が影響する業務支援アプリは、ユーザＤが見積書の申請に使用する連携アプリである。このため、図１１では、「連携１」に対応するアイコン３２３にメッセージ３２５が吹き出し形式で示されている。因みに、アプリＸＸは、ユーザＥの不在が影響しないので、メッセージ３２５は付されていない。
ここでのアイコン３２３は、申請に用いるボタンの一例である。
メッセージ３２５にも、申請が滞留する原因となる承認者の不在の予定と、不在の期間と、申請の処理が再開される時期が提示される。
図１１に示すメッセージ３２５には、「申請を承認するＥ部長には不在期間（３／３１～４／１０）があります。」と「申請は４月１１日以降に処理されます。」と記載されている。図１１の場合、申請の処理が再開される時期が示される一方、申請を促す文面が含まれない点で、画面３１０（図９参照）と異なっている。

もっとも、メッセージに３２５にも、申請を促す文面を含めてもよい。また、画面３１０のメッセージ３１１（図９参照）にも、申請の処理が再開される時期を加えてもよい。
なお、図１１の場合、メッセージ３２５は、申請に使用する業務支援アプリＸＸのアイコン３２３に関連付けて表示されているが、アイコンと紐付けない表示も可能である。例えばＥ部長の承認が関係する業務支援アプリに対応する複数のアイコンがホーム画面３２０に表示されている場合、メッセージ３２５が重なって表示されると、かえって情報の確認が困難になる。このような場合には、アイコンとは無関係な位置にメッセージ３２５を１つだけ表示してホーム画面３２０の見やすさを高めてもよい。
また、メッセージ３２５は、Ｅ部長の承認を含む全ての業務支援アプリのアイコンに紐付けて表示するのではなく、１つのアイコンにだけメッセージ３２５を紐付けて表示することとし、ユーザＤが他のアイコンを選択するたびに、選択されたアイコンに紐付けるようにメッセージ３２５を表示してもよい。

＜処理動作３＞
前述した処理動作１及び２は、申請の可能性があるユーザへの承認者の不在の予定の通知を目的としている。
しかし、処理動作１又は２の通知を受けた申請者が前倒しで申請を行ったとしても、申請の事務処理を行うユーザからの承認者への回覧が遅れると、申請の回覧の滞留が発生する。
そこで、処理動作３では、ワークフローが受け付けた申請の事務処理を担当するユーザのうち承認者の上流で事務作業を行うユーザに対して承認者の不在の予定を積極的に通知する処理動作について説明する。

図１２は、ワークフローサーバ３０で実行される他の処理動作の一例を示すフローチャートである。
図１２の場合には、申請者をユーザＡとし、承認者であるユーザＥに回覧する電子文書の事務の担当者をユーザＣとする。
図１３は、処理動作３で想定する申請後の処理の流れと承認者であるユーザＥの不在期間との関係を説明する図である。

まず、ユーザＡは、３月１０日に申請を行う。ユーザＡが指定した希望納期は４月５日である。承認者であるユーザＥの不在期間は３月３１日から４月１０日までの１１日間であり、希望納期と重なっている。
ユーザＡが申請した電子文書は、ユーザＣの事務作業を経て承認者であるユーザＥに回覧され、その後、ユーザＥの承認を経てユーザＤに回覧される。図１３の場合、ユーザＣとユーザＤが不在でも他のユーザによる事務の代行が可能である。このため、ユーザＡの申請の回覧の滞留は、ユーザＥの不在による承認の遅れにより発生する。

図１４は、ユーザＡによる見積書の申請を説明する図である。図１４には、図１１との対応部分に対応する符号を付して示している。
図１４に示すホーム画面３２０の下部には、申請の対象である見積書に対応する２つのアイコン３２６及び３２７が表示されている。アイコン３２６は「見積書１」に対応し、アイコン３２７は「見積書２」に対応する。
「見積書２」の承認を申請したい場合、ユーザは、「見積書２」に対応するアイコン３２７を、「連携１」に対応するアイコン３２３の位置まで移動させる。この移動は、いわゆるドラッグ＆ドロップの操作である。

図１２の説明に戻る。
この操作を検出した情報端末１０Ａは、ワークフローサーバ３０に対し、申請の発生を通知する（ステップ２１）。
ワークフローサーバ３０は、申請を受け付けると（ステップ２２）、スケジュールサーバ２０に対し、申請を承認するユーザのスケジュールを要求する（ステップ２３）。申請を承認するユーザは、起動された業務支援アプリや申請された電子文書の内容に応じて特定される。本実施の形態の場合、見積書の申請を承認する権限を有するユーザは、ユーザＥである。
スケジュールサーバ２０は、要求に対する応答として、該当するユーザのスケジュールを送信する（ステップ２４）。

スケジュールを受信したワークフローサーバ３０は、承認者に不在の予定があるか否かを判定する（ステップ２５）。
承認者であるユーザＥに不在の予定が無い場合、ワークフローサーバ３０は、ステップ２５で否定結果を得る。
この場合、ワークフローサーバ３０は、承認者であるユーザＥの不在の予定の通知を行う必要がない。このため、ワークフローサーバ３０は、不在の予定の通知に関する処理を終了する。もっとも、ユーザＣが担当する申請の発生は、ワークフローサーバ３０からユーザＣに通知される。

一方、承認者であるユーザＥに不在の予定があった場合、ワークフローサーバ３０は、ステップ２５で肯定結果を得る。
この場合、ワークフローサーバ３０は、申請者の希望納期を取得する（ステップ２６）。
次に、ワークフローサーバ３０は、希望納期が不在期間に重なるか否かを判定する（ステップ２７）。
ステップ２７で否定結果が得られた場合、ワークフローサーバ３０は、ステップ２５で否定結果が得られた場合と同様、ユーザＣには、承認者であるユーザＥの不在の予定の通知は行われない。

一方、ステップ２７で肯定結果が得られた場合、ワークフローサーバ３０は、承認者の上流で事務処理を行うユーザに対し、承認者の不在の予定等を通知する（ステップ２８）。
前述したように、本実施の形態の場合、承認者はユーザＥであり、その上流で事務処理を行うユーザは、ユーザＣである。
従って、ワークフローサーバ３０は、ユーザＣに対してユーザＥの不在の予定を通知する。

図１５は、承認者に回覧する申請の事務を担当するユーザＣが操作する情報端末１０Ｃに表示される画面３３０の一例を説明する図である。
ここでのユーザＣは、承認者の直前に申請を処理するユーザの一例である。
画面３３０には、条件を満たすユーザへのメッセージ３３１として、申請中の希望納期が承認者の不在の予定と重なっていることと、事務処理の完了が求められる目標日とが提示される。事務処理の完了が求められる目標日は、処理の期限の一例である。
図１５に示すメッセージ３３１には、「Ａさんから申請された見積書の希望納期は、承認を担当するＥ部長の不在期間（３／３１～４／１０）に重なっています。」と「３／２０までに申請の事務を完了させてください。」の情報が記載されている。

図１５の場合、承認者であるＥ部長の不在期間の情報も含まれているが、不在期間を具体的に示す記載はなく、事務処理の完了が求められる目標日だけが表示されてもよい。事務処理の完了が求められる目標日が明示的に表示されることで、ユーザＣによるスケジュールの把握が容易になる。
反対に、事務処理の完了が求められる目標日の具体的な情報はなく、不在期間を具体的に示す表示があってもよい。

なお、図１５の場合には、事務処理の完了が求められる目標日を不在期間の初日の１１日前に設定する例を示しているが、この期間は、初期値として与えてもよいし、管理者の設定により与えてもよい。また、目標日や目標日を与えるための期間を、承認者であるユーザＥが個別に設定できるようにしてもよい。
処理動作３の場合、不在の予定がある承認者の前段に配置される処理ステップが１つの場合を想定しているが、複数のステップが存在する場合には、各ステップに対応する作業を担当するユーザに対して承認者の不在の予定等を通知してもよい。この通知にも、電子メールやプッシュ通知を使用すればよい。

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

例えば前述の実施の形態では、申請の受け付け後の手続きに現れる承認者が１名の場合を説明したが、承認者は複数名でもよい。例えば申請の対象である金額によっては、一次承認者による承認の後に、役職上の上位者による承認を必要とすることがある。その場合には、複数名の承認者のそれぞれについて不在期間を判定する。
なお、承認者が複数名おり、複数の不在期間が見つかった場合には、複数の不在期間に対応する承認者のうち職務上の最も上位の承認者の不在期間を基準に用いてもよい。

また、前述の実施の形態においてワークフローサーバ３０が実行すると説明した処理の一部をスケジュールサーバ２０が実行してもよく、反対に、スケジュールサーバ２０が実行すると説明した処理の一部をワークフローサーバ３０が実行してもよい。
また、ワークフローサーバ３０は、スケジュールサーバ２０以外の外部サーバとの連携により、前述した機能を実行してもよい。

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

１…ワークフロー管理システム、１０、１０Ａ、１０Ｂ、１０Ｃ、１０Ｄ、１０Ｅ…情報端末、２０…スケジュールサーバ、３０…ワークフローサーバ

Claims (4)

1. プロセッサを有し、
   前記プロセッサは、
   ワークフローシステムに登録されているユーザのスケジュールを取得し、
   申請を処理する特定のユーザについての不在の予定が検出された場合、当該特定のユーザの不在の予定を、申請の履歴が予め定めた条件を満たすユーザに通知する、
   情報処理装置。
2. 前記条件を満たすユーザは、申請の回数又は申請の頻度が予め定めた閾値を超えるユーザである、請求項１に記載の情報処理装置。
3. 前記条件を満たすユーザは、申請から希望する納期までの期間の長さの平均値が予め定めた閾値より短いユーザである、請求項１に記載の情報処理装置。
4. コンピュータに、
   ワークフローシステムに登録されているユーザのスケジュールを取得する機能と、
   申請を処理する特定のユーザについての不在の予定が検出された場合、当該特定のユーザの不在の予定を、申請の履歴が予め定めた条件を満たすユーザに通知する機能と
   を実現させるプログラム。