ソフト開発監査の監査当日（５）ソフト開発に必要な機能と担当部署（前半）
ソフト品質保証に大切な６つの機能と担当部署
ここまでの記事では、ソフト開発監査の最初の時間に相手先の会社から組織やルールについての説明を受ける時に注意する点として、どんな組織があるのか？ という視点について紹介してきました。もうひとつ、ソフトの品質保証にはどんな機能が大切でそれはどの部署が担当しているのか？ という視点も大切ですので、この記事からはその視点についてソフト開発監査での注意点について紹介しましょう。
ソフトの品質保証のために大切な機能は何なのかという事についても、これが正解というものはありません。ただグータラ親父のこれまで経験からは、ソフト品質保証には以下のような機能が必要で、ソフト開発の委託先の組織にはこれらの機能を担当する部署が在る事が大切だと感じています。
- ソフトウエアのリリース判定
- プロダクト品質の確認
- プロセス品質の確認
- 購入品やフリーソフトの品質の確認
- 開発計画や開発プロジェクトの管理方法
- 不具合事例の横展開や技術教育
ここに挙げた機能のうち最初の３つは、この記事の前のソフト品質保証部門（SQA) のところでも紹介した３つの品質保証活動で、ソフトの品質を確保するには大切な活動です。ですが、これらの機能は必ずしも品質保証部門が担当しているとは限りません。そのあたりにも注意して監査先の会社の説明を聞くのが良いです。 ではそれぞれの注意点について少し具体的に紹介していきしょう。
（１）ソフトのリリース判定の機能
ソフトの品質保証について一番大事な事は何かと考えた時、やはり品質の悪いソフトをリリースしないという単純な回答に辿りつきます。では品質の悪いソフトをリリースしないためにはどうるれば良いかというとこれまた単純で、ソフトをリリースして良いかどうかのリリース判定をすれば良い、となります。ソフトのリリース判定の具体的方法についてはリリース判定の記事グループで詳しく紹介していますので、興味のある方はそちらもご覧ください。
ところでこのリリース判定は、どの部門が実施するのでしょうか？ ソフト品質保証部というのがあればそこで実施されるでしょうから問題はないのですが、組み込み系のソフトの開発を行っている会社では、品質保証部はあってもソフト品質保証部は無い所もよく在ります。
組み込み系のソフト開発行っている会社は多くが機器メーカです。自社の製品に組み込むソフトを社内で開発したり社外に開発の委託をしたりしています。ですので、製品の品質を保証するための品質保証部はあります、しかし品質保証部製造品質を保証する部門というのが一般的なのです。工場で製造された製品の品質保証の一環として製造品の出荷判定は行いますが、そこに組み込まれているソフトのリリース判定は行わない場合も多いです。
そのような場合のソフトのリリース判定は、ソフトの開発を行っている開発部門が実施したり、あるいは開発部門からの委託を受けてソフトのテストを行っているテスト部門が実施したりと、様々です。場合によっては、営業・開発・設計・保守の関連部門が集まった会議体でリリース判定を行っている事もあります。
いずれにしても、ソフトの品質保証で一番大切なリリース判定をどの部署で行っていて、リリース判定の責任者が誰なのかが、明確に決まっているかどうかを確認しておく事が大切です。ルールが定まっていなくて、なんとなく誰かがOKといえばソフトがリリースされていました、というのはさすがに問題ですので。。。
（２）ソフトのプロダクト品質の確認機能
ソフトのリリース判定を実施している部門が判ったとして、その次に注意するのは、どんな基準で誰がソフトの品質を確認するための情報を集めて、その良し悪しを判定しているのかとう点です。ここで言うソフトの品質は、ソフトそのものの品質なのでソフトのプロダクト品質の事を指しています。
このプロダクト品質の判定基準については、いろいろな情報と判定基準を元に判定する事になるので、プロダクト品質の記事で詳しく紹介しています、興味のある方はそちらの記事もご覧ください。
相手先から組織の説明を聞くときに注意するのは、その組織ではプロダクト品質を確認するためにどんな情報を元にどんな判定基準を採用しているのかという点と同様に、その判定に使う情報をどの部門がどうやって集めているのか、という点も大切です。
テストでのバグ件数はどうやって数えていますか
例えばプロダクト品質を判定する情報の１つとして、システムテストでのバグの発見件数を使う事を想定しましょう。見つけたバグはどの部門がどうやって記録して、その件数は誰がどんな方法で数えているのでしょうか？ テストで見つかった問題点は、全てがバグではありません。テストのミスだったり、今の時点では制限事項だったりする場合もあります。これらのバグでは無い項目を取り除いた残りがバグなのですが、テストの記録としてはそれらも書き残されています。その中から、誰がどうやってバグの件数を数えているのか確認しておかないと、バグ件数が正しいかどうかが判らなくなります。
また、テストで見つかった問題点がバグかどうかの判定やその記録は、開発部門の設計者が行っているのか、テスト部門のテスト担当者が行っているのかは、各々の組織でのバグ管理の方法によって様々です。どんな方法で誰が行う事になっていても構わないのですが、複数の人が行う作業になるので明確なルールや基準が無いと人による判断のばらつきが出てしまいます。
バグの検出件数は、ソフトのリリース判定をする上で大切な情報なので、あまりばらつきがあっては困ります。ですので、その組織で誰がどんな基準に従ってバグの記録をしているのか、という実務の担当部署と具体的な実施方法を確認しておく事も大切になります。
（３）ソフト開発プロセス品質の確認機能
プロセス品質の確認という言葉を聞いて、皆さんは具体的にどんなアクションを思い浮かべますか？ プロセス品質の確認という考え方は CMMI のSQA/SQM による活動を想定した物なので、 CMMI の認定を受けている組織で仕事をした経験のある人には、この後の説明は不要かもしれません。
プロセス品質ってそもそも何？ というあたりからモヤーとしていますね。グータラ親父は、決められたソフトウ開発プロセスを守る事をプロセス品質と定義していました。例えば、プロジェクトの計画段階で設計レビューを28回実施すると決めたとします。この場合はレビューという開発プロセスのうち回数を規定したのですが、リリースまでにちゃんと28回の設計レビューができていれば、開発プロセスの品質は良いと判断します。逆に設計レビューが10回しか実施されていなければ、開発プロセスの品質は良くないですね。
開発プロセスとしては、レビューの回数だったり、レビューの指摘の記録やトレース方法だったり、レビューの実施予定日だったり、テストの開始日だったり、テストの量だったりと、いろいろな事が開発計画の時点で決められています。開発計画の時点では、そのような開発プロセスが必要だと判断したので決めたのです。なので、その開発プロセスがちゃんと実施されているかどうかを確認する事が、開発プロセスの確認になります。
そして、この開発プロセスの確認を誰が何時どんな方法で行っていてその結果をどう使っているの、というのがプロセス品質を確認する時の注意点です。
なお、CMMI では SQA担当者という役割の人が居て、開発プロジェクトの計画書を元に、計画された開発プロセスがちゃんと実施されているかどうかを、定期的に確認する事が求められます。ですので CMMI の認証を受けている組織なら、だいたいはできているのでソフトウエア開発監査では、CMMI の認証を取っていればこの確認は省略しても構いません。