JP7266256B1 - 計算機システム及び災害に対応する業務の割当方法 - Google Patents

Abstract

【課題】災害時の組織間の業務の連携を支援する。【解決手段】計算機システムは、災害に対する業務を実行する複数の組織が管理する端末と接続し、端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信する。計算機システムは、現場情報に基づいて現場の状態を特定し、現場の状態に基づいて実施が必要な割当業務を特定し、活動情報に基づいて組織の活動状態を把握し、組織の活動状態に基づいて、割当業務を実行可能な組織を決定し、決定された組織割当業務の実施依頼を送信する。【選択図】 図１

Description

本発明は、災害発生時の業務を複数の縦割り組織が参加する災害対応現場において、円滑な組織間連携を支援する技術に関する。

災害時には、多くの組織が多岐に亘る活動を実施する。災害時の活動の効率化には、活動を行っている組織の状態及び組織が保有する情報を組織間で共有し、共有した情報から活動の全体像を把握する必要がある。

しかし、活動を行う組織は縦割りの組織であるため、他の組織の状態を把握できず、組織間の連携が難しい。また、医療活動支援、道路啓開、及び物資供給支援等、目的に応じて必要となる機能（リソース）が異なり、また、組織の状態も時々刻々と変化するため、割り当てられた業務が実施されていない事態が起こりうる。前述のように組織間の連携が不十分であるため、業務が実施されていないことが後に発覚し、対応が後手後手となる。

前述のような問題を解決するための技術として、特許文献１及び特許文献２に記載の技術が知られている。

特許文献１には、「意思決定に必要な情報を、意思決定支援装置１０１からネットワーク１２９を介して各種端末（１３０、１４０、１５０、１６０）に配信するために、意思決定の原因となるイベントをイベント管理部１０９で検知し、当該イベントに応じたタスク（業務）割当ておよび通知すべき情報を、イベント（およびこれに伴う状況）に応じて、情報相関管理部１１１で管理される各情報の相関関係を用いて、決定する」こと、及び、「決定された情報を、インターフェース部１１７を介して各種端末に配信する」ことが記載されている。

特許文献２には、「新規起票時および関連起票時に、危機対応業務管理支援サーバＳＶにより、タスクを識別するレコードＩＤと、タスクのグループを識別するタスクＩＤ（Task-ID）と、関連起票時に起票元となるタスクとの関係性を示すＩＤ（Org-ID）と、タスクグループ内における各タスクの世代を階層化して示すレイヤ情報を生成し、これを依頼情報に付加して活動ログ記憶部３２に蓄積する。そして、タスクグループごとにそのタスクのリストを表示する際に、タスクの対応状況を時系列上で並べて表示させる。また、蓄積された上記タスクデータごとにボトルネック度を計算し、計算されたボトルネック度を上記タスクデータのリストに付加して表示する」ことが記載されている。

特開２０１３－０８８８２９号公報 特開２０１６－２２４６７１号公報

特許文献１に記載の技術では、混乱している現場における業務の実施の可否が考慮されていない。特許文献２に記載の技術では、各組織が実施している業務について報告を行うことを前提としている。しかし、現場の状態によっては報告ができない場合がある。報告がない業務こそ緊急性が高くシステムが管理するべきであり、特許文献２に記載の技術では対応できない。

このように、従来技術では、割当業務、及び現場に応じて行われた規定外の業務に関する報告が欠落することが想定されておらず、情報の欠落が発生した場合、正しく機能しない。

本発明は、現場から断片的に取得できる情報から現場の状態を把握し、組織に割り当てる業務を計画することによって、災害時の組織間の業務の連携を支援することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する、少なくとも一つの計算機を含む計算機システムであって、災害に対する業務を実行する複数の組織が管理する端末と接続し、前記複数の組織の端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信し、前記計算機システムは、現場の状態及び業務目的を含む第１データを格納する業務発行条件情報と、業務目的、業務、及び業務の実施に必要なリソースを含む第２データを格納する業務マニュアル情報と、を保持し、前記少なくとも一つの計算機は、取得した前記現場情報に基づいて現場の状態を特定し、特定された前記現場の状態に基づいて実施が必要な割当業務を特定し、取得した前記活動情報に基づいて、前記複数の組織の活動状態を把握し、前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定し、決定された前記組織に、前記割当業務の実施依頼を送信し、前記割当業務の特定では、前記少なくとも一つの計算機は、前記業務発行条件情報に基づいて、特定された前記現場の状態に対応する前記業務目的を特定し、前記業務マニュアル情報に基づいて、特定された前記業務目的に対応する前記業務を、前記割当業務として特定する。

本発明によれば、現場から断片的に取得できる情報に基づいて、現場の状態を把握し、組織に対する業務の割当てを計画できる。これによって、災害時の組織間の業務の連携を支援できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

実施例１のシステム構成の一例を示す図である。 実施例１の業務管理支援装置のハードウェア構成の一例を示す図である。 実施例１の業務発行条件情報のデータ構造の一例を示す図である。 実施例１の業務マニュアル情報のデータ構造の一例を示す図である。 実施例１の所有リソース情報のデータ構造の一例を示す図である。 実施例１の組織管理情報のデータ構造の一例を示す図である。 実施例１の客体管理情報のデータ構造の一例を示す図である。 実施例１の業務発行条件情報、業務マニュアル情報、所有リソース情報、組織管理情報、及び客体管理情報の対応関係を説明する図である。 実施例１の確度算出ロジック情報のデータ構造に一例を示す図である。 実施例１のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。 実施例１のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。 実施例１のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。 実施例１のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。 実施例１の現場状態情報のデータ構造の一例を示す図である。 実施例１の割当業務情報のデータ構造の一例を示す図である。 実施例１の推定業務情報のデータ構造の一例を示す図である。 実施例１の業務管理支援装置の状態監視部が実行する現場状態確認処理の一例を説明するフローチャートである。 実施例１の割当部が実行する処理の一例を説明するフローチャートである。 実施例１の割当部が実行する処理の一例を説明するフローチャートである。 実施例１の割当業務管理部が実行する処理の一例を説明するフローチャートである。 実施例１の推定部が実行する処理の一例を説明するフローチャートである。 実施例１の推定業務管理部が実行する処理の一例を説明するフローチャートである。 実施例１の業務管理支援装置の内部の処理のイメージを示す図である。 実施例１の業務管理支援装置及びメッセージングシステムの間のメッセージの流れを示す図である。 実施例１の端末に提示される画面の一例を説明する図である。

以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。

図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。

図１は、実施例１のシステム構成の一例を示す図である。図２は、実施例１の業務管理支援装置１００のハードウェア構成の一例を示す図である。

図１に示すように、システムは、業務管理支援装置１００、メッセージングシステム１０１、及び端末１０２から構成される。業務管理支援装置１００、メッセージングシステム１０１、及び端末１０２はネットワーク１０５を介して互いに接続される。

端末１０２は、災害時に業務を行う組織が管理する端末である。端末１０２は、例えば、パーソナルコンピュータ及びスマートフォン等である。図１では、三つの組織の端末１０２を示している。なお、本発明は端末１０２の種別及び数に限定されない。端末１０２は、アクティブ状態／非アクティブ状態に関する情報、他の端末１０２との間の連絡等の活動ログ、被災状況に関する情報等をメッセージングシステム１０１に登録する機能を有する。また、端末１０２は、メッセージングシステム１０１からメッセージを取得し、取得したメッセージに対応する応答メッセージをメッセージングシステム１０１に送信することができる。

メッセージングシステム１０１は、メッセージキューを実現するシステムである。メッセージングシステム１０１は、業務管理支援装置１００と端末１０２との間の情報をメッセージとして保持し、中継する。

メッセージングシステム１０１は、メッセージ入出力部１４０を有し、また、現場状態キュー１５０、組織状態キュー１５１、割当業務キュー１５２、及び推定業務キュー１５３を管理する。

