JP6487408B2 - 情報管理装置、情報管理方法および情報管理プログラム - Google Patents

Description

本発明は、情報管理装置、情報管理方法および情報管理プログラムに関する。

多くの人と情報をやり取りする手段として、電子メール（以降、メールとする。）、メーリングリスト、ＳＮＳ及び掲示板などがある。メールは、１対１もしくは、１対多の相手と情報をやり取りする。メーリングリストは、多対多の相手と情報をやり取りする。一方、ＳＮＳは、会員といった特定の人の中で情報のやり取りを行う。そして、掲示板は、不特定多数あるいは特定の人との情報のやり取りのために使用される。人々は、様々な環境で、情報をやり取りするツールを使うことができ、利便性を求めて、メーリングリストを掲示板で表示する、或いは、掲示板に投稿された記事をメールで通知することができるツールも提供されている（例えば、非特許文献１参照）。

これらの機能は、プログラムの開発においても、問題を対処する人宛にメールで通知し、結果をメールで受信したものが掲示板で一覧できるツールとして使われている。具体的に、このツールは、やらなければいけないタスクをチケットとして登録し、そこに担当者を割り当て、進捗に応じてチケットを更新するものである。このツールでは、メールを用いてチケットの追加や更新を行なうことができる（例えば、非特許文献２参照）。

一方、ツールごとに操作方法が異なるため、利用者は、各々の使い方を習得しなくてはならず、コミュニティの参加を躊躇する場合もある。このため、利用者の利便性を向上する方法として、統一的に操作が可能なコミュニティ管理方法およびコミュニケーション運営システムが提案されている（例えば、特許文献１参照）。

このコミュニティ管理方法では、コミュニケーション手段等を、Ｗｉｎｄｏｗｓ（登録商標）のデスクトップに表示されるようなファイルアイコン等の各種アイコンに対応付けて表示し、このアイコンに対する操作に基づいてコミュニケーションを実施する。この方法では、コミュニティにおいて情報交換や共同作業を実施する際に、複数のコミュニケーション手段に対する操作を、パーソナルコンピュータや情報端末のファイル操作と同様な統一的な操作方法で実施できる。すなわち、この方法では、コミュニケーション手段独自のアドレス等の識別情報や操作方法を意識的に使い分けずともよい。

また、従来、自治体や企業等において災害やサイバー攻撃等の危機に対応するための危機管理対策本部では、ホワイトボードを使って情報を追記する場合や、電話やＦＡＸで外部の情報をやり取りする場合がある。このように、危機管理対策本部では、様々な媒体からの情報を使って、問題解決にあたっている（例えば、非特許文献３参照）。

例えば、気象等の状況により洪水のおそれがある場合を例に説明する。この場合、水防法にしたがって、気象庁長官は、国土交通大臣および関係都道府県知事に通知する（詳細は、非特許文献４参照）。都道府県知事は、直ちに水防管理者である市町村長に通知する。例えば、市長が、複数の町村にまたがる川の洪水のおそれがあるという通知を受けたときには、該当する町村に情報を流し、各々の自治体でどのような対策を取ったか報告を受けることになる。該当する町村では、これらの報告や対策等を、ホワイトボード、電話、ＦＡＸ等の様々な媒体を用いてやり取りする。

特開２００４−２４０７２６号公報

ＭＬ掲示板の使用方法、［online］、［平成２８年１０月１７日検索］、インターネット＜ＵＲＬ：http://www.psn.or.jp/support/ml/mlbbs.html＞ プロジェクト管理ツールRedmine、［online］、［平成２８年１０月１７日検索］、インターネット＜ＵＲＬ：http://redmine.jp/＞ DRI調査レポート No.45 2016 平成28年(2016年)熊本地震現地調査報告（第1報）のp.2 写真2 オペレーションルーム入口、［online］、［平成２８年１０月１７日検索］、インターネット＜ＵＲＬ：http://www.dri.ne.jp/wordpress/wp-content/uploads/DRIReport45.pdf＞ 洪水予報河川とは（水防法）、［online］、［平成２８年１０月１７日検索］、インターネット＜ＵＲＬ：http://www.mlit.go.jp/river/bousai/main/saigai/tisiki/syozaiti/pdf/yohousyuutikasen.pdf＞

危機対応の現場においては、ブラウザ経由で閲覧する掲示板、メール、ホワイトボードなど様々なツールを連携して危機対応時の情報を一元管理し、各々が情報を共有しながら、対処にあたる必要がある。しかしながら、従来では、使用する各々のツールの特徴により、危機対応情報の一元管理化及び情報の共有化が容易ではなかった。

すなわち、災害やサイバー攻撃などの危機が発生した場合、通常使用している環境が使用できるとは限らない。また、災害現場に出向いて状況を確認するような場合では、被害状況等をできる限り迅速に伝える必要がある。これらを考慮すると、非特許文献１を危機管理マネジメントシステムに適用した場合、この危機管理マネジメントシステムにログインし、状況を報告する画面に到達するまでに多くの操作をしなければならず、効率的とは言えないという問題がある。さらに、メール環境しか使えない人は、そもそも危機管理マネジメントシステムにログインできないため、報告する時点でタスクの進捗状態を把握することが不可能であり、被害状況の迅速な報告が難しいという問題がある。

また、通常の掲示板機能では、スレッドが終了する、という概念がない。一方、危機管理マネジメントシステムでは、１つのタスクが完了し、その結果、新たなタスクが発生して危機対応を行う流れであるため、明確にタスクが完了したことをユーザに示す必要がある。ここで、危機管理マネジメントシステムにブラウザでアクセスしている人は、閲覧すれば一目でタスク状態を把握できる。しかしながら、メール環境しか使えない人は、メール本文にタスクの状態を書いたメールをシステム管理者等に送信してもらうという煩雑な処理が必要であり、即座に把握することが困難であるという問題があった。

そして、非特許文献２記載のプロジェクト管理ツール（Redmine）を危機対応マネジメントシステムに適用した場合、１件のタスクに対して１件のチケットを発行する仕組みを取ることとなる。通常は、危機対応のために複数の組織が関わるため、Redmineを適用した危機対応マネジメントシステムでは、１件のタスクに対して、複数箇所に業務（Redmineにおけるチケット）を依頼することになる。

ここで、気象等の状況により洪水のおそれがある場合には、前述したように、水防法にしたがって、気象庁長官は、国土交通大臣および関係都道府県知事に通知し、都道府県知事は、直ちに市町村長である水防管理者に通知する。例えば、市長が複数の町村にまたがる川の洪水のおそれがあるという通知を受けたときには、該当する町村に情報を流し、各々の自治体でどのような対策を取ったか報告を受けることになる。このとき、タスクは「○○川洪水に対する対応」であり、依頼先は複数の町村となる。これをRedmineで実現しようとすると、町村ごとにタスクを立てる必要があり、一覧で状況を把握しづらくなるという欠点を持つ。

また、特許文献１に記載の方法では、メールと危機管理マネジメントシステムを同じ操作で扱えることが可能になるため、操作性が向上するという利点がある。ただし、特許文献１に記載の方法は、あくまでも操作性に限定されるものであり、上述のタスクの状態管理や進捗状況を把握することは考慮されていない。

