JP2009075760A

JP2009075760A - 事例情報管理システム及びプログラム

Info

Publication number: JP2009075760A
Application number: JP2007242862A
Authority: JP
Inventors: Satoshi Oshima; 諭大島
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2007-09-19
Filing date: 2007-09-19
Publication date: 2009-04-09
Anticipated expiration: 2027-09-19
Also published as: JP4959486B2

Abstract

【課題】社員が事件や事故に巻き込まれた際、他の社員に必要な対応を提示でき、報告書の作成をも支援可能な技術の提供。
【解決手段】緊急事態の分類パターンに応じて用意された複数のテンプレートを格納しておくテンプレートＤＢ22と、分類パターンの選択画面をクライアント端末16に送信する処理、選択された分類パターンに対応したテンプレートに基づく入力画面34をクライアント端末16に送信する処理、クライアント端末16から送信された入力データを事例情報ＤＢ24に格納する処理、クライアント端末16から特定の事例情報の表示リクエストが送信された場合に、該当の事例情報を送信する処理を実行する事例情報管理サーバ12を備えた。入力画面34には、実行すべき作業手順が列挙されており、各作業手順には日時、実行主体、内容等の入力項目が設けられている。
【選択図】図１

Description

この発明は事例情報管理システム及びプログラムに係り、特に、企業の社員が事件や事故等の緊急事態に巻き込まれた際の顛末を記録した事例情報の管理技術に関する。

企業や官庁に勤務する社員や職員は、その通勤途上や勤務中に様々な事件・事故に巻き込まれる可能性があり、例えば移動中に交通事故に遭って病院に担ぎ込まれたり、何らかの嫌疑を受けて警察に逮捕された場合、その第一報が勤務先に通報されることが多い。
このような場合、連絡を受けた企業等では対策本部を立ち上げ、各方面への連絡や現場への急行などの措置を迅速に行う必要がある。

特に昨今では、企業や社員の不祥事が大きく報道され、対応を一歩誤ると取り返しのつかないダメージを企業が被る危険性が増大している。このため、緊急事態発生時における企業の危機管理の重要性が喧伝され、非特許文献１に示すように、危機管理対応マニュアルの作成やシミュレーション訓練の代行を専門に請け負う企業も登場している。
また、特許文献１に示すように、緊急事態の発生に備え、社員に対して事前の研修を効率的に実施するシステムも提案されている。
東京海上日動リスクコンサルティング株式会社［平成１９年７月１０日検索］インターネットURL:http://www.tokiorisk.co.jp/ 特開２００５−２６６４３７

確かに、いざというときに慌てないで済むよう、日頃から十分な準備をしておくに越したことはない。しかしながら、危機管理対応が担当任務の一部である総務や人事部門であれば兎も角、それ以外の営業や開発、製造部門等にとっては、忙しい本業の合間に滅多に生じない事柄のために十分な時間を確保することが難しく、実際に事件や事故が発生してからの対応とならざるを得ないのが実情である。

そして、このように実際に事件や事故が発生した場合には、分厚いマニュアルを引っ張り出して該当ケースを探している暇がないため、現場の社員は結局何をすべきなのかがわからなくなり、思考停止やパニックに陥る危険性があった。

また、事態が沈静化した後は速やかに報告書を作成し、総務や人事への報告を行うことが求められるが、一般社員にとってはこれ自体が相当に煩雑な作業であり、簡にして要を得た報告書をタイムリーに上梓することは困難であった。

さらに、自社の社員が実際に巻き込まれた事例の報告書であれば、本来、他の社員にとっても有効な教訓あるいは教材となる筈であるが、個人情報が含まれている関係で公開できず、過去の事例情報が有効活用されていないという問題があった。

この発明は従来の上記問題を解決するために案出されたものであり、企業の社員が事件や事故に巻き込まれた際に、迅速に必要な対応が執れるように他の社員を導くことができると同時に、必要な報告書の作成をも支援可能なシステムの実現を目的としている。この発明はまた、個人情報を保護しつつ、過去の事例情報を他の社員に公開可能とするシステムの提供をも目的としている。

上記の目的を達成するため、請求項１に記載した事例情報管理システムは、緊急事態の分類パターンに応じて予め用意された複数のテンプレートを格納しておくテンプレート記憶手段と、緊急事態の分類パターンの選択画面をクライアント端末に送信する手段と、クライアント端末から分類パターンの選択データが送信された場合に、対応のテンプレートを反映させた入力画面をクライアント端末に送信する手段と、クライアント端末から送信された入力データを、事例番号に関連付けて事例情報記憶手段に格納する事例情報登録手段と、クライアント端末から特定の事例情報の表示リクエストが送信された場合に、該当の事例情報を抽出し、当該クライアント端末に送信する事例情報送信手段とを備えた事例情報管理システムであって、上記入力画面には、当該緊急事態の発生時に実行すべき作業手順が列挙されており、各作業手順には、実行日時、実行主体、実行内容等の入力項目が設けられていることを特徴としている。

