PR

ソフトウェア品質の「利用時の品質モデル」実務適用ガイド（ISO/IEC 25010）

この記事は約11分で読めます。

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

  1. 1. 導入：利用時の品質が扱う範囲を固定する
  2. 2. モデル全体像：5特性と副特性を「測れる形」に変換する
    1. 2.1 利用時の品質（Quality in Use）の5特性
    2. 2.2 副特性（サブ特性）まで落として「評価観点」を固定する
    3. 2.3 「ユーザビリティ」との関係（混同を避ける）
  3. 3. 重要になる理由：製品品質が高くても、利用時の品質が崩れる典型パターン
    1. 3.1 製品品質（開発者視点）だけでは「成果」を保証できない
    2. 3.2 利害関係者が「一次利用者」だけではない
  4. 4. 方法：利用状況を定義し、品質特性を「要求」に変換する
    1. 4.1 利用状況（コンテキスト）を分解するテンプレ
    2. 4.2 要求への落とし込み例（ECの購入フロー）
  5. 5. 測定設計：ISO/IEC 25022 の思想で「指標・手段・頻度」を決める
    1. 5.1 測定の3レイヤ（推奨）
    2. 5.2 指標カタログ（最小セット）
    3. 5.3 「利用状況網羅性」を測るためのセグメント設計
  6. 6. 実装例：ログとユーザーテストで「有効性・効率性」を可視化する
    1. 6.1 ログ設計（イベントの最小形）
    2. 6.2 SQL例：タスク成功率と中央値時間
    3. 6.3 Python例：利用状況網羅性の差分（セグメント比較）
    4. 6.4 ユーザビリティテスト（観察）で原因を確定する
  7. 7. 注意点・よくある誤り：指標が増えても品質が上がらない理由
    1. 7.1 「満足性」をアンケート1問で済ませる
    2. 7.2 効率性を「処理性能」だけで代替する
    3. 7.3 リスク回避性を「セキュリティ」だけに閉じる
    4. 7.4 利用状況網羅性を「対応ブラウザ一覧」で終える
    5. 7.5 計測がプライバシー侵害になる
  8. 8. まとめ：利用時の品質を「要求→測定→改善」のループに組み込む
  9. A. 参考サイト
  10. B. 関連書籍（日本語を優先、リンク確認済み）

1. 導入：利用時の品質が扱う範囲を固定する

利用時の品質モデルは、「実際の利用状況（ユーザー、目的、環境、運用条件）」の中で、製品・システムがどれだけ目的達成に寄与するかを評価する枠組みです。ISO/IEC 25010 は品質モデルを「製品品質」と「利用時の品質」に分け、後者をユーザー視点の成果として扱います。

実務で重要なのは、利用時の品質を「UIが使いやすいか」だけに限定しない点です。ISO/IEC 25010 の利用時の品質は、有効性・効率性・満足性・リスク回避性・利用状況網羅性 の5特性で構成され、UX（User Experience）や業務影響、リスクも含めて評価します。

2. モデル全体像：5特性と副特性を「測れる形」に変換する

2.1 利用時の品質（Quality in Use）の5特性

ISO/IEC 25010 では利用時の品質を5特性に分類します（英語表記は規格側の用語です）。

特性英語意味（実務での言い換え）代表的な観測対象
有効性Effectivenessユーザーが目的を達成できる度合いタスク成功率、完了率、正確性
効率性Efficiency目的達成に必要な資源（時間・操作・コスト）がどれだけ小さいかタスク時間、操作数、待ち時間
満足性Satisfaction体験が期待を満たし、納得できるか満足度、継続意思、信頼
リスク回避性Freedom from risk利用に伴う損失・危害・環境影響を抑えるか誤操作損失、事故、法令違反
利用状況網羅性Context coverage想定内外の状況でも上記を維持できるか端末差、回線差、利用者差

※「利用状況網羅性」は JIS X 25010:2013（ISO/IEC 25010:2011 のJIS化）でも定義を確認できます。(kikakurui.com)