さらに、危機管理統合センタ等において、ホワイトボード等を使って情報共有される状況では、記述内容は、その場にいないと読むことができない。また、状況の変化によって記述内容が更新されるため、その場にいてもタイミングが合わないと、記述内容を読むことができない。例えば、ある事象の対応策が○時○分に書かれていたことを思い出した人が、それより後に見に行ったとしても、状況によっては、削除されて違う内容に更新されている場合もあるため、情報共有ができないことも考えられる。

このように、従来では、ブラウザ経由で閲覧する掲示板、メール、ホワイトボードなどの各使用ツールの特徴により、危機対応情報の一元管理化及び情報の共有化が容易ではなかった。

本発明は、上記に鑑みてなされたものであって、どのツールを使用しても危機対応情報の一元管理及び情報の共有が可能である情報管理装置、情報管理方法および情報管理プログラムを提供することを目的とする。

本発明の情報管理装置は、危機対応に関する危機対応情報として、危機への対応業務を示す識別情報と、対応業務に含まれる各対応指示及び各対応内容とを対応付けて記憶する記憶部と、対応指示を含むメールの送信指示を受けた場合に送信対象の端末に対応状況及び対応指示を含むメールを送信するとともに該送信した対応指示を、該対応指示が対応する対応業務の識別情報に対応付けた状態で危機対応情報に登録し、端末から該端末のユーザの対応内容を含む返信メールを受信した場合に、対応内容を、該対応内容が対応する対応業務の識別情報に対応付けた状態で危機対応情報に登録するメール処理部と、を有することを特徴とする。

本発明によれば、どのツールを使用しても危機対応情報の一元管理及び情報の共有が可能である。

図１は、危機管理マネジメントシステムの概要を説明するための図である。 図２は、図１に示す危機管理マネジメントシステムサーバの構成を示すブロック図である。 図３は、組織管理テーブルのデータ構成の一例を示す図である。 図４は、ユーザアカウント管理テーブルのデータ構成の一例を示す図である。 図５は、ユーザ所属組織管理テーブルのデータ構成の一例を示す図である。 図６は、ボード管理テーブルのデータ構成の一例を示す図である。 図７は、タスク管理テーブルのデータ構成の一例を示す図である。 図８は、タスクログ管理テーブルのデータ構成の一例を示す図である。 図９は、風水害におけるプロセスを示す画面表示例を示す図である。 図１０は、フェーズ、「Ｔ１:平時、Ｔ０:解除」プロセスにおけるチェックリストの画面表示例を示す図である。 図１１は、風水害におけるフェーズの画面表示例を示す図である。 図１２は、風水害時における情報のやり取りの画面表示例を示す図である。 図１３は、風水害時における避難所状況確認結果の画面表示例である。 図１４は、風水害における送信メールの文面例を示す図である。 図１５は、図１４に示すメールに対する返信メールの文面例を示す図である。 図１６は、ユーザからのメールの文面例の他の例を示す図である。 図１７は、ユーザからのメールの文面例の他の例を示す図である。 図１８は、風水害における登録指示依頼の画面例を示す図である。 図１９は、風水害における登録指示依頼の画面例の他の例を示す図である。 図２０は、図２に示すメール処理部によるメール送信処理の処理手順を示すフローチャートである。 図２１は、図２に示すメール処理部による、利用者端末による返信メールに対する処理の処理手順を示すフローチャートである。 図２２は、図２に示すメール処理部のタスク完了時における処理手順を示すフローチャートである。 図２３は、プログラムが実行されることにより危機管理マネジメントシステムサーバが実現されるコンピュータの一例を示す図である。

以下に、本願に係る情報管理装置、情報管理方法および情報管理プログラムの実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本発明が限定されるものではない。

［危機管理マネジメントシステムの概要］
本発明の情報管理装置は、危機管理マネジメントシステムに含まれる装置、または危機管理マネジメントシステムの１つの機能として実現されてもよい。ここで、危機管理マネジメントシステムとは、自治体や企業の危機管理室が災害やサイバー攻撃といった危機に対応するためのマネジメントを支援するシステムのことである。そして、ある危機管理に対して、様々な危機管理対応業務を束ねたものをボードと定義する。ボード内には、危機管理を遂行する上で必要となる各種情報がまとめられ、危機管理マネジメントシステムでは、これらの情報を、Ｐｌａｎ，Ｄｏ，Ｓｅｅの３つの観点で総覧することによって、ユーザによる意思決定や組織間連携を支援する。

図１は、危機管理マネジメントシステムの概要を説明するための図である。図１に示すように、危機管理マネジメントシステム１００は、ネットワークＮを介して、複数の利用者端末１、危機管理マネジメントシステムサーバ２（情報管理装置）及びメールサーバ３が接続する構成を有する。なお、ネットワークＮは、接続される各装置が相互に通信可能に構成されていればよく、例えばインターネットやＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等で構成することができる。

また、利用者端末１は、例えばパーソナルコンピュータ、スマートフォン、携帯電話等である。ユーザは、各利用者端末１のＷｅｂブラウザを介して、危機管理マネジメントシステムサーバ２から提供される危機対応情報の参照や、危機管理マネジメントシステムサーバ２への情報の送信等を行うことができる。また、ユーザは、各利用者端末のメール環境を介して、危機管理マネジメントシステムサーバ２から提供される危機対応情報の参照や、危機管理マネジメントシステムサーバ２への情報の送信等を行うことができる。

危機管理マネジメントシステムサーバ２は、危機に対する組織の対応状態を示す危機対応情報を管理する。危機管理マネジメントシステムサーバ２は、危機管理対策本部および担当部局に備えられた利用者端末１に、Ｐｌａｎ画面、Ｄｏ画面およびＳｅｅ画面を表示させることによって、危機対応情報を各利用者端末１に提供する。ここで、Ｐｌａｎ画面は、対策本部運営のプロセスおよび各フェーズにおける実施項目を提示する画面である。Ｄｏ画面は、非定型業務についての重要度や進捗状況等の情報を管理する画面である。また、Ｓｅｅ画面は、対応や被害の状況を地図や表で俯瞰的に表示する画面である。危機管理マネジメントシステムサーバ２は、利用者端末１から送信された情報を、危機対応情報に登録する。

メールサーバ３は、ネットワークＮ内の利用者端末１及び危機管理マネジメントシステムサーバ２におけるメールの送信や受信を行う。

本実施の形態では、利用者端末１が、システムにアクセスするためのブラウザが使えない環境であっても、メールを用いることによって、タスク（対応業務）、会議時間、チェックリスト、ある時間におけるホワイトボードなどの危機対応情報の共有を可能とする。

また、本実施の形態では、危機管理マネジメントシステムサーバ２からタスクの状態を利用者端末１にメールで送ることによって、どのツールを使っていてもユーザが状況を把握することが可能になる。また、各ツールを用いて収集された情報は、危機管理マネジメントシステムサーバ２において一元管理されるため、危機管理室では状況を容易に把握でき、的確な指示を出すことが可能となる。そこで、危機管理マネジメントシステムサーバ２の構成について説明する。ここでは、特にＤｏ画面におけるタスクのメール連携機能について説明する。

