品質の特定のためのパターン（2）：「測定可能なシステム品質」「品質の折り込み」「着陸ゾーン」

QA to AQ　第6回

　本連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集『Quality Assurance to Agile Quality』（以下、QA2AQ）の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いします。6回目となる今回は、前回に引き続きアジャイルで重要な品質特性を特定するためのパターンをまとめた、分類「品質の特定」の中から、3つのパターン、「測定可能なシステム品質（Specify Measurable Values or System Qualities）」「品質の折り込み（Fold-out Qualities）」「着陸ゾーン（Agile Landing Zone）」の和訳を提供します。

表1　QA2AQにおける分類とパターン

分類	概要	パターン名
中核	他のパターンを用いるうえでの基礎となるパターン	アジャイル品質プロセス [1]（第1回） 障壁の解体 [3]（第1回）
品質のアジャイルなあり方	アジャイルプロセスにおける品質保証のあり方や役割のパターン	QAを含むOneチーム [1]（第2回） 品質スプリント [1]（第2回） プロダクト品質チャンピオン [5]（第2回） アジャイル品質スペシャリスト [6]（第3回） 品質チェックリスト [5]（第3回） 品質作業の分散 [6]（第3回） 品質エキスパートをシャドーイング [5]（第4回） QAリーダーとペアリング [3]（第4回） できるだけ自動化 [6]（第4回）
品質の特定	重要な品質を特定するためのパターン	重要な品質の発見 [2]（第5回） 品質シナリオ [1]（第5回） 品質ストーリー [1]（第5回） 測定可能なシステム品質 [2]（第6回） 品質の折り込み [1]（第6回） 着陸ゾーン [2]（第6回） 着陸ゾーンの再調整 [2] 着陸ゾーンの合意 [2]
品質の可視化	重要な品質を可視化しチームメンバーに気付かせるパターン	システム品質ダッシュボード [2] システム品質アンドン [4] 品質ロードマップ [4] 品質バックログ [4]

測定可能なシステム品質

• 測定可能なシステム品質（原題Specify Measurable Values or System Qualities , 原著 Joseph W. Yoder and Rebecca Wirfs-Brock）[2]

　「測定しなければ、すべての線は完璧な長さである」――Marty Rubin（カナダの作家）

　望ましい品質が達成されたかどうかを知るには、測定する必要があります。測定しようとしている品質と、具体的な状態の説明は、曖昧であやふやのままにすることはできません。

　品質に期待する値とその測定方法はどのように決定できるでしょうか？

＊＊＊

　パフォーマンスや処理能力などのシステムの品質特性の場合、これは比較的簡単な場合があります。特定シナリオのシステムパフォーマンスを繰り返し測定し平均値を得ることによりパフォーマンスを測定できます。

　信頼性などの他の品質特性については、一定期間にわたって行われる複雑な一連の測定が必要になる場合があります。

　ユーザビリティなどの一部の品質特性では、一見完全に主観的に見えるため、結果として測定が非常に困難になる場合があります。大まかな表現の品質属性は、測定および集計される小さな属性に分解する必要があるかもしれません。

　一部の品質特性は測定が困難、あるいは費用が掛かりすぎます。複雑な品質特性を測定するには、かなりの労力が必要となります。

　品質の変化に対応できるように、システムを設計および構築しているときに、頻繁に測定を行いたいと考えることがあります。

　測定に必要な時間と労力について、得られる情報とバランスを取ることは、困難なときがあります。

＊＊＊

　したがって、品質を測定し、必要な精度と正確さで記述する適切な方法を定義します。

　これには、測定する適切な方法（メーター）を定義または見つけることと、期待する値（スケール）を正確に記述することが含まれます[Gilb]。

　測定スケールには、自然、構築、または代理の3つのタイプがあります。自然スケールとは、明らかに特定の品質に関連付けられているスケールであり、通常は最も簡単に同意できるものです。例として、ミリ秒単位のシステム操作を実行する処理時間や24時間以内のページヒット数などがあります。構築スケールは、品質を測定するために特別に構築されたスケールです。たとえば、7段階のユーザー満足度スケールがあります。

　システムの品質特性を直接測定する方法を知ることが難しい場合があります。この場合、代理スケールを使用することができます。システムの一部を測定し、特定のシステム品質を知り、期待値を推定します。代理スケールは、品質の間接的なスケールです。たとえば、サンプルデータを使用してトランザクションスクリプトを実行することにより、システム処理能力を予測します。

　品質を直接測定するには費用がかかりすぎるか、時間がかかる場合は、代理スケールを選択します。また、システムの一部がまだ完成または統合されていない場合、代理スケールを構築する必要があるかもしれません。代理スケールを使用した測定から始めて、本番環境で品質の監視を続けたい場合は、自然スケールに移行することができます。

　特にユーザビリティ品質特性では、必要な精度と正確さを追加するのは難しい場合があるため、「システムは簡単に使えるものであること」という非常に曖昧な文言をどのように改善するかについて例示してみます。

　最初の試みでは、特定のタスクと、そのタスクにとって「簡単」とは何かを特定することで、より正確にしていきます。

　初心者ユーザーの80％は、支援なしで3分以内に1つのアイテムを正常に注文できるようにする必要がある。

　さらに詳細さを追加していきます、注文の速さを評価するだけでなく、オンラインヘルプが助けになるか邪魔になるかを確認したいとします。

　初心者ユーザーの80％は、オンラインヘルプを使用した場合のみ、3分以内に単一のアイテムを正しく注文できる。

　「簡単に使えること」を測定するには、2つの重要な考え方があります。第一に、測定対象の可能な値を制限するスケールがあります。ここでは、「初心者が、オンラインヘルプのみを使用して1アイテムの注文を完了するのに必要な時間」。　第二に、測定方法を定義するメーターがあります。たとえば、1人のユーザーのみを測定し、すべてのユーザーに対しての推定をしたくないため、100人のユーザーについてのテストで得られた時間を平均するといった方法を決定することができます。

　自然スケールを見つけることが最善です。通常、人々は「簡単に使える」ということを主張しません。自然スケールが見つからない場合は、次に代理スケールを探してください。測定しようとしているものをより小さな部分に分解して、再試行する必要があるかもしれません。たとえば、「新しいローン契約の追加」には、いくつかのサブステップがあり、それぞれに実行する時間が必要です。また、さまざまな状況で期待値を指定するには、いくつかの異なるシナリオが必要になる場合があります。

　最後に、精度が必要な場合には、具体化するために修飾語句を組み込む必要があるかもしれません。たとえば、測定しようとしている対象が古いユーザーの応答だけでない場合は、「オンラインヘルプのみを使用して、初心者が1アイテムの注文を完了するのに必要な時間」がそれにあたります。

　メーターは、測定値を提供するために合意された方法です。メーターを見つけるには、スケールを見てください。明らかなメーターが思い浮かばない場合は、他のユーザーに経験を尋ねるか、合理的なメーターが付いた「既製」のツールを探します。

　メーターが見つかったら、以下を確認します。

• 利害関係者が、それが適切であることに同意している
• より費用対効果の高いメーターがない
• 理想的には、導入前にシステムでテストできること

　測定するものは何であっても、品質目標に合意すること（着陸ゾーンの合意）が重要です。これらの測定可能なシステム品質は、最終的に本番システムの監視で使用されるかもしれないシステム品質ダッシュボードに含めることができます。