請求項２に記載した事例情報管理システムは、請求項１のシステムであって、さらに、上記入力画面に設けられた入力項目の中、特定の入力項目は予め伏字対象項目として設定されており、クライアント端末から送信された入力データの中、この伏字対象項目に入力された文字列を自動的に抽象的な伏字に変換する手段と、他の入力項目中に上記伏字対象項目に入力された文字列と同一の文字列が存在する場合、これを上記と同一の伏字に変換する手段とを備え、上記事例情報登録手段は、伏字に変換された状態の入力データを上記事例情報記憶手段に格納し、上記事例情報送信は、伏字に変換された状態の事例情報をクライアント端末に送信することを特徴としている。

請求項３に記載した事例情報管理システムは、請求項２のシステムであって、さらに、伏字対象項目に入力された文字列と伏字との対応関係を事例番号に関連付けて伏字情報記憶手段に格納する伏字情報登録手段と、特定のユーザIDについて予め完全閲覧権限を設定しておく記憶手段と、クライアント端末から送信されたユーザIDに基づいて、当該ユーザが完全閲覧権限を保有しているか否かを判定する手段と、当該ユーザが完全閲覧権限保有者である場合に、上記伏字情報記憶手段を参照し、各伏字に関連付けられた元の文字列を取得する手段と、上記事例情報中の伏字を元の文字列に変換する手段とを備え、上記事例情報送信手段は、この変換後の文字列を含む事例情報をクライアント端末に送信することを特徴としている。

請求項４に記載した事例情報管理システムは、請求項１〜３のシステムであって、さらに、上記入力画面には緊急事態の当事者の氏名を入力する項目と、この当事者の連絡先を表示する項目が設けられており、クライアント端末から送信された当事者の氏名をキーに人事情報データベースを検索し、この当事者の連絡先データを取得する手段と、この連絡先データを上記の表示項目に補充させた入力画面を生成し、クライアント端末に送信する手段を備えたことを特徴としている。

請求項５に記載した事例情報管理プログラムは、コンピュータを、緊急事態の分類パターンに応じて予め用意された複数のテンプレートを格納しておくテンプレート記憶手段、緊急事態の分類パターンの選択画面をクライアント端末に送信する手段、クライアント端末から分類パターンの選択データが送信された場合に、対応のテンプレートを反映させた入力画面をクライアント端末に送信する手段、クライアント端末から送信された入力データを、事例番号に関連付けて事例情報記憶手段に格納する事例情報登録手段、クライアント端末から特定の事例情報の表示リクエストが送信された場合に、該当の事例情報を抽出し、当該クライアント端末に送信する事例情報送信手段として機能させるプログラムであって、上記入力画面には、当該緊急事態の発生時に実行すべき作業手順が列挙されており、各作業手順には、実行日時、実行主体、実行内容等の入力項目が設けられていることを特徴としている。

請求項１に記載した事例情報管理システム及び請求項５に記載した事例情報管理プログラムによれば、クライアント端末上で緊急事態の分類パターンを選択することによって対応の入力画面がシステムから送信され、この入力画面には当該緊急事態において実行すべき作業手順が列挙されているため、切迫した状況下の一般社員であっても、必要な対応を着々と執行可能となる。
また、各作業手順には実行日時、実行主体、実行内容等の入力項目が予め設けられており、それらに対して必要データを順次入力していくことにより、事例情報の登録が完了する仕組みを備えている。したがって、事案終結後に改めて報告書を作成する手間を省くことが可能となる。

請求項２に記載した事例情報管理システムにあっては、入力画面の伏字対象項目に入力された文字列が自動的に伏字に変換されると共に、非伏字対象項目中に同文字列が入力されている場合にも同じ伏字に変換される仕組みを備えているため、氏名や住所などの個人情報を確実に秘匿した状態で他の社員に事例情報を開示することが可能となる。

請求項３に記載した事例情報管理システムにあっては、企業の幹部や人事部員など一定範囲の社員を予め完全閲覧権限保有者として登録しておくことにより、これらの限られた者に対しては伏字変換前の完全な内容の事例情報を開示可能となり、記録としての完全性を担保することができる。
個人情報の秘匿に関する従来のやり方では、まず事実をそのままデータベースに記録しておき、参照時にユーザの権限に応じて個人情報を隠蔽したり伏字に変換するというアプローチがとられていた。
これに対しこのシステムにあっては、まず秘匿すべき情報については入力時に伏字に置き換えて事例情報記憶手段に記録しておき、参照時に完全閲覧権限を有する者に対してのみ、伏字を本来の情報に置き換えて表示させる仕組みを備えているため、より強固に個人情報を保護することができる。