［危機管理マネジメントシステムサーバの構成］
図２は、図１に示す危機管理マネジメントシステムサーバ２の構成を示すブロック図である。図１に示すように、危機管理マネジメントシステムサーバ２は、データ通信が可能なネットワークＮによって利用者端末１及びメールサーバ３に接続されている。図２に示すように、危機管理マネジメントシステムサーバ２は、データ格納部２１（記憶部）とデータ処理部２２とを有する。

データ格納部２１は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置によって実現され、危機管理マネジメントシステムサーバ２を動作させる処理プログラムや、処理プログラムの実行中に使用されるデータなどが記憶される。ここで、本システムの運用のために運用管理者が任命されると、この運用管理者は、ユーザ情報など危機対応に必要な情報を登録する。データ格納部２１は、これらの情報を格納する。言い換えると、データ格納部２１は、危機対応に関する危機対応情報として、危機への対応業務を示す識別情報と、対応業務に含まれる各対応指示及び各対応内容とを対応付けて記憶する。データ格納部２１は、組織情報格納部２１１、ユーザ情報格納部２１２、アクセス制御情報格納部２１３、ボード情報格納部２１４及びログ情報格納部２１５を有する。

組織情報格納部２１１は、危機に対応するための組織を示す組織管理テーブルを格納する。図３は、組織管理テーブルのデータ構成の一例を示す図である。図３のテーブルＴ１に示すように、組織管理テーブルは、組織ＩＤ、組織名、開始日時、廃止日時等が組織ごとに登録される。例えば、組織として、危機管理室、統括班、応急対策班、情報班などが登録されており、各組織には、組織ＩＤが割り当てられる。

ユーザ情報格納部２１２は、危機管理マネジメントシステム１００のユーザ情報を示すユーザアカウント管理テーブルを格納する。図４は、ユーザアカウント管理テーブルのデータ構成の一例を示す図である。図４のテーブルＴ２に示すように、ユーザアカウント管理テーブルは、ユーザＩＤ、氏名、読み仮名、ログインＩＤ、パスワード、メールアドレス及び登録日時等、ユーザに対応する各種情報が登録される。なお、ユーザアカウント管理テーブルには、メール送受信のための専用アカウントが用意されている。テーブルＴ２では、ユーザＩＤ「０」である「危機管理マネジメントシステムメール対応ユーザ」(以下、メール対応ユーザと略す。)が、メール送受信用の専用アカウントに該当する。このメール対応ユーザは、メールの送受信を専用に受け持つため、危機管理マネジメントシステム１００へのログインＩＤは持たない。

また、ユーザ情報格納部２１２は、組織管理テーブルとユーザアカウント管理テーブルと、を関連付けるためのユーザ所属組織管理テーブルを格納する。図５は、ユーザ所属組織管理テーブルのデータ構成の一例を示す図である。図５のテーブルＴ３に示すように、ユーザ所属組織管理テーブルは、ユーザＩＤ、組織ＩＤ、各々の役割を対応付けたものである。例えば、役割として、「運用管理者」の他、ボードの管理を行う「リーダ」、ボードでの情報のやり取りを行う「担当」がある。

アクセス制御情報格納部２１３は、各役割におけるデータのアクセス制御に関連する情報を格納する。すなわち、アクセス制御情報格納部２１３は、どの役割がどのようなことができるのか、といった情報を格納する。

ボード情報格納部２１４は、ボードＩＤと該ＩＤに対応する危機の各種情報とを対応付けたボード管理テーブル、各タスクにタスクＩＤと該タスクが属するボードのボードＩＤとを対応付けたタスク管理テーブル、及び、各タスクログにタスクログＩＤと対応タスクＩＤとを対応付けたタスクログ管理テーブルを格納する。本実施の形態では、タスクログは、あるタスクに関する個々の情報である。したがって、タスクログと、本システムの使用時に出力されるログや、操作内容を表すログとは異なる。

図６は、ボード管理テーブルのデータ構成の一例を示す図である。図６のテーブルＴ４に示すように、ボード管理テーブルには、ボードＩＤ、ボードの名前、このボードの概要、発生日時、状態、対応組織、登録日時、登録元組織などが登録される。運用管理者及びリーダは、ボード管理部２２３（後述）を用いてボードを作成することができ、このボードに対し、プロセスやフェーズ、チェックリストなどの危機管理対応に必要となる計画に関する設定を行なう。

図７は、タスク管理テーブルのデータ構成の一例を示す図である。図７のテーブルＴ５に示すように、タスク管理テーブルは、払い出されたタスクＩＤと、タスクの名称であるタスク名、このタスクＩＤに対応するタスクがいずれのボードに関係するかを示すボードＩＤ、タスクの優先度などが登録される。

図８は、タスクログ管理テーブルのデータ構成の一例を示す図である。図８のテーブルＴ６に示すように、タスクログ管理テーブルには、タスクログＩＤ、対応タスクＩＤ、内容、起票元か否かを示す起票元タスクログフラグ、起票元組織、起票者情報、送信元のメールアドレスであるMessage-ID、起票者情報に示された起票者のメールアドレスであるIn-Reply-Toが登録される。なお、テーブルＴ６の起票元タスクログフラグ欄には、起票元である場合には「ｔｒｕｅ」フラグが立ち、起票元でない場合「ｆａｌｓｅ」フラグが立つ。

Ｄｏ画面管理部２２５（後述）は、ボード情報格納部２１４が格納するボード管理テーブル、タスク管理テーブル及びタスクログ管理テーブルを基に、利用者端末１の画面に表示させるＤｏ画面を作成する。

ログ情報格納部２１５は、本システムを使用したときのユーザの認証結果、操作内容等を格納する。システム監査人は、監査時に、このログ情報格納部２１５に格納されているログを確認することで、誰がいつ何を変更したのか、不正な処理が行なわれていないかといった内容を把握することができる。

データ処理部２２は、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。例えば、データ処理部２２は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路である。データ処理部２２は、処理受付部２２１、認証処理部２２２、ボード管理部２２３、Ｐｌａｎ画面管理部２２４、Ｄｏ画面管理部２２５、Ｓｅｅ画面管理部２２６、メール処理部２２７及びログ出力部２２８を有する。

処理受付部２２１は、入出力インタフェースからなり、利用者端末１の操作によって入力された操作データを受信する。認証処理部２２２は、処理受付部２２１により利用者端末１のログインＩＤやパスワードなどの識別情報を受信した場合に、ユーザ情報格納部２１２に格納されたユーザ情報をもとに認証を行なう。

ボード管理部２２３は、運用管理者及びリーダが操作する利用者端末１からの操作データにしたがって、ボードを作成する。ボード管理部２２３は、例えば、図６のテーブルＴ４のように、「台風１号危機管理対応」のボードを作成し、該ボードに対して、ボードＩＤ「１」を付与し、ボード管理テーブルに登録する。

