2.11 ソフトウェア品質

概要と動機

ソフトウェア品質とは、システムが述べられたニーズと合理的な期待をどれだけ満たすかです。それは、動くかどうかだけでなく、システムが信頼でき、安全で、保守可能で、使いやすく、性能が良く、時間を通じて目的に適しているかどうかを意味します。品質はテストより広いものです。テスト(2.4章)は、欠陥を明らかにする一つの活動です。品質は、正しいものをうまく作り、そうしたことを証拠とともに知るという、規律全体です。システムはすべてのテストを通過しても、保守できなかったり、アクセスできなかったり、ユーザーが本当に必要とするものにうまく合っていなかったりすれば、低品質でありえます。

大きなチームでは、品質は一人の頭の中や一つのチームの習慣の中に置いておくことはできません。何百人ものエンジニア、複数の製品、長寿命のシステムには、品質の共有された定義、それを保証する明示的なプロセス、そしてそれが良くなっているか悪くなっているかを教える測定が必要です。それがなければ、「品質」は、締め切りとのあらゆる議論に負ける漠然とした願望となり、変更が遅く危険になるまで欠陥が積み上がります。

企業や政府の設定では、賭け金が上がります。規制された、安全が重要な、市民向けのシステムは、品質を単に主張するのではなく、示さなければなりません。文書化されたプロセス、追跡可能な証拠、独立した検証は、しばしば義務です。貧しい品質は、直接の金銭的、法的、評判上のコストを負い、一部の領域では人々を危険にさらします。モデル、プロセス、測定、文化から作られる意図した品質の規律が、品質を偶然から管理された成果に変えます。

主要原則

品質は、目的への適合性と要求への準拠です。両方を明示的に定義します。
品質は作り込むものであって、テストで入れるものではありません。検証は欠陥を見つけ、予防はそれを避けます。
品質保証(私たちのプロセスは健全か)と品質管理(この製品は良いか)を区別します。
検証(verification)は「正しく作ったか」を問い、妥当性確認(validation)は「正しいものを作ったか」を問います。
品質を、意味のある少数の指標で測定します。指標をシグナルとして扱い、目標としてはいけません。
欠陥のコストは、見つかるのが遅いほど上がるので、品質の活動を前倒しにします。
品質は、最後のゲートではなく、組織全体とその文化の特性です。

推奨事項

ISO/IEC 25010のような共有の品質モデルを採用する

認められた製品品質モデルを採用して、組織に品質の共通の語彙を与えます。ISO/IEC 25010は、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性を含む特性を定義しています。それを使って品質を具体的にします。システムごとに、どの特性が最も重要で、それぞれについて「十分良い」が何を意味するかを決めます。これらの製品品質の特性は、アーキテクチャ(3.1章)を駆動する同じ品質特性です。品質とアーキテクチャは一つの関心事の二つの見方なので、競合する二つの優先順位ではなく、一つの優先順位のリストを共有させます。

品質保証と品質管理を分ける

品質保証(QA)と品質管理(QC)を、別個だが補完的な活動として扱います。QAはプロセス指向で予防的です。標準、レビュー、完了の定義、訓練を通じて仕事のやり方を改善し、そもそも欠陥が現れにくくします。QCは製品指向で検出的です。テスト、コードレビュー、監査のように実際の作業成果物を検査し、入り込んだ欠陥を捉えます。成熟した組織は両方に投資しますが、QAに傾きます。欠陥の予防は、見つけて直すよりも安いからです。

明示的なソフトウェア品質管理のプロセスを動かす

品質を、静かな願望ではなく、管理されたプロセスにします。重要な仕事には、目標とする品質特性、保証と管理の活動、受け入れ基準、誰が責任を負うかを述べた品質計画を書きます。すでに持っている実践に織り込みます。管理であり知識を共有する方法でもあるコードレビュー(2.5章)、自動の安全網としてのテスト戦略(2.4章)、継続的な検査としての静的解析。インシデントに反応するだけでなく、品質データを定期的にレビューし、傾向に基づいて行動します。

検証と妥当性確認を別個の規律として実践する

