ソフトウェアの品質ってなんだろう

f:id:shinsuku:20131212195127p:plain

　このブログの主な読者層は「品質保証部」やそれに類する組織に属しておられることと思います。「品質保証部」です。「品質」を「保証」する「部門」です。「品質」を… クドいですね。しかし、みなさんご自身は「品質」、特にソフトウェアにおけるそれを適切に説明することができるでしょうか。そこで今回は、僕自身もソフトウェアテストという仕事にはじめて触れた時に抱いたギモンである「ソフトウェアの品質って何？」について現時点での解を示してみたいと思います。

歴史にあたろう

　このような大きな概念を知るときは歴史にあたるのが王道です。きっと僕が疑問に思うよりはるか昔から、比べ物にならないぐらいの膨大な時間を掛けて、賢人たちが議論して辿り着いた解が既に存在すると考えるべきです。ただし、広くそれを伝えるために抽象化されているので、明日から現場で使えるほどの具体性を期待するのは筋違いでしょう。ラストワンマイル、現場への適用は常に自らの手で試行錯誤する必要があります。

　閑話休題、それでは賢人たちにおける「ソフトウェア品質の定義」について歴史を振り返ってみましょう。ほぼ時系列に並べましたが、いくつか年代不明であったため掲載していないものがあります。