現場状態キュー１５０は、気象及び河川の状態（例えば、河川の氾濫）、ライフラインの状態（例えば、停電）、医療施設の状態、並びに、被害の規模及び範囲等、現場の状態に関する情報を含むメッセージ１０００（図１０Ａを参照）を蓄積する。組織状態キュー１５１は、組織の活動状態に関する情報を含むメッセージ１０１０（図１０Ｂを参照）を蓄積する。割当業務キュー１５２は、業務管理支援装置１００によって実施が依頼された業務に関する情報を含むメッセージ１０２０（図１０Ｃを参照）を蓄積する。推定業務キュー１５３は、業務管理支援装置１００によって任意の組織によって実施されていると推定された業務に関する情報を含むメッセージ１０３０（図１０Ｄを参照）を蓄積する。

メッセージ入出力部１４０は、各キューへのメッセージの登録及び各キューからのメッセージの読出を行う。メッセージ入出力部１４０は、キューへのメッセージの蓄積時に、端末１０２等から受信した情報を所定の形式のメッセージに変換し、当該メッセージを登録する。

（例１）端末１０２から「道路名称」及び「通行可否状態」のから構成されるエントリを１００個含むテーブルを受信した場合、メッセージ入出力部１４０は、テーブルが送信された時刻、「道路名称」、及び「通行可否状態」から構成される１００個のメッセージ１０００を生成し、現場状態キュー１５０に登録する。なお、上記の例では、テーブル形式のデータをメッセージに変換していたが、これに限定されない。受信する情報のデータ形式はＪＳＯＮ形式及びＸＭＬ形式等でもよい。

（例２）端末１０２から「医療施設名称」のフィールドと、「電力状態」、「給水状態」、及び「衣料品保有状態」等の状態を表す３０個のフィールドとから構成されるエントリを１００個格納するテーブルを受信した場合、メッセージ入出力部１４０は、一つのエントリに対して、各状態のフィールドの値を含む３０個のメッセージ１０００を生成する。メッセージ入出力部１４０は、３０００個のメッセージ１０００を現場状態キュー１５０に登録する。なお、上記の例では、テーブル形式のデータをメッセージに変換していたが、これに限定されない。受信する情報のデータ形式はＪＳＯＮ形式及びＸＭＬ形式等でもよい。

（例３）メッセージ入出力部１４０は、端末１０２の通信状態又は応答の有無を確認し、確認結果を含むメッセージ１０１０を生成し、当該メッセージを組織状態キュー１５１に登録する。

業務管理支援装置１００は、メッセージングシステム１０１を介して端末１０２から取得した情報に基づいて現場の状態を把握し、実施されている可能性がある業務を推定する。また、業務管理支援装置１００は、メッセージングシステム１０１を介して端末１０２から取得した情報に基づいて組織の状態を把握し、実施が必要な業務を特定し、当該業務の実施を依頼する組織を決定し、メッセージングシステム１０１を介して当該組織に業務の実施を依頼する。

業務管理支援装置１００は、例えば、図２に示すようなハードウェア構成の計算機である。業務管理支援装置１００は、プロセッサ２０１、主記憶装置２０２、副記憶装置２０３、及びネットワークインタフェース２０４を有する。なお、業務管理支援装置１００は、入力装置及び出力装置を有してもよい。

プロセッサ２０１は、主記憶装置２０２に格納されるプログラムを実行する。プロセッサ２０１がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部（モジュール）として動作する。以下の説明では、機能部を主語に処理を説明する場合、プロセッサ２０１が当該機能部を実現するプログラムを実行していることを示す。

主記憶装置２０２は、メモリ等であり、プロセッサ２０１が実行するプログラム及びプログラムが使用するデータを格納する。副記憶装置２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等であり、データを永続的に格納する。主記憶装置２０２に格納されるプログラム及びデータは、副記憶装置２０３に格納されてもよい。この場合、プロセッサ２０１が副記憶装置２０３からプログラム及びデータを読み出し、主記憶装置２０２にロードする。ネットワークインタフェース２０４は、ネットワークを介して他の装置と通信する。

本実施例のプロセッサ２０１は、業務割当部１１０、業務推定部１１１、状態監視部１１２、及びマニュアル選択部１１３として動作する。本実施例の主記憶装置２０２は、業務発行条件情報１３０、業務マニュアル情報１３１、所有リソース情報１３２、組織管理情報１３３、客体管理情報１３４、確度算出ロジック情報１３５、現場状態情報１３６、割当業務情報１３７、及び推定業務情報１３８を格納する。

業務発行条件情報１３０は、業務の実行条件及び業務を特定するための情報を格納する。業務発行条件情報１３０のデータ構造の詳細は図３を用いて説明する。

業務マニュアル情報１３１は業務マニュアルを格納する。業務マニュアルは、業務を実施する組織及び機能を記述した情報である。後述するように、業務マニュアル情報１３１には災害の種別ごとの業務マニュアルが格納される。業務マニュアル情報１３１のデータ構造の詳細は図４を用いて説明する。

所有リソース情報１３２は、組織が保有する、業務に使用するリソースに関する情報を格納する。所有リソース情報１３２のデータ構造の詳細は図５を用いて説明する。

組織管理情報１３３は、組織のカテゴリに属する組織に関する情報を格納する。組織管理情報１３３のデータ構造の詳細は図６を用いて説明する。

客体管理情報１３４は、客体のカテゴリに属する客体に関する情報を格納する。客体管理情報１３４のデータ構造の詳細は図７を用いて説明する。

確度算出ロジック情報１３５は、推定された業務の推定の尤もらしさを表す確度を算出するためのロジックに関する情報を格納する。確度算出ロジック情報１３５のデータ構造の詳細は図９を用いて説明する。

現場状態情報１３６は、現場状態キュー１５０を介して受信したメッセージ１０００を格納する。現場状態情報１３６のデータ構造の詳細は図１１を用いて説明する。

割当業務情報１３７は、業務管理支援装置１００が実施を依頼した業務に関する情報を格納する。割当業務情報１３７のデータ構造の詳細は図１２を用いて説明する。

推定業務情報１３８は、業務管理支援装置１００が推定した業務に関する情報を格納する。推定業務情報１３８のデータ構造の詳細は図１３を用いて説明する。

業務割当部１１０は、現場の状態に応じて実施が必要な業務を特定し、業務の実施が可能な組織に業務を割り当てる。なお、本実施例では、業務管理支援装置１００は、能動的に業務を割り当てるわけではなく、メッセージキューを介して業務の実施を組織に依頼する。業務の実施は組織の判断に委ねられる。業務割当部１１０は、割当部１２０及び割当業務管理部１２１を含む。割当部１２０は、業務の特定及び組織への業務の実施を依頼する。割当業務管理部１２１は、実施を依頼した業務の進捗を監視し、業務が実行されていない場合、再度、業務の実施を依頼する。

業務推定部１１１は、現場において実施された可能性がある業務を推定する。業務推定部１１１は、推定部１２２及び推定業務管理部１２３を含む。推定部１２２は、現場において実施された可能性がある業務を推定する。推定業務管理部１２３は、推定業務の実施結果を監視し、推定業務の確度を算出する。

状態監視部１１２は、現場状態キュー１５０、組織状態キュー１５１、割当業務キュー１５２、及び推定業務キュー１５３に蓄積されるメッセージを監視する。状態監視部１１２は、組織によって現場状態キュー１５０に登録されたメッセージ１０００を現場状態情報１３６に登録し、組織によって割当業務キュー１５２に登録されたメッセージ１０２０を割当業務情報１３７に登録し、組織によって推定業務キュー１５３に登録されたメッセージ１０３０を推定業務情報１３８に登録する。状態監視部１１２は、現場状態情報１３６に基づいて現場の状態を特定し、現場の状態に応じて業務の割り当て及び推定を行う。また、状態監視部１１２は、メッセージ入出力部１４０を介して各キューにメッセージを登録する。

マニュアル選択部１１３は、業務マニュアル情報１３１に格納される業務マニュアルの中から使用する業務マニュアルを選択する。現場状態キュー１５０に格納されるメッセージ１０００の内容に基づいてマニュアル選択部１１３が自動的に業務マニュアルを決定してもよいし、業務管理支援装置１００を操作するユーザの入力に基づいて決定してもよい。マニュアル選択部１１３は、現場の状態に応じて使用する業務マニュアルを動的に切り替えてもよい。