請求項４に記載した事例情報管理システムにあっては、事件や事故に巻き込まれた当事者の連絡先データが、人事情報データベースから入力画面中に自動的に補充される仕組みを備えているため、緊急事態におかれた一般社員であっても、当事者の家族等に必要な連絡を容易に行うことが可能となる。

図１は、この発明に係る事例情報管理システム10の全体構成図であり、事例情報管理サーバ12と、人事情報管理サーバ14と、社員の操作する複数のクライアント端末16を備えている。これら事例情報管理サーバ12、人事情報管理サーバ14、クライアント端末16間は、ネットワーク18を介して接続されている。

人事情報管理サーバ14は、全社員のID、パスワード、氏名、生年月日、所属部署、役職、連絡先等の属性情報を格納した人事情報ＤＢ20を管理している。
この人事情報ＤＢ20は、原則として人事部の社員のみがアクセス可能であり、後述のように、他の一般社員は人事部を通じて個別のアクセス権が設定された場合に限り、事例情報管理サーバ12を介して人事情報ＤＢ20にアクセスすることが許可される。

また、事例情報管理サーバ12には、専用のアプリケーションプログラムがセットアップされており、テンプレートＤＢ22、事例情報ＤＢ24、伏字情報ＤＢ26、認証ＤＢ27を管理している。
これらのデータベースの中、テンプレートＤＢ22及び事例情報ＤＢ24は、一般社員が自由にアクセスすることが認められている（詳細は後述）。
また、認証ＤＢ27には、人事情報ＤＢ20から取得した各社員のID、パスワードの他、事例情報の閲覧権限が設定されている。ここでは、人事部の社員及び取締役以上の社員について完全閲覧権限が設定されており、他の一般社員には限定閲覧権限が設定されているものとする（詳細は後述）。

以下、図２及び図３のフローチャートに従い、社員が事件や事故に遭遇した際の、このシステム10における処理手順について説明する。
まず、自社の社員に緊急事態が発生したとの連絡を受けた営業部員の「野村太郎」は、自己のクライアント端末16から事例情報管理サーバ12にアクセスし、事例の登録をリクエストする。これを受けた事例情報管理サーバ12は（図２のＳ10）、ID／パスワードの入力画面（図示省略）をクライアント端末16に送信し（Ｓ11）、当該社員のID及びパスワードの入力を促す。

クライアント端末16からID及びパスワードが送信されると（Ｓ12）、事例情報管理サーバ12は認証をした上で（Ｓ13）、分類パターンの選択画面をクライアント端末16に送信する（Ｓ14）。

図４は、この分類パターンの選択画面30を示すものであり、No.１〜16の分類パターンが列記されている。これらの中、No.１〜４は病気や怪我等の事故に関連しており、No.５〜16は犯罪等の事件に関連している。
各分類パターンには、連絡元（社員本人／関係者）、緊急性（要緊急対応／普通対応）、具体例等の分類項目が設定されており、これらの項目の記述を参照することにより、一般社員であっても現在の事態に最も適した分類パターンを容易に選択可能となる。

野村太郎が、No.１〜16の中から一つの番号をクリックして選択状態とし、「送信」ボタン32をクリックすると、クライアント端末16から事例情報管理サーバ12に分類パターンの選択データが送信される。
因みに、今回は同僚社員が駅で倒れたという一報が駅員（関係者）からもたらされた状況にあり、緊急性を有しているため、野村太郎はNo.３の分類パターンを選択したものとする。

この選択データを受けた事例情報管理サーバ12は（Ｓ15）、野村太郎が選択した分類パターンに対応したテンプレートをテンプレートＤＢ22から抽出し、これを反映させた入力画面をクライアント端末16に送信する（Ｓ16）。同時に事例情報管理サーバ12は、ユニークな事例番号を付した事例情報の新規レコードを、事例情報ＤＢ24に追加する（Ｓ17）。この事例情報は複数の「編集可能者」項目を備えており、この時点では野村太郎のIDが当該項目の一つに設定される。

図５は、入力画面34の具体例を示すものであり、上半分の領域に対象者氏名、連絡先１〜５の項目が設けられている。
また、下半分の領域には、経過入力欄36が設けられており、経過No.１〜５の作業手順項目37には、今回の事態において実行すべき作業手順が記述されている。
入力画面の右上には、本件の事例番号「１２５６３２」と、現在編集中の「野村太郎」の氏名が表示されている。

野村太郎は、「対象者氏名」の入力項目38に事件・事故に巻き込まれた社員の氏名「佐藤三郎」をタイプ入力した後、NO.１の作業手順である「最初の連絡の記録」に従い、第一報に関する情報を入力する。