Ｐｌａｎ画面管理部２２４は、データ格納部２１に格納される情報をもとに、Ｐｌａｎ画面に必要な情報を表示する。Ｐｌａｎ画面管理部２２４は、Ｐｌａｎ画面として、全体マネジメントを支援するためのプロセス、個々のプロセスで実施すべきチェックリスト、及び、危機管理におけるフェーズを示す。

図９は、風水害におけるプロセスを示す画面表示例を示す図である。風水害対応の場合には、利用者端末１の画面に、図９に示すプロセスが表示される。そして、図１０は、フェーズ、「Ｔ１:平時、Ｔ０:解除」プロセスにおけるチェックリストの画面表示例を示す図である。図１０のリストＴ７に示すように、「Ｔ１:平時、Ｔ０:解除」プロセスにおけるチェックリストとして、各番号「Ｎｏ」に、評価・チェックリスト及び対応組織が対応付けられたものが、利用者端末１の画面に表示される。

続いて、図１１は、風水害におけるフェーズの画面表示例を示す図である。図１１のテーブルＴ８に示すように、風水害におけるフェーズ画面として、発災前、発災後の各経過時間に応じた対応を示すフェーズ画面が、利用者端末１の画面に表示される。このＰｌａｎ画面を確認することによって、運用管理者及びリーダは、その時点で誰が何をやるべきなのかを確認し、的確な指示を出せるようにしている。

Ｄｏ画面管理部２２５は、データ格納部２１に格納される情報をもとに、Ｄｏ画面に表示されるボードを構成する情報として、タスク及びタスクログを保存する。Ｄｏ画面管理部２２５は、利用者端末１のＤｏ画面表示要求に応じて、風水害時における情報のやり取りを各タスクＩＤに対応付けたＤｏ画面を作成し、利用者端末１の画面に表示させる。そして、Ｄｏ画面管理部２２５によって利用者端末１の画面に表示されたＤｏ画面を確認することによって、運用管理者及びリーダは、風水害の対応状態を認識することができる。

図１２は、風水害時における情報のやり取りの画面表示例を示す図である。図１２の画面Ｔ９に示すように、Ｄｏ画面管理部２２５は、Ｄｏ画面として、タスクＩＤ、優先度、状態、タスク名、更新日時、起票日時、送信側、受信側及び連絡内容等が対応付けられた画面が、利用者端末１の画面に表示される。例えば、画面Ｔ９に示すように、タスクＩＤ「３６０」のタスクは、タスク名が「土砂崩れ発生」である。そして、このタスクには、テーブルＴ６（図８参照）のタスクログＩＤ「６２２」〜「６２６」に示す５つのタスクログが関連付けられている。なお、タスクＩＤ「３６０」の優先度は、テーブルＴ５（図７参照）のタスク管理テーブルから取得されたものである。

Ｓｅｅ画面管理部２２６は、例えば、Ｄｏ画面で報告があった項目を集計した情報を加工してＳｅｅ画面を作成し、該作成したＳｅｅ画面を、利用者端末１の画面に表示させる。Ｓｅｅ画面管理部２２６は、例えば、Ｓｅｅ画面としてグラフや一覧表を作成する。図１３は、風水害時における避難所状況確認結果の画面表示例である。図１３の画面Ｔ１０に示すように、Ｓｅｅ画面管理部２２６は、避難所状況として収集された情報を用いて、報告対象である各避難所の避難所状況を示す画面を、Ｓｅｅ画面として、利用者端末１の画面に表示させる。避難所状況は、状況及び食事、水、トイレ、入浴及び生活必需品の充足状態を示している。このようなＳｅｅ画面は、収集された情報に基づき、運用管理者及びリーダが全体の状況を俯瞰するために使用される。

メール処理部２２７は、対応指示を含むメールの送信指示を受けた場合に送信対象の端末に対応状況及び対応指示を含むメールを送信するとともに、該送信した対応指示を、該対応指示が対応する対応業務の識別情報に対応付けた状態で危機対応情報に登録する。言い換えると、メール処理部２２７は、送信対象の利用者端末１に対し、タスクログをメール送信する。ユーザは、このメールを受信することによって、メール環境しか使えない場合であっても、危機対応の状況を把握することが可能になる。

或いは、メール処理部２２７は、或いは、危機対応情報に変更があった場合に変更内容を含むメールを送信対象の利用者端末１に送信してもよい。もちろん、メール処理部２２７は、定期的に、アラームメールとして、危機対応情報に関する情報を含むメールを送信対象の利用者端末１に送信してもよい。

また、メール処理部２２７は、利用者端末１から該利用者端末１のユーザの対応内容を含む返信メールを受信した場合に、対応内容を、該対応内容が対応する対応業務の識別情報に対応付けた状態で、データ格納部２１が格納する危機対応情報に登録する。これによって、ユーザは、メール環境しか使えない場合であっても、危機管理マネジメントシステムサーバ２に迅速に報告を行うことができるため、危機管理マネジメントシステムサーバ２は、危機管理情報を一元管理することができる。

また、メール処理部２２７は、一つのタスクが完了した場合に、該タスクに関する組織に属する利用者端末１に、該タスクが完了した旨を示す完了メールを送信する。これによって、ユーザは、メール環境しか使えない場合であっても、タスクが完了したことを即座に把握することができる。

ログ出力部２２８は、危機管理マネジメントシステムサーバ２を使用した場合のユーザの認証結果、操作内容等を、ログ情報格納部２１５に格納する。

［メール処理部のメール送信処理］
次に、メール処理部２２７の処理について詳細に説明する。前述したように、メール処理部２２７は、送信対象のユーザが持つ利用者端末１に対し、タスクログをメールで送る。

メール処理部２２７では、起票者が誰であっても、メール対応ユーザが、起票元組織および送信先組織に含まれるユーザに対してメールを送るようにメール本文を作成し、メールサーバ３にメールを送信する。また、メール送信時には、Ｂｃｃ(ブラインドコピー)でメール対応ユーザにメールを送信する。

図１４は、風水害における送信メールの文面例を示す図である。この図１４では、画面Ｔ９（図１２参照）の領域Ｒ１に示す、タスクＩＤ「３６０」の起票日時「８／４ ０２：４１」の連絡内容をメールで送信する指示をメール処理部２２７が受けた場合を例に説明する。この内容は、タスクログＩＤ「６２３」（図８のテーブルＴ６参照）に対応する。

図１４に示すメールＭ１のように、メール処理部２２７は、画面Ｔ９の領域Ｒ１に示す内容を基に、「応急対策班」に属するユーザへ、ボード名「台風１号危機管理対応」、タスク名「土砂崩れ発生」、優先度「緊急」、連絡内容「付近の現地の状況確認をしてください。」としたメール本文を作成する。メール本文の後半には、返信時における対応内容等に関する記載欄を設け、ユーザが容易かつ適切に返信メールを作成できるようにしている。この場合、メール処理部２２７は、起票元組織「統括班」及び送信先組織「応急対策班」のユーザのメールアドレスを送信先アドレスとして設定する。