検証(verification)は、作業成果物がその仕様を満たすこと、つまり各段階への正しい入力が正しい出力を生むことを、レビュー、静的解析、要求に対するテストを通じて確認します。妥当性確認(validation)は、完成したシステムが実際にユーザーのニーズと意図された使用を満たすことを、ユーザーテスト、受け入れテスト、パイロット、現場のフィードバックを通じて確認します。両方が必要です。システムは、欠陥のある仕様に対して正しい(検証されているが妥当ではない)こともあれば、本物のニーズに応えながら欠陥を含んでいる(妥当だが検証されていない)こともあります。規制された環境では、開発者とは別の当事者による独立した検証と妥当性確認(IV&V)が求められることがあります。

意味のある指標で品質を測定する

品質の成果とその推進要因を反映する少数の指標を選び、時間にわたって観察します。有用な尺度には、欠陥密度、欠陥の流出率(リリース前に対して本番で見つかった欠陥)、検出と修復の平均時間、変更失敗率、複雑さや重複のようなコードの健全性のシグナル、ユーザーが報告した問題やアクセシビリティ適合のような妥当性確認のシグナルが含まれます。虚栄的で操作可能な指標は避けてください。目標になった指標は、現実を測るのをやめるからです。数字を、レビューやユーザーのフィードバックからの定性的なシグナルと組み合わせます。

欠陥を体系的に特徴づけ、管理する

欠陥を、消すべき火事だけでなく、データとして扱います。重大度、種類、根本原因で分類します。発見から解決まで追跡します。再発を防げるようパターンを探します。根本原因分析や欠陥の分類のような技法を使って、一回限りのミスと体系的な弱点を区別します。学んだことを、更新された標準、追加されたテスト、改善されたレビューを通じてQAにフィードバックし、同じ種類の欠陥が戻ってこないようにします。原因を理解せずに直された欠陥は、再び招き入れた欠陥です。

品質のコストを意図して管理する

古典的なカテゴリを通じて品質の経済学を理解します。予防コスト(訓練、標準、良い設計、ツール)、評価コスト(レビュー、テスト、監査)、失敗コスト(リリース前の内部の手戻りと、ユーザーに見つけられる外部の失敗。後者ははるかに高くつきます)。投資を予防と早期の評価にシフトさせます。そこでの1ドルが、後の失敗コストの多くのドルを避けるからです。これらのコストを可視化し、「品質に使う時間がない」が、そのとおりのもの、つまり失敗にもっと多く費やすという選択であることが見えるようにします。

品質の文化を築く

品質を全員の責任にし、最後にそれを検査する下流のQA部門に引き渡すのではなく、ソフトウェアを作るチームが所有するものにします。リーダーは品質の成果に報い、欠陥やヒヤリハットを報告しても安全にし、品質データを棒ではなく学びの道具として扱うべきです。欠陥への非難なきアプローチは、問題を早期に公にします。非難するアプローチは、高くつくまでそれらを隠します。

トレードオフ: 長所と短所

実践 / 選択	長所	短所
正式な品質モデル(ISO 25010)	共有された語彙。明示的な優先順位	教条的に適用するとオーバーヘッド
重い品質保証(予防)	欠陥が少ない。総コストが低い	前もっての投資。見返りが現れるのが遅い
重い品質管理(検査)	すり抜ける欠陥を捉える	高価。欠陥を遅く見つける
独立したV&V	高い保証。客観的	高価。遅い。対立的に感じられうる
豊富な品質指標	可視性。早期警告	操作のリスク。測定のオーバーヘッド
専任のQAチーム	集中と専門性	開発者から責任を肩代わりしうる
チームが所有する品質	オーナーシップ。速いフィードバック	あらゆる所で規律とスキルが必要

中心的なトレードオフは、投資と保証であり、タイミングによって形づくられます。予防は、後のより大きな失敗コストを避けるために、今お金を使います。だから経済的に正しい品質の水準は最大ではなく、さらなる保証の限界コストが、それが避ける失敗コストに等しくなる点です。その点は、安全が重要なシステムでは高く、リスクの低い社内ツールでは低くなります。もう一つの繰り返される緊張は、オーナーシップです。中央のQAグループは専門性を築きますが、開発者に責任を肩代わりさせえます。チームが所有する品質はオーナーシップを築きますが、あらゆる所でスキルと規律を要求します。

