JP2010039857A - 電子文書管理サーバ、電子文書管理システム及び電子文書更新方法 - Google Patents

Abstract

【課題】業務の流れに依存し難いプログラムで構築できる、電子文書管理サーバ、電子文書管理システム及び電子文書更新方法を提供する。
【解決手段】業務の流れ、とりわけ電子文書の更新と承認の流れをコマンドテーブルに記録して、プログラムから分離した。プログラムは端末から与えられるパラメータを、シナリオともいえるコマンドテーブルと照合して、その挙動を変える。
【選択図】図１

Description

本発明は、電子文書管理サーバ、電子文書管理システム及び電子文書更新方法に適用して好適な技術に関する。
より詳細には、電子文書に対して上長等が承認する仕組みを容易に構築できる、電子文書管理システムに関する。

近年、過重労働が原因の労働災害が社会的問題となっている。過重労働は心身の健康を大きく損ね、過労死や鬱病による自殺等の深刻な事態の原因となっている。
このような過重労働を未然に防ぐべく、労働安全衛生法第６６条の８が改正され、平成１８年４月１日に施行された。法改正の詳細は非特許文献１に示す厚生労働省のホームページに詳しい。

非特許文献１によれば、
「事業者は、（１）労働者の週４０時間を超える労働が１月当たり１００時間を超え、かつ、疲労の蓄積が認められるときは、労働者の申出を受けて、医師による面接指導を行わなければなりません。」
とある。また、
「事業者は、
（２）長時間の労働（週４０時間を超える労働が１月当たり８０時間を超えた場合）により疲労の蓄積が認められ、又は健康上の不安を有している労働者（申出を受けて実施）
または
（３）事業場で定める基準に該当する労働者
にも、面接指導を実施する、又は面接指導に準ずる措置を講じるよう努めなければなりません。」
とある。
以上のように、長時間残業者の申し出による産業医面接指導が、平成１８年４月１日より義務化された。

特開２００７−２７２７４６号公報 厚生労働省：改正労働安全衛生法〜平成１８年４月１日、施行〜:［２００８年６月４日検索］、インターネット＜URL:http://www.mhlw.go.jp/topics/bukyoku/roudou/an-eihou/060401.html＞

発明者は、産業医による面接指導を効率的に推進すると共に、長時間残業者が恒常的に生じる職場の問題点を解決するための仕組みを、システムとして実現することを試みた。
その際、従来なら紙の文書で問題点を解決するための計画を提出させ、これに承認印を押す、という業務の流れを、電子化する必要が生じた。
電子文書の承認の流れは、その仕組みに強く依存するため、どうしても業務の流れそのものをコーディングする必要がある。
このような背景で作成されるプログラムは、その業務の流れに専用のものである。このため、業務の流れが変わると、プログラムを改変する必要が生じる。

本発明はかかる点に鑑みてなされたものであり、業務の流れに依存し難いプログラムで構築できる、電子文書管理サーバ、電子文書管理システム及び電子文書更新方法を提供することを目的とする。

上記課題を解決するため、本発明による電子文書管理サーバは、電子文書テーブルと、電子文書テーブルの一のレコードを読み込んで端末に電子文書を表示させる電子文書表示部と、電子文書テーブルの一のレコードの指定されたフィールドの値を更新する電子文書更新部と、電子文書表示部の挙動を制御するパラメータ群を格納する表示コマンドテーブルと、電子文書更新部の挙動を制御するパラメータ群を格納する更新コマンドテーブルとを備えるものである。

業務の流れ、とりわけ電子文書の更新と承認の流れをコマンドテーブルに記録して、プログラムから分離した。プログラムは端末から与えられるパラメータを、シナリオともいえるコマンドテーブルと照合して、その挙動を変える。

本発明により、業務の流れに依存し難いプログラムで構築できる、電子文書管理サーバ、電子文書管理システム及び電子文書更新方法を提供できる。

［概要］
本発明の実施の形態を説明する前に、概要を説明する。
これより説明する長時間残業者健康管理システムは、社員が長時間残業を行ってしまった場合に、医師（産業医）が当該社員の健康状態を確認し、適切な指導或は措置を行うためのシステムである。

社員が残業超過状態に陥る原因は、社員本人の心がけよりも、社員が従事する職務と、これに関わる環境によることが多い。特に、慢性的な残業超過状態が続いている場合は、職場環境に問題がある場合が多い。
残業超過状態に陥った社員が所属する職場環境を改善するには、当該社員の直属の所属長である上司が、その作業に携わる必要がある。そして、その作業は、当該上司の所属長に当たる部署長と、人事部門と、産業医が共同で責任をもって対処する必要がある。
仮に、上司が残業を減らすことが叶わない場合は、それは上司だけの責任としてではなく、業務の分担や人員配置等の根本的な面でフォローしなければならない。

「職場環境の改善」という命題に対し、本実施形態の発明者は、生産管理や品質管理などの管理業務を計画どおりスムーズに進めるための概念である「ＰＤＣＡサイクル（plan-do-check-act cycle）」の思想を導入した。ＰＤＣＡサイクルとは、以下の手順を順次遂行するものである：
（１）計画書を作成し（plan）、
（２）計画書に沿って業務を遂行し（do）、
（３）業務が計画に沿って遂行されたか確認し（check）、
（４）業務が計画通り遂行されていなかった部分を調べて処置をする（act）。

本実施形態に係る長時間残業者健康管理システムでは、「改善依頼書」という電子文書を作成する。
産業医が残業超過社員と面談を行った結果、職場環境の改善を要すると判断したら、当該社員の上司に対し、改善依頼書を作成して当該上司に送付し、職場環境の改善を依頼する。
改善依頼書は、
・職場環境を改善するための「改善実施計画」を記す欄と、
・作成された「改善実施計画」に対し、部署長と人事担当部長、そして産業医が承認を行ったか否かを記録する欄と、
・承認された「改善実施計画」を実行した結果を報告するための「改善実施報告」を記す欄と、
・作成された「改善実施報告」に対し、部署長と人事担当部長、そして産業医が承認を行ったか否かを記録する欄
が設けられる。
つまり、担当者が計画書を作成した後、上司が当該計画書を精査して、承認印を押す、という手順を、電子化したものである。

以下、本発明の実施の形態を、図１〜図２０を参照して説明する。

［システム構成］
図１は、本発明の実施形態の例である、長時間残業者健康管理システムの概略図である。
長時間残業者健康管理システム１０１は、
・長時間残業者健康管理サーバ（以下「健康管理サーバ」）１０２と、
・これに接続される複数の端末１０３ａ、１０３ｂ、１０３ｃ、１０３ｄ及び１０３ｅと、
・そして端末に対してメールを送信するメールサーバ１０５と、
・これらを相互に接続する、甲会社の社内に敷設されているＬＡＮ１０６
よりなる。

健康管理サーバ１０２に接続する端末１０３ａ、１０３ｂ、１０３ｃ、１０３ｄ及び１０３ｅは、その使用者によって四種類に大別される。
対象社員乙１０７は、甲会社の社員である。対象社員乙１０７は、甲会社の就業規則で規定されている勤務時間を超えた勤務を行った結果、残業時間が既定の基準を超えてしまった（以下「超過残業」と呼ぶ）。このことを健康管理サーバ１０２が検出し、その結果として対象社員乙１０７は健康管理サーバ１０２にアクセスせざるを得なくなる。
なお、本実施形態の説明中、超過残業を行った社員を「対象社員」と呼ぶ。

上司丙１０８は、対象社員乙１０７の上司である。上司丙１０８は、上司丙１０８の部下である対象社員乙１０７が超過残業を行ってしまった結果、対象社員乙１０７が健康管理サーバ１０２にアクセスすること等を、健康管理サーバ１０２を通じて監視せざるを得なくなる。

部署長丁１０９は、上司丙１０８の上司である。つまり、対象社員乙１０７の上司の上司に当たる。
部署長丁１０９は、部署長丁１０９の部下である上司丙１０８が、後述する改善依頼書に改善実施計画を書いた際、その内容を審査する立場にある。

人事担当部長戊１１０は、甲会社の人事部門の部署長である。つまり、甲会社の人事に対して総括的な責任を負う立場である。
人事担当部長戊１１０は、上司丙１０８が、後述する改善依頼書に改善実施計画を書いた際、部署長丁１０９と共にその内容を審査する立場にある。

産業医己１１１は、甲会社の業務委託を受けている医師である。甲会社に勤務する社員の健康状態を監視し、必要であると判断した際には、対象社員或はその上司等に、健康状態を回復させるための具体的な指示を発する。
特に、産業医己１１１は、上司丙１０８が、後述する改善依頼書に改善実施計画を書き、部署長丁１０９と人事担当部長戊１１０がその内容を審査した後、最終的に当該改善実施計画を承認或は否認する立場にある。

健康管理サーバ１０２は、上述の五者の接続要求に対応し、その立場の相違に従って異なるユーザインターフェースを提供する。

健康管理サーバ１０２はネットワークＯＳが稼動するコンピュータである。
メールサーバ１０５もネットワークＯＳが稼動するコンピュータであり、周知のメール配信ソフト（ＭＴＡ: Mail Transfer Agent）が稼動している。
各端末１０３ａ、１０３ｂ、１０３ｃ、１０３ｄ及び１０３ｅもネットワークＯＳが稼動するコンピュータであり、一般的なパソコンである。
特に、健康管理サーバ１０２はｗｅｂサーバの機能を備えると共に、各端末１０３ａ、１０３ｂ、１０３ｃ、１０３ｄ及び１０３ｅはｗｅｂサーバである健康管理サーバ１０２にアクセスするためのｗｅｂブラウザがインストールされている。
ＬＡＮ１０６は周知のＴＣＰ／ＩＰプロトコルのパケットを通過させるネットワークを構成する。