そして、メール処理部２２７は、ユーザが対応タスクを容易に認識できるように、このメールの件名として、＜ボード名：タスク名＞を入れる。言い換えると、メール処理部２２７は、対応業務の識別情報を件名として記載する。したがって、メール処理部２２７は、メールＭ１の件名として、ボード名である「台風１号危機管理対応」及びタスク名である「土砂崩れ発生」を入れる。メール処理部２２７は、例えば、図１４に示す一定のフォーマットで送信メールを作成する。

続いて、メール処理部２２７は、作成したメールＭ１を、メールサーバ３を介して、送信対象の利用者端末１に送信する。この結果、メールしかない環境のユーザも、このメールを確認することによって、危機対応状態を認識することができる。

なお、メール対応ユーザは、ユーザからの返信メールを受信したときに、例えば、タスクログ管理テーブル（図８のテーブルＴ６参照）の内容と、メール本文中の連絡内容とのマッチングを取って、タスクログＩＤを特定する。その後、メール対応ユーザは、メールのヘッダに付くMessage-IDをタスクログ管理テーブルのカラムに書き込む。図１５は、図１４に示すメールＭ１に対する返信メールの文面例を示す図である。図１５に示すメールＭ２のように、定型フォーマットのメールＭ１に対し、一定のフォーマットを用いてユーザからメールが返信された場合には、該メールＭ２の参照メール（メールＭ１）のMessage-IDがIn-Reply-Toに設定される。

［メール処理部による返信メールに対する処理］
次に、メール処理部２２７が、利用者端末１のユーザによる返信メールに対する処理について説明する。

まず、危機管理マネジメントシステムサーバ２が、図１５に示す定型フォーマットを用いたメールＭ２を受信した場合の処理について説明する。この場合、メール処理部２２７は、返信メールのヘッダを見て、In-Reply-Toに設定されたMessage-IDを特定する。この場合には、Message-IDとして、送信元の「32ga3sg-poe4-ws323201mwl＠foo.or.jp」を特定する。

ここで、前述のように、メールＭ２は、タスクログＩＤ「６２３」のメールに対する返信メールである。このタスクログＩＤ「６２３」のタスクＩＤは「３６０」であるため、メール処理部２２７は、このメールＭ２の内容に対応する新規タスクログＩＤとして「６２５」を登録し（図８のテーブルＴ６参照）、このタスクＩＤを「３６０」とする。そして、メール処理部２２７は、メール本文の連絡内容に記載している文章を基に、ボード名、タスク名、起票元組織、送信先組織、優先度、状態をそれぞれ登録する。

具体的には、メール処理部２２７は、ボード管理テーブル（図６のテーブルＴ４参照）、タスク管理テーブル（図７のテーブルＴ５参照）を参照し、メールＭ２記載のボード名「台風１号危機管理対応」、タスク名「土砂崩れ発生」が、ボードＩＤ「１」及びタスクＩＤ「３６０」に対応することを認識する。

このとき、メール処理部２２７は、メールＭ２は、タスクログＩＤ「６２３」のメールに対する返信メールであるため、このメールＭ２の内容に対し、タスクＩＤ「３６０」に含まれる新規タスクログＩＤ「６２５」を登録する（図８のテーブルＴ６の領域Ｒ３参照）。そして、メール処理部２２７は、タスクログ管理テーブルのタスクログＩＤ「６２５」の内容欄に、メールＭ２の連絡内容「4：08市道△線は、土砂のため通行できません。住民安否は、消防団によると人的被害はないとのことです。」を登録する（図８のテーブルＴ６の領域Ｒ３参照）。また、メール処理部２２７は、タスクログＩＤ「６２５」の起票元組織欄にメールＭ２に記載の「応急対策班」を登録する（図８のテーブルＴ６の領域Ｒ３参照）。そして、メール処理部２２７は、タスクログを出力する。

続いて、メール処理部２２７は、メールＭ２のFrom欄のメールアドレス「takahashi.hideo@foo.or.jp」からユーザアカウント管理テーブル（図４のテーブルＴ２参照）を参照し、起票者情報として「高橋 英夫」を設定する（図８のテーブルＴ６の領域Ｒ３参照）。その後、メール処理部２２７は、メールのヘッダに記載されているMessage-ID「32ga3sg-poe4-ws323201mwl＠foo.or.jp」とIn-Reply-To「EG2LOI8ANOM5432WGS＠foo.or.jp」とをタスクログ管理テーブル（図８のテーブルＴ６の領域Ｒ３参照）に設定する。なお、起票元タスクログフラグは、From欄のメールアドレスが、メール対応ユーザでないため、「false」となる（詳細は、インターネットメッセージフォーマット RFC5322、［online］、［平成２８年１０月１７日検索］、インターネット＜ＵＲＬ：http://srgia.com/docs/rfc5322j.html参照＞）。

次に、新規タスク立ち上げが必要となる返信メールを利用者端末１から受信した場合のメール処理部２２７の処理について説明する。具体的には、メールでのやり取りしかできないような環境において、新規のタスクを立ち上げる場合である。例えば、風水害で見回りをしていた応急対策班の人が、土手が破れて川の水が道路にあふれているのを発見した場合を例に説明する。

図１６は、ユーザからのメールの文面例の他の例を示す図である。図１６に示すメールＭ３は、定型フォーマットにしたがってメールが記載されている。この場合、メール処理部２２７は、文面を解釈し、ボード名から登録すべきボードを特定する。この場合は、ボード名として「台風１号危機管理対応」が記載されており、登録すべきボードが、ボードＩＤ「１」であることが特定できる。そして、このメールＭ３は、新規タスク立ち上げのためのものであるため、メールにはIn-Reply-To欄が記載されていない。メール処理部２２７は、このメールＭ３が示す内容を、新規タスクとしてボードに登録する。図１６の例ではタスク名が空欄になっているため、メール処理部２２７は、空欄のまま新規タスクを登録し、システム上でタスク名を記載する。或いは、メール処理部２２７は、連絡内容の文章の先頭から数文字をタスク名として登録してもよい。

図１７は、ユーザからのメールの文面例の他の例を示す図である。図１７に示すメールＭ４は、非定型フォーマットで記載されている。この場合、登録するボードが記載されていないため、メール処理部２２７は、ボード管理部２２３に問い合わせて、各々のボードを作成した組織に属する運用管理者およびリーダ権限を持つユーザの情報を取得する。そして、メール処理部２２７は、運用管理者およびリーダ権限を持つユーザに対して、新規タスクが来たことを通知し、新規タスクに対応するメールＭ４の登録指示の依頼を送信する。

図１８は、風水害における登録指示依頼の画面例を示す図である。メール処理部２２７は、図１８に示す画面Ｍ５を作成し、運用管理者およびリーダ権限を持つユーザの利用者端末１の画面に表示させる。例えば、本危機管理マネジメントシステムサーバ２にアクセスし、登録指示画面を確認するよう依頼するメールを、運用管理者およびリーダ権限を持つユーザの利用者端末１に送信してもよい。また、この画面Ｍ５のＵＲＬを本文中に記載したメールを、運用管理者およびリーダ権限を持つユーザの利用者端末１に送信し、ユーザが、このメールのＵＲＬをクリックすると、画面Ｍ５に接続できるようにしてもよい。

