読者です 読者をやめる 読者になる 読者になる

∑考=人

そして今日も考える。

品質水準とは何ぞや

今日は仕事をほっぽり出して、品質管理の研修に行ってきましたので、簡単にその内容でもまとめておきます。やっぱりソフトウェアなんてちゃんと動いてナンボのもんですからね。品質をいかに担保して、担保するために何をすべきなのか、というのは一つの学問になっているくらいです。

 

さて、そもそもソフトウェアにおける品質とは何なのか。品質というと、電化製品みたいな目に見えるモノに対して言いますよね。普段の生活の中で私たちは「日本の製品は品質が良い」みたいな言葉を安直に使っていますが、それって一体どういう時に使われるんでしょうか。

 

携帯電話を例にとって考えてみますかね。単純に形が整っていることについて品質が良いという人もいれば、カメラが綺麗な(解像度が高い)ことに対して品質が良いと考える人もいるでしょう。逆にiPhoneなんかだと、落とすとすぐ画面にヒビが入ってしまうことに対して品質が悪いと考える人もいると思います。こうやって列挙してみると、幅広い意味合いで使われている言葉です。

 

ソフトウェアの場合は、(お客さんの)要求事項を満たしていることが品質が良いと定義されています。おそらく、一般的な製品についても同等のことが言えるのでしょう。ISO9000という国際規格で定められています。

 

つまり、iPhoneの画面がすぐ割れること=品質が悪いということではなく、iPhoneという製品に求められる要求事項として、「高度1mから落としても操作に支障をきたす障害が発生しないこと」というものが含まれていなければ、別に品質上問題はない、ということになるのです。

 

ソフトウェアの場合では、例えば、中に記述されているソースコードが凄く読みにくかったり、無駄なソースが含まれていたら品質が悪そうな印象を受けますが、そのソフトウェアが提供するサービスがお客さんに求められた要求を満たしているとすれば品質の良いソフトウェアとなります。(厳密にはユーザ目線の品質と開発者目線の品質があるのですが、ユーザ目線の品質が良ければOK的な風潮があります。)

 

要するに”品質”という言葉は、あるべき姿(=要求事項)が定義された上でしか、意味を持たない言葉になっています。

 

さて。この品質ですが、どうやって実現していくのかが大切になってきます。入念に作れば良いという単純な話ではないんですね。ソフトにしてもハードにしても大体が実際に使ってみないとどうなっているかわかりません。設計なんて所詮想定でしかないですから。

 

なので、現場では実際に作ったものを動かしてみて検証します。いわゆる試験ですね。どんな仕事でもそうでしょう。

 

ソフトウェアの試験というのは実は結構大変です。ぶっちゃけシステムを作る以上に労力を必要とします。しばしば、見積額がとんでもない額になってしまうのも、試験工程にかかる工数が多分に含まれているからです。

 

また、システム開発において基本的に完璧な試験というのはできません。特に仕様ベースのブラックボックス試験などにおいては、規模が大きくなりがちで、全て条件の組み合わせパターンを試験することは不可能である場合がほとんどです。

 

なので、代表的なものだけを選ぶ、という方法に走らざるを得ないのですが、闇雲に代表的なものを抽出していくと、結局試験項目の数は膨大になってしまいます。そういうわけで、どんなプロジェクトにも”品質水準”という基準値が設けられています。

 

品質水準はザックリ言えば、「このぐらいの試験やっとけばええんちゃう?」「こんぐらいバグが出ればええんちゃう?」という値です。具体的には、ソースコードのStep数と、過去の類似プロジェクトの実績値から算出されます。

 

この品質水準値は、品質の妥当性を判断するため、すなわち品質管理のために用います。仮に、試験を100個やって、バグが10個ぐらい出ればいい、と予め決められていたとしましょう。

 

例えば、期間が足りず試験が50個しかできなかったら品質はちょっと悪いかもしれないな、と予想することができます。あるいは、試験を100個やったらバグが50個出た、となっても品質は悪いかもしれないと類推することができます。

 

では、100個試験をやってもバグが1つも出なかったらどうでしょう。この場合なら品質は凄く良い、と考えられそうなものですが、実は全く逆です。そもそも実施した試験の網羅性や観点が十分ではないと判断されることが多いです。

 

もちろん、実際に品質が良い場合もありますが、一般的には事前に設けられた品質水準値±数%の範囲内に収まっていないと何か問題があると判断します。ただ、品質水準値に収まっていても、品質が悪い場合もあります。。。

 

さらに言えば、品質水準値そのものがプロジェクト特性の違いなどによって妥当ではない場合もあります。みんなが口を揃えて、「あくまで目安だから」と言います。。。

 

なら、品質水準値とかいらなくね?

 

私はいつもそんなことを思っています。まぁこれは可監査性のための評価軸としてのみ有効です。

 

簡単な定量評価に頼らず、バグはしっかり定性的に分析しましょう。

 

n1dalap.hatenablog.com