情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持するフォーマット保持部と、前記インシデントの複数の属性情報の中から前記フォーマットで指定された属性情報を前記インシデント情報保持部から取得する取得部と、前記取得部が取得した属性情報が記入された通知ファイルを生成する生成部と、前記生成部が生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する送信部と、前記送信部が送信した通知ファイルであって、前記フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する受信部と、前記受信部が受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する抽出部と、前記抽出部が抽出した回答内容を前記インシデントの属性情報として反映する更新部と、を備えることを特徴とするインシデント管理システム。前記フォーマット保持部は、複数の対応者に対応した複数種類のフォーマットを保持し、前記取得部は、前記インシデントの複数の属性情報の中から、前記インシデントの対応者に対応するフォーマットで指定された属性情報を取得することを特徴する請求項1に記載のインシデント管理システム。前記更新部は、更に、前記インシデントの管理者に対してインシデントに対する属性情報の反映許否を問い合わせ、前記インシデントの管理者から前記インシデントに対する属性情報の反映が許可された場合、前記抽出部が抽出した回答内容を前記インシデントの属性情報として反映することを特徴とする請求項1または2に記載のインシデント管理システム。情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、照会元のユーザに対するインシデントの属性情報の提供に使用される情報提供ファイルのフォーマットであって、複数の照会元のユーザに対応した複数種類のフォーマットを保持するフォーマット保持部と、照会元のユーザから送信されたインシデントの照会を求める電子メールを受信する受信部と、照会元のユーザから照会を求める電子メールを受信した場合、前記インシデントの複数の属性情報の中から、前記フォーマットで指定された属性情報を取得する取得部と、前記取得部が取得した属性情報が記入された情報提供ファイルを生成する生成部と、前記生成部が生成した情報提供ファイルを電子メールに添付して照会元のユーザの電子メールアドレス宛に送信する送信部と、を備えることを特徴とするインシデント管理システム。情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持する機能と、インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持する機能と、前記インシデントの複数の属性情報の中から前記フォーマットで指定された属性情報を取得する機能と、取得した属性情報が記入された通知ファイルを生成する機能と、生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する機能と、送信した通知ファイルであって、前記フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する機能と、受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する機能と、抽出した回答内容を前記インシデントの属性情報として反映する機能と、をコンピュータに実現させるためのコンピュータプログラム。インシデントの中にはサービスデスク業務を行う運用部門の担当者以下運用担当者とよぶでは解決できないものもある。このようなインシデントについては、ハードウェア、ミドルウェア、業務アプリケーションを保守する外部の企業以下、ベンダとよぶに対応を依頼する場合がある。この場合、運用担当者はどのベンダに対応を依頼すべきかの切り分けを行った後、ベンダに対応を依頼をする。運用部門とベンダのような企業間の通信では、セキュリティ上の制約の少ない電子メールだけ許可されることがある。この場合、ベンダはネットワークを介して運用部門のインシデント管理システムにアクセスできない。そのためベンダに対応を依頼するときには、運用担当者は、インシデント管理システムで管理しているインシデントの情報のうち必要な情報をメールに転記し、ベンダに送る必要がある。また、インシデントに対しどのように対応すればよいか、どのように対応したかといった回答をベンダからメールで受け付け、運用担当者がそれをインシデント管理システムに反映する必要がある。このような作業は、多数のインシデントを管理しなければならない運用担当者にとっては大きな負荷となる。本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいて発生したインシデントの効率的な管理を支援するための技術を提供することにある。上記課題を解決するために、本発明のある態様のインシデント管理システムは、情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持するフォーマット保持部と、インシデントの複数の属性情報の中からフォーマットで指定された属性情報をインシデント情報保持部から取得する取得部と、取得部が取得した属性情報が記入された通知ファイルを生成する生成部と、生成部が生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する送信部と、送信部が送信した通知ファイルであって、フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する受信部と、受信部が受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する抽出部と、抽出部が抽出した回答内容をインシデントの属性情報として反映する更新部と、を備える。本発明の別の態様もまた、インシデント管理システムである。本システムは、情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、照会元のユーザに対するインシデントの属性情報の提供に使用される情報提供ファイルのフォーマットであって、複数の照会元のユーザに対応した複数種類のフォーマットを保持するフォーマット保持部と、照会元のユーザから送信されたインシデントの照会を求める電子メールを受信する受信部と、照会元のユーザから照会を求める電子メールを受信した場合、インシデントの複数の属性情報の中から、フォーマットで指定された属性情報を取得する取得部と、取得部が取得した属性情報が記入された情報提供ファイルを生成する生成部と、生成部が生成した情報提供ファイルを電子メールに添付して照会元のユーザの電子メールアドレス宛に送信する送信部と、を備える。なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。本発明によれば、情報処理システムにおいて発生したインシデントの効率的な管理を支援できる。実施の形態に係るインシデント管理システムの概要は以下のとおりである。本インシデント管理システムは、運用部門では解決できないインシデントについてその内容を通知してベンダに対応を依頼する作業と、インシデントの原因が何であるか、インシデントに対しどのように対応すればよいか、どのように対応したかといったベンダからの回答内容をインシデントに反映する作業を支援する以下対応依頼支援機能とよぶ。この目的のために、本システムは、インシデントの対応をベンダに依頼する際に、インシデントの内容をベンダに通知するのに使用する通知ファイルのフォーマットを保持する。本システムは、通知するインシデントに関して、フォーマットで指定された属性情報を取得し、それらが記入された通知ファイルを生成する。生成した通知ファイルを電子メールに添付して対応を依頼するベンダ以下対応者とよぶに送信する。そして、対応者により回答が記入された通知ファイルが添付された電子メールを受信すると、そのファイルから対応者が記入した回答を抽出し、抽出した内容をインシデントの属性情報として反映する。また、本システムは、当該システムにアクセスできない者からインシデントの状況についての照会要求があったときに、インシデントの情報を提供する作業を支援する以下インシデント照会機能とよぶ。この目的のために、本システムは、照会元のユーザにインシデントの情報を提供するのに使用する情報提供ファイルのフォーマットを保持する。本システムは、照会元のユーザからインシデントの照会を求めるメールを受信する。そして、照会を求められたインシデントに関して、フォーマットで指定された属性情報を取得し、それらが記入された情報提供ファイルを生成する。生成した情報提供ファイルを電子メールに添付して紹介元のユーザに送信する。図1は、本実施の形態に係るインシデント管理システム300を含む運用管理システム600の全体構成を示す。情報処理システム100a、100b、、100c以下、まとめて情報処理システム100とよぶは、企業の基幹系システムや情報系システムを含む。ベンダ端末500a、500b、、500c以下、まとめてベンダ端末500とよぶは、情報処理システム100を構成するサーバ、ストレージ、ネットワーク機器等のハードウェアを保守するベンダ、データベース管理システム、トランザクションモニター等のミドルウェアを保守するベンダ、業務アプリケーションを保守するベンダの情報処理端末を含む。運用管理システム600は、情報処理システム100に運用管理サービスを提供する。運用管理システム600は、監視装置200と、インシデント管理システム300と、運用担当者端末400を含む。インシデント管理システム300は、情報処理システム100で発生したインシデントを管理する。インシデント管理システム300は、ベンダ端末500とインターネット等の通信網を介して接続されており、具体的には電子メールによりデータの送受信が可能に構成されている。インシデント管理システム300の詳細な機能構成は図2に関連して後述する。監視装置200は、情報処理システム100の動作状態を監視し、例えば死活監視処理やハードウェアリソースの使用状況の監視処理を実行する。情報処理システム100の動作状態が所定の異常状態になった場合、監視装置200は、新たなインシデントを起票してそのインシデントの情報をインシデント管理システム300へ送信する。また監視装置200は、インシデントを起票済の情報処理システム100の動作状態が変化した場合、そのインシデントの更新情報をインシデント管理システム300へ送信する。運用担当者端末400は、運用担当者により操作される情報処理端末であり、運用担当者から所定の情報や指示を受け付ける。そして、その情報をインシデント管理システム300へ送信する。図2は、図1のインシデント管理システム300の機能構成を示す。これら各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図2の各機能ブロックは、インシデント管理プログラムとして記録媒体に格納され、インシデント管理システム300のストレージへインストールされてもよい。そして、インシデント管理プログラムの起動時に、各機能ブロックに対応するプログラムモジュールがメインメモリに読み出されてCPUにより実行されてもよい。インシデント管理システム300は、インシデント情報表示部302、取得部304、生成部306、送信部308、受信部310、抽出部312、更新部314、インシデント情報受付部316、インシデント情報保持部320、対応関係保持部322、フォーマット保持部324、回答保持部326を含む。以下、各部材の構成についてインシデント対応依頼機能、インシデント照会機能それぞれを実現する場合に分けて説明する。1インシデント対応依頼機能インシデント情報受付部316は、監視装置200および運用担当者端末400からインシデントの情報を受け付け、受け付けたインシデントの情報をインシデント情報保持部320へ格納する。インシデント情報保持部320は、複数の情報処理システム100において発生した複数のインシデントに関する属性情報を保持する。この属性情報は、後述する図3のインシデント情報画面で示す各種情報項目であり、例えば、システム名ステータス優先度等を含む。インシデント情報表示部302は、インシデント情報保持部320に保持された複数のインシデントのうち、運用担当者端末400で指定されたインシデントの属性情報を表示するインシデント情報画面のデータを、運用担当者端末400へ送信する。そして運用担当者端末400に表示する。図3は、インシデント情報画面を示す。インシデント情報画面は、インシデント情報保持部320に保持された複数のインシデントのうち、運用担当者に従って運用担当者端末400が選択したインシデントの情報を表示する。インシデント情報画面は、エスカレーションボタン700を備える。エスカレーションボタン700は、インシデント情報画面で表示されたインシデントについて、対応者に対応を依頼するときに選択される。図2に戻り、対応関係保持部322は、インシデントに関する複数種類の属性それぞれの項目以下、属性項目とも呼ぶ。と、各属性を示すシンボルとしての文字列以下、単にシンボルとも呼ぶ。との対応関係情報を保持する。属性項目は、システム名ステータス優先度等の属性名称であり、インシデント情報保持部320におけるカラム名に相当する。図4は、対応関係保持部322に保持された対応関係情報のデータ構造を示す。対応関係保持部322は、シンボル710と属性項目712とを対応づけて保持する。シンボル710はシンボルを示し、属性項目712は属性項目を示す。対応関係保持部322は、例えば、属性項目システム名とシンボルICDSYSTEM、属性項目ステータスとシンボルICDSTATUS、属性項目優先度とシンボルICDPRILEVELを対応づけて保持する。図2に戻り、フォーマット保持部324は、複数の対応者に対応した複数種類の通知ファイルのフォーマットを保持する。図5は、フォーマット保持部324に保持されているフォーマットの一例を示す。属性項目720は、属性項目を示す。属性値722は、各属性の属性値が表示される領域であり、シンボルが埋め込まれている。後述するごとく、通知ファイルを生成するときに、このシンボルが実際の属性値に置き換えられる。属性値722にシンボルが埋め込まれていない回答724は対応者に回答を記入してもらう属性項目であり、ここでは、影響範囲、原因、ワークアラウンドおよび結果、対応および結果、備考、参考URLが含まれる。複数の対応者に応じた複数種類のフォーマットを保持するのは、対応者によっては受け付けるフォーマットを独自のものに限定することがあるためである。また、対応者ごとの契約の違いにより、対応者によって開示できる情報が異なる場合があるためである。例えば、図5に示すフォーマットにはシステム名が含まれるが、契約上システム名を開示できない対応者がある場合は、システム名を含まないフォーマットも保持する。もちろんシステム名を含むフォーマットとしつつ、特定の文字や記号でマスキングされるようにしてもよい。なお、フォーマットは運用担当者が自由に設計できるので、例えば、運用部門内でインシデントに関する報告会を行うときの報告資料の一部としてそのまま使用できる様式にしてもよい。図2に戻り、フォーマット保持部324は、対応者の名称と、サポート対象と、対応者の宛先と、その対応者への通知に使用される通知ファイルのフォーマットとを対応づけた対応者リスト350も保持する。図6は、対応者リスト350のデータ構造を示す。対応者730は、対応者の名称を示し、サポート対象732は対応者が対応する対象のインシデントの分類を示し、メールアドレス734は対応者のメールアドレスを示す。また、フォーマット736はその対応者にインシデントを通知するときに使用する通知ファイルのフォーマットを示す。図2に戻り、取得部304は、対応を依頼するインシデントと対応者の情報を運用担当者端末400から受け付ける。取得部304は、対応者リスト350を参照して、受け付けた対応者に対応するフォーマットを特定する。例えば、対応者リスト350が図6の場合で、対応者としてDEF社を受け付けたときは、フォーマット1がフォーマットとして特定される。取得部304は、特定したフォーマットの中のシンボルここではに挟まれた文字列を検出する。取得部304は、対応関係保持部322に保持される対応関係情報を参照して、検出したシンボルに対応する属性項目を特定する。そして、特定した属性項目の値属性値をインシデント情報保持部320から取得する。取得部304は、特定したフォーマットの情報および取得した属性値を生成部306に渡す。生成部306は、取得部304が特定したフォーマットをフォーマット保持部324からコピーする。そして、コピーしたファイル内のシンボルを、取得部304が取得した属性値に置き換える。こうして、通知ファイルを生成する。図7は、生成部306が生成した通知ファイルの一例を示す。図4のフォーマットと比較すると、例えば、属性項目タイトルのシンボルICDTITLEが、通知ファイルではストレージ障害に置き換えられている。また、属性項目優先度のシンボルICDPRILEVELが、通知ファイルでは大に置き換えられている。生成部306は生成した通知ファイルを送信部308に渡す。図2に戻り、送信部308は、対応者リストを参照して、取得部304が受け付けた対応者に対応するメールアドレスを特定する。そして、生成部306が生成した通知ファイルを添付した電子メールを、特定したメールアドレス宛に送信する。受信部310は、送信部308が対応者に送信した通知ファイルであって対応者が回答を記入した通知ファイルが添付された電子メールを受信する。受信部310は、受信した通知ファイルを後述の回答保持部326に格納する。回答保持部326は、対応者により回答が記入された通知ファイルを保持する。図8は、回答保持部326が保持している通知ファイルの一例を示す。図7の対応者が記入する前の通知ファイルと比較すると、回答740に回答が記入されている。抽出部312は、回答内容をインシデントに反映する通知ファイルの選択を、運用担当者端末400から受け付ける。抽出部312は、回答保持部326が保持する通知ファイルのうち運用担当者端末400が選択した通知ファイルから、対応者の回答内容を抽出する。通知ファイルの回答元の対応者に対応づけられたフォーマットの回答724に記入された内容を抽出する。図8に示す通知ファイルが選択された場合、例えば、原因としてディスク故障、対応および結果として810に故障したディスクを交換を抽出する。また抽出部312は、インシデント情報保持部320からそのインシデントの属性情報を取得する。抽出部312は、抽出した回答内容および取得した属性情報を更新部314に渡す。なお、選択された通知ファイルに対応するインシデントがインシデント情報保持部320に存在しないとき、すなわち、通知ファイルに記載されているインシデントIDのインシデントがインシデント情報保持部320に存在せず抽出できなかったときは、抽出部312は処理を中止し、その旨を運用担当者端末400に通知する。更新部314は、抽出部312が抽出した回答内容を運用担当者端末400に通知して回答内容をインシデントの属性情報として反映することの許否を問い合わせる。運用担当者端末400から反映を許可する情報を受け付けた場合、更新部314は、対応者からの回答を属性情報として反映する。図9は、対応者からの回答が反映されたインシデントのインシデント情報画面の一例を示す。図3の回答が反映される前のインシデント情報画面と比較すると、影響範囲、原因、ワークアラウンドおよび結果、対応および結果、備考、参考URLに対応者からの回答が反映されている。以上の構成によるインシデント管理システムの動作を説明する。図10は対応者にインシデントの対応を依頼するときの処理フローを示し、図11は対応者から回答を受信したときの処理フローを示し、図12は対応者からの回答内容をインシデントの属性情報として反映するときの処理フローを示す。ここでは、図3に示すインシデントID35のインシデントを例に説明する。運用担当者がこのインシデントは自部門では解決できないと判断し、ストレージを保守するベンダDEF社に対応を依頼する場合を考える。そして、依頼を受けたDEF社は、ディスク故障が原因であると特定し、その対応としてディスク交換を行い、その旨を運用担当者から送られた通知ファイルそのものに記載して回答する場合を考える。図10のごとく、取得部304は、通知するインシデントのインシデントID35と対応者DEF社を運用担当者端末400から受け付けるS10。取得部304は、図6に示す対応者リスト350を参照し、受け付けた対応者DEF社に対応するフォーマットであるフォーマット1を特定するS20。ここでは、図5のフォーマットがフォーマット1であるとする。取得部304は特定したフォーマット1の中のシンボルを検出し、対応関係保持部322に保持された対応関係情報を参照して、シンボルに対応する属性項目を特定するS30。例えば、シンボルICDTITLEを検出し、対応する属性項目としてタイトルを特定する。そして、特定した属性項目の値属性情報をインシデント情報保持部320から取得するS40。例えば、インシデントID35のインシデントの属性項目タイトルの値としてストレージ障害を取得する。生成部306は、フォーマット保持部324からフォーマット1をコピーし、コピーしたファイル内のシンボル文字列を、取得部304が取得した属性情報に置き換え、通知ファイルを生成するS50。図7が生成された通知ファイルとすると、例えば、シンボルICDTITLEがストレージ障害に置き換えられている。送信部308は、生成部306が生成した通知ファイルを添付した電子メールを対応者であるDEF社に送信するS60。こうして、運用担当者は、ストレージに関するインシデントについて、それを保守するベンダにインシデントの内容を通知し、対応依頼することができる。図11のごとく、受信部310は対応者により回答が記載された通知ファイルが添付された電子メールを受信しS70、その通知ファイルを回答保持部326に格納するS80。ここでは、図8の通知ファイルを受信したとする。図11のごとく、抽出部312は、回答内容をインシデントに反映する通知ファイルの選択を運用担当者端末400から受け付けるS90。ここでは、図8の通知ファイルが選択されたとする。抽出部312は、回答保持部326に格納された図8の通知ファイルから、対応者の回答内容を抽出するS100。例えば、原因ディスク故障、対応および結果810に故障したディスクを交換が抽出される。また、抽出部312は、インシデント情報保持部320からそのインシデントの属性情報を取得するS110。当該インシデントがインシデント情報保持部320に存在する場合S120のY、抽出部312は、抽出した回答内容および取得した属性情報を更新部314に渡す。インシデントが存在しない場合S120のN、抽出部312は処理を中止し、その旨を運用担当者端末400に通知するS160。更新部314は、抽出部が抽出した回答内容を運用担当者端末400に通知して回答内容をインシデントの属性情報として反映することの許否を問い合わせるS130。運用担当者端末400から反映を許可する情報を受け付けた場合S140のY、更新部314は、対応者からの回答を属性情報として反映するS150。図9のごとく、例えば、原因ディスク故障、対応および結果810に故障したディスクを交換が反映される。更新を許可しない情報を受け付けた場合S140のN、更新部314は処理を中止する。このようして、運用担当者は、対応者の回答を反映することができる。以上の構成によれば、フォーマットに従って、インシデントの属性情報が記入された通知ファイルが生成される。このため、インシデントの対応を依頼するときにその内容をメールに転記するといった作業が不要となるので、運用担当者の作業負荷が軽減される。また、対応を依頼するのに必要十分な属性項目が含まれるフォーマットを用意しておけば、それらが記入された通知ファイルが生成されるため、運用担当者は必要な情報を対応者に提供できる。このため、不足している情報を対応者から要求され、運用担当者がそれに対応する、といった余計なやり取りを減らすことができ、運用担当者の負担が軽減される。また、通知ファイルに記入された対応者からの回答が抽出され、インシデントに反映される。このため、対応者からの回答を手動で入力する必要がないため、運用担当者の作業負荷が軽減される。2インシデント照会機能インシデント照会機能では、受信部310、取得部304、生成部306、送信部308、インシデント情報受付部316、インシデント情報保持部320、対応関係保持部322、フォーマット保持部324が主に使用される。インシデント対応依頼機能と同じ構成の部材についてはその説明を省略する。また、通知ファイルを情報提供ファイルと読み替えることによって同様の説明が当てはまる部材につても説明を省略する。フォーマット保持部324は、複数の照会元のユーザに応じた複数種類の情報提供ファイルのフォーマットを保持する。情報提供ファイルのフォーマットは、通知ファイルのフォーマットと同様である。複数の照会元のユーザに応じた複数種類のフォーマットを保持するのは、照会元のユーザによって開示できる情報が異なる場合があるためである。情報提供ファイルのフォーマットは運用担当者が自由に設計できるので、ユーザに応じた範囲の情報が開示されるようにフォーマットを用意すればよい。フォーマット保持部324は、インシデントの照会要求があった場合にインシデントの情報を提供するユーザと、そのユーザのメールアドレスと、開示する際に使用する情報提供ファイルのフォーマットの情報との対応関係を示す照会ユーザリスト360を保持する。図13は、照会ユーザリスト360のデータ構造を示す。ユーザ750は照会要求があった場合にインシデントの情報を提供するユーザを示し、メールアドレス752はそのユーザのメールアドレスを示す。また、フォーマット754は、そのユーザにインシデントの情報を開示する際に使用する情報提供ファイルのフォーマットを示す。ユーザはベンダに限らず、さまざまな者を含めることができる。ここでは、運用部門の部門長である運用部門長001をユーザとして含めている。図2に戻り、受信部310は、インシデントの照会を求める電子メールを受信する。ここでは、照会を求めるメールの件名には、インシデントIDが記載されているものとする。例えば、インシデントID35のインシデントの照会を求める場合は、件名に35と記載される。取得部304は、照会を求めるインシデントのインシデントIDと照会元のユーザのメールアドレスを受信部310から受け付ける。取得部304は、照会ユーザリスト360を参照して、受け付けたメールアドレスに対応するフォーマットを特定する。例えば、照会ユーザリスト360が図13の場合で、メールアドレスとしてbumontyou001pqrcojpを受け付けたときは、フォーマット2がフォーマットとして特定される。送信部308は、情報提供ファイルが添付された電子メールを、照会元のユーザに送信する。以上の構成によるインシデント管理システムの動作を説明する。図14は、インシデントの照会要求があったときの処理フローを示す。ここでは、インシデント管理システム300に社内のLANではアクセスできずインターネットを介してアクセスせざるを得ないロケーションにいる運用部門長001メールアドレスはbumontyou001pqrcojpが、図9に示すインシデントID35のインシデントの照会要求をした場合を例に説明する。図14のごとく、受信部310は、件名に35が記載されたメールを受信したとするS170。取得部304は、照会ユーザリスト360を参照し、受信部310から受け付けたメールアドレスbumontyou001pqrcojpに対応するフォーマットフォーマット2を特定するS180。取得部304は特定したフォーマット2の中のシンボルを検出し、対応関係保持部322に保持された対応関係情報を参照して、シンボルに対応する属性項目を特定するS190。そして、特定した属性項目の値属性情報をインシデント情報保持部320から取得するS200。生成部306は、フォーマット保持部324からフォーマット2をコピーし、コピーしたファイル内のシンボル文字列を、取得部304が取得した属性情報に置き換え、情報提供ファイルファイルを生成するS210。送信部308は、生成部306が生成した情報提供ファイルを添付した電子メールを照会元のユーザである運用担当者001の宛先に送信するS220。このように、運用担当者がインシデントの情報をメールに転記して応答するといった作業をするまでもなく、運用部門長001は、インシデントID35のインシデントの状況を確認することができる。以上の構成によれば、フォーマットに従って、インシデントの属性情報が記入された情報提供ファイルが生成され、照会もとのユーザに送信される。このため、運用担当者は、インシデントの照会要求に対してインシデントの情報をメールに転記して応答するといった作業が不要となるので、運用担当者の作業負担が軽減される。以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要件の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。