ソフトウェア品質保証(SQA)とは。特徴や品質指標について解説

品質の話に入る前に、ソフトウェアの特徴をつかんでおくことにしましょう。

ハードウェアとソフトウェアの違い 

昔、職場の先輩からハードウェアとソフトウェアの説明として、「ハードウェアは堅くて、ソフトウェアは軟（やわ）ものだ」という話を聞きました。英語をそのまま訳しただけじゃないかと思われるかもしれません。 

もちろん補足説明があり、それは「ハードウェアは堅いから精密な製品であればあるほど、部品一つ一つの精度が求められると共に、設計図に基づき正しく組み上げないと動くことすらしない」というものでした。ハードウェアに比して「ソフトウェア（プログラムやアプリケーションと読み替えても同じ）は厳密に設計通りに作り込まなくても、何となく動いてしまうことが多い。このため、柔軟性があるといえばあるのだが、適当に作っても製品が仕上がってしまう。その分、ハードウェアに比べるとやっかいなシロモノだ」と違いを説明されました。確かに、ソフトウェアはワーニングメッセージが出たり、プロセスが落ちたり再起動していたりしても、表向き動いていることさえあります。ユーザーからすると、まるで正常に動いているように見えていても、なんだか動作がおかしかったり、遅かったり、というシーンが想像できます。 

ハードウェアの場合、「変な音がする」とか「動かない」、「火花や煙が出る」など明らかに故障であることが分かることがほとんどでしょう。ユーザーから見るとアプリケーションがおかしな挙動だったり、フリーズしていたり、明らかに間違ったデータを表示したりするといった、一般的に不具合と呼ばれている事象のことをソフトウェアに対しては「故障」と言います。その故障につながる要因を「欠陥」と呼び、欠陥の原因となるプログラムの間違いやデータ不良などのことを「エラー」と呼びます。（※1）

このように故障の見え方や発生メカニズムからして両者は異なります。 

機能安全規格　IEC61508を参照すると、ハードウェアの故障は、劣化や摩耗、破損などの要因によりランダムに発生しますが、部品や製品そのものに設計寿命があります。このため故障率として統計論的に扱うことができる「ランダムハードウェア故障」と定義されます。ソフトウェアは上の図のように、故障に至るまでの因果関係があるため、「決定論的原因故障(Systematic Failure)」と定義されます。

「ソフトウェアの品質」の特徴・考え方 

ここまでの話を踏まえた上で「ソフトウェアの品質」の特徴へと、考察をさらに進めていきます。 

不具合、上記ですと「欠陥」の有無は、品質の良し悪しを示す一つの要素に過ぎません。 

ソフトウェア品質を表現するために、ISO/IEC25000シリーズ【Systems and software engineering-Systems and software Quality Requirements and Evaluation (SQuaRE:スクエアと読み、和名はシステム及びソフトウェア製品の品質要求及び評価)】にて「品質モデル」というものが定義されています。 

日本語版の規格となるX25000:2017では、品質モデル(Quality Model)という用語を「品質要求事項の仕様化及び品質評価に対する枠組みを提供する，特性の定義された集合及び特性間の関係の集合」と定義しています。

では、どのような枠組みが提供されており、どのような集合が示されているかを見てみましょう。 

枠組みとしては、以下の3つがあります。 

• 製品品質モデル 
• 利用時の品質モデル 
• データ品質モデル 

なお本記事では、それぞれの詳細説明は割愛します。 

以下にソフトウェアそのものの品質を示す「製品品質モデル」と「利用時の品質モデル」を規格【X 25010：2013】から引用します。（※2）

製品品質モデルは、システムやソフトウェア製品を開発する側に焦点が当たっており、利用時の品質モデルは製品を利用するユーザーの立場に焦点が当たっていることが読み取れます（図表1）。

製品品質モデル中の「システム／ソフトウェア製品品質」の下段にある機能適合性や性能効率性などを品質特性の分け方として主特性といい、さらに下段にある機能完全性や機能正確性などは副特性といいます。

利用時の品質モデルも同様です。 製品品質モデルにおいて、製品ドメインやサービス内容によって、どの主特性を重視するのかや、どの副特性が品質への要求事項として必要に「なるのか／ならないのか」が異なります。これは利用時の品質モデルでも同じことが言え、製品やシステムのターゲットユーザーや、利用に関わる人たち（開発者や保守者などを含む）が持つシステムへの要求事項によって異なります。

担当する製品やシステムの主特性や副特性を把握する上で知っておかなければならないこととして、品質指標(古くはMetrics、最近はMeasurementといった用語が用いられます)が客観的に計測可能なものと、主観評価にならざるを得ないものに分かれることです。

