ソフト開発監査の監査当日（４）組織の概要と規模の把握（後半）
（４）開発プロセスの確認チームは在るか
開発プロセス確認チーム（SQA:Software Quality Assurance ）とはソフト開発の開発プロセス品質を保証するために活動するチームです。SQAとはCMMI が使っている用語で、CMMIはこの機能が組織に在る事を要求しています。
ソフトの開発現場では、開発工程の後半、特にリリースが近づくにつれて工数不足や工程遅れが顕著になってくる場合が多いです。その時に、工程挽回のために、当初計画していたレビューやテストを間引きするというような悪手（悪魔の囁き）を対応策として使ってしまう事も起こりえます。
そのような事が起こさないように、正常なソフト開発プロセスが守られている事を確認して、問題があれば開発プイとジェクトの責任者に報告して対策を求めます。そうるす事で、ソフト開発プロセスの品質を保証するのが開発プロセス確認チームの役割です。
開発プロセス確認チームがあれば、その組織はソフト開発プロセスの維持という面で安心できるといえるので、このようなチームがあるかどうかの確認がポイントとなります。またチームがある場合には、この１年ほどの期間に何件程度の問題点の指摘をしたか、などで活動の成果を確認する事も役に立ちます。
プロセス品質とプロダクト品質は分けて考えましょう
ところで、SQA の元の英語の Software Quality Assurance を日本語に直訳するとソフト品質保証となります。しかし、CMMI の定義する Software Quality Assurance はあくまでもソフト開発のプロセス品質の保証です。一方で日本語でソフト品質保証というと、それはプロセスのプロダクト品質つまりソフトそのものの品質の保証を指します。
ちょっとややこしいのですが、ソフトにはプロダクト品質とプロセス品質という２つの品質がある、という点に気を付けておいてください。ソフトそのものの品質はプロダクト品質です。常に良いプロダクト品質のソフトをリリースするためには、良い開発プロセスでソフトを開発する事が大切です。
CMMI は良い開発プロセスで作られたソフトは良いプロダクト品質になる、という前提でプロセス品質の良し悪しを評価するために考えられた手法です。ですので CMMI ではプロセス品質の保証の事を、 Software Quality Assurance と呼んでいます。
ですが、先ほども言ったように、日本語でソフト品質保証といえば、やはりソフトそのものの品質、つまりプロダクト品質を指すので、話がややこしくなります。グータラ親父は、ややこしいのがいやなので、英語の略称の SQAは使わずに、プロセス確認チームという言葉を使っています。
（５）プロセス改善チーム（SEPG) 在るか
プロセス改善チームは、ソフトの開発プロセスそのものを作ったり改善したりするチームです。開発のためのルールや手順や場合によっては標準的なワークシートを作ったりするチームですね。プロセス改善チームも CMMI がソフト開発のために必要としている組織です。Software Engineering Process Group の頭文字をとって SEPG という略称で呼ばれる事も多いですが、グータラ親父はSQAと同じようにプロセス改善チームという呼び名を使っています。
ソフトの開発プロセスは、一度決めても数年すると実態と合わなくなる事が多いです。新しい開発方法論が出てきたり、新しい開発支援ツールがでてきたりと、開発プロセスの変更が必要な機会が割と頻繁に起こるからです。そのような開発環境の変化に合わせて、開発プロセスを決めているルールや手順の変更や改善を専門に扱うチームがあると、開発プロセスの改善がタイムリーに進むので、いつも最適な開発プロセスを維持する事ができます。
ですので、プロセス改善チームについて確認する時には、そのようなチームが在るかどうか、プロセス改善チームがある場合にはどの程度の頻度で活動しているのか、という点に注意して確認します。
（６）ソフト品質保証部門は在るか
ソフト品質保証部門という名前にしていますが、ここで確認するのはそのような名称の部門があるかどうかではなく、ソフトの品質保証の活動として何があってそれをどの部門や組織が担っているか、という点です。
ソフトの品質保証活動もいろいろな項目があるのですが、大切な順番に３つを挙げると以下のようになります。
- ソフトのリリース判定（品質の悪いソフトをリリースしない）
- プロダクト品質の確認（ソフトの品質の良し悪しを判断する）
- プロセス品質の確認（正しい開発プロセスが実施されているか確認する）
まず一番大事な事が、１つ目の品質の悪いソフトをリリースしないという事になります。なんか、わざわざ確認するのも可笑しくなるほど当たり前の話なのですが、では誰がどんな基準でソフトのリリースの可否判断をしているのか？ となるとこれは組織によってまちまちです。
そして、リリース判定の時に大切なのが、どうやってリリースの可否を判定するのかという事です。言い換えれば、ソフトの品質の良し悪しを判定するために、どんな情報を集めてどんな基準で判定するのかです。これが２つ目のプロダクト品質の確認です。
そして、良い品質のソフトを作るために必要なのが良い開発プロセスに従ったソフトの開発なので、その品質状況を確認するのが３つ目です。
これらのソフト品質を保証する上で大切な活動を、どの部門で実施しているのかを確認するのが、このソフト品質保証部門の確認でのポイントです。
(７)工場の工程内検査ソフトの担当チームは在るか
ここまで見てきたチームや組織は、どれも製品に搭載されて出荷されるソフトの品質に関わるものですが、最後の工場の工程内検査ソフトの開発を担当するチームというのは対象とするソフトが異なります。
ソフトを搭載する製品を製造する工場では、製造工程のあちらこちらで、製品が正しく製造されている事を確認する検査をしています。この検査は、たいていは製品に搭載されているソフトに組み込まれている自己検査機能と、検査の指示や検査結果の収集を行う工場内の検査システムとが連携して機能しています。
これらの、自己検査機能と工場内の検査システムも、その実態はソフトですので誰かが開発しています。その誰かというのに勝手に名前を付けたのが、工程内検査ソフトの担当チームです。一般的な名称ではないので、会社によってあるいは工場によってその呼び名は変わります。ただ、この工程内検査ソフトの担当チームも、製品の品質保証には重要な役割を持っていて、かつソフトではあるので、どこにそのチームが所属するのかなど組織上の位置を確認しておきます。