「品質」という言葉は、我々の世界ではよく使いますが、 品質とは何でしょう。 品質が良い／悪い、と言ったり、 品質を上げる、と言ったりしますが、 これがどんなものなのか、明確に認識しているでしょうか。 いろいろな人の話を聞いていると、 意外と認識が一致していません。
人によっては、検証の結果を見て言います。 「このモジュールは品質が悪いね」と。 人によっては、プロジェクト開始前に言います。 「前回のような品質問題は起こさないようにしよう」と。 人によっては、常に使います。 「品質を測定しろ、品質目標を立てろ」と。 それぞれの人が、それぞれの立場で、 主観で話すケースがほとんどです。
実は「ソフトウェアの品質」というものについては、 ISO 9126-1 という規格に定義がなされています。 もっとも、 品質という概念自体が社会通念上明確というわけではありませんから、 規格にあるからといってそれが唯一の正解、 ということにはならないかも知れません。 しかし、この定義が参考になることは事実です。 そこでまずは、ISO 9126-1 に記載されている 「品質」について整理してみたいと思います。
| ※ | ISO 規格は一般に日本語に翻訳されたものが JIS 規格として発行されています。 ISO 9126-1 に関していえば、JIS X 0129-1 になります。 発行年を併記すると、ISO 9126-1（2001）および JIS X 0129-1（2003）です。 元々はこの規格、ISO 9126（1991）だったものが改正されて ISO 9126-1 と ISO 14598-1（こちらの翻訳版は JIS X 0133-1） の２つになりました。 ２つを合わせると、1991 年版に比べて分量が格段に増えています。 1991 年版の方が簡潔にまとまっていて理解しやすいと思われますので、 もし旧版を入手できるなら、そちらから読んだ方がよいかと思います。 |
品質、というものは具体的な「物」として存在するわけではなく 「概念」ですから、「測定」という行為によって、 なんらかの測定値に置き換えて認識する必要があります。 つまり、品質を論じるには、本来、 測定とセットでなければならないのですが、 測定の詳細については 別の項 に記載することにします。 ここでは、ソフトウェアの「ライフサイクル」 の視点から、次の図（JIS X 0129-1 から引用）を用いて説明します。
この図は右から見ていくのが理解しやすいと思います。 ソフトウェアの品質に直接影響を受けるのは利用者です。 その段階での品質のことを「利用時の品質」と呼び、 利用者の必要性に合致するかどうかを表しているものになります。 これは利用状況によって異なります。 例えば、ある環境で十分満足に機能するソフトウェアも、 別の環境では障害を露呈するかも知れないということです。
「利用時の品質」に直接影響するものが「外部品質」です。 ソフトウェアが実行されるときの品質のことであり、 テストデータを用いたテストの結果（実行時のコードの振る舞い） などが該当します。 ほとんどの人が「品質」として認識するのはこれでしょう。 「利用時の品質」を代表するもの、と捉えることもできます。
「外部品質」に直接影響するものが「内部品質」です。 ソフトウェアの内部的な特徴で、 ソースコードのみならず、仕様書なども測定対象になるでしょう。 静的な測定によって得られるものがほとんどで、 例えばモジュール性（ソフトウェアが適切に構造化され、 変更、修正などが局所的なもので済むようになっている性質） や追跡可能性 （要求から実現されたものへの関連、 および実現されたものから要求への関連を追いかけることができる性質） などが該当します。
「内部品質」に直接影響するものが「プロセス品質」です。 プロセスとは設計／開発のやり方や手順のことです。 この「やり方」の品質が結果的にすべての品質に影響を及ぼす、 ということになります。
| ※ | だからこそ、「設計プロセス改善」は重要なのです。 |
ISO 9126-1 では、ソフトウェアの品質を分類して理解するために、 ここで示した「外部品質」と「内部品質」 を６種の特性に分類するモデルが採用されています。 まずは、この分類モデルについて理解することにしましょう。
ISO 9126-1 では「ソフトウェア品質モデル」 というものを定義しています。 それによれば、 ソフトウェアは仕様書やソースコードにおいて、 記述の長さやプログラム構造、表現の一貫性やクラス継承の深さ、 といった内部の実態に関する様々な「特徴」を持っています。 そして、利用者によってソフトウェアが利用されたときや、 ソフトウェアの開発者が開発を行なったときなど、 この「特徴」に起因した様々な現象に遭遇することになります。
このとき、測定可能で物理的または概念的な「特徴」、 とりわけ分解不可能で基本的な「特徴」のことを「属性」と言います。 この「属性」をある観点から整理し、 分類したものを「特性」と呼び、 「特性」を細かく分類したものを「副特性」と言っています。 特に、ソフトウェアの「品質」の観点から整理した「特性」 のことを「ソフトウェア品質特性」と呼んでいます。
つまり、ソフトウェアが持つ様々な特徴（属性） を品質の観点から整理したものが「品質特性」で、 品質特性をより細かく分類したものが「品質副特性」 というわけです。 これを図にしてみると、次のようになります。
ここで注意ですが、 それでは属性にはどんなものがあるのか、 と問うても答えはありません。 上記の考え方も、 「ソフトウェアの品質は、複数の『品質特性』という形で表現することができる。 『品質特性』に影響を与えている要素として 『特徴』／『属性』といったものがあるはずである。 また、『品質特性』は、 より細かく『品質副特性』というものに分類できると考えられる。 『特徴』／『属性』としてどのようなものがあるのかは対象依存である。」 といった程度のものです。 品質特性の種類は後述しますが、 例えば「関数の行数」という「属性」が、 「保守性」という品質特性に影響していると思っているのであれば、 そう解釈すればよいだけのことです。
上記の図は、属性というものが明確に存在して、 それらがいくつか集まって品質副特性を構成し、 さらに品質副特性がいくつか集まって品質特性を構成しているように見えますが （ボトムアップの方向）、 発想自体は逆（ブレークダウンの方向）です。 また、一つの属性が複数の品質副特性に影響を与えている場合があり、 一つの品質副特性が複数の属性に影響を受けている場合があるので、 完全な階層関係になっているわけではありません。
まずは大分類であるソフトウェア品質特性について見てみましょう。 ソフトウェア品質特性は、大きく６種に分類されています。 その名称と内容を記載します。
品質特性の大枠を飲み込めたでしょうか。 次に、各品質特性の品質副特性について見てみます。
機能性品質特性に関わる品質副特性には以下のものがあります。
「機能性」といったときに、多くの方が想像するのは、 上記の「正確性」という品質副特性だと思います。 つまり、定められた仕様に対して正しく動作するか、という視点ですね。 でも、「機能的に正しいかどうか」を論ずる際には、 上記のその他の品質副特性が関係するということは理解できると思います。
最後の「標準適合性」は、他の品質特性にも出てきます。
信頼性品質特性に関わる品質副特性には以下のものがあります。
使用性品質特性に関わる品質副特性には以下のものがあります。
効率性品質特性に関わる品質副特性には以下のものがあります。
保守性品質特性に関わる品質副特性には以下のものがあります。
移植性品質特性に関わる品質副特性には以下のものがあります。
利用時の品質は、特定の環境および特定の利用状況で利用されるときの、 利用者の視点でのソフトウェア製品の品質です。 これはソフトウェア自体の特徴を測定することによって認識されるわけではなく、 ある環境において、利用者が目標を達成することができる程度を 測定することによってはじめて認識することができます。 同じソフトウェア製品でも、利用者が異なれば結果（認識される品質の度合） は違います。 利用者は自分に関係するソフトウェアの属性のみを暗黙のうちに評価するからです。
ISO 9126-1 では、利用時の品質を次の４種の特性に分類しています。
利用時の品質には副特性が定義されていません。
ここで、前述までの品質特性を図にして俯瞰してみましょう。 下図も JIS X 0129-1 から引用しています。
品質というものを上述のように捉えることは重要です。 品質を考える際の観点が整理されているので、 これを利用してソフトウェア品質を仕様化したり、 評価項目を設定する際の漏れを防止したり優先度付けを行なうことができます。 また、品質目標を設定するようなときにも大いに参考になるでしょう。
例えば、移植性を判定するために、 ソースコードを直接レビューして、 機種依存部分が１つのファイルに収められているかどうかを検査する、 という方法があります。 これは内部品質を静的に測定していることになり、 この測定結果をもって、移植性の善し悪しを「予測」していることになります。 一種の指標です。 対して、実際に移植作業が発生したときに、 移植作業に要した時間や人員数を測定する、という方法もあります。 これは外部品質を動的に測定していることになり、 現象が発生した事後の測定、ということになりますが、 直接の測定です。
品質に影響を与える「属性」としてどのようなものがあり、 それはどのようにして測定することができ、 それらはどの品質特性に影響するのか、 ということはソフトウェア開発組織ごとに自分で考えるしかないと思います。 上記の例でも、 移植性に影響する属性としてどのようなものがあるかということと、 その属性の測定結果と実際の移植性との関連性を将来にわたって追跡し続ける （データを蓄える）ということも管理上重要（予測精度を高めるという意味で） かも知れません。