開発における「品質」をどう考えるか：理論的、計画的なWebアプリケーションのテストの実現

感覚的なイメージで考えられがちな品質をさまざまな角度からのデータで分析する傾向がますます強くなっている。品質について再考してみよう。

[加藤大受，ITmedia]

　2005年はテストに関する書籍や専門誌が数多く発刊され、開発の中で脇役のように考えられていたテストの存在が一躍注目されるようになりました。

　一方、海外の多くの企業および国内の一部の企業では、品質についての責任を持つCQO（Chief Quality Officer：最高品質責任者）という役職が設置され、CTO（最高技術責任者）が技術部門の総責任を持つように、CQOが品質に関する総責任を持つようになっています。

　品質の低下や低い品質がビジネスに与える影響をリスクとして考えることが一般的になり、感覚的なイメージで考えられがちな品質をさまざまな角度からのデータで分析する傾向がますます強くなっているわけです。しかし、品質とはユーザーの満足であるという観点から考えた場合、どんなに詳細にデータを分析しても、開発者とユーザーとの品質についての感覚の差は発生するとも言えます。ここでは品質について少し考えてみたいと思います。

バランスとしての品質

　プロジェクトを立案するときは、コスト（Cost)、スケジュール（Delivery）、品質（Quality）のバランスを考えます。この3つのことをそれぞれの頭文字をとって「QCD」と表記することがあります。プロジェクト管理について体系的にまとめたPMBOKでもこの3つは直接成果に影響する管理項目として重要としており、QCDについての意識を持って製品開発を行うことが望ましいとされています。

　プロジェクトマネージャーを経験している方であればご存じでしょうが、QCDにおいてコストを優先すればスケジュールや品質に大きく影響し、スケジュールを優先すれば品質やコストに大きく影響します。この3つのバランスがうまく保てているとき、プロジェクトは順調であるといえます。

　しかし、バランスを保てているからといって品質が必ずしも良いわけではありませんし、このバランスもP/L（Profit and Loss)の観点から考えなければビジネスとして成り立たなくなります。ただ、QCDに対して逐次進捗を明確にしておくことで、進捗をきちんと把握できますし、プロジェクトの経過が明らかになるといえるでしょう。

図1.QCDのバランス

　QCDのバランスをより詳細に考えるには、米国防総省が欧州の国防関連の政府機関と協力して開発した手法で、公的機関のIT調達に用いられている「アーンド・バリュー・マネジメント」（Earned Value Management：EVM）と呼ばれるプロジェクトの達成度を測る手法を利用すると良いでしょう。

　EVMは作業予定分の予算コストである「BCWS」（Budget Cost of Work Scheduled）、完了した作業を累積し、時系列でグラフ化する「BCWP」（Budget Cost of Work Performed）、完了した作業に費やされた実コストを時系列でグラフ化する「ACWP」（Actual Cost of Work Performed）という3つの基本データを使い、プロジェクトの進捗を可視化します。そして、これらのデータを基に、コスト超過やスケジュールの遅れ具合を計算するものです。国内でも経済産業省がEVMを導入し、政府のIT調達に活用しようとしています。すでにプロジェクトマネージャーとしてさまざまなプロジェクトに携わっている方はぜひEVMを学んでみると良いでしょう。

　では、QCDのバランスの中の「品質」はどのように考えば良いのでしょうか。これを考えるにはまず品質とは何かを正確に把握することが必要です。

ISO/IEC9126の品質特性

　「品質はユーザーの満足度」であると考えた場合、品質は何を示しているのでしょう。満足度という表現である以上、製品の使い勝手、機能、性能、信頼性だけでなく、問い合わせに関する返答時間や応対の態度など、満足度は人によって感じ方が大きく異なります。このため、満足という尺度ではなかなか品質を計ることはできません。

　また、ISO 8402:1994において品質とは「明示又は暗黙のニーズを満たす能力に関する、ある“もの”の特性全体」と表現されています。では品質はどんな尺度を利用すれば計ることができるのでしょうか。

　品質を考えるときの方法として、品質を複数の性質に分けて分類することで数値化が可能になります。この性質についての基準がISO/IEC 9126の「ソフトウェアの品質特性」です。ISO/IEC 9126は翻訳され、「JIS X0129:ソフトウェア製品の評価−品質特性及びその利用要領」として国内でも基準とされています。

　JIS X0129:2003では品質特性は6つの品質特性から構成されています（表2）。また、それぞれの品質特性がさらに細分化されて副特性を持っています。この品質特性を使って実際に品質の分析を行うことで、品質を数値化できるでしょう。

　ただし、この標準は品質特性要素を網羅的に並べ立てているだけですので、特徴的な要素から選択して使用していくことをお勧めします。JIS X0129についてもっと詳しく知りたい方は日本工業標準調査会（jisc)のWebサイトを閲覧してみると良いでしょう。

●表2　JIS X0129:2003 品質特性

表2.JIS X0129:2003 品質特性 特性 副特性 説明 機能性 合目的性 ソフトウェアが、指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力 正確性 相互運用性 セキュリティ 機能性標準適合性 信頼性 成熟性 指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力 障害許容性 回復性 信頼性標準適合性 使用性 理解性 指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力 習得性 運用性 魅力性 使用性標準適合性 効率性 時間効率性 明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力 資源効率性 効率性標準適合性 保守性 解析性 修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、又は環境の変化、要求仕様の変更及び機能仕様の変更にソフトウェアを適応させることを含めてもよい。 変更性 安定性 試験性 保守性標準適合性 移植性 環境適応性 ある環境から他の環境に移すためのソフトウェア製品の能力。 　　　備考：環境には組織、ハードウェア又はソフトウェアの環境を含めてもよい。 設置性 共存性 置換性 移植性標準適合性

品質を考えたテストの計画／設計／実施

　ISO/IEC 9126の品質特性を利用することで品質は分析可能ですが、品質を向上させるには、やはりテストを計画し、品質特性を考え設計し、実施していくことが必要となります。これは筆者がこれまで連載の中で何度も繰り返し述べてきたことです。

　どのようなテストを行うことで品質のどの部分が分かるのかが理解できていなければ、テストを実施して分かることはテストの結果だけとなります。テスト結果を品質分析につなげるためにも、品質をどう捉えるかをまずは考えてみると良いでしょう。さまざまな過去のプロジェクトを分析し、社内の品質基準を作り、それを活用することも品質分析や品質向上の効果があるでしょう。品質基準の考え方についてはまた別の機会に説明したいと思います。