ソフト開発監査チェックリスト（４）品質保証プロセス（前半）
開発プロセスチェックリストの４番目は品質保証です
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では①開発プロセスの中の品質保証の個々の項目について紹介します。（チェックリストそのものはソフト監査実務・チェックリストその１：開発プロセス（要件管理）の記事に載っていますので、そちらをご覧下さい）
ここでの品質保証とはプロセス品質保証という意味です
品質保証はプロセスチェックリストの項目番号の先頭がQA- となっている12項目です。QA は Quality Assuarnce ですしチェックリストに出てくる SQA は Software Quality Assuarnce ですので、日本語に直訳すると品質保証とソフトウエア品質保証、となります。
しかし、実務・プロセスの監査（まずはじめに）の記事でも書きましたがここでの QA や SQA は CMMI が使っている定義なので、ここでの品質保証はソフトそのもののプロダクト品質の品質保証の事はなくてソフトを開発する時のプロセス品質の品質保証という意味です。
混乱しないように、グータラ親父はプロセス品質保証活動と呼んでいます。 ですのでこのチェックリストでも、ソフトの開発プロセスの品質を保証する活動について確認を進めていきます。また、チェックリストによく出てくる SQA は、ソフトの開発プロセスが正しく実施されている事を検証する（＝保証する）役割を持った担当者やチームを指します。
それでは、項目を１つずつ見ていきましょう。
【項目番号：QA-01】
まず最初に、そもそもプロセス品質を保証するための活動（これをCMMIは SQAと呼んでいます）が組織の中に存在するか、存在するならばどんな活動を実施しているかを確認します。監査先の組織が CMMI を取得しているなら SQA という言葉で通じるので楽なのですが、CMMI を所得していない場合には、まず SQA の定義の説明をする必要があります。
良い品質のソフトを作るには良い品質の開発プロセスが開発作業を進める事が必要なので、そのようなよい開発プロセスが実施されている事を監視する仕組みが必要です。それのような活動をする担当者や組織を SQA と呼んでいます、というところの説明からです。あまり抽象的な説明ではわかりにくいので、基本的なソフト開発プロセスの計画書の作成、レビューの実施、テスト計画 等について実施状況を監視するSQA担当者や組織があるかどうか、という聞き方でSQA活動の有無を確認します。
【項目番号：QA-02】
SQA担当者またはSQAチームは、開発プロセスの実施状況を確認したら、その結果を実際の開発を行っている開発チームに報告します。これをソフトエンジグループと呼んでいます、例えば計画書が必要な改定が遅れていたとか、設計レビューが計画していた回数の半分しか実施されていない、とか開発プロセスの面で問題となる事態が起きていたら、それを開発チームとそのチームの責任者に対して報告し、対策を促します。そのような、開発チームへのフィードバック作業がちゃんと実施されているかを、このチェック項目で確認します。
【項目番号：QA-03】
SQA 担当によるプロセス品質保証活動もテストによるバグの発見作業と一緒です。問題点を指摘する事が最終目標ではなくって、見つけた問題点が開発チームなどで対策されて問題点をなくす事が目標です。ですので、見つけた問題点を記録して対策が終わるまでその問題点をトラッキングする作業が着実に実施されている事が大切なので、その点を確認します。
【項目番号：QA-04】
ここからは、プロダクト品質の保証業務そのものであるテストについて、開発プロセスの面から確認する項目が並んでいます。テストというプロセスがちゃんと管理される仕組みがあるかどうかが問題なので、まず一番最初に確認するのが、テスト計画です。テスト計画を作る事が必要となっているか、テスト計画は誰が何時作るのか、テスト計画にはどんな項目を書くのかなど、テスト計画としてどんな項目が必要でどうやって作るのかを明記した文書があるのか、その文書に従ってテスト計画が作られているのか、という点を確認します。
【項目番号：QA-05】
これは特に説明は要りませんね。せっかくテストで見つけたバグは漏れなく記録して対応していかないといけません。せっかく見つけたバグを、その後のトレースを忘れて修正されずに市場に漏れだしてしまっては、テストした意味がありません。もちろん、テストで見つかった問題が全てバグという訳でもないです。
テストそのものが間違っていたり、仕様かどうかはっきりしないグレーな挙動だったりと、バグでない項目もあるでしょう。また、バグではあるけど今回のリリースには修正を織り込まずに、次のバージョンで修正すると判断するようなバグもあるでしょう。 そのような判断をするためにも、バグは漏れなく記録してトラッキングする事が大切なので、その点について確認します。