まず、「日時」の入力項目39には入力画面34を表示させた際の日時がデフォルトで表示されているため、野村太郎は必要に応じて時刻を修正する。
つぎに野村太郎は、「誰から」の入力項目40に第一報をもたらした人物を入力する。今回は社員以外の駅員から連絡があったため、「第三者」の入力項目41に「駅員」とタイプ入力する。
これに対し、仮に他の社員から第一報がもたらされた場合には、「社員」の入力項目42に当該社員の氏名、役職、所属を入力する。

つぎに野村太郎は、「何処で」の入力項目43に事故の発生場所を入力する。今回は大手町駅で佐藤三郎が倒れた事案であるため、「固有名詞」の入力項目44に「大手町」を入力すると共に、「施設種」の入力項目45に「駅」を入力する。

つぎに野村太郎は、「誰に」の入力項目46に事故の第一報を受けた者を入力する。今回は社員である野村太郎が駅員からの電話を受けたため、「社員」の入力項目47に自己の氏名、所属を入力する。

つぎに野村太郎は、「内容」の入力項目48に「佐藤三郎が倒れ、駅医務室にいるとの第一報。」と入力する。

ここまでの入力が完了した時点で、野村太郎は「一時保存」ボタン50をクリックし、入力内容の保存をリクエストする。
そして、クライアント端末16から一時保存のリクエスト及び入力データを受け取った事例情報管理サーバ12は（Ｓ18）、入力データに基づいて事例情報ＤＢ24内の事例情報を更新する（Ｓ20）。

この際、事例情報管理サーバ12によって、入力データ中で個人の特定に繋がる部分については伏字変換処理が施された後（Ｓ19）、事例情報ＤＢ24に格納されるのであるが、この伏字変換処理については後に詳述する。
また、この段階では当該事例情報に「非公開」のフラグが立てられているため、他の一般社員がこれを閲覧することはできないが、上記のように事例情報管理サーバ12によって野村太郎のIDは当該事例情報の「編集可能者」項目に登録されているため、非公開の段階でも野村太郎は自由に閲覧ができる。

この時点で事例情報管理サーバ12は、人事情報管理サーバ14に対して、対象者氏名の「佐藤三郎」、「事例番号：１２５６３２」及び佐藤三郎の伏字（例えば「Ｔ０１」）を送信する（Ｓ21）。
これを受信した人事情報管理サーバ14は、人事情報ＤＢ20における佐藤三郎のレコードに、事例番号と伏字を記録する。この結果、佐藤三郎の今回の事故を人事情報管理サーバ14で管理可能となり、勤務状況や疾病・体調の記録、賞罰の判断資料等として利用される。

つぎに野村太郎は、NO.２の作業手順である「対応事務局の選定」に従い、課長の「斎藤孝夫」に対応事務局の選定について相談する。
そして、この相談の結果、係長の「鈴木一郎」が対応事務局に選定され、以後の入力作業を鈴木一郎が引き継ぐことになったものとする。

この場合、野村太郎はNO.２の作業手順に係る入力項目を埋めていく。すなわち、「誰から」の入力項目40に「氏名：斎藤孝夫」、「役職：課長」、「所属：営業」を入力すると共に、「誰に」の入力項目46に「氏名：鈴木一郎」、「役職：係長」、「所属：営業」を入力する。この場合、場所は重要でないため、「何処で」の入力項目43への入力は省略される。

つぎに野村太郎は、入力画面34の「編集可能者の追加」ボタン51をクリックし、編集可能者の追加をリクエストする。
そして、クライアント端末16から編集可能者の追加リクエスト及び入力データを受け取った事例情報管理サーバ12は（Ｓ22）、この入力データに対して伏字変換処理を施した後（Ｓ23）、この伏字変換済みのデータによって事例情報ＤＢ24に格納された事例情報を更新する（Ｓ24）。

つぎに事例情報管理サーバ12は、編集可能者追加用の入力画面（図示省略）をクライアント端末16に送信し（Ｓ25）、編集可能者として追加されるべき社員のID及び氏名の入力を促す。
これに対し野村太郎のクライアント端末16から鈴木一郎のID及び氏名が送信されると（Ｓ26）、事例情報管理サーバ12は当該事例情報の編集可能者項目に鈴木一郎のIDを追加設定する（Ｓ27）。

一方、事務局に任命された鈴木一郎は、自己のクライアント端末16から事例情報管理サーバ12にアクセスし、入力画面34の表示をリクエストする。これを受けた事例情報管理サーバ12は（図３のＳ30）、ID／パスワード／事例番号の入力画面（図示省略）をクライアント端末16に送信し（Ｓ32）、当該社員のID、パスワード及び事例番号の入力を促す。