例えば、「台風接近」を意味するメッセージ１０００が格納されている場合、風水害用の業務マニュアルが選択され、「地震発生」を意味するメッセージ１０００が格納されている場合、地震災害用の業務マニュアルが選択される。また、現場状態キュー１５０の更新頻度が少ない場合、マニュアル選択部１１３は、平常時と判定し、平常時用の業務マニュアルを選択する。

なお、業務管理支援装置１００が有する各機能部については、複数の機能部を一つの機能部にまとめてもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。

なお、複数の計算機を含む計算機システムを用いて、業務管理支援装置１００が有する機能部を実現してもよい。この場合、各計算機に機能部を分散して配置してもよい。

図３は、実施例１の業務発行条件情報１３０のデータ構造の一例を示す図である。

業務発行条件情報１３０には、図３に示すようなテーブル３００が格納される。テーブル３００は、現場状態３０１及び目的３０２を含むエントリを格納する。一つの業務の発行条件に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

現場状態３０１は、業務の実施条件に対応する現場の状態に関する情報を格納するフィールド群であり、客体カテゴリ３１１及び条件３１２を含む。客体カテゴリ３１１は、現場の種別を識別するための客体カテゴリを格納するフィールドである。条件３１２は、客体カテゴリに属する客体の状態を格納するフィールドである。客体の状態が条件３１２に格納される条件を満たす場合、業務が実施されることになる。目的３０２は、現場の状態の改善目的を格納するフィールドである。

なお、業務発行条件情報１３０には、災害の種別ごとにテーブル３００が格納されてもよい。なお、業務発行条件情報１３０に格納される情報はテーブル形式以外のデータ形式でもよい。

図４は、実施例１の業務マニュアル情報１３１のデータ構造の一例を示す図である。

業務マニュアル情報１３１には、災害の種別ごとに、図４に示すようなテーブル４００が格納される。テーブル４００は、目的４０１、効果４０２、業務４０３、組織カテゴリ４０４、及び機能４０５を含むエントリを格納する。一つの目的に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

目的４０１は、目的３０２と同一のフィールドである。効果４０２は、業務の実施による効果に関する情報を格納するフィールド群であり、客体カテゴリ４１１及び変化４１２を含む。客体カテゴリ４１１は客体カテゴリ３１１と同一のフィールドである。変化４１２は、業務の実施による客体の変化を格納するフィールドである。

業務４０３は、目的を達成するために実施する業務を格納するフィールドである。一つの目的に対して一つ以上の業務が存在する。一つのエントリには、業務の数だけ、業務４０３、組織カテゴリ４０４、及び機能４０５から構成される行が含まれる。組織カテゴリ４０４は、業務を実施可能な組織のカテゴリを格納するフィールドである。機能４０５は、業務の実施に必要な機能を格納するフィールドである。

なお、業務マニュアル情報１３１に格納される情報はテーブル形式以外のデータ形式でもよい。

図５は、実施例１の所有リソース情報１３２のデータ構造の一例を示す図である。

所有リソース情報１３２には、図５に示すようなテーブル５００が格納される。テーブル５００は、組織５０１及び機能５０２を含むエントリを格納する。一つの組織に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

組織５０１は、組織の識別情報を格納するフィールドである。機能５０２は、業務の実施に必要な機能ごとのリソースに関する情報を格納するフィールド群である。機能５０２には、例えば、経路５１１、輸送５１２、車両撤去５１３、判断５１４、及び報告５１５等のフィールドが含まれる。各フィールドには、機能を実現するリソースが格納される。経路５１１には、物資の輸送又は支援部隊の移動に使用され、かつ、組織が管理する道路、河川、及び空港等が格納される。輸送５１２には、輸送に使用され、かつ、組織が管理する救急車及びヘリコプター等が格納される。

なお、所有リソース情報１３２には、災害の種別ごとにテーブル５００が格納されてもよい。なお、所有リソース情報１３２に格納される情報はテーブル形式以外のデータ形式でもよい。

図６は、実施例１の組織管理情報１３３のデータ構造の一例を示す図である。

組織管理情報１３３には、図６に示すようなテーブル６００が格納される。テーブル６００には、組織カテゴリ６０１及び組織６０２を含むエントリを格納する。一つの組織のカテゴリに対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

組織カテゴリ６０１は、組織カテゴリ４０４と同一のフィールドである。組織６０２は、組織のカテゴリに属する組織を格納するフィールドである。組織６０２には組織の数だけ行が含まれる。

なお、組織のカテゴリに属する組織が一つの場合、組織のカテゴリと組織とは一致するものとする。なお、組織管理情報１３３に格納される情報はテーブル形式以外のデータ形式でもよい。

図７は、実施例１の客体管理情報１３４のデータ構造の一例を示す図である。

客体管理情報１３４には、図７に示すようなテーブル７００が格納される。テーブル７００は、客体カテゴリ７０１及び客体７０２を含むエントリを格納する。一つの客体のカテゴリに対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

客体カテゴリ７０１は客体カテゴリ３１１と同一のフィールドである。客体７０２は、客体のカテゴリに属する客体を格納するフィールドである。客体７０２には客体の数だけ行が含まれる。

なお、エントリは、道路、避難所、及び港湾等の位置情報（例えば、経度緯度）を格納するフィールドを含んでもよい。なお、客体管理情報１３４に格納される情報はテーブル形式以外のデータ形式でもよい。

図８は、実施例１の業務発行条件情報１３０、業務マニュアル情報１３１、所有リソース情報１３２、組織管理情報１３３、及び客体管理情報１３４の対応関係を説明する図である。

状態監視部１１２は、「都道府県道Ａ」の状態が「通行可能」から「通行不可」に変化したことを検知した場合、客体「都道府県道Ａ」に基づいて客体管理情報１３４を参照し、客体カテゴリ「道路」が「通行不可」の状態になったことを把握できる。さらに、状態監視部１１２は、業務発行条件情報１３０を参照して、「道路啓開」を達成するための業務を実施する必要があると判定する。状態監視部１１２は、図８に示すように、業務発行条件情報１３０、業務マニュアル情報１３１、組織管理情報１３３、及び所有リソース情報１３２のリンクをたどることによって業務の割当又は業務の推定を行う。

状態監視部１１２は、「都道府県道Ａ」の状態が「通行不可」から「通行可能」に変化したことを検知した場合、客体「都道府県道Ａ」に基づいて客体管理情報１３４を参照し、客体カテゴリ「道路」が「通行可能」の状態になったことを把握できる。さらに、状態監視部１１２は、業務マニュアル情報１３１して、「道路啓開」を達成するための業務が実施されたことを把握できる。

図９は、実施例１の確度算出ロジック情報１３５のデータ構造に一例を示す図である。

確度算出ロジック情報１３５には、図９に示すようなテーブル９００が格納される。テーブル９００は、確度算出条件９０１及び確度９０２を含むエントリを格納する。一つの条件に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。

確度算出条件９０１は、確度の算出条件を格納するフィールドである。確度９０２は、確度算出条件９０１に設定された条件を満たす場合の確度を格納するフィールドである。なお、本実施例では、四種類の確度を定義しているが、確度の数は三種類以下でもよいし、また、四種類より多くてもよい。

なお、確度算出ロジック情報１３５に格納される情報はテーブル形式外のデータ形式でもよい。

また、確度算出ロジック情報１３５には、テーブル９００以外に、統合確度を算出するための数式の情報が含まれる。数式は、例えば、式（１）のように与えられる。ここで、ｎ_ｉは確度ｉ（ｉは１，２，３，４）の推定業務の数を表し、ｗ_ｉは重みを表す。

ｗ_１、ｗ_２、ｗ_３、ｗ_４をすべて１とし、「通知組織」、「時刻」、「客体」が異なるが、「業務カテゴリ」が同一である推定業務が三つあり、そのうち、確度が「１」の推定業務が一つ、確度が「２」の推定業務が二つである場合、総合確度は式（２）に示すように３となる。

