"クライアント端末からWeb上での回答を要求する電子メールを受け付け、受け付けた前記電子メールを識別するメール識別情報と、回答依頼内容へのアクセス情報とを対応づけて第1の記憶部に記憶し、前記電子メールが送信先である複数のクライアント端末各々における該電子メールの開封状況を取得し、前記メール識別情報と前記開封状況とを対応づけて第2の記憶部に記憶し、前記メール識別情報を含む要求を取得し、前記第1の記憶部を参照して前記要求に含まれるメール識別情報に対応する前記アクセス情報に基づいて、前記複数のクライアント端末各々におけるWeb上での回答状況を取得し、取得した前記回答状況と、前記第2の記憶部から取得した前記開封状況とに基づいて、前記複数のクライアント端末のうち少なくとも一部のクライアント端末を管轄する管轄端末に督促情報を出力する、処理をコンピュータに実行させるためのメール督促プログラム。前記アクセス情報は、URL又は添付ファイル名を含むことを特徴とする請求項1に記載のメール督促プログラム。前記複数のクライアント端末を、複数のグループ毎に分類して管理すると共に、前記複数のグループ毎に、前記回答状況が未回答である数、前記開封状況が未開封である数に基づいて、前記複数のグループ各々に対応する前記管轄端末へ前記督促情報を出力することを特徴とする請求項1又は2に記載のメール督促プログラム。前記開封状況は、前記管轄端末が管轄するクライアント端末における前記電子メールの開封率、受信メール数、及び前記アクセス情報へのアクセス回数のうち、少なくとも1つを含むことを特徴とする請求項1乃至3の何れか1項に記載のメール督促プログラム。前記開封率、前記受信メール数、及び前記アクセス情報へのアクセス回数と、対応する閾値との比較結果に基づいて、対応する督促情報の内容を選択することを特徴とする請求項4に記載のメール督促プログラム。前記回答状況を、前記回答依頼内容を作成したクライアント端末に表示させる画面を作成することを特徴とする請求項1乃至5の何れか1項に記載のメール督促プログラム。クライアント端末からWeb上での回答を要求する電子メールを受け付け、受け付けた前記電子メールを識別するメール識別情報と、回答依頼内容へのアクセス情報とを対応づけて記憶する第1の記憶部と、前記電子メールが送信先である複数のクライアント端末各々における該電子メールの開封状況を取得し、前記メール識別情報と前記開封状況とを対応づけて記憶する第2の記憶部と、前記メール識別情報を含む要求を取得し、前記第1の記憶部を参照して前記要求に含まれるメール識別情報に対応する前記アクセス情報に基づいて、前記複数のクライアント端末各々におけるWeb上での回答状況を取得する回答状況取得部と、取得した前記回答状況と、前記第2の記憶部から取得した前記開封状況とに基づいて、前記複数のクライアント端末のうち少なくとも一部のクライアント端末を管轄する管轄端末に督促情報を出力する督促文送信部とを有することを特徴とするメール装置。クライアント端末からWeb上での回答を要求する電子メールを受け付け、受け付けた前記電子メールを識別するメール識別情報と、回答依頼内容へのアクセス情報とを対応づけて第1の記憶部に記憶し、前記電子メールが送信先である複数のクライアント端末各々における該電子メールの開封状況を取得し、前記メール識別情報と前記開封状況とを対応づけて第2の記憶部に記憶し、前記メール識別情報を含む要求を取得し、前記第1の記憶部を参照して前記要求に含まれるメール識別情報に対応する前記アクセス情報に基づいて、前記複数のクライアント端末各々におけるWeb上での回答状況を取得し、取得した前記回答状況と、前記第2の記憶部から取得した前記開封状況とに基づいて、前記複数のクライアント端末のうち少なくとも一部のクライアント端末を管轄する管轄端末に督促情報を出力する、処理を有することを特徴とするメール督促方法。しかしながら、上述した回答率を向上させるためには、Web上の回答数だけでは不十分な場合があった。例えば、依頼メール自体の認識率電子メールの開封率が低い場合には、回答率の低さがその認識率に起因するものであるのか、又は認識率は高いのに回答率が低いのかがわからなかった。つまり、認識率が高い場合で回答率が低い場合には、回答することを忘れていることや、自分に回答する必要がないと思われている場合等が考えられる。一方、認識率が低く回答率が高い場合には、そもそもメール自体を認識していない場合等が考えられる。したがって、実際には、担当者が督促を行う場合や、幹部社員が呼び掛けを行う場合に、何れのパターンかを認識することで、より効果的な督促等を行うことができるのが好ましい。開示の技術は、かかる問題を鑑み、電子メールの受信状況に基づいて適切なメールの督促を効率的に行うことで、回答依頼に対する回答率を向上させることを目的とする。開示の一態様におけるメール督促プログラムは、クライアント端末からWeb上での回答を要求する電子メールを受け付け、受け付けた前記電子メールを識別するメール識別情報と、回答依頼内容へのアクセス情報とを対応づけて第1の記憶部に記憶し、前記電子メールが送信先である複数のクライアント端末各々における該電子メールの開封状況を取得し、前記メール識別情報と前記開封状況とを対応づけて第2の記憶部に記憶し、前記メール識別情報を含む要求を取得し、前記第1の記憶部を参照して前記要求に含まれるメール識別情報に対応する前記アクセス情報に基づいて、前記複数のクライアント端末各々におけるWeb上での回答状況を取得し、取得した前記回答状況と、前記第2の記憶部から取得した前記開封状況とに基づいて、前記複数のクライアント端末のうち少なくとも一部のクライアント端末を管轄する管轄端末に督促情報を出力する、処理をコンピュータに実行させる。開示の技術によれば、電子メールの受信状況に基づいて適切なメールの督促を効率的に行うことができる。また、開示の技術によれば、回答依頼に対する回答率を向上させることができる。以下、添付図面を参照しながら実施例について詳細に説明する。<第1実施例:システム構成例>第1実施例におけるメールシステムの構成例について、図を用いて説明する。図1は、第1実施例におけるメールシステムの一構成例を示す図である。図1に示すメールシステム10は、メールサーバ11と、クライアント端末12-1~12-nとを有する。また、メールサーバ11とクライアント端末12-1~12-nは、例えばインターネットやLANLocalAreaNetwork等に代表される通信ネットワーク13によりデータの送受信が可能な状態で接続されている。メールサーバ11は、各クライアント端末12-1~12-nに対する個々のメールの送受信を管理するメール装置である。したがって、メールサーバ11は、各クライアント端末12-1~12-n毎の送信メールや受信メールを集約して管理する。また、メールサーバ11には、データベース以下、DBと略称するとして、例えばメールURL対応DB第1の記憶部や、メールDB第2の記憶部、利用者認証DB、設定DB、人事DB、回答状況DB、督促文DB等の各DBを有する。なお、各DBは、自らが記憶すべき情報を取得し、幾つかの項目同士を関連づけて記憶する機能を有する。メールサーバ11は、上述した各DBを用いてクライアント端末12の利用者を管理する。また、メールサーバ11は、第1実施例におけるメール督促処理等を実現するためのメール督促プログラム例えば、メールプログラムや回答状況データ作成プログラム等を有する。クライアント端末12は、メールサーバ11から送られるメールの内容を表示する表示プログラム例えば、ブラウザ表示用のプログラム等を有する。また、クライアント端末12は、表示プログラムにより表示されるメールの内容を確認したり、表示されたメール内容に記述された質問への回答を行う。ここで、クライアント端末12が行う回答は、例えばメール内容に記述したURL等のアクセス情報に基づいて外部装置等にアクセスし、そのアクセス先で得られる質問に対する回答等が含まれる。このとき、上述した外部装置は、メールサーバ11の管理外でもよく、また管理内でもよい。なお、クライアント端末12には、回答依頼者や回答者が使用する端末が含まれる。したがって、例えば回答依頼者が使用するクライアント端末12の場合には、Web上での回答を要求する電子メールをメールサーバ11に送信したり、メールサーバ11から回答状況を取得することができる。また、回答者が使用するクライアント端末12の場合には、例えばWeb上での回答を要求する電子メールを受信し、Web上で回答を作成することができる。なお、図1では、メールサーバ11とクライアント端末12との関係を1:nとしているが、これに限定されるものではなく、例えば、m:nm、nは1以上の関係でもよい。<第1実施例:メールサーバ11の機能構成例>図2は、第1実施例におけるメールサーバの機能構成の一例を示す図である。なお、図2では、説明の便宜上、回答依頼側のクライアント端末12-1と、回答側のクライアント端末12-2とが、メールサーバ11に対してデータの送受信が可能な状態で接続されているものとする。したがって、以下の説明において利用者とは、第1実施例におけるメールシステム10を利用するメール回答依頼側及びメール回答側のクライアントユーザの意味を含むものとする。図2に示すメールサーバ11は、メールプログラム20と、回答状況データ作成プログラム30とを有する。メールプログラム20は、利用要求受信部21と、利用者認証部22と、メール送信部23と、回答状況取得部24と、回答状況送信部25と、督促要求受信部26と、督促文送信部27とを有する。回答状況データ作成プログラム30は、回答受信部31と、データ更新部32とを有する。また、メールサーバ11は、DBとして、利用者認証DB41と、人事DB42と、メールDB43と、回答状況DB44と、メールURL対応DB第1の記憶部45と、設定DB46と、督促文DB47とを有する。利用要求受信部21は、回答依頼側のクライアント端末12-1からの利用要求を受信する。このとき、利用要求受信部21は、利用要求のあったクライアント端末12-1に対して、利用者情報入力画面を送信する。なお、利用者情報とは、例えば利用者ID、パスワード等である。利用要求受信部21は、クライアント端末12-1から利用者ID、パスワードを受信すると、利用者認証DB41を参照し、利用者認証部22に情報を出力して認証を行わせる。利用者認証部22は、例えば利用要求受信部21により得られるクライアント端末12-1からの利用者ID、パスワードが、利用者認証DB41に含まれているか否かを判断して利用者認証を行う。利用者認証部22は、認証がOK利用可能であれば、許可された利用者に対して、人事DB42を参照して利用者の部署、役職代表者情報等の確認を行う。また、利用者認証部22は、認証エラーであった場合には、その旨のメッセージ画面を生成し、クライアント端末12-1の表示部に表示させるように制御する。メール送信部23は、利用者認証部22からの認証結果に基づいて、メールDB43を参照し、その利用者に送信するメールの内容メール情報を取得し、取得したメールの内容に基づいて対象者である回答側のクライアント端末12-2にメールを送信する。また、メール送信部23は、例えば複数のクライアント端末12各々における電子メールの開封状況を取得し、クライアント端末12から受け付けた電子メールを識別するメール識別情報と開封状況とを対応づけてメールDB43等に記憶させる機能を有していてもよい。回答状況取得部24は、メールURL対応DB45及び回答状況DB44に基づいて、各回答側のクライアント端末12各々における回答状況を取得する。具体的には、回答状況取得部24は、例えば上述したメール識別情報を含む要求を取得し、メールURL対応DB45等を参照して要求に含まれるメール識別情報に対応するURL等のアクセス情報に基づいて、回答依頼内容に対するWeb上での回答状況を取得する。なお、回答状況取得部24は、例えば上述したメール識別情報と、回答依頼内容へのアクセス情報とを対応づけてメールURL対応DB45に記憶させる機能を有していてもよい。回答状況送信部25は、現時点で、回答状況取得部24により得られる回答状況結果を督促要求受信部26及び回答依頼側のクライアント端末12-1に出力する。督促要求受信部26は、クライアント端末12-1で指定された督促要求を受信し、受信した督促要求を督促文送信部27に出力する。督促文送信部27は、設定DB46を参照して督促要求に対応する設定情報を抽出すると共に、督促文DB47を参照して督促要求及び設定情報に対応する督促文を取得する。また、督促文送信部27は、取得した督促文の内容を回答側の所定のクライアント端末12-2に出力する。つまり、督促文送信部27は、例えば上述した回答状況と開封状況とに基づいて、上述した設定情報との比較を行い、その結果に基づいて督促文DB47から選択された督促文督促情報を、その対象となるクライアント端末12の利用者を管轄する人が利用する管轄端末詳細は後述するに出力する。ここで、管轄端末に出力する形態としては、例えば電子メール等があるが、これに限定されるものではない。回答受信部31は、回答側のクライアント端末12-2からの回答結果を受信する。また、回答受信部31は、クライアント端末12-2からの回答結果をデータ更新部32に出力する。データ更新部32は、回答受信部31により得られる回答結果に基づいて回答状況DB44を更新する。利用者認証DB41は、例えば、利用者IDとパスワードとが対応づけられて記憶されており、クライアント端末12の認証をする際に用いられる。人事DB42は、例えば、利用者IDと、氏名と、部署名と、役職代表者情報とが対応づけられて記憶されており、認証された利用者に対する情報を取得する際に用いられる。メールDB43は、メールを利用する利用者毎にメール情報等が格納されている。なお、メールDB43には、クライアント端末12による電子メールの開封状況が取得され、メッセージIDメール識別情報や開封状況等が対応づけられて記憶されている。また、メールは、送信メールと受信メールとに大きく分類される。受信メールの情報には、例えばそのメールが開封済であるか未開封であるかを示すデータ等が含まれる。また、送信メールには、例えばそのメールが回答要のものか否かを示すデータ等が含まれる。回答状況DB44は、例えば、部署等の所定のグループ毎に、所属人数と、回答数と、現在の回答率と、開封数と、開封率と、その後に受信したメールの数とが対応づけて記録されている。なお、上述した情報は、例えば回答用URL等のアクセス情報毎に存在するが、これに限定されるものではない。メールURL対応DB45は、回答を依頼した回答期限付メールのメッセージIDメール識別情報と、そのメール内容に記載された回答用URL等のアクセス情報とが対応づけられて記憶されている。設定DB46は、回答期限メールの送信者が設定した督促文を利用する際の開封率の閾値や、その後の受信メール数の閾値等が記憶されている。なお、上述した情報は、例えば回答期限メール毎に存在するが、これに限定されるものではない。督促文DB47は、例えば開封率とその後に受信したメール数とに対応づけられて督促文が記憶され、上述した設定DB46における各閾値との比較結果に応じて適切な督促文が利用される。なお、クライアント端末12-1,12-2では、それぞれが表示プログラム50を有し、必要に応じてメールサーバ11から送信されるメールの内容や回答状況、督促文等を参照することができる。つまり、第1実施例では、表示プログラム50を有することで、ブラウザ等を用いたWebメール等により、上述した内容等を実現することができる。ここで、具体的な処理について説明すると、第1実施例では、メールクライアントの利用者クライアント端末12-1が、自らが送信した送信メールの履歴から回答状況を見たい回答期限付メールを選択し、表示要求をメールサーバ11に送信する。メールサーバ11は、その要求を受け付けると、そのメールのメッセージIDから、メールURL対応DB45に基づいて、回答用URLを取得する。次に、第1実施例では、取得した回答用URLに対応する回答状況DB44に基づき、例えば組織毎の回答状況、開封/未開封状況、その後の平均受信メール数を含めた回答状況表示画面を作成し、作成した画面の情報をメールクライアントクライアント端末12-1に返送する。メールクライアント側クライアント端末12-1では、回答状況表示画面をメールサーバ11から受信し、受信した画面の情報を表示する。クライアント端末12-1の利用者は、画面に表示されている1又は複数の組織のうち、ある組織グループを選択し、督促送信要求を送信する。メールサーバ11は、クライアント端末12-1から上述した督促送信要求を受け付けると、設定DB46と、回答状況DB44と、督促文DB47とに基づいて、督促文を自動的に作成する。次に、選択された部署名から部署の管理者の宛先を人事DB42から取得し、督促文をその宛先に送信する。なお、先に記載した管轄端末とは、ここでいう管理者が利用している端末のことを指す。管轄端末は、複数のクライアント端末のうち、予め設定された少なくとも一部のクライアント端末を管轄する。第1実施例では、例えば複数のクライアント端末を複数のグループ毎に分類して管理すると共に、複数のグループ毎に回答状況が未回答である数、開封状況が未開封である数等に基づいて、複数のグループ各々に対応する管轄端末へ督促情報を出力することができる。<第1実施例:クライアント端末12の機能構成例>図3は、第1実施例におけるクライアント端末の機能構成の一例を示す図である。図3では、説明の便宜上、メールサーバ11を簡略的に示しているが、図2に示す構成等を有するものである。図3に示すクライアント端末12は、表示プログラム50を有する。表示プログラム50は、メール表示要求部51と、利用者情報送信部52と、メール表示部53と、メール送信部54と、回答送信部55と、回答状況表示要求部56と、回答状況受信部57と、回答状況表示部58とを有する。メール表示要求部51は、クライアント端末12を使用する利用者に対するメール情報を表示するための要求を作成し、作成した要求情報をメールサーバ11に出力するために利用者情報送信部52に出力する。利用者情報送信部52は、メール表示要求部51からの表示要求に基づき、クライアント端末12でメール情報を表示するため、利用者情報をメールサーバ11に送信する。なお、利用者情報とは、例えば、利用者IDやパスワード等である。また、利用者情報は、利用者情報送信部52が有するメモリ記憶部に記憶されていてもよく、利用者がキーボード等の入力部等を用いてメール表示要求をする度に入力してもよい。メール表示部53は、メールサーバ11から得られたメール表示要求に対応するメール情報をディスプレイ等の表示部の画面に表示する。メール送信部54は、クライアント端末12でメールを作成した場合に、その作成したメール情報をメールサーバ11に送信する。回答送信部55は、受信したメールに含まれている回答用URL等により所定のサイト例えば、ホームページ等にアクセスし、アクセスしたサイトに表示される質問に対する回答を作成し、作成した回答情報をメールサーバ11に送信する。なお、上述したメールの作成及び回答の作成は、例えばクライアント端末12等に設けられたキーボードやマウス、タッチパネル等のデータ入力部等を用いて利用者により行われる。回答状況表示要求部56は、回答依頼側のクライアントが、回答状況を表示したい場合に、回答状況表示要求をメールサーバ11に送信する。回答状況受信部57は、回答状況表示要求部56が要求した回答状況表示要求に対してメールサーバ11から得られる回答状況を受信する。また、回答状況受信部57は、受信した情報を回答状況表示部58に出力する。回答状況表示部58は、回答状況受信部57により得られる回答状況を表示するための所定の画面を作成し、作成された画面をディスプレイ等の表示部の画面に表示する。なお、上述した回答状況表示要求部56、回答状況受信部57、及び回答状況表示部58とは、回答依頼側のクライアント端末12-1が有する機能であるが、回答側のクライアント端末212-2にも有していてもよい。<ハードウェア構成例>ここで、上述したメールサーバメール装置11及びクライアント端末12においては、各機能をコンピュータに実行させることができる実行プログラム例えば、メール督促プログラム、表示プログラム等を作成し、例えば汎用のパーソナルコンピュータ、サーバ、携帯端末、ゲーム機器等にその実行プログラムをインストールすることにより、メール督促処理、表示処理等を実現することができる。ここで、第1実施例におけるメール督促処理が実現可能なコンピュータのハードウェア構成例について図を用いて説明する。図4は、第1実施例におけるメール督促処理が実現可能なハードウェア構成の一例を示す図である。図4におけるコンピュータ本体には、入力装置61と、出力装置62と、ドライブ装置63と、補助記憶装置64と、メモリ装置65と、各種制御を行うCentralProcessingUnitCPU66と、ネットワーク接続装置67とを有するよう構成されており、これらはシステムバスBで相互に接続されている。入力装置61は、利用者等が操作するキーボード及びマウス等のポインティングデバイスを有しており、利用者等からのプログラムの実行等、各種操作信号を入力する。出力装置62は、第1実施例における各処理を行うためのコンピュータ本体を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイを有し、CPU66が有する制御プログラムによりプログラムの実行経過や結果等を表示することができる。ここで、コンピュータ本体にインストールされる実行プログラムは、例えばUniversalSerialBusUSBメモリやCD-ROM等の可搬型の記録媒体68等により提供される。プログラムを記録した記録媒体68は、ドライブ装置63にセット可能であり、記録媒体68に含まれる実行プログラムが、記録媒体68からドライブ装置63を介して補助記憶装置64にインストールされる。補助記憶装置64は、ハードディスク等のストレージ手段であり、第1実施例における実行プログラムやコンピュータに設けられた制御プログラム等を蓄積し、必要に応じて入出力を行うことができる。メモリ装置65は、CPU66により補助記憶装置64から読み出された実行プログラム等を格納する。なお、メモリ装置65は、ReadOnlyMemoryROMやRandomAccessMemoryRAM等からなる。CPU66は、OperatingSystemOS等の制御プログラム、及びメモリ装置65に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御して、メール督促における各処理を実現することができる。なお、プログラムの実行中に必要な各種情報等は、補助記憶装置64から取得することができ、また実行結果等を格納することもできる。ネットワーク接続装置67は、通信ネットワーク等と接続することにより、実行プログラムを通信ネットワークに接続されている他の端末等から取得したり、プログラムを実行することで得られた実行結果又は第1実施例における実行プログラム自体を他の端末等に提供することができる。第1実施例では、上述したようなハードウェア構成により、第1実施例における各プログラムをインストールすることで、汎用のパーソナルコンピュータ等で第1実施例における各処理を容易に実現することができる。なお、上述したメール督促プログラム、表示プログラム等に関する各処理については、後述する。<データベース例>以下の説明では、第1実施例に示すデータベース例について、図5~図11を用いて説明する。図5は、利用者認証DBのデータ例を示す図である。また、図6は、人事DBのデータ例を示す図である。また、図7は、メールDBのデータ例を示す図である。また、図8は、回答状況DBのデータ例を示す図である。また、図9は、メールURL対応DBのデータ例を示す図である。また、図10は、設定DBのデータ例を示す図である。また、図11は、督促文DBのデータ例を示す図である。図5に示す利用者認証DB41のデータ項目としては、例えば、利用者ID、パスワード等からなるが、これに限定されるものではない。利用者IDは、上述するクライアント端末12を利用する利用者の識別情報に相当し、図5の例ではメールアドレスを用いている。つまり、利用者認証DB41は、クライアント端末12からのアクセスに対して、利用者IDとパスワードとにより、その利用者を特定すると共に認証を行い、利用権限があるか否かを判断するためのDBである。図6に示す人事DB42のデータ項目としては、例えば、利用者ID、氏名、部署名、代表者役職、所属コード、及びメーリングリスト名ML名等からなるが、これに限定されるものではない。また、部署名は、更に細分化して、例えば統括部名、部名、課名等の項目を有していてもよい。人事DB42は、利用者毎の現時点での所属や役職等を、メールプログラム20が取得するためのDBである。この人事DB42は、本システムメールシステム10内で管理されていてもよく、総務部や人事部等が管理するDBに直接アクセスして情報を取得してもよい。図7に示すメールDB43の項目としては、例えば、利用者ID、フォルダ名、メッセージID、開封状況、回答要求、差出人、宛先、発信日時、メール情報等からなるが、これに限定されるものではない。また、メール情報は、更に細分化して、例えば、タイトル、本文等の項目を有していてもよい。メールDB43は、利用者ID毎に、各フォルダの何れかに蓄積されているメールの開封状況、そのメールの回答要求の有無、差出人、宛先、発信日時、メール情報タイトル、本文等を管理する。なお、図7の例では、利用者IDがhondaxxx.wwのみのメール情報が蓄積されているが、これに限定されずに、メールサーバ11に登録される複数の利用者毎にメールが管理される。また、回答要求が有とするメールの本文には、本文中に含まれるURL等のアクセス情報が含まれる。また、メール情報には、添付ファイル名や添付ファイルの内容等をアクセス情報として含めてもよいが、全てのメールの本文にアクセス情報が含まれているわけではない。図8に示す回答状況DB44の項目としては、例えば、送信日時、期限日時、統括部名、部名、課名、所属コード、所属人数、回答数、回答率、述べアクセス数、一日平均アクセス数一人当り、督促日1、督促日2等からなるが、これに限定されるものではない。回答状況DB44は、回答用URL毎に存在する。図8の例では、URLが、例えばhttp://www.kaitou3.ne.jp/kaitou3.htmlの例を示している。なお、図8の例では、統括部名、部名、課名毎の回答状況が設定されている。これにより、統括部単位、部単位、課単位の回答状況を容易に確認することができる。また、図8の例では、督促日として最大2つの日付督促日1、督促日2を設定することができるが、これに限定されるものではなく、例えば1つの日付でも、3つ以上の日付を設定することができる。第1実施例では、データ更新部32により回答状況DB44の更新が行われ、回答状況取得部24により回答状況DB44を参照することで、回答状況を容易且つ適切に把握することができる。図9に示すメールURL対応DB45の項目としては、メッセージID、回答用URLからなるが、これに限定されるものではない。メールURL対応DB45は、回答を必要とするメールに対して、そのメッセージIDと、アクセス情報であるURLとを対応づけて管理するためのDBである。なお、アクセス情報としては、URLに限定されず、例えば添付ファイル名等であってもよい。また、メッセージIDに対応するアクセス情報は、1つに限定されずに複数あってもよく、その場合のアクセス情報は、URL及びファイル名のうちの一方でもよく、また両方であってもよい。図10に示す設定DB46の項目としては、設定対象、閾値からなるが、これに限定されるものではない。設定DB46は、例えば回答期限メール毎に存在する。図10の例では、例えば、anke-toxxx.wwの例を示している。第1実施例では、設定DB46の内容に基づいて督促文の内容を判断するための処理が行われる。ここで、設定対象としては、例えば複数のクライアント端末のうち管轄端末が管轄する少なくとも一部のクライアント端末12における電子メールの開封率、受信メール数、及びアクセス情報へのアクセス回数のうち、少なくとも1つであればよい。なお、設定対象は、これに限定されるものではない。図11に示す督促文DB47の項目としては、パターン、督促文からなるが、これに限定されるものではない。督促文DB47は、設定DB46を用いた督促文の判定を行う処理により、判定されたパターン例えば、開封率、受信メール数、アクセス数、閾値外定型に対応した督促文を管理するためのDBである。また、督促文の一部には、図11に示すように変数部分を有していてもよい。その変数部分には、例えば、人事DB42等から得られた部署管理者の氏名や、発信者の氏名、回答期限付きメールの件名、部署名等が入力される。なお、第1実施例におけるパターンの種類及び督促文の内容等については、これに限定されるものではない。<第1実施例のメールサーバ11におけるメールプログラム20の処理手順例>次の説明では、上述した第1実施例のメールサーバ11におけるメールプログラム20の処理手順例について、フローチャートを用いて説明する。図12は、第1実施例のメールプログラムにおける処理手順の一例を示すフローチャートである。図12の例において、メールプログラム20は、メール利用要求をクライアント端末12から受信したか否かを判断しS01、受信していない場合S01において、NO、S01に戻り、受信があるまで待機する。なお、以下の説明において、受信したか否かとは、例えば所定時間内に受信したか否かが判断されるものとする。また、メールプログラム20は、受信があった場合S01において、YES、利用者ID、パスワード入力画面をクライアント端末12に送信するS02。次に、メールプログラム20は、利用者情報として利用者ID、パスワードを受信したか否かを判断しS03、受信していない場合S03において、NO、S03に戻り、受信があるまで待機する。また、メールプログラム20は、受信があった場合S03において、YES、利用者認証DB41を用いて、認証を行うS04。次に、メールプログラム20は、認証OKか否かを判断しS05、認証OKである場合S05において、YES、アクセス数計算処理を行うS06。なお、アクセス数計算処理については、後述する。次に、メールプログラム20は、メッセージ作成要求をクライアント端末12から受信したか否かを判断するS07。メールプログラム20は、メッセージ作成要求を受信した場合S07において、YES、送信処理を行うS08。なお、送信処理については、後述する。メールプログラム20は、S08の処理の終了後、又は上述したS08の処理において、メッセージ作成要求を受信していない場合S07において、NO、送信メール表示要求をクライアント端末12から受信したか否かを判断するS09。メールプログラム20は、送信メール表示要求をクライアント端末12から受信した場合S09において、YES、回答状況送信処理を行うS10。なお、回答状況送信処理については、後述する。また、メールプログラム20は、S10の終了後、又はS09の処理において、送信メール表示要求をクライアント端末12から受信していない場合S09において、NO、処理を終了する。なお、メールプログラム20は、上述したS05の処理において、認証OKでなかった場合S05において、NO、認証エラー画面を作成し、クライアント端末12に送信しS11、処理を終了する。<S06:アクセス数計算処理の処理手順>図13は、第1実施例におけるアクセス数計算処理手順の一例を示すフローチャートである。図13の例において、メールプログラム20は、人事DB42を用いて、その利用者IDの所属コードを取得するS21。次に、メールプログラム20は、回答状況DB44に、S21で取得した所属コードを含む回答状況データが存在するか否かを判断するS22。メールプログラム20は、その所属コードを含む回答状況データが存在する場合S22において、YES、回答状況DB44の述べアクセス数をインクリメント1増加するS23。なお、この場合には、上記所属コードの階層に相当する所属の述べアクセス数もインクリメントする。次に、メールプログラム20は、それぞれの回答状況DB44の一日平均アクセス数を計算し、更新する。<S08:送信処理手順>図14は、第1実施例のメールサーバにおける送信処理手順の一例を示すフローチャートである。図14の例において、メールプログラム20は、メッセージ作成画面を作成し、クライアント端末12に送信するS31。次に、メールプログラム20は、一般メール情報、宛先、タイトル、記事本文を受信したか否かを判断しS32、上述の情報を受信した場合S32において、YES、本メールを識別するためのメッセージID、ヘッダ情報等を作成するS33。また、メールプログラム20は、宛先のメールDBの受信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求0を記録するS34。なお、回答要求が0とは、回答要求がないことを意味するが、回答要求がないことを意味する種別であれば、0以外の他の種別が記録されてもよい。また、メールプログラム20は、差出人のメールDBの送信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求0を記録するS35。また、メールプログラム20は、上述したS32の処理において、一般メール情報、宛先、タイトル、記事本文を受信していない場合S32において、NO、次に、回答要求メール情報、宛先、タイトル、記事本文、回答用URLを受信したか否かを判断するS36。メールプログラム20は、上述した情報を受信していない場合S36において、NO、S32に戻る。また、メールプログラム20は、上述した情報を受信した場合S36において、YES、メッセージID、ヘッダ情報等を作成するS37。次に、メールプログラム20は、メッセージIDと、回答用URLとを対応づけてメールURL対応DBに記録するS38。次に、メールプログラム20は、宛先のメールDBの受信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求1を記録するS39。なお、回答要求が1とは、回答要求があることを意味するが、回答要求があることを意味する種別であれば、1以外の他の種別が記録されてもよい。次に、メールプログラム20は、差出人のメールDBの送信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求1を記録するS40。次に、メールプログラム20は、回答用URL毎の回答状況DB44を作成し、人事DB42を用いて、宛先に相当する所属名、所属人数を記録するS42。<S10:回答状況送信処理手順>図15は、第1実施例における回答状況送信処理手順の一例を示すフローチャートである。図15の例において、メールプログラム20は、利用者IDのメールDB43から送信フォルダ内のメールを取得しS51、メールDB43から、当利用者IDの送信メールを取得し、送信メール表示画面を作成するS52。次に、メールプログラム20は、送信メール表示画面をクライアント端末12に送信するS53。次に、メールプログラム20は、メッセージIDと、回答状況表示要求を受信したか否かを判断しS54、受信した場合S54において、YES、メールURL対応DB45に基づいて、メッセージIDに対応するURLを取得するS55。また、メールプログラム20は、そのメールの回答状況表示画面を、取得したURLの回答状況DB44を用いて作成しS56、作成した回答状況表示画面をクライアント端末12に送信するS57。ここで、メールプログラム20は、S57の処理の終了後、又はS54の処理において、メッセージIDと、回答状況表示要求を受信していない場合S54において、NO、部署名と、督促要求とをクライアント端末12から受信したか否かを判断するS58。メールプログラム20は、クライアント端末12から上述した情報を受信していない場合S58において、NO、S58に戻り、受信するまで待機する。また、メールプログラム20は、クライアント端末12から上述した情報を受信した場合S58において、YES、選択された部署の代表者を人事DB42から取得するS59。次に、メールプログラム20は、選択された部署の開封率をメールDB43から算出するS60。ここで、メールプログラム20は、設定DB46の開封率の閾値よりも低いか否かを判断しS61、開封率の閾値よりも低い場合S61において、YES、督促文DB47の開封率に対応する督促文を取得するS62。また、メールプログラム20は、開封率の閾値よりも低くない場合S61において、NO、選択された部署の平均受信メール数をメールDB43から算出するS63。次に、メールプログラム20は、設定DB46の受信メールの閾値よりも高いか否かを判断しS64、受信メールの閾値よりも高い場合S64において、YES、督促文DB47の受信メール数に対応する督促文を取得するS65。また、メールプログラム20は、受信メールの閾値よりも高くない場合S64において、NO、選択された部署の平均アクセス数を回答状況DB44から取得するS66。次に、メールプログラム20は、設定DB46のアクセス数よりも低いかを判断しS67、アクセス数よりも低くない場合S67において、NO、督促文DB47から定型の督促文を取得するS68。S62の処理後、S65の処理後、S68の処理後、又はS67の処理において、設定DB46のアクセス数よりも低い場合S67において、YES、人事DB42を用いて、取得した督促文内にある変数に、代表者、部署名を代入するS69。また、メールプログラム20は、部署の代表者例えば、管轄端末に対して、取得した督促文を送信しS70、督促修了通知をクライアントに送信するS71。<メールサーバ11における回答状況データ作成プログラム30の処理手順例>以下の説明では、メールサーバ11における回答状況データ作成プログラム30の処理手順例について、フローチャートを用いて説明する。図16は、第1実施例のメールサーバにおける回答状況データ作成プログラムの処理手順の一例を示すフローチャートである。図16の例において、回答状況データ作成プログラム30は、回答用URLから回答を受信したか否かを判断するS81。回答状況データ作成プログラム30は、回答を受信した場合S81において、YES、所属コードの入力を受け付けているか否かを判断するS82。ここで、回答状況データ作成プログラム30は、所属コードの入力を受け付けている場合S82において、YES、回答状況DB44のその所属コードに対応する回答数をインクリメント1増加するS83。また、回答状況データ作成プログラム30は、回答率を計算し、回答状況DB44の回答率を更新するS84。ここで、回答状況データ作成プログラム30は、利用者等の指示等により処理を終了するか否かを判断しS85、処理を終了しない場合S85において、NO、S81に戻る。また、回答状況データ作成プログラム30は、S85において、処理を終了する場合S85において、YES、回答状況データ作成処理を終了する。なお、回答状況データ作成プログラム30は、上述したS81の処理において、回答用URLから回答を受信していない場合S81において、NO、S81に戻る。また、回答状況データ作成プログラム30は、上述したS82の処理において、所属コードの入力を受け付けていない場合S82において、NO、S81に戻る。<クライアント端末12における表示プログラム50の処理手順例>次の説明では、クライアント端末12における表示プログラム50の処理手順例について、フローチャートを用いて説明する。図17は、第1実施例における表示プログラムの処理手順の一例を示すフローチャートである。図17の例において、表示プログラム50は、メール利用要求を利用者から受け付けたか否かを判断するS91。表示プログラム50は、メール利用要求を受け付けていない場合S91において、NO、S91に戻り、メール利用要求を受け付けるまで待機する。また、表示プログラム50は、メール利用要求を受け付けた場合S91において、YES、メールサーバ11に、メール利用要求を送信するS92。次に、表示プログラム50は、メールサーバ11から、利用者ID、パスワード入力画面を受信したか否かを判断するS93。ここで、表示プログラム50は、上記画面を受信していない場合S93において、NO、S93に戻り、受信するまで待機する。また、表示プログラム50は、上記画面を受信した場合S93において、YES、利用者ID、パスワード入力画面を表示するS94。ここで、表示プログラム50は、利用者ID、パスワードの入力を受け付けたか否かを判断しS95、上記入力を受け付けていない場合S95において、NO、S95に戻り、上記入力があるまで待機する。また、表示プログラム50は、上記入力を受け付けた場合S95において、YES、利用者情報である利用者ID、パスワードをメールサーバ11に送信するS96。なお、利用者ID、パスワードは、クライアント端末12が備える入力部等により入力されてもよく、予めメモリ等の記憶部に記憶されていてもよい。次に、表示プログラム50は、認証エラー画面を受信したか否かを判断しS97、認証エラー画面を受信していない場合S97において、NO、メッセージ作成要求を受け付けたか否かを判断するS98。表示プログラム50は、メッセージ作成要求を受け付けた場合S98において、YES、送信処理を行うS99。なお、送信処理については、後述する。また、表示プログラム50は、S99の処理の終了後、又はS98の処理において、メッセージ作成要求を受け付けていない場合S98において、NO、送信メール表示要求を受け付けたか否かを判断するS100。ここで、表示プログラム50は、送信メール表示要求を受け付けた場合S100において、YES、メールサーバ11に送信メール表示要求を送信するS101。また、表示プログラム50は、送信メール表示画面をメールサーバ11から受信したか否かを判断しS102、送信メール表示画面を受信していない場合S102において、NO、S102に戻り、送信メール表示画面を受信するまで待機する。また、表示プログラム50は、送信メール表示画面を受信した場合S102において、YES、送信メール表示画面をメール表示部53に表示する。表示プログラム50は、S103の処理後、又はS100の処理において、送信メール表示要求を受け付けていない場合S100において、NO、メールの選択と、回答状況表示要求を受け付けたか否かを判断するS104。表示プログラム50は、メールの選択と、回答状況表示要求を受け付けた場合S104において、YES、メールサーバ11に、選択されたメールのメッセージIDと回答状況表示要求を送信するS105。また、表示プログラム50は、S105の処理が終了後、又はS104の処理において、メールの選択と、回答状況表示要求を受け付けなかった場合S104において、NO、回答状況表示画面をメールサーバ11から受信したか否かを判断するS106。ここで、表示プログラム50は、回答状況表示画面を受信していない場合S106において、NO、S106に戻り、回答状況表示画面を受信するまで待機する。また、表示プログラム50は、回答状況表示画面を受信した場合S106において、YES、回答状況表示画面を表示するS107。また、表示プログラム50は、部署の選択と、督促要求を受け付けたか否かを判断しS108、部署の選択と、督促要求を受け付けていない場合S108において、NO、S108に戻り、部署の選択と、督促要求を受け付けるまで待機する。また、表示プログラム50は、部署の選択と、督促要求を受け付けた場合S108において、YES、選択された部署名と、督促要求をメールサーバ11に送信するS109。次に、表示プログラム50は、督促送信修了通知をメールサーバ11から受信したか否かを判断しS110、督促送信修了通知を受信していない場合S110において、NO、S110に戻り、督促送信修了通知を受信するまで待機する。また、表示プログラム50は、督促送信修了通知を受信した場合S110において、YES、督促送信修了通知を表示するS111。また、表示プログラム50は、S97の処理において、認証エラー画面を受信した場合S97において、YES、認証エラー画面を表示するS112。<S99:送信処理手順>図18は、第1実施例のクライアント端末における送信処理手順の一例を示すフローチャートである。図18の例において、表示プログラム50は、メールサーバ11にメッセージ作成要求を送信しS121、メッセージ作成画面をメールサーバ11から受信したか否かを判断するS122。表示プログラム50は、メッセージ作成画面を受信していない場合S122において、NO、S122に戻り、メッセージ作成画面を受信するまで待機する。また、表示プログラム50は、メッセージ作成画面を受信した場合S122において、YES、メッセージ作成画面をメール表示部53に表示するS123。また、表示プログラム50は、宛先、タイトル、記事本文等の入力を受け付けるS124。ここで、表示プログラム50は、一般メール送信要求を受け付けたか否かを判断しS125、一般メール送信要求を受け付けた場合S125において、YES、一般メール情報、宛先、タイトル、記事本文をメールサーバ11に送信するS126。また、表示プログラム50は、一般メール送信要求を受け付けていない場合S125において、NO、回答要求メール送信要求を受け付けたか否かを判断するS127。表示プログラム50は、回答要求メール送信要求を受け付けていない場合S127において、NO、S125に戻る。また、表示プログラム50は、回答要求メール送信要求を受け付けた場合S127において、YES、回答用URLの受け付け画面をメール表示部53に表示し、URLを受け付けるS128。また、表示プログラム50は、回答要求メール情報、宛先、タイトル、記事本文、回答用URLをメールサーバ11に送信するS129。なお、第1実施例では、上述した図12~図18に示した各処理が、第1実施例におけるメール督促処理に相当する。第1実施例では、上述した各処理手順により、例えば、回答期限付きメールを複数の宛先に送信した際に、宛先が所属する組織毎の受信メールの受信状況によって、組織管理者に送付する回答督促文面を異ならせて作成することができる。これにより、第1実施例では、電子メールの受信状況に基づいて適切なメールの督促を効率的に行うことで、回答依頼に対する回答率を向上させることができる。したがって、例えば、Webアンケートシステム上での回答を電子メールで要求する際には、メッセージIDメール識別情報とメール記載のURL等のアクセス情報とを管理し、回答率と電子メール開封率とに基づく情報を利用者へ提供することで、低回答率への対策構築を支援することができる。具体的には、督促文を受信した部署管理者は、自らが管理する部署のメンバに、未開封であることが多い、その後の受信メールが多いために埋もれている可能性が高い等の情報を伝えることができる。これによって、部署のメンバは、未回答メールを無闇に探すことがなくなるという効果がある。<第1実施例における画面例>以下の説明では、第1実施例における画面例について図を用いて説明する。図19は、メッセージ作成画面の一例を示す図である。図19に示すメッセージ作成画面70は、ボタン領域71と、文字入力領域72とを有するが、これに限定されるものではない。図19の例では、ボタン領域71に、一般メール送信ボタンと、回答要求メール送信ボタンと、ログアウトボタンとを有する。また、図19の例では、文字入力領域72に、宛先、CC、件名、記事入力画面等を有するが、これに限定されるものではない。利用者は、ボタン領域71の一般メール送信ボタンと回答要求メール送信ボタンにより、一般メール送信、又は第1実施例における回答要求メール送信の何れかを選択することができる。ここで、第1実施例では、回答要求メール送信を選択することで、上述したメール督促処理を行うことができる。なお、ログアウトを選択すると、メッセージ作成画面70が終了する閉じる。また、文字入力領域72において、例えば、宛先には、a-toukatu-mlxxx.ww,b-toukatu-mlxxx.wwと入力される。また、件名には、職場アンケート回答用と入力される。また、記事入力画面には、総務部の本田です。職場アンケートのご協力をお願いします。このアンケートは、職場活性化のために、毎年実施しているものです。多忙かと思われますが、7月23日までにご回答願います。と入力される。ここで、図20は、回答用紙追加画面を表示したメール送信画面例を示す図である。図20の例では、上述したメッセージ作成画面70の他に、回答設定画面80が表示されている。回答設定画面80は、回答要求メール送信を選択することで、表示される画面である。回答設定画面80には、例えば、回答用紙がURLの場合のURL入力領域81と、回答用紙が添付ファイルの場合のファイル名入力領域82と、回答期限を設定するための回答期限設定領域83とを有する。URL入力領域81には、メール内容に、回答用URLとして追記されるURLの内容が入力される。また、ファイル名入力領域82には、回答用紙が添付ファイルの場合に、その回答用紙のファイルを選択することで、そのファイル名がアクセス情報として入力される。また、回答期限設定領域83には、選択された回答期限が設定される。また、回答設定画面80には、確定ボタンやキャンセルボタンを有し、何れかを選択することで、設定事項の確定又はキャンセルが行われる。ここで、図21は、メール内容の一例を示す図である。図21では、上述した図20の回答設定画面80で設定された内容がメール内容として表示されている。なお、図21に示すメール内容に含まれるアドレス情報としてのURLhttp://www.kaitou2.ne.jp/kaitou2.htmlは、ハイパーリンク表示することができる。したがって、メール受信者は、上記URLの表示部分にカーソルを合わせてクリックすると、対応するサイトに画面をジャンプさせることができる。図22は、送信メール表示画面の一例を示す図である。図22に示す送信メール表示画面90は、例えば、ボタン領域91と、送信フォルダの内容表示領域92とを有する。ボタン領域91には、例えば、回答状況表示ボタン及びログアウトボタンを有する。送信メール表示画面90において、利用者は、回答状況を表示したいメールを選択し、回答状況表示ボタンを押すことで、選択したメールに対応する回答状況を表示することができる。なお、第1実施例では、回答要の設定をしていないメールは選択ボタンが表示されない。また、図22の例では、回答状況が表示できるメールであるか否かの識別情報93を有する。例えば、図22の例では、識別情報93-1の表示の場合には、対応する回答状況が表示でき、識別情報93-2の表示の場合には、回答する回答状況が表示できないが、識別情報の種類等がこれに限定されるものではない。図23は、回答状況表示画面の一例を示す図である。図23に示す例では、回答状況表示画面100の一例として、部署別の回答状況表示画面100が表示されている。利用者は、クライアント端末12から督促メールを送信したい部署例えば、統括部名、部名、課名等を1又は複数選択し、督促要求ボタンを選択することで、対象部署に適切な督促文からなる督促メールを送信する。なお、図23における選択クリアボタンは、現在選択している部署を全てクリアするときに用いられる。図23では、表示される項目として、例えば選択、統括部名、部名、課名、所属人数、回答率、開封率、一日平均アクセス数、一人当たり平均受信メール数、督促日情報等が表示されているが、これに限定されるものではない。また、図23の例では、各項目のうち、設定DB46の条件に当てはまらない状況例えば、回答の悪い状況にある項目については、その数値を強調表示例えば、太字、色分け、点滅等の表示を行うことができる。図23の例では、例えばA-1-1課の開封率や、A-2部の一人当たり平均受信メール数等が強調表示されている。これにより、利用者は、容易に督促対象のメールを把握することができる。また、図23の例において、回答率及び開封率のカッコ書きの数値は、以前に督促をした場合に、その督促時点での回答率及び開封率を示している。例えば、図23の例では、A統括部の回答率403012とは、現時点の回答率が40で、前回督促時の回答率が30で、前々回督促時の回答率が12であったことを示している。これにより、第1実施例では、督促による部署の回答状況や、督促後の回答率の伸び率等のより詳細な情報を取得することができる。なお、第1実施例では、一つのメールの複数の回答用URLが含まれる場合もある。そのような場合には、メールURL対応DB45に、一つのメッセージIDに複数のURLが対応づけられることになる。そのため、上述した回答状況表示画面100は、例えば、複数のURLに対応して複数存在することになる。また、図24は、督促文のメール例を示す図である。図24aでは、B統括部を選択した場合のB統括部長宛ての督促文の一例を示し、図24bでは、A-2-1課を選択した場合の、A-2-1課長宛ての督促文の一例を示している。つまり、図24の例では、B統括部長の端末及びA-2-1課長の端末が、管轄端末としてのクライアント端末となる。図24a、図24bに示すように、同一の回答要求メールに対する督促であったとしても部署の回答状況に基づいて、適切な督促文を適切なタイミングで効率的に送信することができる。なお、第1実施例における上述した各画面例は、例えばクライアント端末12がWebメール等を用いた場合にブラウザ表示されるものである。つまり、クライアント端末12は、メールサーバ11にアクセスし、メールサーバ11が作成した各画面を取得して表示部に表示する。これにより、第1実施例では、具体的には、督促文を受信した部署管理者は、自らが管理する部署のメンバに、未開封であることが多い、その後の受信メールが多いために埋もれている可能性が高い等の適切な情報を伝えることができる。これによって、部署のメンバは、未回答メールを無闇に探すことがなくなるという効果がある。第1実施例では、例えば、回答期限付きメールを複数の宛先に送信した際に、宛先が所属する組織毎の受信メールの受信状況によって、組織管理者に送付する回答督促文面を異ならせて作成することができる。これにより、第1実施例では、電子メールの受信状況に基づいて適切なメールの督促を効率的に行うことで、回答依頼に対する回答率を向上させることができる。したがって、例えば、Webアンケートシステム上での回答を電子メールで要求する際には、メッセージIDメール識別情報とメール記載のURL等のアクセス情報とを管理し、回答率と電子メール開封率とに基づく情報を利用者へ提供することで、低回答率への対策の構築を支援することができる。<第2実施例>上述した第1実施例では、例えばWebメール等を用いてメール閲覧等を行う構成について説明した。他の実施例としては、例えばOUTLOOK登録商標等のいわゆるPOPPostOfficeProtocol型のメールソフトウェアメーラー機能を備えたクライアント端末に対しても上述したメール督促処理を適用することができる。以下の説明では、上述した内容に対応する実施例を第2実施例として説明する。なお、第2実施例におけるメールシステムのシステム構成、及びメールサーバの機能構成については、第1実施例と同様の構成を適用できるため、ここでの具体的な説明は省略する。また、第2実施例では、例えば第1実施例と同様にWeb上の質問に対する回答を要求する電子メール等が用いられる。<第2実施例:クライアント端末12の機能構成例>図25は、第2実施例におけるクライアント端末の機能構成の一例を示す図である。図25では、説明の便宜上、メールサーバ11を簡略的に示しているが、メールサーバ11は図2に示す構成等を有するものである。以下の説明において、上述した第1実施例と略同一の処理を行う構成部分については、同一の符号を付するものとし、ここでの説明は省略する。図25に示すクライアント端末12は、表示プログラム50を有する。表示プログラム50は、メール表示要求部51と、利用者情報送信部52と、メール表示部53と、メール送信部54と、回答送信部55と、回答状況表示要求部56と、回答状況受信部57と、回答状況表示部58と、回答状況要求受付部101とを有する。また、第2実施例におけるクライアント端末12は、記憶部としてメールDB102を有する。ここで、第2実施例におけるクライアント端末12は、第1実施例におけるクライアント端末12と比較して第2実施例に回答状況要求受付部101及びメールDB102を有する。回答状況要求受付部101は、利用者からの回答状況の要求を受け付け、受け付けた内容で、回答状況表示要求部56に回答状況の表示要求を行う。回答状況表示要求部56は、回答依頼側のクライアントが、回答状況を表示したい場合に、回答状況表示要求をメールサーバ11に送信する。メールDB102は、メールサーバ11から受信した利用者に対応するメール情報を蓄積しておくためのDBである。つまり、メール表示手段53は、メールDB102に蓄積されたメール情報を表示することができると共に、メールサーバ11のメールDB102から取得したメール情報も表示することができる。ここで、第2実施例におけるメールサーバメール装置11及びクライアント端末12においては、第1実施例と同様に、各機能をコンピュータに実行させることができる実行プログラム例えば、メール督促プログラムメールプログラムや回答状況データ作成プログラム等、表示プログラムを作成し、例えば汎用のパーソナルコンピュータ、サーバ、携帯端末、ゲーム機器等にその実行プログラムをインストールすることにより、メール督促処理等を実現することができる。ここで、本実施例におけるメール督促処理が実現可能なコンピュータのハードウェア構成例については、上述した第1実施例におけるハードウェア構成と同様であるため、ここでの具体的な説明は省略する。<データベース例>ここで、第2実施例に示すデータベース例について説明する。なお、第2実施例では、メールDBをメールサーバ11側と、クライアント端末12側とに設けている。また、それ以外のDBは、上述した第1実施例と同様のDBを適用することができる。したがって、以下に示すDBの説明では、メールDBについて説明し、他のDBについての具体的な説明は省略する。図26は、第2実施例におけるメールDBのデータ例を示す図である。なお、図26aは、メールサーバ11側のメールDB43のデータ例を示し、図26bは、クライアント端末12側のメールDB102のデータ例を示している。図26aに示すメールDB43の項目としては、利用者ID、フォルダ名、メッセージID、回答要求、差出人、宛先、発信日時、メール情報からなるが、これに限定されるものではない。また、図26bに示すメールDB102の項目としては、利用者ID、フォルダ名、メッセージID、開封状況、回答要求、差出人、宛先、発信日時、メール情報からなるが、これに限定されるものではない。また、図26a、図26bに示すメール情報は、更に細分化して、例えば、タイトル、本文等の項目を有していてもよい。つまり、第2実施例においては、メールサーバ11のメールDB43に蓄積されるメール情報は、クライアント端末12に送信されていないメール情報であり、送信後は即時又は所定期間経過後に削除されるものである。また、メールサーバ11のメールDB43は、利用者ID毎に、上述した情報が管理されており、クライアント端末12には、その端末の利用者ユーザのメール情報が管理される。また、本文には、本文中に含まれるURL等のアクセス情報等が含まれる。また、メール情報には、添付ファイル名や添付ファイルのデータの内容等をアクセス情報として含めてもよい。つまり、第2実施例におけるいわゆるPOP型のメーラーでは、例えば未受信のメールがメールサーバ11側のメールDB43に保存される。また、第2実施例では、クライアント端末12により受信されたものが開封/未開封に関わらずクライアント端末12側のメールDB102に保存される。したがって、第2実施例では、クライアント端末12側のメールDB112に開封状況の項目が含まれている。<第2実施例のメールサーバ11におけるメールプログラム20の処理手順例>次の説明では、第2実施例のメールサーバ11におけるメールプログラム20の処理手順例について、フローチャートを用いて説明する。図27は、第2実施例のメールプログラムにおける処理手順の一例を示すフローチャートである。図27の例において、メールプログラム20は、メール利用要求をクライアント端末12から受信したか否かを判断しS131、受信していない場合S131において、NO、S131に戻り、受信があるまで待機する。また、メールプログラム20は、受信があった場合S131において、YES、利用者ID、パスワード入力画面をクライアント端末12に送信するS132。次に、メールプログラム20は、利用者情報として利用者ID、パスワードを受信したか否かを判断しS133、受信していない場合S133において、NO、S133に戻り、受信があるまで待機する。また、メールプログラム20は、受信があった場合S133において、YES、利用者認証DB41を用いて、認証を行うS134。次に、メールプログラム20は、認証OKか否かを判断しS135、認証OKである場合S135において、YES、アクセス数計算処理を行うS136。なお、アクセス数計算処理については、上述した第1実施例におけるアクセス数計算処理と同様の処理を行うことができるため、ここでの具体的な説明は省略する。次に、メールプログラム20は、送信処理を行いS137、処理を終了する。なお、メールプログラム20は、上述したS135の処理において、認証OKでなかった場合S135において、NO、認証エラー画面を作成し、クライアント端末12に送信しS138、処理を終了する。<S137:送信処理手順>図28は、第2実施例のメールサーバにおける送信処理手順の一例を示すフローチャートである。図28の例において、メールプログラム20は、一般メール情報、宛先、タイトル、記事本文を受信したか否かを判断するS141。上述の情報を受信した場合S141において、YES、メールプログラム20は、宛先のメールDBの受信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求0を記録するS142。なお、回答要求が0とは、回答要求がないことを意味するが、回答要求がないことを意味する種別であれば、0以外の他の種別が記録されてもよい。また、メールプログラム20は、差出人のメールDBの送信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求0を記録するS143。また、メールプログラム20は、上述したS141の処理において、一般メール情報、宛先、タイトル、記事本文を受信していない場合S141において、NO、次に、回答要求メール情報、宛先、タイトル、記事本文、回答用URL、ヘッダ情報を受信したか否かを判断するS144。メールプログラム20は、また、メールプログラム20は、上述した情報を受信した場合S144において、YES、メッセージIDと、回答用URLとを対応づけてメールURL対応DBに記録するS145。次に、メールプログラム20は、宛先のメールDBの受信フォルダ欄に、メッセージID、タイトル、記事本文、差出人、回答要求1を記録するS146。なお、回答要求が1とは、回答要求があることを意味するが、回答要求があることを意味する種別であれば、1以外の他の種別が記録されてもよい。次に、メールプログラム20は、回答状況表示要求をクライアント端末12から受信したか否かを判断しS147、回答状況表示要求を受信していない場合S147において、NO、S147に戻り、受信するまで待機する。また、メールプログラム20は、回答状況表示要求を受信した場合S147において、YES、回答状況表示処理を行うS148。回答状況表示処理については、後述する。なお、上述したS144の処理において、回答要求メール情報、宛先、タイトル、記事本文、回答用URL、ヘッダ情報を受信していない場合S144において、NO、そのまま処理を終了する。<S148:回答状況送信処理手順>図29は、第2実施例における回答状況送信処理手順の一例を示すフローチャートである。図29の例において、メールプログラム20は、メッセージIDと、回答状況表示要求を受信したか否かを判断しS151、受信した場合S151において、YES、メールURL対応DB45に基づいて、メッセージIDに対応するURLを取得するS152。また、メールプログラム20は、取得したURLに対応する回答状況DBから、所属名例えば、統括部名、部名、課名等、所属人数、回答数、回答率、一日平均アクセス数等を取得するS153。また、メールプログラム20は、取得した所属名例えば、統括部名、部名、課名等、所属人数、回答数、回答率、一日平均アクセス頻度等をクライアント端末12に送信するS154。ここで、メールプログラム20は、S154の処理の終了後、又はS151の処理において、メッセージIDと、回答状況表示要求を受信していない場合S151において、NO、部署名と、督促要求とをクライアント端末12から受信したか否かを判断するS155。メールプログラム20は、クライアント端末12から上述した情報を受信していない場合S155において、NO、S155に戻り、受信するまで待機する。また、メールプログラム20は、クライアント端末12から上述した情報を受信した場合S155において、YES、選択された部署の代表者を人事DB42から取得するS156。次に、メールプログラム20は、選択された部署の開封率をメールDB43から算出するS157。ここで、メールプログラム20は、設定DB46の開封率の閾値よりも低いか否かを判断しS158、開封率の閾値よりも低い場合S158において、YES、督促文DB47の開封率に対応する督促文を取得するS159。また、メールプログラム20は、開封率の閾値よりも低くない場合S158において、NO、選択された部署の平均受信メール数をメールDB43から算出するS160。次に、メールプログラム20は、設定DB46の受信メールの閾値よりも高いか否かを判断しS161、受信メールの閾値よりも高い場合S161において、YES、督促文DB47の受信メール数に対応する督促文を取得するS162。また、メールプログラム20は、受信メールの閾値よりも高くない場合S161において、NO、選択された部署の平均アクセス数を回答状況DB44から取得するS163。次に、メールプログラム20は、設定DB46のアクセス数よりも低いかを判断しS164、アクセス数よりも低くない場合S164において、NO、督促文DB47から定型の督促文を取得するS165。S159の処理後、S162の処理後、S165の処理後、又はS164の処理において、設定DB46のアクセス数よりも低い場合S164において、YES、取得した督促文について、人事DB42を用いて、代表者、部署名の変数を代入するS166。また、メールプログラム20は、部署の代表者例えば、管轄端末に対して、取得した督促文を送信しS167、督促修了通知をクライアント端末12に送信するS168。ここで、第2実施例のメールサーバ11における回答状況データ作成プログラム30の処理手順については、上述した第1実施例と同様の処理を行うため、ここでの具体的な説明は省略する。<第2実施例のクライアント端末12における表示プログラム50の処理手順例>次の説明では、第2実施例のクライアント端末12における表示プログラム50の処理手順例について、フローチャートを用いて説明する。図30は、第2実施例における表示プログラムの処理手順の一例を示すフローチャートである。図30の例において、表示プログラム50は、メール利用要求を利用者から受け付けたか否かを判断するS171。なお、利用者とは、例えば上述したクライアントユーザを意味する。表示プログラム50は、メール利用要求を受け付けていない場合S171において、NO、S171に戻り、メール利用要求を受け付けるまで待機する。また、表示プログラム50は、メール利用要求を受け付けた場合S171において、YES、メールサーバ11に、メール利用要求を送信するS172。次に、表示プログラム50は、メールサーバ11から、利用者ID、パスワード入力要求を受信したか否かを判断するS173。ここで、表示プログラム50は、上記要求を受信していない場合S173において、NO、S173に戻り、受信するまで待機する。また、表示プログラム50は、上記要求を受信した場合S173において、YES、利用者ID、パスワード入力画面を表示するS174。ここで、表示プログラム50は、利用者ID、パスワードの入力を受け付けたか否かを判断しS175、上記入力を受け付けていない場合S175において、NO、S175に戻り、上記入力があるまで待機する。また、表示プログラム50は、上記入力を受け付けた場合S175において、YES、利用者ID、パスワードをメールサーバ11に送信するS176。なお、利用者ID、パスワードは、クライアント端末12が備える入力部等により入力されてもよく、予めメモリ等の記憶部に記憶されていてもよい。次に、表示プログラム50は、認証エラー画面を受信したか否かを判断しS177、認証エラー画面を受信していない場合S177において、NO、メッセージ作成要求を受け付けたか否かを判断するS178。表示プログラム50は、メッセージ作成要求を受け付けた場合S178において、YES、送信処理を行うS179。なお、送信処理については、後述する。また、表示プログラム50は、S179の処理の終了後、又はS178の処理において、メッセージ作成要求を受け付けていない場合S178において、NO、送信メール表示要求を受け付けたか否かを判断するS180。ここで、表示プログラム50は、送信メール表示要求を受け付けた場合S180において、YES、クライアント端末12側のメールDB102から送信フォルダ内のメールを取得するS181。また、表示プログラム50は、S181の処理で取得したメール情報に基づいて、送信メール表示画面を作成し、メール表示部53に表示する。表示プログラム50は、S182の処理後、又はS180の処理において、送信メール表示要求を受け付けていない場合S180において、NO、メールの選択と、回答状況表示要求を受け付けたか否かを判断するS183。表示プログラム50は、メールの選択と、回答状況表示要求を受け付けた場合S183において、YES、メールサーバ11に、選択されたメールのメッセージIDと回答状況表示要求を送信するS184。また、表示プログラム50は、S184の処理が終了後、又は183の処理において、メールの選択と、回答状況表示要求を受け付けなかった場合S183において、NO、以下の判断を行う。具体的には、表示プログラム50は、メールサーバ11から、所属名例えば、統括部名、部名、課名等、所属人数、回答数、回答率、一日平均アクセス数等を受信したか否かを判断するS185。ここで、表示プログラム50は、上述した情報を受信していない場合S185において、NO、S185に戻り、上述した情報を受信するまで待機する。また、表示プログラム50は、上述した情報を受信した場合S185において、YES、受信した所属名、所属人数、回答数、回答率、一日平均アクセス数等の情報から、回答状況表示画面を作成し、表示するS186。また、表示プログラム50は、部署の選択と、督促要求を受け付けたか否かを判断しS187、部署の選択と、督促要求を受け付けていない場合S187において、NO、S187に戻り、部署の選択と、督促要求を受け付けるまで待機する。また、表示プログラム50は、部署の選択と、督促要求を受け付けた場合S187において、YES、選択された部署名と、督促要求をメールサーバ11に送信するS188。次に、表示プログラム50は、督促送信修了通知をメールサーバ11から受信したか否かを判断しS189、督促送信修了通知を受信していない場合S189において、NO、S189に戻り、督促送信修了通知を受信するまで待機する。また、表示プログラム50は、督促送信修了通知を受信した場合S189において、YES、督促送信修了通知を表示するS190。また、表示プログラム50は、S177の処理において、認証エラー画面を受信した場合S177において、YES、認証エラー画面を表示するS191。<S179:送信処理手順>図31は、第2実施例のクライアント端末における送信処理手順の一例を示すフローチャートである。図31の例において、表示プログラム50は、メッセージ作成画面をメール表示部53に表示するS201。また、表示プログラム50は、宛先、タイトル、記事本文の入力を受け付けるS202。ここで、表示プログラム50は、一般メール送信要求を受け付けたか否かを判断しS203、一般メール送信要求を受け付けた場合S203において、YES、メッセージID、ヘッダ情報を作成するS204。そして、表示プログラム50は、作成したメッセージID、ヘッダ情報と共に、一般メール情報、宛先、タイトル、記事本文をメールサーバ11に送信するS205。また、表示プログラム50は、一般メール送信要求を受け付けていない場合S203において、NO、回答要求メール送信要求を受け付けたか否かを判断するS206。表示プログラム50は、回答要求メール送信要求を受け付けていない場合S206において、NO、S203に戻る。また、表示プログラム50は、回答要求メール送信要求を受け付けた場合S206において、YES、メッセージID、ヘッダ情報を作成するS207。そして、表示プログラム50は、作成したメッセージID、ヘッダ情報と共に、回答用URLの受け付け画面をメール表示部53に表示し、URLを受け付けるS208。また、表示プログラム50は、回答要求メール情報、宛先、タイトル、記事本文、回答用URLをメールサーバ11に送信するS209。なお、第2実施例では、上述した図27~図31に示した各処理が、第2実施例におけるメール督促処理に相当するが、部分的に上述した第1実施例と同様の処理を行う。また、第2実施例における画面例については、上述した第1実施例における画面例と同一の画面を適用できるため、ここでの具体的な説明は省略する。なお、第1実施例では、表示プログラム50によりブラウザ表示させているが、第2実施例では、表示プログラム50を適用したメールソフトウェアにより、クライアント端末12の表示部に表示される。第2実施例では、上述した各処理手順により、第1実施例と同様に、例えば回答期限付きメールを複数の宛先に送信した際に、宛先が所属する組織毎の受信メールの受信状況によって、組織管理者に送付する回答督促文面を異ならせて作成することができる。これにより、第2実施例では、いわゆるPOP型のメールソフトウェアを備えたクライアント端末に対しても電子メールの受信状況に基づいて適切なメールの督促を効率的に行うことで、回答依頼に対する回答率を向上させることができる。したがって、例えば、アンケートシステム上での回答を電子メールで要求する際には、メッセージIDメール識別情報とメールに付加されたURL等のアクセス情報とを管理し、回答率と電子メール開封率とに基づく情報を利用者へ提供することで、低回答率への対策構築を支援することができる。具体的には、督促文を受信した部署管理者は、自らが管理する部署のメンバに、未開封であることが多い、その後の受信メールが多いために埋もれている可能性が高い等の情報を伝えることができる。これによって、部署のメンバは、未回答メールを無闇に探すことがなくなるという効果がある。なお、上述した第1及び第2実施例については、組み合わせて適用することもできる。したがって、上述した図1に示すメールシステム10のクライアント端末12-1~12-nには、第1実施例のクライアント端末と第1実施例のクライアント端末との一方又は両方を含めることができる。その場合には、メールサーバ11のメールプログラム20等において、アクセスしてきたクライアント端末12がどちらの形態の端末であるかを、利用者情報例えば、利用者IDやパスワード等に基づいて管理し、端末の形態に対応させて、上述した処理を実行させる。更に、1つのクライアント端末が、上述した第1及び第2の実施例の両方を実現するための構成を有していてもよく、その場合には利用者の選択により何れかの処理が行われる。以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形、変更が可能である。"