情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合に、その変更履歴を格納するシステム管理データベースと、前記システム管理データベースを参照して、各構成要素についてインシデントの対処に伴って変更された回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定する変更実績解析部と、前記変更実績解析部が特定した構成要素を通知する通知部とを含むことを特徴とするシステム管理支援装置。前記システム管理データベースはさらに、前記変更実績解析部が特定した構成要素と、その構成要素を前記通知部が通知した日付とを関連づけて格納し、前記通知部は、前記変更実績解析部が特定した構成要素を通知した日付から所定の期間経過した場合、当該構成要素は通知しないことを特徴とする請求項1に記載のシステム管理支援装置。前記変更実績解析部は、変更された回数が所定の通知基準回数以上である構成要素を特定する際に、特定を実施する時点からさかのぼって所定の変更計数期間内にあった変更を計数することを特徴とする請求項2に記載のシステム管理支援装置。前記通知基準回数は前記情報処理システムを構成する構成要素毎に定められており、前記変更実績解析部は、計数した構成要素の変更回数が、当該構成要素用に定められた前記通知基準回数以上であるか否かを比較することを特徴とする請求項1から3のいずれかに記載のシステム管理支援装置。情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定して前記情報処理システムのボトルネックを検出することをプロセッサに実行させることを特徴とするシステム管理支援方法。情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合にその変更履歴を格納するシステム管理データベースを参照して、前記情報処理システムを構成する構成要素についてインシデントの対処として構成変更された回数を計数し、変更された回数が所定の通知基準回数以上である構成要素を特定する機能と、特定した構成要素を通知する機能とをコンピュータに実現させることを特徴とするプログラム。サービスを運用中に何らかのインシデントが発生し、その対処として構成要素を変更する場合、上述した優先度に応じて対処の順番を決定することができる。ところが、上述の優先度は、運用中のサービスを維持する上で重要な構成要素を示唆するものの、問題が発生する前に問題を起こす可能性のある構成要素を示唆するものではない。大規模な情報処理システムは問題対処に時間がかかる場合もあり、問題が発生してから対処するのではなく、未然に問題の発生を防止することが求められている。本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいてボトルネックとなり得る構成要素の特定を支援するための技術を提供することにある。上記課題を解決するために、本発明のある態様のシステム管理支援装置は、情報処理システムで発生したインシデントの対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した場合にその変更履歴を格納するシステム管理データベースと、前記システム管理データベースを参照して、各構成要素についてインシデントの対処に伴って変更された回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定する変更実績解析部と、前記変更実績解析部が特定した構成要素を通知する通知部とを含む。上記課題を解決するために、本発明の別の態様はシステム管理支援方法である。この方法は、情報処理システムで発生したインシデント対処に伴って、当該インシデントに関与する前記情報処理システムのハードウェアまたはソフトウェアからなる構成要素を変更した回数を計数し、当該回数が所定の通知基準回数以上となる構成要素を特定して前記情報処理システムのボトルネックを検出することをプロセッサに実行させる。なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。本発明によれば、情報処理システムにおいてボトルネックとなり得る構成要素の候補の特定を支援するための技術を提供できる。実施の形態に係る情報処理システム500は、ITサービス企業例えばSI企業に構築されたコンピュータシステムである。実施の形態に係るシステム管理支援装置100は、情報処理システム500で発生したインシデントや、そのインシデントの対処に伴ってされた情報処理システム500の各構成要素の変更を管理する。ここで情報処理システム500の構成要素とは、情報処理システムを運用する際に必要なハードウェアや、ファームウェアを含むソフトウェアのことをいう。以下では、主にインシデント管理の構成について説明するが、問題管理においても同様の構成が適用できることは当業者には理解されるところである。図1は、実施の形態に係る情報処理システム500の機能構成を模式的に示す図である。情報処理システム500は、ブレード群200、ネットワークスイッチ群300、ストレージ群400、およびシステム管理支援装置100を含む。図1は、実施の形態に係る情報処理システム500を実現するための機能構成を示しており、その他の構成は省略している。図1において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、CPU、メインメモリ、その他のLSILargeScaleIntegrationで構成することができ、ソフトウェア的には、メインメモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。ブレード群200の各構成要素は、データベースサーバやウェブサーバ等の各種サーバプログラムを実行するブレードサーバ以下、単にブレードという。である。このため、ブレード群200は、第1ブレード210、第2ブレード220と続き、第Lブレード230に至るまでのL個のブレードを含む。ここでLはブレード群200に含まれるブレードサーバの数である。Lの値は、例えば情報処理システム500が提供するサービスの規模等を勘案して実験により定めればよい。図2は、仮想マシンを実行するブレードの内部構成を模式的に示す図である。実施の形態に係るブレード群200に含まれる各ブレードは仮想化機能を有しており、仮想マシン250を実行してデータベースサーバ252やウェブサーバ254等の各種サーバプログラムを実行する。仮想マシン250は、仮想マシン250と現実のブレードとを接続する仮想的な第1ネットワークインタフェース256を含み、ブレードが有する現実のネットワークインタフェースである第2ネットワークインタフェース260を介してネットワークスイッチ群300と接続する。仮想マシン250とネットワークスイッチ群300との接続方法は、例えば仮想マシン250から直接第2ネットワークインタフェース260に接続する等いくつかの方法が考えられるが、本実施の形態のテーマではないので説明は割愛する。図1の説明に戻る。ストレージ群400は、例えば顧客情報や商品情報、広告等、情報処理システム500がサービスを提供するために必要な種々の情報を格納する。このため、ストレージ群400は、第1ストレージ410、第2ストレージ420と続き第Mストレージ430に至るまでのM個のネットワークスイッチを含む。ここでMはストレージ群400に含まれるストレージの数である。Mの値は、Lの値と同様に、例えば情報処理システム500が提供するサービスの規模や冗長性の度合い等を勘案して実験により定めればよい。ネットワークスイッチ群300は、ブレード群200に含まれる各ブレードサーバとストレージ群400に含まれる各ストレージとを中継するネットワークスイッチ群である。ネットワークスイッチ群300は、第1スイッチ310、第2スイッチ320と続き、第Nスイッチ330に至るまでのN個のネットワークスイッチを含む。ここでNはネットワークスイッチ群300に含まれるネットワークスイッチの数である。Nの値は、LやMの値と同様に、例えば情報処理システム500が提供するサービスの規模や冗長性の度合い等を勘案して実験により定めればよい。システム管理支援装置100は、情報処理システム500において発生するインシデントと、そのインシデントに関与した構成要素との関連を管理する。ここで情報処理システム500における構成要素とは、ブレード群200に含まれる各ブレードおよびそこで実行されるサーバプログラムやネットワークインタフェース、ネットワークスイッチ群300に含まれる各ネットワークスイッチ、ストレージ群400に含まれる各ストレージ等である。システム管理支援装置100は、インシデント管理部10、システム管理データベース20、変更実績解析部30、および通知部40を含む。システム管理データベース20は、情報処理システム500の各構成要素の変更を管理するために利用される各種テーブルである、構成情報マスタ22、関連管理マスタ24、変更履歴マスタ26、およびボトルネック候補マスタ28を含む。図3は、実施の形態に係る情報処理システム500の構成情報を管理する構成情報マスタ22のデータ構造を模式的に示す図である。構成情報マスタ22は、情報処理システム500の各構成要素の名前例えば、第1ウェブサーバ、第3ブレード等と、それらの構成要素に一意に定められた構成情報IDIDentificationとを対応づけて格納する。構成情報マスタ22はまた、構成情報IDと、その構成情報IDに対応する構成要素が情報処理システム500に設置されてから現在に至るまでに何回変更されたかを示す総変更回数とを対応づけて格納する。構成情報マスタ22はさらに、構成情報IDと期間内変更回数とを対応づけて格納する。期間内変更回数および総変更回数の詳細は後述する。図4は、実施の形態に係る情報処理システム500の構成要素の変更履歴を管理する変更履歴マスタ26のデータ構造を模式的に示す図である。変更履歴マスタ26は、何らかのインシデントが発生してその対処のため構成要素を変更したときに、その構成要素の構成情報IDと変更日付とを対応づけて格納する。例えば、図4に示す変更履歴マスタ26の例において、履歴情報ID0001は、発生したインシデントに関与したその構成情報ID0006に係る第1スイッチ310が、2010年10月11日に変更されたことを示している。図5は、実施の形態に係る情報処理システム500の構成要素同士のつながり、および構成要素とインシデントとの関連を統一的に管理する関連管理マスタ24のデータ構造を模式的に示す図である。関連管理マスタ24において、項目関連元種別と関連先種別とがともに構成管理となっている行は、構成要素同士のつながりを示す。例えば、図5に示す関連管理マスタ24の例において、関連管理IDが0001の行は関連元種別と関連先種別とがともに構成管理となっている。これは図3に示す構成情報マスタ22の例における構成情報ID0001第1ウェブサーバと、構成情報ID0006第1スイッチとが構成上つながりを持っていることを示している。また関連管理マスタ24において、項目関連元種別と関連先種別とのいずれか一方が構成管理であり、もう一方がインシデント管理となっている行は、インシデントと、そのインシデントに関与した構成要素を示す。例えば、図5に示す関連管理マスタ24の例において、関連管理IDが0002の行は関連元種別が構成管理であり、関連先種別がインシデント管理となっている。これは図3に示す構成情報マスタ22の例における構成情報ID0006第1スイッチが、図4に示す変更履歴マスタ26の例における履歴情報ID0001に係るインシデントに関与したことを示す。このように、関連管理マスタ24は、情報処理システム500の構成要素同士のつながり、および構成要素とインシデントとの関連を統一的に管理するために利用することができる。以下、情報処理システム500がネットショッピングを提供するシステムである場合を例として、実施の形態に係るシステム管理支援装置100を具体的に説明する。当然ながら、情報処理システム500はネットオークションサービスやソーシャルネットワークサービスSocialNetworkServiceSNS等、他のサービスを提供する場合についても同様の構成が適用できることは当業者には理解されるところである。インターネット等のネットワークを介して情報処理システム500が提供するネットションピングを利用するユーザから、ネットションピングサイトへのアクセスができないというインシデントが発生したとする。情報処理システム500を管理または保守する担当者以下、単に担当者という。が原因を調査した結果、第3ブレードと第1スイッチ310の3番ポートとの間のリンクダウンであることが判明した。そこでその対処として、第3ブレードと第1スイッチ310とを結ぶネットワークケーブルを交換して第1スイッチ310を再起動したところ、リンクダウンは解消したとする。このとき、インシデント管理部10は、変更履歴マスタ26に第1スイッチ310の変更履歴を格納する。インシデント管理部10はさらに、関連管理マスタ24に、インシデントに第1スイッチ310が関与したこと、およびインシデントに第3ブレードが関与したことを格納する。後日、ネットショッピングサイトでの決算処理のレスポンスが非常に遅いという別のインシデントが発生し、調査の結果、第1ストレージ410と第1スイッチ310とをつなぐ1番ポートが高負荷アクセスとなっていることが判明したとする。そこで、第1スイッチ310における1番ポートの接続を4番ポートの接続に変更したところ、決算処理のレスポンス速度が回復したとする。このとき、インシデント管理部10は、変更履歴マスタ26に第1スイッチ310の変更履歴を格納する。インシデント管理部10はさらに、関連管理マスタ24に、インシデントに第1スイッチ310が関与したこと、およびインシデントに第1ストレージ410が関与したことを格納する。変更実績解析部30は、システム管理データベース20中の関連管理マスタ24を参照して、情報処理システム500を構成する各構成要素についてインシデントの対処に伴って変更された回数を計数する。上記の例の場合、第1スイッチ310の変更回数は2回であり、第3ブレードおよび第1ストレージ410の変更回数はそれぞれ1回である。上述したふたつのインシデントの例は、ショッピングサイトへの接続の問題と決算処理のレスポンスの問題であり、一見直接のつながりはない。しかしながら、これらのインシデントの対処として第1スイッチ310の変更が行われている。このように、異なるインシデントへの対処として、いずれについても変更が行われた構成要素は、その構成要素に何らかの根本的な問題があり、情報処理システム500を運用する上でボトルネックとなる可能性がある。以下、本明細書において、情報処理システム500を運用する上でボトルネックとなる可能性がある構成要素を、単にボトルネック候補と呼ぶことがある。変更実績解析部30は、変更のあった回数が所定の通知基準回数以上となる構成要素を特定する。ここで通知基準回数とは、情報処理システム500を構成する構成要素のうち、情報処理システム500を運用する上でボトルネックとなり得る候補として、担当者に通知すべきか否かを決定するために定められた基準回数である。通知基準回数は、運用するサービスの使用頻度や構成要素の堅牢性等を考慮して実験により定まればよいが、通知基準回数の一例としては2回である。図示はしないが、通知基準回数はシステム管理データベース20内に格納されている。このように、変更実績解析部30が、過去にあったインシデントとそのインシデントに関与した構成要素、および対処のために変更した回数を解析することにより、情報処理システム500を運用する上でボトルネックとなり得る根本的な問題を抱えた構成要素をあぶり出すことが可能となる。ここで変更実績解析部30は、構成変更された回数が所定の通知基準回数以上である構成要素を特定する際に、特定を実施する時点からさかのぼって所定の変更計数期間内にあった変更のみを計数し、変更計数期間よりも過去にあった変更については計数しないようにしてもよい。これにより、過去に多くの変更を要した構成要素があったとしてもある時点で根本的な問題が解決し、その後は問題を起こさないような構成要素がボトルネック候補として通知されることを防止できる。したがって、変更計数期間とは、構成要素をボトルネック候補として特定する際に、変更回数として加算すべき変更か否かを決定するための基準期間である。変更計数期間は情報処理システム500が提供するサービス内容や構成要素の堅牢性等を鑑みて実験により定めればよいが、一例としては3ヶ月である。変更実績解析部30は、変更計数期間内に変更された回数を、前述した構成情報マスタ22内の期間内変更回数に格納する。変更実績解析部30はまた、構成要素が情報処理システム500に設置されてから現在に至るまでの間にあった変更回数を、構成情報マスタ22内の総変更回数に格納する。インシデント管理部10は、変更実績解析部30が特定したボトルネック候補を、ボトルネック候補マスタ28に格納する。図6は、ボトルネック候補を管理するボトルネック候補マスタ28のデータ構造を模式的に示す図である。ボトルネック候補マスタ28は、ボトルネック候補となる構成要素に対応する構成情報IDと、そのボトルネック候補について調査等の対応をしたか否かを表すステータス、対応が終了している場合には対応日とを関連付け、ボトルネック候補を一意に表すボトルネック候補IDを付して格納する。通知部40は、変更実績解析部30が特定した構成要素を情報処理システム500のボトルネック候補として通知する。通知の仕方としては、例えば情報処理システム500の担当者に電子メールを送信する方法で行われる。あるいは、ボトルネック候補を示す専用のサイトを用意し、担当者がそこにアクセスすることで画面として提示してもよい。通知部40がボトルネック候補を最初に通知した日付は、ボトルネック候補マスタ28中に通知日として、その構成要素と関連づけて格納される。図7は、ボトルネックとなり得る構成要素の候補を示す画面の一例を示す図である。図7に示す画面の例では、トップページとして、ボトルネック候補を含む情報処理システム名およびその名称が、それらを一意に表すIDとともに一覧表示される。名称にはリンクが張られており、画面の閲覧者がリンクをクリックすることによってその情報処理システム500に対応するボトルネック候補マスタ28の内容を表示する専用の画面図示せずが表示される。情報処理システム500の担当者は、通知部40からのボトルネック候補の通知を確認することで、第1スイッチ310がボトルネック候補であることを認識したとする。情報処理システム500の担当者が第1スイッチ310を詳細に調査したところ、第1スイッチ310のファームウェアに不具合を見つけたとする。そこで第1スイッチ310のファームウェアにパッチを当てることでファームウェアに不具合が解決した場合、担当者はその旨をインシデント管理部10に入力する。インシデント管理部10は、第1スイッチ310のファームウェアを変更したことを関連管理マスタ24および変更履歴マスタ26に格納し、ボトルネック候補マスタ28のステータスおよび対応日を更新する。これにより、ボトルネック候補を示す画面を見た別の担当者が、担当済みのボトルネック候補を重複して調査することを防止できる。図8は、実施の形態に係るシステム管理支援装置100における処理の流れを示すフローチャートである。本フローチャートにおける処理は、例えばシステム管理支援装置100の電源が投入されたときに開始する。以下に示すフローチャートは情報処理システム500の運用中の処理フローを表すものであり、例えば構成情報マスタ22や関連管理マスタ24への情報処理システム500の構成情報の入力は完了していることを前提とする。情報処理システム500の運用中にインシデントが発生するとS10、インシデント管理部10は、関連管理マスタ24にインシデントとそのインシデントに関与した構成要素とを対応づけて格納するS12。インシデントに対処するために、情報処理システム500の担当者がそのインシデントに関与した構成要素を変更した場合S14のY、担当者は変更の情報をインシデント管理部10に入力し、インシデント管理部10は、変更履歴マスタ26を更新するS16。インシデントに対処するために、情報処理システム500の担当者がそのインシデントに関与した構成要素を変更しない場合S14のN、インシデント管理部10は変更履歴マスタ26を更新しない。変更実績解析部30は、情報処理システム500を構成するある構成要素について、関連管理マスタ24を参照してインシデントに関与したケースを特定する。変更実績解析部30は、構成要素がインシデントに関与している場合、変更履歴マスタ26を参照して、そのインシデントの対処に伴ってその構成要素が変更されたか否かを特定する。変更実績解析部30は、情報処理システム500を構成する全ての構成要素について上述の処理を繰り返すことで、構成要素の変更回数Pを計数するS18。続いて変更実績解析部30は、システム管理データベース20から、通知基準回数Tを取得するS20。変更実績解析部30は、計数した変更回数Pと、取得した通知基準回数Tとを比較して大小関係を取得するS22。計数した変更回数Pが取得した通知基準回数T以上である場合S24のY、変更実績解析部30はボトルネック候補マスタ28を更新するS26。通知部40は、変更回数Pが通知基準回数T以上となった構成要素をボトルネック候補として通知するS28。計数した変更回数Pが取得した通知基準回数T未満である場合S24のN、あるいは通知部40がボトルネック候補を通知した後、変更実績解析部30は構成情報マスタ22内の期間内変更回数および総変更回数を更新するS30。以上の処理を繰り返すことにより、実施の形態に係るシステム管理支援装置100は、情報処理システム500を構成する構成要素の変更を管理し、そのボトルネック候補を特定する。以上の構成による動作は以下のとおりである。情報処理システム500を構築した際に、担当者は情報処理システム500の構成情報を構成情報マスタ22および関連管理マスタ24に入力する。インシデント管理部10は、情報処理システム500の運用中に生じたインシデントやそのインシデントの対処に伴ってされた構成要素の変更を関連管理マスタ24および変更履歴マスタ26を用いて管理する。これにより、変更実績解析部30は、変更回数を計数することで、情報処理システム500のボトルネックとなり得る構成要素を特定する。情報処理システム500の担当者はボトルネック候補を解析することで、問題が起こる前に事前に対処策を講じることができる。以上説明したように、実施の形態のシステム管理支援装置100によれば、情報処理システム500においてボトルネックとなり得る構成要素の特定を支援することができる。これにより、情報処理システム500の運用中に問題が起こる前にボトルネック候補を調査し、問題があれば事前に対処することができる。以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。第1の変形例を説明する。上述したとおり、システム管理データベース20内のボトルネック候補マスタ28は、ボトルネック候補を担当者に最初に通知した日付を通知日として格納している。通知部40は、ボトルネック候補として最初に通知した通知日から、ボトルネック候補期間として定められた所定の期間経過した場合、その構成要素はボトルネック候補として通知しないようにしてもよい。ここでボトルネック候補期間とは、変更実績解析部30が特定した構成要素が、ボトルネック候補とみなされる期間として定められた期間であり、例えば3ヶ月である。変更実績解析部30が特定した構成要素はあくまでもボトルネックの候補であるので、所定の期間、情報処理システム500の運用に支障をきたさないのであれば、その構成要素はボトルネックである可能性が低いと考えられる。そこでボトルネック候補期間を導入し、その期間を経過したボトルネック候補を担当者に通知しないようにすることにより、担当者がボトルネックである可能性の低い構成要素を解析する手間を省略することができる。第2の変形例を説明する。上記の説明では、情報処理システム500を構成する全ての構成要素について共通の通知基準回数を設定する場合について説明したが、通知基準回数として構成要素毎に異なる値を定めてもよい。この場合、変更実績解析部30は構成要素毎に定められた通知基準回数をシステム管理データベース20から取得し、計数した構成要素の変更回数が、その構成要素用に定められた通知基準回数以上であるか否かを比較する。例えばブレード上でローカルに実行されるオペレーティングシステムや、そのオペレーティングシステム上で実行される仮想マシン250はソフトウェアであるため、ブレードに内蔵されるハードウェアである第2ネットワークインタフェース260と比較すると、変更回数が多くなる傾向にある。ハードウェアの場合は物理的に削除したり交換したりする場合に変更となるのに対し、ソフトウェアの場合はそのソフトウェア自体を入れ替える場合のみならず、オンラインアップデートによる修正も変更実績となるからである。そこで、情報処理システム500を構成する構成要素それぞれについて、構成要素がハードウェアであるのかソフトウェアであるのかも含めて、構成要素自体の性質や構成要素の堅牢性、使用頻度等を勘案し、各構成要素に適した通知基準回数を実験により定めておく。全ての構成要素について共通の通知基準回数を設定する場合と比較して、変更実績解析部30によるボトルネック候補の特定精度をより高めることができる。請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。