ｗ_ｉの値は、業務管理支援装置１００が管理する組織がどれだけ丁寧に業務に対して回答しているかという、協力の度合によって定まる。

（設定方法１）確実な報告が期待される場合、ｗ_１を１、ｗ_２を２、ｗ_３を３、ｗ_４を４と設定する。確度が高い推定業務の重みを大きくすることによって、業務推定部１１１の推測結果と、業務割当部１１０が割り当てた業務が一致している業務に関する推定業務を重要視することになる。

（設定方法２）組織が協力的でなく、確実な報告を期待できない場合、業務推定部１１１の推定結果が多少間違ってしまっていても、推定の回数を重ねることによって、推定の精度が高まることが期待される。そのため、ｗ_１、ｗ_２、ｗ_３、ｗ_４をすべて１に設定し、確度が低い推定業務を確度が高い推定業務と同様に扱いことが最適であると考えられる。

Ａ省が業務を実施し、確度が「４」である推定業務が三つである場合、設定方法１の総合確度は式（３）に示すように１２となり、設定方法２の総合確度は式（４）に示すように３となる。

Ｂ省が業務を実施し、確度が「１」である推定業務が五つ、確度が「３」である推定業務が二つである場合、設定方法１の総合確度は式（５）に示すように１１となり、設定方法２の総合確度は式（６）に示すように７となる。

したがって、設定方法２の場合、Ｂ省が推定業務を実施した可能性が高く、設定方法１の場合、Ａ省が推定業務を実施した可能性が高いことを意味する。

図１０Ａ、図１０Ｂ、図１０Ｃ、及び図１０Ｄは、実施例１のメッセージングシステム１０１が蓄積するメッセージのデータ構造の一例を示す図である。

メッセージングシステム１０１に蓄積されるメッセージは、キー及び値のペアを少なくとも一つ含む。

図１０Ａに示すメッセージ１０００は、現場状態キュー１５０に格納されるメッセージであり、キーとして「時刻」、「客体」、及び「状態」を含む。キー「客体」は現場の種別であり、「状態」は現場の状態である。

図１０Ｂに示すメッセージ１０１０は、組織状態キュー１５１に格納されるメッセージであり、キーとして「時刻」、「組織」、「状態」、及び「通信相手」を含む。キー「組織」は、メッセージを登録した組織であり、キー「状態」は組織の状態であり、キー「通信相手」は組織が通信している相手である。

図１０Ｃに示すメッセージ１０２０は、割当業務キュー１５２に格納されるメッセージであり、キーとして「時刻」、「目的」、「業務」、「客体」、「依頼組織」、「状態」、及び「更新者」を含む。キー「目的」は現場の状態の改善目的であり、キー「業務」は実施対象の業務であり、キー「依頼組織」は業務の実施を依頼する組織であり、「状態」は業務の実施状態であり、「更新者」はメッセージの登録者である。

図１０Ｄに示すメッセージ１０３０は、推定業務キュー１５３に格納されるメッセージであり、キーとして「時刻」、「目的」、「業務」、「客体」、「機能」、「実施組織」、「確度」、及び「通知組織」を含む。キー「時刻」は、業務が実施されたと推定される時間帯であり、キー「目的」は現場の状態の改善目的であり、「業務」は推定業務であり、キー「機能」は業務の実施に必要な機能であり、キー「実施組織」は業務を実施したと推定される組織であり、キー「確度」は推定業務の確度であり、「通知組織」は業務の完了を通知した組織である。

図１１は、実施例１の現場状態情報１３６のデータ構造の一例を示す図である。

現場状態情報１３６には、図１１に示すようなテーブル１１００が格納される。テーブル１１００は、時刻１１０１、客体１１０２、及び状態１１０３を含むエントリを格納する。一つのメッセージ１０００に対して一つのエントリが存在する。

時刻１１０１は、メッセージ１０００のキー「時刻」の値を格納するフィールドである。客体１１０２は、メッセージ１０００のキー「客体」の値を格納するフィールドである。状態１１０３は、メッセージ１０００のキー「状態」の値を格納するフィールドである。

なお、現場状態情報１３６に格納される情報はテーブル形式以外のデータ形式でもよい。

状態監視部１１２は、現場状態キュー１５０に新規メッセージ１０００が登録されたことを検知した場合、メッセージ１０００を取得する。状態監視部１１２は、現場状態情報１３６を参照し、客体１１０２に取得したメッセージ１０００のキー「客体」の値が格納されるエントリを検索する。該当するエントリが存在しない場合、状態監視部１１２は、現場状態情報１３６にエントリを追加し、追加されたエントリの各フィールドにメッセージ１０００に含まれる各キーの値を設定する。該当するエントリが存在する場合、状態監視部１１２は、当該エントリの時刻１１０１及び状態１１０３に、メッセージ１０００に含まれるキー「時刻」及びキー「状態」の値を設定する。これによって、業務管理支援装置１００は、各現場の最新の状態を把握することができる。

図１２は、実施例１の割当業務情報１３７のデータ構造の一例を示す図である。

割当業務情報１３７には、図１２に示すようなテーブル１２００が格納される。テーブル１２００は、時刻１２０１、目的１２０２、業務１２０３、客体１２０４、依頼組織１２０５、状態１２０６、及び更新者１２０７を含むエントリを格納する。一つのメッセージ１０２０に対して一つのエントリが存在する。

時刻１２０１は、メッセージ１０２０のキー「時刻」の値を格納するフィールドである。目的１２０２は、メッセージ１０２０のキー「目的」の値を格納するフィールドである。業務１２０３は、メッセージ１０２０のキー「業務」の値を格納するフィールドである。客体１２０４は、メッセージ１０２０のキー「客体」の値を格納するフィールドである。依頼組織１２０５は、メッセージ１０２０のキー「依頼組織」の値を格納するフィールドである。状態１２０６は、メッセージ１０２０のキー「状態」の値を格納するフィールドである。更新者１２０７は、メッセージ１０２０のキー「更新者」の値を格納するフィールドである。

なお、割当業務情報１３７に格納される情報はテーブル形式以外のデータ形式でもよい。

状態監視部１１２は、割当業務キュー１５２に新規メッセージ１０２０が登録されたことを検知した場合、メッセージ１０２０を取得する。状態監視部１１２は、割当業務情報１３７を参照し、業務１２０３及び客体１２０４の値の組合せが、メッセージ１０２０のキー「業務」及びキー「客体」の値の組合せと一致するエントリを検索する。該当するエントリが存在しない場合、状態監視部１１２は、割当業務情報１２７にエントリを追加し、追加されたエントリの各フィールドにメッセージ１０２０に含まれる各キーの値を設定する。該当するエントリが存在する場合、状態監視部１１２は、当該エントリの時刻１２０１、依頼組織１２０５、状態１２０６、及び更新者１２０７に、メッセージ１０２０に含まれるキー「時刻」、キー「依頼組織」、キー「状態」、及びキー「更新者」の値を設定する。これによって、業務管理支援装置１００は、実施を依頼した業務の最新の実施状態を把握することができる。

図１３は、実施例１の推定業務情報１３８のデータ構造の一例を示す図である。

推定業務情報１３８は、図１３に示すようなテーブル１３００を格納する。テーブル１３００は、業務１３０１、客体１３０２、目的１３０３、時刻１３０４、実施組織１３０５、機能１３０６、確度１３０７、及び通知組織１３０８を含む。

業務１３０１は、メッセージ１０３０のキー「業務」の値を格納するフィールドである。客体１３０２は、メッセージ１０３０のキー「客体」の値を格納するフィールドである。目的１３０３は、メッセージ１０３０のキー「目的」の値を格納するフィールドである。時刻１３０４は、メッセージ１０３０のキー「時刻」の値を格納するフィールドである。実施組織１３０５は、メッセージ１０３０のキー「実施組織」の値を格納するフィールドである。機能１３０６は、メッセージ１０３０のキー「機能」の値を格納するフィールドである。確度１３０７は、メッセージ１０３０のキー「確度」の値を格納するフィールドである。通知組織１３０８は、メッセージ１０３０のキー「通知組織」の値を格納するフィールドである。

