"ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部とを含むソフトウェアの検査種別判定装置。前記記憶部は、前記担当者が開発したソフトウェアに係る障害が発生した場合に、該障害の規模に応じた障害判定ポイントをさらに格納し、前記決定部は、前記記憶部に前記担当者の前記障害判定ポイントが格納されている場合には、少なくとも前記開発内容ポイント、前記担当者判定ポイント及び前記障害判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する請求項1に記載のソフトウェアの検査種別判定装置。前記記憶部は、前記担当者の開発に係るブランクに応じたブランク判定ポイントをさらに格納し、前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記ブランク判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する請求項1又は2に記載のソフトウェアの検査種別判定装置。前記記憶部は、前記ソフトウェアの開発規模に応じた開発規模判定ポイントをさらに格納し、前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記開発規模判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する請求項1から3の何れか1項に記載のソフトウェアの検査種別判定装置。前記検査は、前記ソフトウェアの開発の終了時に実施すべき品質検査と、前記ソフトウェアの公開時に実施すべき公開時検査との双方を含む請求項1から4の何れか1項に記載のソフトウェアの検査種別判定装置。コンピュータを、ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部とを備えた装置として機能させるプログラム。前記コンピュータを、前記記憶部が、前記担当者が開発したソフトウェアに係る障害が発生した場合に、該障害の規模に応じた障害判定ポイントをさらに格納し、前記決定部が、前記記憶部に前記担当者の前記障害判定ポイントが格納されている場合には、少なくとも前記開発内容ポイント、前記担当者判定ポイント及び前記障害判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定するように機能させる請求項6に記載のプログラム。前記コンピュータを、前記記憶部が、前記担当者の開発に係るブランクに応じたブランク判定ポイントをさらに格納し、前記決定部が、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記ブランク判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定するように機能させる請求項6又は7に記載のプログラム。前記コンピュータを、前記記憶部が、前記ソフトウェアの開発規模に応じた開発規模判定ポイントをさらに格納し、前記決定部が、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記開発規模判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定するように機能させる請求項6から8の何れか1項に記載のプログラム。しかしながら、品質検査種別を判定するにあたっては、以下の問題があった。すなわち、開発担当者からのヒアリングにおいて、開発担当者の説明不十分、或いは検査担当者のヒアリング不十分などによって、客観的に正確な情報を開発担当者から得ることができず、検査工数の少ない品質検査を行った結果、その後に検査がなされなかった部分で障害が発生することが起こりえる。また、検査結果報告や障害状況報告では、ヒアリングと同様に、十分な客観的画一的な判断を以て検査種別を決定することができない場合があった。この場合、検査担当者は、障害発生を未然に防止する観点から、検査工数の多い品質検査種別を選択しやすい傾向にあった。検査工数の多い品質検査種別が実施されることで、障害発生の可能性の低減を図ることはできるものの、検査対象のソフトウェアの中には、少ない検査工数で済むものがあることも事実であり、そのようなソフトウェアに対して多大な検査工数を実施することは非効率であった。本発明は、上記問題に鑑みなされたものであり、検査種別を客観的且つ画一的に判定して、適正な検査工数での検査を実施可能とする技術を提供することを目的とする。本発明の態様の一つは、ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部とを含むソフトウェアの検査種別判定装置である。上記検査種別判定装置は、前記記憶部が、前記担当者が開発したソフトウェアに係る障害が発生した場合に、該障害の規模に応じた障害判定ポイントをさらに格納し、前記決定部は、前記記憶部に前記担当者の前記障害判定ポイントが格納されている場合には、前記開発内容ポイント、前記担当者判定ポイント及び前記障害判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定するように構成することが可能である。また、上記検査種別判定装置は、前記記憶部が、前記担当者の開発に係るブランクに応じたブランク判定ポイントをさらに格納し、前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記ブランク判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する、ように構成することが可能である。また、上記検査種別判定装置は、前記記憶部が、前記ソフトウェアの開発規模に応じた開発規模判定ポイントをさらに格納し、前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記開発規模判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する、ように構成することができる。また、上記検査は、前記ソフトウェアの開発の終了時に実施すべき品質検査と、前記ソフトウェアの公開時に実施すべき公開時検査との双方を含むようにすることができる。また、開発内容ポイントは、例えば、検査対象のソフトウェアの開発工数の多寡開発規模及び開発の難易度の少なくとも一方を確定するために用意された、回答選択式の複数の設問に対し、前記担当者が各設問に対して選択した回答に予め付与されたポイントの合計値である。本発明は、他の態様として、上記検査種別判定装置と同様の構成を有する検査種別判定方法、コンピュータを上記検査種別判定装置として機能させるプログラム、該プログラムを記録した記録媒体を含むことができる。本発明によれば、検査種別を客観的且つ画一的に判定して、適正な検査工数での検査を実施することが可能となる。以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明の構成は実施形態の構成に限定されない。実施形態1<品質検査に係る過程>図1は、実施形態1に係る品質検査工数の最適化支援システム以下、支援システムと称するが適用される品質検査の過程を模式的に示す図である。品質検査の対象は、ウェブブラウザを通じてユーザに提供される様々なウェブサービスを実現するためのソフトウェアである。ソフトウェアは、プログラム部品、プログラム部品を組み合わせたプログラムモジュール,データ例えばウェブページ又はデータ群,データ群を格納するデータ構造を含む。ソフトウェアは、当該ソフトウェアを用いてユーザに提供されるサービスの単位で管理される。以下、検査対象を特定する単位としてサービスと表記することもある。最初に、開発の担当者によるサービスソフトウェアの開発制作が完了すると、そのサービスソフトウェアが、所望の品質を有しているか否かを検査するため品質検査が依頼される図11。品質検査が依頼されると、品質検査判定が行われる。品質検査判定では、品質検査対象のソフトウェアについて実施すべき品質検査種別が判定される図12。品質検査は、開発されたソフトウェアが所望の品質を有するか否かを判定するための複数の検査工数検査項目からなる。品質検査は、ソフトウェアの信頼性完成度に応じて用意された複数の種別クラスに分類され、種別毎に1以上の検査工数検査項目が用意される。ソフトウェアの信頼性が高い程、検査工数の少ない種別が割り当てられる。品質検査種別が決定されると、その品質検査種別が提示される図13。このとき、品質検査不要との判定結果が出されるようにすることもできる。品質検査種別が提示されると、当該種別に応じた品質検査が検査対象のソフトウェアに対して実施される図14。品質検査の終了したソフトウェアに基づくサービスは、ユーザに対して公開され、リリース運用される図15。公開が決定されたソフトウェアに対しては、品質検査と異なる検査項目を有する公開時検査が実施される。公開後の運用において、当該ソフトウェアに基づくサービスに障害が発生した場合には、障害状況が検査される。以上のように、開発されたソフトウェアに対する品質検査広義として、品質検査狭義、公開時検査、障害時検査の各検査が実施される。一般に、ソフトウェア開発には、品質リスクが伴う。品質リスクとは、ソフトウェアの作り込みの程度に依存する障害発生のリスクである。作り込みが甘い場合には、障害発生の可能性が高く、品質検査において、網羅的な多数の検査工数を実施することが要求される。これに対し、作り込みが好適に行われている場合には、品質検査において、最小限の検査工数とすることが可能である。障害発生を零にしようとする見地からは、開発される総てのソフトウェアに対して、網羅的な品質検査を実施することが望まれる。しかしながら、好適な作り込みがなされている蓋然性の高いソフトウェアについてまで網羅的な品質検査を実施することは、無駄な検査をすることに繋がり、非効率である。本実施形態に係る支援システムは、担当者の品質を数値化した品質ポイント、ソフトウェアの開発内容を数値化した開発内容ポイントなどを格納したデータベースDBを有しており、品質検査判定図12において、DBに蓄積されたポイントを用い、画一的な判断手法で検査対象のソフトウェアに対する品質検査種別を自動的に算出する。DBに蓄積される品質ポイントには、上述した品質検査の検査結果が反映される。また、障害発生時の障害状況が障害判定ポイントとして数値化され、品質検査種別の判定における判定ロジックに組み込まれる図1<1>、<2>。このように、ソフトウェアの開発担当者の過去の実績が反映されたDBを用い、当該担当者により作製されたソフトウェアの信頼性完成度を予測し、品質検査種別が決定される。これによって、過去に信頼性の低い品質検査狭義の結果が良くない、或いは障害が生じたソフトウェアを開発した担当者のソフトウェアに対しては、検査工数の多い品質検査種別が決定される。これに対し、信頼性の高い良好な品質検査狭義結果を得た開発担当者のソフトウェアについては、検査工数の少ない品質検査種別が決定される。このようにして、品質検査対象のソフトウェアに対して、適正な工数の品質検査を実施可能とすることによって、効率的な品質検査を実施することが可能となる。また、従来では、品質検査判定に当たり利用されていた開発担当者からのヒアリング内容や、検査結果、障害状況報告などが、客観的なポイントに置き換えられ、開発担当者の恣意や、検査担当者の解釈などが可能な限り排除されるようになっている。そして、品質検査判定が支援システムを用いた画一的な判定ロジックを用いて実行されることで、画一的且つ客観的な品質種別判定を行うことができ、適正な検査工数の品質検査を実施でき、効率化を図ることができる。以下、支援システムの詳細について説明する。<情報処理装置の構成>図2は、支援システムを実現するために使用される情報処理装置の構成例を示す図である。図2に示す情報処理装置10は、例えばパーソナルコンピュータである。但し、専用又は汎用のコンピュータを用いることが可能である。図2において、情報処理装置10は、バスBを介して相互に接続されたCPU1プロセッサと、主記憶装置2と、記憶部としての補助記憶装置3と、通信インタフェース通信I/F4と、入力装置5と、表示装置6と、プリンタ7とを備えている。補助記憶装置3は、例えばハードディスクHDDのようなコンピュータ読み取り可能な記録媒体であり、支援システムを実現するための1以上のコンピュータプログラムがインストールされている。また、補助記憶装置3には、支援システムを実現するためのプログラムの実行に際して使用されるデータが格納されたデータベースDBが格納されている。また、補助記憶装置3には、品質検査を実施する検査システム後述を実現するための1以上のプログラムがインストールされており、当該プログラムの実行に際して使用されるデータ群を格納している。なお、補助記憶装置3として、HDDのような固定ディスクの他、フラッシュメモリのような可搬性を有する記憶装置を適用することができる。或いは、補助記憶装置3として、EEPROMElectricallyErasableProgrammableReadOnlyMemoryを適用することも可能である。通信I/F4は、例えばLAN構内交換網ボードであり、ネットワークを介して接続された他の情報処理装置コンピュータと通信を行う。これによって、補助記憶装置3に格納された情報を他の情報処理装置に送信したり、他の情報処理装置から受信された情報を補助記憶装置3で保存したりすることができる。入力装置5は、情報処理装置10のオペレータが、各種の情報を情報処理装置10に入力するための装置であり、例えば、キーボードや、マウスのようなポインティングデバイスを含む。表示装置6は、CPU1による処理結果に基づく情報を表示するディスプレイ装置である。プリンタ7は、表示装置に表示された表示内容をシートに印刷する印刷装置である。CPU1は、補助記憶装置3に格納されたプログラムを主記憶装置2にロードして実行することにより、支援システムとしての機能を実現する。主記憶装置2は、例えばRAMReadOnlyMemoryのようなコンピュータ読み取り可能な記録媒体であり、CPU1の作業領域として使用される。情報処理装置10のCPU1がプログラム実行によって支援システムを実現することにより、情報処理装置10は、本発明に係る記憶部,変換部,決定部,及び更新部を少なくとも備える検査種別判定装置として機能する。<テーブルの構成>次に、図2に示した補助記憶装置3に格納されたDBに含まれるテーブル群について説明する。DBは、判定ポイントマスタテーブルと、登録データテーブルと、担当者品質テーブルとを含む。DBは、さらに、品質検査種別マスタテーブルと、担当者情報マスタテーブルと、障害規模-判定ポイントマスタテーブルとを含む。図3Aは、判定ポイントマスタテーブル21のデータ構造例を示す図であり、図3Bは、登録データテーブル22のデータ構造例及び入力例を示す図であり、図3Cは、担当者品質テーブル23のデータ構造例を示す図である。判定ポイントマスタテーブル21は、検査対象のソフトウェアに対する品質検査狭義に当たり、検査対象のソフトウェアサービスの開発規模や開発難易度を確定するために予め用意された複数の設問と、設問に対する回答に対して予め規定されたポイントが登録されている。図3Aに示す例では、各設問に対して回答x,y,zが用意されており、各回答x,y,zに対するポイントが登録されている。登録データテーブル22には、サービス名ソフトウェアを用いて提供されるサービス名と、そのサービスに係るソフトウェアを開発した担当者名と、品質検査に当たって提供される設問の回答内容に応じたポイントが、サービス名且つ担当者毎に登録される。なお、図3Bに示す例では、設問4~設問9に対する欄の図示が省略されている。登録データテーブル22に登録される設問の回答に応じたポイントの合計値は、開発対象のソフトウェアサービスの開発の難易度や、開発工数の規模多寡を示すものであり、開発内容ポイントと称する。開発工数が多い、或いは開発の難易度が高い障害発生の可能性の高い開発が含まれていれば、開発内容ポイントは大きくなり、検査工数が多い検査種別が決定される方向に作用する。逆に、開発規模が小さい、或いは開発の難易度が低い障害発生の可能性が低い開発であれば、開発内容ポイントは小さくなり、検査工数の少ない検査種別が決定される方向に作用する。担当者品質テーブル23には、担当者毎に、品質ポイントと、検査実施回数と、障害判定ポイントとが登録される。品質ポイントは、担当者が作製したソフトウェアの品質を数値化したものであり、品質ポイントが小さい程、担当者が品質の良い障害の起こらないソフトウェアサービスを開発することを示す。検査実施回数は、当該担当者に対して実施された品質検査狭義の回数を示す。障害判定ポイントは、当該担当者によって開発されたソフトウェアサービスが障害を引き起こした場合に付与されるポイント数値である。障害判定ポイントが大きい程、過去に生じた障害規模が大きい、或いは、複数回の障害を発生させたことを示す。図4Aは、品質検査種別マスタテーブル24のデータ構造例を示す図であり、図4Bは、担当者情報マスタテーブルのデータ構造例を示す図であり、図4Cは、障害規模-判定ポイントマスタテーブル26のデータ構造例を示す図である。品質検査種別マスタテーブル24は、品質検査種別検査方法と、判定ポイントとの関係を定義したテーブルである。図4Aの例では、検査方法として、A~D検査と、検査なしとが定義されており、A~D検査及び検査なしの夫々に対応する判定ポイントの数値範囲が登録されている。具体的には、判定ポイントの合計値aが300以上であれば、A検査が決定される。判定ポイントの合計値aが100以上300未満であれば、B検査が決定される。判定ポイントの合計値aが50以上100未満であれば、C検査が決定される。判定ポイントの合計値aが10以上50未満であれば、D検査が決定される。判定ポイントの合計値aが10未満であれば、検査なしが決定される。なお、検査種別検査方法の数は適宜設定可能である。また、判定ポイント合計値の数値範囲も適宜設定可能である。担当者情報マスタテーブル25は、担当者品質と、担当者品質に応じた品質ポイントbの数値範囲と、担当者品質に応じた担当者判定ポイントとが登録されている。図4Bに示す例では、担当者品質のクラスが、良い,普通,悪いの3種類に区分されている。品質ポイントが85を上回り且つ100以下であれば、担当者品質良いに区分される。品質ポイントが50を上回り且つ85以下であれば、担当者品質普通に区分される。品質ポイントが50以下であれば、担当者品質悪いに区分される。そして、良い,普通,悪いの夫々に区分される担当者について、担当者判定ポイント-120,-70,-20が夫々付与される。なお、担当者品質のクラス数、品質ポイントの数値範囲、担当者判定ポイントは適宜設定可能である。また、担当者情報マスタテーブル25は、或る担当者についての品質検査が初めてである初めての品質検査依頼である場合に、当該担当者に付与される品質ポイント及び担当者判定ポイントとして、なし及び0を格納している。障害規模-判定ポイントマスタテーブル26は、障害規模と障害判定ポイントとが定義されたテーブルである。図4Cに示す例では、障害規模は、大,中,小の3つに区分され、各障害規模に対して障害判定ポイント10,7,3が定義されている。障害規模の数及び障害判定ポイントは適宜設定可能である。<動作例>次に、支援システムを実現する情報処理装置10図2の動作例について説明する。開発担当者は、ソフトウェアの開発が終了すると、品質検査を依頼すべく、情報処理装置10の入力装置5を操作して、支援システムを実行するプログラム支援プログラムと称するの実行開始指示を入力する。すると、CPU1が補助記憶装置3に格納された支援プログラムを主記憶装置2にロードし、当該支援プログラムの実行を開始する。<<品質検査依頼時の動作>>図5は、CPU1によって実行される品質検査判定処理の例を示すフローチャートである。支援プログラムの実行が開始されると、CPU1は、表示装置6を制御して、品質検査依頼の入力画面31を情報処理装置10の表示装置6図2に表示する図5,ステップS1。図6は、品質検査依頼の入力画面例を示す図である。図6において、入力画面31は、基本情報入力欄と、検査種別判定情報入力欄とを備えている。図6に示す例では、基本入力欄には、サービス名と、登録者の入力欄が設けられている。サービス名は、開発担当者が開発を行ったサービスソフトウェアの名称が入力される。登録者として、開発担当者の氏名が入力される。このとき、氏名とともに、担当者の所属部署を記入することもできる。また、基本情報として入力が要求される情報項目として、検査対象特定情報サービス名及び担当者特定情報登録者名は必須である。もっとも、検査対象特定情報及び担当者特定情報の情報自体はこれらを特定するためのコードであっても良い。また、基本情報として、検査対象特定情報及び担当者特定情報以外の情報入力が求められるようにしても良い。検査種別判定情報入力欄には、検査種別を判定するための複数の設問が用意されており、設問に対する回答を入力するためのラジオボタンが設問毎に用意されている。図6の例では、検査種別判定情報は、開発担当者の開発規模や開発の難易度開発内容を確定するための情報であり、サービス区分,機能,開発種別,サイトの各項目からなり、各項目について1以上の設問が用意され、全部で9個の設問が用意されている。なお、本実施形態では、9個の設問の総てが必須入力事項である例を示しているが、検査種別判定情報の項目、各項目に対する設問の数や内容は適宜設定可能である。基本情報入力欄及び検査種別判定情報の夫々の近傍には、確認ボタンが用意されている。基本情報入力欄に対応する確認ボタンが押されると、例えば、CPU1は、補助記憶装置3上のDBに予め格納されているサービス名や登録者名を検索し、マッチングを行う。このとき、DBから入力されたサービス名や登録者名が検索されなかった場合には、入力エラーとして、適正なサービス名や登録者名の入力を求める表示が入力画面31に表示される。検査種別判定情報入力欄に対応する確認ボタンが押されると、CPU1は、検査種別判定情報入力欄に対する入力漏れをチェックし、入力漏れがある場合には、入力漏れがあることを報知する表示を入力画面31に表示し、入力を促すことができる。開発担当者は、入力装置5を操作し、入力画面31に対して各種情報を入力し、確認ボタンを押す。すると、品質検査判定処理が開始される。なお、上記説明では、開発担当者本人が情報の入力作業を行っているが、他の者が開発担当者から得た情報を元に入力作業を行うようにしても良い。入力画面31に対する適正な情報入力がなされ、ステップS1の処理が終了すると、CPU1は、処理をステップS2に進め、判定ポイント集計処理を実行する。すなわち、CPU1は、補助記憶装置3に格納されている担当者品質テーブル23図3Cを参照し、入力画面31に入力された担当者登録者のレコードを検索する。このとき、該当する担当者のレコードがヒットすれば、CPU1は、当該レコード中の品質ポイントb及び障害判定ポイントを抽出する。これに対し、担当者品質テーブル23に該当する担当者登録者がなければ、当該担当者登録者に係るレコードが新たに登録される。レコードの初期値として、品質ポイント0,検査実施回数0,及び障害判定ポイント0が登録される。もっとも、担当者品質テーブル23に対し支援システムを利用する総ての開発担当者のレコードを予め登録しておいても良い。この場合、入力画面31に入力された登録者担当者のレコードが必ずヒットする。続いて、CPU1は、担当者情報マスタテーブル25図4Bを参照し、担当者品質テーブル23から得られた品質ポイントbが合致する担当者品質を割り出し、割り出した担当者品質に対応する担当者判定ポイントを読み出す。すなわち、品質ポイントが、複数の担当者品質レベル良い普通悪いの一つに応じた担当者判定ポイントに変換される。本実施形態では、担当者判定ポイントは、マイナスの値であり、後述する検査種別判定において、担当者判定ポイントが小さい低い程、検査工数の少ない検査種別が判定されるようにしている。なお、担当者品質テーブル23の検査実施回数が0の場合には、CPU1は、担当者情報マスタテーブル25から担当者判定ポイント0を読み出す。CPU1は、読み出した担当者判定ポイントを主記憶装置2の作業領域にストアする。次に、CPU1は、判定ポイントマスタテーブル21図3Aを参照し、入力画面31に入力された各設問の回答に対応するポイントを読み出して、登録データテーブル22図3Bへの登録処理を行う。すなわち、CPU1は、登録データテーブル22からサービス名及び担当者名が一致するレコードを検索し、該当するレコードがあれば、判定ポイントマスタテーブルから読み出した設問1~9の回答に対応するポイントを登録する。該当するレコードがない場合には、CPU1は、登録データテーブル22にサービス名及び担当者名でインデックスされる新たなレコードを作成し、当該レコード中に設問1~9の回答に対応するポイントを登録する。CPU1は、登録データテーブル22に登録した設問1~9への回答に対するポイントを、主記憶装置2の作業領域にストアする。そして、CPU1は、以下の計算式に基づき判定ポイント合計値aを加算方式で算出する。下記計算式の括弧内の合計値は、開発内容ポイントを示す。計算式判定ポイント合計値a=担当者判定ポイント障害判定ポイント設問1~9の各回答ポイントの合計値以上のようにして、判定ポイントの合計値を算出すると、CPU1は、ステップS2の判定ポイント集計処理を終了する。なお、上記した担当者品質テーブル23と判定ポイントマスタテーブル21の参照順は逆であっても良く、登録データテーブル22への登録処理と担当者情報マスタテーブル25の参照処理との順序は逆であっても良い。次に、CPU1は、処理をステップS3に進めて品質検査種別判定処理を実行する。すなわち、CPU1は、品質検査種別マスタテーブル24図4Aを参照し、判定ポイント合計値aに合致する、すなわち判定ポイント合計値aが数値範囲に収まる検査方法を読み出し、読み出された検査方法を、今回依頼された品質検査に適用する検査方法検査種別として決定する。次に、CPU1は、処理をステップ4に進めて品質検査種別提示処理を実行する。すなわち、CPU1は、表示装置6を制御し、ステップS3で決定した検査方法を示す品質検査種別提示画面41を表示装置6に表示する。図7Aは、品質検査種別提示画面41の表示例を示し、図7Bは、検査種別に対する検査工数の相対値を示す表を示す。図7Aに示すように、品質検査種別提示画面41には、決定された検査方法図の例ではB検査が画面41の上段に表示される。また、画面41の下段には、各検査方法に合致する提出資料を確認するためのハイパーリンクが表示される。開発担当者は、リンク先の情報を参照して、品質検査に際しての提出資料を確認し、資料を提出することになる。なお、図7Bに示すように、検査方法検査種別は、A検査の検査工数が最も多く、開発されたサービスソフトウェアに対する品質リスクが最も大きい障害発生の蓋然性が高い場合に実施される。以下、B検査、C検査は、D検査と、品質リスクの大きさに準じて検査レベルが下がり、検査工数が削減されている。さらに、品質リスクが殆どない障害発生の蓋然性が殆どない場合には、検査工数0,すなわち検査なしが決定される。このように、品質リスクに応じた品質検査種別検査方法が決定されることで、無駄な検査工数が実施されるのを防止し、品質検査の効率化が図られる。<<品質検査時>>図8は、品質検査サービス公開直後の検査公開時検査と呼ばれるを含む時における支援システムを実現する情報処理装置10CPU1の動作例を示すフローチャートである。図8に示す処理が開始されると、CPU1は、品質検査判定処理にて決定された検査方法での品質検査、及び公開時検査の依頼を、検査システムに渡すステップS01。品質検査と公開時検査とは内容が全く別個の独立した検査である。検査システムは、支援システムから独立した別個のシステムである。検査システムは、プログラムがCPUのようなプロセッサによって実行されることにより実現される機能であり、本実施形態では、情報処理装置10が検査システムを実現するためのプログラムを実行することによって検査システムとして機能する。但し、検査システムとしての処理は、情報処理装置10と異なる他のコンピュータが実施することもでき、例えば、情報処理装置10が、通信回線を介して接続された他のコンピュータが有する検査システムに対して品質検査及び公開時検査を依頼し、当該他のコンピュータから品質検査及び公開時検査の結果品質ポイント及び平均品質ポイント後述を受信するようにしても良い。以下、検査システムが情報処理装置10によって実施される例について説明する。CPU1は、品質検査及び公開時検査の依頼に当たって、検査システムを実現するプログラムの実行を開始する。当該プログラムの実行によって生成される検査システムのプロセスに対し、品質検査の検査種別と、公開時検査の依頼と、登録データテーブル22図3Bのサービス名とを渡す。検査システムは、検査方法に応じた品質検査、及び公開時検査を実施するステップS02。検査の実施に当たって、検査方法に応じた提出資料を使用する。提出資料のデータは、予め情報処理装置10に格納される。そして、品質検査及び公開時検査に対する結果の報告件数報告の内容報告分類などを元に品質ポイントを算出する。報告件数、報告の内容、報告分類は予め決められた数値化方法で数値化ポイント化され、数値化された報告件数、報告内容、報告分類を所定の品質ポイント算出式に代入することで、品質ポイントを算出する。さらに、検査システムは、品質検査や公開時検査の実施により算出された品質ポイントを検査終了時の時間情報ととともに補助記憶装置3の所定領域に蓄積している。検査システムは、今回の品質検査及び公開時検査の終了時点から過去に遡った特定期間内における総ての品質検査及び公開時検査に対する品質ポイントを抽出し、特定期間中の平均品質ポイントを算出する。そして、検査システムは、サービス名とともに、品質検査及び公開時検査によって得られた品質ポイントbと、平均品質ポイントとを支援システムに結果として返す。すると、CPU1は、支援プログラムによる処理を再開し、登録データテーブル22を参照して、サービス名が合致するレコードから担当者名を抽出する。続いて、CPU1は、担当者品質テーブル25図4Bを担当者名でインデックスし、該当するレコード中の品質ポイント担当者品質テーブル.品質ポイントを取得するステップS03。続いて、CPU1は、以下の式を用いて、更新に係る品質ポイントの値を算出する。すなわち、検査システムから得られた平均品質ポイントから品質ポイントを減じた値と、現在の担当者品質テーブルの品質ポイントとを加算する。式担当者品質テーブル.品質ポイント=担当者品質テーブル.品質ポイント平均品質ポイント-品質ポイント続いて、CPU1は、担当者品質テーブル23の品質ポイントを、ステップS03で与えられた品質ポイントで更新上書きする。また、CPU1は、担当者品質テーブル23の検査実施回数に1を加える。上記した品質ポイントの更新により、今回の品質検査及び公開時検査によって得られた品質ポイントが特定期間内の平均品質ポイントを上回る場合には、更新される品質ポイントの値は上昇することになり、当該担当者の品質リスクが低減される。これに対し、今回の検査によって得られた品質ポイントが平均ポイントを下回る場合には、更新される品質ポイントの値は下降することになり、当該担当者の品質リスクが上昇する。なお、上述した例では、公開時検査が必須であり、品質検査と公開時検査とが同時に行われる例について説明したが、品質検査と公開時検査とが時間を空けて実施される場合には、品質検査と公開時検査との一方に係るステップS01~S05の処理が実行され、品質ポイントの更新及び検査実施回数の更新が行われるようにしても良い。また、品質検査と公開時検査との一方のみを実施する運用がなされる場合にも、品質検査と公開時検査との一方に係るステップS01~S05の処理が実行されるようにすることが可能である。<<運用時障害発生時>>図9は、開発されたサービスソフトウェアの運用が開始された後に、当該サービスに係る障害が発生した場合における、支援システムを実現する情報処理装置10CPU1の動作例を示すフローチャートである。図9に示す処理は、例えば、表示装置6に障害規模の入力画面図示せずが表示され、オペレータが入力装置5の操作によって、担当者名登録者名と、発生した障害規模大,中,小を入力することによって開始される。障害規模が入力されると、CPU1は、障害規模-判定ポイントテーブル26図4Cを参照して、入力された障害規模に応じた障害判定ポイントを読み出すステップS11。次に、CPU1は、担当者品質テーブル23図3Cを参照し、担当者品質テーブル23中に、入力された担当者名のレコードがあるか否かを判定するステップS12。このとき、該当レコードがあれば、処理がステップS14に進む。これに対し、該当レコードがなければ、CPU1は、担当者品質テーブル23に当該担当者のレコードを追加しステップS13、処理をステップS14に進める。なお、ステップS13で追加されるレコード中の障害判定ポイントの初期値として0が設定される。ステップS14では、CPU1は、担当者品質テーブル23中の障害判定ポイントの値に、ステップS11で読み出された障害判定ポイントを加算する。続いて、CPU1は、上記加算によって得られた新たな障害判定ポイントで担当者品質テーブル23の当該担当者の障害判定ポイントの値を更新上書きするステップS15。このように、障害が発生した場合には、その障害が発生したサービスの開発担当者に対し、障害規模に応じた障害判定ポイントが加算される。障害判定ポイントは累積的に蓄積されるため、障害を発生させた回数が多い程、判定ポイント合計値が大きくなる方向に作用する。<支援システムの使用例>次に、上述した支援システムを用いて得られる検査種別の判定結果、及び判定ポイントの変遷の例について説明する。図10は、同一のサービスサービス名:サービスAに関して、品質の異なる担当者が開発を行った場合における、品質検査判定処理の結果検査種別を示す表である。図10の表において、担当者の品質として、悪い場合担当者判定ポイント:-20、普通の場合担当者判定ポイント:-70、及び良い場合担当者判定ポイント:-120を示している。また、図10の表において、設問1~9の内容は、図6に示した入力画面31に示された設問1~9に相当し、回答に対するポイントは、図3Aに示した判定ポイントマスタテーブル21の内容に合致する。設問1~9の回答に対するポイントが担当者間で同じであった場合、判定ポイントの合計値aは、夫々140,90,40となる。よって、品質の悪い担当者についてはB検査の実施が決定され、品質が普通の担当者についてはC検査の実施が決定され、品質が良い担当者についてD検査の実施が決定される。このように、支援システムによる品質検査判定処理によれば、担当者の品質に応じた検査工数の検査種別の実施が決定されるようにすることができる。図11は、異なるサービスサービスA~Eについて、担当者が品質検査を始めて依頼する場合担当者の品質が均一である場合における、品質検査判定処理の結果検査種別を示す表である。また、図11の表において、設問1~9の内容は、図6に示した入力画面31に示された設問1~9に相当し、回答に対するポイントは、図3Aに示した判定ポイントマスタテーブル21の内容に合致する。サービスAは、完全な新規サービスの場合である設問1~9に対する回答が総て回答x。新規サービスの開発は、既存サービスの改良に比べて障害が生じる可能性が高く、障害発生箇所の予測が難しい。このため、網羅的な検査が必要となるので、質問に対するポイント加算の結果、最高レベルのA検査が検査種別として決定されるような判定ポイントが算出されるようになっている。サービスBは、既存機能の追加を行い設問3の回答x、更に設問4~9に対して回答xが選択された場合を示す。この場合、新規サービス程の検査工数は要しないものの、変更又は新規追加に係る開発工数が多いため、検査工数がA検査より1レベル低いB検査が検査種別として決定される。サービスCは、設問3,6~9に対して回答xが選択され、且つ設問1,2,4,5に対して回答yが選択された場合の例を示す。この場合、既存機能の追加ではあるが、サイト構成やUIユーザインタフェースの変更はなく、既存テンプレートを用いている。このため、障害発生の可能性はサービスBに比べて低いと考えられる。よって、検査工数がサービスBより低いC検査が検査種別として決定される。サービスDは、既存テンプレートを使用した動的ページの改変に係る開発である。動的ページは、静的ページに比べて障害発生の可能性が高い。このため、検査工数が最低であるが、品質検査を実施する必要があると考えられる。よって、検査工数が最低のD検査が検査種別として決定される。サービスEは、既存テンプレートを使用した20ページ未満の静的ページの追加に係る開発である。この場合、障害は殆ど発生しないと考えられる。よって、検査種別として、検査なしが決定される。図12は、或る担当者担当者Aが或るサービスサービスAの同一の開発内容について複数回の検査を受け、検査毎に担当者の品質が向上した場合における判定ポイント合計値の変遷を示す。図12において、1回目の検査では、品質ポイントが0のため、検査種別はB検査となるが、品質検査の結果が平均を上回れば、品質ポイントが加算されるため、2回目の検査依頼時における品質ポイントは1回目よりも大きくなる。このため、2回目の品質検査では、判定ポイント合計値が減少し、検査工数がB検査より少ないC検査となる。さらに、2回目の品質検査で平均を上回る結果が得られれば、品質ポイント値がさらに上昇するので、3回目の品質検査では、判定ポイント合計値がさらに減少し、C検査よりさらに検査工数の少ないD検査となる。このように、支援システムによれば、担当者が品質の良い開発を続ける限り、品質ポイントが上昇し、判定ポイント合計値が減少するので、当該担当者の開発に係る検査工数は検査毎に減り、効率的な品質検査の実施が可能となる。図13は、或る担当者担当者Aが或るサービスサービスAの同一の開発内容について複数回の検査を受け、検査毎に担当者の品質が低下した場合における判定ポイント合計値の変遷を示す。図13において、1回目の検査では、品質ポイントが-120のため、検査種別はD検査となる。しかし、品質検査の結果が平均を下回れば、品質ポイントが減算されるため、2回目の品質検査依頼時における品質ポイントは1回目よりも小さくなる。このため、2回目の品質検査では、判定ポイント合計値が増加し、検査工数がD検査より多いC検査となる。さらに、2回目の品質検査で平均を下回る結果となれば、品質ポイント値がさらに下降するので、3回目の品質検査では、判定ポイント合計値がさらに減少し、B検査となる。このように、支援システムによれば、担当者が品質の悪い開発を続ければ、品質ポイントが下降し続けるので、それに応じてレベルの高い検査種別が判定結果として示されるようになる。従って、各担当者の検査種別の判定結果を継続的に監視すれば、担当者がどのような品質の開発を行っているかを知ることができる。以上説明した実施形態に係る品質検査工数最適化の支援システムによれば、担当者の過去に実施された検査結果に応じた品質ポイントが担当者の品質ポイントに反映フィードバックされ、次の検査における検査種別検査工数の判定結果は、品質ポイントの大きさに大きく依存する。すなわち、担当者の品質が良ければ品質ポイントが上昇し、悪ければ品質ポイントが下降する。検査システムは、品質検査及び公開時検査について、担当者間且つサービス間で同一の論理判定ロジックで品質ポイント及び平均ポイントを算出するようになっている。このため、検査結果に応じて反映される品質ポイントには客観性が担保されている。また、担当者が開発したサービスが障害を引き起こした場合には、その障害規模に応じた障害判定ポイントが担当者に付与され、検査種別の判定において検査工数を多くする方向に作用する。また、品質検査依頼時の設問として、開発規模の大きさ開発内容を特定するための複数の設問が回答選択形式で提供されるので、開発規模や開発の難易度を客観的且つ画一的にポイントとして数値化でき、検査種別の判定ポイントに反映することができる。よって、支援システムによれば、客観性が担保された判定ポイント合計値を以て品質検査の検査種別が判定される。これによって、担当者に応じた適正な検査工数を有する検査種別での品質検査を実施することができ、品質検査の効率化が図られる。実施形態2次に、本発明の実施形態2について説明する。実施形態2は、実施形態1と共通点を含むため、主として相違点について説明し、共通する構成については同一の符号を付して説明を省略する。実施形態1では、品質検査の実施に当たり、品質検査の受け付け時に品質リスクを考慮する一方で、ソフトウェアの開発制作担当者の過去の実績データに基づき、適正な品質検査方法が提示される。しかしながら、開発担当者の習熟度、及び開発改修規模に対する考慮をさらに進める余地があった。また、品質検査受け付け後における開発の状況変化に応じた品質検査方法の見直しに対し、十分に考慮が払われているとは言えない。品質検査に要求される作業時間を短縮するには、予測される品質リスクの大小に加え、開発担当者の習熟度、開発改修の規模、及び品質検査受け付け後の状況変化に応じて、適正な品質検査方法が提示されることが望ましい。実施形態2に係る支援システムでは、実施形態1に比べて、開発担当者の習熟度や開発改修規模に対する考慮が深められている。また、品質検査の受け付け後における状況変化への対応が可能となっている。以下、実施形態2に係る支援システムにつき詳細に説明する。図15は、実施形態2に係る品質検査工数の最適化支援システム支援システムが適用される品質検査の過程を模式的に示す図である。図15に示す品質検査の過程1~7の概要は、図1に示した実施形態1に係る品質検査の過程1~7と同様である。但し、図15に示す過程2~4の詳細は、実施形態1と異なっている詳細は後述。また、実施形態2では、図15に示すように、過程2A及び3Aが追加されている破線で囲まれた部分を参照。すなわち、過程3の品質検査種別提示後において、ソフトウェアの開発制作状況に変化が生じない場合には、実施形態1と同様に過程4に進む図1参照。これに対し、過程3における品質検査種別の提示後、開発制作状況に変化が生じた場合には、品質検査の再判定が実行され図15、過程2A、再判定結果に応じた品質検査種別が提示される図15、過程3A。その後、過程4において、品質検査等が実施される。このように、実施形態2では、品質検査の受け付け後に、開発状況に変化が生じた場合には、品質検査再判定が実施され、再判定結果に基づく品質検査種別が提示される。したがって、開発工程における計画外の工数増大や仕様変更による品質のぶれのような開発状況の変化に応じて、適正な品質検査種別での品質検査を実施することが可能となる。例えば、品質検査受け付け後に、開発工数や開発規模が増大した場合には、受け付け時よりも障害発生の可能性が高まる。換言すれば、検査すべき事項が増加する。この場合、品質検査種別の再判定が実施され、先に提示された品質検査種別より検査工数の多い品質検査種別が再提示される。これによって、開発状況の変化に応じた適正な品質検査を実施することが可能となる。実施形態2に係る支援システムにおいても、図2に示した情報処理装置10を適用することができる。情報処理装置10の構成は実施形態1で説明したので説明は省略する。但し、実施形態2では、補助記憶装置3図2に格納されたDBに含まれるテーブル群が、実施形態1と異なっている。また、CPU1プロセッサ:制御装置が記録媒体に記録されたプログラムの実行によって実行する品質判定処理の内容が実施形態1と異なる。さらに、実施形態2では、CPU1は、プログラムの実行によって、品質検査再判定及び提示処理を実行する。実施形態2におけるDBは、判定ポイントマスタテーブル21図3A、品質検査種別マスタテーブル24図4A、担当者情報マスタテーブル25図4B、及び障害規模-判定ポイントマスタテーブル26図4Cを有する点において、実施形態1と同様である。このため、これらのテーブル21,24~26の説明は省略する。これに対し、実施形態2におけるDBは、実施形態1における登録データテーブル22図3B及び担当者品質テーブル23図3Cの代わりの登録データテーブル22A及び担当者品質テーブル23Aを備える。また、実施形態2におけるDBは、検査ブランクマスタテーブル27と、開発規模テーブル28とをさらに含む。図16Aは、実施形態2に係る登録データテーブル22Aのデータ構造例を示し、図16Bは、実施形態2に係る担当者品質テーブル23Aのデータ構造例を示す。図17Aは、実施形態2に係る検査ブランクマスタテーブル27のデータ構造例を示し、図17Bは、実施形態2に係る開発規模テーブル28のデータ構造例を示す。図16Aにおいて、登録データテーブル22Aは、サービス名ソフトウェアを用いて提供されるサービス名と、そのサービスに係るソフトウェアを開発した担当者名と、品質検査に当たって提供される設問の回答内容に応じたポイントが、サービス名且つ担当者毎に登録される点において、実施形態1の登録データテーブル22図3Bと同様である。これに対し、登録データテーブル22Aは、さらに検査開始日を格納する点で、実施形態1の登録データテーブル22と異なっている。検査開始日は、担当者が開発したサービスの品質検査の開始日を示す。図16Bにおいて、担当者品質テーブル23Aは、担当者毎に、品質ポイントと、検査実施回数と、障害判定ポイントとを格納する点で、実施形態1の担当者品質テーブル23図3Cと同様である。これに対し、担当者品質テーブル23Aは、開発工数と、前回検査開始日とをさらに格納する点で、テーブル23と異なっている。ここに、開発工数は、品質検査の申請に係る開発の工数を示す。一方、前回検査開始日は、担当者の開発物に対する過去の品質検査のうち、直近に実施された品質検査の検査開始日を示す。図17Aにおいて、検査ブランクマスタテーブル27は、レコードとして、検査ブランクの程度と、検査ブランク値cと、ブランク判定ポイントとを含む複数のエントリからなる。図17Aに示す例では、検査ブランクの程度として、ブランクが低い、ブランクが通常、ブランクが長い、初めての依頼の4種別が用意されている。但し、検査ブランクの程度の種別数は適宜設定可能である。検査ブランク値cは、担当者の開発制作に対するブランクを数値化した値である。検査ブランク値cとして、担当者品質テーブル23Aに格納された前回検査開始日と、登録データテーブル22Aに格納された検査開始日との間の期間日数から求められる値が適用される。検査ブランク値cとして、期間日数がそのまま適用されてもよく、期間日数を適宜の手法で数値化した値が適用されても良い。テーブル27には、検査ブランクの程度に応じた検査ブランク値cの採り得る範囲が格納される。但し、初めての依頼に対する検査ブランク値cの採り得る範囲はない。また、テーブル27には、検査ブランクの程度に応じたブランク判定ポイントが登録される。ブランク判定ポイントは、ブランクが短い程低い値が設定される。但し、図17Aの例では、ブランクが長い場合と初めての依頼とは同じブランク判定ポイントが設定されている。もっとも、ブランクが長い場合のブランク判定ポイントは、初めての依頼のブランク判定ポイントより小さくても良い。図17Bにおいて、開発規模テーブル28は、レコードとして、開発規模の程度と、開発規模値dと、開発規模判定ポイントとを含む複数のエントリからなる。図17Bに示す例では、開発規模の程度として、開発規模が小さい、開発規模が中程度、開発規模が大きい、新規開発の4種別が用意されている。但し、開発規模の程度の種別数は適宜設定可能である。開発規模値dは、品質検査に係る開発物の開発規模を数値化した値である。開発規模値dの算出については後述する。テーブル28には、開発規模の程度に応じた開発規模値dの採り得る範囲が格納される。但し、新規開発に対する開発規模値dの採り得る範囲はない。また、テーブル28には、開発規模の程度に応じた開発規模判定ポイントが登録される。開発規模判定ポイントは、開発規模が小さい程低い値が設定される。但し、図17Bの例では、開発規模が大きい場合と新規開発とは同じ開発規模判定ポイントが設定されている。もっとも、開発規模が大きい場合の開発規模判定ポイントとして、新規開発の開発規模判定ポイントより小さい値が設定されても良い。上記したブランク判定ポイントは、担当者の開発ブランクに応じた開発の習熟度を示す指標の1つとなり、開発規模判定ポイントは、開発の規模を示す指標の1つとなる。これらのブランク判定ポイント及び開発判定ポイントは、実施形態1で説明した担当者判定ポイント及び各設問図6に対する回答のポイントとともに、実施形態2において品質検査種別を判定するための要素となる。すなわち、実施形態2では、担当者判定ポイント及び各設問に対する回答のポイントの合計値に、ブランク判定ポイント及び開発判定ポイントを加えた値が、判定ポイント合計値aとなる。そして、品質検査種別マスタテーブル24図4aの参照によって、判定ポイント合計値aに応じた品質検査種別が決定される。次に、実施形態2における支援システムを実現する情報処理装置10図2の動作例について説明する。開発担当者は、ソフトウェアの開発が終了すると、品質検査を依頼すべく、情報処理装置10の入力装置5を操作して、支援システムを実行するプログラム支援プログラムと称するの実行開始指示を入力する。すると、CPU1が補助記憶装置3に格納された支援プログラムを主記憶装置2にロードし、当該支援プログラムの実行を開始する。図18は、CPU1によって実行される、実施形態2に係る品質検査判定処理図15、2及び品質検査種別提示処理図15、3の例を示すフローチャートである。当該処理は、品質検査の受付を契機に、支援プログラムの実行指示を情報処理装置10に入力することによって開始される。支援プログラムの実行が開始されると、CPU1は、表示装置6を制御して、品質検査依頼の入力画面を情報処理装置10の表示装置6図2に表示する図18,ステップS1。入力画面として、図6に示した入力画面31を適用することができる。但し、入力画面31には、図示しないが、今回の品質検査の開始日と、開発工数の入力欄がさらに設けられる。入力画面31及び入力装置5を用いて、サービス名,登録者開発担当者,各設問に対する回答,開発工数,及び品質検査開始日が入力された状態で確認ボタンが押されると、CPU1は、以下のような処理を行う。すなわち、CPU1は、担当者品質テーブル23Aの、開発担当者に対応するエントリ中に、入力画面31を用いて入力された開発工数を示す値を登録する。また、CPU1は、登録データテーブル22Aの、開発担当者に対応するエントリ中に、入力画面を用いて入力された検査開始日を登録する。さらに、CPU1は、実施形態1と同様に、各設問の回答に応じたポイントをエントリ中に登録するもっとも、この処理は、実施形態1と同様に、判定ポイント集計処理にて実行されても良い。なお、実施形態2における例では、入力画面を用いて開発工数が入力される例が示されている。これに対し、各設問に対する各回答に開発工数値が予め設定され、回答内容に応じた開発工数値をCPU1が集計して合計値開発工数値を求め、担当者品質テーブル23Aに格納するようにしても良い。この場合、開発工数の入力を省略可能である。ステップS1の処理が終了すると、CPU1は、処理をステップS2Aに進め、判定ポイント集計処理を実行する。ステップS2Aの判定ポイント集計処理において、CPU1は、担当者判定ポイント,障害判定ポイント,開発規模判定ポイント,ブランク判定ポイント,及び設問に対する回答ポイントの合計値を得る。担当者判定ポイント及び障害判定ポイントを取得するための処理は、実施形態1と同様の処理であるので、説明を省略する。開発規模判定ポイントを取得するための処理として、CPU1は、以下の処理を行う。すなわち、外部システムである検査システム29にアクセスし、今回の品質検査の対象となる開発物ソフトウェアの初期開発工数を取得する。例えば、CPU1は、サービス名を検査システム29に送り、サービス名に対応する初期開発工数を受け取る。続いて、CPU1は、担当者品質テーブル23A図16Bから担当者名に対応する開発工数を読み出し、以下の式1を用いて開発規模値dを算出する。式1開発規模値d=開発工数÷初期開発工数×100続いて、CPU1は、開発規模テーブル28図17Bを参照し、開発規模値dに対応する開発規模判定ポイントを読み出す。このようにして、開発規模判定ポイントが得られる。また、ブランク判定ポイントを取得するための処理として、CPU1は、以下の処理を行う。すなわち、CPU1は、担当者品質テーブル23Aから、担当者名に対応する前回検査開始日を読み出す。次に、CPU1は、登録データテーブル22A図16Aから、サービス名及び担当者名に対応する検査開始日を読み出し、前回検査開始日と検査開始日とから検査ブランク値cを算出する。続いて、CPU1は、検査ブランクマスタテーブル27図17Aを参照し、検査ブランク値cに対応するブランク判定ポイントを読み出す。このようにして、ブランク判定ポイントが得られる。さらに、CPU1は、登録データテーブル22Aに格納された各設問設問1~9に対する回答に応じたポイントの合計値を算出し、判定ポイント合計値を以下の式2を用いて算出する。式2判定ポイント合計値=担当者判定ポイント障害判定ポイント開発規模判定ポイントブランク判定ポイント各設問に対する回答ポイントの合計次に、CPU1は、品質検査種別判定処理ステップS3Aとして、以下の処理を行う。すなわち、CPU1は、品質検査種別マスタテーブル24図4Aを参照して、判定ポイント合計値が数値範囲に収まる検査方法品質検査種別を、今回の品質検査に対して適用すべき検査方法として決定する。次に、CPU1は、処理をステップS4に進めて品質検査種別提示処理を実行する。すなわち、CPU1は、表示装置6を制御し、ステップS3Aで決定した検査方法を示す品質検査種別提示画面41図7Aを表示装置6に表示する。画面41の内容、及び品質検査種別と検査工数との関係は、実施形態1と同じであるので説明を省略する。さらに、CPU1は、主記憶装置2又は補助記憶装置3の記憶領域上に作成された一次判定ポイントテーブル30に対し、ステップS2Aにおいて取得した担当者判定ポイント,障害判定ポイント,開発規模判定ポイント,ブランク判定ポイント,及び各設問に対する回答ポイントの合計値まとめて、一次判定ポイントと称するを、サービス名及び担当者名と関連づけて記録する。一次判定ポイントは、品質検査再判定及び品質検査種別判定処理において使用される。なお、一次判定ポイントテーブル30には、検査システム29から得た初期開発工数をさらに記録するようにしても良い。このように、実施形態2では、実施形態1で適用される判定要素担当者判定ポイント、障害判定ポイント、各設問に対する回答ポイントに加え、開発規模判定ポイント及びブランク判定ポイントを加味した判定ポイント合計値に基づいて品質検査種別検査方法が決定されることで、開発担当者の習熟度ブランクや開発規模をさらに考慮した品質検査種別を決定することができる。これによって、ブランクや開発規模が大きい場合には、実施形態1での判定結果よりも検査工数の多い判定結果検査方法が決定されることになり、障害発生を未然に防ぐことが可能となる。なお、開発規模判定ポイントとブランク判定ポイントとの双方が判定ポイント合計値に含まれることは必須の構成要件ではない。すなわち、開発規模判定ポイント及びブランク判定ポイントの一方のみが判定ポイント合計値に反映されるようにしても良い。この場合、判定ポイント合計値に反映されない開発規模判定ポイント及びブランク判定ポイントの他方に係る構成は省略が可能である。次に、実施形態2において実行される品質検査再判定処理図15、2A及び再提示処理図15、3Aの処理について説明する。図19は、CPU1による品質検査再判定処理及び品質検査種別提示処理の例を示すフローチャートである。品質検査の受け付け後に、開発工数や品質検査開始日が変更になった場合には、情報処理装置10における支援プログラムの実行を開始して、所定の入力画面開発工数/検査開始日の変更画面:図示せずを表示装置6上に呼び出し、開発工数、検査開始日の変更処理を行うステップS21。変更画面は、少なくともサービス名,担当者名,開発工数,検査開始日の各入力欄を備える。変更画面及び入力装置5図2を用いて、サービス名及び担当者名に関して、変更に係る開発工数及び検査開始日の少なくとも一方の変更を入力することができる。ここでは、開発工数及び検査開始日の双方が変更された場合を例示する。また、変更画面は、入力画面31にて示したような設問の回答欄を有し、設問に対する回答を再入力することもできる。CPU1は、開発工数/検査開始日の変更画面を通じて入力されたサービス名,担当者名,開発工数,及び検査開始日を受け付けると、担当者品質テーブル23A図16Bを参照し、入力された担当者名のエントリにおける開発工数を入力された開発工数で更新する。また、CPU1は、登録データテーブル22A図16Aを参照し、入力された担当者名及びサービス名のエントリにおける検査開始日を入力された検査開始日で更新する。次に、CPU1は、判定ポイント集計処理を行うステップS22。すなわち、CPU1は、一次判定ポイントテーブル30から、サービス名及び担当者名に係る一次判定ポイントを読み出す。次に、CPU1は、検査システム29にアクセスして、サービス名に対応する初期開発工数を取得する。但し、一次判定ポイントテーブル30に初期開発工数が格納されており、一次判定ポイントとともに初期開発工数を読み出すことができた場合には、CPU1は検査システム29に対するアクセスを行わない。次に、CPU1は、担当者品質テーブル23A中の更新変更に係る開発工数と、初期開発工数とを、上記した式1に代入して開発規模値dを得る。この開発規模値dを以て開発規模テーブル28を参照し、新たな開発規模判定ポイントを得る。なお、開発工数の変更がない場合には、当該処理は省略可能である。また、CPU1は、入力されたサービス名及び担当者名を用いて、登録データテーブル22A中の更新変更に係る検査開始日を読み出すとともに、担当者品質テーブル23Aに格納された担当者名に対応する前回検査開始日とを読み出し、ステップS2Aで説明した手法と同様の手法で新たなブランク判定ポイントを得る。なお、検査開始日の変更がない場合には、当該処理は省略可能である。さらに、CPU1は、変更画面にて設問に対する回答が変更されており、登録データテーブル22Aに登録された各設問の回答ポイントが変更されている場合には、各設問の回答ポイントの合計値を再計算する。但し、設問の再回答が認められない場合、及び設問に対する再回答がない場合には、当該処理は省略可能である。そして、CPU1は、新たな開発規模判定ポイントと、新たなブランク判定ポイントと、一次判定ポイントテーブル30から得た担当者品質ポイント及び障害判定ポイントと、各設問に対する回答ポイントの合計値テーブル30から取得、又は再計算との合計値、すなわち判定ポイント合計値aを得る。但し、開発規模判定ポイント及びブランク判定ポイントの一方において、上述した再取得処理が実行されない場合には、一次判定ポイントテーブル30から得たポイント値を用いる。続いて、CPU1は、品質検査種別判定処理ステップS23として、以下の処理を行う。すなわち、CPU1は、品質検査種別マスタテーブル24図4Aを参照して、判定ポイント合計値が数値範囲に収まる検査方法品質検査種別を、新たな検査方法として決定する。次に、CPU1は、処理をステップS24に進めて品質検査種別提示処理を実行する。すなわち、CPU1は、表示装置6を制御し、ステップS23で決定した検査方法を示す品質検査種別提示画面41図7Aを表示装置6に表示する。ステップS24の処理は、ステップS4の処理と同様の処理である。ステップS4によって、開発工数や品質検査開始日の変更に応じた品質検査種別が提示され、検査内容を開発状況の変化に対応させることができる。例えば、開発工数が増加した場合には、品質検査種別が工数の多いレベルに変更されることで、公開後サービス開始後に障害発生の可能性を低減できる。逆に、開発工数が減少した場合には、品質検査種別が工数の少ないレベルに変更されることによって、無駄な検査項目を省くことができる。また、開発の中断によって開発担当者のブランクが長くなった場合には、工数の多い品質検査種別に変更されることが可能となり、障害発生の可能性を低減することができる。なお、上記したステップS24において、一次判定ポイントテーブル30に再計算された各判定ポイントが記録され、品質検査種別の再々判定に使用されるようにしても良い。また、上記した例では、一次判定ポイントテーブル30に、各判定ポイントを記録格納して、再計算される判定ポイントの数を減らすようにしている。もっとも、図18に示すステップS2A及びS3Aの処理が再度実施され、全ての判定ポイントが再計算されるようにしても良い。図20は、実施形態2における品質検査図15、4:サービス公開直後の検査公開時検査と呼ばれるを含む時における支援システムを実現する情報処理装置10CPU1の動作例を示すフローチャートである。図20に示すステップS01,S02A,S03,S04,S05Aの処理は、図8に示した処理と同様である。但し、ステップS02A,S05Aは、実施形態1で説明した処理に加え、以下の処理を実行する点で実施形態1と異なっている。なお、図20に示す検査システム29は、実施形態1図8で示した検査システムと同様のものである。ステップS02Aでは、CPU1は、検査システム29から今回の品質検査の検査開始日を取得する。そして、ステップS05Aでは、CPU1は、担当者品質テーブル23Aの更新において、ステップS02Aで取得した検査開始日を、前回検査開始日として更新上書きする。このようにして、実施形態2では、品質検査の実施において、品質ポイント及び検査実施回数のみならず、前回検査開始日が更新される。以上の処理を除き、図20に示した処理は、図8に示した処理と同様であるので説明を省略する。また、図15の過程5における処理は、実施形態1と同様であるので説明を省略する。すなわち、開発されたサービスソフトウェアの運用が開始された後に、当該サービスに係る障害が発生した場合には、図9に示したような処理が実行される。図21は、或るサービスサービス名:サービスAに関して、同一の担当者品質が同じが開発を行った場合における、品質検査判定処理の結果検査種別の例を示す表である。但し、ブランク判定ポイント開発者のブランクの長さが異なっている。すなわち、検査ブランク判定ポイント以外の判定ポイントが固定された状態において、検査ブランク判定ポイントが100ブランクが長い又は初めての開発の場合と、0ブランクが通常の場合と、-20ブランクが短いの場合とにおける、判定ポイント合計値のそれぞれが示されている。図21に示すように、検査ブランク判定ポイントが大きい、すなわち、ブランクが長い程、判定ポイント合計値は大きくなり、工数の多い品質検査種別が選択される。図21の例では、ブランクが長い場合はB検査、ブランクが通常標準の場合はC検査、ブランクが短い場合はD検査が選択されている。図22は、或るサービスサービス名:サービスBについて、同一の担当者品質が同じが開発を行った場合における、品質検査判定処理の結果検査種別の例を示す表である。但し、開発規模判定ポイント開発規模が異なっている。すなわち、開発規模判定ポイント以外の判定ポイントが固定された状態において、開発規模判定ポイントが100開発規模が大きい又は新規開発の場合と、0開発規模が中通常の場合と、-20開発規模が小さいの場合とにおける、判定ポイント合計値のそれぞれが示されている。図22に示すように、開発規模判定ポイントが大きい、すなわち、開発規模が大きい程、判定ポイント合計値は大きくなり、工数の多い品質検査種別が選択される。図22の例では、開発規模が大きい場合はB検査、開発規模が通常中の場合はC検査、開発規模が小さい場合はD検査が選択されている。以上説明した実施形態1,2の構成は、本発明の目的を逸脱しない範囲で適宜組み合わせることができる。"