Automotive SPICE SUP.1 本当に品質は良くなるの？
今回は、品質保証に関する話題をご提供いたします。 プロセス改善モデルには、品質保証というプロセスが定義されています。 Automotive SPICE では、SUP.1（品質保証）、CMMI v1.3では、PPQA（プロセスと成果物の品質保証）というプロセスが該当します。（CMMI v2.0/3.0では、品質保証の考え方が多少変わってきていますので、後述いたします）
さて、これらのプロセスを実装することで、良い品質の製品をリリースできるでしょうか？
筆者は、本件については甚だ懐疑的です。というのも、これまで自身の担当するプロジェクトで、単純にAutomotive SPICEのSUP.1プラクティスに記載されている内容を実施してきましたが、効果を感じられませんでした。また、多くの組織やプロジェクトを見ても、状況はあまり変わりません。はじめてSW-CMM（CMMIの前身モデルです）というモデルの導入を検討していたとき、SQA（ソフトウェア品質保証）プロセスとは、「プロジェクトが、決められた方法（約束事）に従って活動していることを評価する」ということだと知り、これで品質が担保できるのかと不思議に思ったものでした。
これらの原因は、品質保証活動 ＝ プロセス監査 という考え方になってしまっていることにあると考えています。 確かに Automotive SPICE SUP.1の各プラクティスを見ても、監査すれば十分であると読めてしまうところがあると思います。 また、プロセスモデルでは「品質管理」というプロセスが別に定義されていることもあり、このような実装になってしまうことも仕方ないかもしれません。
しかしながら、せっかく品質を保証する活動を導入するのであれば、もう少し実際の品質に寄与できる活動にしたいとは思いませんか？ 重箱の隅をつつくような作業や、不遵守が発見されない監査項目に多くの時間をかけて作業するのは勿体ないですよね。ここからは、こういった現象に気付いた私たちが実践してきた、品質保証活動の刷新についてご紹介いたします。
まずは、本当の意味での品質保証活動について考え直すことから始めました。
一番参考になったのは、「プロセス成熟度の改善」（Watts S. Humphrey著 日本語訳：日科技連出版社発行）です。この本は、私たちが赤本と呼び、プロセス改善のバイブルとして長年使っているものです。品質保証として評価すべき観点を列挙し、それぞれの開発工程で確認すべき点をまとめました。下記に概略を記載しますので、参考にしてください。
-
構成管理 ：計画とその遵守、設計書・ソースコード・テスト仕様、構成監査
-
レビュー ：レビュー計画と運営状況の確認、各工程のレビューへの参加と品質確認
-
監査 ：プロセスの遵守性
-
要求仕様 ：顧客要求の合意形成、要求のテスト可能性、要求毎の進捗状況
-
設計 ：開発進捗、レビュー摘出率、コードメトリクス、トレーサビリティ
-
テスト ：テスト計画、不具合発生と解決データのトレース、テスト報告書
-
ツール ：使用ツールの妥当性、ツール使用状況
-
修正処置 ：変更依頼の状況、修正手順、各工程の修正の開始から完了までの状況、問題原因の傾向
-
外注先 ：外注先の品質保証プロセス、設計標準の確認、品質データの把握
-
計画 ：計画の妥当性、計画変更の妥当性、計画に対する進捗状況
-
出荷 ：レビュー・テスト指摘解決状況、テスト報告書、出荷審査
こうしてみると、かなり実施すべきことがあると思いませんか？
次に品質保証活動の役割分担について考えました。
本来の意味での品質保証活動を実施するにあたり、品質保証活動の役割を次のように細分化しました。
-
品質システム担当 ：品質システムの構築・運用
-
品質分析担当 ：各プロジェクト品質データの取りまとめ・分析・報告
-
内部レビュー担当 ：プロジェクト内部のレビュー実施者（開発者）
-
外部レビュー担当 ：プロジェクト外の開発者、品質保証グループによるレビュー実施者
-
プロセス監査担当 ：プロジェクトの監査実施者
品質保証活動プロセスの（再）定義
品質保証活動の観点と役割から、品質保証グループとして実施すべき活動とプロジェクトの品質保証活動の２つに分けて、品質保証活動のプロセスを定義しました。プロセスの概要は、導入事例（品質保証活動の刷新）を参照してください。
気が付いている人も多いようですが、監査だけでは品質は良くなりません。品質保証に携わる組織としては、プロジェクトの品質データを収集し、そのデータをもとに品質課題を解決する活動が重要です。 長年の開発経験からわかることは、重大な不具合はソフトウェア全体が悪いわけではなく、ある特定のコンポーネントの不出来が起因して起こるということです。 これらを如何に開発途中で見つけるかが品質保証活動のキーポイントとなるはずです。 いつまでも設計が終わらない機能、規模が膨大になっているソフトウェアコンポーネント、コードメトリクスが例外値を示しているソフトウェアユニット、多くの不具合が発生している機能など、これらを調査することで未然に予防できることがあるはずです。
Automotive SPICE SUP.1や、CMMIを取り巻く環境も近年変化が見られるようです。 欧州の自動車メーカーからは、プロジェクトの品質データを毎月提出することが求められるようになりました。 CMMI v2.0/3.0では、「品質の確保」という属性の中に４つのプラクティス領域（ピアレビュー、プロセス品質保証、要件の開発と管理、検証と妥当性）を設け、従来のPPQAプロセスだけでなく他のプロセスを品質に結び付けています。 皆さんも、監査だけの品質保証から、本質的な活動に移行してみませんか？
日吉 昭彦