鈴木一郎のクライアント端末16からID、パスワード、事例番号（１２５６３２）が送信されると（Ｓ34）、事例情報管理サーバ12は認証をした上で（Ｓ36）、上記の入力画面34を鈴木一郎のクライアント端末16に送信する（Ｓ38）。
この結果、図６に示すように、鈴木一郎のクライアント端末16上に入力画面34が表示される。この入力画面34においては、当然ながら野村太郎によって入力された事例情報が再現されているが、右上の「編集可能者」には鈴木一郎の氏名が表示されている。

これに対し鈴木一郎は、NO.３の作業手順「人事部に連絡」及びNO.４の作業手順「人事ＤＢアクセス許可」に従い、人事部に電話を掛けて人事課長の田中次郎に今回の事案を報告すると共に、人事情報ＤＢ20へのアクセス許可を求める。
そして、人事課長の田中次郎よりアクセス許可を受けた鈴木一郎は、NO.３及びNO.４の作業手順に係る「誰から」の入力項目40及び「誰に」の入力項目46に該当の氏名等を入力する。

一方、人事課長の田中次郎は、クライアント端末16から人事情報管理サーバ14にアクセスし、本件事案が終結するまでの間、営業部係長の鈴木一郎が人事情報ＤＢ20の情報を閲覧できるように、人事情報ＤＢ24にアクセス権を設定する。

引き続き鈴木一郎は、NO.５の作業手順「部長に連絡」に従い、営業部長の加藤四郎に電話を掛けて佐藤三郎が大手町駅で倒れた旨の報告を行った後、この作業手順に係る「誰から」の入力項目40及び「誰に」の入力項目46に該当の氏名等を入力する。

つぎに鈴木一郎は、画面右下の「次頁」ボタン52をクリックし、次頁の表示をリクエストする。
そして、クライアント端末16から次頁表示のリクエスト及び入力データを受け取った事例情報管理サーバ12は（Ｓ40）、この入力データに対して伏字変換処理を施した後（Ｓ41）、この伏字変換済みのデータによって事例情報ＤＢ24に格納された事例情報を更新する（Ｓ42）。

つぎに事例情報管理サーバ12は、次頁の入力画面34を生成し、クライアント端末16に送信する（Ｓ44）。この入力画面34には、図７に示すように、No.６以降の作業手順が記述されている。

そこで鈴木一郎は、NO.６の作業手順「本部長に連絡」に従い、営業本部長の山田五郎に電話を掛けて上記と同様の報告を行った後、この作業手順に係る「誰から」の入力項目40及び「誰に」の入力項目46に該当の氏名等を入力する。

つぎに鈴木一郎は、NO.７の作業手順「家族に連絡」に従い、佐藤三郎の家族への連絡を試みる。
まず「連絡先補充」ボタン54をクリックし、連絡先１〜５の空欄へのデータ入力をリクエストする。

そして、クライアント端末16から連絡先補充のリクエスト及びそれまでの入力データを受け取った事例情報管理サーバ12は（Ｓ46）、まず入力データに対して伏字変換処理を施した後（Ｓ47）、この伏字変換済みのデータによって事例情報ＤＢ24に格納された事例情報を更新する（Ｓ48）。つぎに事例情報管理サーバ12は、鈴木一郎のID及び対象者である「佐藤三郎」の文字列を人事情報管理サーバ14に送信し（Ｓ50）、佐藤三郎の連絡先データを要求する。
人事情報管理サーバ14は、鈴木一郎に人事管理ＤＢ20へのアクセス権が設定されていることを確認した上で、佐藤三郎の連絡先データを事例情報管理サーバ12に送信する。

これを受けた事例情報管理サーバ12は（Ｓ52）、連絡先データを補充した入力画面34を生成し、クライアント端末16に送信する（Ｓ54）。
この結果、連絡先１〜５に必要な情報が記述された入力画面34が、クライアント端末16のディスプレイに表示される。
鈴木一郎は、まず連絡先１（本人自宅）の電話番号に電話を掛け、同居家族との連絡を試みる。そして、自宅に家族が不在の場合、連絡先３（配偶者携帯）以下の電話番号に電話を掛け、配偶者や実家の家族との連絡を試みる。

このテンプレートで規定されている実体的な作業手順はここまでであり、事案によっては家族との連絡が取れた時点で完了となることもある。この場合、鈴木一郎は作業手順９の「人事部へ完了連絡」に従って人事課長の田中次郎に電話連絡を行った後、作業手順９及び作業手順10の入力項目に必要なデータを入力する。
完了の連絡を受けた人事課長の田中次郎は、人事情報ＤＢ20に一時的に設定された鈴木一郎のアクセス権を解除する。

