(57)【要約】【課題】検査種別を客観的且つ画一的に判定して適正な検査工数での検査を実施可能とする。【解決手段】ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部とを含むソフトウェアの検査種別判定装置である。【選択図】図１
2011227885.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、
前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、
少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、
前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部と
を含むソフトウェアの検査種別判定装置。
【請求項２】
前記記憶部は、前記担当者が開発したソフトウェアに係る障害が発生した場合に、該障害の規模に応じた障害判定ポイントをさらに格納し、
前記決定部は、前記記憶部に前記担当者の前記障害判定ポイントが格納されている場合には、少なくとも前記開発内容ポイント、前記担当者判定ポイント及び前記障害判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する
請求項１に記載のソフトウェアの検査種別判定装置。
【請求項３】
前記記憶部は、前記担当者の開発に係るブランクに応じたブランク判定ポイントをさらに格納し、
前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記ブランク判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する
請求項１又は２に記載のソフトウェアの検査種別判定装置。
【請求項４】
前記記憶部は、前記ソフトウェアの開発規模に応じた開発規模判定ポイントをさらに格納し、
前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記開発規模判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する
請求項１から３の何れか１項に記載のソフトウェアの検査種別判定装置。
【請求項５】
前記検査は、前記ソフトウェアの開発の終了時に実施すべき品質検査と、前記ソフトウェアの公開時に実施すべき公開時検査との双方を含む
請求項１から４の何れか１項に記載のソフトウェアの検査種別判定装置。
【請求項６】
コンピュータを、
ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、
前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、
少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、
前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部と
を備えた装置として機能させるプログラム。
【請求項７】
前記コンピュータを、
前記記憶部が、前記担当者が開発したソフトウェアに係る障害が発生した場合に、該障害の規模に応じた障害判定ポイントをさらに格納し、
前記決定部が、前記記憶部に前記担当者の前記障害判定ポイントが格納されている場合には、少なくとも前記開発内容ポイント、前記担当者判定ポイント及び前記障害判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する
ように機能させる請求項６に記載のプログラム。
【請求項８】
前記コンピュータを、
前記記憶部が、前記担当者の開発に係るブランクに応じたブランク判定ポイントをさらに格納し、
前記決定部が、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記ブランク判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する
ように機能させる請求項６又は７に記載のプログラム。
【請求項９】
前記コンピュータを、
前記記憶部が、前記ソフトウェアの開発規模に応じた開発規模判定ポイントをさらに格納し、
前記決定部が、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記開発規模判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する
ように機能させる請求項６から８の何れか１項に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの検査種別判定装置に関する。
【背景技術】
【０００２】
インターネットサービスプロバイダは、ウェブサイトを通じて様々なサービスをユーザに提供している。サービスを提供するために、インターネットサービスプロバイダは様々なプログラム部品、プログラム部品が組み合わされたプログラムモジュール、データ、データ群、データ構造（以下、これらをまとめてソフトウェアと称する）を開発している。
【０００３】
新規、改良、改変に係るソフトウェアが開発された場合、そのソフトウェアが実際の運用において障害を発生させない状態となっているかを検査するために、そのソフトウェアの検査がインターネットサービスプロバイダ（開発者側）によって実施されている。
【０００４】
図１４は、ソフトウェアの検査の概要説明図である。開発の完了したソフトウェアに対しては、品質検査、公開時検査、障害時検査が実施される。品質検査は、開発の終了したソフトウェアに対して、当該ソフトウェアが障害発生の観点から適正な品質を有しているかの検査である。公開時検査は、ソフトウェアがユーザに対して公開され、そのソフトウェアを用いたサービス運用の開始直後に実施される、品質検査と内容の異なる検査である。障害時検査は、サービス運用上の障害が発生した場合に、その障害の要因となったソフトウェアを特定し、その障害の規模などが検査される。品質検査・公開時検査は、或るインターネットサービスプロバイダにおいては必ず実施されるものであるのに対し、障害時検査は、障害が発生した場合に限って実施される。
【０００５】
図１４において、開発担当者は、ソフトウェアの開発が終了すると、検査担当者に対して品質検査の依頼を行う。検査担当者は、開発担当者から開発状況のヒアリングを行うとともに、当該開発担当者について過去に実施された品質検査や公開時検査の結果の報告書、さらには、当該開発担当者が開発したソフトウェアが過去に運用上の障害要因となった場合にその障害状況の報告書などを用いて、今回の検査対象のソフトウェアに対する品質検査の種別を判定する。
【０００６】
品質検査は、主に検査工数の多寡によって、複数の検査種別に分類される。一般的に、ソフトウェアの開発過程における作り込み品質が良い場合には、品質検査や公開時検査、サービス監視での障害（不具合）がなく、高品質なサービスであり、品質検査や障害対応などに工数をかける必要がない。
【０００７】
これに対し、開発過程における作り込み品質が悪いと、品質検査時の障害発生件数の増加にともなう修正・対応工数の増加や公開時期の延期、また公開後の運用障害と、その障害対応に関わる工数の増大につながる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平９−２６５３９３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、品質検査種別を判定するにあたっては、以下の問題があった。すなわち、開発担当者からのヒアリングにおいて、開発担当者の説明不十分、或いは検査担当者の
ヒアリング不十分などによって、客観的に正確な情報を開発担当者から得ることができず、検査工数の少ない品質検査を行った結果、その後に検査がなされなかった部分で障害が発生することが起こりえる。また、検査結果報告や障害状況報告では、ヒアリングと同様に、十分な客観的・画一的な判断を以て検査種別を決定することができない場合があった。この場合、検査担当者は、障害発生を未然に防止する観点から、検査工数の多い品質検査種別を選択しやすい傾向にあった。検査工数の多い品質検査種別が実施されることで、障害発生の可能性の低減を図ることはできるものの、検査対象のソフトウェアの中には、少ない検査工数で済むものがあることも事実であり、そのようなソフトウェアに対して多大な検査工数を実施することは非効率であった。
【００１０】
本発明は、上記問題に鑑みなされたものであり、検査種別を客観的且つ画一的に判定して、適正な検査工数での検査を実施可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の態様の一つは、ソフトウェアを開発した担当者の品質ポイントと、前記ソフトウェアの開発工数の多寡及び開発の難易度の少なくとも一方に依存する開発内容ポイントとが格納された記憶部と、
前記品質ポイントを複数の担当者品質レベルの一つに応じた担当者判定ポイントに変換する変換部と、
少なくとも前記開発内容ポイントと前記担当者判定ポイントとの合計値に基づいて、前記ソフトウェアの障害発生の蓋然性が低い程、検査工数の少ない検査種別が選択されるように、検査工数の異なる複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する決定部と、
前記検査種別の検査の結果に応じて前記品質ポイントの値を更新する更新部と
を含むソフトウェアの検査種別判定装置である。
【００１２】
上記検査種別判定装置は、前記記憶部が、前記担当者が開発したソフトウェアに係る障害が発生した場合に、該障害の規模に応じた障害判定ポイントをさらに格納し、
前記決定部は、前記記憶部に前記担当者の前記障害判定ポイントが格納されている場合には、前記開発内容ポイント、前記担当者判定ポイント及び前記障害判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定するように構成することが可能である。
【００１３】
また、上記検査種別判定装置は、前記記憶部が、前記担当者の開発に係るブランクに応じたブランク判定ポイントをさらに格納し、
前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記ブランク判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する、ように構成することが可能である。
【００１４】
また、上記検査種別判定装置は、前記記憶部が、前記ソフトウェアの開発規模に応じた開発規模判定ポイントをさらに格納し、
前記決定部は、少なくとも前記開発内容ポイント、前記担当者判定ポイント、及び前記開発規模判定ポイントの合計値に基づいて、前記複数の検査種別から前記ソフトウェアの検査に適用すべき検査種別を決定する、ように構成することができる。
【００１５】
また、上記検査は、前記ソフトウェアの開発の終了時に実施すべき品質検査と、前記ソフトウェアの公開時に実施すべき公開時検査との双方を含むようにすることができる。
【００１６】
また、開発内容ポイントは、例えば、検査対象のソフトウェアの開発工数の多寡（開発規模）及び開発の難易度の少なくとも一方を確定するために用意された、回答選択式の複
数の設問に対し、前記担当者が各設問に対して選択した回答に予め付与されたポイントの合計値である。
【００１７】
本発明は、他の態様として、上記検査種別判定装置と同様の構成を有する検査種別判定方法、コンピュータを上記検査種別判定装置として機能させるプログラム、該プログラムを記録した記録媒体を含むことができる。
【発明の効果】
【００１８】
本発明によれば、検査種別を客観的且つ画一的に判定して、適正な検査工数での検査を実施することが可能となる。
【図面の簡単な説明】
【００１９】
【図１】図１は、本実施形態に係る品質検査工数の最適化支援システムが適用される品質検査の過程を模式的に示す図である。
【図２】図２は、支援システムを実現するために使用される情報処理装置の構成例を示す図である。
【図３】図３（Ａ）は、判定ポイントマスタテーブル２１のデータ構造例を示す図であり、図３（Ｂ）は、登録データテーブル２２のデータ構造例及び入力例を示す図であり、図３（Ｃ）は、担当者品質テーブル２３のデータ構造例を示す図である。
【図４】図４（Ａ）は、品質検査種別マスタテーブル２４のデータ構造例を示す図であり、図４（Ｂ）は、担当者情報マスタテーブルのデータ構造例を示す図であり、図４（Ｃ）は、障害規模−判定ポイントマスタテーブル２６のデータ構造例を示す図である。
【図５】図５は、ＣＰＵによって実行される品質検査判定処理の例を示すフローチャートである。
【図６】図６は、品質検査依頼の入力画面例を示す図である。
【図７】図７（Ａ）は、品質検査種別提示画面４１の表示例を示し、図７（Ｂ）は、検査種別に対する検査工数の相対値を示す表を示す。
【図８】図８は、品質検査（サービス公開直後の検査（公開時検査と呼ばれる）を含む）時における支援システムを実現する情報処理装置の動作例を示すフローチャートである。
【図９】図９は、開発されたサービス（ソフトウェア）の運用が開始された後に、当該サービスに係る障害が発生した場合における、支援システムを実現する情報処理装置の動作例を示すフローチャートである。
【図１０】図１０は、同一のサービスに関して、品質の異なる担当者が開発を行った場合における、品質検査判定処理の結果（検査種別）を示す表である。
【図１１】図１１は、異なるサービスについて、担当者が品質検査を初めて依頼する場合（担当者の品質が均一である場合）における、品質検査判定処理の結果（検査種別）を示す表である。
【図１２】図１２は、或る担当者が或るサービスの同一の開発内容について複数回の検査を受け、検査毎に担当者の品質が向上した場合における判定ポイント合計値の変遷を示す。
【図１３】図１３は、或る担当者が或るサービスの同一の開発内容について複数回の検査を受け、検査毎に担当者の品質が低下した場合における判定ポイント合計値の変遷を示す。
【図１４】図１４は、ソフトウェアの検査の概要説明図である。
【図１５】図１５は、実施形態２に係る品質検査工数の最適化支援システム（支援システム）が適用される品質検査の過程を模式的に示す図である。
【図１６】図１６（Ａ）は、実施形態２に係る登録データテーブル２２Ａのデータ構造例を示し、図１６（Ｂ）は、実施形態２に係る担当者品質テーブル２３Ａのデータ構造例を示す。
【図１７】図１７（Ａ）は、実施形態２に係る検査ブランクマスタテーブル２７のデータ構造例を示し、図１７（Ｂ）は、実施形態２に係る開発規模テーブル２８のデータ構造例を示す。
【図１８】図１８は、ＣＰＵによって実行される、実施形態２に係る品質検査判定処理及び品質検査種別提示処理（図１５、（２）及び（３））の例を示すフローチャートである。
【図１９】図１９は、ＣＰＵによる品質検査再判定処理及び品質検査種別提示処理の例を示すフローチャートである。
【図２０】図２０は、実施形態２における品質検査（サービス公開直後の検査（公開時検査と呼ばれる）を含む）時における支援システムを実現する情報処理装置（ＣＰＵ）の動作例を示すフローチャートである。
【図２１】図２１は、ブランクの長さと品質検査種別との関係を説明するための表を示す。
【図２２】図２２は、開発規模の大きさと品質検査種別との関係を説明するための表を示す。
【発明を実施するための形態】
【００２０】
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明の構成は実施形態の構成に限定されない。
【００２１】
〔実施形態１〕
＜品質検査に係る過程＞
図１は、実施形態１に係る品質検査工数の最適化支援システム（以下、支援システムと称する）が適用される品質検査の過程を模式的に示す図である。品質検査の対象は、ウェブブラウザを通じてユーザに提供される様々なウェブサービスを実現するためのソフトウェアである。ソフトウェアは、プログラム部品、プログラム部品を組み合わせたプログラムモジュール，データ（例えばウェブページ）又はデータ群，データ群を格納するデータ構造を含む。ソフトウェアは、当該ソフトウェアを用いてユーザに提供される「サービス」の単位で管理される。以下、検査対象を特定する単位として「サービス」と表記することもある。
【００２２】
最初に、開発の担当者によるサービス（ソフトウェア）の開発（制作）が完了すると、そのサービス（ソフトウェア）が、所望の品質を有しているか否かを検査するため品質検査が依頼される（図１（１））。
【００２３】
品質検査が依頼されると、品質検査判定が行われる。品質検査判定では、品質検査対象のソフトウェアについて実施すべき品質検査種別が判定される（図１（２））。品質検査は、開発されたソフトウェアが所望の品質を有するか否かを判定するための複数の検査工数（検査項目）からなる。品質検査は、ソフトウェアの信頼性（完成度）に応じて用意された複数の種別（クラス）に分類され、種別毎に１以上の検査工数（検査項目）が用意される。ソフトウェアの信頼性が高い程、検査工数の少ない種別が割り当てられる。
【００２４】
品質検査種別が決定されると、その品質検査種別が提示される（図１（３））。このとき、品質検査不要との判定結果が出されるようにすることもできる。品質検査種別が提示されると、当該種別に応じた品質検査が検査対象のソフトウェアに対して実施される（図１（４））。品質検査の終了したソフトウェアに基づくサービスは、ユーザに対して公開され、リリース（運用）される（図１（５））。公開が決定されたソフトウェアに対しては、品質検査と異なる検査項目を有する公開時検査が実施される。公開後の運用において、当該ソフトウェアに基づくサービスに障害が発生した場合には、障害状況が検査される。以上のように、開発されたソフトウェアに対する品質検査（広義）として、品質検査（
狭義）、公開時検査、障害時検査の各検査が実施される。
【００２５】
一般に、ソフトウェア開発には、品質リスクが伴う。品質リスクとは、ソフトウェアの作り込みの程度に依存する障害発生のリスクである。作り込みが甘い場合には、障害発生の可能性が高く、品質検査において、網羅的な多数の検査工数を実施することが要求される。これに対し、作り込みが好適に行われている場合には、品質検査において、最小限の検査工数とすることが可能である。
【００２６】
障害発生を零にしようとする見地からは、開発される総てのソフトウェアに対して、網羅的な品質検査を実施することが望まれる。しかしながら、好適な作り込みがなされている蓋然性の高いソフトウェアについてまで網羅的な品質検査を実施することは、無駄な検査をすることに繋がり、非効率である。
【００２７】
本実施形態に係る支援システムは、担当者の品質を数値化した品質ポイント、ソフトウェアの開発内容を数値化した開発内容ポイントなどを格納したデータベース（ＤＢ）を有しており、品質検査判定（図１（２））において、ＤＢに蓄積されたポイントを用い、画一的な判断手法で検査対象のソフトウェアに対する品質検査種別を自動的に算出する。
【００２８】
ＤＢに蓄積される品質ポイントには、上述した品質検査の検査結果が反映される。また、障害発生時の障害状況が障害判定ポイントとして数値化され、品質検査種別の判定における判定ロジックに組み込まれる（図１＜１＞、＜２＞）。このように、ソフトウェアの開発担当者の過去の実績が反映されたＤＢを用い、当該担当者により作製されたソフトウェアの信頼性（完成度）を予測し、品質検査種別が決定される。
【００２９】
これによって、過去に信頼性の低い（品質検査（狭義）の結果が良くない、或いは障害が生じた）ソフトウェアを開発した担当者のソフトウェアに対しては、検査工数の多い品質検査種別が決定される。
【００３０】
これに対し、信頼性の高い（良好な品質検査（狭義）結果を得た）開発担当者のソフトウェアについては、検査工数の少ない品質検査種別が決定される。このようにして、品質検査対象のソフトウェアに対して、適正な工数の品質検査を実施可能とすることによって、効率的な品質検査を実施することが可能となる。
【００３１】
また、従来では、品質検査判定に当たり利用されていた開発担当者からのヒアリング内容や、検査結果、障害状況報告などが、客観的なポイントに置き換えられ、開発担当者の恣意や、検査担当者の解釈などが可能な限り排除されるようになっている。そして、品質検査判定が支援システムを用いた画一的な判定ロジックを用いて実行されることで、画一的且つ客観的な品質種別判定を行うことができ、適正な検査工数の品質検査を実施でき、効率化を図ることができる。以下、支援システムの詳細について説明する。
【００３２】
＜情報処理装置の構成＞
図２は、支援システムを実現するために使用される情報処理装置の構成例を示す図である。図２に示す情報処理装置１０は、例えばパーソナルコンピュータである。但し、専用又は汎用のコンピュータを用いることが可能である。
【００３３】
図２において、情報処理装置１０は、バスＢを介して相互に接続されたＣＰＵ１（プロセッサ）と、主記憶装置２と、記憶部としての補助記憶装置３と、通信インタフェース（通信Ｉ／Ｆ）４と、入力装置５と、表示装置６と、プリンタ７とを備えている。
【００３４】
補助記憶装置３は、例えばハードディスク（ＨＤＤ）のようなコンピュータ読み取り可
能な記録媒体であり、支援システムを実現するための１以上のコンピュータプログラムがインストールされている。また、補助記憶装置３には、支援システムを実現するためのプログラムの実行に際して使用されるデータが格納されたデータベース（ＤＢ）が格納されている。また、補助記憶装置３には、品質検査を実施する検査システム（後述）を実現するための１以上のプログラムがインストールされており、当該プログラムの実行に際して使用されるデータ群を格納している。
【００３５】
なお、補助記憶装置３として、ＨＤＤのような固定ディスクの他、フラッシュメモリのような可搬性を有する記憶装置を適用することができる。或いは、補助記憶装置３として、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）を適用する
ことも可能である。
【００３６】
通信Ｉ／Ｆ４は、例えばＬＡＮ（構内交換網）ボードであり、ネットワークを介して接続された他の情報処理装置（コンピュータ）と通信を行う。これによって、補助記憶装置３に格納された情報を他の情報処理装置に送信したり、他の情報処理装置から受信された情報を補助記憶装置３で保存したりすることができる。
【００３７】
入力装置５は、情報処理装置１０のオペレータが、各種の情報を情報処理装置１０に入力するための装置であり、例えば、キーボードや、マウスのようなポインティングデバイスを含む。
【００３８】
表示装置６は、ＣＰＵ１による処理結果に基づく情報を表示するディスプレイ装置である。プリンタ７は、表示装置に表示された表示内容をシートに印刷する印刷装置である。
【００３９】
ＣＰＵ１は、補助記憶装置３に格納されたプログラムを主記憶装置２にロードして実行することにより、支援システムとしての機能を実現する。主記憶装置２は、例えばＲＡＭ（Read Only Memory）のようなコンピュータ読み取り可能な記録媒体であり、ＣＰＵ１の作業領域として使用される。情報処理装置１０のＣＰＵ１がプログラム実行によって支援システムを実現することにより、情報処理装置１０は、本発明に係る記憶部，変換部，決定部，及び更新部を少なくとも備える検査種別判定装置として機能する。
【００４０】
＜テーブルの構成＞
次に、図２に示した補助記憶装置３に格納されたＤＢに含まれるテーブル群について説明する。ＤＢは、判定ポイントマスタテーブルと、登録データテーブルと、担当者品質テーブルとを含む。ＤＢは、さらに、品質検査種別マスタテーブルと、担当者情報マスタテーブルと、障害規模−判定ポイントマスタテーブルとを含む。
【００４１】
図３（Ａ）は、判定ポイントマスタテーブル２１のデータ構造例を示す図であり、図３（Ｂ）は、登録データテーブル２２のデータ構造例及び入力例を示す図であり、図３（Ｃ）は、担当者品質テーブル２３のデータ構造例を示す図である。
【００４２】
判定ポイントマスタテーブル２１は、検査対象のソフトウェアに対する品質検査（狭義）に当たり、検査対象のソフトウェア（サービス）の開発規模や開発難易度を確定するために予め用意された複数の設問と、設問に対する回答に対して予め規定されたポイントが登録されている。図３（Ａ）に示す例では、各設問に対して回答ｘ，ｙ，ｚが用意されており、各回答ｘ，ｙ，ｚに対するポイントが登録されている。
【００４３】
登録データテーブル２２には、サービス名（ソフトウェアを用いて提供されるサービス名）と、そのサービスに係るソフトウェアを開発した担当者名と、品質検査に当たって提供される設問の回答内容に応じたポイントが、サービス名且つ担当者毎に登録される。な
お、図３（Ｂ）に示す例では、設問４〜設問９に対する欄の図示が省略されている。
【００４４】
登録データテーブル２２に登録される設問の回答に応じたポイントの合計値は、開発対象のソフトウェア（サービス）の開発の難易度や、開発工数の規模（多寡）を示すものであり、開発内容ポイントと称する。開発工数が多い、或いは開発の難易度が高い（障害発生の可能性の高い）開発が含まれていれば、開発内容ポイントは大きくなり、検査工数が多い検査種別が決定される方向に作用する。逆に、開発規模が小さい、或いは開発の難易度が低い（障害発生の可能性が低い）開発であれば、開発内容ポイントは小さくなり、検査工数の少ない検査種別が決定される方向に作用する。
【００４５】
担当者品質テーブル２３には、担当者毎に、品質ポイントと、検査実施回数と、障害判定ポイントとが登録される。品質ポイントは、担当者が作製したソフトウェアの品質を数値化したものであり、品質ポイントが小さい程、担当者が品質の良い（障害の起こらない）ソフトウェア（サービス）を開発することを示す。検査実施回数は、当該担当者に対して実施された品質検査（狭義）の回数を示す。障害判定ポイントは、当該担当者によって開発されたソフトウェア（サービス）が障害を引き起こした場合に付与されるポイント（数値）である。障害判定ポイントが大きい程、過去に生じた障害規模が大きい、或いは、複数回の障害を発生させたことを示す。
【００４６】
図４（Ａ）は、品質検査種別マスタテーブル２４のデータ構造例を示す図であり、図４（Ｂ）は、担当者情報マスタテーブルのデータ構造例を示す図であり、図４（Ｃ）は、障害規模−判定ポイントマスタテーブル２６のデータ構造例を示す図である。
【００４７】
品質検査種別マスタテーブル２４は、品質検査種別（検査方法）と、判定ポイントとの関係を定義したテーブルである。図４（Ａ）の例では、検査方法として、Ａ〜Ｄ検査と、“検査なし”とが定義されており、Ａ〜Ｄ検査及び“検査なし”の夫々に対応する判定ポイントの数値範囲が登録されている。
【００４８】
具体的には、判定ポイントの合計値ａが３００以上であれば、Ａ検査が決定される。判定ポイントの合計値ａが１００以上３００未満であれば、Ｂ検査が決定される。判定ポイントの合計値ａが５０以上１００未満であれば、Ｃ検査が決定される。判定ポイントの合計値ａが１０以上５０未満であれば、Ｄ検査が決定される。判定ポイントの合計値ａが１０未満であれば、“検査なし”が決定される。なお、検査種別（検査方法）の数は適宜設定可能である。また、判定ポイント合計値の数値範囲も適宜設定可能である。
【００４９】
担当者情報マスタテーブル２５は、担当者品質と、担当者品質に応じた品質ポイントｂの数値範囲と、担当者品質に応じた担当者判定ポイントとが登録されている。図４（Ｂ）に示す例では、担当者品質のクラスが、“良い”，“普通”，“悪い”の３種類に区分されている。品質ポイントが８５を上回り且つ１００以下であれば、担当者品質“良い”に区分される。品質ポイントが５０を上回り且つ８５以下であれば、担当者品質“普通”に区分される。品質ポイントが５０以下であれば、担当者品質“悪い”に区分される。そして、“良い”，“普通”，“悪い”の夫々に区分される担当者について、担当者判定ポイント“−１２０”，“−７０”，“−２０”が夫々付与される。なお、担当者品質のクラス数、品質ポイントの数値範囲、担当者判定ポイントは適宜設定可能である。
【００５０】
また、担当者情報マスタテーブル２５は、或る担当者についての品質検査が初めてである（初めての品質検査依頼である）場合に、当該担当者に付与される品質ポイント及び担当者判定ポイントとして、“なし”及び“０”を格納している。
【００５１】
障害規模−判定ポイントマスタテーブル２６は、障害規模と障害判定ポイントとが定義
されたテーブルである。図４（Ｃ）に示す例では、障害規模は、“大”，“中”，“小”の３つに区分され、各障害規模に対して障害判定ポイント“１０”，“７”，“３”が定義されている。障害規模の数及び障害判定ポイントは適宜設定可能である。
【００５２】
＜動作例＞
次に、支援システムを実現する情報処理装置１０（図２）の動作例について説明する。開発担当者は、ソフトウェアの開発が終了すると、品質検査を依頼すべく、情報処理装置１０の入力装置５を操作して、支援システムを実行するプログラム（支援プログラムと称する）の実行開始指示を入力する。すると、ＣＰＵ１が補助記憶装置３に格納された支援プログラムを主記憶装置２にロードし、当該支援プログラムの実行を開始する。
【００５３】
＜＜品質検査依頼時の動作＞＞
図５は、ＣＰＵ１によって実行される品質検査判定処理の例を示すフローチャートである。支援プログラムの実行が開始されると、ＣＰＵ１は、表示装置６を制御して、品質検査依頼の入力画面３１を情報処理装置１０の表示装置６（図２）に表示する（図５，ステップＳ１）。
【００５４】
図６は、品質検査依頼の入力画面例を示す図である。図６において、入力画面３１は、基本情報入力欄と、検査種別判定情報入力欄とを備えている。図６に示す例では、基本入力欄には、サービス名と、登録者の入力欄が設けられている。
【００５５】
サービス名は、開発担当者が開発を行ったサービス（ソフトウェア）の名称が入力される。登録者として、開発担当者の氏名が入力される。このとき、氏名とともに、担当者の所属部署を記入することもできる。また、基本情報として入力が要求される情報項目として、検査対象特定情報（サービス名）及び担当者特定情報（登録者名）は必須である。もっとも、検査対象特定情報及び担当者特定情報の情報自体はこれらを特定するためのコードであっても良い。また、基本情報として、検査対象特定情報及び担当者特定情報以外の情報入力が求められるようにしても良い。
【００５６】
検査種別判定情報入力欄には、検査種別を判定するための複数の設問が用意されており、設問に対する回答を入力するためのラジオボタンが設問毎に用意されている。図６の例では、検査種別判定情報は、開発担当者の開発規模や開発の難易度（開発内容）を確定するための情報であり、サービス区分，機能，開発種別，サイトの各項目からなり、各項目について１以上の設問が用意され、全部で９個の設問が用意されている。なお、本実施形態では、９個の設問の総てが必須入力事項である例を示しているが、検査種別判定情報の項目、各項目に対する設問の数や内容は適宜設定可能である。
【００５７】
基本情報入力欄及び検査種別判定情報の夫々の近傍には、確認ボタンが用意されている。基本情報入力欄に対応する確認ボタンが押されると、例えば、ＣＰＵ１は、補助記憶装置３上のＤＢに予め格納されているサービス名や登録者名を検索し、マッチングを行う。このとき、ＤＢから入力されたサービス名や登録者名が検索されなかった場合には、入力エラーとして、適正なサービス名や登録者名の入力を求める表示が入力画面３１に表示される。
【００５８】
検査種別判定情報入力欄に対応する確認ボタンが押されると、ＣＰＵ１は、検査種別判定情報入力欄に対する入力漏れをチェックし、入力漏れがある場合には、入力漏れがあることを報知する表示を入力画面３１に表示し、入力を促すことができる。
【００５９】
開発担当者は、入力装置５を操作し、入力画面３１に対して各種情報を入力し、確認ボタンを押す。すると、品質検査判定処理が開始される。なお、上記説明では、開発担当者
本人が情報の入力作業を行っているが、他の者が開発担当者から得た情報を元に入力作業を行うようにしても良い。
【００６０】
入力画面３１に対する適正な情報入力がなされ、ステップＳ１の処理が終了すると、ＣＰＵ１は、処理をステップＳ２に進め、判定ポイント集計処理を実行する。すなわち、ＣＰＵ１は、補助記憶装置３に格納されている担当者品質テーブル２３（図３（Ｃ））を参照し、入力画面３１に入力された担当者（登録者）のレコードを検索する。このとき、該当する担当者のレコードがヒットすれば、ＣＰＵ１は、当該レコード中の品質ポイント（ｂ）及び障害判定ポイントを抽出する。
【００６１】
これに対し、担当者品質テーブル２３に該当する担当者（登録者）がなければ、当該担当者（登録者）に係るレコードが新たに登録される。レコードの初期値として、品質ポイント“０”，検査実施回数“０”，及び障害判定ポイント“０”が登録される。もっとも、担当者品質テーブル２３に対し支援システムを利用する総ての開発担当者のレコードを予め登録しておいても良い。この場合、入力画面３１に入力された登録者（担当者）のレコードが必ずヒットする。
【００６２】
続いて、ＣＰＵ１は、担当者情報マスタテーブル２５（図４（Ｂ））を参照し、担当者品質テーブル２３から得られた品質ポイント（ｂ）が合致する担当者品質を割り出し、割り出した担当者品質に対応する担当者判定ポイントを読み出す。すなわち、品質ポイントが、複数の担当者品質レベル（良い・普通・悪い）の一つに応じた担当者判定ポイントに変換される。本実施形態では、担当者判定ポイントは、マイナスの値であり、後述する検査種別判定において、担当者判定ポイントが小さい（低い）程、検査工数の少ない検査種別が判定されるようにしている。なお、担当者品質テーブル２３の検査実施回数が“０”の場合には、ＣＰＵ１は、担当者情報マスタテーブル２５から担当者判定ポイント“０”を読み出す。ＣＰＵ１は、読み出した担当者判定ポイントを主記憶装置２の作業領域にストアする。
【００６３】
次に、ＣＰＵ１は、判定ポイントマスタテーブル２１（図３（Ａ））を参照し、入力画面３１に入力された各設問の回答に対応するポイントを読み出して、登録データテーブル２２（図３（Ｂ））への登録処理を行う。
【００６４】
すなわち、ＣＰＵ１は、登録データテーブル２２からサービス名及び担当者名が一致するレコードを検索し、該当するレコードがあれば、判定ポイントマスタテーブルから読み出した設問１〜９の回答に対応するポイントを登録する。該当するレコードがない場合には、ＣＰＵ１は、登録データテーブル２２にサービス名及び担当者名でインデックスされる新たなレコードを作成し、当該レコード中に設問１〜９の回答に対応するポイントを登録する。ＣＰＵ１は、登録データテーブル２２に登録した設問１〜９への回答に対するポイントを、主記憶装置２の作業領域にストアする。
【００６５】
そして、ＣＰＵ１は、以下の計算式に基づき判定ポイント合計値（ａ）を加算方式で算出する。下記計算式の括弧内の合計値は、開発内容ポイントを示す。
【００６６】
[計算式] 判定ポイント合計値（ａ）＝担当者判定ポイント＋障害判定ポイント＋（設
問１〜９の各回答ポイントの合計値）
以上のようにして、判定ポイントの合計値を算出すると、ＣＰＵ１は、ステップＳ２の判定ポイント集計処理を終了する。なお、上記した担当者品質テーブル２３と判定ポイントマスタテーブル２１の参照順は逆であっても良く、登録データテーブル２２への登録処理と担当者情報マスタテーブル２５の参照処理との順序は逆であっても良い。
【００６７】
次に、ＣＰＵ１は、処理をステップＳ３に進めて品質検査種別判定処理を実行する。すなわち、ＣＰＵ１は、品質検査種別マスタテーブル２４（図４（Ａ））を参照し、判定ポイント合計値（ａ）に合致する、すなわち判定ポイント合計値（ａ）が数値範囲に収まる検査方法を読み出し、読み出された検査方法を、今回依頼された品質検査に適用する検査方法（検査種別）として決定する。
【００６８】
次に、ＣＰＵ１は、処理をステップ４に進めて品質検査種別提示処理を実行する。すなわち、ＣＰＵ１は、表示装置６を制御し、ステップＳ３で決定した検査方法を示す品質検査種別提示画面４１を表示装置６に表示する。
【００６９】
図７（Ａ）は、品質検査種別提示画面４１の表示例を示し、図７（Ｂ）は、検査種別に対する検査工数の相対値を示す表を示す。図７（Ａ）に示すように、品質検査種別提示画面４１には、決定された検査方法（図の例では“Ｂ検査”）が画面４１の上段に表示される。また、画面４１の下段には、各検査方法に合致する提出資料を確認するためのハイパーリンクが表示される。開発担当者は、リンク先の情報を参照して、品質検査に際しての提出資料を確認し、資料を提出することになる。
【００７０】
なお、図７（Ｂ）に示すように、検査方法（検査種別）は、Ａ検査の検査工数が最も多く、開発されたサービス（ソフトウェア）に対する品質リスクが最も大きい（障害発生の蓋然性が高い）場合に実施される。以下、Ｂ検査、Ｃ検査は、Ｄ検査と、品質リスクの大きさに準じて検査レベルが下がり、検査工数が削減されている。さらに、品質リスクが殆どない（障害発生の蓋然性が殆どない）場合には、検査工数“０”，すなわち“検査なし”が決定される。このように、品質リスクに応じた品質検査種別（検査方法）が決定されることで、無駄な検査工数が実施されるのを防止し、品質検査の効率化が図られる。
【００７１】
＜＜品質検査時＞＞
図８は、品質検査（サービス公開直後の検査（公開時検査と呼ばれる）を含む）時における支援システムを実現する情報処理装置１０（ＣＰＵ１）の動作例を示すフローチャートである。図８に示す処理が開始されると、ＣＰＵ１は、品質検査判定処理にて決定された検査方法での品質検査、及び公開時検査の依頼を、検査システムに渡す（ステップＳ０１）。品質検査と公開時検査とは内容が全く別個の独立した検査である。
【００７２】
検査システムは、支援システムから独立した別個のシステムである。検査システムは、プログラムがＣＰＵのようなプロセッサによって実行されることにより実現される機能であり、本実施形態では、情報処理装置１０が検査システムを実現するためのプログラムを実行することによって検査システムとして機能する。但し、検査システムとしての処理は、情報処理装置１０と異なる他のコンピュータが実施することもでき、例えば、情報処理装置１０が、通信回線を介して接続された他のコンピュータが有する検査システムに対して品質検査及び公開時検査を依頼し、当該他のコンピュータから品質検査及び公開時検査の結果（品質ポイント及び平均品質ポイント（後述））を受信するようにしても良い。以下、検査システムが情報処理装置１０によって実施される例について説明する。
【００７３】
ＣＰＵ１は、品質検査及び公開時検査の依頼に当たって、検査システムを実現するプログラムの実行を開始する。当該プログラムの実行によって生成される検査システムのプロセスに対し、品質検査の検査種別と、公開時検査の依頼と、登録データテーブル２２（図３（Ｂ））のサービス名とを渡す。
【００７４】
検査システムは、検査方法に応じた品質検査、及び公開時検査を実施する（ステップＳ０２）。検査の実施に当たって、検査方法に応じた提出資料を使用する。提出資料のデータは、予め情報処理装置１０に格納される。そして、品質検査及び公開時検査に対する結
果の報告件数・報告の内容・報告分類などを元に「品質ポイント」を算出する。報告件数、報告の内容、報告分類は予め決められた数値化方法で数値化（ポイント化）され、数値化された報告件数、報告内容、報告分類を所定の品質ポイント算出式に代入することで、品質ポイントを算出する。
【００７５】
さらに、検査システムは、品質検査や公開時検査の実施により算出された品質ポイントを検査終了時の時間情報ととともに補助記憶装置３の所定領域に蓄積している。検査システムは、今回の品質検査及び公開時検査の終了時点から過去に遡った特定期間内における総ての品質検査及び公開時検査に対する品質ポイントを抽出し、特定期間中の「平均品質ポイント」を算出する。
【００７６】
そして、検査システムは、サービス名とともに、品質検査及び公開時検査によって得られた「品質ポイント（ｂ）」と、「平均品質ポイント」とを支援システムに結果として返す。
【００７７】
すると、ＣＰＵ１は、支援プログラムによる処理を再開し、登録データテーブル２２を参照して、サービス名が合致するレコードから担当者名を抽出する。続いて、ＣＰＵ１は、担当者品質テーブル２５（図４（Ｂ））を担当者名でインデックスし、該当するレコード中の品質ポイント（担当者品質テーブル．品質ポイント）を取得する（ステップＳ０３）。
【００７８】
続いて、ＣＰＵ１は、以下の式を用いて、更新に係る品質ポイントの値を算出する。すなわち、検査システムから得られた平均品質ポイントから品質ポイントを減じた値と、現在の担当者品質テーブルの品質ポイントとを加算する。
【００７９】
[式] 担当者品質テーブル．品質ポイント＝担当者品質テーブル．品質ポイント＋（平
均品質ポイント−品質ポイント）
続いて、ＣＰＵ１は、担当者品質テーブル２３の品質ポイントを、ステップＳ０３で与えられた品質ポイントで更新（上書き）する。また、ＣＰＵ１は、担当者品質テーブル２３の検査実施回数に１を加える。
【００８０】
上記した品質ポイントの更新により、今回の品質検査及び公開時検査によって得られた品質ポイントが特定期間内の平均品質ポイントを上回る場合には、更新される品質ポイントの値は上昇することになり、当該担当者の品質リスクが低減される。これに対し、今回の検査によって得られた品質ポイントが平均ポイントを下回る場合には、更新される品質ポイントの値は下降することになり、当該担当者の品質リスクが上昇する。
【００８１】
なお、上述した例では、公開時検査が必須であり、品質検査と公開時検査とが同時に行われる例について説明したが、品質検査と公開時検査とが時間を空けて実施される場合には、品質検査と公開時検査との一方に係るステップＳ０１〜Ｓ０５の処理が実行され、品質ポイントの更新及び検査実施回数の更新が行われるようにしても良い。また、品質検査と公開時検査との一方のみを実施する運用がなされる場合にも、品質検査と公開時検査との一方に係るステップＳ０１〜Ｓ０５の処理が実行されるようにすることが可能である。
【００８２】
＜＜運用時（障害発生時）＞＞
図９は、開発されたサービス（ソフトウェア）の運用が開始された後に、当該サービスに係る障害が発生した場合における、支援システムを実現する情報処理装置１０（ＣＰＵ１）の動作例を示すフローチャートである。
【００８３】
図９に示す処理は、例えば、表示装置６に障害規模の入力画面（図示せず）が表示され
、オペレータが入力装置５の操作によって、担当者名（登録者名）と、発生した障害規模（“大”，“中”，“小”）を入力することによって開始される。
【００８４】
障害規模が入力されると、ＣＰＵ１は、障害規模−判定ポイントテーブル２６（図４（Ｃ））を参照して、入力された障害規模に応じた障害判定ポイントを読み出す（ステップＳ１１）。
【００８５】
次に、ＣＰＵ１は、担当者品質テーブル２３（図３（Ｃ））を参照し、担当者品質テーブル２３中に、入力された担当者名のレコードがあるか否かを判定する（ステップＳ１２）。このとき、該当レコードがあれば、処理がステップＳ１４に進む。これに対し、該当レコードがなければ、ＣＰＵ１は、担当者品質テーブル２３に当該担当者のレコードを追加し（ステップＳ１３）、処理をステップＳ１４に進める。なお、ステップＳ１３で追加されるレコード中の障害判定ポイントの初期値として“０”が設定される。
【００８６】
ステップＳ１４では、ＣＰＵ１は、担当者品質テーブル２３中の障害判定ポイントの値に、ステップＳ１１で読み出された障害判定ポイントを加算する。続いて、ＣＰＵ１は、上記加算によって得られた新たな障害判定ポイントで担当者品質テーブル２３の当該担当者の障害判定ポイントの値を更新（上書き）する（ステップＳ１５）。このように、障害が発生した場合には、その障害が発生したサービスの開発担当者に対し、障害規模に応じた障害判定ポイントが加算される。障害判定ポイントは累積的に蓄積されるため、障害を発生させた回数が多い程、判定ポイント合計値が大きくなる方向に作用する。
【００８７】
＜支援システムの使用例＞
次に、上述した支援システムを用いて得られる検査種別の判定結果、及び判定ポイントの変遷の例について説明する。
【００８８】
図１０は、同一のサービス（サービス名：サービスＡ）に関して、品質の異なる担当者が開発を行った場合における、品質検査判定処理の結果（検査種別）を示す表である。図１０の表において、担当者の品質として、悪い場合（担当者判定ポイント：−２０）、普通の場合（担当者判定ポイント：−７０）、及び良い場合（担当者判定ポイント：−１２０）を示している。また、図１０の表において、設問１〜９の内容は、図６に示した入力画面３１に示された設問１〜９に相当し、回答に対するポイントは、図３（Ａ）に示した判定ポイントマスタテーブル２１の内容に合致する。
【００８９】
設問１〜９の回答に対するポイントが担当者間で同じであった場合、判定ポイントの合計値（ａ）は、夫々“１４０”，“９０”，“４０”となる。よって、品質の悪い担当者についてはＢ検査の実施が決定され、品質が普通の担当者についてはＣ検査の実施が決定され、品質が良い担当者についてＤ検査の実施が決定される。
【００９０】
このように、支援システムによる品質検査判定処理によれば、担当者の品質に応じた検査工数の検査種別の実施が決定されるようにすることができる。
【００９１】
図１１は、異なるサービス（サービスＡ〜Ｅ）について、担当者が品質検査を始めて依頼する場合（担当者の品質が均一である場合）における、品質検査判定処理の結果（検査種別）を示す表である。また、図１１の表において、設問１〜９の内容は、図６に示した入力画面３１に示された設問１〜９に相当し、回答に対するポイントは、図３（Ａ）に示した判定ポイントマスタテーブル２１の内容に合致する。
【００９２】
サービスＡは、完全な新規サービスの場合である（設問１〜９に対する回答が総て回答ｘ）。新規サービスの開発は、既存サービスの改良に比べて障害が生じる可能性が高く、
障害発生箇所の予測が難しい。このため、網羅的な検査が必要となるので、質問に対するポイント加算の結果、最高レベルのＡ検査が検査種別として決定されるような判定ポイントが算出されるようになっている。
【００９３】
サービスＢは、既存機能の追加を行い（設問３の回答ｘ）、更に設問４〜９に対して回答ｘが選択された場合を示す。この場合、新規サービス程の検査工数は要しないものの、変更又は新規追加に係る開発工数が多いため、検査工数がＡ検査より１レベル低いＢ検査が検査種別として決定される。
【００９４】
サービスＣは、設問３，６〜９に対して回答ｘが選択され、且つ設問１，２，４，５に対して回答ｙが選択された場合の例を示す。この場合、既存機能の追加ではあるが、サイト構成やＵＩ（ユーザ・インタフェース）の変更はなく、既存テンプレートを用いている。このため、障害発生の可能性はサービスＢに比べて低いと考えられる。よって、検査工数がサービスＢより低いＣ検査が検査種別として決定される。
【００９５】
サービスＤは、既存テンプレートを使用した動的ページの改変に係る開発である。動的ページは、静的ページに比べて障害発生の可能性が高い。このため、検査工数が最低であるが、品質検査を実施する必要があると考えられる。よって、検査工数が最低のＤ検査が検査種別として決定される。
【００９６】
サービスＥは、既存テンプレートを使用した２０ページ未満の静的ページの追加に係る開発である。この場合、障害は殆ど発生しないと考えられる。よって、検査種別として、“検査なし”が決定される。
【００９７】
図１２は、或る担当者（担当者Ａ）が或るサービス（サービスＡ）の同一の開発内容について複数回の検査を受け、検査毎に担当者の品質が向上した場合における判定ポイント合計値の変遷を示す。
【００９８】
図１２において、１回目の検査では、品質ポイントが“０”のため、検査種別はＢ検査となるが、品質検査の結果が平均を上回れば、品質ポイントが加算されるため、２回目の検査依頼時における品質ポイントは１回目よりも大きくなる。このため、２回目の品質検査では、判定ポイント合計値が減少し、検査工数がＢ検査より少ないＣ検査となる。さらに、２回目の品質検査で平均を上回る結果が得られれば、品質ポイント値がさらに上昇するので、３回目の品質検査では、判定ポイント合計値がさらに減少し、Ｃ検査よりさらに検査工数の少ないＤ検査となる。
【００９９】
このように、支援システムによれば、担当者が品質の良い開発を続ける限り、品質ポイントが上昇し、判定ポイント合計値が減少するので、当該担当者の開発に係る検査工数は検査毎に減り、効率的な品質検査の実施が可能となる。
【０１００】
図１３は、或る担当者（担当者Ａ）が或るサービス（サービスＡ）の同一の開発内容について複数回の検査を受け、検査毎に担当者の品質が低下した場合における判定ポイント合計値の変遷を示す。
【０１０１】
図１３において、１回目の検査では、品質ポイントが“−１２０”のため、検査種別はＤ検査となる。しかし、品質検査の結果が平均を下回れば、品質ポイントが減算されるため、２回目の品質検査依頼時における品質ポイントは１回目よりも小さくなる。このため、２回目の品質検査では、判定ポイント合計値が増加し、検査工数がＤ検査より多いＣ検査となる。さらに、２回目の品質検査で平均を下回る結果となれば、品質ポイント値がさらに下降するので、３回目の品質検査では、判定ポイント合計値がさらに減少し、Ｂ検査
となる。
【０１０２】
このように、支援システムによれば、担当者が品質の悪い開発を続ければ、品質ポイントが下降し続けるので、それに応じてレベルの高い検査種別が判定結果として示されるようになる。従って、各担当者の検査種別の判定結果を継続的に監視すれば、担当者がどのような品質の開発を行っているかを知ることができる。
【０１０３】
以上説明した実施形態に係る品質検査工数最適化の支援システムによれば、担当者の過去に実施された検査結果に応じた品質ポイントが担当者の品質ポイントに反映（フィードバック）され、次の検査における検査種別（検査工数）の判定結果は、品質ポイントの大きさに大きく依存する。すなわち、担当者の品質が良ければ品質ポイントが上昇し、悪ければ品質ポイントが下降する。検査システムは、品質検査及び公開時検査について、担当者間且つサービス間で同一の論理（判定ロジック）で品質ポイント及び平均ポイントを算出するようになっている。このため、検査結果に応じて反映される品質ポイントには客観性が担保されている。
【０１０４】
また、担当者が開発したサービスが障害を引き起こした場合には、その障害規模に応じた障害判定ポイントが担当者に付与され、検査種別の判定において検査工数を多くする方向に作用する。
【０１０５】
また、品質検査依頼時の設問として、開発規模の大きさ（開発内容）を特定するための複数の設問が回答選択形式で提供されるので、開発規模や開発の難易度を客観的且つ画一的にポイントとして数値化でき、検査種別の判定ポイントに反映することができる。
【０１０６】
よって、支援システムによれば、客観性が担保された判定ポイント合計値を以て品質検査の検査種別が判定される。これによって、担当者に応じた適正な検査工数を有する検査種別での品質検査を実施することができ、品質検査の効率化が図られる。
【０１０７】
〔実施形態２〕
次に、本発明の実施形態２について説明する。実施形態２は、実施形態１と共通点を含むため、主として相違点について説明し、共通する構成については同一の符号を付して説明を省略する。
【０１０８】
実施形態１では、品質検査の実施に当たり、品質検査の受け付け時に品質リスクを考慮する一方で、ソフトウェアの開発（制作）担当者の過去の実績データに基づき、適正な品質検査方法が提示される。
【０１０９】
しかしながら、開発担当者の習熟度、及び開発・改修規模に対する考慮をさらに進める余地があった。また、品質検査受け付け後における開発の状況変化に応じた品質検査方法の見直しに対し、十分に考慮が払われているとは言えない。
【０１１０】
品質検査に要求される作業時間を短縮するには、予測される品質リスクの大小に加え、開発担当者の習熟度、開発・改修の規模、及び品質検査受け付け後の状況変化に応じて、適正な品質検査方法が提示されることが望ましい。
【０１１１】
実施形態２に係る支援システムでは、実施形態１に比べて、開発担当者の習熟度や開発・改修規模に対する考慮が深められている。また、品質検査の受け付け後における状況変化への対応が可能となっている。以下、実施形態２に係る支援システムにつき詳細に説明する。
【０１１２】
図１５は、実施形態２に係る品質検査工数の最適化支援システム（支援システム）が適用される品質検査の過程を模式的に示す図である。図１５に示す品質検査の過程（１）〜（７）の概要は、図１に示した実施形態１に係る品質検査の過程（１）〜（７）と同様である。但し、図１５に示す過程（２）〜（４）の詳細は、実施形態１と異なっている（詳細は後述）。
【０１１３】
また、実施形態２では、図１５に示すように、過程（２Ａ）及び（３Ａ）が追加されている（破線で囲まれた部分を参照）。すなわち、過程（３）の品質検査種別提示後において、ソフトウェアの開発（制作）状況に変化が生じない場合には、実施形態１と同様に過程（４）に進む（図１参照）。これに対し、過程（３）における品質検査種別の提示後、開発（制作）状況に変化が生じた場合には、品質検査の再判定が実行され（図１５、過程（２Ａ））、再判定結果に応じた品質検査種別が提示される（図１５、過程（３Ａ））。その後、過程（４）において、品質検査等が実施される。
【０１１４】
このように、実施形態２では、品質検査の受け付け後に、開発状況に変化が生じた場合には、品質検査再判定が実施され、再判定結果に基づく品質検査種別が提示される。したがって、開発工程における計画外の工数増大や仕様変更による品質のぶれのような開発状況の変化に応じて、適正な品質検査種別での品質検査を実施することが可能となる。
【０１１５】
例えば、品質検査受け付け後に、開発工数や開発規模が増大した場合には、受け付け時よりも障害発生の可能性が高まる。換言すれば、検査すべき事項が増加する。この場合、品質検査種別の再判定が実施され、先に提示された品質検査種別より検査工数の多い品質検査種別が再提示される。これによって、開発状況の変化に応じた適正な品質検査を実施することが可能となる。
【０１１６】
実施形態２に係る支援システムにおいても、図２に示した情報処理装置１０を適用することができる。情報処理装置１０の構成は実施形態１で説明したので説明は省略する。但し、実施形態２では、補助記憶装置３（図２）に格納されたＤＢに含まれるテーブル群が、実施形態１と異なっている。また、ＣＰＵ１（プロセッサ：制御装置）が記録媒体に記録されたプログラムの実行によって実行する品質判定処理の内容が実施形態１と異なる。さらに、実施形態２では、ＣＰＵ１は、プログラムの実行によって、品質検査再判定及び提示処理を実行する。
【０１１７】
実施形態２におけるＤＢは、判定ポイントマスタテーブル２１（図３（Ａ））、品質検査種別マスタテーブル２４（図４（Ａ））、担当者情報マスタテーブル２５（図４（Ｂ））、及び障害規模−判定ポイントマスタテーブル２６（図４（Ｃ））を有する点において、実施形態１と同様である。このため、これらのテーブル２１，２４〜２６の説明は省略する。
【０１１８】
これに対し、実施形態２におけるＤＢは、実施形態１における登録データテーブル２２（図３（Ｂ））及び担当者品質テーブル２３（図３（Ｃ））の代わりの登録データテーブル２２Ａ及び担当者品質テーブル２３Ａを備える。また、実施形態２におけるＤＢは、検査ブランクマスタテーブル２７と、開発規模テーブル２８とをさらに含む。
【０１１９】
図１６（Ａ）は、実施形態２に係る登録データテーブル２２Ａのデータ構造例を示し、図１６（Ｂ）は、実施形態２に係る担当者品質テーブル２３Ａのデータ構造例を示す。図１７（Ａ）は、実施形態２に係る検査ブランクマスタテーブル２７のデータ構造例を示し、図１７（Ｂ）は、実施形態２に係る開発規模テーブル２８のデータ構造例を示す。
【０１２０】
図１６（Ａ）において、登録データテーブル２２Ａは、サービス名（ソフトウェアを用
いて提供されるサービス名）と、そのサービスに係るソフトウェアを開発した担当者名と、品質検査に当たって提供される設問の回答内容に応じたポイントが、サービス名且つ担当者毎に登録される点において、実施形態１の登録データテーブル２２（図３（Ｂ））と同様である。これに対し、登録データテーブル２２Ａは、さらに“検査開始日”を格納する点で、実施形態１の登録データテーブル２２と異なっている。“検査開始日”は、担当者が開発したサービスの品質検査の開始日を示す。
【０１２１】
図１６（Ｂ）において、担当者品質テーブル２３Ａは、担当者毎に、品質ポイントと、検査実施回数と、障害判定ポイントとを格納する点で、実施形態１の担当者品質テーブル２３（図３（Ｃ））と同様である。これに対し、担当者品質テーブル２３Ａは、“開発工数”と、“前回検査開始日”とをさらに格納する点で、テーブル２３と異なっている。ここに、“開発工数”は、品質検査の申請に係る開発の工数を示す。一方、“前回検査開始日”は、担当者の開発物に対する過去の品質検査のうち、直近に実施された品質検査の検査開始日を示す。
【０１２２】
図１７（Ａ）において、検査ブランクマスタテーブル２７は、レコードとして、検査ブランクの程度と、検査ブランク値（ｃ）と、ブランク判定ポイントとを含む複数のエントリからなる。図１７（Ａ）に示す例では、検査ブランクの程度として、“ブランクが低い”、“ブランクが通常”、“ブランクが長い”、“初めての依頼”の４種別が用意されている。但し、検査ブランクの程度の種別数は適宜設定可能である。
【０１２３】
検査ブランク値（ｃ）は、担当者の開発（制作）に対するブランクを数値化した値である。検査ブランク値（ｃ）として、担当者品質テーブル２３Ａに格納された前回検査開始日と、登録データテーブル２２Ａに格納された検査開始日との間の期間（日数）から求められる値が適用される。検査ブランク値（ｃ）として、期間（日数）がそのまま適用されてもよく、期間（日数）を適宜の手法で数値化した値が適用されても良い。
【０１２４】
テーブル２７には、検査ブランクの程度に応じた検査ブランク値（ｃ）の採り得る範囲が格納される。但し、“初めての依頼”に対する検査ブランク値（ｃ）の採り得る範囲はない。また、テーブル２７には、検査ブランクの程度に応じたブランク判定ポイントが登録される。ブランク判定ポイントは、ブランクが短い程低い値が設定される。但し、図１７（Ａ）の例では、ブランクが長い場合と初めての依頼とは同じブランク判定ポイントが設定されている。もっとも、ブランクが長い場合のブランク判定ポイントは、初めての依頼のブランク判定ポイントより小さくても良い。
【０１２５】
図１７（Ｂ）において、開発規模テーブル２８は、レコードとして、開発規模の程度と、開発規模値（ｄ）と、開発規模判定ポイントとを含む複数のエントリからなる。図１７（Ｂ）に示す例では、開発規模の程度として、“開発規模が小さい”、“開発規模が中程度”、“開発規模が大きい”、“新規開発”の４種別が用意されている。但し、開発規模の程度の種別数は適宜設定可能である。
【０１２６】
開発規模値（ｄ）は、品質検査に係る開発物の開発規模を数値化した値である。開発規模値（ｄ）の算出については後述する。テーブル２８には、開発規模の程度に応じた開発規模値（ｄ）の採り得る範囲が格納される。但し、“新規開発”に対する開発規模値（ｄ）の採り得る範囲はない。また、テーブル２８には、開発規模の程度に応じた開発規模判定ポイントが登録される。開発規模判定ポイントは、開発規模が小さい程低い値が設定される。但し、図１７（Ｂ）の例では、開発規模が大きい場合と新規開発とは同じ開発規模判定ポイントが設定されている。もっとも、開発規模が大きい場合の開発規模判定ポイントとして、新規開発の開発規模判定ポイントより小さい値が設定されても良い。
【０１２７】
上記したブランク判定ポイントは、担当者の開発ブランクに応じた開発の習熟度を示す指標の１つとなり、開発規模判定ポイントは、開発の規模を示す指標の１つとなる。これらのブランク判定ポイント及び開発判定ポイントは、実施形態１で説明した担当者判定ポイント及び各設問（図６）に対する回答のポイントとともに、実施形態２において品質検査種別を判定するための要素となる。すなわち、実施形態２では、担当者判定ポイント及び各設問に対する回答のポイントの合計値に、ブランク判定ポイント及び開発判定ポイントを加えた値が、判定ポイント合計値（ａ）となる。そして、品質検査種別マスタテーブル２４（図４（ａ））の参照によって、判定ポイント合計値（ａ）に応じた品質検査種別が決定される。
【０１２８】
次に、実施形態２における支援システムを実現する情報処理装置１０（図２）の動作例について説明する。開発担当者は、ソフトウェアの開発が終了すると、品質検査を依頼すべく、情報処理装置１０の入力装置５を操作して、支援システムを実行するプログラム（支援プログラムと称する）の実行開始指示を入力する。すると、ＣＰＵ１が補助記憶装置３に格納された支援プログラムを主記憶装置２にロードし、当該支援プログラムの実行を開始する。
【０１２９】
図１８は、ＣＰＵ１によって実行される、実施形態２に係る品質検査判定処理（図１５、（２））及び品質検査種別提示処理（図１５、（３））の例を示すフローチャートである。当該処理は、品質検査の受付を契機に、支援プログラムの実行指示を情報処理装置１０に入力することによって開始される。支援プログラムの実行が開始されると、ＣＰＵ１は、表示装置６を制御して、品質検査依頼の入力画面を情報処理装置１０の表示装置６（図２）に表示する（図１８，ステップＳ１）。
【０１３０】
入力画面として、図６に示した入力画面３１を適用することができる。但し、入力画面３１には、図示しないが、今回の品質検査の開始日と、開発工数の入力欄がさらに設けられる。入力画面３１及び入力装置５を用いて、サービス名，登録者（開発担当者），各設問に対する回答，開発工数，及び品質検査開始日が入力された状態で確認ボタンが押されると、ＣＰＵ１は、以下のような処理を行う。
【０１３１】
すなわち、ＣＰＵ１は、担当者品質テーブル２３Ａの、開発担当者に対応するエントリ中に、入力画面３１を用いて入力された開発工数を示す値を登録する。また、ＣＰＵ１は、登録データテーブル２２Ａの、開発担当者に対応するエントリ中に、入力画面を用いて入力された検査開始日を登録する。さらに、ＣＰＵ１は、実施形態１と同様に、各設問の回答に応じたポイントをエントリ中に登録する（もっとも、この処理は、実施形態１と同様に、判定ポイント集計処理にて実行されても良い）。なお、実施形態２における例では、入力画面を用いて開発工数が入力される例が示されている。これに対し、各設問に対する各回答に開発工数値が予め設定され、回答内容に応じた開発工数値をＣＰＵ１が集計して合計値（開発工数値）を求め、担当者品質テーブル２３Ａに格納するようにしても良い。この場合、開発工数の入力を省略可能である。
【０１３２】
ステップＳ１の処理が終了すると、ＣＰＵ１は、処理をステップＳ２Ａに進め、判定ポイント集計処理を実行する。ステップＳ２Ａの判定ポイント集計処理において、ＣＰＵ１は、担当者判定ポイント，障害判定ポイント，開発規模判定ポイント，ブランク判定ポイント，及び設問に対する回答ポイントの合計値を得る。
【０１３３】
担当者判定ポイント及び障害判定ポイントを取得するための処理は、実施形態１と同様の処理であるので、説明を省略する。開発規模判定ポイントを取得するための処理として、ＣＰＵ１は、以下の処理を行う。すなわち、外部システムである検査システム２９にアクセスし、今回の品質検査の対象となる開発物（ソフトウェア）の初期開発工数を取得す
る。例えば、ＣＰＵ１は、サービス名を検査システム２９に送り、サービス名に対応する初期開発工数を受け取る。続いて、ＣＰＵ１は、担当者品質テーブル２３Ａ（図１６（Ｂ））から担当者名に対応する開発工数を読み出し、以下の[式１]を用いて開発規模値（ｄ）を算出する。
[式１]  開発規模値（ｄ）＝（開発工数÷初期開発工数）×１００
続いて、ＣＰＵ１は、開発規模テーブル２８（図１７（Ｂ））を参照し、開発規模値（ｄ）に対応する開発規模判定ポイントを読み出す。このようにして、開発規模判定ポイントが得られる。
【０１３４】
また、ブランク判定ポイントを取得するための処理として、ＣＰＵ１は、以下の処理を行う。すなわち、ＣＰＵ１は、担当者品質テーブル２３Ａから、担当者名に対応する前回検査開始日を読み出す。次に、ＣＰＵ１は、登録データテーブル２２Ａ（図１６（Ａ））から、サービス名及び担当者名に対応する検査開始日を読み出し、前回検査開始日と検査開始日とから検査ブランク値（ｃ）を算出する。続いて、ＣＰＵ１は、検査ブランクマスタテーブル２７（図１７（Ａ））を参照し、検査ブランク値（ｃ）に対応するブランク判定ポイントを読み出す。このようにして、ブランク判定ポイントが得られる。
【０１３５】
さらに、ＣＰＵ１は、登録データテーブル２２Ａに格納された各設問（設問１〜９）に対する回答に応じたポイントの合計値を算出し、判定ポイント合計値を以下の[式２]を用いて算出する。
[式２]  判定ポイント合計値＝担当者判定ポイント＋障害判定ポイント＋開発規模判定ポイント＋ブランク判定ポイント＋各設問に対する回答ポイントの合計
【０１３６】
次に、ＣＰＵ１は、品質検査種別判定処理（ステップＳ３Ａ）として、以下の処理を行う。すなわち、ＣＰＵ１は、品質検査種別マスタテーブル２４（図４（Ａ））を参照して、判定ポイント合計値が数値範囲に収まる検査方法（品質検査種別）を、今回の品質検査に対して適用すべき検査方法として決定する。
【０１３７】
次に、ＣＰＵ１は、処理をステップＳ４に進めて品質検査種別提示処理を実行する。すなわち、ＣＰＵ１は、表示装置６を制御し、ステップＳ３Ａで決定した検査方法を示す品質検査種別提示画面４１（図７（Ａ））を表示装置６に表示する。画面４１の内容、及び品質検査種別と検査工数との関係は、実施形態１と同じであるので説明を省略する。
【０１３８】
さらに、ＣＰＵ１は、主記憶装置２又は補助記憶装置３の記憶領域上に作成された一次判定ポイントテーブル３０に対し、ステップＳ２Ａにおいて取得した担当者判定ポイント，障害判定ポイント，開発規模判定ポイント，ブランク判定ポイント，及び各設問に対する回答ポイントの合計値（まとめて、「一次判定ポイント」と称する）を、サービス名及び担当者名と関連づけて記録する。一次判定ポイントは、品質検査再判定及び品質検査種別判定処理において使用される。なお、一次判定ポイントテーブル３０には、検査システム２９から得た初期開発工数をさらに記録するようにしても良い。
【０１３９】
このように、実施形態２では、実施形態１で適用される判定要素（担当者判定ポイント、障害判定ポイント、各設問に対する回答ポイント）に加え、開発規模判定ポイント及びブランク判定ポイントを加味した判定ポイント合計値に基づいて品質検査種別（検査方法）が決定されることで、開発担当者の習熟度（ブランク）や開発規模をさらに考慮した品質検査種別を決定することができる。これによって、ブランクや開発規模が大きい場合には、実施形態１での判定結果よりも検査工数の多い判定結果（検査方法）が決定されることになり、障害発生を未然に防ぐことが可能となる。
【０１４０】
なお、開発規模判定ポイントとブランク判定ポイントとの双方が判定ポイント合計値に
含まれることは必須の構成要件ではない。すなわち、開発規模判定ポイント及びブランク判定ポイントの一方のみが判定ポイント合計値に反映されるようにしても良い。この場合、判定ポイント合計値に反映されない開発規模判定ポイント及びブランク判定ポイントの他方に係る構成は省略が可能である。
【０１４１】
次に、実施形態２において実行される品質検査再判定処理（図１５、（２Ａ））及び再提示処理（図１５、（３Ａ））の処理について説明する。図１９は、ＣＰＵ１による品質検査再判定処理及び品質検査種別提示処理の例を示すフローチャートである。
【０１４２】
品質検査の受け付け後に、開発工数や品質検査開始日が変更になった場合には、情報処理装置１０における支援プログラムの実行を開始して、所定の入力画面（開発工数／検査開始日の変更画面：図示せず）を表示装置６上に呼び出し、開発工数、検査開始日の変更処理を行う（ステップＳ２１）。
【０１４３】
変更画面は、少なくともサービス名，担当者名，開発工数，検査開始日の各入力欄を備える。変更画面及び入力装置５（図２）を用いて、サービス名及び担当者名に関して、変更に係る開発工数及び検査開始日の少なくとも一方の変更を入力することができる。ここでは、開発工数及び検査開始日の双方が変更された場合を例示する。また、変更画面は、入力画面３１にて示したような設問の回答欄を有し、設問に対する回答を再入力することもできる。
【０１４４】
ＣＰＵ１は、開発工数／検査開始日の変更画面を通じて入力されたサービス名，担当者名，開発工数，及び検査開始日を受け付けると、担当者品質テーブル２３Ａ（図１６（Ｂ））を参照し、入力された担当者名のエントリにおける開発工数を入力された開発工数で更新する。また、ＣＰＵ１は、登録データテーブル２２Ａ（図１６（Ａ））を参照し、入力された担当者名及びサービス名のエントリにおける検査開始日を入力された検査開始日で更新する。
【０１４５】
次に、ＣＰＵ１は、判定ポイント集計処理を行う（ステップＳ２２）。すなわち、ＣＰＵ１は、一次判定ポイントテーブル３０から、サービス名及び担当者名に係る一次判定ポイントを読み出す。次に、ＣＰＵ１は、検査システム２９にアクセスして、サービス名に対応する初期開発工数を取得する。但し、一次判定ポイントテーブル３０に初期開発工数が格納されており、一次判定ポイントとともに初期開発工数を読み出すことができた場合には、ＣＰＵ１は検査システム２９に対するアクセスを行わない。
【０１４６】
次に、ＣＰＵ１は、担当者品質テーブル２３Ａ中の更新（変更）に係る開発工数と、初期開発工数とを、上記した[式１]に代入して開発規模値（ｄ）を得る。この開発規模値（ｄ）を以て開発規模テーブル２８を参照し、新たな開発規模判定ポイントを得る。なお、開発工数の変更がない場合には、当該処理は省略可能である。
【０１４７】
また、ＣＰＵ１は、入力されたサービス名及び担当者名を用いて、登録データテーブル２２Ａ中の更新（変更）に係る検査開始日を読み出すとともに、担当者品質テーブル２３Ａに格納された担当者名に対応する前回検査開始日とを読み出し、ステップＳ２Ａで説明した手法と同様の手法で新たなブランク判定ポイントを得る。なお、検査開始日の変更がない場合には、当該処理は省略可能である。
【０１４８】
さらに、ＣＰＵ１は、変更画面にて設問に対する回答が変更されており、登録データテーブル２２Ａに登録された各設問の回答ポイントが変更されている場合には、各設問の回答ポイントの合計値を再計算する。但し、設問の再回答が認められない場合、及び設問に対する再回答がない場合には、当該処理は省略可能である。
【０１４９】
そして、ＣＰＵ１は、新たな開発規模判定ポイントと、新たなブランク判定ポイントと、一次判定ポイントテーブル３０から得た担当者品質ポイント及び障害判定ポイントと、各設問に対する回答ポイントの合計値（テーブル３０から取得、又は再計算）との合計値、すなわち判定ポイント合計値（ａ）を得る。但し、開発規模判定ポイント及びブランク判定ポイントの一方において、上述した再取得処理が実行されない場合には、一次判定ポイントテーブル３０から得たポイント値を用いる。
【０１５０】
続いて、ＣＰＵ１は、品質検査種別判定処理（ステップＳ２３）として、以下の処理を行う。すなわち、ＣＰＵ１は、品質検査種別マスタテーブル２４（図４（Ａ））を参照して、判定ポイント合計値が数値範囲に収まる検査方法（品質検査種別）を、新たな検査方法として決定する。
【０１５１】
次に、ＣＰＵ１は、処理をステップＳ２４に進めて品質検査種別提示処理を実行する。すなわち、ＣＰＵ１は、表示装置６を制御し、ステップＳ２３で決定した検査方法を示す品質検査種別提示画面４１（図７（Ａ））を表示装置６に表示する。ステップＳ２４の処理は、ステップＳ４の処理と同様の処理である。ステップＳ４によって、開発工数や品質検査開始日の変更に応じた品質検査種別が提示され、検査内容を開発状況の変化に対応させることができる。
【０１５２】
例えば、開発工数が増加した場合には、品質検査種別が工数の多いレベルに変更されることで、公開後（サービス開始後）に障害発生の可能性を低減できる。逆に、開発工数が減少した場合には、品質検査種別が工数の少ないレベルに変更されることによって、無駄な検査項目を省くことができる。また、開発の中断によって開発担当者のブランクが長くなった場合には、工数の多い品質検査種別に変更されることが可能となり、障害発生の可能性を低減することができる。なお、上記したステップＳ２４において、一次判定ポイントテーブル３０に再計算された各判定ポイントが記録され、品質検査種別の再々判定に使用されるようにしても良い。また、上記した例では、一次判定ポイントテーブル３０に、各判定ポイントを記録（格納）して、再計算される判定ポイントの数を減らすようにしている。もっとも、図１８に示すステップＳ２Ａ及びＳ３Ａの処理が再度実施され、全ての判定ポイントが再計算されるようにしても良い。
【０１５３】
図２０は、実施形態２における品質検査（図１５、（４）：サービス公開直後の検査（公開時検査と呼ばれる）を含む）時における支援システムを実現する情報処理装置１０（ＣＰＵ１）の動作例を示すフローチャートである。図２０に示すステップＳ０１，Ｓ０２Ａ，Ｓ０３，Ｓ０４，Ｓ０５Ａの処理は、図８に示した処理と同様である。但し、ステップＳ０２Ａ，Ｓ０５Ａは、実施形態１で説明した処理に加え、以下の処理を実行する点で実施形態１と異なっている。なお、図２０に示す検査システム２９は、実施形態１（図８）で示した検査システムと同様のものである。
【０１５４】
ステップＳ０２Ａでは、ＣＰＵ１は、検査システム２９から今回の品質検査の“検査開始日”を取得する。そして、ステップＳ０５Ａでは、ＣＰＵ１は、担当者品質テーブル２３Ａの更新において、ステップＳ０２Ａで取得した“検査開始日”を、“前回検査開始日”として更新（上書き）する。このようにして、実施形態２では、品質検査の実施において、品質ポイント及び検査実施回数のみならず、前回検査開始日が更新される。以上の処理を除き、図２０に示した処理は、図８に示した処理と同様であるので説明を省略する。
【０１５５】
また、図１５の過程（５）における処理は、実施形態１と同様であるので説明を省略する。すなわち、開発されたサービス（ソフトウェア）の運用が開始された後に、当該サービスに係る障害が発生した場合には、図９に示したような処理が実行される。
【０１５６】
図２１は、或るサービス（サービス名：サービスＡ）に関して、同一の担当者（品質が同じ）が開発を行った場合における、品質検査判定処理の結果（検査種別）の例を示す表である。但し、ブランク判定ポイント（開発者のブランクの長さ）が異なっている。すなわち、検査ブランク判定ポイント以外の判定ポイントが固定された状態において、検査ブランク判定ポイントが“１００（ブランクが長い又は初めての開発）”の場合と、“０（ブランクが通常）”の場合と、“−２０（ブランクが短い）”の場合とにおける、判定ポイント合計値のそれぞれが示されている。
【０１５７】
図２１に示すように、検査ブランク判定ポイントが大きい、すなわち、ブランクが長い程、判定ポイント合計値は大きくなり、工数の多い品質検査種別が選択される。図２１の例では、ブランクが長い場合は「Ｂ検査」、ブランクが通常（標準）の場合は「Ｃ検査」、ブランクが短い場合は「Ｄ検査」が選択されている。
【０１５８】
図２２は、或るサービス（サービス名：サービスＢ）について、同一の担当者（品質が同じ）が開発を行った場合における、品質検査判定処理の結果（検査種別）の例を示す表である。但し、開発規模判定ポイント（開発規模）が異なっている。すなわち、開発規模判定ポイント以外の判定ポイントが固定された状態において、開発規模判定ポイントが“１００（開発規模が大きい又は新規開発）”の場合と、“０（開発規模が中（通常））”の場合と、“−２０（開発規模が小さい）”の場合とにおける、判定ポイント合計値のそれぞれが示されている。
【０１５９】
図２２に示すように、開発規模判定ポイントが大きい、すなわち、開発規模が大きい程、判定ポイント合計値は大きくなり、工数の多い品質検査種別が選択される。図２２の例では、開発規模が大きい場合は「Ｂ検査」、開発規模が通常（中）の場合は「Ｃ検査」、開発規模が小さい場合は「Ｄ検査」が選択されている。
【０１６０】
以上説明した実施形態１，２の構成は、本発明の目的を逸脱しない範囲で適宜組み合わせることができる。
【符号の説明】
【０１６１】
１・・・ＣＰＵ（プロセッサ：制御装置）
２・・・主記憶装置
３・・・補助記憶装置
４・・・通信インタフェース
５・・・入力装置
６・・・表示装置
７・・・プリンタ
１０・・・情報処理装置
２１・・・判定ポイントマスタテーブル
２２，２２Ａ・・・登録データテーブル
２３，２３Ａ・・・担当者品質テーブル
２４・・・品質検査種別マスタテーブル
２５・・・担当者情報マスタテーブル
２６・・・障害規模−判定ポイントマスタテーブル
２７・・・検査ブランクマスタテーブル
２８・・・開発規模テーブル
２９・・・検査システム（外部システム）
３０・・・一次判定ポイントテーブル
【図１】
2011227885.tif 000003
【図２】
2011227885.tif 000004
【図３】
2011227885.tif 000005
【図４】
2011227885.tif 000006
【図５】
2011227885.tif 000007
【図６】
2011227885.tif 000008
【図７】
2011227885.tif 000009
【図８】
2011227885.tif 000010
【図９】
2011227885.tif 000011
【図１０】
2011227885.tif 000012
【図１１】
2011227885.tif 000013
【図１２】
2011227885.tif 000014
【図１３】
2011227885.tif 000015
【図１４】
2011227885.tif 000016
【図１５】
2011227885.tif 000017
【図１６】
2011227885.tif 000018
【図１７】
2011227885.tif 000019
【図１８】
2011227885.tif 000020
【図１９】
2011227885.tif 000021
【図２０】
2011227885.tif 000022
【図２１】
2011227885.tif 000023
【図２２】
2011227885.tif 000024