状態監視部１１２は、推定業務キュー１５３に新規のメッセージ１０３０が登録されたことを検知した場合、メッセージ１０３０を取得する。状態監視部１１２は、推定業務情報１３８を参照し、業務１３０１及び客体１３０２の値の組合せが、メッセージ１０３０のキー「業務」及びキー「客体」の値の組合せと一致するエントリを検索する。該当するエントリが存在しない場合、状態監視部１１２は、推定業務情報１３８にエントリを追加し、追加されたエントリの各フィールドにメッセージ１０３０に含まれる各キーの値を設定する。なお、確度１３０７には「１」が設定される。該当するエントリが存在する場合、状態監視部１１２は、当該エントリの時刻１３０４及び実施組織１３０５に、メッセージ１０３０に含まれるキー「時刻」及びキー「実施組織」の値を設定する。これによって、業務管理支援装置１００は、推定業務の最新の実施状態を把握することができる。

図１４は、実施例１の業務管理支援装置１００の状態監視部１１２が実行する現場状態確認処理の一例を説明するフローチャートである。

状態監視部１１２は、業務管理支援装置１００の起動後に、メッセージキューの監視を開始する。現場状態キュー１５０の監視では以下のような処理が周期的に実行される。なお、実行周期は任意に設定できる。例えば、実行周期が１分の場合、状態監視部１１２は、１８：００からカウントを開始した場合、１８：０１に現場状態キュー１５０を参照し、１８：００から１８：０１の間に登録されたメッセージ１０００の有無を判定する。

状態監視部１１２は、現場状態キュー１５０に新規メッセージ１０００が登録されたか否かを判定する（ステップＳ１０１）。

新規メッセージ１０００が登録されていない場合、状態監視部１１２は、現場状態キュー１５０の監視を継続する。

新規メッセージ１０００が登録されている場合、ステップＳ１０２以降の処理が実行される。なお、一つの新規メッセージ１０００に対してステップＳ１０２以降の処理が実行される。すなわち、新規メッセージ１０００が複数存在する場合、各メッセージ１０００に対してステップＳ１０２以降の処理が実行される。

状態監視部１１２は、現場状態情報１３６を参照し、客体１１０２に新規メッセージ１０００のキー「客体」の値が格納され、かつ、状態１１０３に新規メッセージ１０００のキー「状態」の値が格納されるエントリを検索し（ステップＳ１０２）、当該エントリが存在するか否かを判定する（ステップＳ１０３）。エントリが存在する場合、すでに現場の状態に応じた業務が実施されている可能性が高いため業務の推定が行われる。一方、エントリが存在しない場合、現場の状態に応じた業務は実施されていない可能性が高いため業務の実施依頼が行われる。

エントリが存在する場合、状態監視部１１２は、業務マニュアル情報１３１を参照し、実施可能な業務を検索し（ステップＳ１０４）、実施可能な業務が存在するか否かを判定する（ステップＳ１０５）。

具体的には、状態監視部１１２は、メッセージ１０００のキー「客体」の値に基づいて客体管理情報１３４を参照し、値を客体カテゴリに変換する。状態監視部１１２は、客体カテゴリ及びキー「状態」の値と、テーブル４００の各エントリの効果４０２の値とを比較することによって、実施可能な業務が存在するか否かを判定する。なお、状態及び状態変化の関係性を定義した情報が予め存在するものとする。

実施可能な業務が存在しない場合、状態監視部１１２は、現場状態キュー１５０の監視を継続する。

実施可能な業務が存在する場合、状態監視部１１２は、ステップＳ１０４において検索されたエントリに基づいて、推定業務のメッセージ１０３０を生成し（ステップＳ１０６）、業務推定部１１１を呼び出す（ステップＳ１０７）。その後、状態監視部１１２は、現場状態キュー１５０の監視を継続する。

具体的には、状態監視部１１２は、ステップＳ１０４において検索されたエントリの業務４０３の値を取得する。状態監視部１１２は、各値（各業務）についてメッセージ１０３０を生成する。メッセージ１０３０のキー「目的」にはエントリの目的４０１の値が設定され、キー「業務」には業務４０３の値が設定され、キー「機能」には機能４０５の値が設定される。メッセージ１０３０のキー「時刻」、キー「実施組織」、及びキー「確度」は空欄となっている。状態監視部１１２は、業務推定部１１１を呼び出し、メッセージ１０３０を出力する。

ステップＳ１０３においてエントリが存在しない場合、状態監視部１１２は、業務発行条件情報１３０を参照し、実施可能な業務を検索し（ステップＳ１０８）、実施可能な業務が存在するか否かを判定する（ステップＳ１０９）。

具体的には、状態監視部１１２は、メッセージ１０００のキー「客体」の値に基づいて客体管理情報１３４を参照し、値を客体カテゴリに変換する。状態監視部１１２は、客体カテゴリ及びキー「状態」の値と、テーブル３００の現場状態３０１の値とを比較することによって、実施可能な業務が存在するか否かを判定する。

実施可能な業務が存在しない場合、状態監視部１１２は、現場状態キュー１５０の監視を継続する。

実施可能な業務が存在する場合、状態監視部１１２は、ステップＳ１０５において検索されたエントリに基づいて、割当業務のメッセージ１０２０を生成し（ステップＳ１１０）、業務割当部１１０を呼び出す（ステップＳ１１１）。その後、状態監視部１１２は、現場状態キュー１５０の監視を継続する。

具体的には、状態監視部１１２は、ステップＳ１０８において検索されたエントリの目的３０２の値を取得する。状態監視部１１２は、業務マニュアル情報１３１を参照し、目的４０１に取得した値が格納されるエントリを検索する。状態監視部１１２は、検索されたエントリの業務４０３の値を取得する。状態監視部１１２は、各値（各業務）についてメッセージ１０２０を生成する。メッセージ１０２０のキー「目的」にはエントリの目的４０１の値が設定され、キー「業務」には業務４０３の値が設定され、キー「客体」にはメッセージ１０００のキー「客体」の値が設定され、キー「依頼組織」にはメッセージ１０００のキー「通知組織」の値が設定される。メッセージ１０２０のキー「状態」及びキー「更新者」は空欄となっている。状態監視部１１２は、業務割当部１１０を呼び出し、メッセージ１０２０を出力する。

次に、図１５Ａ、図１５Ｂ、及び図１６を用いて業務割当部１１０が実行する処理について説明する。

図１５Ａ及び図１５Ｂは、実施例１の割当部１２０が実行する処理の一例を説明するフローチャートである。

割当部１２０は、状態監視部１１２から呼び出された場合、以下で説明する処理を実行する。

割当部１２０は、状態監視部１１２が出力したメッセージ１０２０を取得する（ステップＳ２０１）。割当部１２０は、メッセージ１０２０のキー「依頼組織」に対応する組織をターゲット組織に設定する。

割当部１２０は、ターゲット組織の状態を確認し（ステップＳ２０２）、ターゲット組織がメッセージ１０２０に対応する業務を実施できるか否かを判定する（ステップＳ２０３）。

具体的には、割当部１２０は、組織状態キュー１５１を参照し、キー「組織」にターゲット組織の値が格納され、かつ、キー「時刻」の値が現在から一定時間前の時間範囲に含まれるメッセージ１０１０を検索する。なお、検索する時間の範囲は、１分、３０分、又は１時間等、任意に設定できる。メッセージ１０１０が存在しない場合、割当部１２０は、ターゲット組織が業務を実施できると判定する。検索されたメッセージ１０１０のキー「状態」の値が「通信遮断」又は「応答なし」等である場合、割当部１２０は、ターゲット組織が業務を実施できないと判定する。

ターゲット組織がメッセージ１０２０に対応する業務を実施できる場合、割当部１２０は、メッセージ１０２０のキー「依頼組織」にターゲット組織を設定し（ステップＳ２１１）、当該メッセージ１０２０に対応するエントリを割当業務情報１３７に追加する（ステップＳ２１３）。その後、割当部１２０は処理を終了する。