チームで議論すべき問い

同じ種類の欠陥が二度現れたとき、根本原因分析を実行しますか。それとも、また直すだけですか。 原因を理解せずに直された欠陥は、再び招き入れた欠陥であり、大きなチームでは、同じ根本原因が、誰かが点を結ぶ前に多くのサービスに現れえます。欠陥をデータとして扱うこと(重大度、種類、原因で分類し、パターンのために掘り下げる)が、着実に信頼性を増すチームと、同じミスを直すことに忙しいままのチームを分けます。欠陥トラッカーを会議に持ち込み、繰り返し現れる署名を探してください。最近のインシデントのうち、体系的に対処したことのない原因を共有しているものがいくつあるか。答えは予防に反映されるべきで、繰り返す原因が、更新された標準、新しい共有ヘルパー、追加されたテスト、より良いレビューのチェックリストを促します。一か所の修正が、その種類全体の再発を止める方法だからです。
私たちのチームでは、欠陥やヒヤリハットを報告しても安全で、それを提起した人はどうなりますか。 品質は文化の特性であり、非難なきアプローチは問題を早期に公にし、非難するアプローチは高くつくまで隠します。規制されたシステムや市民向けのシステムでは、それは公的な失敗や罰則を意味しえます。これは規模が大きくなるほど重要になります。リスクに最も近いエンジニアはしばしばジュニアで、黙っている動機が強いからです。誠実なシグナルを持ち込んでください。ヒヤリハットは記録され議論されるか、それとも消えるか。ポストモーテムは原因を名指しするか、人を名指しするか。行動は、品質データを棒ではなく学びの道具にし、問題を表面化させる人々に報い、非難なきポストモーテムを実施することです。チームが報告を恐れるものは、防げないからです。
妥当性確認は実際にリリースを止められ、締め切りが迫るとき、その権限は誰が持ちますか。 検証(正しく作ったか)と妥当性確認(正しいものを作ったか)は別個の規律であり、妥当性確認は、失敗したアクセシビリティのチェック、失敗した受け入れテスト、あるいは決定的に不利なユーザーリサーチが、出荷を本当にブロックできる場合にだけ力を持ちます。企業や政府の設定では、これはしばしば義務で、ときに開発者とは別の当事者による独立した検証と妥当性確認を通じ、「とにかく出荷した」は監督機関が受け入れる答えではありません。直近のリリースをいくつか持ち込んでください。品質のシグナルが実際にリリースを止めたことはありますか。それとも、ゲートはいつも日付に譲りますか。妥当性確認が一度もリリースをブロックしたことがないなら、それは飾りであり、直し方は、受け入れ基準を前もって品質計画に書き込み、継続・中止の決定を誰が所有するかを名指しし、その決定にデリバリーの圧力から独立した本物の権限を与えることです。
私たちは貧しい品質のコストを実際に知っていて、支出を失敗から予防へと意図してシフトさせていますか。 貧しい品質のコスト(COPQ)は、内部の手戻り、本番のインシデント、緊急の修正、サポートの負荷、失われたユーザー、罰則で失われるお金であり、ほぼ常に、レビューとテストへの目に見える支出より大きいものです。大きなチームでは、失敗コストはインシデントのチャンネル、サポートの待ち行列、誰も手戻りとして記録しない手戻りに散らばっているので、誰かが合計するまで見えません。緊張は、予防が、後に、他の誰かの予算に落ちる失敗コストを避けるために、予算サイクルの中で今お金を使うことで、そのため取引は永遠に先送りされやすいことです。本物の数字を持ち込んでください。インシデントの数とコスト、手戻りの時間、流出した欠陥の率、そして予防、評価、失敗にわたる現在の支出の配分を持ち込み、その組み合わせがより早い段階に動くべきかを決めます。生涯コストの大半が最初のリリースの後に発生する企業や政府のシステムでは、COPQを予算を握る人々の前に示してください。監督機関が見られる数字は、「品質」への漠然とした訴えよりも、はるかに取引で手放しにくいからです。
私たちの品質指標のうち、静かに目標になったものはどれで、今どんな行動を駆り立てていますか。 目標になった指標は現実を測るのをやめます。カバレッジの割合を追えば、欠陥を捉えるテストではなく、数字を動かすために書かれたテストが得られます。規模が大きくなると、これは危険です。数十のチームで共有されるヘッドラインのダッシュボードは、そのすべての動機を設定し、操作可能な指標は、操作をあらゆる所に一度に広げるからです。相反する考慮は、それでも測定が必要なことなので、答えはめったに「指標を捨てる」ではなく、「対抗するシグナルと組み合わせ、レビューやユーザーからの定性的な証拠と並べて読む」です。現在の指標の集合を持ち込み、それぞれについて、プレッシャーのもとにある人が、品質を改善せずにそれを動かすために何をできるか、そしてそれが起きるのを見たことがあるかを問ってください。規制された、市民向けの設定では、基礎にある妥当性確認(アクセシビリティ、本物のユーザーの成果)が本当に行われたことがないまま緑に見える適合性の指標に特に警戒してください。監査人はいずれ数字の背後の現実をテストするからです。
ここで品質を所有しているのは誰ですか。コードを書くチームですか。それとも最後にいる別のグループですか。そして実際にどちらに資源を割いていますか。オーナーシップは下流のすべてを形づくります。下流のQAのサイロは、開発者が書くコードへの責任を肩代わりさせ、チームが所有する品質は、あらゆるチームでスキルと規律を求める代わりにオーナーシップを築くからです。大きなチームでは、これは二者択一ではありません。持続可能なパターンは通常、チームがコードレビューと自動テストを通じて品質を所有し、最後に品質を検査して入れるのではなく、標準を維持し、プロセス改善としての品質保証を行い、コーチングする小さな中央のグループに支えられるものです。品質の仕事が現在どこで行われているか、欠陥が流出したとき誰が責任を負うか、予算と人員が実際にどこにあり、レトリックが品質の居場所だと言う所とどう違うかについての、誠実なマップを持ち込んでください。企業や政府の組織では、独立した検証と妥当性確認の要件を加えてください。一部の保証の制度は別の当事者を義務づけているので、どの統制がデリバリーチームに属し、どれが監査を満たすために独立したままでなければならないかを、意図して決めてください。