例えば、性能効率性は、リソースの使用率が〷％を超えないとか、優先度　高のタスクは10mm秒以内に終了することなどを計測し、数値で評価することができます。一方、満足性となると、例えばユーザーによるベータテストでのアンケート調査として「この製品の操作性に満足できますか？　1:とてもできる、2:できる、3:そこそこ、4:不満、5:とても不満」という設問を通じて、何となく数値で評価することなら可能でしょう。

とはいえ、評価する人にとって満足するかどうかの尺度が異なるため、たとえ数値化したとしても主観に左右されてしまいます。ですから、主観的に評価をする品質特性を扱う場合には、少なくとも関係者で合意を得られるような指標の決め方を心がけるべきでしょう。

このようにソフトウェア品質と一口に言っても、開発対象となる製品やシステムによって持つべき、さまざまな品質特性と副特性を把握したり、優先度を決めるなりしないと、精確な品質保証へつなげることが難しくなってしまいます。あえて精確と表現したのは、品質特性をきちんと理解できていなくとも、組織として品質保証のプロセスが存在しているならば、それなりに不具合が無い製品を開発することは可能だからです。このような製品ならば、開発者が決めた仕様通りに動作することは保証できるかもしれません。

しかしながら、ユーザーの期待通りの動作をしているかどうかや、製品が本来優先すべき品質特性を具備しているかどうかまでは、評価することが難しいでしょう。品質特性を理解も把握もできずに市場に出た製品は、たとえ製品不良によるリコールや瑕疵による損害賠償のリスクが無かったとしても、売れる製品となる保証など無い、というビジネスリスクを抱えてしまうことにつながりかねません。

ここまでの説明でソフトウェア品質の全体像が何となくでもお分かりいただけたでしょうか。

では、ソフトウェアの品質保証(SQA: Software Quality Assurance)そのものを、品質保証の専門家集団である品質保証部門に任せてしまえばよいだろう、とか、ベリサーブのような第三者検証企業に評価を任せしてしまえばよいだろうという考えは正しいでしょうか。

実際、自社製品やシステムの品質保証をいわゆるQA(Quality Assurance)とかSQA、品証（品質保証）とか品管（品質管理）といった部署に一任している企業や組織はあります。

平たく言えば、開発と品証とで「私、作る人、あなた保証する人」という役割分担です。

このような形態で製品品質を確保しつつ、円滑に組織運営ができていて、将来もできそうならばよいのかもしれません。

他山の石にしてもらってよいのですが、筆者の経験やメーカー系の品質保証部門を取りまとめた先輩から聞いた言葉、海外の専門家から聞いた話のいずれもが、このようなやり方のままで品質保証し続けることはできなくなるだろう、という話ばかりでした。ある先輩は「品質保証という役割を品証にとどめ続けるのではなく、開発側へ大政奉還しないと、開発サイクルが短くなっているにもかかわらず、ますます複雑、肥大化し続けるシステムの品質保証などできなくなってしまう」と熱く語っていました。当時、筆者がこの話を聞いたときに「ふむ。このことはひょっとするとアジャイル開発モデルと通じるものがあるかもしれないぞ。チーム全体で品質を担保するアプローチを採るアジャイル開発モデルが欧米でどんどん普及していっているように、日本でも同様の傾向になっていきそうだ」と感じました。

開発と品証の品質特性に応じた責務分担の必要性

品質モデルを眺めても、開発と品証では品質特性に応じた責務分担が必要なことは明らかです。

テストレベルの観点で考えてみます。例えば、品質特性の主特性の一つである機能適合性を取り上げると、ユニットテストや統合テストといったホワイトボックステストのアプローチで確認すべき副特性となる機能正確性は開発側でないと、効率的かつ適切な構造カバレッジを満たした検証は難しいです。システムテストになると、要求・仕様に基づいて機能が適切に動作するかどうか、プログラムのアルゴリズムに関係なくブラックボックスのアプローチで妥当性確認を行います。ですから開発とは独立し、かつユーザーに近い視点を持ち得る品証部門や第三者検証企業が得意な領域となります。

本記事では、ソフトウェア品質がどのようなものか、ソフトウェア品質保証を誰が行うべきなのかを考察しました。ソフトウェア品質保証を実現するための手法や技法にはさまざまなものが存在するのですが、紙面の都合があるため別記事にて取り上げていきます。

最後に、第三者検証企業ごとにエンタープライズや組み込みといったドメインごとのテストプロジェクトの経験に差があるように、品質特性や副特性を評価する上での得手／不得手があるときもあります。

ですから、第三者検証企業にソフトウェア品質保証に関わる業務を依頼するときは、このことを念頭に置いて交渉を進めたり、選定したりするならば、スムーズかつ品質の期待を満足する結果につながりやすくなることを、覚えておいて損はありません。

■参考■

（※1）標準規格によっては異なる定義・呼称の場合があります。

（※2）この標準はISO/IEC 25010:2023として昨年11月に改訂版が発行されました。