2.2 副特性（サブ特性）まで落として「評価観点」を固定する

利用時の品質はさらに副特性を持ちます。代表例として、満足性は「有用性・信頼・快さ・快適さ」、リスク回避性は「経済・健康安全・環境」などに分かれます（分類の枠は ISO/IEC 25010 のモデルに基づきます）。
※規格本文は有償のため、実務では「副特性の名称」よりも「何をリスク／満足として測るか」を先に決める運用が現実的です。

2.3 「ユーザビリティ」との関係（混同を避ける）

ユーザビリティ（Usability）は ISO 9241-11 の枠で「有効さ・効率・満足度」を中心に定義されます。(日本規格協会 JSA GROUP Webdesk)
利用時の品質は、ユーザビリティの3要素を含みつつ、リスク回避性 と 利用状況網羅性 を加えた拡張と捉えると整理しやすくなります。

3. 重要になる理由：製品品質が高くても、利用時の品質が崩れる典型パターン

3.1 製品品質（開発者視点）だけでは「成果」を保証できない

製品品質（例：性能効率性、信頼性、セキュリティなど）を満たしても、利用現場で目的達成できなければビジネス上の品質は下がります。ISO/IEC 25010 を解説する資料でも、利用時の品質と製品品質を分けて考える前提が示されています。(IPA)

具体例：

  • 入力画面が高速で落ちない（製品品質）一方、入力項目の意味が理解できず誤入力が多い（有効性低下）
  • セキュリティ制約が強すぎて業務が迂回し、結果的にシャドーITが発生（効率性・リスク回避性の逆転）
  • 主要ブラウザでは快適だが、モバイル回線や支援技術で操作不能（利用状況網羅性の欠落）

3.2 利害関係者が「一次利用者」だけではない

利用時の品質の評価では、直接操作する一次利用者だけでなく、運用・保守などで支援する二次利用者、出力を受け取る間接利用者も視野に入れる整理が実務上有用です。(大塚商会)
例：会計SaaSで、経理担当（一次）・情シス（支援）・管理部門（間接）で「満足性」や「リスク」の中身が変わる。

4. 方法：利用状況を定義し、品質特性を「要求」に変換する

4.1 利用状況（コンテキスト）を分解するテンプレ

利用時の品質はコンテキスト依存のため、まず利用状況を分解して文章で固定します。

  • 利用者：役割、熟練度、支援技術の有無、認知特性
  • 目的：達成すべき成果（例：申請を期限内に提出）
  • タスク：目的を構成する操作系列（例：検索→入力→確認→送信）
  • 環境：端末、OS/ブラウザ、回線、騒音、移動中、業務時間帯
  • 制約：法令、SLA、監査、プライバシー、セキュリティ規定

この分解は、JIS X 25010 が「明示された利用状況」や「想定を超越した状況」も含むとする考え方と整合します。(kikakurui.com)

4.2 要求への落とし込み例（ECの購入フロー）

例として「ECで購入完了」を目的に置きます。

  • 有効性：購入完了率（$SR=\frac{\text{成功タスク数}}{\text{実施タスク数}}$）
  • 効率性：購入完了までの時間 (T)、操作回数 (A)、待ち時間 (W)
  • 満足性：購入後アンケート（満足度、信頼、継続意思）
  • リスク回避性：誤課金率、返金率、不正利用検知率、個人情報漏えいゼロ
  • 利用状況網羅性：低帯域／小画面／支援技術でも $SR$ と $T$ を許容範囲に維持

ここで重要なのは、「特性名」ではなく「合否判定できる閾値」を置く点です。

5. 測定設計：ISO/IEC 25022 の思想で「指標・手段・頻度」を決める

ISO/IEC 25022 は、ISO/IEC 25010 の利用時の品質特性に対して測定量（measures）を定義し、測定方法の説明も含む規格です。両者を併用する前提が示されています。(ISO)
※測定量の細目は規格本文（有償）に依存するため、ここでは「実務で再現できる測定設計」に翻訳します。

