本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。
1. 製品品質モデルを「要求の抜け」と「評価のブレ」対策として使う
ソフトウェアの品質を議論すると、要件定義では「使いやすく」「速く」「安全に」といった抽象語が並び、テストや受け入れでは「どこまで確認すれば合格か」が曖昧になりやすいです。ここで役立つのが、ISO/IEC 25010 の 製品品質モデル です。ISO では、製品品質モデル（product quality model）を8つの品質特性（quality characteristics）で構成し、それぞれを副特性に分解できる枠組みとして示されています。(ISO)
ISO/IEC 25010:2011 は ISO サイト上で「Withdrawn（廃止）」と表示されており、新バージョンとして ISO/IEC 25010:2023 が案内されています。(ISO)
日本では、JSA（日本規格協会）の Webdesk 上で ISO/IEC 25010:2023 に対応する JIS X 25010:2025（IDT） が示されています。(日本規格協会 JSA GROUP Webdesk)
※ISO/IEC 25010:2023 / JIS X 25010:2025 の「最新の特性セットの詳細」は規格本文に依存するため、公開情報だけで断定できません。組織でどの版（2011/2013 か 2023/2025 か）を採用するかを先に決めておくと、以降の議論が揺れにくくなります。(ISO)
2. 前提: SQuaRE と「製品品質」対「利用時の品質」
重要用語の定義
- SQuaRE（Systems and software Quality Requirements and Evaluation）: ISO/IEC 25000 シリーズの総称で、品質モデル・品質要求・測定・評価などを体系化します。IPA資料でも、SQuaRE が品質モデル部門（2501n）や品質測定部門（2502n）などに分かれることが説明されています。(特許庁)
- 製品品質（product quality）: ソフトウェア/システムそのものが持つ静的・動的な性質を、特性と副特性で整理します。(ISO)
- 利用時の品質（quality in use）: 特定の利用状況における「達成度・効率・満足・リスク回避・利用状況網羅性」など、利用結果に関する品質です。IPA資料では、製品品質と利用時の品質が別概念という点が強調されています。(特許庁)
両者を分ける実務上の理由
製品品質が高くても、利用環境や運用条件によって UX（User Experience）が悪化し、事故や苦情につながる場合があります。IPA資料では、同じ製品品質でも利用環境次第で「使いやすい場合もあればリスクを招く場合もある」と述べられており、製品品質と利用時の品質を分けて扱う重要性が示されています。(特許庁)
以下の関係で捉えると、実務での混乱が減りやすいです。
(内部品質/実装・設計) → 製品品質（ISO/IEC 25010: 製品品質モデル） → 利用時の品質（利用時の品質モデル）※組織の品質保証プロセスでは、まず「製品品質モデル」で要求とテスト観点を網羅し、そのうえで「利用時の品質」をユーザテストや運用モニタリングで補完する、という二段構えが現実的です。(特許庁)
3. 製品品質モデル: 8特性・31副特性をチェックリストではなく「分解器」として使う
ISO では、製品品質モデルが 8つの品質特性から構成されることが明示されています。(ISO)
（ここでは、JIS X 25010:2013 / ISO/IEC 25010:2011 相当の一般的な整理を採用します。※最新版の差分は規格本文で確認が必要です）
8特性と副特性の対応表
| 品質特性 | 副特性（例） | 現場での典型的な「論点」 |
|---|---|---|
| 機能適合性 | 機能完全性 / 機能正確性 / 機能適切性 | 要求された機能が漏れなく正しく、業務を余計に増やさず達成できるか |
| 性能効率性 | 時間効率性 / 資源効率性 / 容量満足性 | p95応答時間、同時接続、CPU・メモリ、スループットが足りるか |
| 互換性 | 共存性 / 相互運用性 | 他システムとデータ連携できるか、同居で干渉しないか |
| 使用性 | 適切度認識性 / 習得性 / 運用操作性 / ユーザエラー防止性 / UI快美性 / アクセシビリティ | 迷い・誤操作・学習コストを減らせるか、支援技術でも使えるか |
| 信頼性 | 成熟性 / 可用性 / 障害許容性 / 回復性 | MTTR、フェイルオーバ、復旧手順、データ整合で止まらないか |
| セキュリティ | 機密性 / インテグリティ / 否認防止性 / 責任追跡性 / 真正性 | 認証・認可、改ざん耐性、監査ログ、本人性、説明責任を満たすか |
| 保守性 | モジュール性 / 再利用性 / 解析性 / 修正性 / 試験性 | 変更容易性、影響範囲把握、テスト容易性、技術的負債の制御 |
| 移植性 | 適応性 / 設置性 / 置換性 | OS/クラウド移行、インストール、バージョン更新、乗換え容易性 |
※副特性名や用語のニュアンスは訳語差が出る。
4. 品質要求に落とす: 「品質特性→シナリオ→測定可能な基準」の順で固める
製品品質モデルは「品質の観点を網羅する」ための枠組みで、全部を同じ強度で満たす前提ではありません。テスト設計の漏れを減らす観点として品質特性を使う、という整理も一般に行われます。(Qbook | ソフトウェアの品質向上プラットフォーム by VALTES)
したがって実務では、次の順序で要求を具体化するとブレが減りやすいです。
手順1: 利害関係者と利用状況を固定する
- 利害関係者: 利用者、運用者、保守担当、監査担当、購買（取得者）など
- 利用状況: 利用端末、ネットワーク条件、ピーク時間、障害時運用、データ連携先
ISO では、品質モデルが「要求の包括性検証」や「受け入れ基準設定」に使えることが挙げられています。(ISO)
手順2: 優先する特性を選び、品質シナリオにする
品質シナリオは「状況・刺激・応答・測定」で書くと測定可能になる。
例（性能効率性・信頼性）:
- 状況: 平日12:00、同時ログイン2,000
- 刺激: 注文確定API呼び出し
- 応答: 2秒以内で結果返却、失敗時はリトライ可能なエラーを返す
- 測定: p95応答時間、エラーレート、スループット
手順3: 受け入れ基準（Acceptance Criteria）を数値/判定で定義する
測定量（メトリクス）を置き、閾値を決めます。IPA資料では、品質測定量と測定法が「要素を確定し、組み合わせて計算し測定結果を出す」流れで整理されています。(特許庁)
代表例:
- 欠陥密度: $D = \frac{\text{欠陥数}}{\text{KLOC}}$
- 可用性: $A = \frac{\text{稼働時間}}{\text{稼働時間} + \text{停止時間}}$
- p95応答時間（秒）: パーセンタイルで合否判定（平均だけに依存しない）
※ここは組織のSLA（Service Level Agreement）や運用コストに直結するため、必要に応じて専門家（SRE、セキュリティ、法務/監査）に確認すると安心です。
5. 測定とテスト設計: 「副特性→テスト観点→測定方法」を1枚に落とす
製品品質モデルを運用可能にする最短ルートは、品質副特性を“テスト観点の辞書”として使い、各観点に測定方法を紐付けることです。JaSST資料でも、品質副特性にテスト観点を紐付ける考え方が示されています。(JaSST -)
例: 品質特性テストマトリクス
| 特性/副特性 | 代表テスト | 測定量/判定 | いつ実施 |
|---|---|---|---|
| 性能効率性/時間効率性 | 負荷試験 | p95応答時間 ≤ 2.0s | リリース前・性能変更時 |
| 信頼性/回復性 | 障害復旧演習 | RTO（目標復旧時間）≤ 30分 | 四半期ごと |
| セキュリティ/真正性 | 認証・セッション試験 | 乗っ取り/固定化耐性 | リリース前・認証改修時 |
| 保守性/解析性 | 静的解析 | 複雑度、ルール違反数 | CIで常時 |
| 移植性/設置性 | デプロイ試験 | 自動化率、手順数 | リリース前 |
IPA資料が示すように、SQuaRE の枠組みでは品質測定量と測定法が体系化されています。(特許庁)
実務では「測定量を決めても測定法が決まらない」ことが多いため、“誰が・どの環境で・どのツールで・どの頻度で” まで仕様化しておくと運用しやすいです。
6. 実装例: Web API サービスでの要求定義（YAML）と CI への組み込み
ここでは、製品品質モデルを「要求の文章」から「検証可能な定義」に変換する最小例を示します。
6.1 品質要求の雛形（YAML）
quality_requirements:
performance_efficiency:
time_behaviour:
target: "注文確定API"
metric: "p95_response_time_seconds"
threshold: 2.0
load_profile:
concurrent_users: 2000
ramp_up_seconds: 300
reliability:
availability:
metric: "monthly_availability"
threshold: 0.999
recoverability:
metric: "rto_minutes"
threshold: 30
security:
authenticity:
requirement: "MFA必須（管理者）"
accountability:
requirement: "監査ログ: 誰が/いつ/何を を改ざん耐性付きで保存"
maintainability:
analysability:
metric: "cyclomatic_complexity_max"
threshold: 15
testability:
metric: "unit_test_coverage"
threshold: 0.706.2 CI での運用ポイント
- 性能効率性: 変更差分が性能へ影響する箇所（DBクエリ、キャッシュ、暗号化）だけでも「回帰負荷」を走らせておくと、性能劣化の見落としが減りやすいです
- セキュリティ: 認証/認可とログは副特性（真正性・責任追跡性）に直結するため、仕様と試験を同一リポジトリで管理すると追従しやすいです
- 保守性: 「解析性・修正性・試験性」は“遅れて効くコスト”なので、CIで基準を継続的に運用しないと形骸化しやすいです
※性能やセキュリティの受け入れ基準は、障害時の損失規模や法規制の影響を受けます。業界（金融・医療・公共）によって必要水準が大きく変わるため、前提条件を明示して合意しておくと安全です。
7. ありがちな失敗と回避策（製品品質モデルを形骸化させない）
- 8特性を全部“必須”にして破綻する
→ まず「業務価値に直結する特性」を選び、次に「事故時の損失が大きい特性（信頼性・セキュリティ等）」を選ぶと整理しやすいです。ISO では要求の包括性検証に品質モデルを使える旨が示されていますが、同時に“特性を要求に落とす”実務設計が重要になります。(ISO) - 副特性がテスト観点に変換されず、チェックリストで終わる
→ 副特性ごとに「測定量・測定法・実施頻度」を決め、テストマトリクスを成果物として残すと運用に乗りやすいです。(特許庁) - 利用時の品質と混同する（UX問題を製品品質だけで解こうとする）
→ 製品品質で担保できる範囲を明確にし、利用時の品質はユーザテストや運用データで評価すると切り分けやすいです。IPA資料でも両者の差が明確化されています。(特許庁) - 翻訳語や版差で用語が揺れ、議論が空転する
→ 採用規格（ISO/IEC 25010:2011 か 2023、JIS X 25010:2013 か 2025）を固定しておくと、用語の揺れを抑えやすいです。ISO では2011版がWithdrawnで新バージョンがあることが示されており、JSA Webdesk では2023とJIS 2025の対応が示されています。(ISO)
8. まとめ
- 製品品質モデル は、品質議論を「抽象語」から「副特性レベルの論点」へ分解し、要求・測定・テスト設計を一直線でつなぐための枠組みとして使えます。(ISO)
- 実務では、特性を選択し、品質シナリオ化し、測定可能な受け入れ基準へ落とす ことで運用に乗りやすくなります。(特許庁)
- 2011版は廃止扱いで、2023/2025系の最新版が案内されています。組織で採用する版を決め、用語・副特性・判定基準を統一しておくと、資料や会話の整合が取りやすいです。(ISO)
- 利用時の品質 と 製品品質 は別概念なので、製品品質だけでは利用環境起因のリスクを取り切れない場合があります。(特許庁)
A. 参考サイト
- ISO: ISO/IEC 25010:2011（Withdrawn表示とモデル概要） (ISO)
- 日本規格協会 Webdesk: ISO/IEC 25010:2023 と JIS X 25010:2025 の対応表示 (日本規格協会 JSA GROUP Webdesk)
- IPA（情報処理推進機構）:「システム及びソフトウェアの品質測定量とその測定方法」 (特許庁)
- IPA（情報処理推進機構）:「つながる世界の利用時の品質」 (特許庁)
- VeriServe: ソフトウェア品質特性（ISO/IEC 25010）の解説（利用時の品質・製品品質の整理に有用） (veriserve.co.jp)
コメント