これに対し、家族への連絡を行った後に追加的な処理を行った場合には、作業手順が空白となっているNO.８の行に行為主体（誰から）や場所（何処で）、対象者（誰に）、内容を記述する。
さらに追加的な処理を行った場合には、「行の追加」ボタン56をクリックして空白行を追加し、それぞれの行為主体や場所、行為対象者、内容を記述する。
図８に、NO.７の必要的作業手順以降に、多数の追加的作業を行った場合の入力例を示す。

入力画面34に必要なデータを入力し終えた鈴木一郎は、「入力完了」ボタン58をクリックし、事例情報の最終的な登録をリクエストする。
クライアント端末16からこの登録リクエスト及び入力データを受け取った事例情報管理サーバ12は（Ｓ56）、まず入力データに対して伏字変換処理を施した後（Ｓ57）、この伏字変換済みのデータによって事例情報ＤＢ24に格納された事例情報を更新する（Ｓ58）。

つぎに事例情報管理サーバ12は、当該事例情報について「公開」のフラグを設定し（Ｓ59）、一般社員の閲覧に供する。

つぎに、図９のフローチャートに従い、事例情報管理サーバ12による伏字変換処理について詳細に説明する。

まず事例情報管理サーバ12は、入力データ中から伏字対象項目に入力された文字列を抽出する（Ｓ60）。
すなわち、入力画面34においては、「対象者氏名」、「連絡先１〜５」の「氏名」、「誰から／社員」の「氏名」及び「所属」、「何処で」の「固有名詞」、「誰に／社員」の「氏名」及び「所属」の各入力項目が、予め伏字対象項目として設定されている。
このため、これらの項目に入力された文字列は、事例情報管理サーバ12によって自動的に伏字対象文字列として抽出され、抽象的な文字列からなる伏字に原則として変換される（Ｓ64）。

例えば、対象者氏名、配偶者氏名、本人実家の氏名、配偶者実家の氏名は、Ｔ０１〜Ｔ０４に変換される。
また、「社員／氏名」については、Ｓ０１〜Ｓｎに変換される。
また「何処で／固有名詞」についてはＢ０１〜Ｂｎに変換される。
さらに、「所属」についてはＤ０１〜Ｄｎに変換される。ただし、所属が「人事」の場合には伏字にしても「作業手順」の項目の記述から人事であることが自明であり、秘匿する必要性も少ないため、予め「人事」は伏字対象外文字列に指定されており、伏字への変換処理は省略される（Ｓ61）。

つぎに事例情報管理サーバ12は、図１０に示すように、伏字対象項目に入力された氏名等の固有文字列と伏字との対応データを、事例番号に関連付けて伏字情報ＤＢ26に格納する（Ｓ65）。

この伏字変換処理に際し、事例情報管理サーバ12は伏字情報ＤＢ26を参照し、伏字対象項目に入力された文字列が既に伏字化された文字列と一致する場合には（Ｓ62）、新たな伏字を割り当てることなく、当該文字列を既存の伏字に置き換える（Ｓ63）。
例えば、「鈴木一郎」の文字列は入力データ中に何度も登場しているが、事例情報管理サーバ12は同一人物と判断して統一的な伏字を割り当てる。

また、フリーフォーマットで記述される「作業手順」や「内容」の項目への入力文字をもチェックし、その中に伏字対象項目に記述された文字列と同一の文字列が含まれている場合（Ｓ66）、事例情報管理サーバ12はこれらについても自動的に対応の伏字に置き換える（Ｓ67）。
なお、連絡先１〜５の電話番号や住所に記述された文字列については、伏字にするまでもなく、入力完了時点で破棄される。

上記のように、このシステム10によれば、入力画面34中に今回の事例において最低限遂行すべき作業手順が列挙されているため、緊急事態発生時においても一般社員は迷うことなく必要な処理を遂行可能となる。
同時に、各作業手順の日時、行動主体、場所、対象者、内容を入力していくことで、時系列に沿った記録が残る仕組みであるため、事件や事故が終結した後に改めて報告書を作成する手間を省くことが可能となる。

事例情報ＤＢ24に蓄積された事例情報は他の社員の閲覧に供され、緊急事態発生時における生きた教材として利用される。以下、図１１のフローチャートに従い、事例情報の公開手順について説明する。

まず、過去の事例情報の閲覧を希望する社員は、自己のクライアント端末16から事例情報管理サーバ12にアクセスし、事例の閲覧をリクエストする。これを受けた事例情報管理サーバ12は（Ｓ70）、ID／パスワードの入力画面（図示省略）をクライアント端末16に送信し（Ｓ72）、当該社員のID及びパスワードの入力を促す。