5.1 測定の3レイヤ（推奨）

  1. 実利用ログ（テレメトリ）：日次で追える。母数が大きい。
  2. ユーザーテスト（観察）：原因が分かる。頻度は低い。
  3. アンケート・インタビュー：満足性・信頼・不安を補足する。

IPAの資料でも、利用時の品質評価（UX評価）と、製品品質側の「使用性」評価（ユーザビリティ評価）を分けて扱う整理が示されています。(IPA)

5.2 指標カタログ（最小セット）

特性最小限の定量指標代表的な収集方法
有効性タスク成功率、エラー率、再試行率ログ、観察
効率性タスク時間、待ち時間、ステップ数ログ、RUM（Real User Monitoring）
満足性CSAT（満足度）、継続意思、信頼アンケート、定性
リスク回避性誤課金/損失率、重大インシデント件数監査ログ、運用記録
利用状況網羅性条件別の成功率差（端末/回線/支援技術）セグメント分析、テスト

※NPSやSUS等の指標は業界で広く使われますが、ISO/IEC 25010 の公式指標そのものではありません。組織の標準に合わせて補助指標として採用されるケースが多いと考えられます。

5.3 「利用状況網羅性」を測るためのセグメント設計

利用状況網羅性は「全体平均」では見えにくくなります。以下のように分割して比較します。

  • デバイス：モバイル/PC、画面サイズ
  • 回線：低帯域/高帯域
  • 利用者：新規/熟練、支援技術利用の有無（可能なら）
  • 失敗モード：オフライン、タイムアウト、権限不足

JIS X 25010 の「利用状況完全性」「柔軟性」などの記述は、この分割測定を求める方向性と整合します。(kikakurui.com)

6. 実装例：ログとユーザーテストで「有効性・効率性」を可視化する

6.1 ログ設計（イベントの最小形）

タスク単位で開始・完了・失敗を記録すると、成功率と時間を計算できます。

  • task_start(user_id, task_id, context...)
  • task_end(user_id, task_id, result=success/fail, error_type, duration_ms, context...)

※プライバシーの観点から個人情報は避け、匿名IDや集約単位を使います。個人情報保護、電気通信事業法、医療・金融規制などは法務・セキュリティへエスカレーションします。

6.2 SQL例：タスク成功率と中央値時間

-- 購入タスク（checkout）の成功率と時間を日次で集計
WITH task AS (
  SELECT
    date_trunc('day', ts) AS d,
    user_id,
    task_id,
    max(CASE WHEN event = 'task_start' THEN ts END) AS start_ts,
    max(CASE WHEN event = 'task_end'   THEN ts END) AS end_ts,
    max(CASE WHEN event = 'task_end'   THEN result END) AS result
  FROM task_events
  WHERE task_id = 'checkout'
  GROUP BY 1,2,3
)
SELECT
  d,
  count(*) AS trials,
  sum(CASE WHEN result = 'success' THEN 1 ELSE 0 END) * 1.0 / count(*) AS success_rate,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY extract(epoch from (end_ts - start_ts))) AS median_seconds
FROM task
WHERE start_ts IS NOT NULL AND end_ts IS NOT NULL
GROUP BY 1
ORDER BY 1;

この集計で、有効性（成功率）と効率性（時間）を日次監視できます。ISO/IEC 25010 の「有効性」「効率性」という枠に対応付けやすくなります。

6.3 Python例：利用状況網羅性の差分（セグメント比較）

import pandas as pd

df = pd.read_csv("task_daily.csv")  # d, segment, trials, success_rate, median_seconds

# 例：回線種別（low_bandwidth / normal）で成功率差を算出
pivot = df.pivot_table(index="d", columns="segment", values="success_rate")
pivot["gap_low_vs_normal"] = pivot["low_bandwidth"] - pivot["normal"]

# 閾値例：成功率差が -3% を下回る日を検知
alerts = pivot[pivot["gap_low_vs_normal"] < -0.03]
print(alerts.tail(10))