セクター別の視点

スタートアップ。 儀式より速度が重要なので、製品を実際に守る二、三の品質特性、通常は信頼性と保守性に名前を付け、磨き上げは待たせます。配置できない別のQAグループを立ち上げるのではなく、コードレビューとささやかな自動テストのスイートで、チーム全体で品質を所有します。同じ種類のバグが二度現れたら、根本原因に20分を費やし、共有ヘルパーとテストを一つ加えるので、予防は安いままで、素早く動きながら変更失敗率は低く保たれます。

小規模事業者。 専任の品質の専門家はおらず予算も厳しいので、自分で動かさなければならないプロセスではなく、買うツールとプラットフォームに組み込まれた品質に頼ってください。ソフトウェアを選ぶとき、ベンダーの品質の証拠を購入の一部として扱います。セキュリティの姿勢、アクセシビリティ、サポートの応答性、リリースがどれだけ頻繁に壊れるか。保守する人のいない凝った指標プログラムではなく、安くて誠実な少数のシグナル(本番のインシデント、顧客が報告した問題、修正までの時間)を追跡します。

大企業。 仕事は多数のチームにわたる一貫性です。ISO/IEC 25010のような共有の品質モデルを採用し、品質保証(プロセス)と品質管理(製品)を分け、支出を予防にシフトさせる品質コストのレビューを実施します。品質はデリバリーチームが所有し続け、標準を維持し、欠陥の流出率、変更失敗率、コードの健全性の傾向のダッシュボードを維持する小さな中央のグループに支えられます。グループが品質の実践を再発明するのをやめるよう、語彙とゲートを標準化し、チームには、その基準を自分たちのやり方で満たす余地を残します。

政府。 調達、透明性、公的な説明責任が枠組みを設定するので、品質要件を契約に書き込み、主張ではなく、文書化された追跡可能な品質の証拠を求めます。開発者とは別の当事者による独立した検証と妥当性確認、義務づけられたアクセシビリティ適合、監査証跡の一部として保持される重大度と根本原因を伴う欠陥の記録を予期してください。貧しい品質のコストの数字(手戻り、不服申し立て、サービスの失敗)を監督機関に報告し、頼りにしている市民を失望させるリリースをブロックする本物の権限を、妥当性確認に与えます。