［電子書類の流れ］
健康管理サーバ１０２が取り扱う電子書類に対する、処理の流れの概略を説明する。
図２（ａ）、（ｂ）及び（ｃ）は、セルフチェック票の処理の流れを説明する概略図である。
セルフチェック票２０２は、超過残業を行った社員に対し、均等に配布される。
図２（ａ）は、健康管理サーバ１０２によって対象社員乙１０７にセルフチェック票２０２が配布された様子を示す。対象社員乙１０７は端末１０３ａを操作して、セルフチェック票２０２を端末１０３ａの表示画面に表示する。実際は、セルフチェック票２０２はｈｔｍｌ文書であり、ｗｅｂブラウザによって表示される。
セルフチェック票２０２は対象社員に健康状態を詳細に調査するための質問が列挙されている。セルフチェック票２０２はいわばアンケート用紙である。対象社員乙１０７はこのセルフチェック票２０２に記される質問に回答を入力する。

図２（ｂ）は、アンケートに対する回答、すなわち入力を済ませた対象社員乙１０７のセルフチェック票２０２を、産業医己１１１が端末１０３ｅで閲覧している様子を示す。産業医己１１１は、対象社員乙１０７による当該セルフチェック票２０２の回答内容と、対象社員乙１０７の過去の残業時間の推移、また過去のセルフチェック票２０２の内容を参照して、面接の実施を行うか否かを決定する。決定した結果は端末１０３ｅを通じて健康管理サーバ１０２内に保存されている当該セルフチェック票２０２に記録され、電子メール（以下「メール」）で対象社員乙１０７に通知される。

図２（ｃ）は、産業医己１１１が面接の実施を決定した結果、産業医己１１１と対象社員乙１０７が面接を行っている様子を示す。面接と記しているが、実質的には医師の診察とほぼ等しい行為であり、産業医己１１１は対象社員乙１０７の疲労の蓄積度や様々な症状の有無、そしてそれらの進行の度合いの確認を行う。

図３（ａ）、（ｂ）及び（ｃ）は、産業医己１１１による、面接終了後の処理の流れを説明する概略図である。
図３（ａ）は、端末１０３ｅ上で稼動するｗｅｂブラウザ３０２に表示される、対象社員乙１０７のセルフチェック票２０２を示す図である。
産業医己１１１は、面接終了後に端末１０３ｅの表示画面に表示されるｗｅｂブラウザ３０２を操作し、対象社員乙１０７のセルフチェック票２０２をｗｅｂブラウザ３０２に表示する。この状態で、ｗｅｂブラウザ３０２内にはセルフチェック票２０２を表示している部分の上側に、「面接指導結果報告書作成」ボタン３０３がある。産業医己１１１は、マウス等のポインティングデバイスでこの「面接指導結果報告書作成」ボタン３０３を押すことで、面接指導結果報告書３０４を作成し、面接の結果判定した結論を記入する。

図３（ｂ）は、端末１０３ｅ上で稼動するｗｅｂブラウザ３０２に表示される、対象社員乙１０７の面接指導結果報告書３０４を示す図である。
前述の通り、産業医己１１１は、端末１０３ｅの表示画面に表示されるｗｅｂブラウザ３０２を操作し、「面接指導結果報告書作成」ボタン３０３を押すことで、面接指導結果報告書３０４を新規に作成し、ｗｅｂブラウザ３０２に表示する。
面接指導結果報告書３０４の中には、面接の結果を入力するための、二つの入力項目がある。
「事後措置として指導勧告の必要性」欄３０５と「上司への注意事項要望事項の必要性」欄３０６は、共にラジオボタンである。これらの欄には「不要」と「要」のいずれかを選択するラジオボタンが設けられている。産業医己１１１は、これらラジオボタンをマウス等のポインティングデバイスで選択入力を行う。
「事後措置として指導勧告の必要性」欄３０５と「上司への注意事項要望事項の必要性」欄３０６が共に「不要」である場合は、対象社員乙１０７に健康上の問題や懸念が見受けられなかったことを示す。したがって、この後面接指導結果報告書３０４が対象社員乙１０７と上司丙１０８に送付される以外、特別な作業は発生しない。

「事後措置として指導勧告の必要性」欄３０５が「不要」に選択され、「上司への注意事項要望事項の必要性」欄３０６が「要」に選択される場合は、対象社員乙１０７に健康上の問題や懸念がやや見受けられたことを示す。つまり、要注意状態である。健康管理サーバ１０２では、この状態をサッカーのルールでいう「イエローカード」状態と認識し、後述する健康管理サーバ１０２内のセルフチェックテーブルに記録する。

「事後措置として指導勧告の必要性」欄３０５が「要」に選択され、「上司への注意事項要望事項の必要性」欄３０６が「不要」に選択される場合は、対象社員乙１０７に健康上の問題や懸念が強く見受けられたことを示す。つまり、喫緊の対応を要する状態である。健康管理サーバ１０２では、この状態をサッカーのルールでいう「レッドカード」状態と認識し、後述する健康管理サーバ１０２内のセルフチェックテーブルに記録すると共に、改善依頼書の発行を実行する。

図３（ｃ）は、端末１０３ｅ上で稼動するｗｅｂブラウザ３０２に表示される、対象社員乙１０７の面接指導結果報告書３０４を示す図である。
図３（ｃ）では、産業医己１１１が、端末１０３ｅの表示画面に表示されるｗｅｂブラウザ３０２を操作し、ｗｅｂブラウザ３０２に表示されている面接指導結果報告書３０４の「事後措置として指導勧告の必要性」欄３０５を「要」に、「上司への注意事項要望事項の必要性」欄３０６を「不要」に選択した後の状態を示す。
この時、面接指導結果報告書３０４を表示しているｗｅｂブラウザ３０２の上側に、「改善依頼書作成」ボタン３０７が現れる。
「改善依頼書作成」ボタン３０７を押すと、改善依頼書が作成される。改善依頼書の詳細は後述する。

ここで、残業超過を行った社員は、産業医によって四つの組に分類される。
一つは、産業医がセルフチェック票２０２の内容を見たところ、面接は不要であると判定された社員である。面接が実施されないので、面接指導結果報告書３０４は作成されない。

もう一つは、産業医がセルフチェック票２０２の内容を見たところ、面接を要すると判定され、実際に面接を行ったところ、特に健康上の問題点は見出せなかった社員である。面接が実施されたので、異常が見受けられなかった旨の内容が記された面接指導結果報告書３０４が作成され、当該社員及びその上司に送付される。

もう一つは、産業医がセルフチェック票２０２の内容を見たところ、面接を要すると判定され、実際に面接を行ったところ、健康上の問題点がやや見受けられた社員である。これが前述の「イエローカード」である。面接が実施されたので、やや異常が見受けられた旨の内容と、上司に対して注意すべきであるとする旨のメッセージが記された面接指導結果報告書３０４が作成され、当該社員及びその上司に送付される。

そして最後の一つは、産業医がセルフチェック票２０２の内容を見たところ、面接を要すると判定され、実際に面接を行ったところ、喫緊に対応すべき健康上の問題点が見受けられた社員である。これが前述の「レッドカード」である。面接が実施されたので、異常が見受けられた旨の内容が記された面接指導結果報告書３０４が作成され、当該社員及びその上司に送付される。そして、これに留まらず、改善依頼書が別途作成され、上司に送付される。
つまり、改善依頼書は対象社員が産業医によって「レッドカード」と判定された時にのみ作成される。

以上の説明より、健康管理サーバ１０２は、三種類の電子文書を作成する。
一つはセルフチェック票２０２である。残業超過を行った対象社員全員に配布される、電子アンケート用紙である。
もう一つは面接指導結果報告書３０４である。残業超過を行った対象社員のうち、産業医が面接をすべきと判断し、実際に面接を行った結果、作成される報告書である。
そして、もう一つは改善依頼書である。残業超過を行った対象社員のうち、産業医が面接をすべきと判断し、実際に面接を行った結果、特に喫緊の対応を要すると産業医が判定した社員について、その上司に当該社員の労働環境の改善を申し入れるための依頼書である。

図４は、改善依頼書の概略図である。
「対象者情報」欄４０３は、対象社員の氏名、所属等の事項が列挙されている箇所である。
「就業上の措置で改善すべきこと」欄（以下「改善欄」）４０４は、産業医が対象社員の上司に対し、改善すべき項目を文章で記入する項目である。
「改善実施計画」欄（以下「計画欄」）４０５は、改善欄４０４に記された産業医の指導内容を受けて、上司が具体的な改善計画を文章で記入する項目である。
計画審査ボタン４０６と計画審査却下ボタン４０７は、計画欄４０５の内容を審査するか審査却下する時に押すボタンである。これらボタンは、文書に対する承認印の役割を担うものであり、部署長と人事担当部長と産業医が操作可能である。
計画審査履歴欄４０８は、部署長と人事担当部長と産業医による計画審査ボタン４０６と計画審査却下ボタン４０７の操作の結果、つまり、誰が計画欄４０５の内容を審査したか或は審査却下したかを表示する欄である。
「改善実施報告」欄（以下「報告欄」）４０９は、計画欄４０５に記された改善実施計画の結果を、上司が文章で記入する項目である。
報告審査ボタン４１０と報告審査却下ボタン４１１は、報告欄４０９の内容を審査するか審査却下する時に押すボタンである。これらボタンは、文書に対する承認印の役割を担うものであり、部署長と人事担当部長と産業医が操作可能である。
報告審査履歴欄４１２は、部署長と人事担当部長と産業医による報告審査ボタン４１０と報告審査却下ボタン４１１の操作の結果、つまり、誰が報告欄４０９の内容を審査したか或は審査却下したかを表示する欄である。

図５は、改善依頼書４０２の処理手順の概念を示す概略図である。
産業医己１１１は、新規に作成した改善依頼書４０２の改善欄４０４に、上司丙１０８に対し、「就業上の措置で改善すべきこと」を文章で記入する（Ｓ５０１）。
上司丙１０８は、改善依頼書４０２の改善欄４０４に記された、産業医己１１１による指導内容を読む。そして、改善依頼書４０２の計画欄４０５に、具体的な「改善実施計画」を記入する（Ｓ５０２）。

部署長丁１０９は、改善依頼書４０２の計画欄４０５に記された、上司丙１０８による改善実施計画の内容を読む。そして、当該内容を審査するか或は審査却下するかを示すために、計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押す（Ｓ５０３）。
部署長丁１０９が計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押した結果は、これらボタンの直下に設けられている計画審査履歴欄４０８に表示される。