「どのセグメントで品質が崩れるか」を先に特定すると、改善が要件（利用状況網羅性）に直結しやすくなります。(kikakurui.com)

6.4 ユーザビリティテスト（観察）で原因を確定する

ログで「成功率が落ちた」「時間が伸びた」までは把握できますが、原因の特定には観察が有効です。ユーザーテストを「手順化した実務ガイド」として進める際は、ユーザビリティテストの設計・実査・分析を扱う書籍が参考になります。(オーム社)

ユーザーテスト設計の最小セット：

  • タスク：ログで落ちているタスクをそのまま使う
  • 成功条件：完了定義を明文化（例：注文確定画面まで到達）
  • 測定：成功/失敗、時間、迷い（発話・視線・操作停滞）
  • 参加者：想定ユーザーの属性を合わせる（新規/熟練、端末差）

7. 注意点・よくある誤り：指標が増えても品質が上がらない理由

7.1 「満足性」をアンケート1問で済ませる

満足性は主観的で、UIの好み・価格・期待値・直前の障害などに影響されます。ISO/IEC 25010 は満足性を主要特性として扱いますが、実務では「信頼」「快さ」など要素を分けると解釈しやすくなります。
対策：最低でも「満足」「信頼」「継続意思」を分け、自由記述で理由を取る。

7.2 効率性を「処理性能」だけで代替する

処理性能（レスポンス）は効率性の一部ですが、効率性にはユーザー側の資源（手戻り、操作数、確認負荷）も含まれます。性能改善だけでタスク時間が縮まらないケースも見られます。
対策：待ち時間（システム要因）と操作時間（ユーザー要因）を分離して測る。

7.3 リスク回避性を「セキュリティ」だけに閉じる

リスク回避性は、経済・健康安全・環境といった広い影響を含みます（製品の影響を扱います）。
対策：ドメイン別にリスク項目を棚卸しする。例：金融なら誤送金、医療なら誤投薬につながるUI、B2Bなら監査不備。

7.4 利用状況網羅性を「対応ブラウザ一覧」で終える

対応表だけでは、実際に有効性・効率性・満足性を維持できるかが分かりません。利用状況網羅性は「状況における成果」を問います。(kikakurui.com)
対策：セグメント別の成功率差・時間差を継続監視する。

7.5 計測がプライバシー侵害になる

利用時の品質のためのログは、粒度を上げすぎると個人特定・行動追跡になり得ます。

8. まとめ：利用時の品質を「要求→測定→改善」のループに組み込む

  • 利用時の品質モデルは、ユーザーの成果として 有効性・効率性・満足性・リスク回避性・利用状況網羅性 を扱います。
  • 実務では、利用状況（ユーザー・タスク・環境）を先に固定し、特性を「合否判定できる要求」に変換します。(kikakurui.com)
  • ISO/IEC 25022 は測定量を整備する規格で、ISO/IEC 25010 と併用する前提が示されています。これを踏まえ、ログ・観察・アンケートの3レイヤで測定設計すると運用しやすくなります。(ISO)
  • 「利用状況網羅性」は平均値に隠れやすいため、セグメント分析と閾値監視が有効です。(kikakurui.com)

A. 参考サイト

  • IPA（独立行政法人 情報処理推進機構）「システム及びソフトウェアの品質測定量とその測定方法」（JIS X 25010に基づく図・解説を含むPDF）(IPA)
  • IPA「つながる世界の利用時の品質」（利用時の品質評価とUX評価の整理を含むPDF）(IPA)
  • JIS X 25010:2013（利用時の品質・利用状況網羅性の定義が読めるページ）(kikakurui.com)
  • ISO/IEC 25022:2016（quality in use measures の規格概要）(ISO)
  • ベリサーブ（VeriServe）「ソフトウェア品質特性とは？ISO規格や活用例」（実務寄りの解説）(veriserve.co.jp)

B. 関連書籍（日本語を優先、リンク確認済み）

コメント