ソフトウェア品質の全体像を捉えるうえで、重要な役割を果たすのが「品質特性」です。そもそも現在のソフトウェア品質が高いのか低いのか、明確な基準をもって示せる人は少ないのではないでしょうか。
ソフトウェアの品質特性は、9つの品質特性と40の品質副特性があり、種類が豊富です。また、実際の利用シーンに着目した「利用時の品質」における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の品質副特性に分類され、広く普及しました。現在は、2023年の最新版に改定されています。
品質特性を取り入れる場合、上記のいずれかを採用することが一般的です。この記事では、改良版の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）
ここからは、9つの品質特性と40の品質副特性をまとめて紹介します。各品質特性について解説し、それらに付随する品質副特性を表で紹介していく流れで解説します。
3-1 機能適合性
「機能適合性」は、機能がユーザーのニーズをどれだけ満たせているかの度合いです。ここでいう「ニーズ」は、要件定義書や仕様書に記載された明示的なニーズに限りません。つまり、開発文書で明確な記載がない性能面も評価ポイントとなります。
たとえば「ログインできること」という要件に対し、単にログインができるだけでなく、「パスワードを間違えた際に適切なエラーメッセージが出るか」といった点も含まれます。
想定されるユーザーが求める機能を網羅し、目的に沿った処理や結果を提供できるソフトウェアは「機能適合性が高い」といえます。機能適合性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
機能適合性 |
機能完全性 |
機能がニーズをどれだけ網羅しているか（例：利用者の目的を叶えた機能が搭載されているか） |
|
機能正確性 |
機能を誤りなく正確に提供できるか（例：処理や出力が仕様どおりか） |
|
|
機能適切性 |
利用目的にふさわしい機能内容か（例：機能の実現に不要な手順がないか） |
3-2 性能効率性
「性能効率性」は、与えられたITリソース（資源）に対して、どれだけの性能を発揮できるかの度合いです。ITリソースはCPUやメモリ、外部ハードディスクなど多岐にわたりますが、対象のソフトウェアによって変わります。
ITリソースを効率的に活用し、できる限り高いパフォーマンスを提供できるソフトウェアは「性能効率性が高い」といえます。性能効率性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
性能効率性 |
時間効率性 |
応答時間や処理時間が適切か（例：画面遷移の速度は許容範囲内か） |
|
資源効率性 |
ITリソースを無駄なく効率的に使えているか（例：CPU負荷は許容範囲内か） |
|
|
容量満足性 |
入力値やデータ量の許容範囲が十分か（例：想定されるデータ量を処理できるか） |
3-3 互換性
「互換性」は、利用環境のバリエーションに対して柔軟に対応できるかの度合いです。「利用環境」には、ブラウザやOSといったソフトウェア、モバイル端末やネットワークケーブルといった機器を含みます。
周辺ソフト・周辺機器の製品やバージョンが変わった場合でも、影響を最小限に抑えられるソフトウェアは「互換性が高い」といえます。互換性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
互換性 |
共存性 |
他ソフトウェアに悪影響を与えたり、悪影響を受けたりせずに動作するか（例：同じPC上で、他アプリケーションを同時に起動しても問題なく動作できるか） |
|
相互運用性 |
他ソフトウェアや他機器と連携できるか（例：旧バージョンで作成されたファイルを新バージョンで開き、編集できるか） |
3-4 インタラクション容易性、対話性
「インタラクション容易性、対話性」は、想定される利用者・利用状況において、どれだけ使いやすいかの度合いです。ユーザーや運用者など、開発者以外の立場に焦点を当てます。
対象の利用者がストレスなく快適に利用でき、高い満足度を感じられるソフトウェアは「インタラクション能力が高い」といえます。インタラクション容易性、対話性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
インタラクション容易性、対話性 |
適切度認識性 |
自分のニーズに合うソフトウェアだと直感的に認識できるか（例：紹介ページや画面などを見て、自分の目的を果たせそうだとすぐ理解できるか） |
|
習得性 |
ユーザーが使い方をストレスなく効率的に習得できるか（例：マニュアルの記載どおりに処理が行えるか） |
|
|
運用操作性 |
運用者が操作しやすいか（例：バックアップ操作を効率的に行えるか） |
|
|
ユーザーエラー防止性 |
ユーザーの誤操作を防止できるか（例：不正なデータ処理時にエラーが表示されるか） |
|
|
ユーザーエンゲージメント、利用者関与性 |
ユーザーが楽しみながら使い続けたいと感じられるか（例：デザインやインタラクションがユーザーの関心を引き続けるか） |
|
|
インクルーシビティ、包摂性 |
多様な背景・文化・言語を持つユーザーが公平に利用できるか（例：多言語対応や文化的配慮がなされているか） |
|
|
ユーザ支援性 |
幅広い範囲の特性及び能力の違いがあっても、目的達成できるよう支援されているか（例：年齢や身体障害の有無を問わず幅広い人々が利用できるか） |
|
|
自己記述性 |
必要とする場面で適切な情報を提示し、迷わず操作できるか（例：使い方やできることが分かりやすいか） |
3-5 信頼性
「信頼性」は、想定される時間帯や利用状況において、機能を提供し続けられる度合いです。簡単にいえば、「どれだけ利用者の期待を裏切らずに動作できるか」となります。障害の発生しにくさや発生時の対処など、障害への対応能力に焦点を当てた品質特性です。
想定される時間帯や利用状況において障害が発生せず、ユーザーが使い続けられるソフトウェアは「信頼性が高い」といえます。信頼性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
信頼性 |
無障害性 |
システムの信頼性はユーザーにとって満足か（例：障害発生時に停止しないか） |
|
可用性、アベイラビリティ |
ユーザーが使いたい時に利用できるか（例：機能を24時間利用できるか） |
|
|
障害許容性、耐故障性 |
障害の発生をどこまで許容できるか（例：障害発生時に機能制限付きで動作を維持できるか） |
|
|
回復性 |
障害発生前の状態に戻せるか（例：データベース操作のロールバックが行えるか） |
3-6 セキュリティ
「セキュリティ」は、どれだけセキュリティリスクを低減できるかの度合いです。前提として、セキュリティリスクを完全に排除することはできません。サイバー攻撃は日々進化し続けており、継続的にセキュリティ対策を施していくことが求められます。
そのため、想定される脅威に対して適切なセキュリティ対策が継続的に施されたソフトウェアは「セキュリティ性が高い」といえます。セキュリティの品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
セキュリティ |
機密性 |
許可されたデータだけにアクセスできるか（例：管理者画面に管理者ユーザーだけがアクセスできるか） |
|
インテグリティ |
不正なアクセスやシステムエラーにより、権限のないデータの変更や削除を防止できるか（例：一般ユーザーによる管理者画面へのアクセスが禁止されているか） |
|
|
否認防止性 |
事実を否認されないように対策されているか（例：利用規約への同意が記録されているか） |
|
|
責任追跡性 |
操作や事象を後から追跡できるか（例：システムログに操作が記録されているか） |
|
|
真正性 |
偽りなく本物であると証明できるか（例：ユーザー認証が間違いなく行えるか） |
|
|
対攻撃性 |
不正アクセスやサイバー攻撃に対して正常に動作し続けられるか（例：ブルートフォース攻撃やサービス妨害攻撃への対処が講じられているか） |
3-7 保守性
「保守性」は、どれだけ適切に保守作業を行えるかの度合いです。保守作業には、コードの修正、設定ファイルの変更や引き継ぎ、環境移行にともなう動作確認などを含みます。また、機能追加や品質改善といったアップデートも保守性の評価対象です。
ソフトウェアの修正や更新の負担を軽減し、適切に保守作業を行えるソフトウェアは「保守性が高い」といえます。保守性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
保守性 |
モジュール性 |
構成要素ができる限り独立し、他の構成要素への影響を抑えられているか（例：モジュールAの変更がモジュールBに影響しないか） |
|
再利用性 |
既存の構成要素を他システムへ再利用できるか（例：バージョンアップにともない、設定ファイルの引き継ぎが行えるか） |
|
|
解析性 |
影響範囲や修正箇所、問題箇所などを解析できるか（例：ログを見て、障害の原因をすぐに特定できるか） |
|
|
修正性 |
品質を保ちつつ効率的にプログラムを修正できるか（例：コードが読みやすく、どこを直せばよいかすぐに判断できるか） |
|
|
テスト可用性、試験性 |
品質を保ちつつ効率的にテストを行えるか（例：明確な合否基準を設定できるか） |
3-8 柔軟性
「柔軟性」は、ソフトウェアを別の利用環境にうまく移行できるかの度合いです。ソフトウェア利用環境（OSやブラウザなど）の移行、新しい利用環境へのインストールなどを含みます。
利用環境の移行作業が効率的に行え、新しい利用環境に適応できるソフトウェアは「柔軟性が高い」といえます。柔軟性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
柔軟性 |
適応性 |
H/W、S/W、周辺ソフトや機器などが異なる場合でも、設定や手順によってどれだけ適応できるか（例：専門家に依存せず、運用担当者やユーザーが対応できるか） |
|
拡張性 |
負荷やデータ量の減少や増大に、リソース追加や構成変更、設定調整などにより性能や処理能力を調整し問題なく対応できるか（例：ユーザー数やトランザクション数が増加しても性能を維持できるか） |
|
|
インストール性、設置性 |
所定の場所へ効率的に配置・削除できるか（例：インストールがスムーズに行えるか） |
|
|
置換性 |
別のソフトや機器との置き換えが行いやすいか（例：データベースの移行がスムーズに行えるか） |
3-9 安全性（Safety）
「安全性（Safety）」は、ソフトウェアの利用によって人間や社会、物的環境に実質的な危害を与えないかの度合いです。特に金融システムや医療機器、自動車制御など、誤動作が人命や社会的損失に直結するソフトウェアにおいて重要な観点です。安全性の品質副特性や観点は次のとおりです。
|
品質特性 |
品質副特性 |
観点 |
|---|---|---|
|
安全性（Safety） |
運用制約性 |
危険な操作や想定外の操作を防ぐ制約が設けられているか（例：誤操作による重大な処理実行を確認ダイアログで防止しているか） |
|
リスク識別性 |
潜在的な危険やリスクを事前に識別・警告できるか（例：異常値を検知してアラートを発する機能があるか） |
|
|
フェールセーフ |
障害発生時に安全な状態に移行できるか（例：異常検知時にシステムを安全モードに切り替えられるか） |
|
|
危険警告性 |
危険な状況になりそうな場合、利用者が回避できるタイミングで事前に警告できるか |
|
|
統合時安全性 |
他の部品や機能と組み合わせて動作しているときに、想定外の状態が発生しても危険にさらされないようになっているか |
4. ソフトウェア品質特性に関するQ&A（よくある質問）
最後に、ソフトウェア品質特性を現場で活用する際によくある2つの疑問について回答します。
4-1 Q1.全ての品質特性を網羅しないといけないの？
すべての品質特性を完璧に満たす必要はありません。品質特性はあくまで「物差し」であり、網羅しようとすると膨大なコストと時間がかかります。
重要なのは、プロジェクトの目的や予算に応じて優先順位を付けることです。「絶対に外せない特性」と「あると良い特性」を明確にし、メリハリのある品質管理を行いましょう。たとえば、社内限定の業務ツールであればユーザーインターフェース快美性は後回しにし、機能適合性（業務ができること）を最優先する、といった判断が求められます。
4-2 Q2.ソフトウェアによって重視すべき品質特性は変わるの？
はい。重視すべき品質特性は、ソフトウェアの種類や利用目的によって異なります。そのため、必ずしもすべての特性を均等に高める必要はないと覚えておくと良いでしょう。
たとえば、金融システムの場合はミスや不正が許されないため、信頼性やセキュリティが最優先されます。一方、スマートフォン向けのゲームアプリであれば、楽しさや動作の軽さが求められるため、使用性や性能効率性が重視されるでしょう。
対象となるユーザーや利用シーンを想像し、重み付けを変えることが大切です。
5. まとめ：ソフトウェア品質特性を活用して品質を向上させよう
ソフトウェア品質特性とは、ソフトウェアの品質を捉えやすいように細分化した観点のことです。品質特性を活用することで、ソフトウェアの品質を可視化できるだけでなく、テスト設計や要件定義の漏れを防げるメリットもあります。
この記事では、ISO/IEC 25010（JIS X 25010）における「製品品質」の9特性について解説しました。ソフトウェア品質特性を取り入れる際には、今回の内容を参考にしてみてはいかがでしょうか。
また品質特性に限らず、ソフトウェア品質に関して理解を深めるうえではeラーニングがおすすめです。バルテスのeラーニングでは動画とテキストを組み合わせた効率的な学習がWeb上で行えます。ソフトウェア品質に関する学習の際には、ぜひお試しください。