ソフトウェアを完全に停止させたり、容認できないような結果を出す欠陥が全くないこと(Capers Jones:恐らく70年代)
要件に対する適合(Philip B Crosby:1980)
「狭義の品質」と「広義の品質」(石川馨:1981)
　狭義の品質:製品の品質
　広義の品質:仕事、サービス、情報、工程、部門、人、
　システム、会社の全てを含めた質
魅力的品質と当たり前品質/狩野モデル (狩野紀昭:1984)
製品またはサービスが、明示してあるか、あるいは暗黙の要望を満たす能力として持っている特性の総称(ISO 8402: 1986)
システムが本稼働するとき、どこまで真のビジネス(ユーザ)ニーズにあっているかということ(James Martin:1994)
品質は誰かにとっての価値である(G.M.Weinberg:1994)
プロダクトの特性が顧客のニーズに応えることで満足を提供する &不備(障害や誤り)から免れる(Joseph M. Juran:1998)
指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力(ISO 25000:2005)
機能及び性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的に開発が行われた全てのソフトウェアに期待される暗黙の特性に対する適合(Roger S. Pressman:200

バグが無いこと？

　1970年代では「バグが無いこと」と定義されていました。海外での変遷は大雑把には「バグが無いこと→要求を満たしていること→暗黙の要求もあるよ→ビジネスニーズもあるよ→もう、何だかわからない(ワインバーグ) →悟りの世界(プレスマン)」という流れです。ワインバーグの言はわかったようなわからないような印象を受けますが、実は品質の相対性という重要なポイントを初めて示しています。筆者の俗な想像ですが、「品質って何ですか？」と訊かれまくった賢人たち、ワインバーグはキレてぶっきらぼうに言い放ち、プレスマンはムキになって説明した、のではないでしょうか。特にプレスマンの言は「それでわかるなら定義なんか調べないよ！」と言いたくなるようなヒステリックさです。

　これだけ品質の定義について幅自体がブレてきたのは、ソフトウェアシステムの社会における存在感、価値の占めるその割合の増加と密接な関係があるのではないでしょうか。掲載した限り最も古い言及であるCapers Jonesの時代にはB2Cなどというドメインすら無かったはずで、社会におけるソフトウェアの役割も小さく「最悪動かなくても手でやるよ！」という牧歌的な頃であったかと思います。時代を経るにつれ、ソフトウェアの利用は効果的、もはや無くては立ち行かないもの、水道や電気と同じぐらい、あるいはそれ以上に重要かつクリティカルなインフラ、とその重要さを増すたびに、人間がシステムに持つ期待がどんどん膨らんでいき、今現在においてもその膨張はとどまることを知らないように見えます。

Column:

　80年代における日本とアメリカの品質認識の違いはとても興味深いものがあります。「品質」の定義を異様に広くとっている日本に対し、アメリカのそれは「先立つ何かがあり、十全にそれに従えていること」とされています。これは、アメリカのソフトウェア産業が主に軍からの厳密な発注と契約に基づいて発展してきたのに対し、日本はお客様の望む以上のものを提供する、という工業製品における思想に範を置いてきたためと考えられます。「プロセス保証」と「テスト」という軸を並列に置いた時日本では前者が、海外では後者に重きが置かれているように感じるのもこの歴史的経緯とは無関係ではないはずです。

　日本の定義はさすがお客様第一主義らしく、最初から幅が広く、著名な狩野モデルでは製品自体の品質とユーザの満足度を相対的に表すモデルが84年の時点で既に提唱されています。魅力的品質なんて今でも定量化が難しいのに30年以上前からその端緒をつけるあたり、品質大国ニッポンは伊達ではないです。日本の定義はシステムに限った話ではないのですが、伝統的に工業製品の製造過程を見習ってきたため、ソフトウェア産業においても同様の定義が使われてきたと考えて良さそうです。海外からすると「ニホンすげえよ、奥が深いよ！(でも具体的に何したらいいのかわからないよ)」で、日本からすると「海外の方法論はスゴいけど、お客様が語らないんだよねえ」という印象をお互いに持っていたのではないでしょうか。

"ソフトウェア"品質モデル

　一方、品質を一意に定義する、ことはどうやら難しいと悟った別の賢人達はソフトウェアに限ってその抽象度を一段下げ「ソフトウェア品質モデル」を提唱しはじめます。こちらも時系列に沿っていくつかの例を挙げます。

Boehm’s Quality Model (Boehm: 1976)
McCall’s Quality Model (McCall: 1977)
FURPS (Hewlett-Packard:70年代後半) *のちに+
ISO/IEC 9126 (1991)
ISO/IEC 25000 シリーズ SQuaRE (2005)

　このどれもが今でも使えるものばかりなのは驚愕です。余談ですが、最初に触るものとしてはFURPS+が特性の数が少ないのでオススメです。特徴的なのはFURPS(+)を除きそのどれもがツリー構造を採用している点です。BoehmとMcCalのそれは親特性と子特性が交差しあうN:Nの関係を持っていたのに対し、ISO9126以降では1:Nの構造が遵守されているのは、恐らく普及のためにある程度の単純化が図られたからではないかと予想されます。

　特に有名なISO/IEC 9126は、前述のお互いへのリスペクトが、海外の具体的な計測法と日本の品質の幅を広くとる思想の両方をソフトウェアという分野に限って標準化できた幸福な例と言えると思います。さきほど、人間が持つシステムへの期待は今も膨張していると述べましたが、それはISO/IEC9126から25010への改訂時に主特性が6個から8個に。利用時の品質も主特性が1つ増加し、副特性が正式に定められたことからも伺えます。9126だけでも大変だったのに、更に増えてこの先どうしたらいいのだろうとこの記事を書いている今も頭を抱えています。人間がある程度諦めてくれれば特性も減るのでしょうが、それを言ったら負けな気もするので頑張りたいと思います。

いまいまの解

　気を取り直して。ここまで「品質」自体の定義の例とソフトウェアに限って「品質」を一段具体化した「品質モデル」の例を見てきました。冒頭の質問に立ち返ってみましょう。「ソフトウェア品質って何ですか」。これらの考察を踏まえて解答するなら、現時点では

　「定義自体は以上のような変遷を経て未だに定まり切れていないが、ソフトウェアに限定してモデル化されたものがいくつかある。その中でも網羅性を求めるならISO/IEC9126(→25010)を、使用性を求めるならFURPS+が良さそう。9126は品質モデルの定義と内部/外部品質と利用時品質に分かれており、モデルは6つの主特性と27の副特性から構成され…」

　といった形になり、このあと対象の製品にまでスコープが及べば数時間は話せますが、相手が寝てしまうと思うので、少なくともソフトウェア企業の品質保証部という実戦部隊としての短い答えは、

「既存の品質モデルを製品にテーラリングして良し悪しを語れるようにした概念」

　となります。そこから、その良し悪しを良い方向に導いたり計測したりするための、今現在最も効果的な、パズルのような、”知る”技術として、ソフトウェアテストがあるのだなと理解しています。もちろんみなさんがいまおかれているコンテクストにおいて異論は多々あるでしょうし、僕自身、もっと良い解答を得られる事もこの先あると思いますが、先ず議論自体が行えるように、自分なりの解を用意しておくことも大事かなと思います。