人事担当部長戊１１０は、改善依頼書４０２の計画欄４０５に記された、上司丙１０８による改善実施計画の内容を読む。そして、当該内容を審査するか或は審査却下するかを示すために、計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押す（Ｓ５０４）。
人事担当部長戊１１０が計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押した結果は、これらボタンの直下に設けられている計画審査履歴欄４０８に表示される。

産業医己１１１は、改善依頼書４０２の計画欄４０５に記された、上司丙１０８による改善実施計画の内容を読む。そして、計画審査履歴欄４０８に記されている部署長丁１０９及び人事担当部長戊１１０の審査結果を参考にしつつ、当該内容を承認するか或は否認するかを示すために、計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押す（Ｓ５０５）。
産業医己１１１が計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押した結果は、これらボタンの直下に設けられている計画審査履歴欄４０８に表示される。

上司丙１０８は、計画欄４０５に記して、産業医己１１１の承認を受けた改善実施計画に沿って、対象社員乙１０７の残業時間を減少させ、対象社員乙１０７の健康を回復させる施策を実行する。そして、一定期間経過後、改善実施計画の実行結果を、報告欄４０９に記入する（Ｓ５０６）。つまり、報告欄４０９に「改善実施報告」を記入する。

部署長丁１０９は、改善依頼書４０２の報告欄４０９に記された、上司丙１０８による改善実施報告の内容を読む。そして、当該内容を審査するか或は審査却下するかを示すために、報告審査ボタン４１０と報告審査却下ボタン４１１のいずれかを押す（Ｓ５０７）。
部署長丁１０９が報告審査ボタン４１０と報告審査却下ボタン４１１のいずれかを押した結果は、これらボタンの直下に設けられている報告審査履歴欄４１２に表示される。

人事担当部長戊１１０は、改善依頼書４０２の報告欄４０９に記された、上司丙１０８による改善実施報告の内容を読む。そして、当該内容を審査するか或は審査却下するかを示すために、報告審査ボタン４１０と報告審査却下ボタン４１１のいずれかを押す（Ｓ５０８）。
人事担当部長戊１１０が報告審査ボタン４１０と報告審査却下ボタン４１１のいずれかを押した結果は、これらボタンの直下に設けられている報告審査履歴欄４１２に表示される。

産業医己１１１は、改善依頼書４０２の報告欄４０９に記された、上司丙１０８による改善実施報告の内容を読む。そして、報告審査履歴欄４１２に記されている部署長丁１０９及び人事担当部長戊１１０の審査結果を参考にしつつ、当該内容を承認するか或は否認するかを示すために、報告審査ボタン４１０と報告審査却下ボタン４１１のいずれかを押す（Ｓ５０９）。
産業医己１１１が報告審査ボタン４１０と報告審査却下ボタン４１１のいずれかを押した結果は、これらボタンの直下に設けられている報告審査履歴欄４１２に表示される。

以上の説明より、改善依頼書４０２は、三つの文書を一つに集約したものとなっている。
一つは、産業医が上司に対して対象社員の職場の労働環境の改善を要望する、題目どおりの「労働環境改善依頼書」である。
もう一つは、上司が部署長、人事担当部長及び産業医に対して、対象社員の職場の労働環境を改善するための、具体的な改善計画を報告する、「労働環境改善計画書」である。
もう一つは、上司が部署長、人事担当部長及び産業医から承認を受けた、対象社員の職場の労働環境の改善計画に従って、実際に計画を実施した結果を報告する、「労働環境改善実施報告書」である。

［健康管理サーバ１０２］
これより、先に説明した電子文書である改善依頼書４０２の詳細と、その作成と更新を実現する装置、及びその動作の流れを順次説明する。
図６は、健康管理サーバ１０２の機能ブロック図である。
健康管理サーバ１０２は、主にｗｅｂサーバとして稼動する。その中核に位置する機能ブロックが、ｗｅｂサーバプログラム６０２である。ｗｅｂサーバプログラム６０２は、ＨＴＴＰ（HyperText Transfer Protocol）のサーバプログラムであり、一例としてＡｐａｃｈｅ（http://www.apache.org/）が挙げられる。
図６中、各機能ブロックは大きく三つに大別される。
（１）セルフチェック票ｃｇｉ６０３、面接指導結果報告書ｃｇｉ６０４、改善依頼書表示用ｃｇｉ６０５及び改善依頼書更新用ｃｇｉ６０６は、ｗｅｂサーバプログラム６０２から呼び出されて実行されるｃｇｉである。これらｃｇｉは、端末のアクセスを許可するか否かの判断を、ユーザ認証部６０７を通じて行う。
ユーザ認証部６０７は、周知のＣｏｏｋｉｅ認証方式により、端末から送信されるＨＴＴＰメッセージのヘッダ中のＣｏｏｋｉｅを読み取り、ユーザマスタ６０８と照合して当該ユーザのアクセスの許否を決定する。また、ユーザ認証部６０７は、ユーザマスタ６０８及び所属マスタ６０９を組み合わせて、ユーザの属性の照合も行う。この、ユーザの属性と照合については後述する。
（２）メール作成部６１０は、ｗｅｂサーバプログラム６０２とは関係なく、直接ＬＡＮ１０６を通じてメールサーバ１０５に接続する。
（３）カレンダクロック６１１は、改善依頼書更新用ｃｇｉ６０６が改善依頼書テーブル６１２を更新する際に、更新日時を記録するために実行される機能ブロックであり、ＬＡＮ１０６には接続されない。

図７は健康管理サーバ１０２内に存在する各テーブルのフィールドの一覧を示す。
セルフチェックテーブル６１３は、セルフチェック票２０２の各項目が記録されるテーブルである。一つのレコードは超過残業を行った社員を示す。
「シリアルナンバー」フィールドは、セルフチェックテーブル６１３の各レコードを一意に識別するユニークな番号である。なお、後述するエントリーテーブルのシリアルナンバーとは全く関係しないものである。
「社員番号」フィールドは、甲会社に所属し勤務する各社員に付与されている社員番号である。
「残業記録」フィールドは、当該社員の過去６ヶ月分の残業時間のデータが格納される。
「チェック項目群」フィールドは、セルフチェック票２０２にて回答者である対象社員が回答する項目である。健康状態等に関する質問が多数列挙されている。

「判定結果」フィールドは、当該回答者は産業医との健康状態に関する面接が必要か否かを、産業医が判定した結果を記録するフィールドである。このフィールドの値が「真」の場合は、面接が行われることを示す。
「事後措置として指導勧告の必要性」フィールドは、面接指導結果報告書３０４で選択入力される「事後措置として指導勧告の必要性」欄３０５の値である。
「上司への注意事項要望事項の必要性」フィールドは、面接指導結果報告書３０４で選択入力される「上司への注意事項要望事項の必要性」欄３０６の値である。
「事後措置として指導勧告の必要性」フィールドと「上司への注意事項要望事項の必要性」フィールドの値は、三つの値をとり得る。
初期値はいずれも「未定」を示す「−１」が格納されている。
面接指導結果報告書３０４上で「要」を選択すると、論理の「真」を示す「１」が格納される。
面接指導結果報告書３０４上で「不要」を選択すると、論理の「負」を示す「０」が格納される。

「判定結果」フィールドの値が「真」であり、「事後措置として指導勧告の必要性」フィールドと「上司への注意事項要望事項の必要性」フィールドの値が両方共「−１」であれば、面接は決定したものの、まだ面接指導結果報告書３０４が作成されていない状態である。
「判定結果」フィールドの値が「真」であり、「事後措置として指導勧告の必要性」フィールドと「上司への注意事項要望事項の必要性」フィールドの値がそれぞれ「１」或は「０」であれば（つまり「−１」以外の値であれば）、面接は決定し、面接指導結果報告書３０４が作成された状態である。

ユーザマスタ６０８は、甲会社の社員全員と、産業医の情報が記録されるテーブルである。
「社員番号」フィールドは、前述のセルフチェックフィールドのそれと同じである。なお、産業医は厳密には甲会社の社員ではないが、便宜的にこのテーブルに記録されている。
「社員氏名」フィールドは、当該社員或は産業医の氏名が、「所属コード」フィールドは、当該社員或は産業医の所属部門が、「メールアドレス」フィールドは、当該社員或は産業医のメールアドレスが、それぞれ記録される。
「パスワード」フィールドは、ユーザ認証部６０７にて用いられるデータである。

所属マスタ６０９は、甲会社に設けられている部門のコード（「所属コード」フィールド）との名称（「所属名」フィールド）と、担当社員、つまり上司の社員番号（「上司社員番号」フィールド）が記録されているテーブルである。

ユーザマスタ６０８と所属マスタ６０９を組み合わせることにより、対象社員の社員番号から、対象社員の上司の社員番号、更にその上司である部署長の社員番号、人事担当部長の社員番号、そして産業医の社員番号を知ることができる。
対象社員の社員番号でユーザマスタ６０８を検索し、対象社員の所属コードを得る。その所属コードで所属マスタ６０９を検索し、担当社員番号を得る。これが上司の社員番号である。
更に、その上司の社員番号でユーザマスタ６０８を検索し、上司の所属コードを得る。その所属コードで所属マスタ６０９を検索し、担当社員番号を得る。これが部署長の社員番号である。
予め図示しないファイル等に保持している人事担当部門の所属コードで、所属マスタ６０９を検索し、担当社員番号を得る。これが人事担当部長の社員番号である。
予め図示しないファイル等に保持している産業医を示す所属コードで、ユーザマスタ６０８を検索し、社員番号のリストを得る。これが産業医の全ての社員番号である。