画面Ｍ５では、登録指示の依頼内容となる連絡内容と、起票元組織とを示す。そして、そして、画面Ｍ５では、ボード名、タスク名、送信先組織、優先度、状態のそれぞれが、選択可能に表示される（画面Ｍ５の白抜き欄）。

ここで、ボードは危機管理の事象により作成されるため、同じ時期に類似の内容のボードが作成されることは考えにくい。そのため、メール処理部２２７は、複数のボードが作成されていたとしても、ボード管理テーブル（図６のテーブルＴ４参照）を基に、新規タスクに対して該当するボードを、特定することができる。メール処理部２２７は、特定したボードを画面Ｍ５のボード名欄に示す。そして、メール処理部２２７は、メール起票者が所属する組織を、組織情報格納部２１１及びユーザ情報格納部２１２から特定し、起票元組織として設定する。メール処理部２２７は、特定した起票元組織を画面Ｍ５の起票元組織欄に示す。

そして、該当する組織の運用管理者またはリーダは、自身が有する利用者端末１を操作し、表示された画面Ｍ５の、ボード名、タスク名、送信先組織、優先度を記載、或いは、選択し、登録ボタンを押下することで、図１７のメールＭ４を新規タスクとして登録する。実際には、メール処理部２２７は、運用管理者またはリーダが有する利用者端末１から、ボード名、タスク名、送信先組織、優先度を記載、或いは、選択する情報を登録内容として受信し、新規タスクとしてボードに登録する。新規タスクログＩＤの設定、タスクログ登録、起票者情報の設定及びタスクログ管理テーブルへのメールアドレス設定は、前述したものと同様である。

また、メール処理部２２７は、新規タスクに限らず、定型フォーマットを使わずにメールで報告があった場合も同様の処理を行う。図１９は、風水害における登録指示依頼の画面例の他の例を示す図である。メール処理部２２７は、この場合も、同様に、各々のボードを作成した組織に属する運用管理者およびリーダ権限を持つユーザの利用者端末１に、図１９の画面Ｍ６に例示する登録指示画面を表示させる。

この場合、運用管理者またはリーダは、画面Ｍ６を用いて、ボード名やタスク名、送信先組織、優先度に加えて、状態や関連するタスクのＩＤを記載、或いは、選択して登録することによって、該当するタスクをタスクログとして登録することができる。

言い換えると、メール処理部２２７は、返信メールに対応業務の識別情報が記載されていない場合には、組織の責任者である運用管理者およびリーダ権限を持つユーザが有する利用者端末１に対し、返信メールの内容とともに、返信メールに対応する対応業務の識別情報を含む危機対応情報への登録内容の指示依頼を送信する。そして、メール処理部２２７は、運用管理者およびリーダ権限を持つユーザが有する利用者端末１から返信された指示内容にしたがって危機対応情報への登録を行う。

なお、上記では、画面Ｍ５，Ｍ６を表示する相手として、「各々のボードを作成した組織に属する運用管理者およびリーダ権限を持つユーザ」と記載したが、これに限られるものではなく、あくまでも一例である。危機管理に対応する方針により、誰でも対応できるようにするために、メール処理部２２７は、「メール起票者が属する組織のユーザ全員」の全利用者端末１に対して画面Ｍ５，Ｍ６を表示させてもよい。或いは、組織で責任を持つ方針に則るのであれば、メール処理部２２７は、「メール起票者が属する組織の、運用管理者およびリーダ権限を持つユーザ」の全利用者端末１に対して画面Ｍ５，Ｍ６を表示することで、危機対応は可能となる。

［タスク完了時におけるメール処理部の処理］
次に、タスク完了時におけるメール処理部２２７の処理について説明する。タスクを完了させる場合は、タスクの起票者もしくは起票者が所属する組織が、状態を変更（図１９の画面Ｍ６の「状態」を「完了」に変更)する。この登録内容を受信することによって、メール処理部２２７は、このタスクが完了したことを、データ格納部２１の対応データに登録する。続いて、メール処理部２２７は、このタスク全体に関わった組織に属するユーザの全利用者端末１に対して、タスク完了メールを送信する。タスク完了メールには、完了したタスクの識別情報、及び、該タスクが完了した旨が記載される。

なお、メール本文で、「状態」が「完了」と書かれていたとしても、メールの起票者の所属組織が、タスクの起票組織と一致しない場合は、メール処理部２２７は、データ格納部２１の対応データに対して、「状態」を変更しないようにする。また、「状態」が「完了」となったタスクに対し、ユーザがタスク登録のためのメールを出しても、このメールの内容は、データ格納部２１の対応データに登録されない。メール処理部２２７は、タスク完了メール送信後に該タスクに対する返信メールを受信した場合、何もメール返信しないとしてもよいし、自動で「このタスクは完了しました」というメールを再度送って、送信者に状態を再認識させ、別のタスクを遂行させてもよい。

また、危機管理マネジメントシステムサーバ２では、タスクがスケジュール、チェックリスト、ホワイトボードなどに置き換わったとしても、メールで内容を通知するという処理内容は同じである。危機管理マネジメントシステムサーバ２は、Ｐｌａｎ画面の情報共有の場合には、Ｄｏ画面のタスクとして表示してもよいし、表示しないようにしてもよい。Ｐｌａｎ画面にある内容を情報共有する場合、Ｄｏ画面のタスクの内容として、会議開催通知、やるべき項目のチェックリスト、あるいはホワイトボードに記述された内容（画面キャプチャ、あるいはすべての履歴を保存していた場合は、表示したい時間情報とホワイトボードの場所の提供等）などが記述されることになる。

［メール送信処理の処理手順］
次に、メール処理部２２７によるメール送信処理の処理手順について説明する。図２０は、図２に示すメール処理部２２７によるメール送信処理の処理手順を示すフローチャートである。

図２０に示すように、メール処理部２２７は、タスクログのメール送信の指示を受けると（ステップＳ１）、まず、危機管理情報であるデータ格納部２１の各データを参照する（ステップＳ２）。起票元組織及び送信先組織に含まれるユーザをメールの送信先に設定する（ステップＳ３）。そして、メール処理部２２７は、メールの件名として、＜ボード名：タスク名＞を入れる（ステップＳ４）。続いて、メール処理部２２７は、送信を指示された連絡内容を含むメール本文を作成する（ステップＳ５）。この場合、メール処理部２２７は、例えば、図１４のメールＭ１で示す定型フォーマットにしたがって、メール本文を作成する。そして、メール処理部２２７は、作成したメールを、送信対象の利用者端末１に送信して（ステップＳ６）、処理を終了する。なお、メール処理部２２７は、送信された連絡内容（対応指示）を、該対応指示が対応するタスクＩＤに対応付けた状態で危機対応情報に登録する。

［返信メールに対する処理の処理手順］
次に、メール処理部２２７による、利用者端末１による返信メールに対する処理の処理手順について説明する。図２１は、図２に示すメール処理部２２７による、利用者端末１による返信メールに対する処理の処理手順を示すフローチャートである。メール処理部２２７は、利用者端末１による返信メールを受信すると（ステップＳ１１）、この返信メールが非定型フォーマットか否かを判断する（ステップＳ１２）。

