システム／ソフトウェア開発に品質保証活動は必要なのか？
はじめにAutomotive SPICEのSUP.1やCMMIのPPQAでは、システム開発／ソフトウェア開発の品質保証活動に対する要求事項をまとめています。しかしながら、そもそもなぜシステム開発／ソフトウェア開発に品質保証活動が必要なのかを考えたことがありますか？今回は、SUP.1やPPQAの元となっている規格や書籍を参考に、「品質保証活動の必要性」について考えていきます。 品質保証の規格MIL規格（Military Standard）最初に品質保証が規格として体系化されたのは、MIL-STD-109で、1960年代後半に初版が制定されました。この中で「品質保証（Quality Assurance）」を以下のように定義しています。A planned and systematics pattern of all actions necessary to provide adequate confidence that management and technical planning and controls are adequate to: Established correct technical requirements for design and manufacturing. Create products and services that confirm to the established technical requirements.管理および技術計画と制御が次の事項に適切であるという十分な確信を与えるために必要なすべてのアクションの計画的かつ体系的なパターン。 設計および製造に関する正しい技術要件を確立する。 確立された技術要件に準拠する製品およびサービスを作成する。つまり「適切に正しい技術要件を定義して、適切にそれに準じた製品やサービスを作っている確信を得るための活動」が品質保証であるとしています。さらにその技術要件の重要な要素である品質要件についても以下のように定義しています。The technical requirements relating to the quality of the product (supply or service) and contract clauses prescribing quality standards, inspection, and other quality controls incumbent on the contractor, to assure that the product or service confirms to the contractual requirements.製品 (供給またはサービス) の品質に関する技術要件、および契約者に課せられた品質基準、検査、およびその他の品質管理を規定する契約条項で、製品またはサービスが契約要件に準拠していることを保証する。契約者（≒供給者）が、要件通りのモノを作ったことを保証するための契約事項（≒約束事）を品質要件と定めています。言い換えると、要件通りにモノを作ったことを対外的に保証する行為が品質保証活動だと言えるでしょう。ISO規格（国際標準規格）品質に関する国際標準は、皆さんもご存知のISO 9000シリーズです。1980年代に制定されましたが、その中のISO 9003が、特に「最終検査および試験における品質保証モデル」に焦点を当てた規格です。ISO 9003は、製品の最終検査と試験を通じて品質を保証するためのガイドラインを提供していました。ISO 9003は、長期間にわたって製造、設計、その他の使用方法が確立されている製品に対して、最終検査のみで品質を保証するための規格でしたが、2000年の改訂により、ISO 9001に統合され、より柔軟で包括的な品質マネジメントシステムの規格となりました。IEEE規格（電気・電子工学分野における国際標準規格）電気・電子工学分野における国際的な標準を策定するための組織であるIEEE（Institute of Electrical and Electronics Engineers）も、前述のMIL-STDをベースに1970年代後半に品質保証の国際標準を制定しました。IEEE Std 730IEEE Standard for Software Quality Assurance Processesがその規格であり、今もなお改版を続けています。この中で、Automotive SPICEやCMMI以上に詳細説明があるので、この規格を参考に必要性を整理していきます。この国際標準では、SQAプロセスの目的と以下のように定義しています。 「ソフトウェア開発プロジェクトが SQA プロセスを使用して、ソフトウェア製品が確立された要件に準拠していることを正当に証明するための根拠となる証拠を作成および収集できるようにすること」 やはり、品質保証を要件通りにモノを作ったことを対外的に保証する行為と位置付けています。 QAが準拠保証しなくてはならない要件とは Automotive SPICEのSUP.1でも定義されているように、成果物とプロセスの品質保証をする必要があるため、QAが遵守保証しなくてはならない要件は、プロダクト要件とプロセス要件になります。IEEE std 730では、契約事項である利害関係者要件から導出されたプロダクト要件とプロセス要件に対し、図にあるような適合関係の推移性に基づいて、1つ前の情報と比較し適合していることを確認することで、プロジェクト全体を通じて、「要件通りにモノを作ったことを保証する」こととしています。 契約事項と導出されたプロセス要件の適合を確認する プロセス要件と導出された計画やプロセス、標準や手順の適合を確認する 計画やプロセス、標準や手順と実際の活動結果の適合を確認するこのように、1つ前の情報との適合を確認することが、品質保証活動の基本的な考え方となります。 プロジェクト内のレビューやチェックだけでは品質保証は十分なのか？契約事項に基づいた「要件通りにモノを作ったことを対外的に保証する」必要性は、開発に携わった人であれば理解できることかと思います。それでは、その対外的な保証はプロジェクト内の活動だけで十分であると考えることはできないのでしょうか？先のコラムAutomotive SPICE SUP.1 本当に品質は良くなるの？でも引用した「プロセス成熟度の改善」（Watts S. Humphrey著日本語訳：日科技連出版社発行）には、客観的な品質保証の必要性を以下のように説明しています。監査者に対し客観的になることは、誰にとっても難しい。一般に、我々はかなり注意深く仕事をやっており、そうでないように言われると不愉快に感ずる。しかし、「外側から」のレビューを行うのは、釣り合いのとれた見方が必要だからである。たとえば、あなたがこれからパラシュートを包み終えて跳ぼうとしているとする。有能な検査者があなたの1つ1つの動作を監視して本当に正しく行ったということを保証してくれるならば、あなたの幸せになれる勝算は大きくなる。品質が決定的に重要な場合は、なんらかの独立したチェックが必要である。それはその人たちが信頼できないからではなくて、その人たちが人間だからである。ソフトウェアにおける問題は、チェックが必要かどうかではなく、誰がどうやるかである。小規後な組織では、しばしば管理者自身が作業を直接に監視できるので、SQAの活動は必要がない。部下の数が多くなるにつれて管理者は他の業務に巻き込まれ、次第に日常の技術的作業ができなくなってしまう。このような時には、管理者は次の事項の1つを行うことが必要である。 余分な負荷をうまく扱うなんらかの方法を見つけ、部下の仕事をより密接に監視できるようにする。 監視する人を雇う。 部下同士が互いに監視するように動機づける。技術的、経済的、そしてモラル上の観点から、最後の選択が一般には最も望ましい。残念ながら、歴史的にもソフトウェアの組織が数十人を越えてくると、この「ニ人一組方式」は崩壊してしまう。このような場合には、SQAによって解決しなければならないのである。 規模が膨らみ、複雑なシステム／ソフトウェア開発を行っているからこそ、管理者に代わって、「要件通りにモノを作ったことを対外的に保証する」客観的な視点が必要になるのです。当然ながら、管理者のサポートが、効果的な品質保証活動を行う大前提となります。 さいごに いかがだったでしょうか。今回は、改めて品質保証活動の必要性について考察してみました。皆さんの効果的な品質保証活動を行う動機付けになれば幸いです。 内山哲三