品質とは何か

ソフトウェアにおける品質とは、指標をどの程度満たしているかです。指標は定量的に測定できるものとできないものがあります。良い品質とは、多くの指標を高いレベルで満たしたものと言えます。

指標の種類

ソフトウェア業界の広がりとともに、指標の種類も変化してきました。昔は、RASがありました。

RAS: Reliability（信頼性）、Availability（可用性）、Serviceability（保守性）

その後、これにISが加わりRASISになりました。

RASIS: RAS + Integrity（完全性）、Security（安全性）

現在、日本のIPA:独立行政法人情報処理推進機構における情報処理技術者試験においては、FRUEMPおよびその副特性となっています。なお、FRUEMPはここでの便宜的な覚え方・呼び方であって、単語として存在していません。

FRUEMP: Functionality（機能性）、Reliability（信頼性）、Usability（使用性）、Efficiency（効率性）、Maintainability（保守性）、Portability（移植性）

これらは、ISO/IEC9126 ソフトウェア製品の評価 - 品質特性とその適用に関するガイドラインとして国際規格となっています。

品質特性	適用
機能性	機能の集合と、その仕様化された性質の実現をもたらす属性の集合目的性、正確性、相互運用性(接続性)、標準適合性、セキュリティ
信頼性	明示された条件の下で、明示された期間、ソフトウェアの実行のレベルを維持するための能力をもたらす属性の集合成熟性、障害許容性、回復性
使用性	明示的または暗示的な使用者の集合が、使用するために必要とする労力、および個々の仕様結果による評価をもたらす属性の集合理解性、習得性、運用性
効率性	明示的な条件の下で、ソフトウェアの実行のレベルと使用される資源の量との間の関係をもたらす属性の集合時間許容性(実行効率性)、資源効率性
保守性	仕様化された改訂を行うのに必要な労力をもたらす属性の集合解析性、変更性、安定性、試験性
移植性	ある環境から他の環境へソフトウェアを移す能力をもたらす属性の集合環境適応性、移植作業性(設置性)、規格適合(準拠)性、置換性

業務における品質指標

FRUEMPを業務に適用するために、皆さんの業務に合わせてブレイクダウンする必要があります。また、極力定量化できるようにします。定量化できない感覚的なものだと、人によって評価が分かれてしまいます。人はスキルも違いますし好き嫌いもあり、文化の違いもあるからです。広く使われているものに、以下があります。

[共通]

フェーズごとのレビュー結果（指摘数、指摘種類、実施時間と参加人数）、フェーズごとの開発工数

[管理]

質問・回答件数、課題・タスクの件数、課題の種類、課題完了数

[要件定義、設計フェーズ]

仕様書のページ数

[製造フェーズ]

ソースの全体ステップ数、実効ステップ数、コメント率

[テストフェーズ]

テスト項目数、ソースの実効ステップ数に対する項目数の割合、故障件数、故障の種類、故障発生の収束状況

定量化が難しい指標

ソフトウェア開発の中で、品質向上のための活動を行うとき、どうしても定量化できないものも現時点では存在します。しかしそれらも業界が進化していく中でいずれ解決されていくと思います。人が見て、度合いを十段階評価などすることはできますが、恣意的な評価になる恐れもあります。複数人で見て、平均値を取ってもいいかもしれませんが、そこまで工数をかけられるかはまた別の問題です。ここでは、定量化が難しいものを挙げてみます。

[美しさ、洗練度]

仕様やソースコードを読んで美しいと感じたり醜いと感じる、その感性。

[満足度]

使い手だけでなく、作り手の満足度や喜び。職人魂の発揮度合い。

[手になじむ度合い]

直感的に使えるか、覚えやすいか、かゆいところに手が届くか。右利きの人が作った場合、左利きの人でも違和感を感じないか。

[グローバル対応性]

他国に持って行ったとき、そのまま使えるか。文化や宗教に合わせた修正が必要になるか。

バグを出すこと

バグ(故障)は、どのようなソフトウェアにも必ず存在します。テストは、ソフトウェアで実現したいことをバグによって阻害される確率を問題のないレベルにまで下げる活動です。問題がある・ないは、ソフトウェアが実現する業務によって差があります。例えば、銀行のATMシステムは、バグによって使えなくなってしまうと社会的に大きな問題になるのでテストに多大な工数をかけます。あなたの会社の社内掲示板システムは、おそらく保守のため半日ダウンしていてもあまり大きな問題にはならないと思います。（え、なります？）

テストはバグがないことを確認する活動ではなく、定義した指標通りに適切な数を摘出し、適切に直して運用時にバグが出る確率をほぼなくす活動です。出たバグは内容やなぜ出たかを分析し、他にも潜んでいないか探します。テスト時には、バグが出たら嬉しいと思わなければなりません。

ところが、バグが出過ぎても問題になります。設定した指標を大きく超えてバグが出てしまったら、原因追究と対策を講じる必要があります。なにより、顧客に説明できません。バグが出たけど問題ないとは言えません。多くの場合、追加の品質向上活動を行うことになります。これは費用は顧客に請求できません。品質強化試験などの名目で追加のテストを行います。一番困るのが、結合テストを始めたら単体テストレベルのバグが頻発してテスト進行が滞ることです。プロジェクトマネジャーは、このまま結合テストを進めるか、一旦結合テストを停止して単体テストをやり直すかの判断を迫られることになります。

不具合とバグの違い

不具合とバグは異なります。不具合は、バグと確定する前の段階です。システムに何かおかしい、変な挙動が発生した場合、原因をつきとめる活動を行います。それが故障管理（障害管理、バグ管理）です。故障管理の中で、何かおかしいと皆に知らしめるために故障処理票（障害連絡票）という伝票を使います。故障処理票を書き起こすことを起票といいますが、起票した時点ではその現象はバグと決まっていません。ですので不具合という言葉を使います。不具合の原因をつきとめ、それがバグだとわかった場合、バグと確定します。バグと確定したらバグを是正する活動が開始され、非バグであれば何も起こりません。

レビューの種類

品質確保の活動として、レビューがあります。レビューは多くの開発フェーズで行われます。設計書も、ソースコードも、テスト項目もレビューの対象になります。レビューには、以下の種類があります。

種類	実施方法
ウォークスルー	レビュー対象の手続きに対して、いくつかのテストケースを用意し、机上で手続きををシミュレートして妥当性を確認する。
インスペクション	目的を決め、資料を事前に配布し、モデレータ(責任者)のもとで一堂に会してレビューを行う。体系的、公式的。
プロトタイピング	目的とするソフトに対して、画面の一部やサンプルプログラムを用意し、実際に動かしてレビューを行う。
ラウンドロビン	レビューに参加したメンバが持ち回りで責任者を務めながら、全体としてレビューを進めていく。
シミュレーション	システム(ソフト)のシミュレーションモデルを設定し、数学的近似値を用いて実際の動きを評価する。