ソフト開発監査チェックリスト（５）品質保証プロセス（後半）
開発プロセスチェックリストの４番目、品質保証の後半の紹介です
この記事では前の記事に続いて、ソフト監査チェックリストの①開発プロセスの中の品質保証の個々の項目について紹介します。（チェックリストそのものはソフト監査実務・チェックリストその１：開発プロセス（要件管理）の記事に載っていますので、そちらをご覧下さい）
前の記事では項目番号 QA-5 までを紹介しましたので、QA-6 以降の項目について紹介していきます。
【項目番号：QA-06】
テストで見つかったバグが少数ですぐに修正できれ良いのですが、普通は大量のバグが見つかって設計チームはまさにバグとの闘いに明け暮れる事になります。そんな時には、闇雲に目の前のバグを潰していくのではなくちゃんと優先度をつけて重要なバグから修正していく事が大切です。バグをどんな基準で優先度をつけるのか、優先度の付け方や優先度に従ったバグの調査・対策の進め方が、ちゃんと決まっていてその通りに実施されているか、という点を確認します。
【項目番号：QA-07】
テストが終わると次はリリースですが、リリースしても良いかどうかのリリース判定はソフトとして最も重要な判定プロセスです。判定の仕方について、例えばどんな情報を元にソフトのプロダクト品質を判断するのか、判断する時の基準値は何なのか、誰が判断の最終責任者なのかなどのリリース可否の判定作業について、ちゃんと進め方のルールが決まっていてそのルールに従って実施されているかを確認します。
【項目番号：QA-08】
ソフトのリリースには、正式版のリリース以外にも何種類かのリリースがあります。一部の機能を評価するためのアルファ版のリリース、全部の機能は載っいて使い勝手を評価するためベータ版リリース、不具合を修正するためのバグFIX版リリース、その他に社内や関連会社での限定評価のためのエンジンリングリリースなどもあります。色々なリリースの種類があって面倒なのですが、まあ工場で作られる製品にも、試作品とか試供品とかがあるのでソフトウエアに限った事でもありません。
ただしある組織がリリースするソフトに複数の種類のリリースがあるのなら、それぞれのリリースについてその目的や用途等がちゃんと定義されている必要があります。また、それぞれのリリースにつていのリリース可否の判定方法や判定の基準についても、明確になっている必要があります。そうでないと、社内も社外も混乱していますので。ですので、その組織が使っているリリースの種類について、定義やリリース判定の基準が明確になっているか、という点を確認します。
【項目番号：QA-09】
ソフトの開発を受託していて、受託する作業の中にテストが含まれているなら、テストの計画や進捗やその成果としてのバグ等の情報は、定期的の開発委託元に伝える必要があります。そのような活動について、具体的にどうしているのかを確認します。
【項目番号：QA-10】
ソフトは目に見えない物なので、リリースする時にはリリースノートを一緒に提供して、どんなソフトなのかの説明をします。リリースノートには、機能や修正されたバグが書いてあるのですが、それだけではなくどんなテストをして品質を確認したのか、テストで見つかったが今回のリリースまでに修正が間に合っていない残存バグにどんな物があるのか、はソフトウエアを受ける側にとってとても大切な事項です。それらの情報がリリースノートに記載されるような仕事の仕組みになっているかどうかを確認します。
【項目番号：QA-11】
リリースノートはソフトにとって重要なドキュメントです。品質の面からは特に残存しているバグ（社内の試験で見つかったけど今回のリースでは修正できていないバグ）の情報はとても重要です。そのような重要な情報が漏れなくリリースノートに書かれていてほしいものです。では、そのような重要な情報は、元の情報はどこに記録されていてそれを誰がどんな方法で選び出してきて、リリースノートに纏めるのでしょうか？ 誰かの頭の中にある記憶だけを頼りにしてリリースノートが作成されるようでは、重要な項目に漏れが出るかもしれません。リリースノートに書かれた情報に洩れが無いように、どんな元情報からどんな方法でリリースノートに乗せる内容を取り出すのか、具体的な方法について確認します。
【項目番号：QA-12】
最後の項目はちょっと他の項目とは異なっています。ソフトの開発管理には色々な方法がありますが、メトリクス（日本語に直すとソフトウエアの品質指標ですね）を使った管理もあります。数名程度の少人数の開発チームならメトリクス管理をしなくてもだいたいの品質や進捗は判るのですが、複数のチームが共同していて総勢で数十人ともなってくると、何等かのメトリクスが無いと進捗や品質の管理が難しくなります。相手先の組織でソフトメトリクスによる開発管理をしているかどうか、メトリクスを使っているのなら、どんなメトリクスで基準は何か等について確認しましす。
品質保証の次は構成管理です
品質保証の次は構成管理についての確認項目について、次の記事で紹介します。