ターゲット組織がメッセージ１０２０に対応する業務を実施できない場合、割当部１２０は、推定業務情報１３８を参照し、メッセージ１０２０に対応する業務と同一内容の推定業務を検索し（ステップＳ２０４）、メッセージ１０２０に対応する業務と同一内容の推定業務が存在するか否かを判定する（ステップＳ２０５）。

具体的には、割当部１２０は、業務１３０１及び目的１３０３の値の組合せが、メッセージ１０２０のキー「業務」及びキー「目的」の値の組合せに一致し、かつ、メッセージ１０２０のキー「時刻」の値が、時刻１３０４に対応する時間範囲に含まれるエントリを検索する。

メッセージ１０２０に対応する業務と同一内容の推定業務が存在しない場合、割当部１２０は、メッセージ１０２０のキー「依頼組織」に「全組織」を設定し（ステップＳ２１２）、当該メッセージ１０２０に対応するエントリを割当業務情報１３７に追加する（ステップＳ２１３）。その後、割当部１２０は処理を終了する。

メッセージ１０２０に対応する業務と同一内容の推定業務が存在する場合、割当部１２０は、検索されたエントリに基づいて組織のリストを生成し（ステップＳ２０６）、リストの中から一つの組織を選択し、当該組織をターゲット組織に設定する（ステップＳ２０７）。

組織の選択方法としては以下のような方法が考えられる。
（選択方法１）ランダム
（選択方法２）総合確度の大きい順

割当部１２０は、ターゲット組織の状態を確認し（ステップＳ２０８）、ターゲット組織がメッセージ１０２０に対応する業務を実施できるか否かを判定する（ステップＳ２０９）。ステップＳ２０８及びステップＳ２０９の処理は、ステップＳ２０２及びステップＳ２０３の処理と同一である。

ターゲット組織がメッセージ１０２０に対応する業務を実施できる場合、割当部１２０は、メッセージ１０２０のキー「依頼組織」にターゲット組織を設定し（ステップＳ２１１）、当該メッセージ１０２０に対応するエントリを割当業務情報１３７に追加する（ステップＳ２１３）。その後、割当部１２０は処理を終了する。

ターゲット組織がメッセージ１０２０に対応する業務を実施できない場合、割当部１２０は、リストに未処理の組織が存在するか否かを判定する（ステップＳ２１０）。

リストに未処理の組織が存在する場合、割当部１２０はステップＳ２０７に戻り、同様の処理を実行する。

リストに未処理の組織が存在しない場合、割当部１２０は、メッセージ１０２０のキー「依頼組織」に「全組織」を設定し（ステップＳ２１２）、当該メッセージ１０２０に対応するエントリを割当業務情報１３７に追加する（ステップＳ２１３）。その後、割当部１２０は処理を終了する。

図１６は、実施例１の割当業務管理部１２１が実行する処理の一例を説明するフローチャートである。

割当業務管理部１２１は、業務管理支援装置１００の起動後、割当業務情報１３７の監視を開始する。割当業務情報１３７の監視では以下のような処理が周期的に実行される。なお、参照する周期は任意に設定できる。例えば、周期は１０分である。

割当業務管理部１２１は、割当業務情報１３７を参照し、実行されていない業務が存在するか否かを判定する（ステップＳ３０１）。

具体的には、割当業務管理部１２１は、状態１２０６が「未」の状態が時刻１２０１の値から一定時間継続している業務が存在するか否かを判定する。一定時間は、１２時間等、任意に設定できる。

実行されていない業務が存在しない場合、割当業務管理部１２１は割当業務情報１３７の監視を継続する。

実行されていない業務が存在する場合、割当業務管理部１２１は、割当部１２０を呼び出し、当該業務に対応するエントリの情報を通知する（ステップＳ３０２）。その後、割当業務管理部１２１は割当業務情報１３７の監視を継続する。これによって、実施されていない業務の再依頼が行われる。

次に、図１７及び図１８を用いて業務推定部１１１が実行する処理について説明する。

図１７は、実施例１の推定部１２２が実行する処理の一例を説明するフローチャートである。

推定部１２２は、状態監視部１１２から呼び出された場合、以下で説明する処理を実行する。

推定部１２２は、状態監視部１１２が出力したメッセージ１０３０を取得する（ステップＳ４０１）。推定部１２２は、メッセージ１０３０のキー「実施組織」に対応する組織をターゲット組織に設定する。

推定部１２２は、ターゲット組織の状態を確認し（ステップＳ４０２）、ターゲット組織がメッセージ１０３０に対応する業務を実施できるか否かを判定する（ステップＳ４０３）。

ステップＳ４０２の処理はステップＳ２０２の処理と同一である。ステップＳ４０３の処理はステップＳ２０３の処理と同一でもよいし、以下のような処理でもよい。推定部１２２は、推定業務情報１３８を参照し、機能１３０６にメッセージ１０３０のキー「機能」の値が設定されているエントリが存在するか否かを判定する。エントリが存在しない場合、推定部１２２は、ターゲット組織が業務を実施できると判定する。

ターゲット組織がメッセージ１０３０に対応する業務を実施できる場合、推定部１２２は、メッセージ１０３０のキー「実施組織」にターゲット組織を設定し（ステップＳ４０９）、当該メッセージ１０３０に対応するエントリを推定業務情報１３８に追加する（ステップＳ４１１）。その後、推定部１２２は処理を終了する。

ターゲット組織がメッセージ１０３０に対応する業務を実施できない場合、推定部１２２は、所有リソース情報１３２を参照し、当該業務の実施に必要な機能を有する組織を抽出し、組織のリストを生成する（ステップＳ４０４）。

具体的には、推定部１２２は、テーブル５００の各エントリの機能５０２と、メッセージ１０３０のキー「機能」とを比較することによって、業務の実施に必要な機能を有する組織を抽出する。

推定部１２２は、組織のリストの中から一つの組織を選択し、当該組織をターゲット組織に設定する（ステップＳ４０５）。

推定部１２２は、ターゲット組織の状態を確認し（ステップＳ４０６）、ターゲット組織がメッセージ１０２０に対応する業務を実施できるか否かを判定する（ステップＳ４０７）。ステップＳ４０６及びステップＳ４０７の処理は、ステップＳ４０２及びステップＳ４０３の処理と同一である。

ターゲット組織がメッセージ１０３０に対応する業務を実施できる場合、推定部１２２は、メッセージ１０３０のキー「実施組織」にターゲット組織を設定し（ステップＳ４０９）、当該メッセージ１０３０に対応するエントリを推定業務情報１３８に追加する（ステップＳ４１１）。その後、推定部１２２は処理を終了する。

ターゲット組織がメッセージ１０３０に対応する業務を実施できない場合、推定部１２２は、リストに未処理の組織が存在するか否かを判定する（ステップＳ４０８）。

リストに未処理の組織が存在する場合、推定部１２２はステップＳ４０５に戻り、同様の処理を実行する。

リストに未処理の組織が存在しない場合、推定部１２２は、メッセージ１０３０のキー「実施組織」を空欄に設定し（ステップＳ４１０）、当該メッセージ１０３０に対応するエントリを推定業務情報１３８に追加する（ステップＳ４１１）。その後、推定部１２２は処理を終了する。

図１８は、実施例１の推定業務管理部１２３が実行する処理の一例を説明するフローチャートである。

推定業務管理部１２３は、業務管理支援装置１００の起動後、推定業務情報１３８の監視を開始する。推定業務情報１３８の監視では以下のような処理が周期的に実行される。なお、参照する周期は任意に設定できる。例えば、周期は１０分である。

推定業務管理部１２３は、推定業務情報１３８を参照し、更新されたエントリが存在するか否かを判定する（ステップＳ５０１）。なお、推定業務管理部１２３による更新は対象としない。

更新されたエントリが存在しない場合、推定業務管理部１２３は推定業務情報１３８の監視を継続する。