図８は改善依頼書テーブル６１２の構成を示す図である。
改善依頼書テーブル６１２は、二つのテーブルよりなる。
一つは、改善依頼書一通毎に一レコード記録される、エントリーテーブル８０２である。
もう一つは、改善依頼書４０２一通毎に多数のレコードが記録される、ログテーブル８０３である。
エントリーテーブル８０２は改善依頼書４０２の検索キーとなる基本的なフィールドだけが用意される。
「シリアルナンバー」フィールドは、改善依頼書４０２をユニークに識別するための番号である。
「社員番号」フィールドは、対象社員の社員番号である。
「日時」フィールドは、当該レコードを作成した日時である。これはカレンダクロック６１１から日時データを取得して、このフィールドに記録する。
ログテーブル８０３は、「シリアルナンバー」フィールドでエントリーテーブル８０２と一対多の関係を持つ。
「フィールド名」フィールドは、フィールドの名前が格納される。
「値」フィールドは、フィールドの値が格納される。このフィールドは可変長フィールドである。
「日時」フィールドは、エントリーテーブル８０２と同様、当該レコードを作成した日時である。
ログテーブル８０３は、
・改善依頼書４０２に記録されるデータは比較的長い文章が多い、という性質上、可変長フィールドが好ましいことと、
・必ずしも全てのフィールドが常時埋まるとは限らないこと
から、データを格納する効率を考慮して、設けられたものである。したがって、エントリーテーブル８０２とログテーブル８０３が一体化した構成のテーブルであっても構わない。その場合、改善依頼書４０２テーブルは、「シリアルナンバー」、「社員番号」、「措置」、「措置日時」、「計画」、「計画日時」、「審査１」、「審査１日時」、「審査２」、「審査２日時」、「承認」、「承認日時」というフィールド構成となる。

図９は、表示コマンドテーブル６１４と更新コマンドテーブル６１５の中身と、表示コマンドテーブル６１４の各レコードに対応するＵＲＬの一例を示す図である。
端末に表示される改善依頼書４０２は、ｗｅｂブラウザ３０２が所定のＵＲＬに従って健康管理サーバ１０２にアクセスすることにより、改善依頼書表示用ｃｇｉ６０５によってｈｔｍｌ文書が作成され、このｈｔｍｌ文書を端末が受信して表示することにより、端末に表示される。
この時、端末はＨＴＴＰのＧＥＴメソッドで改善依頼書表示用ｃｇｉ６０５にアクセスを行う。
ＧＥＴメソッドは、ＨＴＴＰの周知のアクセス手順であり、クライアントからサーバに対するリクエストメッセージを構成するリクエストライン中に全てのパラメータを記述する手法である。

周知の通り、ＨＴＴＰは、インターネットに関係する技術の事実上の規格書であるＲＦＣ（Request For Comments）２６１６（http://tools.ietf.org/html/rfc2616）にその技術仕様が公開されている。メソッドはＧＥＴを含め、８個のメソッド（"OPTIONS", "GET", "HEAD", "POST", "PUT", "DELETE", "TRACE", "CONNECT"）が存在する。本実施形態では、ＧＥＴメソッドの他に、クライアントである端末からｗｅｂサーバである健康管理サーバ１０２にデータを送信する際に用いる、ＰＯＳＴメソッドを使用する。

今、ＵＲＬ文字列が「http://server.private/kaizen_iraisho.cgi?&sno=****&zoku=4&action=0&field=措置」という文字列であるとする。
「server.private」は、健康管理サーバ１０２のＦＱＤＮ（Fully Qualified Domain Name：完全修飾ドメイン名）である。
「/kaizen_iraisho.cgi?&sno=****&zoku=4&action=0&field=措置」は、健康管理サーバ１０２に渡されるパラメータであり、リクエストラインの全体である。
ｗｅｂサーバプログラム６０２は、このリクエストラインを解析し、「/kaizen_iraisho.cgi」というｃｇｉのファイル名と、「&sno=****&zoku=4&action=0&field=措置」という、「kaizen_iraisho.cgi」に渡すパラメータに分解する。次に、ｗｅｂサーバプログラム６０２は、「/kaizen_iraisho.cgi」に「&sno=****&zoku=4&action=0&field=措置」というパラメータを伴って実行する。
「/kaizen_iraisho.cgi」、すなわち改善依頼書表示用ｃｇｉ６０５は、渡された「&sno=****&zoku=4&action=0&field=措置」というパラメータを、「&」をフィールドセパレータ（区切り子）として分解する。そして、後述する所定の処理を行う。

表示コマンドテーブル６１４の「ｒｅｃｎｏ」フィールドは、表示コマンドテーブル６１４のレコード番号を意味する。
表示コマンドテーブル６１４の「ｚｏｋｕ」フィールドには、アクセスするユーザの属性が記録されている。
ユーザの属性は：
０：対象社員
１：上司
２：部署長
３：人事担当部長
４：産業医
である。

表示コマンドテーブル６１４の「ａｃｔｉｏｎ」フィールドには、アクセスする際の、改善依頼書テーブル６１２に対する動作が記録されている。その数字の意味は：
０：追記
１：更新
２：閲覧
である。

表示コマンドテーブル６１４の「ｆｉｅｌｄ」フィールドには、ユーザが端末で編集対象とする、改善依頼書テーブル６１２のフィールドが記録されている。この「ｆｉｅｌｄ」フィールドに記されたフィールドは、ｈｔｍｌ文書中で、「フォーム」と呼ばれる入力欄として形成される。
フォームは、ｈｔｍｌの「<form>」タグと、「<input>」タグで構成される。フォームの詳細は割愛する。

ＵＲＬ文字列中、表示コマンドテーブル６１４のフィールドとして現れない「ｓｎｏ」という項目がある。これは、エントリーテーブル８０２の「シリアルナンバー」フィールドの値である。つまり、改善依頼書４０２のシリアルナンバーである。

以上に説明したように、表示コマンドテーブル６１４は、クライアントから受信したメッセージに基づいて、改善依頼書表示用ｃｇｉ６０５の挙動を決定するためのテーブルである。

端末に表示されたｈｔｍｌ文書による改善依頼書４０２は、先に説明したように、ＵＲＬ文字列中の「「ｆｉｅｌｄ」＝」で指定されたフィールドが、入力可能になっている。
文字列を入力したり、或は二者択一のボタンを押す等の操作を行うと、端末のｗｅｂブラウザ３０２が所定のＵＲＬに従って健康管理サーバ１０２にアクセスすることにより、改善依頼書更新用ｃｇｉ６０６によって、改善依頼書テーブル６１２の更新が行われる。
この時、端末はＨＴＴＰのＰＯＳＴメソッドで改善依頼書更新用ｃｇｉ６０６にアクセスを行う。
ＰＯＳＴメソッドは、前述のＲＦＣ２６１６に記されているように、ＨＴＴＰの周知のアクセス手順であり、クライアントからサーバに対して比較的データ量の多いデータのアップロードを行う際に用いられる手法である。

改善依頼書更新用ｃｇｉ６０６は更に、改善依頼書テーブル６１２の更新を行った後、所定のパラメータをメール作成部６１０に渡してメール作成部６１０を起動する。メール作成部６１０は、改善依頼書更新用ｃｇｉ６０６から受け取ったパラメータに基づいて、適切な送信相手に送信するためのメールを作成し、自動送信する。このメールにはＵＲＬが記述されており、受信したユーザが当該ＵＲＬをマウス等のポインティングデバイスでクリックすることにより、ｗｅｂブラウザ３０２に読み込まれる。ｗｅｂブラウザ３０２は当該ＵＲＬ文字列に基づいて健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５にアクセスし、ｈｔｍｌ文書を表示する。

更新コマンドテーブル６１５の「ｚｏｋｕ」フィールドは、表示コマンドテーブル６１４の「ｚｏｋｕ」フィールドと同じである。従って、入力される値も同じである。
更新コマンドテーブル６１５の「ａｃｔｉｏｎ」フィールドは、表示コマンドテーブル６１４の「ａｃｔｉｏｎ」フィールドと同じである。従って、入力される値も同じである。
更新コマンドテーブル６１５の「ｆｉｅｌｄ」フィールドは、表示コマンドテーブル６１４の「ｆｉｅｌｄ」フィールドと基本的には同じである。但し、「ｆｉｅｌｄ」が「承認」の時のみ、「承認＝Ｙ」の場合と、「承認＝Ｎ」の場合の、二通りが存在する。つまり、「ｆｉｅｌｄ」が「承認」の場合は、そのフィールドに割り当てられた値とも含めて一致を見る。

更新コマンドテーブル６１５の「ｔｏ」フィールドと、「ｈｉｎａｇａｔａ」フィールドと、「ｒｅｃｎｏ」フィールドは、改善依頼書更新用ｃｇｉ６０６がメール作成部６１０を起動する際に、メール作成部６１０に引き渡すパラメータである。
更新コマンドテーブル６１５の「ｔｏ」フィールドは、メール作成部６１０が作成したメールの送信相手の属性を示す。例えばこのフィールドの値が「１；２；３」の場合は、
・属性が「１」つまり上司と、
・属性が「２」つまり部署長と、
・属性が「３」つまり人事担当部長
の、三者に送信する、という意味である。
更新コマンドテーブル６１５の「ｈｉｎａｇａｔａ」フィールドは、メールひな型ディレクトリ６１６に格納されているメールのひな型を指定する番号である。

更新コマンドテーブル６１５の「ｒｅｃｎｏ」フィールドは、表示コマンドテーブル６１４の「ｒｅｃｎｏ」フィールドを指定する番号である。先に説明したように、メール作成部６１０は、作成するメールの本文に改善依頼書４０２を表示するためのＵＲＬ文字列を埋め込む。この時、メール作成部６１０は、ＵＲＬ文字列を作成するために必要な情報を、表示コマンドテーブル６１４の特定されたレコードから読み取る。

図１０は、ＰＯＳＴメソッドによって端末から健康管理サーバ１０２に対して送信される、ＨＴＴＰリクエストメッセージの一例を示す図である。
ＰＯＳＴメソッドのＨＴＴＰリクエストメッセージは、リクエストライン、リクエストヘッダ、メッセージボディよりなる。リクエストヘッダとメッセージボディとの間は、空行が一行挿入される。なお、ヘッダと本文との間に空行が一行存在する形式は、電子メールのメッセージのフォーマットと等しい。

