ソフトウェア品質の全体像を捉えるうえで、重要な役割を果たすのが「品質特性」です。そもそも現在のソフトウェア品質が高いのか低いのか、明確な基準をもって示せる人は少ないのではないでしょうか。
ソフトウェアの品質特性は、8つの品質特性と31の品質副特性があり、種類が豊富です。また、実際の利用シーンに着目した「利用時の品質」における5つの品質特性も定められています。ソフトウェア品質特性を活用するにあたっては、それぞれにどのような観点があるのかを理解しておくことが大切です。
この記事では、ソフトウェア品質特性の概要や、具体的な構成要素をすべて紹介します。
- もくじ
1．ソフトウェア品質特性とは
まずは、そもそもソフトウェア品質特性とは何かを知っておきましょう。ソフトウェア品質特性の概要や、関連する規格について解説します。
1-1 品質特性とは？
ソフトウェア品質特性とは、ソフトウェアの品質を捉えやすいように細分化した観点のことです。大項目である「品質特性」、品質特性を細分化した「品質副特性」から構成されます。
品質特性と品質副特性を整理して体系化したものを「品質モデル」と呼びます。
「ソフトウェア品質」といっても、さまざまな観点が存在します。
たとえば「利用しやすさ」という観点も、掘り下げると「使い方を覚えやすいか」「操作性が良いか」など多岐にわたります。これらを1つの物差しだけで評価することは難しいでしょう。
そこで、ソフトウェアの品質にまつわる観点を細分化し、個々の物差しで評価するアプローチが普及しました。このアプローチ方法を体系化したのが品質モデルであり、品質モデルにおける観点が品質特性です。
1-2 品質特性の規格
品質特性を取り入れる場合、信頼性の高い組織によって標準化された規格を採用することが一般的となっています。
品質特性の規格で元祖ともいえるのが「ISO/IEC 9126」です。
ISO/IEC 9126はソフトウェア品質の評価に関する国際規格であり、6の品質特性と27の品質副特性から成り立ちます。
2010年代には、ISO/IEC 9126の改良版として「ISO/IEC 25010（日本語版：JIS X 25010）」が登場しました。ISO/IEC 25010はISO/IEC 9126の品質モデルを拡張しており、8の品質特性と31の品質副特性に分類されています。
品質特性を取り入れる場合、上記のいずれかを採用することが一般的です。この記事では、改良版のISO/IEC 25010（JIS X 25010）にもとづき品質特性を紹介します。
なお、ISO/IEC 25010はISO/IEC 25000シリーズの1要素です。このシリーズには、品質モデル以外にも次のような要素が定義されています。
| 規格番号 | 規格の対象範囲 |
|---|---|
| ISO/IEC 25000～ | 品質管理 |
| ISO/IEC 25010～ | 品質モデル（品質特性を含む） |
| ISO/IEC 25020～ | 品質測定 |
| ISO/IEC 25030～ | 品質要求 |
| ISO/IEC 25040～ | 品質評価 |
2．ソフトウェア品質特性を活用する3つのメリット
ソフトウェア品質特性を活用する主なメリットは、次の3つです。品質特性を適切に活用するために、メリットを正しく把握しておきましょう。
2-1 ソフトウェア品質を可視化できる
ソフトウェア品質特性を用いることで、ソフトウェア品質を可視化できます。
品質が高い・低いという基準では漠然とし過ぎており、主観的な評価しかできません。しかし品質モデルでは、品質評価の観点が品質特性・品質副特性として細分化されています。具体的な評価ポイントが示されているため、品質の評価がしやすいでしょう。
たとえば「使いやすいか」という観点のみでは抽象的で、品質の評価が困難です。しかし、「使用性」という品質特性に落とし込めば、「ユーザーが使い方をストレスなく効率的に習得できるか（習得性）」や「運用者が操作しやすいか（運用操作性）」など、より具体的な観点で評価できます。
2-2 テスト設計の漏れを減らせる
ソフトウェア品質特性は、テストケースを作成する「テスト設計」でも役立ちます。テスト設計では、「何に着目して検証するのか」というテスト観点の洗い出しが必要です。テスト観点に漏れがあると、テストすべき品質要素が十分に検証されず、重大なバグの見逃しを招きかねません。
その点、品質特性はテスト観点を考える際の重要な手がかりとなります。品質特性をもとにテストケースを作成すれば、検証で着目すべき観点が整理されるため、漏れを減らせるでしょう。仮にテスト設計の初期段階で見落としがあっても、品質特性をチェックリストのように活用することで、テストケースの漏れに気付けます。
ただし品質特性と品質副特性は多数あり、必ずしもすべてをテスト観点に落とし込む必要はありません。顧客のニーズやテストの戦略を考慮して、必要なテスト観点を選定することが大切です。
2-3 非機能要件の定義漏れを防げる
品質特性は、要件定義における非機能要件の定義漏れを防ぐのにも役立ちます。
ソフトウェア開発では、機能要件（何ができるか）が重視されがちですが、非機能要件（どのように上手く振る舞うか）も重要です。しかし、非機能要件には性能や保守のしやすさなど幅広い観点があり、そのすべてを網羅するのは容易ではありません。
その点、品質特性をガイドラインとして活用すれば、非機能要件を検討する際の観点を網羅的に整理できます。「信頼性」や「セキュリティ」といった品質特性の観点から要件を検討することで、考慮すべき要件が明確になり、定義漏れを防げるでしょう。
3．ソフトウェア品質特性・品質副特性の種類（ISO/IEC 25010）
ここからは、8つの品質特性と31の品質副特性をまとめて紹介します。各品質特性について解説し、それらに付随する品質副特性を表で紹介していく流れで解説します。
3-1 機能適合性
「機能適合性」は、機能がユーザーのニーズをどれだけ満たせているかの度合いです。ここでいう「ニーズ」は、要件定義書や仕様書に記載された明示的なニーズに限りません。つまり、開発文書で明確な記載がない性能面も評価ポイントとなります。
たとえば「ログインできること」という要件に対し、単にログインができるだけでなく、「パスワードを間違えた際に適切なエラーメッセージが出るか」といった点も含まれます。
想定されるユーザーが求める機能を網羅し、目的に沿った処理や結果を提供できるソフトウェアは「機能適合性が高い」といえます。機能適合性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 機能適合性 | 機能完全性 | 機能がニーズをどれだけ網羅しているか |
| 機能正確性 | 機能を誤りなく正確に提供できるか（例：処理や出力が仕様どおりか） | |
| 機能適切性 | 利用目的にふさわしい機能内容か（例：機能の実現に不要な手順がないか） |
3-2 性能効率性
「性能効率性」は、与えられたITリソース（資源）に対して、どれだけの性能を発揮できるかの度合いです。ITリソースはCPUやメモリ、外部ハードディスクなど多岐にわたりますが、対象のソフトウェアによって変わります。
ITリソースを効率的に活用し、できる限り高いパフォーマンスを提供できるソフトウェアは「性能効率性が高い」といえます。性能効率性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 性能効率性 | 時間効率性 | 応答時間や処理時間が適切か（例：画面遷移の速度は許容範囲内か） |
| 資源効率性 | ITリソースを無駄なく効率的に使えているか（例：CPU負荷は許容範囲内か） | |
| 容量満足性 | 入力値やデータ量の許容範囲が十分か（例：想定されるデータ量を処理できるか） |
3-3 互換性
「互換性」は、利用環境のバリエーションに対して柔軟に対応できるかの度合いです。「利用環境」には、ブラウザやOSといったソフトウェア、モバイル端末やネットワークケーブルといった機器を含みます。
周辺ソフト・周辺機器の製品やバージョンが変わった場合でも、影響を最小限に抑えられるソフトウェアは「互換性が高い」といえます。互換性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 互換性 | 共存性 | 他ソフトウェアに悪影響を与えたり、悪影響を受けたりせずに動作するか |
| 相互運用性 | 他ソフトウェアや他機器と連携できるか |
3-4 使用性
「使用性」は、想定される利用者・利用状況において、どれだけ使いやすいかの度合いです。ユーザーや運用者など、開発者以外の立場に焦点を当てます。
対象の利用者がストレスなく快適に利用でき、高い満足度を感じられるソフトウェアは「使用性が高い」といえます。使用性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 使用性 | 適切度認識性 | 自分のニーズに合うソフトウェアだと直感的に認識できるか（例：紹介ページや画面などを見て、自分の目的を果たせそうだとすぐ理解できるか） |
| 習得性 | ユーザーが使い方をストレスなく効率的に習得できるか（例：マニュアルの記載どおりに処理が行えるか） | |
| 運用操作性 | 運用者が操作しやすいか（例：バックアップ操作を効率的に行えるか） | |
| ユーザーエラー防止性 | ユーザーの誤操作を防止できるか（例：不正なデータ処理時にエラーが表示されるか） | |
| ユーザーインターフェース快美性 | ユーザーが満足できる色やデザインか（例：配色やレイアウトが、利用シーンにふさわしく魅力的なものか） | |
| アクセシビリティ | 年齢や身体障害の有無を問わず幅広い人々が利用できるか |
3-5 信頼性
「信頼性」は、想定される時間帯や利用状況において、機能を提供し続けられる度合いです。簡単にいえば、「どれだけ利用者の期待を裏切らずに動作できるか」となります。障害の発生しにくさや発生時の対処など、障害への対応能力に焦点を当てた品質特性です。
想定される時間帯や利用状況において障害が発生せず、ユーザーが使い続けられるソフトウェアは「信頼性が高い」といえます。信頼性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 信頼性 | 成熟性 | システムの信頼性はユーザーにとって満足か（例：障害発生時に停止しないか） |
| 可用性 | ユーザーが使いたい時に利用できるか（例：機能を24時間利用できるか） | |
| 障害許容性（耐故障性） | 障害の発生をどこまで許容できるか（例：障害発生時に機能制限付きで動作を維持できるか） | |
| 回復性 | 障害発生前の状態に戻せるか（例：データベース操作のロールバックが行えるか） |
3-6 セキュリティ
「セキュリティ」は、どれだけセキュリティリスクを低減できるかの度合いです。前提として、セキュリティリスクを完全に排除することはできません。サイバー攻撃は日々進化し続けており、継続的にセキュリティ対策を施していくことが求められます。
そのため、想定される脅威に対して適切なセキュリティ対策が継続的に施されたソフトウェアは「セキュリティ性が高い」といえます。セキュリティの品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| セキュリティ | 機密性 | 許可されたデータだけにアクセスできるか（例：管理者画面に管理者ユーザーだけがアクセスできるか） |
| インテグリティ | 不正なアクセスを防止できるか（例：一般ユーザーによる管理者画面へのアクセスが禁止されているか） | |
| 否認防止性 | 事実を否認されないように対策されているか（例：利用規約への同意が記録されているか） | |
| 責任追跡性 | 操作や事象を後から追跡できるか（例：システムログに操作が記録されているか） | |
| 真正性 | 偽りなく本物であると証明できるか（例：ユーザー認証が間違いなく行えるか） |
3-7 保守性
「保守性」は、どれだけ適切に保守作業を行えるかの度合いです。保守作業には、コードの修正、設定ファイルの変更や引き継ぎ、環境移行にともなう動作確認などを含みます。また、機能追加や品質改善といったアップデートも保守性の評価対象です。
ソフトウェアの修正や更新の負担を軽減し、適切に保守作業を行えるソフトウェアは「保守性が高い」といえます。保守性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 保守性 | モジュール性 | 構成要素ができる限り独立し、他の構成要素への影響を抑えられているか（例：モジュールAの変更がモジュールBに影響しないか） |
| 再利用性 | 既存の構成要素を他システムへ再利用できるか（例：バージョンアップにともない、設定ファイルの引き継ぎが行えるか） | |
| 解析性 | 影響範囲や修正箇所、問題箇所などを解析できるか（例：ログを見て、障害の原因をすぐに特定できるか） | |
| 修正性 | 品質を保ちつつ効率的にプログラムを修正できるか（例：コードが読みやすく、どこを直せばよいかすぐに判断できるか） | |
| 試験性 | 品質を保ちつつ効率的にテストを行えるか（例：明確な合否基準を設定できるか） |
3-8 移植性
「移植性」は、ソフトウェアを別の利用環境にうまく移行できるかの度合いです。ソフトウェア利用環境（OSやブラウザなど）の移行、新しい利用環境へのインストールなどを含みます。
利用環境の移行作業が効率的に行え、新しい利用環境に適応できるソフトウェアは「移植性が高い」といえます。移植性の品質副特性や観点は次のとおりです。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 移植性 | 適応性 | 異なる周辺ソフトや機器にどれだけ適応できるか |
| 設置性 | 所定の場所へ効率的に配置・削除できるか（例：インストールがスムーズに行えるか） | |
| 置換性 | 別のソフトや機器との置き換えが行いやすいか（例：データベースの移行がスムーズに行えるか） |
4. 「利用時の品質」における5つの品質特性（ISO/IEC 25010:2011）
これまで紹介した8つの品質特性は、ソフトウェアそのものの品質（製品品質）を指します。それに対して、ユーザーが実際にシステムを利用した結果としての品質を「利用時の品質」と呼びます。
ISO/IEC 25010:2011では、利用時の品質として5つの特性（有効性・効率性・満足性・リスク回避性・利用状況網羅性）が定義されています。
これまで解説した「ソフトウェア品質特性」は、ソフトウェアそのものの品質を評価する際に使用するものです。それに対して「利用時の品質」は、実際にソフトウェアを利用した結果や満足度を評価する際に使用します。では、それぞれ見ていきましょう。
4-1 有効性
「有効性」は、ユーザーが指定された目標をどれだけ正確かつ完全に達成できるかの度合いです。ソフトウェアを使って、利用者が本来やりたかった作業を滞りなく完了できるかを評価します。
たとえばECサイトでは、「購入手続きが最後までエラーなく完了できるかどうか」が1つの評価対象となります。途中で処理が中断したり、数量や金額を間違えたまま注文確定してしまったりする状態では、「有効性が高い」とはいえません。
4-2 効率性
「効率性」は、目標を達成するために費やした時間や労力などの資源が、結果に対して適正であるかの度合いです。同じ成果を得られる場合でも、操作が少なく、短時間で完了するほど「効率性が高い」と評価されます。
ECサイトでは「購入完了までの入力項目が必要以上に多くなっていないか」「画面遷移が過剰でないか」といった点が評価対象となります。操作が煩雑で時間がかかる場合、有効性が満たされていても「効率性が高い」とはいえません。
4-3 満足性
「満足性」は、ソフトウェアを使用したユーザーのニーズがどれだけ満たされるかの度合いです。ユーザーの主観に強く依存する品質特性であり、機能的な正しさとは別の観点で評価する必要があります。満足性は、さらに4つの観点（副特性）に整理できます。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 満足性 | 実用性 | ユーザーが達成しようとする目標に対して、どれだけ役立っていると感じられるか（例：仕事の役に立つ、便利だと実感できるか） |
| 信用性 | システムの結果や振る舞いを信用できるか（例：誤作動や情報漏えいの心配なく安心して使えるか） | |
| 快感性 | 利用することで喜びや心地よさを感じられるか（例：操作時のアニメーションや演出にワクワクするか） | |
| 快適性 | 身体的な負担や不快感がないか（例：長時間見ても目が疲れない配色や文字サイズか） |
4-4 リスク回避性
「リスク回避性」は、ソフトウェアの使用にともなう経済的損失や、人命・健康・環境への悪影響といったリスクを抑制できる度合いです。エラーが原因で金銭的な損失を出したり、ユーザーの安全を脅かしたりしないかが評価されます。
リスク回避性は、さらに3つの観点（副特性）に整理できます。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| リスク回避性 | 経済リスク緩和性 | 商業上の財産や評判など、経済的な状況へのリスクを緩和できるか（例：システムダウンによる売上の機会損失を防げるか） |
| 健康・安全リスク緩和性 | 人々の安全や健康に対するリスクを緩和できるか（例：誤作動によってユーザーが怪我をする危険性がないか） | |
| 環境リスク緩和性 | 環境への衝撃や破壊に関するリスクを緩和できるか（例：機器の熱暴走による火災や、有害物質の排出を防げるか） |
4-5 利用状況網羅性
「利用状況網羅性」は、想定された利用状況だけでなく、当初想定していなかった状況下でもソフトウェアが有効に機能するかどうかの度合いです。多様なユーザーの利用環境や使い方に対して、一定の価値を提供できるかが評価されます。
利用状況網羅性は、さらに2つの観点（副特性）に整理できます。
| 品質特性 | 品質副特性 | 観点 |
|---|---|---|
| 利用状況網羅性 | 利用状況完全性 | 明示的に指定されたすべての利用状況で、問題なく利用できるか（例：対応機種として記載されたすべてのスマートフォンで動作するか） |
| 柔軟性 | 当初の要件で想定していなかった状況下でも利用できるか（例：想定外の古いOSや、特殊なブラウザ設定でも最低限の機能を使えるか） |
5. ソフトウェア品質特性に関するQ&A（よくある質問）
最後に、ソフトウェア品質特性を現場で活用する際によくある2つの疑問について回答します。
5-1 Q1.全ての品質特性を網羅しないといけないの？
すべての品質特性を完璧に満たす必要はありません。品質特性はあくまで「物差し」であり、網羅しようとすると膨大なコストと時間がかかります。
重要なのは、プロジェクトの目的や予算に応じて優先順位を付けることです。「絶対に外せない特性」と「あると良い特性」を明確にし、メリハリのある品質管理を行いましょう。たとえば、社内限定の業務ツールであればユーザーインターフェース快美性は後回しにし、機能適合性（業務ができること）を最優先する、といった判断が求められます。
5-2 Q2.ソフトウェアによって重視すべき品質特性は変わるの？
はい。重視すべき品質特性は、ソフトウェアの種類や利用目的によって異なります。そのため、必ずしもすべての特性を均等に高める必要はないと覚えておくと良いでしょう。
たとえば、金融システムの場合はミスや不正が許されないため、信頼性やセキュリティが最優先されます。一方、スマートフォン向けのゲームアプリであれば、楽しさや動作の軽さが求められるため、使用性や性能効率性が重視されるでしょう。
対象となるユーザーや利用シーンを想像し、重み付けを変えることが大切です。
6. まとめ：ソフトウェア品質特性を活用して品質を向上させよう
ソフトウェア品質特性とは、ソフトウェアの品質を捉えやすいように細分化した観点のことです。品質特性を活用することで、ソフトウェアの品質を可視化できるだけでなく、テスト設計や要件定義の漏れを防げるメリットもあります。
この記事では、ISO/IEC 25010（JIS X 25010）における「製品品質」の8特性と、「利用時の品質」の5特性について解説しました。ソフトウェア品質特性を取り入れる際には、今回の内容を参考にしてみてはいかがでしょうか。
また品質特性に限らず、ソフトウェア品質に関して理解を深めるうえではeラーニングがおすすめです。バルテスのeラーニングでは動画とテキストを組み合わせた効率的な学習がWeb上で行えます。ソフトウェア品質に関する学習の際には、ぜひお試しください。
ソフトウェア品質セミナー eラーニング版「品質とテストの基本編」
ソフトウェアテストの意義と重要性、並びにソフトウェア業務の概観と品質の考え方を体系的に把握することを目的としています。そして、基本的な発想法の講義を実施し、実業務での活用の視点を提供します
