(57)【要約】【課題】安全報告書の作成を円滑に進め、かつ、安全報告書のデータをデータベースに確実に蓄積させる安全報告書作成支援技術を提供する。【解決手段】安全管理者１７０が所定の項目の入力を行い安全月報を作成すると、安全報告書管理部１１０は、事例報告書管理部１６０より、その月のヒヤリハットの提出状況に関する情報を取得し、これに基づいて、事例報告書管理部１６０に提出されたヒヤリハットに対する措置の実施状況を把握する。また、ヒヤリハット提出件数が所定の基準に満たない者に対する措置の実施状況を把握する。これらの措置が完了されている場合、安全報告書管理部１１０は、後述する承認作業に移行する。措置が未完了の場合、安全報告書管理部１１０は、安全報告書の入力者である安全管理者１７０に対して必要な措置を行うよう促す。【選択図】  図１
2004234569.tif 000002
【特許請求の範囲】
【請求項１】
安全活動に関する安全報告書の入力依頼を受け付け、該安全報告書の作成を支援するとともに、作成された安全報告書を登録または承認する安全報告書管理部と、
事故事例、または、事故には至らなかったが事故になった可能性のある事例を報告する事例報告書の作成を支援するとともに、作成された事例報告書を格納する事例報告書管理部と、
を備え、
前記安全報告書管理部が前記安全報告書の入力依頼を受け付けたとき、前記安全報告書管理部または前記事例報告書管理部が、前記事例報告書管理部に提出された前記事例報告書に対する措置または事例報告書提出件数が所定の基準に満たない者に対する措置の実施状況を把握し、措置が未完了の場合、前記安全報告書管理部における前記安全報告書の登録または承認を中断するとともに前記安全報告書の入力者に対して必要な措置を行うよう促し、措置が完了されている場合、前記安全報告書管理部において前記安全報告書の登録または承認を行うことを特徴とする書類作成支援システム。
【請求項２】
請求項１に記載の書類作成支援システムにおいて、前記事例報告書管理部は、措置の必要な事例を識別して格納する事例記憶部を有し、前記安全報告書管理部は、前記事例記憶部から、措置の必要な事例報告書の存否に関する情報を取得することを特徴とする書類作成支援システム。
【請求項３】
請求項１または２に記載の書類作成支援システムにおいて、前記安全報告書は、所定期間ごとに作成を義務づけられているものであることを特徴とする書類作成支援システム。
【請求項４】
請求項１乃至３いずれかに記載の書類作成支援システムにおいて、前記安全報告書管理部は、前記措置が必要な場合、前記安全報告書の入力者に対して必要な措置を行うよう促すとともに、前記安全報告書に対し、実施した措置の内容を追記することを要求することを特徴とする書類作成支援システム。
【請求項５】
請求項１乃至４いずれかに記載の書類作成支援システムにおいて、ネットワークを介して安全管理者および作業者と接続しており、前記安全管理者は、前記安全報告書管理部にアクセスして前記安全報告書を作成し、前記作業者は、事例報告書管理部にアクセスして前記事例報告書を作成することを特徴とする書類作成支援システム。
【請求項６】
請求項１乃至５いずれかに記載の書類作成支援システムにおいて、前記安全報告書管理部は、作成された安全報告書を構成する報告書情報を電子的に保存する報告書情報記憶部と、前記報告書情報記憶部に保存された報告書情報を、要求に応じて安全報告書作成者に提示する情報提示部と、安全報告書作成者から所定の報告書情報の入力を受け付け、入力が完了したとき、該報告書情報に基づいて安全報告書を作成するとともに、該報告書情報を前記報告書情報記憶部に記憶させる安全報告書作成部と、を備えることを特徴とする書類作成支援システム。
【請求項７】
請求項１乃至６いずれかに記載の書類作成支援システムにおいて、作成された安全報告書を承認者に提示する安全報告書提示部と、承認者に提示した前記安全報告書についての承認を受け付ける承認部とをさらに備えることを特徴とする書類作成支援システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、安全活動を推進するための文書の作成を支援するシステムに関するものである。
【０００２】
【従来の技術】
事故や災害を防止するための安全活動は、様々な事業活動の基盤をなすものであり、従来、安全活動の活性化を図る試みが種々行われてきた。そうした試みの一つに、事故や災害には至らずとも「ヒヤリ」としたり「ハット」したりした事例を記載する「ヒヤリハット」や、これに類した事例報告書を作業者等に提出させる制度がある。
【０００３】
事故や災害として表面に現れてくる件数は氷山の一角で、水面下には、事故に至らなかった数々の事例がある。よく知られているハインリッヒの法則によると、重大事故が１件発生したとすると、小規模の事故が２９件発生しており、さらにその陰には、作業者が「ヒヤリ」「ハット」とするような不安全状態が、３００件発生していることになる。したがって、ヒヤリハット活動を活性化し、「ヒヤリ」「ハット」とする状態をなくすことが、事故防止につながる重要な安全対策となる。
【０００４】
しかしながら、ヒヤリハット活動はともすれば形骸化する傾向があり、次第に提出件数が少なくなることが多かった。また、提出されたヒヤリハットについてその対策に関し充分な検討がなされず、折角抽出された設備や作業上の問題点が解決されないまま放置されるケースが多かった。
【０００５】
また、ヒヤリハットの特徴は作業者自身が自ら経験した事例を報告するところにあるため、作業者が自覚できる動作的な事例（滑った・ころんだ）ばかりが集まりやすい。したがって、提出されたヒヤリハットを活用して有効な安全活動に結びつけるためには、ヒヤリハットに記載された事例の本質を充分に分析し、その事例の裏に潜む問題点を明確にした上で対策を講じることが重要となる。
【０００６】
こうした問題を解決するためには、安全管理者が、ヒヤリハットの提出件数の少ない人あるいはグループに対し提出を促すようにしたり、提出されたヒヤリハットを充分に検討する仕組みを作ることが重要である。
【０００７】
ところが、従来、ヒヤリハットは紙の形態で作成、保存されていた。このためヒヤリハット事例報告書は膨大な量になり、保管コストがかさむ上、その利用はきわめて困難なものとなっていた。
【０００８】
このような問題を解決するため、ヒヤリハットや災害事例事例報告書をデータベース化する試みも行われている。特許文献１には、事故事例をデータベースに入力し保管するシステムが記載されている。しかしながら、こうしたデータベース化の試みの多くは、データの蓄積がなかなか進まない、という共通の課題を有していた。ヒヤリハットは、自己の失敗体験を公表する側面があり、自ら積極的にヒヤリハットを提出することは、本来的には少ない。したがって、ヒヤリハット事例報告書の記載の手間を減らすことにより提出を促すだけでは充分でなく、ヒヤリハット提出の少ない人やグループに対するフォローが必要である。
【０００９】
また、ヒヤリハットをデータベース化しても、そのデータを定期的に活用し、日々の安全活動にフィードバックするシステムが必要である。ヒヤリハットのデータが順調に蓄積されるようになると、その対策を速やかに行うことが非常に重要となる。対策検討をいったんやらなくなると、未対策ヒヤリハットが雪だるま式に増加し、処置が困難な状態となる。
その他、従来のヒヤリハットには以下の問題があった。第一に、勉強会等で一連のヒヤリハットを作業員に伝えても、その場では理解しても頭に残りにくかった。また、作業前に関連するヒヤリハットを迅速に見つけだすことが困難であった。また、通常、ヒヤリハットは一枚にまとめられていることが通常であるが、それでも情報量が多すぎるため、作業員は作業前にすべてを読むことは少ない。
【００１０】
【特許文献１】
特開平１０−１０５５６７号公報
【００１１】
【発明が解決しようとする課題】
本発明は上記事情に鑑みなされたものであって、その目的は、ヒヤリハットの提出を促すとともに、提出されたヒヤリハットの対策、フォローを確実に実行させるシステムを提供することにある。
【００１２】
【課題を解決するための手段】
本発明によれば、安全活動に関する安全報告書の入力依頼を受け付け、該安全報告書の作成を支援するとともに、作成された安全報告書を登録または承認する安全報告書管理部と、
事故事例、または、事故には至らなかったが事故になった可能性のある事例を報告する事例報告書の作成を支援するとともに、作成された事例報告書を格納する事例報告書管理部と、
を備え、
前記安全報告書管理部が前記安全報告書の入力依頼を受け付けたとき、前記安全報告書管理部または前記事例報告書管理部が、前記事例報告書管理部に提出された前記事例報告書に対する措置または事例報告書提出件数が所定の基準に満たない者に対する措置の実施状況を把握し、措置が未完了の場合、前記安全報告書管理部における前記安全報告書の登録または承認を中断するとともに前記安全報告書の入力者に対して必要な措置を行うよう促し、措置が完了されている場合、前記安全報告書管理部において前記安全報告書の登録または承認を行うことを特徴とする書類作成支援システムが提供される。
【００１３】
ここで、事例報告書の例としては、前述のヒヤリハット等が挙げられる。
【００１４】
従来技術の項で述べたように、ヒヤリハットをはじめとする事例報告書は、ともすると提出件数が減少しがちになり、また、その対策がなおざりになりがちである。こうした課題に対応するため、本発明のシステムは、安全報告書を作成する際、事例報告書に対する措置または事例報告書提出件数が所定の基準に満たない者に対する措置が適正に行われているかどうかがチェックされ、措置が実施していなければ安全報告書作成業務が完了しないように構成されている。これにより、事例報告書の提出件数の減少を抑えるとともに提出された事例報告書の対策が確実に実施されるようになる。
【００１５】
本発明において、前記事例報告書管理部は、措置の必要な事例を識別して格納する事例記憶部を有し、前記安全報告書管理部は、前記事例記憶部から、措置の必要な事例報告書の存否に関する情報を取得するように構成することができる。かかる構成によれば、措置の必要な事例報告書を確実に把握できる。
【００１６】
本発明において、前記安全報告書は、所定の期間ごとに作成されるものとすることができる。たとえば安全月報等の定期安全報告書の類が例示される。こうした安全報告書の作成と事例報告書の管理を連動させることにより、事例報告書の管理が定期的に確実に実施されることとなり、安全活動をより一層活発化することが可能となる。
【００１７】
本発明において、前記安全報告書管理部は、前記措置が必要な場合、前記安全報告書の入力者に対して必要な措置を行うよう促すとともに、前記安全報告書に対し、実施した措置の内容を追記することを要求するように構成することができる。こうすることによって、事例報告書の内容が安全報告書に反映され、より一層、安全活動の推進を図ることができる。
【００１８】
本発明において、文書作成支援システムをネットワークを介して安全管理者および作業者と接続した構成とし、前記安全管理者は、前記安全報告書管理部にアクセスして前記安全報告書を作成し、前記作業者は、事例報告書管理部にアクセスして前記事例報告書を作成することができる。事例報告書は、設備や作業手順の点で改善すべき点についての指摘を含んでいる。こうした指摘に対応して、設備や作業手順の見直しを行い、改善を検討しておくことが重要となる。こうした対策の検討を、事例報告書提出者自らが実行しなければならない仕組みにすると、作業者は自分の労力が増大する心理的負担から事例報告書の提出を控えるようになり、事例報告書の提出件数が伸びず、安全活動は不活発なものとなる。また、提出された事例報告書について個別に対応するよりも、複数の事例報告書を分析してその対策を充分に検討する方がより効果的な場合も多い。特に、設備の改善等、コストを要するものは、このような方法で対策を検討することが重要である。したがって、安全管理者等のしかるべき担当者を決め、その者が、作業者により提出された事例報告書をいったん収集し、それらの分析、検討を行った上で設備や作業手順の改善を図ることが望ましい。上記構成によれば、こうした仕組みを好適に実現することができる。
【００１９】
本発明において、前記安全報告書管理部は、作成された安全報告書を構成する報告書情報を電子的に保存する報告書情報記憶部と、前記報告書情報記憶部に保存された報告書情報を、要求に応じて安全報告書作成者に提示する情報提示部と、安全報告書作成者から所定の報告書情報の入力を受け付け、入力が完了したとき、該報告書情報に基づいて安全報告書を作成するとともに、該報告書情報を前記報告書情報記憶部に記憶させる安全報告書作成部と、を備える構成とすることができる。
【００２０】
ここで報告書情報とは、安全報告書を構成する情報をいう。たとえば、安全報告書の要旨を含む文書情報、安全報告書の書誌情報、安全報告書に関連づけられたキーワード等が挙げられる。また、安全報告書の関連資料がある場合には、関連資料のリンク先情報を含んでいても良い。
【００２１】
上記構成によれば、安全報告書作成者が報告書情報を入力すると自動的に安全報告書が作成されるようになっているので、安全報告書の作成の労力が顕著に軽減される。また、予め定めた書式の安全報告書が作成されるため、担当者が異なっても統一した書式で読みやすい安全報告書が作成される。また、報告書情報に基づいて安全報告書が作成されるとともに、報告書情報がデータベースに記憶されるため、安全報告書作成とは別にデータベース入力のための手間をかける必要がない。したがって、担当者に余計な負担を強いることなく、データベースを円滑に構築していくことができる。
【００２２】
本発明において、安全報告書管理部が、安全報告書提示部および承認部をさらに備える構成とすることができる。このようにすれば、報告書情報をデータベースに保存する形式でなければ承認が得られないこととなるため、データベースへの報告書情報の入力がより一層確実になる。
【００２３】
以上、本発明の構成について説明したが、上記構成要素の任意の組合せや、上記表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【００２４】
【発明の実施の形態】
第一の実施の形態
以下、本発明の一実施形態について図面を参照して説明する。
【００２５】
図１は、本実施形態に係る書類作成支援システムの概略図である。
【００２６】
書類作成支援システム１００は、安全報告書管理部１１０、資料格納部１３０、文献格納部１４０及び事例報告書管理部１６０より構成されている。安全報告書管理部１１０は、安全管理者１７０が定期的に作成することを義務づけられている文書の作成支援及び文書保存を行う。本実施形態では、月々の安全活動の実施状況を報告する安全月報を例に挙げて説明する。
【００２７】
図１中、点線で囲まれた部分は、安全管理者１７０が毎月定期的に行う定型作業である。ここでは、安全管理者１７０が安全月報を作成し、これを出力し、関係者に配布するといったサイクルを示している。
【００２８】
安全月報作成にあっては、資料やカタログ等、技術文献等を参考資料として添付したい場合がある。そのようなときは、これらの文書やイメージのデータを、安全月報と関連づけた形で所定の記憶部に格納しておく。資料格納部１３０は、安全管理者１７０が安全月報を作成する際に収集した資料やカタログを格納する。また、文献格納部１４０は、安全報告書管理部１１０に格納された安全月報を作成する際に利用した技術文献や技術ジャーナル等が格納される。たとえば、再利用性の高いものを資料格納部１３０、文献格納部１４０に格納し、そうでない参考資料等は報告書にイメージファイル等で添付する。安全報告書管理部１１０、資料格納部１３０および文献格納部１４０に格納された資料や文献等のデータはそれぞれ相互に関連付けられ、過去の安全月報を閲覧したとき、リンク形式で各種資料、文献等が提示されるようになっている。資料やカタログのうち、他の事例にも共通しそうな（再利用性が高いと考えられる）ものは、資料格納部１３０、文献格納部１４０に格納し、ある事例に特有な（再利用性がほとんどない）ものは、これらに格納せず、事例報告書（事例ＤＢ）に格納することもできる。
【００２９】
以上は安全管理者１７０が使用する安全月報の作成支援部に関連した部分について説明した。これとは別に、書類作成支援システム１００内には、作業者１８０からのヒヤリハット提出を受け付ける事例報告書管理部１６０が設けられている。ヒヤリハットとは、事故には至らなかったが事故になった可能性のある事例を報告する事例報告書であり、「ヒヤリ」としたり「ハット」したりした事例を報告するものである。ここでは、職場の衛生を向上させるための改善提案や、実際に起こった事故事例等も含むものとする。作業者１８０は、例えば月に数件のヒヤリハット提出が義務付けられており、端末上で所定の項目を入力することにより、ヒヤリハット事例を事例報告書管理部１６０に入力する。ヒヤリハットの入力は、たとえば図２に示すフォーマットを作業者１８０の端末のディスプレイに表示し、所定の項目の入力によりヒヤリハットシートが入力されるようになっている。図２において、「フィードバック先」は、この登録された事例が、社内のどの部門にとって重要か、すなわち、どの部門に対してこの事例があったことをフィードバックするかを示すために使用する。
【００３０】
本実施形態では、図１における安全報告書管理部１１０および事例報告書管理部１６０が相互に提携し、作業者１８０によるヒヤリハットの提出を促進するとともに、安全管理者１７０によるヒヤリハットのフォローが確実に行われるようになっている。以下、この点について説明する。
【００３１】
安全管理者１７０が所定の項目の入力を行い安全月報を作成すると、安全報告書管理部１１０は、事例報告書管理部１６０より、その月のヒヤリハットの提出状況に関する情報を取得し、これに基づいて、以下の（ｉ）および（ｉｉ）について把握する。
【００３２】
（ｉ）事例報告書管理部１６０に提出されたヒヤリハットに対する措置の実施状況（ｉｉ）ヒヤリハット提出件数が所定の基準に満たない者に対する措置の実施状況
これらの実施状況を把握し、措置が完了されている場合、安全報告書管理部１１０は、後述する承認作業に移行する。措置が未完了の場合、安全報告書管理部１１０は、安全報告書の入力者である安全管理者１７０に対して必要な措置を行うよう促す。具体的には、その月の目標を達成していない作業者のリストが安全管理者１７０の端末に提示される。安全管理者１７０はその結果を受けて、該当する作業者に対してヒヤリハットの提出を促す。たとえば、書類作成システム１００を介して作業者１８０の端末にヒヤリハット提出を促す表示を行う。また、事例報告書管理部１６０は安全管理者１７０に対して、対策の必要なヒヤリハットを抽出し、その結果を直接または表示部を介して安全管理者１７０へ通知する。これらの通知は、安全管理者１７０の端末のディスプレイに表示することにより行われる。図３はこうした表示の一例である。
【００３３】
安全管理者１７０は、上記の結果を受け、適宜、それらのヒヤリハットに対する対応策を検討し、その内容を安全月報に書き加える。こうして、安全報告書管理部１１０及び事例報告書管理部１６０の連携により、安全月報の作成及びその月のヒヤリハットへの対策が完了すると、安全報告書管理部１１０は、承認部１２０を介して結果を出力する。出力の形式は、印刷物であってもよいし、電子ファイルを送出する形態でもよい。その結果は安全管理者１７０に送信されると共に、安全管理者１７０はその結果を関係者に配布するなどして、安全活動の徹底を図ることができる。
【００３４】
図４は、図１における安全報告書管理部１１０及び事例報告書管理部１６０の連携について詳細に説明するための図である。
【００３５】
安全月報作成にあたり、まず安全管理者１７０は、データベース検索部１１２を介して報告書情報ＤＢ１２４、個人情報ＤＢ１２６を含むデータベース１２７にアクセスし、過去に作成された安全月報を検索する（Ｔ１０１、Ｔ１０２）。これにより、過去の類似安全月報を参照しながら新規の安全月報を作成することができ、安全月報の作成の労力が大幅に軽減される。また前月以前の安全月報を参照することにより、前月までに立てた安全活動の推進計画に対し、実績がどの程度上がったかを確認することができる。また、他の部署における安全月報を参照して自分の部署の安全活動計画を進めていく上での参考にすることも可能である。検索にあたっては、文書作成日時、部署ＩＤ、キーワード等を利用することができる。本実施形態では、安全管理者１７０の端末のディスプレイに、図５に示す検索画面を提示し、所定のキーワードの入力を受け付け、検索を実行する。
【００３６】
ここで、図５の検索画面では、すべてのキーワードの選択肢が同一画面上に表示されている。従来の検索画面では、キーワードを入力者が自由に入力する形式や、プルダウンメニューにより候補が表示される形式、あるいは、大概念、中概念、小概念と順次、概念の広さが異なる選択窓が開き、その中からキーワードを選択する形式などが広く用いられていた。このような形式によれば、多種多様なキーワードにより検索を実行できるが、キーワードの入力が煩雑となるという課題があった。本発明の目的は、操作の簡便性に重点をおき、このような形態の検索画面としている。このようにすべてのキーワードが同一画面上に表示されていると、検索を何度か実行することにより、表示画面中のキーワードの位置が自然に把握され、視覚的効果により、キーワードを探し当てるまでの時間が大幅に短縮される。
【００３７】
ここで、上記検索画面において、選択したキーワードをワード群ＳＥＡＲＣＨ  ＷＯＲＤ欄に示すだけでなく、選択したキーワード自体の色を変えたり、カラムの色を反転表示させたりすることができる。このようにすれば、キーワード一覧から目を離さないで選択したキーワードを確認することができ、検索操作の効率が向上する。
【００３８】
つづいて、安全管理者１７０は、安全月報を構成する報告書情報を随時入力し、文書を作成していく。具体的には、図４において、安全管理者１７０が報告書作成部１１４へ報告書情報を入力し、報告書作成部１１４はこの情報をデータベース１２７へ格納する。ここで、安全月報を構成する報告書情報は、安全報告書の要旨を含む文書情報、安全報告書の書誌情報、安全報告書に関連づけられたキーワード等が含まれる。関連資料がある場合には、そのリンク先情報を含んでいても良い。なお、資料やカタログ等、技術文献等を参考資料として添付したい場合は、前述のように該当データを図１の資料格納部１３０、文献格納部１４０（図４では不図示）にそれぞれ格納する。
【００３９】
文書の要旨や関連資料は、所定の画面（不図示）から入力する。キーワードの登録は、図６に示すキーワード一覧画面で所望のキーワードを選択することにより行う。
【００４０】
安全月報を作成して入力し、さらにこの月報に関連づけるキーワードを登録することにより、現在作成中の安全月報を活用しやすいものにすることができる。図６の画面には図５で示した検索画面と同じキーワードが示されている。したがって、データ入力時と検索時でキーワードが一致し、検索効率が向上する。また、図６のキーワード登録画面においても、キーワードの全選択肢が一覧表示されているので、入力がきわめて容易となる。さらに、大概念、中概念、小概念と、概念の広さの異なるキーワードが同一画面に並列的に表示されているため、キーワード入力者に対し、異なるカテゴリーのキーワードを複数、入力することを促すことができる。
【００４１】
ここで、上記検索画面において、選択（付与）したキーワードの背景色を反転（色を変え）、自分が登録した案件にどのようなキーワードを付与したかを確認できるようにしてもよい。また、キーワード登録画面は、安全管理者用（安全管理者が使うキーワード群）と、作業員用（作業員が使うキーワード群）に大きく分け、キーワード群の基本背景色を違う色にしてもよい。なお、作業員（登録者）は、安全管理者用、作業員用どちらのキーワードも付与することができる。最終的には、安全管理者が作業員の登録したキーワードを選択してその事案に対するキーワードを確定する。もちろん、ログイン情報から判断するなどして、作業員が安全管理者用キーワードを入力させないことも可能である。これは、作業員に安全管理者側のキーワードを見せることによって、安全管理者側がどのような視点でヒヤリ・ハットを管理（利用）しようとしているかを気づかせ、作業員自身に他の視点を与えられ、新たな視点を与える効果がある。
【００４２】
図４にもどり、以上のようにして、安全月報の文書情報、キーワード等の所定のデータが、報告書作成部１１４を介してデータベース１２７に格納される（Ｔ１０３、Ｔ１０４）。
【００４３】
安全月報作成後、安全管理者１７０は、承認要求部１１６に対して、作成された安全月報の承認を求める（Ｔ１０５）。承認要求部１１６は、その承認要求を事例ＤＢ制御部１１８へ送出する（Ｔ１０６）。事例ＤＢ制御部１１８は、このデータを受け、事例報告書管理部１６０内にある事例ＤＢ１６４を参照し、対策の必要なヒヤリハットを抽出する（Ｔ１０７）。ここで事例ＤＢ１６４内には、図７の形式のデータが格納されている。各ヒヤリハットには、安全管理者１７０への通知要否に関する情報が含まれており、通知を要するものにはフラグ「１」が立てられている。このフラグは、たとえば、作業者がヒヤリハットを入力する際に付与し、その後、安全管理者が判断して「１」のままにするか「０」に変換するかを決定するようにしてもよい。事例ＤＢ制御部１１８は、このフラグの有無を認識して対策の必要なヒヤリハットを抽出する。なお、「１」のフラグは、対策が実施されその内容がシステムにアップされたとき、「０」に変換される。この点については後述する。
【００４４】
また、上記と同時に、承認要求部１１６は事例ＤＢ制御部１１８を介してヒヤリハット提出件数の目標未達成者のリストを取得する。そして、取得したリストを承認要求部１１６へ送出する。承認要求部１１６は、このデータを安全管理者１７０へ通知し、対策の実施及び完了報告の入力を促す。
【００４５】
安全管理者１７０は、これを受けて適宜、対策を実施する。具体的には、目標未達成者に対してヒヤリハットの提出を促すとともに、対策の必要なヒヤリハットについて設備改善やマニュアル変更等の対策を検討する。これらの対策のうち、大がかりな対策やコストの要する対策についてはある程度の期間をもって改善計画を策定する。これらの検討結果は安全月報の内容に追加し、報告書作成部１１４を介してデータベース１２７に格納する（Ｔ１０３、Ｔ１０４）。報告書作成部１１４は、アップロードされた内容を事例ＤＢ制御部１１８へ伝達し（Ｔ１５０）、事例ＤＢ制御部１１８は、該当ヒヤリハットを事例報告書管理部１６０から取得する。そして、そのヒヤリハットについて付与されていた対策要否に関わるフラグを「１」（要対策）から「０」（対策不要）に変換する。つづいて、事例ＤＢ制御部１１８から承認要求部１１６を介して安全管理者１７０へ、ヒヤリハットへの対策の登録が完了したことを通知する（Ｔ１０６、Ｔ１０５）。同様に、目標未達成者に関するデータについても、対策を実施したことを表すフラグを付与する。
【００４６】
ここで、ヒヤリハットについて付与されていた対策要否に関わるフラグを「１」（要対策）から「０」（対策不要）に変換するイベントとしては、対策が実際に現場で実施されたときに安全管理者が入力してフラグを０にする、安全対策を考えたことをもってフラグを０にする等が考えられる。
【００４７】
ここで、現場で対策が行われたらフラグを０にする方法だけでは、定修時にまとめて対策工事を行うなどの際、フラグが１のまま長期にわたって残ることになり、日々追加される事例との区別が難くなる場合がある。このような場合は、以下のような措置をとってもよい。まず、図２「対応」のチェックボックスで、登録者が対策の必要な事例を判断（現明細書で記載されているフラグを使用）する。ついで、対策を行うにあたって現場の工事が必要かを安全管理者が判断し、工事が必要なら新たに設けるフラグを１にする。この段階で、安全管理者が「対応」のチェックボックスのフラグを０にする（対策済みとなる）。工事が行われるときに、工事が必要な対策を抽出し、工事リストを作成・工事計画を行い、工事終了後工事対策必要のフラグを安全管理者が０にする。なお、この工事対策要否フラグを立てる画面は、安全管理者の取り扱う端末のみに表示させてもよい。
【００４８】
その後、前述の手順と同様にして、安全管理者１７０から承認要求部１１６へ承認要求が送信され、事例ＤＢ制御部１１８を介して事例報告書管理部１６０を参照することにより、その月に提出されたヒヤリハットに関する業務が完了したことを確認する。その後、業務完了確認された場合、承認要求部１１６から承認者１９０へ承認の入力依頼が送信される（Ｔ１０８）。対策が実施され完了安全報告書がなされるまでは、この入力依頼は送信されない。これを受け、承認者１９０は、承認部１２０に承認の入力を行う（Ｔ１０９）。承認部１２０は、承認された報告文書について、そのデータを出力部１２２へ送信し承認部１２０を介し安全月報の出力がなされる（Ｔ１１０）。なお、事例報告書管理部１６０内にある事例ＤＢ１６４へのデータの入力は、作業者１８０により入力部１６２を介して行われる（Ｔ１１１、Ｔ１１２）。
【００４９】
図８は、上述したシステムによる処理の流れを示す図である。はじめに、安全管理者により安全月報が作成され、システムにアップロードされる（Ｓ１０１）。次いで安全管理者から承認要求がなされる（Ｓ１０２）。この承認要求に対応して、システム側では、該当月間に提出されたヒヤリハットをチェックし、対策の必要なヒヤリハットの存否を確認する（Ｓ１０３）。対策の必要なヒヤリハットが存在する場合は、安全報告書の登録または承認を中断するとともに安全報告書の入力者に対して必要な措置を行うよう促す。ここでは、その対策を実施するよう安全管理者端末へ当該措置を要求する表示を行う（Ｓ１０４）。つづいて、システム側において、目標ヒヤリハット提出件数に満たない作業者の抽出を行う（Ｓ１０５）。該当者がいる場合、システムは、安全管理者に対しその者にヒヤリハットの提出を促すよう要求する（Ｓ１０６）。この要求を受けて安全管理者は目標件数に到達しない者にヒヤリハットの提出を求める。
【００５０】
対策の必要なヒヤリハットへの措置、目標ヒヤリハット提出件数に満たない作業者へのフォローが完了すると、システムから承認者へ承認の入力を求める通知を行い、これに対応して承認受付が登録される（Ｓ１０７）。以上により、安全月報の作成、登録が完了する。
【００５１】
本実施形態によれば、安全報告書を作成する際、事例報告書に対する措置または事例報告書提出件数が所定の基準に満たない者に対する措置が適正に行われているかどうかがチェックされ、措置が実施していなければ安全報告書作成業務が完了しないように構成されている。これにより、事例報告書の提出件数の減少を抑えるとともに提出された事例報告書の対策が確実に実施される。
【００５２】
また、本実施形態のシステムは、安全報告書管理部１１０、資料格納部１３０、文献格納部１４０及び事例報告書管理部１６０より構成されている。これらは、それぞれ異なるキャリアを有する者によりデータ入力されるため、様々な分野の知を結集したデータベース群が無理なく構築し、知の共有を図ることができる。
【００５３】
第二の実施の形態
第一の実施の形態においては、事例報告書等に関する措置の状況により承認可否が行われていた。これに対し本実施形態では、安全報告書の入力のため、安全管理者１７０がシステムにログインした際、事例報告書等に関する措置の状況を判別し、これに基づいて安全報告書入力操作への移行の可否を行う。
【００５４】
図９は本実施形態に係るシステムの機能ブロック図である。安全管理者１７０が文書作成支援システムにログインすると、その情報が安全報告書管理部１１０内の入力受付部１２９に送信され（Ｔ１００）、つづいてこの情報が事例ＤＢ制御部１１８へ送出される（Ｔ１０６）。これを受けて事例ＤＢ制御部１１８は、事例報告書管理部１６０内にある事例ＤＢ１６４を参照し（Ｔ１０７）、対策の必要なヒヤリハットを抽出する。ここで事例ＤＢ１６４内には、図７の形式のデータが格納されている。各ヒヤリハットには、安全管理者１７０への通知要否に関する情報が含まれており、通知を要するものにはフラグ「１」が立てられている。事例ＤＢ制御部１１８は、このフラグの有無を認識して対策の必要なヒヤリハットを抽出する（Ｔ１０７）。なお、「１」のフラグは、対策が実施されその内容がシステムにアップされたとき、「０」に変換される。また、上記とあわせ、入力受付部１２９は事例ＤＢ制御部１１８を介してヒヤリハット提出件数の目標未達成者のリストを取得する。
【００５５】
以上のようにして取得したリストが、事例ＤＢ制御部１１８から入力受付部１２９へ送出される（Ｔ１０６）。入力受付部１２９は、このデータを安全管理者１７０へ通知し、対策の実施及び完了報告の入力を促す。そして、安全管理者１７０により対策が実施され完了報告がなされると（Ｔ１０３）、報告書作成部１１４による安全報告書作成が可能な状態となる。対策が実施され完了安全報告書がなされるまでは、報告書作成部１１４による安全報告書作成は禁止される。
【００５６】
本実施形態の構成によれば、安全報告書作成を開始するにあたりヒヤリハットへ必要な対策を完了していることが要求されるため、ヒヤリハットの提出を促進するとともに、提出されたヒヤリハットの対策、フォローを確実に実行させることができる。
【００５７】
以上、本発明の実施形態について説明した。これらの実施形態は例示であり、それら各構成要素や各処理プロセスの組み合わせに変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者には理解されるところである。
【００５８】
たとえば、上記実施の形態では、ヒヤリハット等に関する必要な措置の把握および安全管理者１７０への通知を安全報告書管理部１１０が実施する構成となっていたが、これらを図１０に示すように事例報告書管理部１６０が実施するようにしてもよい。この場合、たとえば図４のシステムにおける処理の手順は以下のようになる。安全管理者１７０が所定の項目を入力して安全月報を作成すると、安全報告書管理部１１０は、事例報告書管理部１６０にその月のヒヤリハットの提出状況について問い合わせる。これを受けて事例報告書管理部１６０はヒヤリハット提出状況を調査し、その結果を安全管理者１７０に通知する。これにより、その月の目標を達成していない作業者のリストが提示され、安全管理者１７０はその結果を受けて、該当する作業者に対してヒヤリハットの提出を促す。また、事例報告書管理部１６０は安全管理者１７０に対して、対策の必要なヒヤリハットを抽出し、その結果を安全管理者１７０へ通知する。これらの通知は、安全管理者１７０の端末のディスプレイに表示することにより行うようにする。
【００５９】
また、上記実施の形態では、事例報告書管理部１６０が事故事例も取り扱うものとしたが、事故事例については別途、管理部およびデータベースを設けることとしてもよい。この場合において、事故事例のデータベースと、図１における安全報告書管理部１１０、事例報告書管理部１６０とは、互いにリンクした構成とすることもできる。
【００６０】
なお、本発明のシステムは、工場、製造現場、医療現場、交通（バス、タクシー会社、鉄道）関係など、様々に適用することができる。
【００６１】
【発明の効果】
以上説明したように本発明によれば、ヒヤリハットの提出を促すとともに、提出されたヒヤリハットの対策、フォローを確実に実行させるシステムが提供される。
【図面の簡単な説明】
【図１】実施の形態に係るシステムの概略図である。
【図２】ヒヤリハットシートの一例を示す図である。
【図３】安全管理者へのヒヤリハット実績通知の一例を示す図である。
【図４】実施の形態に係るシステムの概略図である。
【図５】キーワード検索画面の一例を示す図である。
【図６】安全報告書入力画面の一例を示す図である。
【図７】事例ＤＢに格納されたデータ構造を示す図である。
【図８】実施の形態に係る書類作成手順の一例を示す図である。
【図９】実施の形態に係るシステムの概略図である。
【図１０】実施の形態に係るシステムの概略図である。
【符号の説明】
１００  書類作成支援システム
１１０  安全報告書管理部
１１２  データベース検索部
１１４  報告書作成部
１１６  承認要求部
１１８  事例ＤＢ制御部
１２０  承認部
１２２  出力部
１２４  報告書情報ＤＢ
１２６  個人情報ＤＢ
１２７  データベース
１２９  入力受付部
１３０  資料格納部
１４０  文献格納部
１６０  事例報告書管理部
１６２  入力部
１６４  事例ＤＢ
１７０  安全管理者
１８０  作業者
１９０  承認者
【図１】
2004234569.tif 000003
【図２】
2004234569.tif 000004
【図３】
2004234569.tif 000005
【図４】
2004234569.tif 000006
【図５】
2004234569.tif 000007
【図６】
2004234569.tif 000008
【図７】
2004234569.tif 000009
【図８】
2004234569.tif 000010
【図９】
2004234569.tif 000011
【図１０】
2004234569.tif 000012