リクエストラインは、ＨＴＴＰリクエストメッセージの先頭の一行である。ここには、ＨＴＴＰのメソッドとパラメータ、ＨＴＴＰのバージョンが記される。図１０では、
・ＨＴＴＰメソッド：POST
・パラメータ：/kaizen_iraisho_post.cgi
・ＨＴＴＰバージョン：1.1
である。
因みに、ＧＥＴメソッドのリクエストメッセージは、このリクエストラインと次に説明するリクエストヘッダだけで構成される。

リクエストヘッダは、ｗｅｂサーバに渡す環境変数群である。一例として図１０では、
・User-Agent（ｗｅｂブラウザ３０２がＨＴＴＰのプロトコルに則って名乗る名前）：WEBBROUSER/0
・Content-Type（メッセージボディのメッセージ形式）：application/x-www-form-urlencoded
・Content-Length（メッセージボディのメッセージ長）：
である。

メッセージボディは、ｗｅｂブラウザ３０２からｗｅｂサーバに対して送信する、任意のデータである。ＧＥＴメソッドとＰＯＳＴメソッドの一番の相違点は、このメッセージボディの有無である。
図１０では、フィールド名とその値が、イコール（”=”）で結ばれており、フィールド毎に図示しない改行コードによって行が改められている。
「ｓｎｏ」は改善依頼書テーブル６１２のシリアルナンバーである。
「ｚｏｋｕ」は更新コマンドテーブル６１５の「ｚｏｋｕ」フィールドである。
「ａｃｔｉｏｎ」は更新コマンドテーブル６１５の「ａｃｔｉｏｎ」フィールドである。
「ｆｉｅｌｄ」は更新コマンドテーブル６１５の「ｆｉｅｌｄ」フィールドである。
更に、この次の行は「措置＝」の後に文字列が続いている。これは、改善依頼書テーブル６１２の「措置」フィールドに記録する文字列である。

改善依頼書更新用ｃｇｉ６０６は、ＰＯＳＴメソッドで受け取ったメッセージボディ中、「ｚｏｋｕ」フィールド、「ａｃｔｉｏｎ」フィールド及び「ｆｉｅｌｄ」フィールドの値で更新コマンドテーブル６１５を検索して、対応するレコードを特定する。特定できたら、ＰＯＳＴメソッドで受け取ったメッセージボディ中の「ｓｎｏ」フィールドの値で改善依頼書テーブル６１２のエントリーテーブル８０２を検索し、「ｆｉｅｌｄ」フィールドの値で示されるフィールドの値を改善依頼書テーブル６１２のログテーブル８０３に記録する。
そして、更新コマンドテーブル６１５の特定されたレコードの「ｔｏ」フィールド、「ｈｉｎａｇａｔａ」フィールド及び「ｒｅｃｎｏ」フィールドの値と、ＰＯＳＴメソッドで受け取ったメッセージボディ中の「ｓｎｏ」フィールドの値をメール作成部６１０に引き渡して、メール作成部６１０を起動する。

以上に説明したように、更新コマンドテーブル６１５は、クライアントから受信したメッセージに基づいて、改善依頼書更新用ｃｇｉ６０６とメール作成部６１０の挙動を決定するためのテーブルである。

［動作シーケンス］
図１１、図１２、図１３、図１４、図１５、図１６を用いて、健康管理サーバ１０２と、上司、部署長、人事担当部長、産業医との間の処理の流れを説明する。
図１１は、健康管理サーバ１０２と、上司、部署長、人事担当部長、産業医との間の処理の流れを示す、シーケンスの全体概略図である。
図１２は、健康管理サーバ１０２と産業医との間の処理の流れの詳細を示す、シーケンス図である。図５のステップＳ５０１及び図１１のステップＳ１１０１に相当する。
図１３は、健康管理サーバ１０２と上司との間の処理の流れの詳細を示す、シーケンス図である。図５のステップＳ５０２及び図１１のステップＳ１１０２に相当する。
図１４は、健康管理サーバ１０２と部署長との間の処理の流れの詳細を示す、シーケンス図である。図５のステップＳ５０３及び図１１のステップＳ１１０３に相当する。
図１５は、健康管理サーバ１０２と人事担当部長との間の処理の流れの詳細を示す、シーケンス図である。図５のステップＳ５０４及び図１１のステップＳ１１０４に相当する。
図１６は、健康管理サーバ１０２と産業医との間の処理の流れの詳細を示す、シーケンス図である。図５のステップＳ５０５及び図１１のステップＳ１１０５に相当する。

以下、図１２から順に説明する。
産業医己１１１は、端末１０３ｅを操作して、予め健康管理サーバ１０２の機能で取得したＵＲＬ文字列をｗｅｂブラウザ３０２に読み込ませ、健康管理サーバ１０２にアクセスする（Ｓ１２０１）。健康管理サーバ１０２のｗｅｂサーバプログラム６０２は、端末１０３ｅから送られたリクエストラインに記されている文字列をセルフチェック票ｃｇｉ６０３に渡して、セルフチェック票ｃｇｉ６０３を起動する。
セルフチェック票ｃｇｉ６０３は、端末１０３ｅから送られたリクエストラインに記されている文字列から、パラメータを取得する。この文字列はＵＲＬ文字列の一部であり、セルフチェックテーブル６１３のシリアルナンバーが含まれている。そして、セルフチェック票ｃｇｉ６０３はシリアルナンバーでセルフチェックテーブル６１３を検索し、該当レコードの各フィールドの値を取得して、セルフチェック票２０２を表示するｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｅへ送信する（Ｓ１２０２）。

セルフチェック票２０２のｈｔｍｌ文書を受信した端末１０３ｅは、これをｗｅｂブラウザ３０２に読み込ませ、ｗｅｂブラウザ３０２に表示する（Ｓ１２０３）。産業医己１１１は、ｗｅｂブラウザ３０２の中に現れている「面接指導結果報告書作成」ボタン３０３を押す（Ｓ１２０４）。
健康管理サーバ１０２の面接指導結果報告書ｃｇｉ６０４はこれを受けて、面接指導結果報告書３０４のｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｅへ送信する（Ｓ１２０５）。

面接指導結果報告書３０４のｈｔｍｌ文書を受信した端末１０３ｅは、これをｗｅｂブラウザ３０２に読み込ませ、表示画面に表示する（Ｓ１２０６）。産業医己１１１は、対象社員乙１０７の健康状態や面接の聞き取り等から総合的に判定した結果を、ラジオボタンである「事後措置として指導勧告の必要性」欄３０５と「上司への注意事項要望事項の必要性」欄３０６を操作することで入力する。
ここでは、対象社員乙１０７は慢性的な残業超過状態に陥っており、本人の努力ではもはやどうすることもできず、労働環境の早急な改善が必要である、と産業医己１１１が判断したものとする。
産業医己１１１は、「事後措置として指導勧告の必要性」欄３０５を「要」に選択する。すると、面接指導結果報告書３０４を表示しているｗｅｂブラウザ３０２の上側に、「改善依頼書作成」ボタン３０７が現れる。そこで、産業医己１１１は、この「改善依頼書作成」ボタン３０７を押す（Ｓ１２０７）。

産業医己１１１の判定結果は、健康管理サーバ１０２の面接指導結果報告書ｃｇｉ６０４に送信される。面接指導結果報告書ｃｇｉ６０４は、受信した判定結果を見て、それが改善依頼書４０２の作成を要するものであると判定する。そして、改善依頼書表示用ｃｇｉ６０５に転送するための転送用メッセージを作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｅへ送信する（Ｓ１２０８）。

転送用メッセージの一例を以下に記す：

HTTP/1.1 302 Found
Location: http://server.private/kaizen_iraisho.cgi?&sno=****&zoku=4&action=0&field=措置

転送用メッセージは、ＨＴＴＰのステータスコードの一種である転送機能を用いている。これは、ＨＴＴＰでｗｅｂサーバからクライアントへ送信されるレスポンス（応答メッセージ）の先頭行であるステータス行中に、「３」で始まる三桁のステータスコードが記される。そして、次の行に「Location: 」と記され、続いて転送先のＵＲＬが記される。これはＨＴＴＰのＬｏｃａｔｉｏｎヘッダフィールド行である。
面接指導結果報告書ｃｇｉ６０４は、このように構成したＨＴＴＰレスポンスを作成し、ｗｅｂサーバプログラム６０２を介して産業医己１１１の端末１０３ｅへ送信する。

健康管理サーバ１０２から転送用メッセージを受信した端末１０３ｅは、ＨＴＴＰレスポンス中のステータスコードを読み取り、転送を実行する。ＨＴＴＰレスポンス中のＬｏｃａｔｉｏｎヘッダフィールド行に示されるＵＲＬ文字列に基づいて、健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５にアクセスを行う（Ｓ１２０９）。

端末１０３ｅのアクセスに呼応して、健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５がｗｅｂサーバプログラム６０２を通じて起動される。改善依頼書表示用ｃｇｉ６０５は、改善依頼書４０２を表示するｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｅへ送信する（Ｓ１２１０）。

改善依頼書４０２のｈｔｍｌ文書を受信した端末１０３ｅは、これをｗｅｂブラウザ３０２に読み込ませ、表示画面に表示する（Ｓ１２１１）。産業医己１１１は、ｗｅｂブラウザ３０２に表示されている改善依頼書４０２の中の、フォームとして形成されている改善欄４０４に、上司丙１０８に対し、対象社員乙１０７の「就業上の措置で改善すべきこと」の文章を入力する（Ｓ１２１２）。なお、ここで入力された文章は、ログテーブル８０３の「措置」フィールドに該当する。
そして、産業医己１１１は送信を実行する。

産業医己１１１の「措置」に関する文章は、端末１０３ｅから健康管理サーバ１０２の改善依頼書更新用ｃｇｉ６０６に送信される。改善依頼書更新用ｃｇｉ６０６は、受信した内容を見て、エントリーテーブル８０２に新規にレコードを追記すると共に、ログテーブル８０３に追記したレコードと関係する「措置」のレコードを追記する（Ｓ１２１３）。その後、メール作成部６１０を起動し、メールを自動作成し、上司丙１０８へメールを送信する（Ｓ１２１４）。
このメールには、上司丙１０８が健康管理サーバ１０２にアクセスして、改善依頼書４０２を表示するためのＵＲＬ文字列が本文に記録されている。

