IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧 ▶ 独立行政法人防災科学技術研究所の特許一覧

特許7266256計算機システム及び災害に対応する業務の割当方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2023-04-20
(45)【発行日】2023-04-28
(54)【発明の名称】計算機システム及び災害に対応する業務の割当方法
(51)【国際特許分類】
   G06Q 10/00 20230101AFI20230421BHJP
   G06Q 50/26 20120101ALN20230421BHJP
【FI】
G06Q10/00
G06Q50/26
【請求項の数】 6
(21)【出願番号】P 2022004375
(22)【出願日】2022-01-14
【審査請求日】2022-01-14
【国等の委託研究の成果に係る記載事項】(出願人による申告)令和3年度、国立研究開発法人防災科学技術研究所、戦略的イノベーション創造プログラム(SIP)「国家レジリエンス(防災・減災)の強化/「災害動態解析と統合化システム連動技術の研究開発」委託研究、産業技術力強化法第17条の適用を受ける特許出願
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(73)【特許権者】
【識別番号】501138231
【氏名又は名称】国立研究開発法人防災科学技術研究所
(74)【代理人】
【識別番号】110001678
【氏名又は名称】藤央弁理士法人
(72)【発明者】
【氏名】永吉 勤
(72)【発明者】
【氏名】小林 悠一
(72)【発明者】
【氏名】谷本 幸一
(72)【発明者】
【氏名】臼田 裕一郎
(72)【発明者】
【氏名】花島 誠人
【審査官】田付 徳雄
(56)【参考文献】
【文献】特開2016-071420(JP,A)
【文献】特開2011-086237(JP,A)
【文献】米国特許出願公開第2011/0270767(US,A1)
【文献】米国特許出願公開第2009/0327052(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する、少なくとも一つの計算機を含む計算機システムであって、
災害に対する業務を実行する複数の組織が管理する端末と接続し、
前記複数の組織の端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信し、
前記計算機システムは、現場の状態及び業務目的を含む第1データを格納する業務発行条件情報と、業務目的、業務、及び業務の実施に必要なリソースを含む第2データを格納する業務マニュアル情報と、を保持し、
前記少なくとも一つの計算機は、
取得した前記現場情報に基づいて現場の状態を特定し、
特定された前記現場の状態に基づいて実施が必要な割当業務を特定し、
取得した前記活動情報に基づいて、前記複数の組織の活動状態を把握し、
前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定し、
決定された前記組織に、前記割当業務の実施依頼を送信し、
前記割当業務の特定では、前記少なくとも一つの計算機は、
前記業務発行条件情報に基づいて、特定された前記現場の状態に対応する前記業務目的を特定し、
前記業務マニュアル情報に基づいて、特定された前記業務目的に対応する前記業務を、前記割当業務として特定することを特徴とする計算機システム。
【請求項2】
請求項1に記載の計算機システムであって、
前記複数の組織が有するリソースを管理するための所有リソース情報を保持し、
前記第2データは、業務の効果を含み、
前記少なくとも一つの計算機は、
受信した前記現場情報の現場と同一の現場に関する前記現場情報をすでに受信している場合、前記業務マニュアル情報を参照して、特定された前記現場の状態及び前記第2データに含まれる前記業務の効果との比較結果に基づいて、前記現場の状態に対応する業務を推定業務として特定し、
前記所有リソース情報に基づいて、前記推定業務を実施に必要なリソースを有する前記組織を特定し、
特定された前記組織の前記活動情報に基づいて、当該組織の活動状態を把握し、
特定された前記組織の活動状態に基づいて、前記推定業務を実施している可能性がある組織を特定し、
前記推定業務及び特定された前記組織を対応づけて記録し、
特定された前記組織による前記推定業務の実行実績を評価する指標を算出し、
前記指標及び前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定することを特徴とする計算機システム。
【請求項3】
請求項2に記載の計算機システムであって、
前記少なくとも一つの計算機及び前記複数の組織の端末は、メッセージキューを介して、情報を送受信することを特徴とする計算機システム。
【請求項4】
計算機システムが実行する災害に対応する業務の割当方法であって、
前記計算機システムは、
プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する、少なくとも一つの計算機を含み、
災害に対する業務を実行する複数の組織が管理する端末と接続し、
前記複数の組織の端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信し、
前記計算機システムは、現場の状態及び業務目的を含む第1データを格納する業務発行条件情報と、業務目的、業務、及び業務の実施に必要なリソースを含む第2データを格納する業務マニュアル情報と、を保持し、
前記災害に対応する業務の割当方法は、
前記少なくとも一つの計算機が、取得した前記現場情報に基づいて現場の状態を特定する第1のステップと、
前記少なくとも一つの計算機が、特定された前記現場の状態に基づいて実施が必要な割当業務を特定する第2のステップと、
前記少なくとも一つの計算機が、取得した前記活動情報に基づいて、前記複数の組織の活動状態を把握する第3のステップと、
前記少なくとも一つの計算機が、前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定する第4のステップと、
前記少なくとも一つの計算機が、決定された前記組織に、前記割当業務の実施依頼を送信する第5のステップと、を含み、
前記第2のステップは、
前記少なくとも一つの計算機が、前記業務発行条件情報に基づいて、特定された前記現場の状態に対応する前記業務目的を特定するステップと、
前記少なくとも一つの計算機が、前記業務マニュアル情報に基づいて、特定された前記業務目的に対応する前記業務を、前記割当業務として特定するステップと、を含むことを特徴とする災害に対応する業務の割当方法。
【請求項5】
請求項4に記載の災害に対応する業務の割当方法であって、
前記計算機システムは、前記複数の組織が有するリソースを管理するための所有リソース情報を保持し、
前記第2データは、業務の効果を含み、
前記災害に対応する業務の割当方法は、
前記少なくとも一つの計算機が、受信した前記現場情報の現場と同一の現場に関する前記現場情報をすでに受信している場合、前記業務マニュアル情報を参照して、特定された前記現場の状態及び前記第2データに含まれる前記業務の効果との比較結果に基づいて、前記現場の状態に対応する業務を推定業務として特定するステップと、
前記少なくとも一つの計算機が、前記所有リソース情報に基づいて、前記推定業務を実施に必要なリソースを有する前記組織を特定するステップと、
前記少なくとも一つの計算機が、特定された前記組織の前記活動情報に基づいて、当該組織の活動状態を把握するステップと、
前記少なくとも一つの計算機が、特定された前記組織の活動状態に基づいて、前記推定業務を実施している可能性がある組織を特定するステップと、
前記少なくとも一つの計算機が、前記推定業務及び特定された前記組織を対応づけて記録するステップと、
前記少なくとも一つの計算機が、特定された前記組織による前記推定業務の実行実績を評価する指標を算出するステップと、を含み、
前記第4のステップは、前記少なくとも一つの計算機が、前記指標及び前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定するステップを含むことを特徴とする災害に対応する業務の割当方法。
【請求項6】
請求項5に記載の災害に対応する業務の割当方法であって、
前記少なくとも一つの計算機及び前記複数の組織の端末は、メッセージキューを介して、情報を送受信することを特徴とする災害に対応する業務の割当方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、災害発生時の業務を複数の縦割り組織が参加する災害対応現場において、円滑な組織間連携を支援する技術に関する。
【背景技術】
【0002】
災害時には、多くの組織が多岐に亘る活動を実施する。災害時の活動の効率化には、活動を行っている組織の状態及び組織が保有する情報を組織間で共有し、共有した情報から活動の全体像を把握する必要がある。
【0003】
しかし、活動を行う組織は縦割りの組織であるため、他の組織の状態を把握できず、組織間の連携が難しい。また、医療活動支援、道路啓開、及び物資供給支援等、目的に応じて必要となる機能(リソース)が異なり、また、組織の状態も時々刻々と変化するため、割り当てられた業務が実施されていない事態が起こりうる。前述のように組織間の連携が不十分であるため、業務が実施されていないことが後に発覚し、対応が後手後手となる。
【0004】
前述のような問題を解決するための技術として、特許文献1及び特許文献2に記載の技術が知られている。
【0005】
特許文献1には、「意思決定に必要な情報を、意思決定支援装置101からネットワーク129を介して各種端末(130、140、150、160)に配信するために、意思決定の原因となるイベントをイベント管理部109で検知し、当該イベントに応じたタスク(業務)割当ておよび通知すべき情報を、イベント(およびこれに伴う状況)に応じて、情報相関管理部111で管理される各情報の相関関係を用いて、決定する」こと、及び、「決定された情報を、インターフェース部117を介して各種端末に配信する」ことが記載されている。
【0006】
特許文献2には、「新規起票時および関連起票時に、危機対応業務管理支援サーバSVにより、タスクを識別するレコードIDと、タスクのグループを識別するタスクID(Task-ID)と、関連起票時に起票元となるタスクとの関係性を示すID(Org-ID)と、タスクグループ内における各タスクの世代を階層化して示すレイヤ情報を生成し、これを依頼情報に付加して活動ログ記憶部32に蓄積する。そして、タスクグループごとにそのタスクのリストを表示する際に、タスクの対応状況を時系列上で並べて表示させる。また、蓄積された上記タスクデータごとにボトルネック度を計算し、計算されたボトルネック度を上記タスクデータのリストに付加して表示する」ことが記載されている。
【先行技術文献】
【特許文献】
【0007】
【文献】特開2013-088829号公報
【文献】特開2016-224671号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
特許文献1に記載の技術では、混乱している現場における業務の実施の可否が考慮されていない。特許文献2に記載の技術では、各組織が実施している業務について報告を行うことを前提としている。しかし、現場の状態によっては報告ができない場合がある。報告がない業務こそ緊急性が高くシステムが管理するべきであり、特許文献2に記載の技術では対応できない。
【0009】
このように、従来技術では、割当業務、及び現場に応じて行われた規定外の業務に関する報告が欠落することが想定されておらず、情報の欠落が発生した場合、正しく機能しない。
【0010】
本発明は、現場から断片的に取得できる情報から現場の状態を把握し、組織に割り当てる業務を計画することによって、災害時の組織間の業務の連携を支援することを目的とする。
【課題を解決するための手段】
【0011】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する、少なくとも一つの計算機を含む計算機システムであって、災害に対する業務を実行する複数の組織が管理する端末と接続し、前記複数の組織の端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信し、前記計算機システムは、現場の状態及び業務目的を含む第1データを格納する業務発行条件情報と、業務目的、業務、及び業務の実施に必要なリソースを含む第2データを格納する業務マニュアル情報と、を保持し、前記少なくとも一つの計算機は、取得した前記現場情報に基づいて現場の状態を特定し、特定された前記現場の状態に基づいて実施が必要な割当業務を特定し、取得した前記活動情報に基づいて、前記複数の組織の活動状態を把握し、前記複数の組織の活動状態に基づいて、前記割当業務を実行可能な組織を決定し、決定された前記組織に、前記割当業務の実施依頼を送信し、前記割当業務の特定では、前記少なくとも一つの計算機は、前記業務発行条件情報に基づいて、特定された前記現場の状態に対応する前記業務目的を特定し、前記業務マニュアル情報に基づいて、特定された前記業務目的に対応する前記業務を、前記割当業務として特定する。
【発明の効果】
【0012】
本発明によれば、現場から断片的に取得できる情報に基づいて、現場の状態を把握し、組織に対する業務の割当てを計画できる。これによって、災害時の組織間の業務の連携を支援できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【0013】
図1】実施例1のシステム構成の一例を示す図である。
図2】実施例1の業務管理支援装置のハードウェア構成の一例を示す図である。
図3】実施例1の業務発行条件情報のデータ構造の一例を示す図である。
図4】実施例1の業務マニュアル情報のデータ構造の一例を示す図である。
図5】実施例1の所有リソース情報のデータ構造の一例を示す図である。
図6】実施例1の組織管理情報のデータ構造の一例を示す図である。
図7】実施例1の客体管理情報のデータ構造の一例を示す図である。
図8】実施例1の業務発行条件情報、業務マニュアル情報、所有リソース情報、組織管理情報、及び客体管理情報の対応関係を説明する図である。
図9】実施例1の確度算出ロジック情報のデータ構造に一例を示す図である。
図10A】実施例1のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。
図10B】実施例1のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。
図10C】実施例1のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。
図10D】実施例1のメッセージングシステムが蓄積するメッセージのデータ構造の一例を示す図である。
図11】実施例1の現場状態情報のデータ構造の一例を示す図である。
図12】実施例1の割当業務情報のデータ構造の一例を示す図である。
図13】実施例1の推定業務情報のデータ構造の一例を示す図である。
図14】実施例1の業務管理支援装置の状態監視部が実行する現場状態確認処理の一例を説明するフローチャートである。
図15A】実施例1の割当部が実行する処理の一例を説明するフローチャートである。
図15B】実施例1の割当部が実行する処理の一例を説明するフローチャートである。
図16】実施例1の割当業務管理部が実行する処理の一例を説明するフローチャートである。
図17】実施例1の推定部が実行する処理の一例を説明するフローチャートである。
図18】実施例1の推定業務管理部が実行する処理の一例を説明するフローチャートである。
図19】実施例1の業務管理支援装置の内部の処理のイメージを示す図である。
図20】実施例1の業務管理支援装置及びメッセージングシステムの間のメッセージの流れを示す図である。
図21】実施例1の端末に提示される画面の一例を説明する図である。
【発明を実施するための形態】
【0014】
以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
【0015】
以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。
【0016】
本明細書等における「第1」、「第2」、「第3」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。
【0017】
図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。
【実施例1】
【0018】
図1は、実施例1のシステム構成の一例を示す図である。図2は、実施例1の業務管理支援装置100のハードウェア構成の一例を示す図である。
【0019】
図1に示すように、システムは、業務管理支援装置100、メッセージングシステム101、及び端末102から構成される。業務管理支援装置100、メッセージングシステム101、及び端末102はネットワーク105を介して互いに接続される。
【0020】
端末102は、災害時に業務を行う組織が管理する端末である。端末102は、例えば、パーソナルコンピュータ及びスマートフォン等である。図1では、三つの組織の端末102を示している。なお、本発明は端末102の種別及び数に限定されない。端末102は、アクティブ状態/非アクティブ状態に関する情報、他の端末102との間の連絡等の活動ログ、被災状況に関する情報等をメッセージングシステム101に登録する機能を有する。また、端末102は、メッセージングシステム101からメッセージを取得し、取得したメッセージに対応する応答メッセージをメッセージングシステム101に送信することができる。
【0021】
メッセージングシステム101は、メッセージキューを実現するシステムである。メッセージングシステム101は、業務管理支援装置100と端末102との間の情報をメッセージとして保持し、中継する。
【0022】
メッセージングシステム101は、メッセージ入出力部140を有し、また、現場状態キュー150、組織状態キュー151、割当業務キュー152、及び推定業務キュー153を管理する。
【0023】
現場状態キュー150は、気象及び河川の状態(例えば、河川の氾濫)、ライフラインの状態(例えば、停電)、医療施設の状態、並びに、被害の規模及び範囲等、現場の状態に関する情報を含むメッセージ1000(図10Aを参照)を蓄積する。組織状態キュー151は、組織の活動状態に関する情報を含むメッセージ1010(図10Bを参照)を蓄積する。割当業務キュー152は、業務管理支援装置100によって実施が依頼された業務に関する情報を含むメッセージ1020(図10Cを参照)を蓄積する。推定業務キュー153は、業務管理支援装置100によって任意の組織によって実施されていると推定された業務に関する情報を含むメッセージ1030(図10Dを参照)を蓄積する。
【0024】
メッセージ入出力部140は、各キューへのメッセージの登録及び各キューからのメッセージの読出を行う。メッセージ入出力部140は、キューへのメッセージの蓄積時に、端末102等から受信した情報を所定の形式のメッセージに変換し、当該メッセージを登録する。
【0025】
(例1)端末102から「道路名称」及び「通行可否状態」のから構成されるエントリを100個含むテーブルを受信した場合、メッセージ入出力部140は、テーブルが送信された時刻、「道路名称」、及び「通行可否状態」から構成される100個のメッセージ1000を生成し、現場状態キュー150に登録する。なお、上記の例では、テーブル形式のデータをメッセージに変換していたが、これに限定されない。受信する情報のデータ形式はJSON形式及びXML形式等でもよい。
【0026】
(例2)端末102から「医療施設名称」のフィールドと、「電力状態」、「給水状態」、及び「衣料品保有状態」等の状態を表す30個のフィールドとから構成されるエントリを100個格納するテーブルを受信した場合、メッセージ入出力部140は、一つのエントリに対して、各状態のフィールドの値を含む30個のメッセージ1000を生成する。メッセージ入出力部140は、3000個のメッセージ1000を現場状態キュー150に登録する。なお、上記の例では、テーブル形式のデータをメッセージに変換していたが、これに限定されない。受信する情報のデータ形式はJSON形式及びXML形式等でもよい。
【0027】
(例3)メッセージ入出力部140は、端末102の通信状態又は応答の有無を確認し、確認結果を含むメッセージ1010を生成し、当該メッセージを組織状態キュー151に登録する。
【0028】
業務管理支援装置100は、メッセージングシステム101を介して端末102から取得した情報に基づいて現場の状態を把握し、実施されている可能性がある業務を推定する。また、業務管理支援装置100は、メッセージングシステム101を介して端末102から取得した情報に基づいて組織の状態を把握し、実施が必要な業務を特定し、当該業務の実施を依頼する組織を決定し、メッセージングシステム101を介して当該組織に業務の実施を依頼する。
【0029】
業務管理支援装置100は、例えば、図2に示すようなハードウェア構成の計算機である。業務管理支援装置100は、プロセッサ201、主記憶装置202、副記憶装置203、及びネットワークインタフェース204を有する。なお、業務管理支援装置100は、入力装置及び出力装置を有してもよい。
【0030】
プロセッサ201は、主記憶装置202に格納されるプログラムを実行する。プロセッサ201がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部(モジュール)として動作する。以下の説明では、機能部を主語に処理を説明する場合、プロセッサ201が当該機能部を実現するプログラムを実行していることを示す。
【0031】
主記憶装置202は、メモリ等であり、プロセッサ201が実行するプログラム及びプログラムが使用するデータを格納する。副記憶装置203は、HDD(Hard Disk Drive)及びSSD(Solid State Drive)等であり、データを永続的に格納する。主記憶装置202に格納されるプログラム及びデータは、副記憶装置203に格納されてもよい。この場合、プロセッサ201が副記憶装置203からプログラム及びデータを読み出し、主記憶装置202にロードする。ネットワークインタフェース204は、ネットワークを介して他の装置と通信する。
【0032】
本実施例のプロセッサ201は、業務割当部110、業務推定部111、状態監視部112、及びマニュアル選択部113として動作する。本実施例の主記憶装置202は、業務発行条件情報130、業務マニュアル情報131、所有リソース情報132、組織管理情報133、客体管理情報134、確度算出ロジック情報135、現場状態情報136、割当業務情報137、及び推定業務情報138を格納する。
【0033】
業務発行条件情報130は、業務の実行条件及び業務を特定するための情報を格納する。業務発行条件情報130のデータ構造の詳細は図3を用いて説明する。
【0034】
業務マニュアル情報131は業務マニュアルを格納する。業務マニュアルは、業務を実施する組織及び機能を記述した情報である。後述するように、業務マニュアル情報131には災害の種別ごとの業務マニュアルが格納される。業務マニュアル情報131のデータ構造の詳細は図4を用いて説明する。
【0035】
所有リソース情報132は、組織が保有する、業務に使用するリソースに関する情報を格納する。所有リソース情報132のデータ構造の詳細は図5を用いて説明する。
【0036】
組織管理情報133は、組織のカテゴリに属する組織に関する情報を格納する。組織管理情報133のデータ構造の詳細は図6を用いて説明する。
【0037】
客体管理情報134は、客体のカテゴリに属する客体に関する情報を格納する。客体管理情報134のデータ構造の詳細は図7を用いて説明する。
【0038】
確度算出ロジック情報135は、推定された業務の推定の尤もらしさを表す確度を算出するためのロジックに関する情報を格納する。確度算出ロジック情報135のデータ構造の詳細は図9を用いて説明する。
【0039】
現場状態情報136は、現場状態キュー150を介して受信したメッセージ1000を格納する。現場状態情報136のデータ構造の詳細は図11を用いて説明する。
【0040】
割当業務情報137は、業務管理支援装置100が実施を依頼した業務に関する情報を格納する。割当業務情報137のデータ構造の詳細は図12を用いて説明する。
【0041】
推定業務情報138は、業務管理支援装置100が推定した業務に関する情報を格納する。推定業務情報138のデータ構造の詳細は図13を用いて説明する。
【0042】
業務割当部110は、現場の状態に応じて実施が必要な業務を特定し、業務の実施が可能な組織に業務を割り当てる。なお、本実施例では、業務管理支援装置100は、能動的に業務を割り当てるわけではなく、メッセージキューを介して業務の実施を組織に依頼する。業務の実施は組織の判断に委ねられる。業務割当部110は、割当部120及び割当業務管理部121を含む。割当部120は、業務の特定及び組織への業務の実施を依頼する。割当業務管理部121は、実施を依頼した業務の進捗を監視し、業務が実行されていない場合、再度、業務の実施を依頼する。
【0043】
業務推定部111は、現場において実施された可能性がある業務を推定する。業務推定部111は、推定部122及び推定業務管理部123を含む。推定部122は、現場において実施された可能性がある業務を推定する。推定業務管理部123は、推定業務の実施結果を監視し、推定業務の確度を算出する。
【0044】
状態監視部112は、現場状態キュー150、組織状態キュー151、割当業務キュー152、及び推定業務キュー153に蓄積されるメッセージを監視する。状態監視部112は、組織によって現場状態キュー150に登録されたメッセージ1000を現場状態情報136に登録し、組織によって割当業務キュー152に登録されたメッセージ1020を割当業務情報137に登録し、組織によって推定業務キュー153に登録されたメッセージ1030を推定業務情報138に登録する。状態監視部112は、現場状態情報136に基づいて現場の状態を特定し、現場の状態に応じて業務の割り当て及び推定を行う。また、状態監視部112は、メッセージ入出力部140を介して各キューにメッセージを登録する。
【0045】
マニュアル選択部113は、業務マニュアル情報131に格納される業務マニュアルの中から使用する業務マニュアルを選択する。現場状態キュー150に格納されるメッセージ1000の内容に基づいてマニュアル選択部113が自動的に業務マニュアルを決定してもよいし、業務管理支援装置100を操作するユーザの入力に基づいて決定してもよい。マニュアル選択部113は、現場の状態に応じて使用する業務マニュアルを動的に切り替えてもよい。
【0046】
例えば、「台風接近」を意味するメッセージ1000が格納されている場合、風水害用の業務マニュアルが選択され、「地震発生」を意味するメッセージ1000が格納されている場合、地震災害用の業務マニュアルが選択される。また、現場状態キュー150の更新頻度が少ない場合、マニュアル選択部113は、平常時と判定し、平常時用の業務マニュアルを選択する。
【0047】
なお、業務管理支援装置100が有する各機能部については、複数の機能部を一つの機能部にまとめてもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。
【0048】
なお、複数の計算機を含む計算機システムを用いて、業務管理支援装置100が有する機能部を実現してもよい。この場合、各計算機に機能部を分散して配置してもよい。
【0049】
図3は、実施例1の業務発行条件情報130のデータ構造の一例を示す図である。
【0050】
業務発行条件情報130には、図3に示すようなテーブル300が格納される。テーブル300は、現場状態301及び目的302を含むエントリを格納する。一つの業務の発行条件に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。
【0051】
現場状態301は、業務の実施条件に対応する現場の状態に関する情報を格納するフィールド群であり、客体カテゴリ311及び条件312を含む。客体カテゴリ311は、現場の種別を識別するための客体カテゴリを格納するフィールドである。条件312は、客体カテゴリに属する客体の状態を格納するフィールドである。客体の状態が条件312に格納される条件を満たす場合、業務が実施されることになる。目的302は、現場の状態の改善目的を格納するフィールドである。
【0052】
なお、業務発行条件情報130には、災害の種別ごとにテーブル300が格納されてもよい。なお、業務発行条件情報130に格納される情報はテーブル形式以外のデータ形式でもよい。
【0053】
図4は、実施例1の業務マニュアル情報131のデータ構造の一例を示す図である。
【0054】
業務マニュアル情報131には、災害の種別ごとに、図4に示すようなテーブル400が格納される。テーブル400は、目的401、効果402、業務403、組織カテゴリ404、及び機能405を含むエントリを格納する。一つの目的に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。
【0055】
目的401は、目的302と同一のフィールドである。効果402は、業務の実施による効果に関する情報を格納するフィールド群であり、客体カテゴリ411及び変化412を含む。客体カテゴリ411は客体カテゴリ311と同一のフィールドである。変化412は、業務の実施による客体の変化を格納するフィールドである。
【0056】
業務403は、目的を達成するために実施する業務を格納するフィールドである。一つの目的に対して一つ以上の業務が存在する。一つのエントリには、業務の数だけ、業務403、組織カテゴリ404、及び機能405から構成される行が含まれる。組織カテゴリ404は、業務を実施可能な組織のカテゴリを格納するフィールドである。機能405は、業務の実施に必要な機能を格納するフィールドである。
【0057】
なお、業務マニュアル情報131に格納される情報はテーブル形式以外のデータ形式でもよい。
【0058】
図5は、実施例1の所有リソース情報132のデータ構造の一例を示す図である。
【0059】
所有リソース情報132には、図5に示すようなテーブル500が格納される。テーブル500は、組織501及び機能502を含むエントリを格納する。一つの組織に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。
【0060】
組織501は、組織の識別情報を格納するフィールドである。機能502は、業務の実施に必要な機能ごとのリソースに関する情報を格納するフィールド群である。機能502には、例えば、経路511、輸送512、車両撤去513、判断514、及び報告515等のフィールドが含まれる。各フィールドには、機能を実現するリソースが格納される。経路511には、物資の輸送又は支援部隊の移動に使用され、かつ、組織が管理する道路、河川、及び空港等が格納される。輸送512には、輸送に使用され、かつ、組織が管理する救急車及びヘリコプター等が格納される。
【0061】
なお、所有リソース情報132には、災害の種別ごとにテーブル500が格納されてもよい。なお、所有リソース情報132に格納される情報はテーブル形式以外のデータ形式でもよい。
【0062】
図6は、実施例1の組織管理情報133のデータ構造の一例を示す図である。
【0063】
組織管理情報133には、図6に示すようなテーブル600が格納される。テーブル600には、組織カテゴリ601及び組織602を含むエントリを格納する。一つの組織のカテゴリに対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。
【0064】
組織カテゴリ601は、組織カテゴリ404と同一のフィールドである。組織602は、組織のカテゴリに属する組織を格納するフィールドである。組織602には組織の数だけ行が含まれる。
【0065】
なお、組織のカテゴリに属する組織が一つの場合、組織のカテゴリと組織とは一致するものとする。なお、組織管理情報133に格納される情報はテーブル形式以外のデータ形式でもよい。
【0066】
図7は、実施例1の客体管理情報134のデータ構造の一例を示す図である。
【0067】
客体管理情報134には、図7に示すようなテーブル700が格納される。テーブル700は、客体カテゴリ701及び客体702を含むエントリを格納する。一つの客体のカテゴリに対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。
【0068】
客体カテゴリ701は客体カテゴリ311と同一のフィールドである。客体702は、客体のカテゴリに属する客体を格納するフィールドである。客体702には客体の数だけ行が含まれる。
【0069】
なお、エントリは、道路、避難所、及び港湾等の位置情報(例えば、経度緯度)を格納するフィールドを含んでもよい。なお、客体管理情報134に格納される情報はテーブル形式以外のデータ形式でもよい。
【0070】
図8は、実施例1の業務発行条件情報130、業務マニュアル情報131、所有リソース情報132、組織管理情報133、及び客体管理情報134の対応関係を説明する図である。
【0071】
状態監視部112は、「都道府県道A」の状態が「通行可能」から「通行不可」に変化したことを検知した場合、客体「都道府県道A」に基づいて客体管理情報134を参照し、客体カテゴリ「道路」が「通行不可」の状態になったことを把握できる。さらに、状態監視部112は、業務発行条件情報130を参照して、「道路啓開」を達成するための業務を実施する必要があると判定する。状態監視部112は、図8に示すように、業務発行条件情報130、業務マニュアル情報131、組織管理情報133、及び所有リソース情報132のリンクをたどることによって業務の割当又は業務の推定を行う。
【0072】
状態監視部112は、「都道府県道A」の状態が「通行不可」から「通行可能」に変化したことを検知した場合、客体「都道府県道A」に基づいて客体管理情報134を参照し、客体カテゴリ「道路」が「通行可能」の状態になったことを把握できる。さらに、状態監視部112は、業務マニュアル情報131して、「道路啓開」を達成するための業務が実施されたことを把握できる。
【0073】
図9は、実施例1の確度算出ロジック情報135のデータ構造に一例を示す図である。
【0074】
確度算出ロジック情報135には、図9に示すようなテーブル900が格納される。テーブル900は、確度算出条件901及び確度902を含むエントリを格納する。一つの条件に対して一つのエントリが存在する。なお、エントリに含まれるフィールドは一例であってこれに限定されない。
【0075】
確度算出条件901は、確度の算出条件を格納するフィールドである。確度902は、確度算出条件901に設定された条件を満たす場合の確度を格納するフィールドである。なお、本実施例では、四種類の確度を定義しているが、確度の数は三種類以下でもよいし、また、四種類より多くてもよい。
【0076】
なお、確度算出ロジック情報135に格納される情報はテーブル形式外のデータ形式でもよい。
【0077】
また、確度算出ロジック情報135には、テーブル900以外に、統合確度を算出するための数式の情報が含まれる。数式は、例えば、式(1)のように与えられる。ここで、nは確度i(iは1,2,3,4)の推定業務の数を表し、wは重みを表す。
【0078】
【数1】
【0079】
、w、w、wをすべて1とし、「通知組織」、「時刻」、「客体」が異なるが、「業務カテゴリ」が同一である推定業務が三つあり、そのうち、確度が「1」の推定業務が一つ、確度が「2」の推定業務が二つである場合、総合確度は式(2)に示すように3となる。
【0080】
【数2】
【0081】
の値は、業務管理支援装置100が管理する組織がどれだけ丁寧に業務に対して回答しているかという、協力の度合によって定まる。
【0082】
(設定方法1)確実な報告が期待される場合、wを1、wを2、wを3、wを4と設定する。確度が高い推定業務の重みを大きくすることによって、業務推定部111の推測結果と、業務割当部110が割り当てた業務が一致している業務に関する推定業務を重要視することになる。
【0083】
(設定方法2)組織が協力的でなく、確実な報告を期待できない場合、業務推定部111の推定結果が多少間違ってしまっていても、推定の回数を重ねることによって、推定の精度が高まることが期待される。そのため、w、w、w、wをすべて1に設定し、確度が低い推定業務を確度が高い推定業務と同様に扱いことが最適であると考えられる。
【0084】
A省が業務を実施し、確度が「4」である推定業務が三つである場合、設定方法1の総合確度は式(3)に示すように12となり、設定方法2の総合確度は式(4)に示すように3となる。
【0085】
【数3】
【0086】
【数4】
【0087】
B省が業務を実施し、確度が「1」である推定業務が五つ、確度が「3」である推定業務が二つである場合、設定方法1の総合確度は式(5)に示すように11となり、設定方法2の総合確度は式(6)に示すように7となる。
【0088】
【数5】
【0089】
【数6】
【0090】
したがって、設定方法2の場合、B省が推定業務を実施した可能性が高く、設定方法1の場合、A省が推定業務を実施した可能性が高いことを意味する。
【0091】
図10A図10B図10C、及び図10Dは、実施例1のメッセージングシステム101が蓄積するメッセージのデータ構造の一例を示す図である。
【0092】
メッセージングシステム101に蓄積されるメッセージは、キー及び値のペアを少なくとも一つ含む。
【0093】
図10Aに示すメッセージ1000は、現場状態キュー150に格納されるメッセージであり、キーとして「時刻」、「客体」、及び「状態」を含む。キー「客体」は現場の種別であり、「状態」は現場の状態である。
【0094】
図10Bに示すメッセージ1010は、組織状態キュー151に格納されるメッセージであり、キーとして「時刻」、「組織」、「状態」、及び「通信相手」を含む。キー「組織」は、メッセージを登録した組織であり、キー「状態」は組織の状態であり、キー「通信相手」は組織が通信している相手である。
【0095】
図10Cに示すメッセージ1020は、割当業務キュー152に格納されるメッセージであり、キーとして「時刻」、「目的」、「業務」、「客体」、「依頼組織」、「状態」、及び「更新者」を含む。キー「目的」は現場の状態の改善目的であり、キー「業務」は実施対象の業務であり、キー「依頼組織」は業務の実施を依頼する組織であり、「状態」は業務の実施状態であり、「更新者」はメッセージの登録者である。
【0096】
図10Dに示すメッセージ1030は、推定業務キュー153に格納されるメッセージであり、キーとして「時刻」、「目的」、「業務」、「客体」、「機能」、「実施組織」、「確度」、及び「通知組織」を含む。キー「時刻」は、業務が実施されたと推定される時間帯であり、キー「目的」は現場の状態の改善目的であり、「業務」は推定業務であり、キー「機能」は業務の実施に必要な機能であり、キー「実施組織」は業務を実施したと推定される組織であり、キー「確度」は推定業務の確度であり、「通知組織」は業務の完了を通知した組織である。
【0097】
図11は、実施例1の現場状態情報136のデータ構造の一例を示す図である。
【0098】
現場状態情報136には、図11に示すようなテーブル1100が格納される。テーブル1100は、時刻1101、客体1102、及び状態1103を含むエントリを格納する。一つのメッセージ1000に対して一つのエントリが存在する。
【0099】
時刻1101は、メッセージ1000のキー「時刻」の値を格納するフィールドである。客体1102は、メッセージ1000のキー「客体」の値を格納するフィールドである。状態1103は、メッセージ1000のキー「状態」の値を格納するフィールドである。
【0100】
なお、現場状態情報136に格納される情報はテーブル形式以外のデータ形式でもよい。
【0101】
状態監視部112は、現場状態キュー150に新規メッセージ1000が登録されたことを検知した場合、メッセージ1000を取得する。状態監視部112は、現場状態情報136を参照し、客体1102に取得したメッセージ1000のキー「客体」の値が格納されるエントリを検索する。該当するエントリが存在しない場合、状態監視部112は、現場状態情報136にエントリを追加し、追加されたエントリの各フィールドにメッセージ1000に含まれる各キーの値を設定する。該当するエントリが存在する場合、状態監視部112は、当該エントリの時刻1101及び状態1103に、メッセージ1000に含まれるキー「時刻」及びキー「状態」の値を設定する。これによって、業務管理支援装置100は、各現場の最新の状態を把握することができる。
【0102】
図12は、実施例1の割当業務情報137のデータ構造の一例を示す図である。
【0103】
割当業務情報137には、図12に示すようなテーブル1200が格納される。テーブル1200は、時刻1201、目的1202、業務1203、客体1204、依頼組織1205、状態1206、及び更新者1207を含むエントリを格納する。一つのメッセージ1020に対して一つのエントリが存在する。
【0104】
時刻1201は、メッセージ1020のキー「時刻」の値を格納するフィールドである。目的1202は、メッセージ1020のキー「目的」の値を格納するフィールドである。業務1203は、メッセージ1020のキー「業務」の値を格納するフィールドである。客体1204は、メッセージ1020のキー「客体」の値を格納するフィールドである。依頼組織1205は、メッセージ1020のキー「依頼組織」の値を格納するフィールドである。状態1206は、メッセージ1020のキー「状態」の値を格納するフィールドである。更新者1207は、メッセージ1020のキー「更新者」の値を格納するフィールドである。
【0105】
なお、割当業務情報137に格納される情報はテーブル形式以外のデータ形式でもよい。
【0106】
状態監視部112は、割当業務キュー152に新規メッセージ1020が登録されたことを検知した場合、メッセージ1020を取得する。状態監視部112は、割当業務情報137を参照し、業務1203及び客体1204の値の組合せが、メッセージ1020のキー「業務」及びキー「客体」の値の組合せと一致するエントリを検索する。該当するエントリが存在しない場合、状態監視部112は、割当業務情報127にエントリを追加し、追加されたエントリの各フィールドにメッセージ1020に含まれる各キーの値を設定する。該当するエントリが存在する場合、状態監視部112は、当該エントリの時刻1201、依頼組織1205、状態1206、及び更新者1207に、メッセージ1020に含まれるキー「時刻」、キー「依頼組織」、キー「状態」、及びキー「更新者」の値を設定する。これによって、業務管理支援装置100は、実施を依頼した業務の最新の実施状態を把握することができる。
【0107】
図13は、実施例1の推定業務情報138のデータ構造の一例を示す図である。
【0108】
推定業務情報138は、図13に示すようなテーブル1300を格納する。テーブル1300は、業務1301、客体1302、目的1303、時刻1304、実施組織1305、機能1306、確度1307、及び通知組織1308を含む。
【0109】
業務1301は、メッセージ1030のキー「業務」の値を格納するフィールドである。客体1302は、メッセージ1030のキー「客体」の値を格納するフィールドである。目的1303は、メッセージ1030のキー「目的」の値を格納するフィールドである。時刻1304は、メッセージ1030のキー「時刻」の値を格納するフィールドである。実施組織1305は、メッセージ1030のキー「実施組織」の値を格納するフィールドである。機能1306は、メッセージ1030のキー「機能」の値を格納するフィールドである。確度1307は、メッセージ1030のキー「確度」の値を格納するフィールドである。通知組織1308は、メッセージ1030のキー「通知組織」の値を格納するフィールドである。
【0110】
状態監視部112は、推定業務キュー153に新規のメッセージ1030が登録されたことを検知した場合、メッセージ1030を取得する。状態監視部112は、推定業務情報138を参照し、業務1301及び客体1302の値の組合せが、メッセージ1030のキー「業務」及びキー「客体」の値の組合せと一致するエントリを検索する。該当するエントリが存在しない場合、状態監視部112は、推定業務情報138にエントリを追加し、追加されたエントリの各フィールドにメッセージ1030に含まれる各キーの値を設定する。なお、確度1307には「1」が設定される。該当するエントリが存在する場合、状態監視部112は、当該エントリの時刻1304及び実施組織1305に、メッセージ1030に含まれるキー「時刻」及びキー「実施組織」の値を設定する。これによって、業務管理支援装置100は、推定業務の最新の実施状態を把握することができる。
【0111】
図14は、実施例1の業務管理支援装置100の状態監視部112が実行する現場状態確認処理の一例を説明するフローチャートである。
【0112】
状態監視部112は、業務管理支援装置100の起動後に、メッセージキューの監視を開始する。現場状態キュー150の監視では以下のような処理が周期的に実行される。なお、実行周期は任意に設定できる。例えば、実行周期が1分の場合、状態監視部112は、18:00からカウントを開始した場合、18:01に現場状態キュー150を参照し、18:00から18:01の間に登録されたメッセージ1000の有無を判定する。
【0113】
状態監視部112は、現場状態キュー150に新規メッセージ1000が登録されたか否かを判定する(ステップS101)。
【0114】
新規メッセージ1000が登録されていない場合、状態監視部112は、現場状態キュー150の監視を継続する。
【0115】
新規メッセージ1000が登録されている場合、ステップS102以降の処理が実行される。なお、一つの新規メッセージ1000に対してステップS102以降の処理が実行される。すなわち、新規メッセージ1000が複数存在する場合、各メッセージ1000に対してステップS102以降の処理が実行される。
【0116】
状態監視部112は、現場状態情報136を参照し、客体1102に新規メッセージ1000のキー「客体」の値が格納され、かつ、状態1103に新規メッセージ1000のキー「状態」の値が格納されるエントリを検索し(ステップS102)、当該エントリが存在するか否かを判定する(ステップS103)。エントリが存在する場合、すでに現場の状態に応じた業務が実施されている可能性が高いため業務の推定が行われる。一方、エントリが存在しない場合、現場の状態に応じた業務は実施されていない可能性が高いため業務の実施依頼が行われる。
【0117】
エントリが存在する場合、状態監視部112は、業務マニュアル情報131を参照し、実施可能な業務を検索し(ステップS104)、実施可能な業務が存在するか否かを判定する(ステップS105)。
【0118】
具体的には、状態監視部112は、メッセージ1000のキー「客体」の値に基づいて客体管理情報134を参照し、値を客体カテゴリに変換する。状態監視部112は、客体カテゴリ及びキー「状態」の値と、テーブル400の各エントリの効果402の値とを比較することによって、実施可能な業務が存在するか否かを判定する。なお、状態及び状態変化の関係性を定義した情報が予め存在するものとする。
【0119】
実施可能な業務が存在しない場合、状態監視部112は、現場状態キュー150の監視を継続する。
【0120】
実施可能な業務が存在する場合、状態監視部112は、ステップS104において検索されたエントリに基づいて、推定業務のメッセージ1030を生成し(ステップS106)、業務推定部111を呼び出す(ステップS107)。その後、状態監視部112は、現場状態キュー150の監視を継続する。
【0121】
具体的には、状態監視部112は、ステップS104において検索されたエントリの業務403の値を取得する。状態監視部112は、各値(各業務)についてメッセージ1030を生成する。メッセージ1030のキー「目的」にはエントリの目的401の値が設定され、キー「業務」には業務403の値が設定され、キー「機能」には機能405の値が設定される。メッセージ1030のキー「時刻」、キー「実施組織」、及びキー「確度」は空欄となっている。状態監視部112は、業務推定部111を呼び出し、メッセージ1030を出力する。
【0122】
ステップS103においてエントリが存在しない場合、状態監視部112は、業務発行条件情報130を参照し、実施可能な業務を検索し(ステップS108)、実施可能な業務が存在するか否かを判定する(ステップS109)。
【0123】
具体的には、状態監視部112は、メッセージ1000のキー「客体」の値に基づいて客体管理情報134を参照し、値を客体カテゴリに変換する。状態監視部112は、客体カテゴリ及びキー「状態」の値と、テーブル300の現場状態301の値とを比較することによって、実施可能な業務が存在するか否かを判定する。
【0124】
実施可能な業務が存在しない場合、状態監視部112は、現場状態キュー150の監視を継続する。
【0125】
実施可能な業務が存在する場合、状態監視部112は、ステップS105において検索されたエントリに基づいて、割当業務のメッセージ1020を生成し(ステップS110)、業務割当部110を呼び出す(ステップS111)。その後、状態監視部112は、現場状態キュー150の監視を継続する。
【0126】
具体的には、状態監視部112は、ステップS108において検索されたエントリの目的302の値を取得する。状態監視部112は、業務マニュアル情報131を参照し、目的401に取得した値が格納されるエントリを検索する。状態監視部112は、検索されたエントリの業務403の値を取得する。状態監視部112は、各値(各業務)についてメッセージ1020を生成する。メッセージ1020のキー「目的」にはエントリの目的401の値が設定され、キー「業務」には業務403の値が設定され、キー「客体」にはメッセージ1000のキー「客体」の値が設定され、キー「依頼組織」にはメッセージ1000のキー「通知組織」の値が設定される。メッセージ1020のキー「状態」及びキー「更新者」は空欄となっている。状態監視部112は、業務割当部110を呼び出し、メッセージ1020を出力する。
【0127】
次に、図15A図15B、及び図16を用いて業務割当部110が実行する処理について説明する。
【0128】
図15A及び図15Bは、実施例1の割当部120が実行する処理の一例を説明するフローチャートである。
【0129】
割当部120は、状態監視部112から呼び出された場合、以下で説明する処理を実行する。
【0130】
割当部120は、状態監視部112が出力したメッセージ1020を取得する(ステップS201)。割当部120は、メッセージ1020のキー「依頼組織」に対応する組織をターゲット組織に設定する。
【0131】
割当部120は、ターゲット組織の状態を確認し(ステップS202)、ターゲット組織がメッセージ1020に対応する業務を実施できるか否かを判定する(ステップS203)。
【0132】
具体的には、割当部120は、組織状態キュー151を参照し、キー「組織」にターゲット組織の値が格納され、かつ、キー「時刻」の値が現在から一定時間前の時間範囲に含まれるメッセージ1010を検索する。なお、検索する時間の範囲は、1分、30分、又は1時間等、任意に設定できる。メッセージ1010が存在しない場合、割当部120は、ターゲット組織が業務を実施できると判定する。検索されたメッセージ1010のキー「状態」の値が「通信遮断」又は「応答なし」等である場合、割当部120は、ターゲット組織が業務を実施できないと判定する。
【0133】
ターゲット組織がメッセージ1020に対応する業務を実施できる場合、割当部120は、メッセージ1020のキー「依頼組織」にターゲット組織を設定し(ステップS211)、当該メッセージ1020に対応するエントリを割当業務情報137に追加する(ステップS213)。その後、割当部120は処理を終了する。
【0134】
ターゲット組織がメッセージ1020に対応する業務を実施できない場合、割当部120は、推定業務情報138を参照し、メッセージ1020に対応する業務と同一内容の推定業務を検索し(ステップS204)、メッセージ1020に対応する業務と同一内容の推定業務が存在するか否かを判定する(ステップS205)。
【0135】
具体的には、割当部120は、業務1301及び目的1303の値の組合せが、メッセージ1020のキー「業務」及びキー「目的」の値の組合せに一致し、かつ、メッセージ1020のキー「時刻」の値が、時刻1304に対応する時間範囲に含まれるエントリを検索する。
【0136】
メッセージ1020に対応する業務と同一内容の推定業務が存在しない場合、割当部120は、メッセージ1020のキー「依頼組織」に「全組織」を設定し(ステップS212)、当該メッセージ1020に対応するエントリを割当業務情報137に追加する(ステップS213)。その後、割当部120は処理を終了する。
【0137】
メッセージ1020に対応する業務と同一内容の推定業務が存在する場合、割当部120は、検索されたエントリに基づいて組織のリストを生成し(ステップS206)、リストの中から一つの組織を選択し、当該組織をターゲット組織に設定する(ステップS207)。
【0138】
組織の選択方法としては以下のような方法が考えられる。
(選択方法1)ランダム
(選択方法2)総合確度の大きい順
【0139】
割当部120は、ターゲット組織の状態を確認し(ステップS208)、ターゲット組織がメッセージ1020に対応する業務を実施できるか否かを判定する(ステップS209)。ステップS208及びステップS209の処理は、ステップS202及びステップS203の処理と同一である。
【0140】
ターゲット組織がメッセージ1020に対応する業務を実施できる場合、割当部120は、メッセージ1020のキー「依頼組織」にターゲット組織を設定し(ステップS211)、当該メッセージ1020に対応するエントリを割当業務情報137に追加する(ステップS213)。その後、割当部120は処理を終了する。
【0141】
ターゲット組織がメッセージ1020に対応する業務を実施できない場合、割当部120は、リストに未処理の組織が存在するか否かを判定する(ステップS210)。
【0142】
リストに未処理の組織が存在する場合、割当部120はステップS207に戻り、同様の処理を実行する。
【0143】
リストに未処理の組織が存在しない場合、割当部120は、メッセージ1020のキー「依頼組織」に「全組織」を設定し(ステップS212)、当該メッセージ1020に対応するエントリを割当業務情報137に追加する(ステップS213)。その後、割当部120は処理を終了する。
【0144】
図16は、実施例1の割当業務管理部121が実行する処理の一例を説明するフローチャートである。
【0145】
割当業務管理部121は、業務管理支援装置100の起動後、割当業務情報137の監視を開始する。割当業務情報137の監視では以下のような処理が周期的に実行される。なお、参照する周期は任意に設定できる。例えば、周期は10分である。
【0146】
割当業務管理部121は、割当業務情報137を参照し、実行されていない業務が存在するか否かを判定する(ステップS301)。
【0147】
具体的には、割当業務管理部121は、状態1206が「未」の状態が時刻1201の値から一定時間継続している業務が存在するか否かを判定する。一定時間は、12時間等、任意に設定できる。
【0148】
実行されていない業務が存在しない場合、割当業務管理部121は割当業務情報137の監視を継続する。
【0149】
実行されていない業務が存在する場合、割当業務管理部121は、割当部120を呼び出し、当該業務に対応するエントリの情報を通知する(ステップS302)。その後、割当業務管理部121は割当業務情報137の監視を継続する。これによって、実施されていない業務の再依頼が行われる。
【0150】
次に、図17及び図18を用いて業務推定部111が実行する処理について説明する。
【0151】
図17は、実施例1の推定部122が実行する処理の一例を説明するフローチャートである。
【0152】
推定部122は、状態監視部112から呼び出された場合、以下で説明する処理を実行する。
【0153】
推定部122は、状態監視部112が出力したメッセージ1030を取得する(ステップS401)。推定部122は、メッセージ1030のキー「実施組織」に対応する組織をターゲット組織に設定する。
【0154】
推定部122は、ターゲット組織の状態を確認し(ステップS402)、ターゲット組織がメッセージ1030に対応する業務を実施できるか否かを判定する(ステップS403)。
【0155】
ステップS402の処理はステップS202の処理と同一である。ステップS403の処理はステップS203の処理と同一でもよいし、以下のような処理でもよい。推定部122は、推定業務情報138を参照し、機能1306にメッセージ1030のキー「機能」の値が設定されているエントリが存在するか否かを判定する。エントリが存在しない場合、推定部122は、ターゲット組織が業務を実施できると判定する。
【0156】
ターゲット組織がメッセージ1030に対応する業務を実施できる場合、推定部122は、メッセージ1030のキー「実施組織」にターゲット組織を設定し(ステップS409)、当該メッセージ1030に対応するエントリを推定業務情報138に追加する(ステップS411)。その後、推定部122は処理を終了する。
【0157】
ターゲット組織がメッセージ1030に対応する業務を実施できない場合、推定部122は、所有リソース情報132を参照し、当該業務の実施に必要な機能を有する組織を抽出し、組織のリストを生成する(ステップS404)。
【0158】
具体的には、推定部122は、テーブル500の各エントリの機能502と、メッセージ1030のキー「機能」とを比較することによって、業務の実施に必要な機能を有する組織を抽出する。
【0159】
推定部122は、組織のリストの中から一つの組織を選択し、当該組織をターゲット組織に設定する(ステップS405)。
【0160】
推定部122は、ターゲット組織の状態を確認し(ステップS406)、ターゲット組織がメッセージ1020に対応する業務を実施できるか否かを判定する(ステップS407)。ステップS406及びステップS407の処理は、ステップS402及びステップS403の処理と同一である。
【0161】
ターゲット組織がメッセージ1030に対応する業務を実施できる場合、推定部122は、メッセージ1030のキー「実施組織」にターゲット組織を設定し(ステップS409)、当該メッセージ1030に対応するエントリを推定業務情報138に追加する(ステップS411)。その後、推定部122は処理を終了する。
【0162】
ターゲット組織がメッセージ1030に対応する業務を実施できない場合、推定部122は、リストに未処理の組織が存在するか否かを判定する(ステップS408)。
【0163】
リストに未処理の組織が存在する場合、推定部122はステップS405に戻り、同様の処理を実行する。
【0164】
リストに未処理の組織が存在しない場合、推定部122は、メッセージ1030のキー「実施組織」を空欄に設定し(ステップS410)、当該メッセージ1030に対応するエントリを推定業務情報138に追加する(ステップS411)。その後、推定部122は処理を終了する。
【0165】
図18は、実施例1の推定業務管理部123が実行する処理の一例を説明するフローチャートである。
【0166】
推定業務管理部123は、業務管理支援装置100の起動後、推定業務情報138の監視を開始する。推定業務情報138の監視では以下のような処理が周期的に実行される。なお、参照する周期は任意に設定できる。例えば、周期は10分である。
【0167】
推定業務管理部123は、推定業務情報138を参照し、更新されたエントリが存在するか否かを判定する(ステップS501)。なお、推定業務管理部123による更新は対象としない。
【0168】
更新されたエントリが存在しない場合、推定業務管理部123は推定業務情報138の監視を継続する。
【0169】
更新されたエントリが存在する場合、推定業務管理部123は、割当業務情報137を参照し、更新されたエントリに対応する割当業務のエントリを検索し(ステップS502)、推定業務に対応する割当業務が存在するか否かを判定する(ステップS503)。
【0170】
具体的には、推定業務管理部123は、業務1203の値が更新されたエントリの業務1301の値に一致し、依頼組織1205の値が更新されたエントリの実施組織1305の値に一致し、かつ、時刻1201に格納される時刻が更新されたエントリの時刻1304に格納される時間範囲に含まれるエントリを検索する。
【0171】
推定業務に対応する割当業務が存在しない場合、推定業務管理部123は推定業務情報138の監視を継続する。
【0172】
推定業務に対応する割当業務が存在する場合、推定業務管理部123は、確度算出ロジック情報135に基づいて、更新されたエントリの確度1307を更新する(ステップS504)。
【0173】
図19は、実施例1の業務管理支援装置100の内部の処理のイメージを示す図である。
【0174】
状態監視部112は、現場状態キュー150からメッセージ1000を取得し、メッセージ1000のキー「客体」に基づいて業務発行条件情報130を参照し、現場状態に合致するエントリを検索する。該当するエントリが存在する場合、状態監視部112は、当該エントリに基づいて割当業務のメッセージ1020を生成し、割当部120に出力する。該当するエントリが存在しない場合、状態監視部112は、現場状態情報136から、客体1102の値がメッセージ1000のキー「客体」の値と一致するエントリを取得する。状態監視部112は、取得したエントリの客体1102及び状態1103の値の組合せに基づいて、業務マニュアル情報131を参照し、実施可能な業務のエントリを取得する。状態監視部112は、取得したエントリに基づいてメッセージ1030を生成し、推定部122に出力する。
【0175】
割当部120は、状態監視部112からメッセージ1020を取得した場合、組織状態キュー151に基づいて、組織が業務を実施できるか確認する。組織が業務を実施できる場合、割当部120は、割当業務情報137に当該メッセージ1020に対応するエントリを追加する。組織が業務を実施できない場合、割当部120は、推定業務情報138を参照し、同一内容の推定業務を検索する。さらに、割当部120は、組織状態キュー151及び確度算出ロジック情報135に基づいて推定業務を組織が実施できるか否かを判定し、推定業務を組織が実施できる場合には、メッセージ1020のキー「依頼組織」の値を書き換え、割当業務情報137に当該メッセージ1020に対応するエントリを追加する。
【0176】
割当業務管理部121は、割当業務情報137を監視し、一定期間実施されていない業務が存在する場合、当該業務に対応するエントリを割当部120に出力する。割当部120は、図15A及び図15Bに示す処理を実行し、メッセージ1020のキー「依頼組織」を更新し、割当業務情報137に当該メッセージ1020に対応するエントリを追加する。
【0177】
推定部122は、状態監視部112からメッセージ1030を取得した場合、組織状態キュー151に基づいて組織が業務を実施できるか確認する。組織が業務を実施できる場合、推定部122は、推定業務情報138に当該メッセージ1030に対応するエントリを追加する。組織が業務を実施できない場合、推定部122は、所有リソース情報132に基づいて、業務を実施するために必要な機能を有する組織を特定し、組織状態キュー151に基づいて当該組織が業務を実施できるか確認する。組織が業務を実施できる場合、推定部122は、メッセージ1030のキー「実施組織」の値を書き換え、推定業務情報138に当該メッセージ1030に対応するエントリを追加する。
【0178】
推定業務管理部123は、推定業務情報138を監視し、更新されたエントリが存在する場合、割当業務情報137を参照し、当該エントリ(推定業務)に対応する割当業務を検索する。エントリに対応する割当業務が存在する場合、推定業務管理部123は、確度算出ロジック情報135に基づいて確度を算出し、エントリの確度1307の値を書き換える。
【0179】
図20は、実施例1の業務管理支援装置100及びメッセージングシステム101の間のメッセージの流れを示す図である。図21は、実施例1の端末102に提示される画面の一例を説明する図である。
【0180】
まず、端末102に提示される画面について説明する。端末102には、メッセージングシステム101によって図21に示すような画面2100が提示される。
【0181】
画面2100は、表示欄2101、2102、2103、2104、2105と、操作欄2106とを含む。
【0182】
表示欄2101は、端末102に対応する組織に実施が依頼されている業務(割当業務)を表示する欄である。表示欄2102は、端末102に対応する組織とは異なる組織に実施が依頼されている業務(割当業務)を表示する欄である。表示欄2103は、端末102に対応する組織が実施したと推定される業務(推定業務)を表示する欄である。表示欄2104は、端末102に対応する組織とは異なる組織が実施したと推定される業務(推定業務)を表示する欄である。表示欄2105は、割当業務又は推定業務の詳細を表示する欄である。操作欄2106は、各種操作を選択するための欄である。
【0183】
端末102を操作するユーザは、表示欄2101、2102、2103、2104を閲覧することによって、自組織及び他組織の割当業務及び推定業務を確認できる。割当業務の詳細を確認する場合、ユーザは、表示欄2101又は表示欄2102に表示される業務を選択する。これによって、表示欄2105に選択された割当業務の詳細が表示される。推定業務の詳細を確認する場合、ユーザは、表示欄2103又は表示欄2104に表示される業務を選択する。これによって、表示欄2104に選択された推定業務の詳細が表示される。
【0184】
ユーザは、割当業務又は推定業務に関する編集を行う場合、操作欄2106の「編集」を選択する。割当業務を編集する場合、表示欄2104の表示が、依頼組織、状態、及び更新者等が編集可能な状態に遷移する。推定業務を編集する場合、表示欄2104の表示が、時刻、実施組織、及び確度等が編集可能な状態に遷移する。ユーザは、値を編集し、操作欄2106の送信ボタンを押下する。これによって、メッセージが更新される。
【0185】
ユーザは、割当業務に関するメッセージを生成する場合、操作欄2106の「業務生成」を選択し、推定業務に関するメッセージを生成する場合、操作欄2106の「推定業務生成」を選択する。表示欄2104には、割当業務又は推定業務のメッセージを生成するためのテンプレートが表示される。ユーザは、テンプレートに値を入力し、操作欄2106の送信ボタンを押下する。これによって、メッセージキューにメッセージが登録される。
【0186】
状態監視部112は、組織によって現場状態キュー150にメッセージ1000が登録された場合、メッセージ入出力部140を介して、メッセージ1000を取得し、現場状態情報136にメッセージ1000に対応するエントリを登録する。
【0187】
状態監視部112は、割当業務情報137にエントリが登録された場合、当該エントリからメッセージ1020を生成し、メッセージ入出力部140に送信する。メッセージ入出力部140は、メッセージ1020を割当業務キュー152に登録する。
【0188】
任意の組織が、画面2100を介してメッセージ1020のキー「状態」を「未」から「済」に更新した場合、状態監視部112は、メッセージ入出力部140を介して、更新されたメッセージ1020を取得し、割当業務情報137に当該メッセージに対応するエントリを登録する。
【0189】
状態監視部112は、推定業務情報138にエントリが登録された場合、当該エントリからメッセージ1030を生成し、メッセージ入出力部140に送信する。メッセージ入出力部140は、メッセージ1030を推定業務キュー153に登録する。
【0190】
任意の組織が、画面2100を介してメッセージ1030のキー「状態」、キー「実施組織」、及びキー「確度」等を更新した場合、状態監視部112は、メッセージ入出力部140を介して、更新されたメッセージ1030を取得し、推定業務情報138に当該メッセージに対応するエントリを登録する。
【0191】
以上で説明したように、実施例1によれば、業務管理支援装置100は、現場から断片的に取得できる情報に基づいて現場の状態及び実行されている可能性がある業務を把握し、組織に割り当てる業務を計画し、依頼することができる。これによって、災害時の組織間の業務の円滑な連携が可能となり、災害時の活動の迅速化及び効率化を実現できる。
【実施例2】
【0192】
次に、実施例2について説明する。実施例2では、推定部122が実行する処理が一部異なる。以下、実施例1との差異を中心に実施例2について説明する。
【0193】
実施例2のシステム構成、ハードウェア構成、及びソフトウェア構成は実施例1と同一である。実施例2では、推定部122が実行する処理が一部異なる。具体的には、ステップS403の判定方法が異なる。
【0194】
(判定方法1)推定部122は、各組織の現場状態キュー150に登録すべき情報の登録状態に基づいて、組織が業務を実施できるか否かを判定する。例えば、平常時には医療施設の情報を1時間間隔で現場状態キュー150に登録していた組織が、任意の時間帯に医療施設の情報を登録していない場合、推定部122は、その時間帯において組織に何らかのトラブルが発生しており、業務を実施できないと判定する。
【0195】
(判定方法2)推定部122は、組織の連絡相手に基づいて、組織が業務を実施できるか否かを判定する。例えば、「啓開箇所決定」の業務をA省が実施した旨のメッセージが割当業務キュー152に登録され、業務が実施されていた時間帯にA省及びB省との間で密に連絡が行われていた場合、推定部122は、「車両撤去」の業務はB省によって実行された可能性が高いと判定する。
【0196】
このように、処理に使用する情報を組み合わせることによって推定の精度を向上させることができる。
【0197】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
【0198】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、CD-ROM、DVD-ROM、ハードディスク、SSD(Solid State Drive)、光ディスク、光磁気ディスク、CD-R、磁気テープ、不揮発性のメモリカード、ROMなどが用いられる。
【0199】
また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、C/C++、perl、Shell、PHP、Python、Java(登録商標)等の広範囲のプログラム又はスクリプト言語で実装できる。
【0200】
さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はCD-RW、CD-R等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
【0201】
上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
【符号の説明】
【0202】
100 業務管理支援装置
101 メッセージングシステム
102 端末
105 ネットワーク
110 業務割当部
111 業務推定部
112 状態監視部
113 マニュアル選択部
120 割当部
121 割当業務管理部
122 推定部
123 推定業務管理部
127 割当業務情報
130 業務発行条件情報
131 業務マニュアル情報
132 所有リソース情報
133 組織管理情報
134 客体管理情報
135 確度算出ロジック情報
136 現場状態情報
137 割当業務情報
138 推定業務情報
140 メッセージ入出力部
150 現場状態キュー
151 組織状態キュー
152 割当業務キュー
153 推定業務キュー
201 プロセッサ
202 主記憶装置
203 副記憶装置
204 ネットワークインタフェース
【要約】
【課題】災害時の組織間の業務の連携を支援する。
【解決手段】計算機システムは、災害に対する業務を実行する複数の組織が管理する端末と接続し、端末は、災害の現場に関する現場情報及び実施した業務の少なくともいずれかに関する活動情報を送信する。計算機システムは、現場情報に基づいて現場の状態を特定し、現場の状態に基づいて実施が必要な割当業務を特定し、活動情報に基づいて組織の活動状態を把握し、組織の活動状態に基づいて、割当業務を実行可能な組織を決定し、決定された組織割当業務の実施依頼を送信する。
【選択図】 図1
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10A
図10B
図10C
図10D
図11
図12
図13
図14
図15A
図15B
図16
図17
図18
図19
図20
図21