クライアント端末16からID及びパスワードが送信されると（Ｓ74）、事例情報管理サーバ12は認証ＤＢ27を参照して当該ID及びパスワードが正しいことを確認すると同時に、当該社員の閲覧権限を取得する（Ｓ76）。つぎに事例情報管理サーバ12は、事例情報ＤＢ24に格納された事例の選択画面をクライアント端末16に送信する（Ｓ78）。
図示は省略したが、この選択画面には、例えば事例の分類毎に事例番号と登録年月日がリスト表示されると共に、検索ボックスが設けられている。

ここで社員が検索ボックスに「倒れ」や「入院」のキーワードを入力し、検索ボタンをクリックすると、クライアント端末16から事例情報管理サーバ12に対して検索リクエストが送信される。
これを受けた事例情報管理サーバ12は（Ｓ80）、入力されたキーワードを含む事例情報の事例番号が列記された検索結果のリスト画面を生成し、クライアント端末16に送信する（Ｓ82）。

この中から社員が「事例番号：１２５６３２」を選択すると、クライアント端末16から事例情報管理サーバ12に「事例番号：１２５６３２」の選択データが送信される。
この選択データを受信した事例情報管理サーバ12は（Ｓ84）、事例情報ＤＢ24から該当の事例情報を抽出する（Ｓ86）。

つぎに事例情報管理サーバ12は、この社員が完全閲覧権限を保有している場合には（Ｓ90／Y）、伏字情報ＤＢ26を参照して当該事例に関連付けられた伏字情報を取得し、伏字を元の文字列に変換する（Ｓ92）。
つぎに事例情報管理サーバ12は事例情報表示画面を生成し、クライアント端末16に送信する（Ｓ94）。この結果、図示は省略したが、クライアント端末16のディスプレイには、伏字が元の文字列に変換された事例情報が表示される。

これに対し、この社員が完全閲覧権限を保有していない場合（Ｓ90／N）、事例情報管理サーバ12は伏字を元の文字列に変換することなく、伏字をそのまま表示させた事例情報表示画面を生成し、クライアント端末16に送信する（Ｓ94）。

図１２は、この事例情報表示画面60を示すものであり、必須の作業手順及び追加的に実施された作業が時系列に沿って表示されている。これを閲覧することにより、他の社員は自社において実際に発生した事件や事故の概要を認識できると共に、時々刻々と進展する緊迫した対応ぶりを参照することにより、平時において緊急時対応のシミュレーションを行うことが可能となる。

また、事例情報ＤＢ24に記録されているデータについて、個人の氏名はもちろん、個人の特定につながる所属や場所についても原則として伏字に変換されているため、個人情報が有効に保護された状態で、一般社員に対して緊急時対応のストーリーのみを開示できる。
事例情報ＤＢ24には、このような自由度の高い閲覧性がありながら、個人を特定する情報はすべて伏字化されて記録されているため、この事例情報ＤＢ24中のテキストデータを如何に検索しようとも、このような情報を原理的に発見できず、強固なセキュリティ機能を有している。
なお、セキュリティ性をより向上させるためには、伏字情報ＤＢ26と事例情報ＤＢ24とを物理的に分離させることが望ましい。

このシステム10の場合、上記のように入力画面34中の特定の入力項目が予め伏字対象項目として設定されており、ここに入力された文字列は、「内容」などの非伏字対象項目中に出現する場合も含め、原則として自動的に伏字に変換される仕組みであるため、テキストマイニングなどの高度な言語解析アルゴリズムを用いることなく、要秘匿文字列を伏字に変換できる利点がある。

また、このシステム10によれば、通常は人事情報ＤＢ20にアクセスできない一般社員であっても、人事部に連絡して個別にアクセス権を設定してもらうことにより、事例情報管理サーバ12経由で人事情報ＤＢ20に格納された対象者の連絡先情報を入力画面34において参照可能となるため、緊急時に連絡先がわからずに右往左往することを有効に回避できる。

なお、上記の例では「誰から」及び「誰に」中の「第三者」については伏字変換対象項目として設定されていないが、ここには「駅員」や「警官」などの抽象的な人物名を記載することが事前にルール化されているため、特に問題はない。
もっとも、「第三者」も伏字変換対象項目として設定しておくと共に、この項目には個人名を記載するようにルール化しておくことも可能である。

この発明に係る事例情報管理システムの全体構成図である。事例情報入力時の処理手順を示すフローチャートである。事例情報入力時の処理手順を示すフローチャートである。分類パターンの選択画面を示す図である。事例情報入力画面を示す図である。事例情報入力画面を示す図である。事例情報入力画面を示す図である。事例情報の入力例を示す図である。伏字変換処理の詳細手順を示すフローチャートである。伏字情報ＤＢの登録例を示す図である。事例情報公開時の処理手順を示すフローチャートである。事例情報表示画面を示す図である。