メール処理部２２７は、返信メールが非定型フォーマットであると判断した場合（ステップＳ１２：Ｙｅｓ）、返信メールに、登録するボードが記載されていないため、ボード管理部２２３に問い合わせを行う（ステップＳ１３）。

そして、メール処理部２２７は、各々のボードを作成した組織に属する運用管理者およびリーダ権限を持つユーザの情報を取得する（ステップＳ１４）。続いて、メール処理部２２７は、運用管理者およびリーダ権限を持つユーザの利用者端末１に対して、ボード不明のタスクが来たことを通知し、該タスクの登録指示の依頼を送信する（ステップＳ１５）。具体的には、メール処理部２２７は、図１８に示す画面Ｍ５或いは図１９に示す画面Ｍ６を、運用管理者およびリーダ権限を持つユーザの利用者端末１に表示させる。続いて、メール処理部２２７は、運用管理者またはリーダが有する利用者端末１から、登録内容を受信する（ステップＳ１６）。登録内容は、ボード名、タスク名、送信先組織、優先度等である。

一方、メール処理部２２７は、返信メールが非定型フォーマットでなく定型フォーマットであると判断した場合（ステップＳ１２：Ｎｏ）、この返信メールのIn-Reply-To欄が記載されているか否かを判断する（ステップＳ１７）。メール処理部２２７は、返信メールのIn-Reply-To欄が記載されてないと判断した場合には（ステップＳ１７：Ｎｏ）、この返信メールの文面を解釈し（ステップＳ１８）、ボード名から登録先のボードを特定する（ステップＳ１９）。

そして、メール処理部２２７は、ステップＳ１６終了後、または、ステップＳ１９終了後、返信メールが新規タスクに対応するものであるかを判断する（ステップＳ２０）。メール処理部２２７は、返信メールが新規タスクに対応するものであると判断した場合（ステップＳ２０：Ｙｅｓ）、新規タスクとしてボードに登録する（ステップＳ２１）。

そして、メール処理部２２７は、ステップＳ２１終了後、または、返信メールのIn-Reply-To欄が記載されていると判断した場合（ステップＳ１７：Ｙｅｓ）、または、返信メールが新規タスクに対応するものでないと判断した場合（ステップＳ２０：Ｎｏ）、この返信メールの内容に対して、新規タスクログＩＤを設定する（ステップＳ２２）。続いて、メール処理部２２７は、この返信メールの内容、及び、運用管理者またはリーダが有する利用者端末１から指示された登録内容を、対応するタスクログに登録し（ステップＳ２３）、タスクログを出力する（ステップＳ２４）。

そして、メール処理部２２７は、返信メールのFrom欄のメールアドレスと、ユーザアカウント管理テーブル（図４のテーブルＴ２参照）とを基に、起票者情報を設定する（ステップＳ２５）。続いて、メール処理部２２７は、返信メールのヘッダの記載内容をタスクログ管理テーブル（図８のテーブルＴ６の領域Ｒ３参照）に設定し（ステップＳ２６）、処理を終了する。

［タスク完了時における処理の処理手順］
図２２は、図２に示すメール処理部２２７のタスク完了時における処理手順を示すフローチャートである。図２２に示すように、メール処理部２２７は、タスクの状態が完了した場合には（ステップＳ３１）、このタスク全体に関わった組織に属するユーザの全利用者端末１に対して、このタスクが完了したことを示したタスク完了メールを送信する（ステップＳ３２）。

また、メール処理部２２７は、状態が完了となったタスクに対して返信メールを受信したか否かを判断する（ステップＳ３３）。メール処理部２２７は、タスク完了メール送信後に該タスクに対する返信メールを受信したと判断した場合には（ステップＳ３３：Ｙｅｓ）、タスク完了メールを、該返信メールの送信元に再送信する（ステップＳ３４）。また、メール処理部２２７は、タスク完了メール送信後に該タスクに対する返信メールを受信していないと判断した場合には（ステップＳ３３：Ｎｏ）、処理を終了する。

［本実施の形態の効果］
本実施の形態に係る危機管理マネジメントシステムサーバ２は、送信対象の利用者端末１に対し、タスクログをメール送信する。すなわち、危機管理マネジメントシステムサーバ２は、危機対応計画の内容や現在の状況を、担当者にメールで送ることができるようにしている。したがって、対応の担当者は、メール環境しか使えない場合であっても、このメールを受信することによって、危機対応の状況等を把握することが可能になる。この結果、本実施の形態によれば、メール環境しか使用できない担当者がいる場合であっても、このメールを受信することによって、危機対応計画を把握でき、今後の対応の進め方に対する指標を立てることができる。

また、メール処理部２２７は、利用者端末１から該利用者端末１のユーザが実行した対応内容を示した返信メールを受信した場合には、返信メールに示された対応内容を、データ格納部２１が格納する危機対応情報に登録する。言い換えると、ユーザは、メール環境しか使えない場合であっても、危機管理マネジメントシステムサーバ２に迅速にメールで報告を行うことができる。そして、危機管理マネジメントシステムサーバ２は、ユーザによる返信メールに示された内容を危機管理情報に登録することによって、危機管理情報を適切に一元管理することができる。

また、メール処理部２２７は、一つのタスクが完了した場合に、該タスクに関する組織に属する利用者端末１に、該タスクが完了した旨を示す完了メールを送信する。これによって、ユーザは、メール環境しか使えない場合であっても、タスクが完了したことを即座に把握することができる。すなわち、本実施の形態によれば、メール環境さえ使用することができれば、担当者に、やるべきことを連絡でき、かつ現状報告も行なえる。言い換えると、完了したタスクについては、その旨通知が来るので、担当者は状況が把握でき、次にやるべきことに取り掛かることができる。また、本実施の形態では、危機管理マネジメントシステムサーバ２が、メールからの情報も一元管理するため、対応を指揮している人は、全体の状況を容易に把握でき、次にやるべきことの指示が的確に出せるようになる。

具体的には、危機管理マネジメントシステム１００では、危機対応に対する計画を立案し、それをＰｌａｎ画面として提示する。危機管理室は、各プロセスにおけるチェックリストに従って具体的なタスクを作成し、タスクに対する情報収集や調査結果を報告するように、各担当者に指示を出している。本危機管理マネジメントシステム１００では、Ｄｏ画面に掲示板を用意し、そこでタスクに関するやり取りが行なわれる。

このようなシステムにおいて、危機管理マネジメントシステムサーバ２では、システムにログインできない担当者がいる場合を考慮し、登録されている担当者に対してはメールでもやり取りを可能とした。また、担当者から、ある依頼に対する返信メールがあった場合、危機管理マネジメントシステム１００のＤｏ画面で表示するときには、どの依頼に対する返信であるかが分かるようにするために、依頼内容に加え、タスクの状態も合わせて担当者にメールを送る。これによって、本実施の形態では、通信手段がメールしかない環境においても、ユーザによる進捗状況の判別を可能とする。