以上説明したように、産業医己１１１と健康管理サーバ１０２との間とで、セルフチェック票２０２、面接指導結果報告書３０４及び改善依頼書４０２と、文書の送受信が行われる。そして、この過程の後、上司丙１０８へメールが送信される。これが、図１１のステップＳ１１０１の詳細である。

次に、図１３を説明する。
健康管理サーバ１０２から送信されたメールを受信した上司丙１０８は、端末１０３ｂを操作して、メールを表示する（Ｓ１３０１）。
先に述べたように、メールには上司丙１０８が健康管理サーバ１０２にアクセスして、改善依頼書４０２を表示するためのＵＲＬ文字列が本文に記録されている。上司丙１０８はこのＵＲＬ文字列をマウス等のポインティングデバイスでクリックして、ｗｅｂブラウザ３０２を起動し、健康管理サーバ１０２へアクセスする。

端末１０３ｂのアクセスに呼応して、健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５がｗｅｂサーバプログラム６０２を通じて起動される。
改善依頼書表示用ｃｇｉ６０５は、端末１０３ｂから送られたリクエストラインに記されている文字列から、パラメータを取得する。この文字列はＵＲＬ文字列の一部であり、改善依頼書４０２テーブルのシリアルナンバーが含まれている。そして、改善依頼書表示用ｃｇｉ６０５はシリアルナンバーで改善依頼書４０２テーブルを検索し、該当レコードの各フィールドの値を取得して、改善依頼書４０２を表示するｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｂへ送信する（Ｓ１３０２）。

改善依頼書４０２のｈｔｍｌ文書を受信した端末１０３ｂは、これをｗｅｂブラウザ３０２に読み込ませ、ｗｅｂブラウザ３０２に表示する（Ｓ１３０３）。上司丙１０８は、ｗｅｂブラウザ３０２の中に表示されている改善依頼書４０２の改善欄４０４に、具体的な改善計画を書いて、送信する（Ｓ１３０４）。
健康管理サーバ１０２の改善依頼書更新用ｃｇｉ６０６はこれを受けて、ログテーブル８０３に「計画」のレコードを追記する（Ｓ１３０５）。その後、メール作成部６１０を起動し、メールを自動作成し、部署長丁１０９へメールを送信する（Ｓ１３０６）。

以上説明したように、上司丙１０８と健康管理サーバ１０２との間とで、改善依頼書４０２テーブルに改善計画を登録する、という更新作業が行われる。そして、この過程の後、部署長丁１０９へメールが送信される。これが、図１１のステップＳ１１０２の詳細である。

次に、図１４を説明する。
健康管理サーバ１０２から送信されたメールを受信した部署長丁１０９は、端末１０３ｃを操作して、メールを表示する（Ｓ１４０１）。
先に述べたように、メールには部署長丁１０９が健康管理サーバ１０２にアクセスして、改善依頼書４０２を表示するためのＵＲＬ文字列が本文に記録されている。部署長丁１０９はこのＵＲＬ文字列をマウス等のポインティングデバイスでクリックして、ｗｅｂブラウザ３０２を起動し、健康管理サーバ１０２へアクセスする。

端末１０３ｃのアクセスに呼応して、健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５がｗｅｂサーバプログラム６０２を通じて起動される。
改善依頼書表示用ｃｇｉ６０５は、端末１０３ｃから送られたリクエストラインに記されている文字列から、パラメータを取得する。この文字列はＵＲＬ文字列の一部であり、改善依頼書４０２テーブルのシリアルナンバーが含まれている。そして、改善依頼書表示用ｃｇｉ６０５はシリアルナンバーで改善依頼書４０２テーブルを検索し、該当レコードの各フィールドの値を取得して、改善依頼書４０２を表示するｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｃへ送信する（Ｓ１４０２）。

改善依頼書４０２のｈｔｍｌ文書を受信した端末１０３ｃは、これをｗｅｂブラウザ３０２に読み込ませ、ｗｅｂブラウザ３０２に表示する（Ｓ１４０３）。部署長丁１０９は、ｗｅｂブラウザ３０２の中に表示されている改善依頼書４０２の計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押す（Ｓ１４０４）。
健康管理サーバ１０２の改善依頼書更新用ｃｇｉ６０６はこれを受けて、ログテーブル８０３に「審査１」のレコードを追記する（Ｓ１４０５）。その後、メール作成部６１０を起動し、メールを自動作成し、人事担当部長戊１１０へメールを送信する（Ｓ１４０６）。

以上説明したように、部署長丁１０９と健康管理サーバ１０２との間とで、改善依頼書４０２テーブルに審査結果を示す「審査１」を登録する、という更新作業が行われる。そして、この過程の後、人事担当部長戊１１０へメールが送信される。これが、図１１のステップＳ１１０３の詳細である。

次に、図１５を説明する。
健康管理サーバ１０２から送信されたメールを受信した人事担当部長戊１１０は、端末１０３ｄを操作して、メールを表示する（Ｓ１５０１）。
先に述べたように、メールには人事担当部長戊１１０が健康管理サーバ１０２にアクセスして、改善依頼書４０２を表示するためのＵＲＬ文字列が本文に記録されている。人事担当部長戊１１０はこのＵＲＬ文字列をマウス等のポインティングデバイスでクリックして、ｗｅｂブラウザ３０２を起動し、健康管理サーバ１０２へアクセスする。

端末１０３ｄのアクセスに呼応して、健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５がｗｅｂサーバプログラム６０２を通じて起動される。
改善依頼書表示用ｃｇｉ６０５は、端末１０３ｄから送られたリクエストラインに記されている文字列から、パラメータを取得する。この文字列はＵＲＬ文字列の一部であり、改善依頼書４０２テーブルのシリアルナンバーが含まれている。そして、改善依頼書表示用ｃｇｉ６０５はシリアルナンバーで改善依頼書４０２テーブルを検索し、該当レコードの各フィールドの値を取得して、改善依頼書４０２を表示するｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｄへ送信する（Ｓ１５０２）。

改善依頼書４０２のｈｔｍｌ文書を受信した端末１０３ｄは、これをｗｅｂブラウザ３０２に読み込ませ、ｗｅｂブラウザ３０２に表示する（Ｓ１５０３）。人事担当部長戊１１０は、ｗｅｂブラウザ３０２の中に表示されている改善依頼書４０２の計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押す（Ｓ１５０４）。
健康管理サーバ１０２の改善依頼書更新用ｃｇｉ６０６はこれを受けて、ログテーブル８０３に「審査２」のレコードを追記する（Ｓ１５０５）。その後、メール作成部６１０を起動し、メールを自動作成し、産業医己１１１へメールを送信する（Ｓ１５０６）。

以上説明したように、人事担当部長戊１１０と健康管理サーバ１０２との間とで、改善依頼書４０２テーブルに審査結果を示す「審査２」を登録する、という更新作業が行われる。そして、この過程の後、産業医己１１１へメールが送信される。これが、図１１のステップＳ１１０４の詳細である。

次に、図１６を説明する。
健康管理サーバ１０２から送信されたメールを受信した産業医己１１１は、端末１０３ｅを操作して、メールを表示する（Ｓ１６０１）。
先に述べたように、メールには産業医己１１１が健康管理サーバ１０２にアクセスして、改善依頼書４０２を表示するためのＵＲＬ文字列が本文に記録されている。産業医己１１１はこのＵＲＬ文字列をマウス等のポインティングデバイスでクリックして、ｗｅｂブラウザ３０２を起動し、健康管理サーバ１０２へアクセスする。

端末１０３ｅのアクセスに呼応して、健康管理サーバ１０２の改善依頼書表示用ｃｇｉ６０５がｗｅｂサーバプログラム６０２を通じて起動される。
改善依頼書表示用ｃｇｉ６０５は、端末１０３ｅから送られたリクエストラインに記されている文字列から、パラメータを取得する。この文字列はＵＲＬ文字列の一部であり、改善依頼書４０２テーブルのシリアルナンバーが含まれている。そして、改善依頼書表示用ｃｇｉ６０５はシリアルナンバーで改善依頼書４０２テーブルを検索し、該当レコードの各フィールドの値を取得して、改善依頼書４０２を表示するｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介して端末１０３ｅへ送信する（Ｓ１６０２）。

改善依頼書４０２のｈｔｍｌ文書を受信した端末１０３ｅは、これをｗｅｂブラウザ３０２に読み込ませ、ｗｅｂブラウザ３０２に表示する（Ｓ１６０３）。産業医己１１１は、ｗｅｂブラウザ３０２の中に表示されている改善依頼書４０２の計画審査ボタン４０６と計画審査却下ボタン４０７のいずれかを押す（Ｓ１６０４）。
健康管理サーバ１０２の改善依頼書更新用ｃｇｉ６０６はこれを受けて、押されたボタンが計画審査ボタン４０６と計画審査却下ボタン４０７のどちらであるか、確認する（Ｓ１６０５）。
計画審査ボタン４０６であれば（Ｓ１６０５のＹ）、産業医己１１１は上司丙１０８が作成した改善計画を承認したことを意味する。そこで、ログテーブル８０３に「承認＝Ｙ」のレコードを追記する（Ｓ１６０６）。その後、メール作成部６１０を起動し、改善計画が承認されたことを関係者に告知するためのメールを自動作成する（Ｓ１６０７）。

計画審査却下ボタン４０７であれば（Ｓ１６０５のＮ）、産業医己１１１は上司丙１０８が作成した改善計画を否認したことを意味する。そこで、ログテーブル８０３に「承認＝Ｎ」のレコードを追記する（Ｓ１６０８）。その後、メール作成部６１０を起動し、改善計画が否認されたことを関係者に告知するためのメールを自動作成する（Ｓ１６０９）。

そして最後に（Ｓ１６０７或はＳ１６０９）、作成したメールを、上司丙１０８、部署長丁１０９及び人事担当部長戊１１０に送信する（Ｓ１６１０）。

