ソフトウェア品質雑感　～SQuBOKから読み解くソフトウェア品質～

ＮＡＲＡコンサルティング 代表
奈良 隆正

　現代社会におけるコンピュータシステムは社会インフラの重要な一部であり、その中核に位置するのが、我々が手がけるソフトウェアである。
　また、ソフトウェアはあらゆる電子機器に組み込まれ、多様な機能を実現し、人々に利便性を与えている。まさにソフトウェアの無い世界は存在しえないのが現代である。
　したがって、ソフトウェアの重要性が益々増し、高品質、高信頼性など品質に対する高度化が求められている。
　しかし、ソフトウェア品質については色々な定義や考え方があり多様であり一意的には決まらない。ステークホルダや立場が違うとその定義は異なってくる。
ここではソフトウェアの品質について、SQuBOK（ソフトウェア品質知識体系）ガイドをベースにして私の経験を加えて読み解いてみたい。

１．ソフトウェア品質の定義と変遷

　品質の最も古典的な定義はクロスビー（P. Crosby）の定義として有名な「要求に対する適合」であろう。これは要求が常に正しいという前提に成り立っているが、ソフトウェア要求を正確に定義するのは難しいことは今でも解決されておらず、問題の残る定義である。しかし、これは長い間ソフトウェアの世界でも中心的な考え方として最近まで良く使われた定義である。
　現在、ソフトウェア品質の定義はユーザ視点に立つべきというのが一般的であり、ユーザにとっての「価値」や「満足度」と言われることが多い。そこで、ソフトウェアを意識したソフトウェア品質定義の変遷をみてみる。

（１）品質は誰かにとっての価値である。
　これはワインバーグ（G.M.Weinberg）の定義である。
　ここで「誰か」とは、実際にソフトウェアを使うユーザや管理者であったり、ソフトウェアを開発する開発者自身であったりする。
　ワインバーグは自身の著書「ワインバーグのシステム思考法」の中で、ソフトウェア工学の専門家として、クロスビーの定義の要求の正確さに依存しない、ソフトウェア品質の定義を一般化しなければならないと述べている。
　ソフトウェアの要求の曖昧さに悩まされながらソフトウェアの開発に携わってきた者にとって納得の出来る定義であろう。

（２）品質は、ユーザにとっての満足度（ＣＳ）である。
　これは近代的品質管理における品質の定義として、一般に受け入れられている考え方である。
「満足度（ＣＳ：Customer Satisfaction）」は日本の品質管理の成功に刺激されて米国が作ったマルコム．ボルドリッチ国家品質賞のスローガン「顧客満足度（ＣＳ）」が逆輸入されたもので,日本企業の経営指針として多く採用されている。
　顧客満足度について、英国ソフトウェア企業ＰＲＡＸＩＳ社のマーチン．トーマスは「ＣＳは我々のゴールである。しかし、カスタマー（顧客）の視点は毎月でも変わりうる。」と述べ、顧客満足度というのはやさしいが、日々変化する「各々の顧客の満足とは何か」を知りフォローするのは容易なことではないし、これを実現し続けるのは至難の技であると解説している。

（３）システムが本稼働するとき、どこまで真のビジネス（ユーザ）ニーズに合っているかということ
　これはジェームス．マーチン（Martin.J.）の定義であり、自身の著書「ラピッド．アプリケーション.ディペロップメント」の中で述べている。
　開発期間が長くなると計画時点でユーザニーズを正確に把握していたとしても、完成時にはニーズ自体が変化しているということが往々にして発生すという現実に対応したものである。
　結局、最終的にユーザが使用する時点で、そのニーズをどれだけ満足しているかが、良い品質かどうかの鍵である。ただし、前にも述べたとおり、ユーザとは誰であるかが課題である。

２．ソフトウェア品質の三つの視点

　ソフトウェアの開発は図―１に示した様に①ユーザの要求が有り、②これをソフトウェアの仕様に落とし、③そのソフトウェア仕様に従ってコードを書く、という手順で行われる。
　ソフトウェア品質を捉える際は、ソフトウェア品質を、狭義の品質と広義の品質の両面から考える必要がある。狭義には①ユーザの要求がソフトウェア仕様に正しく反映されているかという品質、すなわち「要求と仕様の適合度」があり、さらに②ソフトウェア仕様の定義に従ったコードが生成されているかという品質、すなわち「仕様とコードの適合度」の品質がある。これらは一般に①を設計品質、②をプログラム品質と呼ぶことが多い。
　広義の品質とは最終成果物（プログラム）がユーザの使用する時点で要求をどれだけ満たしているか、という品質すなわち「ユーザ要求への適合度」である。これは前述したジェームス．マーチンの品質定義に通じるところがある。
　ソフトウェア品質を大きく一つとして捉えるのではなく、上述のように分けて考えることで品質改善やＳＰＩなどの改善活動に活かしやすくなる。