情報処理システムにおいて発生した複数のインシデントの情報を保持するインシデント情報保持部と、前記複数のインシデントの中からユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する抽出条件保持部と、前記抽出条件にもとづき前記複数のインシデントの中からインシデントを抽出する抽出部と、前記抽出部により抽出されたインシデントの情報を通知する通知部と、を備えることを特徴とするインシデント管理システム。前記通知部は、前記抽出部によりインシデントが抽出された場合、前記抽出部により過去抽出されたインシデントと今回抽出されたインシデントの片方にだけ含まれるインシデントの情報を、今回抽出されたインシデントの情報とは別に通知することを特徴とする請求項1に記載のインシデント管理システム。前記通知部は、前記抽出部によりインシデントが抽出された場合、前記抽出部により過去抽出されたインシデントに含まれるが、今回抽出されたインシデントには含まれないインシデントの情報を、今回抽出されたインシデントの情報とは別に通知することを特徴とする請求項1に記載のインシデント管理システム。情報処理システムにおいて発生した複数のインシデントの情報を保持する機能と、前記複数のインシデントの中からユーザへ通知すべきインシデントを抽出するための条件であり、ユーザが予め定めた抽出条件を保持する機能と、前記抽出条件にもとづき前記複数のインシデントの中からインシデントを抽出する機能と、抽出されたインシデントの情報を通知する機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。サービスデスク業務を行う運用部門の担当者は、運用部門で抱えるインシデントの状況を監視する必要がある。現状一般に、監視すべきインシデントを手動で特定してリスト化しておき、そのステータス等の進展状況を継続的に監視している。しかし、その方法では、監視すべきインシデントが新たに発生していないか、または既存インシデントの属性が変化し監視すべきインシデントとなっていないかを逐次確認し、リストに追加しなければならい。また、逆にインシデントがクローズされたことなどにより監視の必要がなくなった場合は、リストから削除しなければならない。このような作業は、多くのインシデントの状況を監視しなければならない担当者にとっては大きな負荷となる。本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいて発生したインシデントの効率的な管理を支援するための技術を提供することにある。上記課題を解決するために、本発明のある態様のインシデント管理システムは、情報処理システムにおいて発生した複数のインシデントの情報を保持するインシデント情報保持部と、複数のインシデントの中からユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する抽出条件保持部と、抽出条件にもとづき複数のインシデントの中からインシデントを抽出する抽出部と、抽出部により抽出されたインシデントの情報を通知する通知部と、を備える。なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。本発明によれば、情報処理システムにおいて発生したインシデントの効率的な管理を支援できる。本発明の実施の形態は、情報処理システムで発生した複数のインシデントを管理するためのシステムに関する。インシデント管理システムは、運用担当者以下、ユーザともよぶが監視すべきインシデント、すなわちユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する。インシデント管理システムは、複数のインシデントの中から当該抽出条件に該当するインシデントを抽出し、ユーザに通知する。また、過去に抽出されたが今回抽出されなかったインシデントと、過去に抽出されなかったが今回抽出されたインシデントとを、差分インシデントとしてユーザに通知する。図1は、本実施の形態に係るインシデント管理システム300を含む運用管理システム500の全体構成を示す。情報処理システム100a、100b、、100c以下、まとめて情報処理システム100とよぶは、企業の基幹系システムや情報系システムを含む。運用管理システム500は、情報処理システム100に運用管理サービスを提供する。運用管理システム500は、監視装置200と、インシデント管理システム300と、運用端末400a、400b、、400c以下、まとめて運用端末400とよぶを含む。インシデント管理システム300は、情報処理システム100で発生したインシデントを管理する。インシデント管理システム300の詳細な機能構成は図2に関連して後述する。監視装置200は、情報処理システム100の動作状態を監視し、例えば死活監視処理やハードウェアリソースの使用状況の監視処理を実行する。情報処理システム100の動作状態が所定の異常状態になった場合、監視装置200は、新たなインシデントを起票してそのインシデントの情報をインシデント管理システム300へ送信する。また監視装置200は、インシデントを起票済の情報処理システム100の動作状態が変化した場合、そのインシデントの更新情報をインシデント管理システム300へ送信する。監視装置200からインシデント管理システム300へ送信される情報は、図3で示す。運用端末400は、ユーザにより操作される情報処理端末であり、情報処理システムで発生したインシデントの情報起票情報や更新情報の入力をユーザから受け付ける。そして、その情報をインシデント管理システム300へ送信する。運用端末400からインシデント管理システム300へ送信される情報は、監視装置200からインシデント管理システム300へ送信される情報と同様であり、図3で示す。また、運用端末400は、図4で示すインシデントを抽出するための条件の入力をユーザから受け付け、その情報をインシデント管理システム300へ送信する。図2は、図1のインシデント管理システム300の機能構成を示す。これら各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図2の各機能ブロックは、インシデント管理プログラムとして記録媒体に格納され、インシデント管理システムのストレージへインストールされてもよい。そして、運用管理支援プログラムの起動時に、各機能ブロックに対応するプログラムモジュールがメインメモリに読み出されてCPUにより実行されてもよい。インシデント管理システム300は、インシデント情報受付部310と、インシデント情報保持部320と、抽出条件受付部330と、抽出条件保持部340と、抽出部350と、抽出結果保持部360と、通知部370を含む。インシデント情報受付部310は、監視装置200および運用端末400からインシデントの情報を受け付け、受け付けたインシデントの情報をインシデント情報保持部320へ格納する。インシデント情報保持部320は、情報処理システム100において発生したインシデントの情報を記憶する。図3は、インシデント情報保持部320に保持されるインシデントのデータ構造を示す。インシデント情報保持部320は、インシデントID600と、属性情報610とを対応づけて保持する。インシデントID600は、インシデントを一意に識別するためのIDである。属性情報610は、インシデントの内容や状況等を示す属性情報であり、ここでは、発生日時、タイトル、ステータス、担当者、緊急度を含む。図2に戻り、抽出条件受付部330は、インシデント情報保持部320に保持された複数のインシデントの中から、ユーザが監視すべきインシデント、すなわちユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた条件以下、抽出条件とよぶを運用端末400から受け付ける。抽出条件受付部330は、受け付けた抽出条件を抽出条件保持部340へ格納する。抽出条件保持部340は、抽出条件を記憶する。図4は、抽出条件保持部340に保持された抽出条件を示す。抽出条件保持部340は、ユーザID700と、抽出条件710とを対応付けて保持する。ユーザID700は、ユーザを一意に識別するためのIDである。抽出条件710は、抽出条件となるインシデントの項目であり、ここでは、ステータス、担当者、緊急度を含む。図4において、同じレコードに含まれる抽出条件の各項目はAND論理積で連結される。例えば、ユーザIDU001のユーザの場合、ステータスクローズ以外すなわち継続中のインシデントかつ担当者山田一郎かつ緊急度高という条件に該当するインシデントが抽出される。また、同じユーザIDのレコードが複数ある場合、それらはOR論理和で連結される。例えば、ユーザIDU002のユーザの場合、ステータスクローズ以外かつ担当者鈴木二郎という条件と、ステータスクローズ以外かつ担当者佐藤三郎という条件と、ステータスクローズ以外かつ緊急度高という条件のいずれかに該当するインシデントが抽出される。図2に戻り、抽出結果保持部360は、後述する抽出部350により抽出されたインシデントの情報を抽出結果として記憶する。本実施の形態では、抽出結果保持部360は、ユーザごとに前回1回分の抽出結果を保持する。図5は、抽出結果保持部360に保持された抽出結果のデータ構造を示す。抽出結果保持部360は、ユーザID800と、インシデントID810とを対応付けて保持する。ユーザID800は、ユーザを一意に認識するためのIDであり、インシデントID810は、インシデントを一意に識別するためのIDである。図5に示す例では、ユーザIDU001の抽出条件により、インシデントIDI0002、I0003の2つのインシデントが前回抽出されたことを示している。図2に戻り、抽出部350は、インシデント情報保持部320に保持された複数のインシデントの中から対象となるユーザの抽出条件に該当するインシデントを抽出する。例えば、図4のユーザIDU001のユーザの場合、ステータスクローズ以外かつ担当者山田一郎かつ緊急度高の条件に該当するインシデントを抽出する。インシデント情報保持部320に保持されているインシデントが図3に示す状態の場合、インシデントIDI0003、I0007の2つのインシデントが抽出される。抽出部350は、抽出したインシデントの情報を後述する通知部370へ渡す。抽出部350は、抽出結果保持部360に保持された抽出結果前回の抽出結果と、今回抽出したインシデントとを比較し、片方にだけ含まれるインシデントの情報を差分インシデントとして通知部370へ渡す。例えば、インシデント情報保持部320に保持されているインシデント、抽出結果保持部360に保持されている抽出結果がそれぞれ図3、5に示す状態であったとする。ユーザIDU001のユーザを例に考えると、前述のごとく、前回抽出されたインシデントは、インシデントIDI0002、I0003の2つのインシデントである。一方、インシデントIDI0003、I0007の2つのインシデントが今回抽出される。そうすると、この場合、前回の抽出したインシデントと今回の抽出したインシデントの片方にだけ含まれる、インシデントIDI0002、I0007のインシデントの情報を通知部370へ渡す。抽出部350は、今回抽出した抽出結果を抽出結果保持部360に格納する。なお、抽出部350が、上述の処理を実行するタイミングは、ユーザが運用端末400からインシデント管理システム300にログインしたタイミングや、ログイン後に処理実行させる特定のボタンを押下したタイミング等いくつかのタイミングが考えられる。通知部370は、抽出部350が今回抽出したインシデントの情報と、差分インシデントの情報をそれぞれユーザに通知する。通知は、抽出結果の画面情報をユーザが使用している運用端末400に送信して行う。もちろん、ユーザの電子メールアドレス宛に所定の情報を含む電子メールを送信してもよい。図6は、通知部370によりユーザが使用している運用端末400に通知された抽出結果の画面を示す。抽出インシデント一覧900は、抽出部350により今回抽出されたインシデントの情報を表示する。また、差分インシデント一覧910は、差分インシデントの情報を表示する。インシデントIDにはリンクが張られており、ユーザがリンクをクリックすることによってそのインシデントの詳細情報を示す画面図示せずが表示される。以上の構成によるインシデント管理システムの動作を説明する。図7はインシデントが発生したときの処理フローを示し、図8はインシデントを抽出したときの処理フローを示す。これらはインシデント管理システム300の運用中の処理フローを表すものであり、監視すべきインシデントを抽出するための抽出条件の設定は完了していることを前提とする。また、ユーザIDがU001である運用担当者山田一郎以下ユーザU001とよぶが抽出処理を実行した場合を例に説明する。インシデント管理システム300の運用中に、情報処理システム100の利用者から、システムにログインできないという連絡があったとする。図7のごとく、利用者からの連絡を受けた運用担当者が運用端末400にその内容を入力すると、インシデント情報受付部310がその情報を受け付け、一意のインシデントIDと対応付けてインシデント情報保持部320にインシデントを登録するS10。ここでは、図3のごとく、インシデントIDI0007が割り当てられたとする。ログインできないという事象は業務に直接影響を及ぼすため緊急度として高が設定され、担当者には、過去に同じ事象のインシデントに対応したことのある山田一郎がアサインされたとする。なお、ここではインシデントの情報を手動で入力する例を示したが、後述の変形例において、この入力を可能な限り自動化する例も示す。図8のごとく、ユーザU001が、自身が監視すべきインシデントの状況を確認するために、抽出処理を実行させる特定のボタンを押下したとするS20。ここでは、インシデントIDI0007のインシデント発生後、初めてインシデントの状況を確認したとする。抽出部350は、抽出条件保持部340に保持された抽出条件にもとづきインシデント情報保持部320に保持された複数のインシデントの中からインシデントを抽出し、通知部370に渡すS30。図4のごとく、ユーザU001の抽出条件は、ステータスクローズ以外かつ担当者山田一郎かつ緊急度高であるため、新たに発生したインシデントIDI0007のインシデントも抽出される。図8に戻り、抽出部350は、抽出結果保持部360に保持された前回の抽出結果と今回の抽出結果を比較し、片方にだけ含まれるインシデントの情報を差分インシデントとして通知部370に渡すS40。前回抽出時には発生していなかったインシデントIDI0007のインシデントも差分インシデントとして抽出される。通知部400は、図6のごとく、抽出部350から受け取った今回抽出されたインシデントの情報と差分インシデントを運用端末400を介してユーザU001に通知するS50。これにより、ユーザU001はインシデントの緊急度に応じた対応をすることができる。実施の形態のインシデント管理システムによれば、ユーザが監視すべきインシデントを抽出するためにユーザが予め定めた抽出条件によってインシデントが抽出される。このため、ユーザが監視すべきインシデントが新たに発生した場合やインシデントの属性情報が変化し監視すべきインシデントとなった場合にそれらのインシデントを手動で特定してリストに追加したり、逆にインシデントがクローズされたことなどにより監視する必要がなくなった場合にリストから削除したりする、といったユーザ自身によるメンテナンス作業が不要となり、ユーザの負荷が軽減される。また、前回抽出されたインシデントと今回抽出されたインシデントの片方にだけ含まれるインシデントの情報が、今回の抽出結果とともに通知される。このため、前回の抽出結果と今回の抽出結果が異なる場合に、インシデントのどの属性情報が変化したため抽出されなくなったか、どのインシデントが新たに抽出されたかが確認でき、より的確にインシデントの状況を把握できる。以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。変形例1実施の形態では、抽出結果保持部360に保持された前回の抽出結果と、今回の抽出結果のうち、片方にだけ含まれるインシデントの情報を差分インシデントとして通知部370へ渡す例を示した。しかし、今回抽出した結果にだけ含まれるインシデントの情報は差分インシデントとはせず、前回抽出したインシデントにだけ含まれるインシデントの情報を差分インシデントとして扱い、その差分インシデントの情報を通知部370へ渡すようにしてもよい。ユーザが設定した抽出条件は常に十分とは限らない。仮にそれが不十分だった場合、前回は抽出されたが、今回は抽出できなかったインシデントが発生しうる。そうしたインシデントは、監視すべき対象でなくなったために抽出されなくなったわけではなく、単に抽出漏れである。本変形例では、そうしたインシデントを明示することでユーザの確認を促すことができる。変形例2実施の形態では、抽出結果保持部360は前回1回分の抽出結果のみ保持する例を示したが、所定回数分の過去の抽出結果を保持するようにしてもよい。そして、抽出部350は、前回以外の過去の抽出結果と今回の抽出結果とを比較するようにしてもよい。これにより、例えば、ある特定の日時だけで発生するインシデント、その他、システムの状況や環境に応じて発生するインシデントを特定できる場合がある。変形例3実施の形態では、ユーザごとに一つの抽出条件を保持する例を示したが、抽出条件保持部340は、それぞれ独立した複数の抽出条件を保持できるようにしてもよい。そして、抽出部350で複数の抽出条件にて抽出された結果をディスプレイに並べて表示したり、切り替え可能に表示したりするようにしてもよい。この場合、どのような抽出条件を設定すればより的確に必要なインシデントを抽出できるかを検討しやすくなる。変形例4インシデントの情報の入力は可能な限り自動化ないし簡略化することが望ましい。本変形例の概要は、インシデントのタイトルをプルダウンメニューから選択できるインシデント情報入力画面を運用端末400に提供する。そして、インシデント毎に予め緊急度を対応付けておくことで、選択されたインシデントの緊急度を設定する。また、選択されたインシデントと同様のインシデントを過去に対応したことがある運用担当者を、当該インシデントの担当者として設定する。または、各運用担当者が有する技術分野にもとづいて、インシデント毎に予め担当者を対応付けておくことで、選択されたインシデントの担当者を設定するようにしてもよい。具体的には、インシデント情報保持部320に、インシデント発生の予想されるインシデントやこれまでに発生したことのあるインシデントと、その緊急度とを対応付けた緊急度リストを予め保持しておく。また、インシデントと、そのインシデントを過去に対応したことがある担当者とを対応付けた担当者履歴リストを予め保持しておく。または、各運用担当者が有する技術分野にもとづいて定めた、インシデントと担当者とを対応付けた担当者技術リストを予め保持しておく。インシデント情報受付部310は、例えば緊急度リストに記録されているインシデントにもとづき、インシデントのタイトルをプルダウンメニューから選択できるインシデント情報入力画面を運用端末400に提供する。運用担当者は、インシデント情報入力画面においてプルダウンメニューからインシデントを選択し、インシデントを登録する。インシデント情報受付部310は、選択されたインシデントに対応する緊急度を緊急度リストから取得する。同様に、担当者履歴リストまたは担当者技術リストから選択されたインシデントに対応する担当者を取得する。そして、インシデント情報受付部310は、インシデントのタイトルと、緊急度と、担当者とを対応付けてインシデント情報保持部320に記録する。なお、担当者履歴リストや担当者技術リストにもとづいて自動で担当者を設定すると、特定の運用担当者に偏って設定される場合がある。そのため、例えば、担当者履歴リストや担当者技術リストにもとづいて取得された担当者が既に所定数以上のインシデントの担当者として設定されている場合は、インシデント情報受付部310は担当者履歴リストや担当者技術リストによらず、最も担当しているインシデントが少ない運用担当者を担当者として設定する等、特定の担当者に偏らないよう調整する機能を有するようにしてもよい。また、例えば以下のような、監視装置200が検知できるインシデントについては、インシデントのタイトルの設定さえも自動化することができ、インシデント情報の登録を人手を介さずに実施できる。ハードウェア、ミドルウェアの異常停止CPU、メモリ、ディスク等のハードウェアのリソース逼迫ジョブ管理ツールにより実行しているジョブの異常終了具体的には、上記のインシデントが発生したときに監視装置200が検知するエラーメッセージと、インシデントとを対応付けたエラーメッセージリストをインシデント情報受付部310に予め保持する。インシデント情報受付部310は、監視装置200からエラーメッセージを受け付けると、エラーメッセージに対応するインシデントのタイトルをエラーメッセージリストから取得する。請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要件の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。