以上説明したように、産業医己１１１と健康管理サーバ１０２との間とで、改善依頼書４０２テーブルに承認結果を示す「承認」を登録する、という更新作業が行われる。そして、この過程の後、上司丙１０８、部署長丁１０９及び人事担当部長戊１１０へメールが送信される。これが、図１１のステップＳ１１０５の詳細である。

［ｃｇｉの動作］
図１７乃至図２２を用いて、健康管理サーバ１０２内の各ｃｇｉの動作の詳細を説明する。
図１７は改善依頼書表示用ｃｇｉ６０５のフローチャートである。
図１８は改善依頼書更新用ｃｇｉ６０６のフローチャートである。
図１９はユーザ認証部６０７で行われるユーザ属性確認処理のフローチャートである。
図２０は改善依頼書表示用ｃｇｉ６０５で行われるＧＥＴ処理のフローチャートである。
図２１は改善依頼書更新用ｃｇｉ６０６で行われるＰＯＳＴ処理のフローチャートである。
図２２はメール作成部６１０で行われるメール送信処理のフローチャートである。

図１７を参照して、改善依頼書表示用ｃｇｉ６０５の動作を説明する。
ｗｅｂサーバプログラム６０２は、クライアント（端末１０３ａ、１０３ｂ、１０３ｃ、１０３ｄ及び１０３ｅ）から健康管理サーバ１０２に対するアクセス（リクエストメッセージ）が改善依頼書表示用ｃｇｉ６０５に対する要求であることを知ると、改善依頼書表示用ｃｇｉ６０５を起動する（Ｓ１７０１）。
改善依頼書表示用ｃｇｉ６０５は、ｗｅｂサーバプログラム６０２を通じてクライアントから受け取ったパラメータをユーザ認証部６０７に渡す。
ユーザ認証部６０７は、最初に、受け取ったパラメータから得たユーザＩＤ及びパスワード文字列とユーザマスタ６０８とを照合し、正規のユーザであるか否かを確認する（Ｓ１７０２）。もし、不正なアクセスであれば、これ以降のセッションは遮断される（Ｓ１７０３）。

次に、ユーザ認証部６０７は受け取ったパラメータからユーザの属性を確認する処理を行う（Ｓ１７０４）。この処理の詳細は図１９にて後述する。
ユーザの属性の確認が取れたら、改善依頼書４０２のｈｔｍｌ文書を作成するための処理である、ＧＥＴ処理を実行し（Ｓ１７０５）、処理を終了する（Ｓ１７０６）。

図１８を参照して、改善依頼書更新用ｃｇｉ６０６の動作を説明する。
ｗｅｂサーバプログラム６０２は、クライアントから健康管理サーバ１０２に対するアクセスが改善依頼書更新用ｃｇｉ６０６に対する要求であることを知ると、改善依頼書更新用ｃｇｉ６０６を起動する（Ｓ１８０１）。
改善依頼書更新用ｃｇｉ６０６は、ｗｅｂサーバプログラム６０２を通じてクライアントから受け取ったパラメータをユーザ認証部６０７に渡す。
ユーザ認証部６０７は、最初に、受け取ったパラメータから得たユーザＩＤ及びパスワード文字列とユーザマスタ６０８とを照合し、正規のユーザであるか否かを確認する（Ｓ１８０２）。もし、不正なアクセスであれば、これ以降のセッションは遮断される（Ｓ１８０３）。

次に、ユーザ認証部６０７は受け取ったパラメータからユーザの属性を確認する処理を行う（Ｓ１８０４）。この処理の詳細は図１９にて後述する。
ユーザの属性の確認が取れたら、改善依頼書４０２テーブルを更新するための処理である、ＰＯＳＴ処理を実行し（Ｓ１８０５）、処理を終了する（Ｓ１８０６）。

図１９を参照して、ユーザ属性確認処理の動作を説明する。
ユーザ認証を済ませた後（Ｓ１９０１）、先ずクライアントから受け取ったパラメータから、エントリーテーブル８０２の「シリアルナンバー」フィールドの値を用いて、エントリーテーブル８０２を検索する（Ｓ１９０２）。次に、検索にヒットしたレコードの「社員番号」フィールドから対象社員の社員番号を取得する（Ｓ１９０３）。

次に、クライアントから受け取ったパラメータの「ｚｏｋｕ」フィールドの値を見る。「ｚｏｋｕ」が「１」である場合（Ｓ１９０４のＹ）は、ユーザの属性が上司であることを示すものである。そこで、先に取得した対象社員の社員番号を用いて、ユーザマスタ６０８を検索する。すると、所属コードが得られるので、得られた所属コードを用いて所属マスタ６０９を検索する。すると、担当社員番号がわかる。これが、対象社員の直属の上司の社員番号である（Ｓ１９０５）。
次に、こうして得た社員番号と、クライアントから受け取ったパラメータに含まれている社員番号とを照合する（Ｓ１９０６）。照合の結果、合致していれば（Ｓ１９０６のＹ）、当該ユーザは「上司」であるので、ユーザ認証部６０７は正常である旨の返り値を改善依頼書表示用ｃｇｉ６０５に返す（Ｓ１９０７）。
もし、照合の結果、合致していなければ（Ｓ１９０６のＮ）、当該ユーザは「上司」ではないので、不正なアクセスである可能性が高い。そこで、セッションを遮断する（Ｓ１９０８）。

以下、ステップＳ１９０４のＮから説明を続ける。
クライアントから受け取ったパラメータの「ｚｏｋｕ」フィールドの値が「２」である場合（Ｓ１９０９のＹ）は、ユーザの属性が部署長であることを示すものである。そこで、先に取得した対象社員の社員番号を用いて、ユーザマスタ６０８を検索する。すると、所属コードが得られるので、得られた所属コードを用いて所属マスタ６０９を検索する。すると、担当社員番号がわかる。これが、対象社員の直属の上司の社員番号である。
部署長の場合は、当該直属の上司の更に上司に当たるので、上述と同じ検索をもう一度行う。つまり、先に得た上司の社員番号で、もう一度ユーザマスタ６０８を検索し、所属コードを得る。その所属コードで所属マスタ６０９を検索し、担当社員番号を得る。これが、対象社員の上司の上司、つまり部署長の社員番号である（Ｓ１９１０）。
ステップＳ１９１０以降の処理は、先に説明したステップＳ１９０６以降と同様である。

クライアントから受け取ったパラメータの「ｚｏｋｕ」フィールドの値が「３」である場合（Ｓ１９１１のＹ）は、ユーザの属性が人事担当部長であることを示すものである。そこで、予め保持されている人事担当部門の所属コードを用いて所属マスタ６０９を検索する。すると、担当社員番号がわかる。これが、人事担当部長の社員番号である（Ｓ１９１２）。
ステップＳ１９１２以降の処理は、先に説明したステップＳ１９０６以降と同様である。

クライアントから受け取ったパラメータの「ｚｏｋｕ」フィールドの値が「４」である場合（Ｓ１９１１のＮ）は、ユーザの属性が産業医であることを示すものである。そこで、予め保持されている産業医の所属コードを用いてユーザマスタ６０８を検索する。すると、ユーザマスタ６０８に登録されている産業医のレコードがヒットする。得られた産業医のレコードの中に、クライアントから受け取ったパラメータに含まれている社員番号と同じものがあるか、確認する（Ｓ１９１３）。
もしあれば（Ｓ１９１３のＹ）、当該アクセスは正当な産業医からのアクセスであるので、ユーザ認証部６０７は正常である旨の返り値を改善依頼書表示用ｃｇｉ６０５に返す（Ｓ１９０７）。
もしなければ（Ｓ１９１３のＮ）、当該アクセスは不正なアクセスである可能性が高いので、セッションを遮断する（Ｓ１９０８）。

図２０を参照して、ＧＥＴ処理の動作を説明する。この「ＧＥＴ処理」という名称は、ＨＴＴＰのＧＥＴメソッドを意味する。つまり、改善依頼書表示用ｃｇｉ６０５は、ＧＥＴメソッドの処理である。
処理を開始すると（Ｓ２００１）、クライアントから受け取ったパラメータの「ｚｏｋｕ」、「ａｃｔｉｏｎ」及び「ｆｉｅｌｄ」の値で、表示コマンドテーブルを検索する（Ｓ２００２）。
検索の結果、合致するレコードがなかった場合は（Ｓ２００３のＮ）、不正アクセスとしてセッションを遮断する（Ｓ２００４）。
検索の結果、合致するレコードがあった場合は（Ｓ２００３のＹ）、「ｆｉｅｌｄ」に記されるフィールドを入力可能なフォームで記述した、改善依頼書４０２を表示するためのｈｔｍｌ文書を作成し、ｗｅｂサーバプログラム６０２を介してクライアントへ送信し（Ｓ２００５）、処理を終了する（Ｓ２００６）。

図２１を参照して、ＰＯＳＴ処理の動作を説明する。
この「ＰＯＴ処理」という名称は、ＨＴＴＰのＰＯＴメソッドを意味する。つまり、改善依頼書更新用ｃｇｉ６０６は、ＰＯＳＴメソッドの処理である。
処理を開始すると（Ｓ２１０１）、クライアントから受け取ったパラメータの「ｚｏｋｕ」、「ａｃｔｉｏｎ」及び「ｆｉｅｌｄ」の値で、更新コマンドテーブル６１５を検索する（Ｓ２１０２）。
検索の結果、合致するレコードがなかった場合は（Ｓ２１０３のＮ）、不正アクセスとしてセッションを遮断する（Ｓ２１０４）。
検索の結果、合致するレコードがあった場合は（Ｓ２１０３のＹ）、「ａｃｔｉｏｎ」の値が１であるか否かを確認する（Ｓ２１０５）。
「ａｃｔｉｏｎ」の値が０の場合は（Ｓ２１０５のＮ）、エントリーテーブル８０２に新規にレコードを追記する（改善依頼書４０２を新規に作成する）ことを示すので、エントリーテーブル８０２に１レコード追記する（Ｓ２１０６）。
「ａｃｔｉｏｎ」の値が１の場合は（Ｓ２１０５のＹ）、「ｆｉｅｌｄ」の値をログテーブル８０３に書き込む（Ｓ２１０７）。「ａｃｔｉｏｎ」の値が０の場合も、ステップＳ２１０６の後、同様に「ｆｉｅｌｄ」の値をログテーブル８０３に書き込む（Ｓ２１０７）。
この後、メール作成部６１０にてメール送信処理を行い（Ｓ２１０８）、処理を終了する（Ｓ２１０９）。