また、Ｐｌａｎ画面には、会議などの今後のスケジュールやチェックリスト、ホワイトボードなどが提供されている。危機管理マネジメントシステムサーバ２では、例えば、スケジュールであれば、関係者に開始時間をメールなどで通知することで、遠隔からの会議参加を促すことができるようになる。ここで、危機管理マネジメントシステムサーバ２では、ホワイトボードについて、共有したいタイミングで画像キャプチャを取る、或いは、時系列に記載された内容を保存し、遠隔にいるユーザ等には、メールで通知することによって、ある特定の時間の情報を共有することができるようになる。したがって、本実施の形態では、ホワイトボードの内容を、ユーザは、システムにログインしなくても共有できる。また、本実施の形態では、ホワイトボードの内容は、時間情報と併せてＤｏ画面に保存されるため、ユーザは、その時に何が情報として挙がっていたのかを、のちの振り返り時にでも把握できる。

すなわち、本危機管理マネジメントシステムサーバ２は、災害に対処するために、様々なタスクが発生し、その進捗状況については、掲示板で報告がなされる。危機管理マネジメントシステムサーバ２では、各々のタスクの進捗状況などを含む現在の状態や優先順位といった項目を、投稿者が意識しなくても自動的に付与することで、掲示板を見ることができないメール使用者にもタスクの状況が分かるようにする。そして、危機管理マネジメントシステムサーバ２では、メールでやり取りしたものも、掲示板上のタスクの報告として追記されるため、掲示板で情報を共有する人も、すべてのやり取りを閲覧できる。また、本危機管理マネジメントシステムサーバ２では、タスクの状態が変更された場合、自動的にメールを送るようにすることで、メール使用者にも状態を容易に把握できる機能を提供する。

また、本危機管理マネジメントシステムサーバ２では、タスク以外の会議開催時間、やるべき項目のチェックリストやシステムが用意するホワイトボードの画面キャプチャや過去の履歴から特定の時間の記述内容などをメールで通知することによって、様々なツールを連携させて情報共有する機能を提供することができる。

したがって、本実施の形態によれば、どのツールを使用しても危機対応情報の一元管理及び情報の共有が可能である。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central Processing Unit）および当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
図２３は、プログラムが実行されることにより、危機管理マネジメントシステムサーバ２が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、危機管理マネジメントシステムサーバ２の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、危機管理マネジメントシステムサーバ２における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid State Drive）により代替されてもよい。

また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等は全て本発明の範疇に含まれる。

１ 利用者端末
２ 危機管理マネジメントシステムサーバ
３ メールサーバ
２１ データ格納部
２２ データ処理部
１００ 危機管理マネジメントシステム
２１１ 組織情報格納部
２１２ ユーザ情報格納部
２１３ アクセス制御情報格納部
２１４ ボード情報格納部
２１５ ログ情報格納部
２２１ 処理受付部
２２２ 認証処理部
２２３ ボード管理部
２２４ Ｐｌａｎ画面管理部
２２５ Ｄｏ画面管理部
２２６ Ｓｅｅ画面管理部
２２７ メール処理部
２２８ ログ出力部
Ｎ ネットワーク

Claims (8)

1. 危機対応情報を危機ごとに束ねたものをボードとし、該ボードの識別情報であるボードＩＤと前記危機への対応業務であるタスクを示す識別情報であるタスクＩＤとを関連づけるタスク管理テーブル、及び、前記タスクＩＤと前記タスクにおける対応指示及び対応内容の情報を示すタスクログとを関連づけるタスクログ管理テーブルを階層的に対応付けて記憶する記憶部と、
   対応指示を含むメールの送信指示を受けた場合に送信対象の端末に対応状況及び前記対応指示を含むメールを送信するとともに該送信した対応指示を、対応する前記タスクログ管理テーブルにタスクログとして対応付けて登録し、前記端末から該端末のユーザの対応内容を含む返信メールを受信した場合に、前記返信メールのタスクログが既存のタスクに対応する場合には、前記対応内容を、対応する前記タスクログ管理テーブルに対応付けたタスクログとして登録し、前記返信メールのタスクログのタスクが不明である場合には、前記返信メールの文面を解釈して登録すべきボードを特定して、特定したボードに新規のタスクを登録するとともに前記対応内容を前記新規のタスクに対応付けてタスクログとして登録するメール処理部と、
   を有することを特徴とする情報管理装置。
2. 前記メール処理部は、一つのタスクが完了した場合に、該タスクに関する組織に属する端末に該タスクが完了した旨を示す完了メールを送信することを特徴とする請求項１に記載の情報管理装置。
3. 前記メール処理部は、前記危機対応情報に変更があった場合に変更内容を含むメールを前記送信対象の端末に送信し、または、定期的に前記危機対応情報に関する情報を含むメールを前記送信対象の端末に送信することを特徴とする請求項１または２に記載の情報管理装置。
4. 前記メール処理部は、前記対応状況及び対応指示を含むメールの本文中に返信時における前記対応内容に関する記載欄を設けることを特徴とする請求項１〜３のいずれか一項に記載の情報管理装置。
5. 前記メール処理部は、前記対応業務の識別情報を件名として記載したメールを送信することを特徴とする請求項１〜４のいずれか１項に記載の情報管理装置。
6. 前記メール処理部は、前記返信メールにタスクの識別情報が記載されていない場合には、前記タスクに関する組織の責任者が有する端末に対し、前記返信メールの内容とともに、前記返信メールに対応するタスクの識別情報を含む前記ボードへの登録内容の指示依頼を送信し、前記組織の責任者が有する端末から返信された指示内容にしたがって前記ボードへの前記対応内容の登録を行うことを特徴とする請求項１〜５のいずれか１項に記載の情報管理装置。
7. 危機対応情報を危機ごとに束ねたものをボードとし、該ボードの識別情報であるボードＩＤと前記危機への対応業務であるタスクを示す識別情報であるタスクＩＤとを関連づけるタスク管理テーブル、及び、前記タスクＩＤと前記タスクにおける対応指示及び対応内容の情報を示すタスクログとを関連づけるタスクログ管理テーブルを階層的に対応付けて記憶する記憶部を有する情報管理装置が実行する情報管理方法であって、
   対応指示を含むメールの送信指示を受けた場合に送信対象の端末に対応状況及び前記対応指示を含むメールを送信するとともに該送信した対応指示を、対応する前記タスクログ管理テーブルにタスクログとして対応付けて登録する工程と、
   前記端末から該端末のユーザの対応内容を含む返信メールを受信した場合に、前記返信メールのタスクログが既存のタスクに対応する場合には、前記対応内容を、対応する前記タスクログ管理テーブルに対応付けたタスクログとして登録し、前記返信メールのタスクログのタスクが不明である場合には、前記返信メールの文面を解釈して登録すべきボードを特定して、特定したボードに新規のタスクを登録するとともに前記対応内容を前記新規のタスクに対応付けてタスクログとして登録する工程と、
   を含んだことを特徴とする情報管理方法。
8. コンピュータを、請求項１〜６のいずれか１項に記載の情報管理装置として機能させるための情報管理プログラム。

Images