更新されたエントリが存在する場合、推定業務管理部１２３は、割当業務情報１３７を参照し、更新されたエントリに対応する割当業務のエントリを検索し（ステップＳ５０２）、推定業務に対応する割当業務が存在するか否かを判定する（ステップＳ５０３）。

具体的には、推定業務管理部１２３は、業務１２０３の値が更新されたエントリの業務１３０１の値に一致し、依頼組織１２０５の値が更新されたエントリの実施組織１３０５の値に一致し、かつ、時刻１２０１に格納される時刻が更新されたエントリの時刻１３０４に格納される時間範囲に含まれるエントリを検索する。

推定業務に対応する割当業務が存在しない場合、推定業務管理部１２３は推定業務情報１３８の監視を継続する。

推定業務に対応する割当業務が存在する場合、推定業務管理部１２３は、確度算出ロジック情報１３５に基づいて、更新されたエントリの確度１３０７を更新する（ステップＳ５０４）。

図１９は、実施例１の業務管理支援装置１００の内部の処理のイメージを示す図である。

状態監視部１１２は、現場状態キュー１５０からメッセージ１０００を取得し、メッセージ１０００のキー「客体」に基づいて業務発行条件情報１３０を参照し、現場状態に合致するエントリを検索する。該当するエントリが存在する場合、状態監視部１１２は、当該エントリに基づいて割当業務のメッセージ１０２０を生成し、割当部１２０に出力する。該当するエントリが存在しない場合、状態監視部１１２は、現場状態情報１３６から、客体１１０２の値がメッセージ１０００のキー「客体」の値と一致するエントリを取得する。状態監視部１１２は、取得したエントリの客体１１０２及び状態１１０３の値の組合せに基づいて、業務マニュアル情報１３１を参照し、実施可能な業務のエントリを取得する。状態監視部１１２は、取得したエントリに基づいてメッセージ１０３０を生成し、推定部１２２に出力する。

割当部１２０は、状態監視部１１２からメッセージ１０２０を取得した場合、組織状態キュー１５１に基づいて、組織が業務を実施できるか確認する。組織が業務を実施できる場合、割当部１２０は、割当業務情報１３７に当該メッセージ１０２０に対応するエントリを追加する。組織が業務を実施できない場合、割当部１２０は、推定業務情報１３８を参照し、同一内容の推定業務を検索する。さらに、割当部１２０は、組織状態キュー１５１及び確度算出ロジック情報１３５に基づいて推定業務を組織が実施できるか否かを判定し、推定業務を組織が実施できる場合には、メッセージ１０２０のキー「依頼組織」の値を書き換え、割当業務情報１３７に当該メッセージ１０２０に対応するエントリを追加する。

割当業務管理部１２１は、割当業務情報１３７を監視し、一定期間実施されていない業務が存在する場合、当該業務に対応するエントリを割当部１２０に出力する。割当部１２０は、図１５Ａ及び図１５Ｂに示す処理を実行し、メッセージ１０２０のキー「依頼組織」を更新し、割当業務情報１３７に当該メッセージ１０２０に対応するエントリを追加する。

推定部１２２は、状態監視部１１２からメッセージ１０３０を取得した場合、組織状態キュー１５１に基づいて組織が業務を実施できるか確認する。組織が業務を実施できる場合、推定部１２２は、推定業務情報１３８に当該メッセージ１０３０に対応するエントリを追加する。組織が業務を実施できない場合、推定部１２２は、所有リソース情報１３２に基づいて、業務を実施するために必要な機能を有する組織を特定し、組織状態キュー１５１に基づいて当該組織が業務を実施できるか確認する。組織が業務を実施できる場合、推定部１２２は、メッセージ１０３０のキー「実施組織」の値を書き換え、推定業務情報１３８に当該メッセージ１０３０に対応するエントリを追加する。

推定業務管理部１２３は、推定業務情報１３８を監視し、更新されたエントリが存在する場合、割当業務情報１３７を参照し、当該エントリ（推定業務）に対応する割当業務を検索する。エントリに対応する割当業務が存在する場合、推定業務管理部１２３は、確度算出ロジック情報１３５に基づいて確度を算出し、エントリの確度１３０７の値を書き換える。

図２０は、実施例１の業務管理支援装置１００及びメッセージングシステム１０１の間のメッセージの流れを示す図である。図２１は、実施例１の端末１０２に提示される画面の一例を説明する図である。

まず、端末１０２に提示される画面について説明する。端末１０２には、メッセージングシステム１０１によって図２１に示すような画面２１００が提示される。

画面２１００は、表示欄２１０１、２１０２、２１０３、２１０４、２１０５と、操作欄２１０６とを含む。

表示欄２１０１は、端末１０２に対応する組織に実施が依頼されている業務（割当業務）を表示する欄である。表示欄２１０２は、端末１０２に対応する組織とは異なる組織に実施が依頼されている業務（割当業務）を表示する欄である。表示欄２１０３は、端末１０２に対応する組織が実施したと推定される業務（推定業務）を表示する欄である。表示欄２１０４は、端末１０２に対応する組織とは異なる組織が実施したと推定される業務（推定業務）を表示する欄である。表示欄２１０５は、割当業務又は推定業務の詳細を表示する欄である。操作欄２１０６は、各種操作を選択するための欄である。

端末１０２を操作するユーザは、表示欄２１０１、２１０２、２１０３、２１０４を閲覧することによって、自組織及び他組織の割当業務及び推定業務を確認できる。割当業務の詳細を確認する場合、ユーザは、表示欄２１０１又は表示欄２１０２に表示される業務を選択する。これによって、表示欄２１０５に選択された割当業務の詳細が表示される。推定業務の詳細を確認する場合、ユーザは、表示欄２１０３又は表示欄２１０４に表示される業務を選択する。これによって、表示欄２１０４に選択された推定業務の詳細が表示される。

ユーザは、割当業務又は推定業務に関する編集を行う場合、操作欄２１０６の「編集」を選択する。割当業務を編集する場合、表示欄２１０４の表示が、依頼組織、状態、及び更新者等が編集可能な状態に遷移する。推定業務を編集する場合、表示欄２１０４の表示が、時刻、実施組織、及び確度等が編集可能な状態に遷移する。ユーザは、値を編集し、操作欄２１０６の送信ボタンを押下する。これによって、メッセージが更新される。

ユーザは、割当業務に関するメッセージを生成する場合、操作欄２１０６の「業務生成」を選択し、推定業務に関するメッセージを生成する場合、操作欄２１０６の「推定業務生成」を選択する。表示欄２１０４には、割当業務又は推定業務のメッセージを生成するためのテンプレートが表示される。ユーザは、テンプレートに値を入力し、操作欄２１０６の送信ボタンを押下する。これによって、メッセージキューにメッセージが登録される。

状態監視部１１２は、組織によって現場状態キュー１５０にメッセージ１０００が登録された場合、メッセージ入出力部１４０を介して、メッセージ１０００を取得し、現場状態情報１３６にメッセージ１０００に対応するエントリを登録する。

状態監視部１１２は、割当業務情報１３７にエントリが登録された場合、当該エントリからメッセージ１０２０を生成し、メッセージ入出力部１４０に送信する。メッセージ入出力部１４０は、メッセージ１０２０を割当業務キュー１５２に登録する。

任意の組織が、画面２１００を介してメッセージ１０２０のキー「状態」を「未」から「済」に更新した場合、状態監視部１１２は、メッセージ入出力部１４０を介して、更新されたメッセージ１０２０を取得し、割当業務情報１３７に当該メッセージに対応するエントリを登録する。

状態監視部１１２は、推定業務情報１３８にエントリが登録された場合、当該エントリからメッセージ１０３０を生成し、メッセージ入出力部１４０に送信する。メッセージ入出力部１４０は、メッセージ１０３０を推定業務キュー１５３に登録する。

任意の組織が、画面２１００を介してメッセージ１０３０のキー「状態」、キー「実施組織」、及びキー「確度」等を更新した場合、状態監視部１１２は、メッセージ入出力部１４０を介して、更新されたメッセージ１０３０を取得し、推定業務情報１３８に当該メッセージに対応するエントリを登録する。

