１９９５年に、ソフトウェアの世界に新しい品質の概念が持ち込まれました。それが「Good Enough」という概念です。それまでの品質の概念では、バグは一つでも許されませんでした。まさにゴキブリと同じで、１匹でもいたらダメという状況でした。たとえ、それが大した悪さをしなくても、存在そのものが“悪”と認識されるのです。もちろん、今でも、バグが“許されている”わけではありませんが、増える一方の機能に対して、一定の要件の範囲で、あらゆる組み合わせのテストを実施することができなくなったし、そのことに経済的合理性が認められなくなったのです。
汎用コンピュータの時代とちがって、たとえばＰＣのＯＳは精々２万円前後の値段でする。そのようなソフトに対して汎用コンピュータの時と同じようなテストを実施することに合理的な理由を失ってしまったのです。いや、ＰＣのＯＳと言っても、操作性を含めた機能面では、かっての汎用コンピュータのＯＳを越えているかもしれません。
そうした状況から、「Statistical Testing」という考え方が現れてきました。どれだけの機能が用意されていようと、ユーザーがどのような使い方をしているかという観点からテストを実施する。つまり、テストケースをユーザーの利用形態に合わせてランキングしてテストを実施するもので、そこから、ソフトウェアの「信頼性」を割り出したのです。その結果、同じ１件のバグでも、利用度の高いところで発生した場合は、その製品の信頼性は低くなるが、１０万人に一人しか使わないような所に発生した場合は、その製品の信頼性に殆ど影響を与えないかもしれません。つまり後者は「十分よい」ソフトと認められることになります。このような「Statistical Testing」という考え方は、アメリカでは９５年以前にすでに定着していました。『闘うプログラマー』（日経ＢＰ出版）などを読んでも、そのような開発組織の姿を見ることができます。
私は、「Good Enough」は、この「Statistical Testing」をベースにして、はじめて成立するものと考えています。
「Good Enough」の考え方を表に出したのは、James Bach でです。１９９５年という年は、あの世界中を湧かせた Windows 95 が発売された年であり、Pentium の浮動小数点演算のバグの情報が、インターネットを介して世界中を駆け回った年です。Win 95 にも、多くのバグが残ったままの出荷でした。だが世界はそれを「十分よいもの」として受け入れました。その後に発表されたマイクロソフトの WORD も、多くのバグを残したままの出荷となりましたが、これも市場はそれを受け入れました。
最近の Pentium CPU にも“軽微な”バグがあることが報道されていますが、市場は特に問題にしていないようです。
参考文献：
（インデックスに戻るときはウィンドウをクローズしてください）
「Good Enough」は、このように時代の流れとして出てきた概念です。その下地は既に「Statistical Testing」の中にありました。ではなぜ、「Statistical Testing」や「Good Enough」という考え方が出てきたのか。少なくとも、１０年ほど前には、このような考え方は無かったと思われます。そこではテストは全ての組み合わせを網羅することが前提でした。とても時間的にムリという場合でも、表向きは網羅したということで通していました。というより、そうでないと顧客や市場に受け入れられなかったからです。いまでも、我が国では、多くの開発組織で、組み合わせの網羅テストが行なわれていると思います。もっとも、全網羅テストしか受け入れられなかった理由は、ユーザーの使用環境で多くのバグを出していたからでもあるのですが。
だかそれも、増える一方の機能と、短くなっていく製品のサイクルの前にあえなく崩れさったのです。その結果、すべての組み合わせを網羅するのではなく、もっと効率のよいテストが必要になったのです。そうして出てきたのが「Statistical Testing」です。これは日本では「統計的テスト」と訳されていると思われます。現実問題として、機能の組み合わせの網羅テストは納期に間に合う形で実現していないのではないかと思われます。
「Statistical Testing」は、提供している機能をユーザーがどのように使っているかという統計的な情報を元に、テストケースに使用頻度や優先度という尺度がセットされ、その頻度の高い利用形態に於ては、絶対にバグを出さないことによって、ソフトウェアに信頼性という品質特性を確立した。もちろん、個々の機能についての基本的な動作の確認は完了していることが前提です。この結果、ソフトウェアの製品に「ＭＴＢＦ」という考え方を導入することが出来るようになりました。「Good Enough」は、このような信頼性の実現が背景にあって、はじめて成立する概念です。
（インデックスに戻るときはウィンドウをクローズしてください）
工業製品は、基本的に「品質」「機能」「タイムリー性」の３つの要素について、常に市場から強い“要請”を受けています。「品質」とはある意味ではバグが存在しない程度であり、この場合、本来は信頼性という品質特性で代表されます。「機能」とはその製品の特徴であり、存在意義でもあります。だから他社の製品と差別化するために機能を増やし、性能を上げようとします。そして「タイムリー性」とは、開発サイドでいえば納期やスケジュールにあたりますが、製品レベルで言えば発売時期に相当します。
また、これらの３つの要素の背後に、実際には「コスト」という強烈な要素も存在しており、それによって「高い品質」「高性能・多機能」「納期の短縮」の３つの要素は、基本的に要求のレベルのままでは同時に成立しないことになり、いずれかの要素が犠牲になることになります。
これまでは「納期」が犠牲になったのですが、最近は、発売時期が３つの要素の中で年々厳しくなってきました。それは、競争相手の存在にあります。これまでのように強力な競争相手がいなければ、この発売時期の圧力は強くはならなかったのですが、手強い競争相手がいて品質や機能が似ているとなれば、必然的にタイムリー性を競うことになります。発売時期が半年遅れたことで、競争相手に市場をとられてしまい、惨めな結果になってしまう。経済がグローバル化するほど、競争相手が特定出来ず、この危険が高くなります。だからどうしても「タイムリー性」が他の要素よりも優先することになるのです。
しかしながら、「タイムリー性」が優先するということで、他の要素を蔑ろにするわけには行きません。そこで、「品質」と「機能」の妥協点を探す必要が生じてくるわけで。「Good
Enough」は、その一つの合意点でもあります。ただ、日本の場合は、安易にコストが犠牲になることが多く、そのことで３つの要素について発達を阻害しています。
（インデックスに戻るときはウィンドウをクローズしてください）
「Good Enough」という考え方が市民権を得るためには、それが市場にとってメリットがあることが必要です。２０万円前後のＰＣの本体価格に対して、ＯＳや必要なアプリケーションの価格が１０万円もするようでは、「市場」には受け入れられません。一部に高額なアプリケーションがありますが、それらが受け入れられているのは、市場ではなく、“マニア”であり、それがあることで、より大きな富みを得る方法を持っている“特定の人”なのです。
もちろん、「市場」に受け入れられる（べき）ソフトも、初期の頃はこのような“マニア”が立ち上がりを支えるということは、よく見られる姿ではありますが、「市場」に受け入れられる製品（商品）になるには、ソフトの価格を大幅に引き下げることが条件となります。そして「Good Enough」は、その実現を支援する考え方でもあるのです。
市場は、この「Good Enough」を受け入れなければ、ソフトのコストは高く付いてしまうでしょう。その意味では、「Good Enough」の出現は、一つの「必然」、あるいは「流れ」であったかもしれません。それは、「Statistical Testing」や「ＣＭＭ」の出現と同様に、「市場の要請」を受けて産みだされたものでもあるのです。
別の見方をすれば、「Statistical Testing」や「ＣＭＭ」がほぼ確立し、それを背景として「Good Enough」が実現することを「市場」は知った以上、このあと５年もすれば、市場はこの要求をソフトの開発組織に対して、“不退転”な要求として実現を求めてくるはずです。そのときまでに、対応できる体制を身に付けていなければ、市場原理に従って淘汰される可能性が高くなることは云うまでもないでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）