"第1の情報処理装置で実行される複数のプログラムを含む情報処理システムを、前記第1の情報処理装置とは異なる基盤の第2の情報処理装置に移行する際の品質を評価する移行品質評価システムであって、前記情報処理システムに含まれるサブシステムごとの実行可能なパス数に応じた情報であるパス情報を記憶するパス情報記憶部と、システム移行時における、パス数とバグ数との関係を示すバグ指標を記憶するバグ指標記憶部と、前記第2の情報処理装置において検出された、前記サブシステムごとのバグ数を記憶する検出バグ数記憶部と、前記パス情報及び前記バグ指標に基づいて、前記第2の情報処理装置で発生し得る、前記サブシステムごとのバグ数を予測するバグ数予測部と、前記検出されたバグ数と前記予測されたバグ数とに基づいて、前記サブシステムごとの移行品質を示す品質評価情報を出力する品質評価部と、を備える移行品質評価システム。請求項1に記載の移行品質評価システムであって、前記サブシステムごとの実行可能なパス数に応じた情報であるパス情報を記憶するパス情報記憶部と、前記第2の情報処理装置において実行された、前記サブシステムごとのパス数に応じた情報である実行パス情報を記憶する実行パス情報記憶部と、前記パス情報及び前記実行パス情報に基づいて、前記サブシステムごとのカバレッジを算出するカバレッジ算出部と、をさらに備え、前記品質評価部は、前記サブシステムごとのカバレッジを前記品質評価情報に含めて出力する、移行品質評価システム。請求項2に記載の移行品質評価システムであって、前記品質評価部は、前記検出されたバグ数と前記予測されたバグ数との関係と、前記カバレッジとを前記サブシステムごとに対応づけて、前記品質評価情報として所定の表示装置上に表示する、移行品質評価システム。このようなリホストによる移行では、プログラム言語やプログラム内の構造が変更されないため、通常のシステム開発時のようなプログラム単位での詳細なテストは実行されず、システム全体の動作を確認するテストのみが実行されることが多い。例えば、移行前の基盤で実行される情報処理システム以後、旧システムと言うに対する入力データを、移行先の基盤で実行される情報処理システム以後、新システムと言うに対しても入力し、旧システム及び新システムの出力結果を比較することにより、移行が正常に行われていることを確認するコンペアテストが一般的に用いられている。しかしながら、コンペアテストにおける入力データは、例えば、旧システムの本番運用において実際に発生したデータを用いる場合が多く、システムを構成するプログラムのあらゆるパスを考慮したテストが実行されるわけではない。そのため、コンペアテストの結果だけでは、システム移行時の品質を見極めることは非常に難しい。また、コンペアテストの入力データとして、プログラムのあらゆるパスを考慮した入力データを本番データ以外に作成することも理論的には可能であるが、システム移行時のコストが増大してしまうこととなるため現実的ではない。本発明はこのような事情に鑑みてなされたものであり、システム移行時の品質評価の精度を高めることを目的とする。本発明の一側面に係る移行品質評価システムは、第1の情報処理装置で実行される複数のプログラムを含む情報処理システムを、第1の情報処理装置とは異なる基盤の第2の情報処理装置に移行する際の品質を評価する移行品質評価システムであって、情報処理システムに含まれるサブシステムごとの実行可能なパス数に応じた情報であるパス情報を記憶するパス情報記憶部と、システム移行時における、パス数とバグ数との関係を示すバグ指標を記憶するバグ指標記憶部と、第2の情報処理装置において検出された、サブシステムごとのバグ数を記憶する検出バグ数記憶部と、パス情報及びバグ指標に基づいて、第2の情報処理装置で発生し得る、サブシステムごとのバグ数を予測するバグ数予測部と、検出されたバグ数と予測されたバグ数とに基づいて、サブシステムごとの移行品質を示す品質評価情報を出力する品質評価部と、を備える。なお、本発明において、部とは、単に物理的手段を意味するものではなく、その部が有する機能をソフトウェアによって実現する場合も含む。また、1つの部や装置が有する機能が2つ以上の物理的手段や装置により実現されても、2つ以上の部や装置の機能が1つの物理的手段や装置により実現されても良い。本発明によれば、システム移行時の品質評価の精度を高めることが可能となる。以下、図面を参照して本発明の一実施形態について説明する。図1は、本発明の一実施形態である移行品質評価システムの構成を示す図である。移行品質評価システム10は、システム移行時の品質を評価するための情報処理システムであり、1台または複数台の情報処理装置を用いて構成される。本実施形態では、ホスト20で稼動しているシステムをサーバ22に移行する際の品質を評価することとする。ホスト20は、例えばメインフレームなどの大型汎用コンピュータであり、プログラムやジョブの実行環境を備えている。また、サーバ22は、例えばUNIX登録商標やLinux登録商標などのOSが用いられるオープン系のサーバであり、プログラムやジョブの実行環境を備えている。移行サーバ24は、ホスト20で稼動しているシステム以後、旧システムと言うをサーバ22のシステム以後、新システムと言うに移行するために、プログラムやジョブ、データの変換などを行う情報処理装置である。図1に示すように、移行品質評価システム10は、カバレッジ算出部30、バグ数予測部32、品質評価部34、複雑度記憶部40、実行パス情報記憶部42、カバレッジ記憶部44、バグ指標記憶部46、及び検出バグ数記憶部48を含んで構成される。なお、移行品質評価システム10を構成する各部は、例えば、メモリや記憶装置等の記憶領域を用いたり、メモリに格納されたプログラムをプロセッサが実行したりすることにより実現することができる。移行品質評価システム10を構成する各部の詳細については後述する。まず、移行サーバ24の構成について説明する。図2は、移行サーバ24の構成例を示す図である。移行サーバ24は、変換部60、複雑度算出部62、複雑度集計部64、ライブラリ情報記憶部66、及び複雑度記憶部68を含んで構成される。なお、移行サーバ24の各部は、例えば、メモリや記憶装置等の記憶領域を用いたり、メモリに格納されたプログラムをプロセッサが実行したりすることにより実現することができる。変換部60は、ホスト20用のプログラムやジョブ、データをサーバ22用に変換する機能を有している。例えば、変換部60は、ホスト20で実行されるCOBOLプログラムのソースコードの文字コードをサーバ22用に変換し、さらに、ソースコードに含まれる、ホスト20の基盤に依存する部分をサーバ22の基盤に応じたコードに変換する。なお、サーバ22用に変換されたソースコードは、サーバ22用のコンパイラで実行形式に変換され、サーバ22に転送される。同様に、変換部60は、ホスト20においてジョブを制御するためのJCLJobControlLanguageや、ホスト20で用いられるデータについても、文字コードや形式をサーバ22用に変換する。なお、本実施形態では、プログラムのソースコードは基盤に依存する部分のみが変更され、プログラム言語そのものや、プログラムのロジック自体は変更されないこととする。このようにプログラムの主要部を変更せずに移行する方式はリホストと呼ばれる。また、変換部60は、プログラムにおいて実行されたパスを検証可能とするためのコードを追加する。例えば、変換部60は、プログラム中の分岐条件ごとに、該条件が満たされた場合に所定のデータを出力するコードを追加することができる。複雑度算出部62は、プログラムごとの複雑度を算出する。ここで、複雑度とは、プログラム中の実行可能なパス数に応じた情報であり、パス数が多くなるほど複雑度は高くなる。本実施形態では、プログラムのパス数を複雑度として用いることとする。複雑度集計部64は、ライブラリ情報記憶部66に格納されているライブラリ情報に基づいて、プログラムごとの複雑度をサブシステム単位に集計し、複雑度記憶部68に格納する。ここで、サブシステムとは、移行対象となっているシステムを機能単位に分割したものである。図3は、ライブラリ情報記憶部66の構造の一例を示している。図3に示すように、ライブラリ情報記憶部66には、サブシステムのコードとプログラムのコードとが対応付けて記憶されている。例えば、XXAB010やXXAB020のプログラムは、サブシステムABに属するものであることがわかる。図4は、複雑度記憶部68の構造の一例を示している。図4に示すように、複雑度記憶部68には、サブシステムのコードと複雑度とが対応付けて記憶されている。次に、ホスト20とサーバ22での並行運用テストコンペアテストについて説明する。図5は、並行運用テストの一例を示す図である。図5に示すように、ホスト20は、処理部70及び転送部72,74を含んでいる。ホスト70を構成する各部は、例えば、メモリや記憶装置等の記憶領域を用いたり、メモリに格納されたプログラムをプロセッサが実行したりすることにより実現することができる。処理部70は、旧システムのプログラムやジョブの実行部であり、入力データに対して処理を実行し、出力データを出力する。なお、入力データは、例えば、旧システムの本番運用で発生するデータを用いることができる。転送部72,74は、それぞれ、入力データ及び出力データをサーバ22に転送する。サーバ22は、変換部80,82、処理部84、比較部86、比較結果記憶部88、集計部90、及び実行パス情報記憶部92を含んでいる。サーバ22を構成する各部は、例えば、メモリや記憶装置等の記憶領域を用いたり、メモリに格納されたプログラムをプロセッサが実行したりすることにより実現することができる。変換部80,82は、それぞれ、ホスト20から転送されてくる入力データ及び出力データをサーバ22用に変換する。処理部84は、移行サーバ24によって変換された、新システムのプログラムやジョブの実行部であり、入力データに対して処理を実行し、出力データを出力する。また、前述したように、新システム用のプログラムには、実行されたパスを検証するためのコードが埋め込まれており、処理部84は、実行パスを示す実行パスデータを出力する。比較部86は、ホスト20から転送された出力データと、サーバ22において生成された出力データとを例えばファイル単位で比較し、比較結果を比較結果記憶部88に格納する。ここで、比較結果が不一致となった場合には、移行が正常に行われていないことが考えられる。そのため、並行運用テストの実施者は、比較結果が不一致となった原因を突き止め、例えば、移行サーバ24の変換部60における変換規則の修正など、比較結果を一致させるための対処を施す。集計部90は、プログラムごとの実行パスデータと、ライブラリ情報とに基づいて、サブシステムごとに実行パス数を集計し、実行パス情報記憶部92に格納する。なお、ライブラリ情報は、図3に示したライブラリ情報と同等のものである。図6は、実行パス情報記憶部92の構造の一例を示している。図6に示すように、実行パス情報記憶部92には、サブシステムのコードと実行パス数とが対応付けて記憶されている。次に、図1及び図7~図13を参照し、移行品質評価システム10を構成する各部の詳細について説明する。カバレッジ算出部30は、新システムにおける、サブシステムごとのカバレッジを算出し、カバレッジ記憶部44に格納する。具体的には、図7に示すように、カバレッジ算出部30は、サブシステムごとの複雑度パス数と、サブシステムごとの実行パス数とに基づいて、サブシステムごとのカバレッジを算出する。なお、サブシステムごとの複雑度は、図4に示した複雑度と同等のものであり、複雑度記憶部40に記憶されている。また、サブシステムごとの実行パス数は、図6に示した実行パス情報と同等のものであり、実行パス情報記憶部42に記憶されている。図8は、カバレッジ記憶部44の構造の一例を示している。図8に示すように、カバレッジ記憶部44には、サブシステムのコードとカバレッジとが対応付けて記憶されている。なお、サブシステムごとのカバレッジは、例えば、サブシステムごとの複雑度パス数に対するサブシステムごとの実行パス数の割合として算出することができる。図1に戻り、バグ数予測部32は、並行運用テストにおいてサーバ22で発生し得るバグ数をサブシステムごとに予測する。具体的には、図7に示すように、バグ数予測部32は、システム移行時における複雑度パス数とバグ数との関係を示すバグ指標を考慮することにより、移行対象のサブシステムの複雑度に応じたバグ数を予測する。ここで、バグ指標とは、例えば、以前に移行されたシステムにおける、複雑度と検出バグ数との関係を示すものであり、バグ指標記憶部46に記憶されている。図9は、バグ指標記憶部46の構造の一例を示している。図9に示すように、バグ指標記憶部46には、以前に移行されたシステムにおけるサブシステムごとに、複雑度と、並行運用テストで検出されたバグ数とが対応づけて記憶されている。また、図10には、複雑度を横軸、バグ数を縦軸としてバグ指標が示されている。バグ数予測部32は、バグ指標記憶部46に記憶されているバグ指標に基づいて、バグを予測するための関係式を導出する。例えば、バグ数予測部32は、サブシステムごとの複雑度とバグ数との関係を示す線形近似曲線である中心線を導出する。図10に示すように、複雑度が高くなるにつれてバグ数が増加する傾向にあることがわかる。バグ数予測部32は、このような複雑度とバグ数との関係に基づいて、移行対象システムにおけるサブシステムごとのバグ数を予測する。具体的には、バグ数予測部32は、各サブシステムの複雑度を中心線の関係式にあてはめることにより、サブシステムごとの予測バグ数を算出する。なお、線形近似曲線は一例であり、複雑度とバグ数との関係式の導出には任意の手法を用いることができる。さらに、バグ数予測部32は、指標となるシステムにおけるサブシステムごとの複雑度を中心線の関係式に代入することにより得られるシステム全体での予測バグ数と、該システムにおいて実際に検出されたバグ数とを比較することにより、関係式を補正することも可能である。例えば、予測バグ数が実際に発生したバグ数よりも10少ない場合であれば、算出されるバグ数が10減少するように関係式を補正することとしてもよい。また、バグ数予測部32は、図10に示すように、中心線に対してバグ数を上方に例えば20増加させた上方管理限界と、中心線に対してバグ数を下方に例えば20減少させた下方管理限界とを導出する。上方管理限界から下方管理限界の間のバグ数が、複雑度に応じた適正なバグ数としての一つの目安となる。なお、バグ数予測部32により予測されたバグ数を、サブシステムコードと対応付けて予測バグ数記憶部に格納しておくことも可能である。この場合、例えば、上方管理限界から下方管理限界など、ある範囲の幅を有する予測バグ数を記憶しておくこととしてもよい。図1に戻り、品質評価部34は、バグ数予測部32により予測されたサブシステムごとの予測バグ数と、並行運用テストにおいて実際に検出されたサブシステムごとのバグ数と、サブシステムごとのカバレッジとに基づいて、サブシステムごとの移行品質を示す品質評価情報を出力する。なお、検出されたバグ数は、テスト実施者によってサブシステムごとに集計され、検出バグ数記憶部48に格納されていることとする。図11は、検出バグ数記憶部48の構造の一例を示している。図11に示すように、サブシステムコードと、検出バグ数とが対応付けて記憶されている。図12は、品質評価部34における品質評価の分類の一例を示す図である。図12に示すように、品質評価部34は、カバレッジとバグ数との関係に基づいてサブシステムごとの品質を評価することができる。図12の例では、カバレッジは、30及び50を境界として3つのグループに分類され、バグ数は、下方管理限界及び上方管理限界を境界として3つのグループに分類されている。これにより、全体でC1~C9の9つのグループに分類されている。なお、分類の基準値やグループの数は一例にすぎない。そして、品質評価部34は、例えば、図13に示すように、各サブシステムのカバレッジと検出バグ数との関係を示す品質評価情報を出力する。なお、品質評価情報の出力は、ディスプレイ等に表示することにより行われてもよいし、帳票等に印刷されることにより行われてもよい。また、品質評価情報は、CSVConmaSeparatedValues形式等、他の情報処理装置での加工が容易な形式で出力されることとしてもよい。例えば、図13の例では、サブシステムABはグループC6にプロットされている。ここで、グループC6は、カバレッジが50以上であり、バグ数が上方管理限界と下方管理限界との間にあるグループである。この場合、サブシステムABの移行品質は高いと推定することができる。また、サブシステムCDはグループC7にプロットされている。ここで、グループC7は、カバレッジが30未満であり、バグ数が下方管理限界未満のグループである。この場合、テスト実施者は、例えば、サブシステムC7における未カバレッジ実行されていないパスの調査を行い、未カバレッジ部分を実行するための追加テストを実行することにより、移行品質を高めることができる。また、サブシステムEFはグループC3にプロットされている。ここで、グループC3は、カバレッジが50以上であり、バグ数が上方管理限界以上のグループである。この場合、カバレッジは高いもののバグ数が多いため、品質に問題がある可能性がある。そこで、テスト実施者は、例えば、バグの発生傾向を分析して妥当性を検証することにより、移行品質を高めることができる。このように、カバレッジと検出バグ数とに基づいて、サブシステムごとの移行品質を評価することができる。そして、移行品質が低いと推定されるサブシステムを抽出して追加テストを実施することにより、システム全体での移行品質を高めることが可能となる。図14は、移行品質評価システム10における処理の流れの一例を示すフローチャートである。まず、カバレッジ算出部30は、複雑度記憶部40に記憶されている複雑度と、実行パス情報記憶部42に記憶されている実行パス情報とに基づいて、サブシステムごとのカバレッジを算出し、カバレッジ記憶部44に格納するS1401。また、バグ数予測部32は、複雑度記憶部40に記憶されている複雑度と、バグ指標記憶部46に記憶されているバグ指標とに基づいて、サブシステムごとの予測バグ数を算出するS1402。そして、品質評価部34は、カバレッジ記憶部44に格納されているカバレッジ、算出された予測バグ数、及び検出バグ数記憶部48に格納されている検出バグ数に基づいて、サブシステムごとの移行品質を評価し、品質評価情報を出力するS1403。また、品質評価部34は、移行品質の評価結果である品質評価情報を、例えば図13に示したように画面や帳票上に出力するS1404。以上、本実施形態の移行品質評価システム10について説明した。本実施形態によれば、例えば他システムの移行実績に基づくバグ指標を用いることにより、移行対象システムにおけるサブシステムごとの予測バグ数が算出される。そして、予測バグ数を検出バグ数と比較することにより、サブシステムごとの移行品質を評価することができる。これにより、単にコンペアテストの結果だけで移行品質を評価する場合と比較して、移行品質の評価精度を高くすることができる。そして、移行品質が低いと推定されるサブシステムについては、個別に追加テストを実施することなどにより、移行品質を高めることが可能となる。つまり、移行コストを抑制可能であるリホストの特性を活かしたうえで、システム全体の移行品質を向上させることが可能となる。また、本実施形態によれば、例えば図13に示したように、カバレッジと検出バグ数との関係により、サブシステムごとの移行品質を評価することができる。これにより、移行品質の評価精度をさらに高めることが可能となる。なお、本実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更/改良され得るととともに、本発明にはその等価物も含まれる。例えば、本実施形態では、ホストからサーバにシステムが移行されることとしたが、旧システム及び新システムの基盤はこれに限られない。例えば、サーバで運用されているシステムを、ミドルウェアやデータベースなどが異なる別のサーバに移行する場合にも、本実施形態と同様の評価手法を適用することができる。また、例えば、複雑度記憶部40や実行パス情報記憶部42、カバレッジ記憶部44、検出バグ数記憶部48などに記憶される情報は、サブシステム単位に集計されたものではなく、プログラム単位のものであってもよい。この場合、例えば、プログラムとサブシステムとの対応関係を示すライブラリ情報に基づいて、各種情報をサブシステム単位に集計することが可能である。また、例えば、移行品質評価システム10内の一部は、サーバ22や移行サーバ24内に設けられることとしてもよい。同様に、移行サーバ24内の一部は、サーバ22内に設けられることとしてもよい。また、本実施形態では、並行運用テストにおける比較処理はサーバ22で行われることとしたが、ホスト20やその他の情報処理装置において行われることとしてもよい。また、本実施形態では、プログラム言語を変更することなく移行するリホストを前提として説明したが、ロジックは変更せずにプログラム言語を変更するリライトにおいて、本実施形態と同様の評価手法を適用することも可能である。また、本実施形態では、過去に移行された1つのシステムにおけるサブシステムごとの複雑度と検出バグ数とをバグ指標として用いることとしたが、複数のシステムの移行実績に基づいて算出されるバグ指標が用いられることとしてもよい。このように、複数のシステムの移行実績に基づいてバグ指標を更新することにより、バグ数の予測精度を高めることが可能となる。"