符号の説明

10 事例情報管理システム
12 事例情報管理サーバ
14 人事情報管理サーバ
16 クライアント端末
18 ネットワーク
20 人事情報ＤＢ
22 テンプレートＤＢ
24 事例情報ＤＢ
26 伏字情報ＤＢ
27 認証ＤＢ
30 分類パターンの選択画面
32 「送信」ボタン
34 入力画面
36 経過入力欄
37 作業手順項目
38 「対象者氏名」の入力項目
39 「日時」の入力項目
40 「誰から」の入力項目
41 「誰から／第三者」の入力項目
42 「誰から／社員」の入力項目
43 「何処で」の入力項目
44 「何処で／固有名詞」の入力項目
45 「何処で／施設種」の入力項目
46 「誰に」の入力項目
47 「誰に／社員」の入力項目
48 「内容」の入力項目
50 「一時保存」ボタン
51 「編集可能者の追加」ボタン
52 「次頁」ボタン
54 「連絡先補充」ボタン
56 「行の追加」ボタン
58 「入力完了ボタン」ボタン
60 事例情報表示画面

Claims

緊急事態の分類パターンに応じて予め用意された複数のテンプレートを格納しておくテンプレート記憶手段と、
緊急事態の分類パターンの選択画面をクライアント端末に送信する手段と、
クライアント端末から分類パターンの選択データが送信された場合に、対応のテンプレートを反映させた入力画面をクライアント端末に送信する手段と、
クライアント端末から送信された入力データを、事例番号に関連付けて事例情報記憶手段に格納する事例情報登録手段と、
クライアント端末から特定の事例情報の表示リクエストが送信された場合に、該当の事例情報を抽出し、当該クライアント端末に送信する事例情報送信手段とを備えた事例情報管理システムであって、
上記入力画面には、当該緊急事態の発生時に実行すべき作業手順が列挙されており、
各作業手順には、実行日時、実行主体、実行内容等の入力項目が設けられていることを特徴とする事例情報管理システム。
上記入力画面に設けられた入力項目の中、特定の入力項目は予め伏字対象項目として設定されており、
クライアント端末から送信された入力データの中、この伏字対象項目に入力された文字列を自動的に抽象的な伏字に変換する手段と、
他の入力項目中に上記伏字対象項目に入力された文字列と同一の文字列が存在する場合、これを上記と同一の伏字に変換する手段とを備え、
上記事例情報登録手段は、伏字に変換された状態の入力データを上記事例情報記憶手段に格納し、
上記事例情報送信は、伏字に変換された状態の事例情報をクライアント端末に送信することを特徴とする請求項１に記載の事例情報管理システム。
伏字対象項目に入力された文字列と伏字との対応関係を、事例番号に関連付けて伏字情報記憶手段に格納する伏字情報登録手段と、
特定のユーザIDについて予め完全閲覧権限を設定しておく記憶手段と、
クライアント端末から送信されたユーザIDに基づいて、当該ユーザが完全閲覧権限を保有しているか否かを判定する手段と、
当該ユーザが完全閲覧権限保有者である場合に、上記伏字情報記憶手段を参照し、各伏字に関連付けられた元の文字列を取得する手段と、
上記事例情報中の伏字を元の文字列に変換する手段とを備え、
上記事例情報送信手段は、この変換後の文字列を含む事例情報をクライアント端末に送信することを特徴とする請求項２に記載の事例情報管理システム。
上記入力画面には、緊急事態の当事者の氏名を入力する項目と、
この当事者の連絡先を表示する項目が設けられており、
クライアント端末から送信された当事者の氏名をキーに人事情報データベースを検索し、この当事者の連絡先データを取得する手段と、
この連絡先データを上記の表示項目に補充させた入力画面を生成し、クライアント端末に送信する手段と、
を備えたことを特徴とする請求項１〜３の何れかに記載の事例情報管理システム。
コンピュータを、
緊急事態の分類パターンに応じて予め用意された複数のテンプレートを格納しておくテンプレート記憶手段、
緊急事態の分類パターンの選択画面をクライアント端末に送信する手段、
クライアント端末から分類パターンの選択データが送信された場合に、対応のテンプレートを反映させた入力画面をクライアント端末に送信する手段、
クライアント端末から送信された入力データを、事例番号に関連付けて事例情報記憶手段に格納する事例情報登録手段、
クライアント端末から特定の事例情報の表示リクエストが送信された場合に、該当の事例情報を抽出し、当該クライアント端末に送信する事例情報送信手段として機能させるプログラムであって、
上記入力画面には、当該緊急事態の発生時に実行すべき作業手順が列挙されており、
各作業手順には、実行日時、実行主体、実行内容等の入力項目が設けられていることを特徴とする事例情報管理プログラム。