(57)【要約】【課題】必要な修正のみ適用すること。【解決手段】情報処理装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、バグレポート２の情報を記憶する。演算部１ｂは、１または複数のソフトウェアの複数の機能それぞれを実行した際の、自装置の動作状況を示す環境情報を機能ごとに取得する。演算部１ｂは、取得した機能ごとの環境情報が、バグレポート２の情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する。【選択図】図１
2016015021.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
１または複数のソフトウェアの複数の機能それぞれを実行した際の、前記コンピュータの動作状況を示す環境情報を機能ごとに取得し、
取得した前記機能ごとの環境情報が、バグレポートの情報に含まれる前記機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、
処理を実行させる修正適用判断プログラム。
【請求項２】
前記バグレポートは、バグに起因する障害の発生条件を示す情報を含み、
前記障害の発生条件に基づいて前記機能ごとの環境情報の条件を生成する、
請求項１記載の修正適用判断プログラム。
【請求項３】
前記取得では、前記バグレポートの情報に含まれる前記機能ごとの環境情報に応じて、取得対象の環境情報を絞り込む、請求項１または２記載の修正適用判断プログラム。
【請求項４】
前記決定では、何れかのソフトウェアに対する修正の適用要否を決定すると、当該修正の適用の判定に用いられた前記機能ごとの環境情報の取得を停止する、請求項１乃至３記載の修正適用判断プログラム。
【請求項５】
バグレポートの情報を記憶する記憶部と、
１または複数のソフトウェアの複数の機能それぞれを実行した際の、自装置の動作状況を示す環境情報を機能ごとに取得し、
取得した前記機能ごとの環境情報が、前記バグレポートの情報に含まれる前記機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、演算部と、
を有する情報処理装置。
【請求項６】
コンピュータが、
１または複数のソフトウェアの複数の機能それぞれを実行した際の、前記コンピュータの動作状況を示す環境情報を機能ごとに取得し、
取得した前記機能ごとの環境情報が、バグレポートの情報に含まれる前記機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、
修正適用判断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は修正適用判断プログラム、情報処理装置および修正適用判断方法に関する。
【背景技術】
【０００２】
コンピュータなどの情報処理装置を複数含む情報処理システムが利用されている。情報処理システムでは複数のソフトウェアが利用され得る。ソフトウェアの不具合は、情報処理システムの障害の要因になるおそれがある。ソフトウェアを修正することで、不具合を解消し得る。そこで、ソフトウェアを修正する方法が考えられている。
【０００３】
例えば、複数の機能をもつプログラム製品を使用する監視対象装置において、使用許可または使用履歴が記録された機能を修正対象と判定し、当該修正対象に対するメンテナンスデータを運用管理装置から取得し、プログラム製品に適用する提案がある。
【０００４】
また、不具合の箇所を修正するパッチの適用対象の情報処理装置において、パッチが実行された場合に、パッチがアクセスするリソースを別の機能が使用する場合に、パッチの適用可否を管理者に問い合わせる提案もある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−９９３１９号公報
【特許文献２】特開２０１４−１３４５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
修正の適用には、リグレッション（または、デグレーション）のリスクがある。例えば、複数の機能が関係し合っているとき、ある機能に対する修正が、修正前は正常に動作していた他の機能に影響を及ぼし、誤動作を引き起こす可能性がある。
【０００７】
ここで、不具合の発見されているソフトウェアを利用しているからといって、必ずしも現利用環境下で障害が発生するとは限らない。障害の発生は、機能利用時の個々の情報処理装置の動作状況（リソース使用量、使用パラメタ、接続ユーザ数など）によることもあるからである。利用している全ての機能に対して無暗に修正を適用していると、余計な修正適用によりリグレッションなどのリスクを却って助長しかねないという問題がある。
【０００８】
１つの側面では、本発明は、必要な修正のみ適用できる修正適用判断プログラム、情報処理装置および修正適用判断方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
１つの態様では、修正適用判断プログラムが提供される。修正適用判断プログラムは、コンピュータに、１または複数のソフトウェアの複数の機能それぞれを実行した際の、コンピュータの動作状況を示す環境情報を機能ごとに取得し、取得した機能ごとの環境情報が、バグレポートの情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、処理を実行させる。
【００１０】
また、１つの態様では、情報処理装置が提供される。情報処理装置は、記憶部と演算部とを有する。記憶部は、バグレポートの情報を記憶する。演算部は、１または複数のソフトウェアの複数の機能それぞれを実行した際の、自装置の動作状況を示す環境情報を機能ごとに取得し、取得した機能ごとの環境情報が、バグレポートの情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する。
【００１１】
また、１つの態様では、修正適用判断方法が提供される。修正適用判断方法では、コンピュータが、１または複数のソフトウェアの複数の機能それぞれを実行した際の、コンピュータの動作状況を示す環境情報を機能ごとに取得し、取得した機能ごとの環境情報が、バグレポートの情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する。
【発明の効果】
【００１２】
１つの側面では、必要な修正のみ適用できる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態の情報処理装置を示す図である。
【図２】第２の実施の形態の情報処理システムを示す図である。
【図３】サーバのハードウェア例を示す図である。
【図４】情報処理システムの機能例を示す図である。
【図５】バグレポートの例を示す図である。
【図６】修正適用識別情報の例を示す図である。
【図７】ログ採取管理テーブルの例を示す図である。
【図８】ログの例を示す図である。
【図９】バグ識別結果テーブルの例を示す図である。
【図１０】修正適用の判断例を示すフローチャートである。
【図１１】ログの記録例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。情報処理装置１は、ソフトウェアを実行する。情報処理装置１には、複数のソフトウェアがインストールされ得る。ソフトウェアは複数の機能を含み得る。情報処理装置１は、記憶部１ａおよび演算部１ｂを有する。
【００１５】
記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂはプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
【００１６】
記憶部１ａは、バグレポート２の情報を記憶する。バグレポート２は、ソフトウェアの欠陥（バグ）に関する情報である。バグレポート２は、実運用環境やテスト環境などでバグに起因して発生した障害の報告を含み、障害発生時におけるシステムの動作状況に関する情報を含む。また、バグレポート２は、バグに起因する障害発生の可能性が比較的高いと判定するための条件を含む。ここで、ある装置がソフトウェアの機能を実行したときの当該装置の動作状況が、ソフトウェアのバグによる誤動作の発生要因になり得る。装置の動作状況は、例えば機能実行時におけるリソース使用量、使用パラメタおよび接続ユーザ数などの環境情報を用いて表される。
【００１７】
バグレポート２は、例えば、ソフトウェアＡのバグａについて、機能ごとの環境情報に関し、バグａに起因する障害が発生する可能性が高いと判断される次の条件（１）、（２）、（３）を含む。（１）機能ｘ実行時の環境情報αがα＜３００であり、かつ、（２）機能ｙ実行時の環境情報βがβ≧８０％であり、かつ、（３）機能ｚ実行時の環境情報γがγ＝１００である。
【００１８】
また、記憶部１ａはログ３の情報を記憶する。ログ３は、情報処理装置１で実行される１または複数のソフトウェアに関する情報の履歴である。
演算部１ｂは、１または複数のソフトウェアの複数の機能それぞれを実行した際の、情報処理装置１の環境情報を機能ごとに取得する。例えば、演算部１ｂは、機能ｘを実行するたびに、機能ｘの実行中における環境情報αを取得し、ログ３に記録する。演算部１ｂは、機能ｙを実行するたびに、機能ｙの実行中における環境情報βを取得し、ログ３に記録する。演算部１ｂは、機能ｚを実行するたびに、機能ｚの実行中における環境情報γを取得し、ログ３に記録する。
【００１９】
演算部１ｂは、バグレポート２の情報を参照して、バグレポート２に含まれる機能ｘの実行時の環境情報α、機能ｙの実行時の環境情報βおよび機能ｚの実行時の環境情報γに限定して、ログ３に記録してもよい。すなわち、演算部１ｂは、バグレポート２に含まれていない環境情報をログ３に記録しなくてもよい。
【００２０】
演算部１ｂは、取得した機能ごとの環境情報が、バグレポート２の情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する。
【００２１】
例えば、演算部１ｂは、ある期間内にログ３の記録を行い、バグレポート２に含まれる条件を満たすか否かの監視を行う。ここで、ログ３には、機能ｘ実行時の環境情報αについて、α＝２００という情報が記録されている。これは、条件（１）を満たす。また、ログ３には、機能ｙ実行時の環境情報βについて、β＝８５％という情報が記録されている。これは、条件（２）を満たす。更に、ログ３には、機能ｚ実行時の環境情報γについて、γ＝１００という情報が記録されている。これは、条件（３）を満たす。演算部１ｂは、条件（１）、（２）、（３）を全て満たすので、情報処理装置１において、ソフトウェアＡのバグａに対する修正を適用すると決定する。
【００２２】
一方、ある期間内での演算部１ｂによる監視で、条件（１）、（２）、（３）の少なくとも１つの条件が、満たされないこともある。その場合、演算部１ｂは、情報処理装置１において、ソフトウェアＡのバグａに対する修正を適用しないと決定する。
【００２３】
情報処理装置１によれば、１または複数のソフトウェアの複数の機能それぞれを実行した際の情報処理装置１の動作状況を示す環境情報が機能ごとに取得される。取得した機能ごとの環境情報が、バグレポート２の情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用が決定される。これにより、必要な修正のみ適用できる。
【００２４】
ここで、不具合の発見されているソフトウェアを利用しているからといって、必ずしも現在の利用環境下で障害が発生するとは限らない。ソフトウェアのバグに起因する障害の発生が、機能利用時の情報処理装置１の動作状況によることもあるからである。すなわち、ソフトウェアに不具合が発見されていても、ある特定の条件が揃わない限りは、障害にまで至らないこともある。
【００２５】
例えば、利用しているソフトウェアに対する全ての修正（全ての機能に対する修正）を、適用することも考えられる。しかし、利用しているソフトウェアに対して全ての修正を適用していると、現在の利用環境下では起こり得ないような障害に関する余計な修正も適用される可能性がある。余計な修正適用を行っていると、リグレッションや適用失敗などのリスクを却って助長しかねない。
【００２６】
一方、ある機能に対する修正が、他の機能や他のソフトウェアの動作に影響がないことを確かめるために、実環境で修正前に、テスト環境を用いた確認テストを行うことも考えられる。しかし、情報処理装置１では、多数のミドルウェアやアプリケーションが動作し、修正も頻繁に発生し得る。修正がリリースされるたびに、全ての修正に対して事前の確認を行うのは、多大な工数を要し、現実的ではない。
【００２７】
これに対し、情報処理装置１は、バグレポート２に基づいて、修正適用の要否を判断する。バグレポート２は、実環境での実績に応じた障害発生の条件（あるいは、障害発生の可能性が比較的高いと判断される条件）を含んでいる。情報処理装置１は、ソフトウェアの現在の利用環境下において、バグによる障害が発生し得るかを適切に判断した上で、修正の適用を決定できる。このため、必要な修正のみ適用できる。すなわち、不要な修正の適用を抑止できる。また、適用対象の修正を絞り込むことで、全ての修正を適用するよりも、リグレッションなどのリスクを軽減できる。こうして、効率的なシステム保守を支援できる。
【００２８】
情報処理装置１は、バグレポート２で示される機能毎の環境情報に限定して、ログ３に記録してもよい。記録する内容を絞り込むことで、余分な情報をログ３に記録するよりも、情報処理装置１の負荷を軽減できる。
【００２９】
なお、情報処理装置１は、他の情報処理装置におけるソフトウェアの修正の適用要否を判断してもよい。具体的には、情報処理装置１は、他の情報処理装置が１または複数のソフトウェアの複数の機能それぞれを実行した際の、他の情報処理装置の動作状況を示す環境情報を機能ごとに取得してもよい。情報処理装置１は、他の情報処理装置から取得した機能ごとの環境情報が、バグレポート２の情報に含まれる機能ごとの環境情報の条件を満たすか否かの判定に応じて、他の情報処理装置におけるソフトウェアの修正の適用要否を決定することもできる。
【００３０】
更に、上記の例では、情報処理装置１はバグレポート２に含まれる条件が満たされる場合に修正を適用し、満たされない場合に修正を適用しないと決定することを例示した。一方、バグレポート２にバグによる障害が発生しない条件が含まれることもある。その場合、情報処理装置１は、バグレポート２の条件が満たされない場合に修正を適用し、バグレポート２の条件が満たされる場合に修正を適用しないと決定することも考えられる。
【００３１】
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、サーバ１００，１００ａ，１００ｂおよび管理サーバ２００を有する。サーバ１００，１００ａ，１００ｂおよび管理サーバ２００は、ネットワーク１０に接続されている。ネットワーク１０は、例えばＬＡＮ（Local Area Network）である。
【００３２】
サーバ１００，１００ａ，１００ｂは、複数のミドルウェアや複数のアプリケーションを実行するサーバコンピュータである。以下の説明では、ミドルウェアやアプリケーションなどを総称してソフトウェアと称することがある。サーバ１００，１００ａ，１００ｂは、ネットワーク１０を介して、クライアントコンピュータ（図示を省略）にアプリケーションに応じたサービスを提供することもできる。
【００３３】
管理サーバ２００は、サーバ１００，１００ａ，１００ｂを管理するサーバコンピュータである。管理サーバ２００は、ソフトウェアのバグに関するバグレポートを記憶し、サーバ１００，１００ａ，１００ｂに配信する。バグレポートは、ソフトウェアの実際の利用により発生したバグに関する情報である。バグレポートは、ソフトウェアおよびバグの識別情報、当該バグにより発生する障害の内容や障害の発生条件などの情報を含む。
【００３４】
例えば、第２の実施の形態の情報処理システムの保守を行う管理者は、第２の実施の形態の情報処理システムまたは他の情報処理システムで発生した障害に基づいて、バグレポートの情報を作成し、管理サーバ２００に登録する。あるいは、ソフトウェアを提供する事業者が、ユーザから収集した情報や、ソフトウェアの動作テストの結果などを基にバグレポートを作成し、ソフトウェアのユーザに配布することもある。例えば、管理サーバ２００は、ソフトウェアの事業者が管理するサーバコンピュータ（図示を省略）から、バグレポートの情報を取得することもできる。
【００３５】
図３は、サーバのハードウェア例を示す図である。サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、読み取り装置１０６および通信インタフェース１０７を有する。各ユニットはサーバ１００のバスに接続されている。管理サーバ２００もサーバ１００と同様のハードウェアを用いて実現できる。
【００３６】
プロセッサ１０１は、サーバ１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００３７】
ＲＡＭ１０２は、サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）、ミドルウェアおよびアプリケーションなどの各種ソフトウェアのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００３８】
ＨＤＤ１０３は、サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、各種ソフトウェアのプログラム、および各種データが格納される。サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００３９】
画像信号処理部１０４は、プロセッサ１０１からの命令に従って、サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００４０】
入力信号処理部１０５は、サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００４１】
読み取り装置１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。読み取り装置１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００４２】
通信インタフェース１０７は、ネットワーク１０を介して他の装置と通信を行う。通信インタフェース１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００４３】
図４は、情報処理システムの機能例を示す図である。サーバ１００は、記憶部１１０、ソフトウェア群１２０、ログ生成部１３０および判定部１４０を有する。記憶部１１０は、ＲＡＭ１０２やＨＤＤ１０３に確保された記憶領域として実現され得る。ログ生成部１３０および判定部１４０は、プロセッサ１０１によりプログラムが実行されることで実現され得る。
【００４４】
記憶部１１０は、管理サーバ２００から取得したバグレポートの情報（以下、単にバグレポートと称する）を記憶する。記憶部１１０は、ソフトウェア群１２０に関するログの情報（以下、単にログと称する）を記憶する。記憶部１１０は、ソフトウェア群１２０に含まれる各ソフトウェアに対する修正適用の要否に関する情報を記憶する。
【００４５】
ソフトウェア群１２０は、サーバ１００にインストールされたミドルウェアやアプリケーションなどのソフトウェアの集合である。ソフトウェア群１２０は、ソフトウェア１２１，１２２，１２３を含む。ソフトウェア１２１は、複数の機能を有する。例えば、ソフトウェア１２１の機能は、ソフトウェア１２１の実行時に呼び出される関数やクラスなどを示す識別子によって区別され得る。あるいは、ソフトウェア１２１の機能は、ソフトウェア１２１に対して入力される実行指示コマンドによって区別され得る。ソフトウェア１２２およびソフトウェア１２３も、ソフトウェア１２１と同様に複数の機能を有する。
【００４６】
ソフトウェア１２１，１２２，１２３の機能は、他のソフトウェアの機能と連携することもある。例えば、ミドルウェアの機能が、アプリケーションの機能を実現する前提になることもある。また、例えば、あるアプリケーションの機能が他のアプリケーションの機能を実現する前提になることもある。
【００４７】
ログ生成部１３０は、ソフトウェア１２１，１２２，１２３の複数の機能の実行状況を監視する。例えば、ログ生成部１３０は、ソフトウェア１２１，１２２，１２３において呼び出された関数やクラス、および、ソフトウェア１２１，１２２，１２３に入力された実行指示コマンドなどの情報から、何れの機能が実行されているかを監視できる。
【００４８】
ログ生成部１３０は、記憶部１１０に記憶されたバグレポートに基づいて、ソフトウェア１２１，１２２，１２３の複数の機能それぞれの実行に応じたログを生成し、記憶部１１０に格納する。ログ生成部１３０は、機能実行時におけるサーバ１００の環境情報を、機能ごとにログとして記録する。
【００４９】
環境情報としては、ファイル数、リソース（プロセッサ１０１、ＲＡＭ１０２およびＨＤＤ１０３など）の使用量、リソースの未使用量、機能実行時に使用されたパラメタの値、および、サーバ１００を利用中のユーザ数（接続ユーザ数）などが考えられる。ログ生成部１３０は、何れの情報を環境情報として取得するかを、バグレポートに基づいて、機能ごとに決定する。
【００５０】
判定部１４０は、記憶部１１０に記憶されたログに含まれる機能ごとの環境情報に基づいて、バグレポートに登録されているバグに対する修正の適用が、サーバ１００において必要であるか否かを判定する。ここで、バグレポートには、修正を適用すべきか否かを判定するための、環境情報に関する条件が登録されている。判定部１４０は、バグレポートに含まれる条件と、ログに記録された環境情報とを対比することで、サーバ１００において修正の適用が必要であるか否かを判定できる。
【００５１】
なお、サーバ１００ａ，１００ｂも、サーバ１００と同様に、記憶部１１０、ソフトウェア群１２０、ログ生成部１３０および判定部１４０に相当する機能を有している。
管理サーバ２００は、記憶部２１０および管理部２２０を有する。記憶部２１０は、管理サーバ２００が備えるＲＡＭやＨＤＤに確保された記憶領域として実現され得る。管理部２２０は、管理サーバ２００が備えるプロセッサによりプログラムが実行されることで実現され得る。
【００５２】
記憶部２１０は、バグレポートを記憶する。記憶部２１０は、サーバ１００，１００ａ，１００ｂに対するバグの修正適用の要否を示す情報を記憶する。バグレポートは、前述のように、第２の実施の形態の情報処理システムの管理者により、発生した障害および発見されたバグに応じて作成され、記憶部２１０に登録される。あるいは、ソフトウェア１２１，１２２，１２３を提供する事業者によりバグレポートが配布される場合、管理サーバ２００は、当該事業者のサーバから、バグレポートをダウンロードし、記憶部２１０に格納してもよい。
【００５３】
管理部２２０は、サーバ１００，１００ａ，１００ｂで利用されるソフトウェアを管理する。管理部２２０は、サーバ１００からのバグレポートの要求に応じて、記憶部２１０に記憶されたバグレポートをサーバ１００に送信する。管理部２２０は、サーバ１００ａ，１００ｂからのバグレポートの要求に対しても同様にしてバグレポートを提供できる。
【００５４】
管理部２２０は、サーバ１００におけるバグの修正適用の要否を示す情報をサーバ１００から受信し、記憶部２１０に格納する。管理部２２０は、サーバ１００ａ，１００ｂからも同様に、サーバ１００ａ，１００ｂにおけるバグの修正適用の要否を示す情報を受信し、記憶部２１０に格納する。
【００５５】
管理部２２０は、サーバ１００，１００ａ，１００ｂにおけるバグの修正適用の要否を示す情報を、情報処理システムの管理者や保守員などに通知する。例えば、管理部２２０は、サーバ１００，１００ａ，１００ｂにおけるバグの修正適用の要否を示す情報を、管理サーバ２００に接続されたディスプレイに表示させてもよい。また、管理部２２０は、サーバ１００，１００ａ，１００ｂにおけるバグの修正適用の要否を示すメッセージを含む電子メールを、管理者や保守員などが利用する電子メールアドレスを宛先として送信してもよい。
【００５６】
図５は、バグレポートの例を示す図である。バグレポート１１１は、記憶部１１０に記憶される。例えば、ログ生成部１３０は、管理サーバ２００からバグレポート１１１を取得し、記憶部１１０に格納する。以下、バグレポート１１１の左側に付した行番号を示して説明する。バグレポート１１１は、修正番号、現象、ソフトウェア構成、発生条件、原因および修正適用識別用リストの項目を含む。
【００５７】
修正番号には、ソフトウェアのバグおよび当該バグに対する修正内容を識別するための情報（修正番号）が設定される。例えば、バグレポート１１１には、修正番号として“ＢＵＧ００１”が設定されている（１，２行目）。例えば、修正番号に対応するソフトウェアおよびソフトウェアの修正内容の情報が管理サーバ２００により別途保持される（修正番号から修正内容を識別できる）。修正内容の情報としては、例えば、適用する修正プログラム（パッチと呼ばれることもある）を示す情報が考えられる。
【００５８】
現象には、バグにより発生する障害の内容が設定される。例えば、バグレポート１１１には、「機能Ｆ１で、イベントＥに対するアクションが実行されない。」という情報が設定されている（４，５行目）。
【００５９】
ソフトウェア構成には、バグによる障害が発生したサーバにおけるソフトウェア構成が設定される。例えば、バグレポート１１１には、「（１）ソフトウェアＸをインストールしている。（２）インストール時に、構成ＡＡＡを選択している。」という情報が設定されている（７〜９行目）。「ソフトウェアＸ」は、例えばソフトウェア１２１の名称である。「構成ＡＡＡ」は、例えばソフトウェアＸのインストール時に選択可能な利用対象機能の複数の組合せの中の１つの名称である。
【００６０】
発生条件には、バグによる障害が発生したときの環境情報に関する条件が設定される。例えば、バグレポート１１１には、「（１）機能Ｆ１で使用するファイル数が１２００以上。（２）機能Ｆ３実行時のディスクの使用量が９５％以上。（３）機能Ｆ３実行時のパラメタＰ１の入力値がＡＢＣ。」という情報が設定されている（１１〜１４行目）。
【００６１】
原因には、プログラムのバグに該当する箇所の情報やバグにより誤動作が引き起こされる理由などが設定される（１６，１７行目）。
修正適用識別用リストには、バグに対する修正を適用するか否かの判定条件が設定される。例えば、バグレポート１１１には、修正適用識別情報１１１ａが設定されている（１９行目以降）。修正適用識別情報１１１ａは、バグに対する修正を適用するか否かの判定条件を示すメタデータである。
【００６２】
図６は、修正適用識別情報の例を示す図である。修正適用識別情報１１１ａは、バグレポート１１１に含まれる。修正適用識別情報１１１ａは、修正番号、採取ログおよび条件値の情報を含む。
【００６３】
修正番号の項目には、修正番号が登録される。採取ログの項目には、採取対象とするログの種類を示す情報が登録される。採取対象とするログは、機能名および環境情報によって識別される。機能名は、何れかのソフトウェアの機能の識別情報である。環境情報は、取得対象とする環境情報の識別情報である。
【００６４】
条件値の項目には、修正番号で示されるバグに対する修正の適用可否を判定するための条件が登録される。修正適用識別情報１１１ａの例では、１つの修正番号に対して、採取ログおよび条件値が複数種類ある場合は、複数の条件値が全て満たされたときに、修正を適用すると判断するものとする。ただし、複数の条件値の何れかが満たされたときに、修正を適用すると判断するような条件を設定することも考えられる。
【００６５】
例えば、修正適用識別情報１１１ａには、修正番号が“ＢＵＧ００１”、採取ログの機能名が“機能Ｆ１”、環境情報が“ファイル数”、条件値が“８００以上”という情報が登録される。これは、“ＢＵＧ００１”で示されるバグに対し、機能Ｆ１の実行時に、機能Ｆ１の処理対象となるファイル数の情報をログとして取得することを示す。また、処理対象となるファイル数が“８００以上”のときに、修正を適用するための１つの条件が満たされることを示す。
【００６６】
修正適用識別情報１１１ａには、修正番号“ＢＵＧ００１”に対して、その他にも機能Ｆ３の実行時に、ディスク使用率および機能Ｆ３の処理などに用いられるパラメタＰ１の設定値をログとして取得することが示されている。修正適用識別情報１１１ａには、ディスク使用率に対する条件値として、例えば“７０％以上”という情報が登録されている。修正適用識別情報１１１ａには、パラメタＰ１に対する条件値として、例えば“ＡＢＣに等しい”という情報が登録されている。
【００６７】
修正適用識別情報１１１ａの例によれば、「機能Ｆ１の実行時における機能Ｆ１の処理対象のファイル数が８００以上、かつ、機能Ｆ３の実行時におけるディスク使用率が７０％以上、かつ、機能Ｆ３の実行時におけるパラメタＰ１の設定がＡＢＣ」という条件を満たすとき、ＢＵＧ００１に対する修正を適用すると判断することになる。
【００６８】
ここで、条件値の設定内容は、バグレポート１１１で示されるバグによる障害の発生条件よりも緩い条件（障害の発生条件で示される値よりも緩い値）とすることが好ましい。バグによる障害が発生する前に修正を適用することで、障害の発生を未然に防げるからである。例えば、ある環境情報について第１の閾値以上がバグによる障害の発生条件である場合、緩い値は、第１の閾値よりも所定割合だけ小さい値である。また、ある環境情報について第２の閾値以下がバグによる障害の発生条件である場合、緩い値は、第２の閾値よりも所定割合だけ大きい値である。
【００６９】
ただし、修正適用判定のための条件値と発生条件との差が小さ過ぎると障害の発生のリスクが高まる。一方、修正適用判定のための条件値と発生条件との差が大き過ぎると修正適用の頻度が増える。そこで、上記の所定割合（安全率）としては、例えば２０〜３０％程度が好ましい。具体的には、上記の第１の閾値（障害の発生条件の値）に対しては、第１の閾値の２０〜３０％程度小さな値を、修正適用判定のための条件値とする。上記の第２の閾値（障害の発生条件の値）に対しては、第２の閾値の２０〜３０％程度大きな値を、修正適用判定のための条件値とする。ログ生成部１３０が、バグレポート１１１の発生条件に登録された値に基づいて、修正適用識別情報１１１ａにおける条件値を決定してもよい。すなわち、ログ生成部１３０が、障害の発生条件に基づいてソフトウェアの機能ごとの環境情報の条件を生成してもよい。
【００７０】
図７は、ログ採取管理テーブルの例を示す図である。ログ採取管理テーブル１１２は、記憶部１１０に記憶される。ログ採取管理テーブル１１２は、修正適用識別情報１１１ａに基づいて、ログ生成部１３０により生成される。ログ採取管理テーブル１１２は、修正番号、採取ログ、採取状況、採取期間および条件値の項目を含む。
【００７１】
修正番号の項目には、修正番号が登録される。採取ログの項目には、採取対象とするログの種類を示す情報が登録される。採取対象とするログは、図６で説明したように、機能名と環境情報の識別情報とによって示される。
【００７２】
採取状況の項目には、該当のログが現在採取対象となっているか否かを示す情報が登録される。現在採取対象となっていれば、“ＯＮ”が登録される。現在採取対象となっていなければ、“ＯＦＦ”が登録される。
【００７３】
採取期間の項目には、該当のログを採取する期間の情報が登録される。採取期間は、期間の開始の日（日時でもよい）および期間の終了の日（日時でもよい）により示される。条件値の項目には、修正番号で示されるバグに対する修正の適用可否を判定するための条件が登録される。設定内容は、図６で説明した同名の項目の設定内容と同一である。
【００７４】
例えば、ログ採取管理テーブル１１２には、修正番号が“ＢＵＧ００１”、採取ログの機能名が“機能Ｆ１”、環境情報が“ファイル数”、採取状況が“ＯＮ”、採取期間の開始が“２０１４／１／１”、採取期間の終了が“２０１４／２／１”、条件値が“８００以上”という情報が登録される。これは、“ＢＵＧ００１”で示されるバグに対し、機能Ｆ１の実行時に、機能Ｆ１の処理対象となるファイル数の情報をログとして取得することを示す。ログの採取期間が２０１４年１月１日から、２０１４年２月１日までであること、現在、当該ログが採取対象となっていることを示す。また、処理対象となるファイル数が“８００以上”のときに、修正を適用するための複数の条件のうちの１つが満たされることを示す。
【００７５】
ログ採取管理テーブル１１２の修正番号“ＢＵＧ００１”について、採取ログおよび条件値として登録される情報は、修正適用識別情報１１１ａに登録された情報と同一である。ログ採取管理テーブル１１２には、複数のバグレポートそれぞれに含まれる修正適用識別情報の内容がマージされて登録されることになる。例えば、ログ採取管理テーブル１１２には、修正適用識別情報１１１ａで示した修正番号“ＢＵＧ００１”の他に、修正番号“ＢＵＧ００２”の情報も含まれている。
【００７６】
図８は、ログの例を示す図である。ログ１１３は、ログ採取管理テーブル１１２で指定された採取ログの出力結果である。ログ１１３は、記憶部１１０に記憶される。ログ１１３は、ＣＳＶ（Comma Separated Values）形式で出力されている。データ項目は、“機能名”、“環境情報”、“ログ内容”であり、カンマ記号を用いて“機能名，環境情報，ログ内容”と区別される。
【００７７】
例えば、ログ１１３の１行目には、“機能Ｆ１，ファイル数，６００”という情報が記録されている。これは、機能Ｆ１を実行した際に、機能Ｆ１による処理対象のファイル数が６００個であったことを示す。
【００７８】
また、例えば、ログ１１３の２行目には、“機能Ｆ３，パラメタＰ１，ＸＹＺ”という情報が記録されている。これは、機能Ｆ３を実行した際に、パラメタＰ１の設定値が“ＸＹＺ”であったことを示す。
【００７９】
また、例えば、ログ１１３の３行目には、“機能Ｆ３，ディスク使用率，７０％”という情報が記録されている。これは、機能Ｆ３を実行した際に、サーバ１００のＨＤＤ１０３の使用率が７０％であったことを示す。
【００８０】
ログ１１３の４行目以降にも、各機能の実行時における環境情報が同様に記録されている。
図９は、バグ識別結果テーブルの例を示す図である。バグ識別結果テーブル１１４は、記憶部１１０に記憶される。バグ識別結果テーブル１１４は、ログ１１３に基づいて、判定部１４０により生成される。バグ識別結果テーブル１１４は、修正番号、修正要否、機能名、環境情報および測定値の項目を含む。
【００８１】
修正番号の項目には、修正番号が登録される。修正要否の項目には、修正の要否の判定結果を示す情報が登録される。機能名の項目には、修正番号に対してログの取得対象とした機能名が登録される。環境情報の項目には、当該ログの取得対象とした環境情報の名称が登録される。測定値の項目には、ログに記録された環境情報の測定値（修正要否の判断に用いられた値）が登録される。
【００８２】
例えば、バグ識別結果テーブル１１４には、修正番号が“ＢＵＧ００１”、修正要否が“必要”、機能名が“機能Ｆ１”、環境情報が“ファイル数”、測定値が“９００”という情報が登録される。これは、修正番号“ＢＵＧ００１”について、サーバ１００での修正が必要であることを示す。また、機能Ｆ１の実行時に、処理対象のファイル数が９００個であったというログが記録されていることを示す。
【００８３】
また、バグ識別結果テーブル１１４には、修正番号“ＢＵＧ００１”に対応付けて、機能名が“機能Ｆ３”、環境情報が“ディスク使用率”、測定値が“７５％”という情報が登録される。同様に、バグ識別結果テーブル１１４には、修正番号“ＢＵＧ００１”に対応付けて、機能名が“機能Ｆ３”、環境情報が“パラメタＰ１”、測定値が“ＡＢＣ”という情報が登録される。
【００８４】
更に、バグ識別結果テーブル１１４には、修正番号“ＢＵＧ００２”、修正要否が“不要”、機能名が“機能Ｆ４”、環境情報が“ＣＰＵ使用率”、測定値が“２０％”という情報が登録される。これは、修正番号“ＢＵＧ００２”について、サーバ１００での修正が不要であることを示す。また、機能Ｆ４の実行時に、ＣＰＵ使用率が２０％であったというログが記録されていることを示す。
【００８５】
次に、第２の実施の形態の各サーバによる修正適用の判断手順を説明する。
図１０は、修正適用の判断例を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
【００８６】
（Ｓ１）ログ生成部１３０は、複数のバグレポートを管理サーバ２００から取得し、記憶部１１０に格納する。複数のバグレポートは、修正番号“ＢＵＧ００１”に関するバグレポート１１１を含む。複数のバグレポートは、修正番号“ＢＵＧ００２”に関するバグレポートを含む。例えば、ログ生成部１３０は、管理サーバ２００から、バグレポートを定期的に（例えば、日次、週次、月次などで）取得することが考えられる。
【００８７】
（Ｓ２）ログ生成部１３０は、複数のバグレポートそれぞれに含まれる修正適用識別情報を参照して、ログ採取管理テーブル１１２を生成する。例えば、ログ生成部１３０は、バグレポート１１１に含まれる修正適用識別情報１１１ａに基づいて、ログ採取管理テーブル１１２における修正番号“ＢＵＧ００１”のエントリを生成する。同様に、ログ生成部１３０は、修正番号“ＢＵＧ００２”のバグレポートに含まれる修正適用情報に基づいて、ログ採取管理テーブル１１２における修正番号“ＢＵＧ００２”のエントリを生成する。採取状況のデフォルト値は、例えば“ＯＦＦ”である。ログ生成部１３０は、予め定められた基準（例えば、エントリ生成日以降の１日、１週間、１カ月間などを採取期間とするなど）に応じて採取期間を決定する。ただし、ログ生成部１３０は、管理サーバ２００から採取期間の情報を取得したり、採取期間の情報のユーザによる指定を受け付けたりしてもよい。
【００８８】
（Ｓ３）ログ生成部１３０は、ログ採取管理テーブル１１２のエントリのうちログ採取対象の環境情報のエントリに対して、採取状況“ＯＮ”を設定する。現時刻が採取期間に含まれているエントリがログ採取対象の環境情報のエントリとなる。ログ生成部１３０は、ログ採取管理テーブル１１２に基づくログ１１３の出力を開始する。ログ生成部１３０は、ログ採取管理テーブル１１２に設定された機能の実行に応じて、該当機能の実行時における環境情報をログ１１３に記録する。
【００８９】
（Ｓ４）判定部１４０は、ログ採取管理テーブル１１２およびログ１１３を参照して、何れかの修正番号の条件が充足されたか否かを判定する。何れかの修正番号の条件が充足された場合、処理をステップＳ５に進める。充足されていない場合、処理をステップＳ９に進める。例えば、ログ採取管理テーブル１１２によれば、修正番号“ＢＵＧ００１”の条件は次の（１）〜（３）の３つである。（１）機能Ｆ１実行時の機能Ｆ１による処理対象のファイル数が８００個以上である。（２）機能Ｆ３実行時のサーバ１００におけるディスク使用率が７０％以上である。（３）機能Ｆ３実行時の機能Ｆ３の処理に用いられるパラメタＰ１の値がＡＢＣである。判定部１４０は、ログ１１３を参照して、（１）〜（３）を全て満たす情報が記録されていれば、修正番号“ＢＵＧ００１”の条件が充足されたと判定する。同じ機能の同じ環境情報に対して複数回分の測定値がログ１１３に記録されていることもある。その場合、複数回の何れかの測定値が（１）〜（３）などの条件を満たしていればよい。一方、判定部１４０は、（１）〜（３）の何れかを満たす情報がログ１１３に記録されていなければ、修正番号“ＢＵＧ００１”の条件が充足されていないと判定する。判定部１４０は、他の修正番号についても同様に判定する。
【００９０】
（Ｓ５）判定部１４０は、ステップＳ４で条件を充足したと判定された修正番号（バグ）について、修正要否を“必要”として、バグ識別結果テーブル１１４に設定する。また、修正要否を“必要”と判断したときに参照したログ内容（機能名、環境情報および測定値）も、当該修正番号に対応付けて、バグ識別結果テーブル１１４に設定する。例えば、ある機能について、ある環境情報が複数回記録され、（１）〜（３）の何れかの条件が複数回充足されていることもある。その場合、複数回の測定値のうち、条件を満たした最新の測定値、または、条件を満たした測定値のうち、閾値との差が最も大きな測定値を、バグ識別結果テーブル１１４に記録することが考えられる。
【００９１】
（Ｓ６）判定部１４０は、新たに修正要否を“必要”（すなわち、修正要）と判断した修正番号（バグ）およびサーバ１００の識別情報を管理サーバ２００に通知する。
（Ｓ７）ログ生成部１３０は、新たに修正要と判断した修正番号（バグ）に関するログ出力を停止する。具体的には、ログ生成部１３０は、ログ採取管理テーブル１１２のエントリのうちログ採取非対象とする環境情報のエントリに対して、採取状況“ＯＦＦ”を設定する。
【００９２】
（Ｓ８）ログ生成部１３０は、ログ採取管理テーブル１１２に登録された全ての修正番号に対するログ出力が停止（すなわち、全エントリの採取状況が“ＯＦＦ”）になったか否かを判定する。全ての修正番号に対するログ出力が停止となった場合、処理を終了する。全ての修正番号に対するログ出力が停止となっていない場合、処理をステップＳ３に進める（ログ出力を継続する）。
【００９３】
（Ｓ９）判定部１４０は、ログ採取管理テーブル１１２を参照して、採取状況“ＯＮ”の修正番号のうち、ログ採取期間が満了した修正番号があるか否かを判定する。ログ採取期間が満了した修正番号がある場合、処理をステップＳ１０に進める。ログ採取期間が満了した修正番号がない場合、処理をステップＳ３に進める。
【００９４】
（Ｓ１０）判定部１４０は、ログ採取期間が満了した修正番号に関するバグの修正要否を“不要”として、バグ識別結果テーブル１１４に設定する。また、修正要否を“不要”と判断したときに参照したログ内容（機能名、環境情報および測定値）も、当該修正番号に対応付けて、バグ識別結果テーブル１１４に設定する。例えば、判定部１４０は、設定するログ内容の候補が複数ある場合は、最新のログ内容、または、比較した閾値との差が最も小さい測定値であるログ内容を、バグ識別結果テーブル１１４に設定することが考えられる。
【００９５】
（Ｓ１１）判定部１４０は、新たに修正要否を“不要”（すなわち、修正不要）と判断した修正番号（バグ）およびサーバ１００の識別情報を管理サーバ２００に通知する。
（Ｓ１２）ログ生成部１３０は、新たに修正不要と判断した修正番号（バグ）に関するログ出力を停止する。具体的な処理方法は、ステップＳ７と同様である。そして、処理をステップＳ８に進める。
【００９６】
このように、サーバ１００は、ログとして取得した環境情報が、バグレポートで示される条件を満たすか否かの判定に応じて、バグレポートで示されるバグに対する修正を適用するか否かを決定する。
【００９７】
なお、ステップＳ６またはステップＳ１１の通知により、管理部２２０は、修正番号および修正要否の情報をサーバ１００から取得する。管理部２２０は、サーバ１００に対応付けて、通知された修正番号に対する修正を行うか否かの情報を生成し、記憶部２１０に格納する。管理部２２０は、サーバ１００ａ，１００ｂについても同様にして、修正番号と修正要否の情報とを管理する。管理部２２０は、記憶部２１０に記憶された情報を参照して、修正番号とサーバごとの修正要否の情報とを、情報処理システムの管理者に通知できる。
【００９８】
図１１は、ログの記録例を示す図である。ソフトウェア１２１は、機能Ｆ１，Ｆ２を有する。ソフトウェア１２２は、機能Ｆ３を有する。ソフトウェア１２３は、機能Ｆ４を有する。ログ生成部１３０は、ログ採取管理テーブル１１２に基づいて、各機能実行時の環境情報をログ１１３に記録する。
【００９９】
ログ採取管理テーブル１１２には、機能Ｆ１，Ｆ３，Ｆ４に対してログの取得対象とする環境情報が登録されている。一方、ログ採取管理テーブル１１２には、機能Ｆ２に対してログの取得対象とする環境情報が登録されていない。
【０１００】
例えば、サーバ１００において、機能Ｆ１が実行されたとする。ログ生成部１３０は、サーバ１００で実行されるプログラムの関数名、コマンド名およびプロセス名などから、機能Ｆ１に対応する名称を検出することで、機能Ｆ１の実行を検出する。すると、ログ生成部１３０は、ログ採取管理テーブル１１２に基づいて、機能Ｆ１の処理対象となったファイル数の測定値をログ１１３に記録する。
【０１０１】
ログ生成部１３０は、機能Ｆ３の実行を検出すると、ログ採取管理テーブル１１２に基づいて、機能Ｆ３実行時のディスク使用率の測定値をログ１１３に記録する。更に、ログ生成部１３０は、機能Ｆ４の実行を検出すると、ログ採取管理テーブル１１２に基づいて、機能Ｆ４実行時のＣＰＵ使用率の測定値をログ１１３に記録する。
【０１０２】
ログ採取管理テーブル１１２は、機能Ｆ２に対するエントリを含んでいない。このため、ログ生成部１３０は、機能Ｆ２が実行されたとしても、機能Ｆ２に関するログ生成を行わない。
【０１０３】
判定部１４０は、ログ１１３に何れかの情報が記録されると、ログ１１３に記録された内容とログ採取管理テーブル１１２に登録された環境情報ごとの条件値とを比較することで、修正番号ごとの修正適用の要否を判定する。このとき、例えば、判定部１４０は、ソフトウェア１２１のバグに対応する修正番号に対して、ソフトウェア１２１とは異なるソフトウェア１２２の機能Ｆ３に関する環境情報を取得することもできる。このため、サーバ１００は、例えば、バグの発見されているソフトウェア１２１の連携先のソフトウェア１２２の機能に関する環境情報も考慮して、修正適用の要否を判断できる。すなわち、サーバ１００は、実際の利用環境に即した適切な判断を行える。
【０１０４】
なお、第２の実施の形態の例では、ログ生成部１３０が、各ソフトウェアにおける機能の実行状況を監視するものとした。ただし、ログ生成部１３０は、各ソフトウェアにおける機能の実行時に、当該機能により呼び出されてもよい。
【０１０５】
ここで、例えば、各サーバにおいて、利用しているソフトウェアに対する全ての修正（全ての機能に対する修正）を、適用することも考えられる。しかし、利用しているソフトウェアに対して全ての修正を適用していると、現在の利用環境下では起こり得ないような障害に関する余計な修正も適用される可能性がある。余計な修正適用を行っていると、リグレッションや適用失敗などのリスクを却って助長しかねない。例えば、大規模システムでは、多数のミドルウェアが利用され得る。このため、監視対象となる障害の種類も多く、修正を適用することでシステムの動作が変更され、障害が発生する可能性も高い。
【０１０６】
システム障害は、システムを利用するユーザの業務に多大な影響を与えるおそれがある。修正適用の前に、テスト環境などを用いて受け入れテストを行い、修正適用後に障害が発生しないことを事前に確認することも考えられる。しかし、受け入れテストは時間がかかり、あらゆる修正に対して受け入れテストを行うことは困難である。
【０１０７】
また、システムの管理者や保守員などが、人手で、自システムで対策すべき修正の選別を行うことも考えられる。しかし、障害の選別には、アプリケーションやミドルウェアの高度な専門知識が必要になり、障害の選別を人手で行うとすると、その作業には多大な時間を要する。当該作業を行う人材の確保も容易でない。修正の適用が遅れると、修正を適用していない潜在的なリスクを抱えた状態の運用を強いられることになる。
【０１０８】
そこで、多数の障害から自システムで対策すべき障害の有無を効率的に識別する仕組みが求められる。例えば、自システムで対策すべき障害の識別に当たり、バグの発見されている機能の使用状況を把握するためにログやトレースの情報を取得することが考えられる。しかし、取得されるログやトレースの情報は膨大になり得るため、取得された情報を分析することは容易ではない。
【０１０９】
これに対し、第２の実施の形態のサーバ１００は、バグレポートに基づいて、ソフトウェアの機能ごとに、ログとして取得する環境情報を絞り込む。このため、あらゆるログを取得する場合に比べて、ログ取得に伴う負荷を軽減できる。
【０１１０】
そして、サーバ１００は、取得した環境情報がバグレポートで示される条件を充足するか否かの判定に応じて、修正の適用要否を決定する。バグレポートは、実際の運用でのバグによる障害の発生条件を集約した情報である。このため、サーバ１００は、適用対象とする修正を、情報処理システムの現在の利用環境下において障害を引き起こす可能性の高いバグに関するものに限定できる。すなわち、サーバ１００は、現在の利用環境下において障害を引き起こす可能性の低いバグに関する修正の適用を行わないよう判断できる。このように、必要な修正のみ適用すると決定でき、情報処理システムの効率的な保守を支援できる。
【０１１１】
サーバ１００，１００ａ，１００ｂは、第１の実施の形態の情報処理装置１の一例と考えることができる。ただし、判定部１４０の機能を管理サーバ２００に設けることもできる。その場合、管理サーバ２００は、サーバ１００，１００ａ，１００ｂにより生成されたログを収集し、各サーバに対応付けて記憶部２１０に格納する。管理サーバ２００は、記憶部２１０に記憶されたバグレポートと各サーバから取得したログとに基づいて、判定部１４０と同様に、サーバ１００，１００ａ，１００ｂそれぞれにおけるソフトウェア毎の修正適用の判断を行える。このように、判定部１４０の機能を管理サーバ２００によって実現するならば、管理サーバ２００を第１の実施の形態の情報処理装置１の一例と考えることもできる。
【０１１２】
なお、第１の実施の形態の情報処理は、演算部１ｂとして用いられるプロセッサにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。
【０１１３】
例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【０１１４】
以上の第１，第２の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１）  コンピュータに、
１または複数のソフトウェアの複数の機能それぞれを実行した際の、前記コンピュータの動作状況を示す環境情報を機能ごとに取得し、
取得した前記機能ごとの環境情報が、バグレポートの情報に含まれる前記機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、
処理を実行させる修正適用判断プログラム。
【０１１５】
（付記２）  前記バグレポートは、バグに起因する障害の発生条件を示す情報を含み、
前記障害の発生条件に基づいて前記機能ごとの環境情報の条件を生成する、
付記１記載の修正適用判断プログラム。
【０１１６】
（付記３）  前記生成では、前記障害の発生条件よりも緩い条件を生成する、付記２記載の修正適用判断プログラム。
（付記４）  前記取得では、前記バグレポートの情報に含まれる前記機能ごとの環境情報に応じて、取得対象の環境情報を絞り込む、付記１乃至３の何れか１つに記載の修正適用判断プログラム。
【０１１７】
（付記５）  前記決定では、何れかのソフトウェアに対する修正の適用要否を決定すると、当該修正の適用の判定に用いられた前記機能ごとの環境情報の取得を停止する、付記１乃至４記載の修正適用判断プログラム。
【０１１８】
（付記６）  前記決定では、前記機能ごとの環境情報の取得を所定期間行っても、前記バグレポートの情報に含まれる条件が満たされない場合、当該条件に対応する修正の適用を不要と決定する、付記１乃至５の何れか１つに記載の修正適用判断プログラム。
【０１１９】
（付記７）  前記決定では、第１のソフトウェアの機能を実行した際に取得した環境情報に基づいて、第２のソフトウェアに対する修正の適用要否を決定する、付記１乃至６の何れか１つに記載の修正適用判断プログラム。
【０１２０】
（付記８）  バグレポートの情報を記憶する記憶部と、
１または複数のソフトウェアの複数の機能それぞれを実行した際の、自装置の動作状況を示す環境情報を機能ごとに取得し、
取得した前記機能ごとの環境情報が、前記バグレポートの情報に含まれる前記機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、演算部と、
を有する情報処理装置。
【０１２１】
（付記９）  コンピュータが、
１または複数のソフトウェアの複数の機能それぞれを実行した際の、前記コンピュータの動作状況を示す環境情報を機能ごとに取得し、
取得した前記機能ごとの環境情報が、バグレポートの情報に含まれる前記機能ごとの環境情報の条件を満たすか否かの判定に応じて、何れかのソフトウェアに対する修正の適用要否を決定する、
修正適用判断方法。
【符号の説明】
【０１２２】
１  情報処理装置
１ａ  記憶部
１ｂ  演算部
２  バグレポート
３  ログ
【図１】
2016015021.tif 000003
【図２】
2016015021.tif 000004
【図３】
2016015021.tif 000005
【図４】
2016015021.tif 000006
【図５】
2016015021.tif 000007
【図６】
2016015021.tif 000008
【図７】
2016015021.tif 000009
【図８】
2016015021.tif 000010
【図９】
2016015021.tif 000011
【図１０】
2016015021.tif 000012
【図１１】
2016015021.tif 000013