図２２を参照して、メール送信処理の動作を説明する。
改善依頼書更新用ｃｇｉ６０６は、図２１のステップＳ２１０２にて更新コマンドテーブル６１５を検索して、ステップＳ２１０３で該当レコードを得る。この時の、
・更新コマンドテーブル６１５のｔｏ、「ｈｉｎａｇａｔａ」フィールドの値と、
・更新コマンドテーブル６１５のｒｅｃｎｏフィールドの値から紐付けられる、表示コマンドテーブルのレコードの「ｚｏｋｕ」、「ａｃｔｉｏｎ」、「ｆｉｅｌｄ」フィールドの値と、
・編集対象であるエントリーテーブル８０２の社員番号フィールドの値（対象社員の社員番号）と
を、メール作成部６１０に引き渡して、メール作成部６１０を起動する（Ｓ２２０１）。
メール作成部６１０は、受け取ったこれらパラメータのうち、「ｈｉｎａｇａｔａ」フィールドの値で、メールひな型ディレクトリ６１６内に格納されている、メールのひな型ファイルを読み出す（Ｓ２２０２）。

次に、メール作成部６１０は、受け取ったこれらパラメータのうち、ｔｏフィールドの値で指定されている送信相手を検索する（Ｓ２２０３）。
送信相手が「１」であれば「上司」であるので、対象社員の社員番号から直属の上司の社員番号を得て、そのメールアドレスを得る。
送信相手が「２」であれば「部署長」であるので、対象社員の社員番号から上司の上司、つまり部署長の社員番号を得て、そのメールアドレスを得る。
送信相手が「３」であれば「人事担当部長」であるので、人事部門の担当者の社員番号を得て、そのメールアドレスを得る。
送信相手が「４」であれば「産業医」であるので、セルフチェックテーブル６１３から担当の産業医の社員番号を得て、そのメールアドレスを得る。

次に、表示コマンドテーブルのレコードの「ｚｏｋｕ」、「ａｃｔｉｏｎ」、「ｆｉｅｌｄ」フィールドの値を基に、メールに埋め込むためのＵＲＬを作成する（Ｓ２２０４）。
そして、ひな型とＵＲＬを組み合わせてメールを作成し、然るべき送信相手へメールを送信し（Ｓ２２０５）、処理を終了する（Ｓ２２０６）。

以上に説明した内容を要約する。
・改善依頼書表示用ｃｇｉ６０５は、ＧＥＴメソッドでアクセスされる。受け取ったパラメータのうち、「ｆｉｅｌｄ」で指定されたフィールドを「<form>」タグ及び「<input>」タグで形成したｈｔｍｌ文書を作成する。
・改善依頼書更新用ｃｇｉ６０６は、ＰＯＳＴメソッドでアクセスされる。受け取ったパラメータの値をログテーブル８０３に記録すると共に、メール作成部６１０を起動して、適切な送信相手にメールを送信する。
・表示コマンドテーブルは、改善依頼書表示用ｃｇｉ６０５のアクセスの正当性を検査するために利用されると共に、メール作成部６１０が作成するメールに埋め込むＵＲＬを作成するために、改善依頼書更新用ｃｇｉ６０６から利用される。
・更新コマンドテーブル６１５は、改善依頼書更新用ｃｇｉ６０６のアクセスの正当性を検査するためと、メール作成部６１０が作成するメールの送信相手とメールのひな型を選ぶために、改善依頼書更新用ｃｇｉ６０６から利用される。

表示コマンドテーブルと更新コマンドテーブル６１５の存在によって、改善依頼書表示用ｃｇｉ６０５と、改善依頼書更新用ｃｇｉ６０６は、汎用的な構成を採ることができる。動作の詳細な流れは表示コマンドテーブルと更新コマンドテーブル６１５によって決定付けられるので、仮に文書の処理の流れを変更しなければならなくなったとしても、表示コマンドテーブルと更新コマンドテーブル６１５を書き換えることで、迅速な対応が可能となる。
表示コマンドテーブルと更新コマンドテーブル６１５は、健康管理サーバ１０２内で動作の流れを制御する、いわばシナリオの役目を果たしている。

本実施形態においては、長時間残業者健康管理システムと健康管理サーバ１０２を開示した。ＰＤＣＡサイクルを電子文書で実践するための仕組みを、汎用的に作成された改善依頼書表示用ｃｇｉ６０５と改善依頼書更新用ｃｇｉ６０６と、シナリオの役目を担う表示コマンドテーブルと更新コマンドテーブル６１５を用意することで、比較的容易に実現できる。

以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。

本発明の実施形態の例である、長時間残業者健康管理システムの概略図である。 セルフチェック票の処理の流れを説明する概略図である。 産業医己による、面接終了後の処理の流れを説明する概略図である。 改善依頼書の概略図である。 改善依頼書の処理手順の概念を示す概略図である。 健康管理サーバの機能ブロック図である。 健康管理サーバ内に存在する各テーブルのフィールドの一覧を示す。 改善依頼書テーブルの構成を示す図である。 表示コマンドテーブルと更新コマンドテーブルの中身と、表示コマンドテーブルの各レコードに対応するＵＲＬの一例を示す図である。 ＰＯＳＴメソッドによって端末から健康管理サーバに対して送信される、ＨＴＴＰリクエストメッセージの一例を示す図である。 健康管理サーバと、上司、部署長、人事担当部長、産業医との間の処理の流れを示す、シーケンスの全体概略図である。 健康管理サーバと産業医との間の処理の流れの詳細を示す、シーケンス図である。 健康管理サーバと上司との間の処理の流れの詳細を示す、シーケンス図である。 健康管理サーバと部署長との間の処理の流れの詳細を示す、シーケンス図である。 健康管理サーバと人事担当部長との間の処理の流れの詳細を示す、シーケンス図である。 健康管理サーバと産業医との間の処理の流れの詳細を示す、シーケンス図である。 改善依頼書表示用ｃｇｉのフローチャートである。 改善依頼書更新用ｃｇｉのフローチャートである。 ユーザ認証部で行われるユーザ属性確認処理のフローチャートである。 改善依頼書表示用ｃｇｉで行われるＧＥＴ処理のフローチャートである。 改善依頼書更新用ｃｇｉで行われるＰＯＳＴ処理のフローチャートである。 メール作成部で行われるメール送信処理のフローチャートである。

符号の説明

１０１…長時間残業者健康管理システム、１０２…健康管理サーバ、１０３ａ、１０３ｂ、１０３ｃ、１０３ｄ、１０３ｅ…端末、１０５…メールサーバ、１０６…ＬＡＮ、１０７…対象社員乙、１０８…上司丙、１０９…部署長丁、１１０…人事担当部長戊、１１１…産業医己、２０２…セルフチェック票、３０２…ｗｅｂブラウザ、３０３…「面接指導結果報告書作成」ボタン、３０４…面接指導結果報告書、３０５…「事後措置として指導勧告の必要性」欄、３０６…「上司への注意事項要望事項の必要性」欄、３０７…「改善依頼書作成」ボタン、４０２…改善依頼書、４０３…「対象者情報」欄、４０４…改善欄、４０５…計画欄、４０６…計画審査ボタン、４０７…計画審査却下ボタン、４０８…計画審査履歴欄、４０９…報告欄、４１０…報告審査ボタン、４１１…報告審査却下ボタン、４１２…報告審査履歴欄、６０２…ｗｅｂサーバプログラム、６０３…セルフチェック票ｃｇｉ、６０４…面接指導結果報告書ｃｇｉ、６０５…改善依頼書表示用ｃｇｉ、６０６…改善依頼書更新用ｃｇｉ、６０７…ユーザ認証部、６０８…ユーザマスタ、６０９…所属マスタ、６１０…メール作成部、６１１…カレンダクロック、６１２…改善依頼書テーブル、６１３…セルフチェックテーブル、６１４…表示コマンドテーブル、６１５…更新コマンドテーブル、６１６…メールひな型ディレクトリ、８０２…エントリーテーブル、８０３…ログテーブル

Claims (4)

1. 電子文書テーブルと、
   前記電子文書テーブルの一のレコードを読み込んで端末に電子文書を表示させる電子文書表示部と、
   前記電子文書テーブルの一のレコードの指定されたフィールドの値を更新する電子文書更新部と、
   前記電子文書表示部の挙動を制御するパラメータ群を格納する表示コマンドテーブルと、
   前記電子文書更新部の挙動を制御するパラメータ群を格納する更新コマンドテーブルと
   を備える電子文書管理サーバ。
2. 前記表示コマンドテーブルは、パラメータにユーザの属性を備える請求項１記載の電子文書管理サーバ。
3. 電子文書を表示する端末と、
   前記電子文書の各項目を格納する電子文書テーブルと、前記電子文書テーブルの一のレコードを読み込んで前記端末に電子文書を表示させる電子文書表示部と、前記電子文書テーブルの一のレコードの指定されたフィールドの値を更新する電子文書更新部と、前記電子文書表示部の挙動を制御するパラメータ群を格納する表示コマンドテーブルと、前記電子文書更新部の挙動を制御するパラメータ群を格納する更新コマンドテーブルとを備える電子文書管理サーバと
   を備える電子文書管理システム。
4. 端末から所定の第一パラメータ群を伴って電子文書の表示要求を電子文書管理サーバに送信するステップと、
   前記第一パラメータ群を表示コマンドテーブルと照合するステップと、
   前記第一パラメータ群で指定された電子文書テーブルの一のレコードを読み込んで端末に電子文書を表示させるステップと、
   前記端末から所定の第二パラメータ群を伴って電子文書の更新要求を電子文書管理サーバに送信するステップと、
   前記第二パラメータ群で指定された前記電子文書テーブルの一のレコードの指定されたフィールドの値を更新するステップと
   を有する電子文書更新方法。

Images