69号：品質特性
≣ はじめに
「ASTERセミナー標準テキスト」の57ページについてです。
今回は、「品質特性」です。前回、「『品質特性』を参考にすると、テストタイプの抜け漏れを防止できる」と書きました。
「品質特性」については、「知ってる、知ってる。キュー・イチ・ニー・ロクの『キシシコホイ』（※）でしょ」という人が多いので、一つひとつの品質特性の意味は調べ方を書く程度として、ここでは「品質特性」そのものの話を中心に書こうと思います。
もちろん、暗記することは、『悪くない』（©️ 美食探偵）です。
※ 『キュー・イチ・ニー・ロクの、キシシコホイ』とは、ISO/IEC 9126-1:2001（JIS X 0129-1:2003）という国際標準の「外部及び内部品質のための品質モデル」の6つの主特性である、「機能性」、「信頼性」、「使用性」、「効率性」、「保守性」、「移植性」の読みの1文字目を並べた語呂合わせです。
ルート5の値（2.2360679）を「富士山麓オウム鳴く」と覚えるようなものです。
『キシシコホイ』の用途としては、例えば、基本設計のレビューの時に、この語呂合わせを思い出して、「キミキミ、保守性や移植性は考慮しているかい？」というと、ちょっと良い指摘に聞こえる（かもしれない）とか、そんな感じです。
ところで、今は、9126は25010（キャッチイメージ）に置き換わっています。主特性について、「互換性」と「セキュリティ」が増えて8つになったので、25010の語呂合わせは聞いた事がありません。『キセゴシシセホイ』では長いですし。また、漏れなく覚えることも（何かの試験対策には）大切かもしれませんが、それよりも、時代の変化にともなって何が増えたのかのほうが重要です。そこで、私は、「キシシコホイ ＋ 互換性（特に相互運用性）とセキュリティ』と覚えています。（効率性が性能効率性という分かりやすい呼び方になったことにも注意が必要です）
※ 例えば、「IoTの時代になって、様々な機器の相互運用性と、セキュリティがますます重要となってきた」といったように、時代背景とセットで考えることが大切と思います。
……ということで、暗記しなくても良いとは思いますが、知っていると、テストの実行時にふと思い出してテスト実行内容が充実するなど、何かと良い事があります。
ところで、いまだに9126の品質特性を元にしたウェブや雑誌の記事をみかけることがあるのですが、そんなとき、「知識のアップデートをしてください」と思います。（25010が公開された2011年から9年も経つのですから）
それから、ISO/IEC 25000シリーズのことを「SQuaRE シリーズ」とも呼びます。興味がある方も無い方も、『システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要』をお読みください。
≣ 情報源
最初に「品質特性」についての情報源について書きます。それぞれの品質特性の定義やメトリクスの計測方法などを参照できます。
まずは、規格書ですが、『JIS X 25010. ：2013 (ISO/IEC 25010：2011)』となります。次に、IPAから出ている『つながる世界のソフトウェア品質ガイド』を読むと良いでしょう。（PDF版を無料でダウンロードできますが、小冊子を買って手元に置いておくと便利です）
ソフトウェアテストをしている方は、どんな事が書いてあるのか、両方ともパラパラと、流し読みで構いませんから、一度は目を通すことをお勧めします。
なぜお勧めするかというと、使う機会が多いことと、ISOもIPAも権威なので「国際標準と整合性を取りたい」等と、他人を説得するときの根拠として使えるからです。
≣ 品質特性とは（quality characteristic）
ソフトウェア品質特性： ソフトウェア品質に影響を及ぼすソフトウェア品質属性の分類。
注記 ソフトウェア品質特性は，複数の階層の品質副特性及び最終的にはソフトウェア品質属性に精緻化することができる。
出典：JIS X 25040：2014
まず、品質とは何かについて復習します。以前、「46号：品質の定義 その変遷（後編）」で、以下の「品質」の定義を載せました。
品物又はサービスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体。
出典：JIS Z 8101:1981（品質管理用語）の定義
ここでいう「評価の対象となる固有の性質・性能」が、ソフトウェア品質特性の定義の中にある「品質属性」です。
そして「品質属性」（quality attribute）をカテゴライズしたものを「品質特性」（quality characteristic）と呼びます。
ISO 25010の品質特性は、「主特性」（例えば、キャッチイメージの「機能適合性」など）を「副特性」（例えば、「機能適合性」の下にある「機能完全性」、「機能正確性」、「機能適切性」）に分解し階層化したモデルとなっています。
副特性をさらに自分のテスト対象に対して、展開していった時の末端が「品質属性」というわけです。
≪補足≫
先に紹介した東先生の概要に、「ISO/IEC JTC1/SC7/WG6 では、ISO/IEC9126 の当初より品質（Quality）の定義を、ISO8402 Quality Vocabularyを出発点としている。」、「ソフ トウェア品質：明示された状況下で使用されたとき、明示的ニーズ及び暗黙のニーズをソフトウェア製品が満足させる度合い。（JIS X25010 品質モデル）」とあります。
≣ 品質特性はいかにして生まれたのか
品質特性を「品質のモデル」と思っている人は割と多くいるように思います。上に書いたように、品質特性は、「品質属性のモデル」です。品質属性は、「評価の対象となる固有の性質・性能」でした。つまり、品質属性は評価できるということは、「測定できる」ものです。
JISの品質の定義は「品質属性を全部集めたもの」です。だったら「品質のモデル」も「品質属性のモデル」も同じでは？ と思われるかもしれません。それに対しては「測定出来ること」は品質に対する必須要件ではないと言いたいです。「品質は利用者の心の中に湧き上がるもの」と言っても良いのですが、言い換えても分かりやすくなった気がしないのでこの話はここまでとします。
品質特性が生まれた理由は、品質の良し悪しを簡単に言えないところから来ています。よく、「カタログだけ見てもわからない」と言います。100万円するカメラも、1万円のカメラもカタログを見る限り、それほど変わらないように見えるためです。ましてや、100万円のカメラと50万円のカメラではどうでしょう？ ひょっとしたら画素数や機能数は50万円のカメラの方が上かもしれません。
でも、その業界のプロが決めた値付けですから、トータルの品質は100万円のカメラの方がおそらく高いのでしょう。
ここで、カメラの品質は画素数や機能数だけで決まるものではないということについて分かってもらえたと思います。カメラでいえば、レンズの明るさや歪みのなさ、色味の再現性、露光の確かさ、操作性の良さ、壊れにくさ等々、「複数の特徴を総合して決まるものが品質」ということです。
そこで、それらの特徴の一覧（セット）が分かれば、それを評価すれば良いという考えが広まりました。つまり、「評価すべき特徴＝品質属性」を明らかにして、それらを評価（出来栄えを計測）することで品質についての確信を高めようというアイデアが生まれました。
ソフトウェアにおける複数の特徴とは何か？ 何と何と何と何・・・によって品質は決まるのか？
Boehm（1973）をはじめとし、様々な人が、様々なモデルを作りました（品質属性の抽象化をしました）。
「はじめとし」と言うのは「有名」と言うほうの意味で、Boehmが最初に言い出したと言うことではありません。1960年代からありました。
ここで、様々なモデルと書きましたが、商品Aと商品Bの品質を比較したい時には、同じモデルを使用する方が比較が容易です。そこで、国際標準を作ろうということになり、Boehmの階層型品質モデルなど、複数のモデルをもとに、ISO/IEC 9126が1991年にできました。そして、10年後の2001年に、ISO/IEC 9126-1として改定され、さらに10年後の2011年に、ISO/IEC 25000シリーズの25010として改定されました。
さらに10年後の2021年に改定はあるのでしょうか？
≣ 「利用時の品質」と「データ品質」
キャッチイメージの図は「システム／ソフトウェア製品品質」ですが、その他に、「利用時の品質」と「データ品質」もモデル化されています。「利用時の品質」は、9126の頃からありましたが、「データ品質」は25010からです。AI商品はもとより、データの良し悪しで品質が決まるものが増えてきたからです。
例えば、カーナビの地図情報（マップデータ）はデータですが、どういう特性を測れば良い地図情報と言えるのか知りたいですよね？
ISO/IEC 25010では、下記のデータ品質モデルにまとめられています。
◆固有のデータ品質特性
正確性、完全性、一貫性、信ぴょう性、最新性
◆固有及びシステム依存のデータ品質特性
アクセシビリティ、標準適合性、機密性、効率性、精度、追跡可能性、理解性
◆システム依存のデータ品質特性
可用性、移植性、回復性
≣ 終わりに
品質特性について見てきましたが、詳細は上にあげた規格あるいは冊子を参照してください。テストタイプは、これらの品質特性の主特性、副特性をテスト対象の言葉に書き換えて使用します。
主特性や副特性をテストタイプ名にしても構いませんが、冊子に記載されている計測方法については、そのまま使うのではなく、必ず「自分のソフトウェアでいうとXXだな」と書き換えて計測方法と目標値を決めます。また決めた内容に対して、関係者でレビューし、合意することが大切です。
というのは、品質特性には、「あちらを立てると、こちらが立たず」といった相反する価値があるからです。例えば、「セキュリティという品質特性を向上するためには使用性を落とさないとならない」などです。こちらについて、適切なバランスで目標値を決める（トレードオフする）必要があります。
この記事が気に入ったらサポートをしてみませんか？