事例

スタートアップ。 5人のスタートアップは、初期の製品にとって、信頼性と保守性が重要な品質特性だと決め、ピクセル単位の磨き上げは待たせます。品質はチーム全体が所有します。コードレビューとささやかな自動テストのスイートが管理で、欠陥を渡す別のQAグループはありません。同じ種類のバグが二度現れたとき、彼らは素早く根本原因を見るのに20分を使い、共有ヘルパーとテストを一つ加えるので、毎回手で直す代わりに再発が止まります。その予防の小さな習慣が、まだ速く動いている間、変更失敗率を低く保ちます。

大企業。 大手の金融サービス会社が、ISO/IEC 25010を品質の語彙として採用し、製品ごとに信頼性、セキュリティ、保守性の目標水準を記録します。チームが品質を所有します。コードレビューと自動テストはパイプラインの管理で、小さな中央のグループが標準を維持しコーチングすることでQAを運営します。品質ダッシュボードが、欠陥の流出率、変更失敗率、コードの健全性の傾向を追跡します。欠陥は分類され根本原因が分析され、繰り返す原因が共有ライブラリとチェックリストの更新を促します。リーダーシップは品質コストのデータを四半期ごとにレビューし、支出を予防にシフトさせて、本番のインシデントとその修正コストの両方を減らしました。

政府。 市民向けの給付プラットフォームを提供する国の機関が、文書化された品質の証拠を求める保証の制度のもとで働いています。リリースごとの品質計画を伴う正式な品質管理のプロセスを動かし、開発者とは別のチームによる独立した検証と妥当性確認も行います。検証は、政策にたどれる要求に対して各作業成果物をチェックします。妥当性確認には、アクセシビリティ適合のテストと本物の市民とのユーザーリサーチが含まれ、どちらもリリースをブロックできます。欠陥は、監査証跡の一部として重大度と根本原因とともに追跡され、貧しい品質のコストの数字(手戻り、不服申し立て、サービスの失敗)は、予防への継続的な投資を正当化するために監督機関に提出されます。

ビジネスケース: 動機、ROI、TCO

品質の見返りは、より低い総所有コストと、安定したデリバリー速度です。品質のコストには二つの側面があります。良い支出である予防と評価は、可視で制御可能です。設計、標準、レビュー、テスト、ツール。貧しい品質のコスト(COPQ)はより大きいですが、しばしば隠れています。内部の手戻り、本番のインシデント、緊急の修正、顧客サポート、失われたユーザー、規制上の罰則、評判の傷。Crosbyの「Quality Is Free」にさかのぼる研究は一貫して、貧しい品質の総コストが、それを予防するコストをはるかに上回り、欠陥は捉えるのが遅いほどはるかに高価になることを見出しています。設計で見つかった問題は、同じ問題が本番で見つかる場合のコストのほんの一部です。

リーダーシップにとって、論拠は「品質にもっと使え」ではありません。「全体で少なく使うために、早く使え」です。自分たちのデータからCOPQを定量化し(インシデントの数とコスト、手戻りの時間、流出した欠陥の率)、予防と早期の評価がそれをどう下げるかを示してください。品質をビジネスの成果に結びつけます。信頼性は顧客を引き留め、保守性は将来の変更を安く保ち、セキュリティとアクセシビリティは法的なトラブルから遠ざけます。コストの大半が最初のリリースの後に発生する長寿命の企業や政府のシステムでは、品質の保守性と信頼性の次元が生涯コストを支配します。それが、早期の品質への投資を、あなたにできる最もてこの効く決定の一つにします。

アンチパターンと落とし穴

最後のゲートとしての品質: 品質を作り込む代わりに最後に検査して入れようとし、欠陥が最も高価なときに見つかること。
テストと品質の混同: テストの合格が高品質を意味すると想定し、保守性、使用性、目的への適合を無視すること。
サイロとしてのQA: 「品質を所有する」下流のチームが、開発者に自分の書くコードへの責任を肩代わりさせること。
指標の芝居: カバレッジの割合や欠陥数を目標として追い、操作を招いて本物の品質を隠すこと。
妥当性確認のない検証: 仕様を正しく作りながら、仕様が本物のニーズを満たすかを確かめないこと。
根本原因分析がない: 体系的な原因に対処せず個々に欠陥を直し、同じ種類が再発すること。
貧しい品質のコストの無視: 失敗コストが隠れて測定されていないため、品質を純粋なコストとして扱うこと。