以上で説明したように、実施例１によれば、業務管理支援装置１００は、現場から断片的に取得できる情報に基づいて現場の状態及び実行されている可能性がある業務を把握し、組織に割り当てる業務を計画し、依頼することができる。これによって、災害時の組織間の業務の円滑な連携が可能となり、災害時の活動の迅速化及び効率化を実現できる。

次に、実施例２について説明する。実施例２では、推定部１２２が実行する処理が一部異なる。以下、実施例１との差異を中心に実施例２について説明する。

実施例２のシステム構成、ハードウェア構成、及びソフトウェア構成は実施例１と同一である。実施例２では、推定部１２２が実行する処理が一部異なる。具体的には、ステップＳ４０３の判定方法が異なる。

（判定方法１）推定部１２２は、各組織の現場状態キュー１５０に登録すべき情報の登録状態に基づいて、組織が業務を実施できるか否かを判定する。例えば、平常時には医療施設の情報を１時間間隔で現場状態キュー１５０に登録していた組織が、任意の時間帯に医療施設の情報を登録していない場合、推定部１２２は、その時間帯において組織に何らかのトラブルが発生しており、業務を実施できないと判定する。

（判定方法２）推定部１２２は、組織の連絡相手に基づいて、組織が業務を実施できるか否かを判定する。例えば、「啓開箇所決定」の業務をＡ省が実施した旨のメッセージが割当業務キュー１５２に登録され、業務が実施されていた時間帯にＡ省及びＢ省との間で密に連絡が行われていた場合、推定部１２２は、「車両撤去」の業務はＢ省によって実行された可能性が高いと判定する。

このように、処理に使用する情報を組み合わせることによって推定の精度を向上させることができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

１００ 業務管理支援装置
１０１ メッセージングシステム
１０２ 端末
１０５ ネットワーク
１１０ 業務割当部
１１１ 業務推定部
１１２ 状態監視部
１１３ マニュアル選択部
１２０ 割当部
１２１ 割当業務管理部
１２２ 推定部
１２３ 推定業務管理部
１２７ 割当業務情報
１３０ 業務発行条件情報
１３１ 業務マニュアル情報
１３２ 所有リソース情報
１３３ 組織管理情報
１３４ 客体管理情報
１３５ 確度算出ロジック情報
１３６ 現場状態情報
１３７ 割当業務情報
１３８ 推定業務情報
１４０ メッセージ入出力部
１５０ 現場状態キュー
１５１ 組織状態キュー
１５２ 割当業務キュー
１５３ 推定業務キュー
２０１ プロセッサ
２０２ 主記憶装置
２０３ 副記憶装置
２０４ ネットワークインタフェース

Claims (6)

1. プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する、少なくとも一つの計算機を含む計算機システムであって、
   災害に対する業務を実行する複数の組織が管理する端末と接続し、
   前記複数の組織の端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信し、
   前記計算機システムは、現場の状態及び業務目的を含む第１データを格納する業務発行条件情報と、業務目的、業務、及び業務の実施に必要なリソースを含む第２データを格納する業務マニュアル情報と、を保持し、
   前記少なくとも一つの計算機は、
   取得した前記現場情報に基づいて現場の状態を特定し、
   特定された前記現場の状態に基づいて実施が必要な割当業務を特定し、
   取得した前記活動情報に基づいて、前記複数の組織の活動状態を把握し、
   前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定し、
   決定された前記組織に、前記割当業務の実施依頼を送信し、
   前記割当業務の特定では、前記少なくとも一つの計算機は、
   前記業務発行条件情報に基づいて、特定された前記現場の状態に対応する前記業務目的を特定し、
   前記業務マニュアル情報に基づいて、特定された前記業務目的に対応する前記業務を、前記割当業務として特定することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記複数の組織が有するリソースを管理するための所有リソース情報を保持し、
   前記第２データは、業務の効果を含み、
   前記少なくとも一つの計算機は、
   受信した前記現場情報の現場と同一の現場に関する前記現場情報をすでに受信している場合、前記業務マニュアル情報を参照して、特定された前記現場の状態及び前記第２データに含まれる前記業務の効果との比較結果に基づいて、前記現場の状態に対応する業務を推定業務として特定し、
   前記所有リソース情報に基づいて、前記推定業務を実施に必要なリソースを有する前記組織を特定し、
   特定された前記組織の前記活動情報に基づいて、当該組織の活動状態を把握し、
   特定された前記組織の活動状態に基づいて、前記推定業務を実施している可能性がある組織を特定し、
   前記推定業務及び特定された前記組織を対応づけて記録し、
   特定された前記組織による前記推定業務の実行実績を評価する指標を算出し、
   前記指標及び前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記少なくとも一つの計算機及び前記複数の組織の端末は、メッセージキューを介して、情報を送受信することを特徴とする計算機システム。
4. 計算機システムが実行する災害に対応する業務の割当方法であって、
   前記計算機システムは、
   プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する、少なくとも一つの計算機を含み、
   災害に対する業務を実行する複数の組織が管理する端末と接続し、
   前記複数の組織の端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信し、
   前記計算機システムは、現場の状態及び業務目的を含む第１データを格納する業務発行条件情報と、業務目的、業務、及び業務の実施に必要なリソースを含む第２データを格納する業務マニュアル情報と、を保持し、
   前記災害に対応する業務の割当方法は、
   前記少なくとも一つの計算機が、取得した前記現場情報に基づいて現場の状態を特定する第１のステップと、
   前記少なくとも一つの計算機が、特定された前記現場の状態に基づいて実施が必要な割当業務を特定する第２のステップと、
   前記少なくとも一つの計算機が、取得した前記活動情報に基づいて、前記複数の組織の活動状態を把握する第３のステップと、
   前記少なくとも一つの計算機が、前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定する第４のステップと、
   前記少なくとも一つの計算機が、決定された前記組織に、前記割当業務の実施依頼を送信する第５のステップと、を含み、
   前記第２のステップは、
   前記少なくとも一つの計算機が、前記業務発行条件情報に基づいて、特定された前記現場の状態に対応する前記業務目的を特定するステップと、
   前記少なくとも一つの計算機が、前記業務マニュアル情報に基づいて、特定された前記業務目的に対応する前記業務を、前記割当業務として特定するステップと、を含むことを特徴とする災害に対応する業務の割当方法。
5. 請求項４に記載の災害に対応する業務の割当方法であって、
   前記計算機システムは、前記複数の組織が有するリソースを管理するための所有リソース情報を保持し、
   前記第２データは、業務の効果を含み、
   前記災害に対応する業務の割当方法は、
   前記少なくとも一つの計算機が、受信した前記現場情報の現場と同一の現場に関する前記現場情報をすでに受信している場合、前記業務マニュアル情報を参照して、特定された前記現場の状態及び前記第２データに含まれる前記業務の効果との比較結果に基づいて、前記現場の状態に対応する業務を推定業務として特定するステップと、
   前記少なくとも一つの計算機が、前記所有リソース情報に基づいて、前記推定業務を実施に必要なリソースを有する前記組織を特定するステップと、
   前記少なくとも一つの計算機が、特定された前記組織の前記活動情報に基づいて、当該組織の活動状態を把握するステップと、
   前記少なくとも一つの計算機が、特定された前記組織の活動状態に基づいて、前記推定業務を実施している可能性がある組織を特定するステップと、
   前記少なくとも一つの計算機が、前記推定業務及び特定された前記組織を対応づけて記録するステップと、
   前記少なくとも一つの計算機が、特定された前記組織による前記推定業務の実行実績を評価する指標を算出するステップと、を含み、
   前記第４のステップは、前記少なくとも一つの計算機が、前記指標及び前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定するステップを含むことを特徴とする災害に対応する業務の割当方法。
6. 請求項５に記載の災害に対応する業務の割当方法であって、
   前記少なくとも一つの計算機及び前記複数の組織の端末は、メッセージキューを介して、情報を送受信することを特徴とする災害に対応する業務の割当方法。

Images