成熟度モデル

レベル1(開始)。 品質は未定義で場当たり的です。個人の勤勉さに頼り、主に最後の手作業のテストでチェックされ、欠陥は表面化するにつれて反応的に扱われます。共有のモデルも指標もなく、保証と管理の間の線もありません。

レベル2(発展)。 基本的な実践が現れます。コードレビュー、自動テスト、欠陥トラッカー。一部の品質データは集められますが、不均一で、各チームが独自のやり方で行います。品質はまだ大半がテストと見なされ、予防は最小限で、検証は行われ、妥当性確認は非公式です。

レベル3(標準化)。 組織が共有の品質モデル(ISO/IEC 25010など)を採用し、QAとQCを分け、品質計画と受け入れ基準を伴う品質管理のプロセスを、文書化してチーム間で一貫して適用します。検証と妥当性確認は別個で意図されたもので、欠陥は合意された方式で分類され、根本原因が分析されます。

レベル4(管理)。 品質がベースラインに対して測定され、制御されます。意味のある少数の指標(欠陥密度、欠陥の流出率、検出と修復の平均時間、変更失敗率、複雑さや重複のようなコードの健全性のシグナル)が時間にわたって追跡され、品質のコストが予防、評価、失敗にわたって定量化されます。受け入れと品質のゲートは意見ではなく証拠で徹底され、傾向は一定の周期でレビューされ、妥当性確認は本当にリリースをブロックできます。

レベル5(オーケストレーション)。 品質は、継続的に改善され、文化的に所有される、ビジネスとリスクの計画に統合された規律です。予防が重視され、品質コストのデータが投資の向かう先を導き、根本原因の発見が体系的に再発を防ぎます。チームは品質を端から端まで所有し、指標は継続的な改善にフィードバックされ、組織は製品、リスク、規制の変化に応じて品質の実践を適応させます。これは10.8章の成熟度モデルの上位レベルと整合します。

議論のためのアイデア

ISO/IEC 25010の品質特性のうち、あなたのシステムにとって最も重要なものはどれで、それぞれの「十分良い」とは何ですか。
あなたの組織は、予防・評価・失敗の支出の組み合わせのどこにあり、それはシフトすべきですか。
実際に検証と妥当性確認を区別していますか。それとも、両方を「テスト」にまとめていますか。
品質は、ソフトウェアを作るチームが所有していますか。それとも別のグループに委ねられていて、移したら何が変わりますか。
貧しい品質の本当のコストは何で、ビジネスケースを作るのに十分測定できますか。
品質指標のうち、本物のシグナルはどれで、操作可能な目標になってしまったのはどれですか。

要点

品質はテストより広いものです。信頼性、セキュリティ、保守性のような特性にわたる、目的への適合性と準拠です。
品質特性が明示的でアーキテクチャ(3.1章)と整合するよう、共有の品質モデル(ISO/IEC 25010)を使います。
品質保証(予防、プロセス)と品質管理(検出、製品)を分け、予防に傾けます。
検証(正しく作った)と妥当性確認(正しいものを作った)を、別個の規律として実践します。
意味のある少数の指標で品質を測定し、再発を防ぐために欠陥を重大度と根本原因で特徴づけます。
品質のコストを管理します。予防と早期の評価は、特に長寿命のシステムで、失敗よりはるかに安いものです。
コードレビュー(2.5章)とテスト戦略(2.4章)に支えられた、チームが品質を所有する、非難なき品質の文化を築きます。

参考文献とさらなる読み物

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Quality knowledge area.
ISO/IEC 25010, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE): System and software quality models.
ISO/IEC 25000 series (SQuaRE), Software product quality requirements and evaluation.
Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain.
W. Edwards Deming, Out of the Crisis.
Capers Jones and Olivier Bonsignour, The Economics of Software Quality.
Gerald Weinberg, Quality Software Management.
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (quality assurance and V&V process context).