はじめに
「テストを増やせば品質は上がる」── 漠然とそう思っていないでしょうか。
自分も少し前までそう信じていました。
バグが出るのはテストが足りないから、カバレッジを上げれば品質は守れる、と。
ところが実際の現場では、テスト段階で見つかったバグの修正コストは、設計段階で見つかった場合の数倍〜十数倍に膨らむことが珍しくありません。
テストは「最後の砦」であって「唯一の砦」ではない、ということに気づかされました。
この記事では、欠陥が生まれてから消えるまでの「ライフサイクル」を追いかけながら、
品質を作り込むための概念・手法・仕組みを整理していきます。
テストの前段階で何が起きていて、なぜそこに手を打つことが効くのか。
そしてチーム単独ではなく組織全体で品質を保証する仕組みは何のためにあるのか。
そのあたりを整理してみたいと思います。
TL;DR
- 欠陥は開発初期に生まれ、工程が進むほど雪だるま式に増幅する。
「テストで見つける」では遅すぎる場面が多い - レビューは設計段階の欠陥の最大75%を除去できる。
「時間がかかる」のではなく「時間を節約する」活動である - SQAはチーム横断で品質活動を監視・改善する仕組み。
統計的手法で「本当に効く改善」に集中する
欠陥はいつ、どこで生まれるのか ── 品質問題の起点を知る
品質を語る前に、まず「品質問題」の正体を押さえておきたいと思います。
バグは突然湧いて出るのではなく、開発の特定のフェーズで生まれ、
見逃されるたびに膨らんでいきます。
ここを掴まないと、後で出てくる「レビュー」「SQA」といった対策がなぜそういう形をしているのかが腹落ちしません。
エラーと欠陥 ── リリース前後で名前が変わる
品質問題には実は2つの呼び方があります。
-
エラー: リリース前に発見される問題。
自分たちの手で気づき、自分たちの手で修正できる -
欠陥: リリース後に発見される問題。
ユーザーに影響を与え、修正コストが跳ね上がる
この区別は単なる用語の違いではありません。
エラーの段階で見つけるのと、欠陥としてユーザーに届いてしまうのとでは、
ビジネスへの影響が桁違いに変わります。
問い合わせ対応、緊急パッチ、信頼の毀損など、
目に見えるコストと見えないコストの両方が積み上がります。
開発者として目指すべきは明確で、
できる限り多くの問題を「エラーの段階」で見つけて潰しておくことです。
業界の慣習では「バグ・エラー・欠陥」をほぼ同義に扱う場面も多いです。
ただ、いつ見つかったかで影響が大きく変わるのは事実なので、
本記事では「リリース前＝エラー / リリース後＝欠陥」と整理して進めていきます。
欠陥増幅 ── 1つのミスが雪だるま式に膨らむ仕組み
ここでもう一つ知っておきたい現象があります。「欠陥増幅（defect amplification）」です。
要件定義の段階で生まれた1つのエラーがそのまま見逃されると、
そのエラーに基づいて設計が行われます。
すると設計段階では、元の1つのエラーから複数のエラーが派生して生まれます。
さらに、増幅された設計エラーはコーディング段階でもう一段増幅されます。
最終的に、要件段階で生まれた1つのエラーが、
コーディング段階では数倍〜十数倍のエラーに膨らんでいることがあります。
数字はあくまでイメージですが、業界調査では「設計工程で全エラーの50〜65%が混入し、レビューはその設計エラーの最大75%を除去できる」という報告があります。
逆に言えば、レビューを省くと設計段階のエラーがそのまま下流に流れ込むということです。
ここで大事なのは、品質問題の起点は「コードの書き方」ではなく「要件や設計の不備」であることが多いという点です。
テスト段階で表面的なバグを潰しても、
根本にある要件や設計のエラーが残っていれば問題は解決しません。
品質をテストだけで担保しようとしても、
根本原因に手が届かない構造になっているわけです。
ちなみに、見逃したエラーが下流に影響を与え続けることを
「欠陥伝播（defect propagation）」と呼びます。
厳密には「技術的負債（technical debt）」とは別概念です
（技術的負債は設計上の意図的・偶発的な妥協の累積を指すのが本来の定義）。
ただし、見逃された欠陥が後工程の修正コストを押し上げていく構図は、
技術的負債が利息を生むのと似た実感があります。
欠陥を早く見つけるほど安い ── 品質のコストという考え方
欠陥が増幅する仕組みがわかったところで、
次に気になるのは「では実際にどれくらいのコスト差があるのか」という点です。
直感的には「早く見つけたほうが安い」と感じますが、これを体系的に整理してくれる考え方として「品質のコスト（cost of quality）」があります。
品質のコストの3分類
品質に関わるコストは、大きく3つに分類できます。
品質のコスト
├─ 予防コスト（Prevention）
│ ・品質計画、教育・トレーニング
│ ・完全な要件・設計モデルの作成
│ ・テスト計画
│ → エラーの発生自体を防ぐ投資
│
├─ 評価コスト（Appraisal）
│ ・テクニカルレビュー
│ ・テストとデバッグ
│ ・メトリクス計測
│ → 成果物の品質を確認する活動
│
└─ 失敗コスト（Failure）
├─ 内部失敗コスト（リリース前に発見）
│ ・手戻り（修正作業）
│ ・修正による副作用の対処
│ ・品質データ収集のコスト
│
└─ 外部失敗コスト（リリース後に発見）
・クレーム対応、製品回収
・サポート対応、保証対応
・「信頼の失墜」（定量化が難しい）
このうち、コストは原則として 予防 → 評価 → 内部失敗 → 外部失敗 の順に大きくなります。
つまり予防への投資が最もリターンが大きく、外部失敗（リリース後）まで持ち越したコストが最も高くつくということです。
特に外部失敗コストには「定量化しにくいが確実に存在する」損失が含まれます。
一度失った顧客の信頼は、コストとして帳簿には現れにくいですが、
次の購買行動や口コミに長く影響します。
ここを軽視して目先のスケジュールを優先する判断が、結果的に最も高くつく
── という構図は、経験がある方もいらっしゃるのではないでしょうか。
修正コストの数値感
具体的にどれくらいの差が出るのか、
業界調査で繰り返し引用されている数値感を見ておきます。
| 発見フェーズ | 1件あたりの修正コスト（相対値） |
|---|---|
| コーディング | 1（基準） |
| システムテスト | 約7倍 |
| 保守（リリース後） | 約14倍 |
仮にコーディング段階で200件のエラーが発生するアプリケーションがあったとします。
これを早期にすべて潰した場合と、テスト・保守段階に持ち越した場合では、
修正コストの総額に約12倍の差が出るという試算もあります。
自社のコストが業界平均の半分だったとしても、
早期の品質活動の投資対効果は圧倒的に大きい計算になります。
ここから導かれる結論はシンプルです。
品質活動の中心は「テストで欠陥を見つけること」ではなく、「テストに到達する前にできるだけ多くのエラーを除去すること」であるべき。
そして「テスト前にエラーを除去する」最も効果的な手段がレビューなのですが、
レビューの話に入る前に、もう一つ整理しておきたいことがあります。
それは「そもそも何をもって品質とするか」という定義の問題です。
「良い品質」とは何か ── 品質の定義がなければ品質は作れない
欠陥のコストが明確になり、早期に手を打つべきこともわかってきました。
しかし「品質の高いソフトウェアを作ろう」と言うとき、
そもそも「品質が高い」とは何を意味するのでしょうか。
定義なしに品質を追求することはできません。
品質は単一の指標では測れない
品質は見る角度によって異なる意味を持ちます。
- ユーザーが目標を達成できるか
- 仕様通りに作られているか
- 顧客が対価を払う価値があるか
- 開発チームにとって保守しやすいか
たとえば、ユーザーにとって使いやすくても保守性が低ければ、
開発チームにとっての品質は低いと言えます。
逆に保守性が高くても、ユーザーが目標を達成できなければユーザーから見た品質は低い。
実務でまず認識すべきは「品質は単一の指標では測れない」ということです。
そのうえで、ソフトウェア品質は次の3つの柱で成り立つと整理できます。
-
効果的なソフトウェアプロセスの適用
── 場当たり的な開発でなく、計画・設計・レビュー等のプロセスが整っていること -
有用な製品の提供
── 明示的な要件の充足に加え、暗黙的な期待（使いやすさなど）も満たすこと -
作る側と使う側の双方にとっての価値の創出
── 単に動くだけでなく、開発組織にも顧客にも価値が生まれること
3つの柱は記事の後半とも対応しています。
レビュー・SQAは 柱1（プロセス） を整える活動、テストは 柱2（製品） を確認する活動、柱3（価値） はステークホルダーとの対話で形作られるもの。
そのうち柱2を具体的に評価するために役立つのが、次に紹介するISO/IEC 25010です。
品質要因 ── 評価のためのフレームワーク
「有用な製品」を評価するには、具体的な評価軸が必要になります。
そのための代表的なフレームワークがISO/IEC 25010の品質モデルです。
ISO/IEC 25010品質モデルは「利用時の品質」と「製品品質」の2つのモデルで構成されています。
本記事では広く参照されてきた2011年版の特性で整理します。
2023年に改訂版が出ており、製品品質モデルでは「安全性」が独立した特性として追加されるなど構成が拡張されています。
下の表は全体像をつかむための一覧です。
すべての特性を覚える必要はなく、評価対象に応じて関連する特性を引き当てる「参照表」として使う想定です。
| モデル | 特性 | 意味（簡略） |
|---|---|---|
| 利用時の品質 | 有効性 | ユーザーが目標を正確かつ完全に達成できるか |
| 効率性 | 目標達成にどれだけのリソースを要するか | |
| 満足度 | 有用性・信頼感・使っていて快適かどうか | |
| リスクからの自由 | 経済・健康・安全・環境のリスクが低減されているか | |
| コンテキストカバレッジ | 多様な利用文脈で適切に機能するか | |
| 製品品質 | 機能適合性 | 必要な機能が完全・正確・適切に実装されているか |
| 性能効率性 | 応答時間・リソース利用・処理能力 | |
| 互換性 | 他システムとの共存・相互運用 | |
| 使用性 | 適切性・学習容易性・操作性・エラー防止・美的外観・アクセシビリティ | |
| 信頼性 | 成熟性・可用性・障害許容性・回復性 | |
| セキュリティ | 機密性・インテグリティ（完全性）・否認防止性・責任追跡性・真正性 | |
| 保守性 | モジュール性・再利用性・修正容易性・テスト容易性 | |
| 移植性 | 適応性・インストール性・置換性 |
実務での活用イメージは次のような感じです。
- 自チームのプロジェクトで「どの品質要因が重要か」を明示的に定義する
- 品質要因ごとにチェックリストを作成し、レビューや評価で使用する
- 例: 使用性を評価したいなら、「適切性・学習容易性・操作性・エラー防止・美的外観・アクセシビリティ」の観点でユーザータスクを設計する。観察と質問紙を組み合わせて評価する
すべての品質要因を定量的に評価するのは難しいですが、結合度や複雑度などのソフトウェアメトリクスを使えば、間接的に品質を測ることもできます。
「直接は測れないが、その兆候は測れる」というスタンスで臨むと現実的です。
品質のジレンマ ── 「完璧」を目指すとリリースできない
品質は高ければ高いほど良い、と単純には言えません。
品質の追求には時間とコストがかかり、しかし品質が低ければユーザーは離れていく。
この板挟みが「品質のジレンマ」と呼ばれます。
品質を追求しすぎると…
↓
[コスト爆発] [市場機会の喪失] [リリースが間に合わない]
│
│ ← どこかにバランスポイントがある
│
[信頼失墜] [手戻りの発生] [ユーザー離反]
↑
品質が不足すると…
この板挟みへの一つの答え方として「Good Enough（十分に良い）ソフトウェア」という考え方があります。
主要機能は高品質で提供し、
一部の機能には既知の不具合を残したままリリースする戦略です。
マーケットシェア確保のために大企業が採るケースもあります。
ただしこのアプローチが機能する場面は限られていて、
注意すべきポイントがいくつかあります。
-
小規模な企業の場合: バグ持ちの製品を出すと、
信頼の失墜から立ち直る前にビジネスが終わるリスクがある -
ミッションクリティカルな領域: 医療機器、航空機、自動車のソフトウェアで
「good enough」は許されない。法的責任にも直結する -
セキュリティとの関係: 品質が低いソフトウェアはハッキングされやすい。
品質問題はそのままセキュリティリスクに転化する
実践的な向き合い方としては、品質を「全か無か」で考えるのではなく、
対象領域のリスクに応じて品質目標を明示的に設定することだと自分は考えています。
「うちのプロダクトでは何の特性をどこまで担保するか」を言語化しておくと、
判断がぶれません。
最後に意外と見落としがちなのが、管理判断の影響です。
非現実的な納期、依存関係を無視したスケジューリング、リスク管理の欠如
── これらの管理判断は、技術的にどれだけ頑張っても品質を直接的に毀損します。
「時間がない」を理由にレビューを省略する判断は、短期的にはスケジュールを守るように見えても、長期的には外部失敗コストとして跳ね返ってきます。
レビューという多層フィルター ── テスト前に欠陥を潰す最も効果的な手段
品質の定義が明確になり、欠陥を早く見つけるほどコストが下がることもわかりました。
では具体的に、テスト前にエラーを除去する手段は何か。
最も効果的な手段として知られているのがレビューです。
レビューと一口に言っても、
軽いものから重いものまでフォーマリティ（形式度合い）にグラデーションがあります。
すべてのレビューを重厚にする必要はなく、
対象や状況に応じて使い分けるのがポイントです。
インフォーマルレビュー ── 日常に組み込める品質活動
最も軽いのがインフォーマルレビュー。
代表例はデスクチェックとペアプログラミングです。
デスクチェック
デスクチェックは、同僚に成果物を見てもらうシンプルな方法です。
事前準備なし、アジェンダなし、フォローアップもない。
それでもエラーを見つける効果は確かにあります。
ただし、漫然と「ちょっと見てもらえる？」だと精度がぶれるので、
効果を高めるコツが一つあります。
品質要因ごとのチェックリストを使うことです。
たとえばUI設計のレビューなら、
- レイアウトは標準的な慣習に沿っているか（左→右、上→下）
- 配色やフォントサイズは効果的に使われているか
- ナビゲーション選択肢は同じ抽象度で並んでいるか
- 全てのナビゲーションラベルは明確か
といった観点をチェックリストとして渡しておくと、
見るべきポイントが揃って指摘の質が安定します。
ペアプログラミング
ペアプログラミングは「継続的レビュー」と捉えることができます。
成果物の作成とレビューが同時に進むので、エラーの即時発見が可能です。
実務で気になるポイントを整理しておきます。
- 「2人で1タスクは無駄では？」: 手戻り削減の効果を含めると、投資対効果が成立するケースが多い
- モブプログラミング: さらに多人数で同様の効果を狙う形式。近年広がっている
フォーマルテクニカルレビュー（FTR） ── 構造化された欠陥除去
もう一段重い形式がフォーマルテクニカルレビュー（FTR） です。
これは構造化された会議として行うレビューで、
ソフトウェア品質管理活動の中で最も効果的とされる仕組みのひとつです。
FTRは総称で、実際には
ウォークスルー（walkthrough） と インスペクション（inspection） の2形式があります。
ウォークスルーは作成者が成果物を順に説明し、参加者が指摘していく軽めの形式。
インスペクションはさらに役割と手順を厳密にした重い形式で、欠陥発見の効果は高い反面、準備工数も大きくなります。
ここから説明する手順はウォークスルー寄りの、FTRの代表的な進め方です。
FTRが構造化されているのは、果たそうとする目的が5つに渡るためです。
- 機能・ロジック・実装のエラーの発見
- 要件との適合性の検証
- 事前に定義された標準への準拠確認
- 開発の均一性の確保（チーム間でのやり方のばらつきを抑える）
- プロジェクトの管理容易性の向上（誰が何をどこまで作ったかを可視化する）
エラー発見だけでなく、組織として品質をコントロールする多くの役割を1つの会議で果たそうとする ── このことが、続いて見るFTRの手順や役割分担の構造化に繋がっていきます。
FTRの典型的な進め方は次のような流れです。
[作成者] 成果物完成・レビュー依頼
│
▼
[レビューリーダー] 適切性確認 → レビュアー選定 → 資料配布
│
▼
[各レビュアー] 事前準備（1〜2時間で成果物を確認・問題点をメモ）
│
▼
[レビュー会議] （2時間以内）
├─ 紹介（アジェンダ確認）
├─ 作成者によるウォークスルー
├─ レビュアーによる指摘・記録者による記録
└─ 判定: 修正なしで受理 / 重大エラーで再レビュー
/ 軽微な修正後に受理（再レビュー不要）
│
▼
[フォローアップ] 指摘事項が適切に修正されたかを確認
参加者は3〜5人が適切とされていて、
人数が多すぎても少なすぎてもうまくいきにくいです。
そして、FTRを失敗させないためのガイドラインがいくつか伝えられています。
全体像として10項目を並べておきます。
これは暗記するというより、レビューを設計するときや振り返るときに引きで参照する「チェックリスト」として使う想定です。
- 製品をレビューするのであって、作成者を批判するのではない（指摘は穏やかに）
- アジェンダを設定し、維持する（脱線を防ぐ）
- 議論や反論は制限する（その場で結論を出そうとしない）
- 問題は指摘するが、その場で解決しようとしない（解決はあとで）
- メモを取る（できれば全員から見えるホワイトボードで）
- 参加者数を制限し、事前準備を必須とする
- チェックリストを活用する
- FTR用のリソースと時間をスケジュールに確保する
- レビュアー全員にトレーニングを提供する
- 初期のレビュー自体をレビューする（プロセス改善のフィードバックループ）
特に1番は大事だと考えています。
「コードへの指摘」が「人格への攻撃」と受け取られてしまうと、
レビュー文化そのものが崩壊します。
指摘の仕方を質問形式にする（「ここで〜が起きた場合どうなりそうですか？」など）と、
作成者自身に気づきを促せて、関係性も保てます。
レビューの投資対効果 ── 数値で見る「時間を節約する」効果
「レビューって時間がかかるから後回しにしたい」── 実務でよく聞く声です。
ですが、先に見た「修正コストはフェーズが進むほど跳ね上がる（1:7:14）」という数字を、
レビュー活動に当てはめると印象が変わります。
要件モデルのレビューでよく引用される具体的な数字です。
| 指標 | 値 |
|---|---|
| レビューで発見した要件エラー1件の修正工数 | 約6人時 |
| 同じエラーがテストで発見された場合の修正工数 | 約45人時 |
| 1件あたりの節約 | 39人時 |
| 22件のエラー発見で削減できる工数 | 858人時 |
これは要件レビューだけの数字で、
設計やコードのレビューも入れればさらに削減効果は積み上がります。
レビューのある開発とない開発を時系列で比べると、初期工数こそレビュー込みのほうが大きいものの、
テスト・修正フェーズの工数が大幅に減り、結果的にデプロイ時期はレビューありのほうが
早くなるという結果も多く報告されています。
「レビューは時間がかかる」のではなく「テスト後の手戻りという、もっと長い時間を節約してくれる」と捉え直すと、優先順位の付け方が変わってくると思います。
フォーマリティの違いを整理すると次のようになります。
| 手法 | 計画・準備 | 役割定義 | 構造化度 | 記録 | フォローアップ |
|---|---|---|---|---|---|
| デスクチェック | なし | なし | 低 | 任意 | なし |
| ペアプログラミング | なし | 緩やか | 低 | コードに反映 | 継続的 |
| ウォークスルー | あり | 緩やか | 中 | あり | あり |
| インスペクション | あり | 厳密 | 高 | 厳密 | 厳密 |
選び方の目安は 「変更の重要度」と「対象成果物の影響範囲」 です。
日々のコード変更ならデスクチェックやペアプロで十分なことが多く、
要件定義書や全社共通ライブラリのインターフェースのようにミスの代償が大きい成果物ほど、
ウォークスルーやインスペクションのように記録とフォローアップが残る重い形式が割に合います。
すべて重い手法でやると工数が回らず、すべて軽い手法だと重要な欠陥を見逃すリスクがあります。
アジャイル開発におけるレビュー
ここまで紹介してきたレビュー手法は、
計画的な工程をもつ開発を前提に発展してきた側面もあります。
アジャイル開発のように短いサイクルで進める現場では、
これらは適用できないのでしょうか。
結論から言うと、目的（早期欠陥発見）は同じで、
レビューの形式が異なるだけです。スクラムにおけるレビューの機会を整理してみます。
| スクラムイベント | レビューとしての役割 |
|---|---|
| スプリント計画 | ユーザーストーリーのレビューと優先順位付け |
| デイリースクラム | 日々の進捗確認・問題の早期発見（軽量なインフォーマルレビュー） |
| ペアプログラミング | コードの継続的レビュー |
| スプリントレビュー | FTRに似た形式でプロダクトオーナーに成果物をウォークスルー |
| レトロスペクティブ | プロセス自体を振り返って改善する機会 |
技術的負債はレビューを省略しても消えません。
短期的な速度のために長期的な品質を犠牲にしていないか、立ち止まって見直す機会を持てるかどうかが、長期的な開発速度を左右すると感じます。
組織的に品質を保証する ── SQAの仕組み
レビューは個々の成果物の品質を高める強力な手段ですが、
ここで一段視点を上げる必要があります。
「レビューが適切に行われているか」「品質活動がプロジェクト全体でうまく機能しているか」を、誰がチェックするのか、という問いです。
個人やチームの品質活動を組織レベルで支え、
改善していく仕組みがSQA（Software Quality Assurance、ソフトウェア品質保証）です。
SQAの守備範囲 ── 品質は全員の仕事
SQAが担う活動の範囲は、想像以上に幅広いです。
┌─────────────────────────────┐
│ SQAの守備範囲 │
└──────────────┬──────────────┘
│
┌───────────────────┼──────────────────┐
│ │ │
[標準・準拠] [監査・監視] [改善・予防]
・標準策定 ・レビュー監査 ・エラー/欠陥分析
・準拠確認 ・テスト計画監視 ・教育・プロセス改善
・成果物監査 ・変更管理の確保
・ベンダー管理
・セキュリティ管理
・安全性の確保
・リスク管理の監視
[開発チーム] [SQAグループ]
品質を「作り込む」 品質活動の「効果を確認・改善推進」
（品質管理 / QC） （品質保証 / QA）
SQAグループの位置づけとして覚えておきたいのが「顧客の社内代理人」という役割です。
開発チームが作ったものを、顧客の視点で評価する役割を担います。
だから内部の人間ではあるけれど、開発チームとは独立した立場で「これは顧客に出せる品質か？」を問う、というスタンスになるわけです。
開発チームとSQAグループの役割分担はおおむねこう整理できます。
- 開発チーム（QC: Quality Control）: 品質を「作り込む」。レビューやテストで欠陥を除去する
- SQAグループ（QA: Quality Assurance）: 品質活動の「効果を確認し、改善を推進する」。プロセスへの適合性を監査する
具体的なSQAタスクの例には次のようなものがあります。
- SQA計画の策定
- ソフトウェアプロセスへの参加と適合性レビュー
- 成果物の監査、逸脱の文書化と追跡
- 不適合の上級管理職への報告
「品質を確認するだけでなく、確認した結果を経営層にエスカレーションするルートを持っている」のがSQAの特徴です。
統計的SQA ── データに基づく改善
SQAが面白いのは、感覚や根性ではなく、
データで改善の方向を決める仕組みになっているところだと思います。
これを統計的SQAと呼びます。
基本ステップは次の4つです。
- エラーと欠陥の情報を収集・分類する
- 各エラー/欠陥をその根本原因に追跡する
-
パレート原則（80:20の法則） を適用し、
問題の大部分を引き起こしている少数の原因（vital few）を特定する - vital few に集中して是正措置を行う
エラーの根本原因の典型例には、
- 不完全な仕様
- 顧客コミュニケーションの誤解
- 仕様からの意図的逸脱
- プログラミング標準違反
- データ表現エラー
- 設計ロジックエラー
- 不十分なテスト
などがあります。
重要なのは、全てのエラー原因に均等に対処するのではなく、
パレート原則で「本当に効く少数の原因」に集中することです。
vital few を改善すると新たな候補がトップに上がってくるので、
継続的に改善サイクルを回していきます。
ここで効くフレームワークが Six Sigma です。
業界で最も広く使われている統計的品質管理戦略で、
欠陥を「100万機会あたり3.4件以下」に抑えることを目標として設計されています。
Six Sigma には、
既存プロセスを改善する DMAIC（Define→Measure→Analyze→Improve→Control）と、
新規プロセスを設計する DMADV（Define→Measure→Analyze→Design→Verify）
の2サイクルがあります。
SQAが具体的に追う目標・属性・メトリクスを整理しておくと、
SQAが「お題目」ではなく「動かせる仕組み」だということが見えてきます。
| 目標 | 属性の例 | メトリクスの例 |
|---|---|---|
| 要件品質 | 曖昧さ、完全性、追跡可能性 | 曖昧な修飾語の数、未定項目の数、設計/コードに追跡できない要件の数 |
| 設計品質 | アーキテクチャ整合性、コンポーネント完全性 | アーキテクチャモデルの有無、アーキテクチャモデルへの追跡可能なコンポーネント数 |
| コード品質 | 複雑度、保守性、可読性 | 循環的複雑度、内部コメント割合、命名規則準拠率 |
| QC効果 | リソース配分、レビュー有効性、テスト有効性 | アクティビティ別工数比率、見つかったエラー数と重大度、エラー発生源 |
「品質を上げる」と言っても抽象的で動きにくいですが、
具体化すると改善活動として駆動しやすくなります。
たとえば「このメトリクスを追って、まず要件の曖昧さを減らす」のように、
目標→メトリクス→アクションの順で落とし込んでいくのが現実的です。
SQAの仕組みを外部に示す ── ISO 9001:2015
SQAの仕組みを「自社の中で回している」だけでなく、
第三者に客観的に示す手段として ISO 9001:2015 という国際標準があります。
品質マネジメントシステムの国際標準で、ソフトウェア組織にも適用されます。
ISO 9001:2015の要求事項に並んでいる主な項目は次のとおりです。
- 経営責任、契約レビュー、設計管理
- 文書管理、製品識別と追跡可能性
- プロセス管理、検査とテスト
- 是正・予防処置、品質記録の管理
- 内部監査、教育、サービス、統計的手法
ご覧のとおり、SQAの活動領域とほぼ重なる項目が並んでいます。
第三者監査による認証で、組織の品質活動の信頼性を外部に示すことができます。
顧客や取引先に対して「自社が体系的な品質管理をしている」と客観的に証明する手段として機能します。
ただし、認証取得そのものが目的化すると形骸化しがちです。
SQAの実務（標準・レビュー・監査・改善）が回っていることが前提で、
ISO 9001:2015はその「外向きの証明書」として位置づけるのが健全だと感じます。
品質活動の成果を測る ── 信頼性・可用性・安全性
ここまで、レビューやSQAで品質を「作り込む」「保証する」仕組みを見てきました。
ではこれらの活動が成功すると、最終的に何が生まれるのか。
その答えとなるのが、本番運用で見える品質指標 ── 信頼性・可用性・安全性です。
SQAが追う「プロセス側のメトリクス」が結果として現れる先、
と捉えると繋がりが見えやすくなります。
信頼性と可用性 ── 「どれくらい壊れないか」「どれくらい使えるか」
ソフトウェア信頼性は
「指定された環境で指定された時間にわたって、故障なく動作する確率」と定義されます。
たとえば「あるプログラムが8時間の処理時間で信頼性0.999」と言ったら、
1000回実行したうちの999回は故障せず動作する、ということです。
主要な指標を整理します。
[MTBF]
平均故障間隔
│
┌───────────────┴────────────────┐
│ │
[MTTF] + [MTTR]
平均故障時間 平均修復時間
[可用性]
Availability = MTTF / (MTTF + MTTR) × 100%
改善の方向は2つ:
┌──────────────────┬───────────────────┐
│ MTTF を伸ばす │ MTTR を縮める │
│ ＝ 壊れにくくする │ ＝ 壊れても速く直す │
│ （欠陥を減らす） │ （復旧の自動化など） │
└──────────────────┴───────────────────┘
ここで重要なのは、改善の方向が2つあって、どちらも品質の一部 だという点です。
レビューやSQAが効くのは MTTF を伸ばす側（壊れにくくする）。
一方、MTTR を縮める側（壊れても速く直す）は、運用設計の領域
── 自動復旧、ロールバックの容易さ、観測性の向上などが絡みます。
両方を意識して初めて「使えるソフトウェア」が成立します。
なぜMTBFが有用なのかというと、ユーザーが気にするのは「全部で何個バグがあるか」ではなく「使っている最中に壊れるかどうか」だからです。
全欠陥数を減らしても、よく使う機能に残る欠陥があれば信頼性は低い、
ということがあり得ます。
逆に、滅多に使われないコードパスのバグは、
たとえ件数が多くても利用上の信頼性にはあまり影響しません。
安全性 ── ソフトウェアの欠陥が人命に関わるとき
最後に、信頼性と並べて理解しておきたいのが 安全性（software safety） です。
ソフトウェア安全性は、「潜在的なハザード（危険源）を特定し、
それがシステム全体の障害につながることを防ぐ」活動です。
信頼性と似ていますが、視点が少し違います。
| 観点 | 信頼性 | 安全性 |
|---|---|---|
| 評価対象 | 故障の発生確率 | 故障が危険な状態につながるかどうか |
| 例 | 1000回のうち何回正常動作するか | 1回の故障で人命が失われる可能性があるか |
| アプローチ | 統計的分析 | ハザード分析・FTA・Petriネット等 |
信頼性が高くても安全でない場合があります。
たとえば滅多に発生しない故障でも、
それが人命に直結するなら安全性は低いと評価されます。
逆に、頻繁に発生する故障でも、結果が軽微なら安全性は相対的に高い、
ということもあり得ます。
安全性確保の典型的な流れは
「ハザードの特定 → 分類（重大度×確率） → 要件段階での応答定義 → 設計への組み込み」
となります。
医療機器、自動車、航空機などのドメインでは、
品質保証の中でも特に安全性が重視されます。
信頼性とは別軸の品質活動として認識しておく必要があります。
おわりに ── 品質はプロセスのすべての段階で「仕込む」もの
欠陥が生まれてから消えるまでのライフサイクルを追いかけてきました。
ここから見えてきたのは、品質活動は開発プロセスのどこか1箇所に集中させるものではなく、すべての段階に仕込むものだということです。
テストフェーズだけ気合いを入れても、要件・設計フェーズで生まれた欠陥は減らせない。
レビューだけ強化しても、組織として品質活動を改善し続ける仕組みがなければ持続しない。
整理すると、品質を作り込むためには次の4つの柱がそろって機能する必要があります。
- ソフトウェアエンジニアリング手法: 要件分析から設計まで、確かな方法論で品質の土台を作る
- プロジェクト管理: 現実的な見積もり、リスク管理、依存関係の理解が品質を守る
- 品質管理（QC）: レビューとテストというフィルターで欠陥を除去する
- 品質保証（QA）: 品質活動自体の効果を監視し、組織的に改善し続ける
これら4つが機能して初めて、ユーザーから見える品質
── 信頼性・可用性・安全性 ── が確保されます。
プロセスを整える最終的な目的はここにあります。
テストは「最後の砦」であり、
品質を確認する最終チェックポイントとして大事な役割を持っています。
ただし品質の大部分は、テストに到達する前の活動で決まっている、
というのがこの記事を通じて伝えたかったメッセージです。
そして、品質のジレンマは消えません。
完璧は追求できないし、追求すべきでない場面もあります。でも、
- 品質目標を明示的に設定する（何の特性をどこまで担保するか）
- 早期発見に投資する（レビュー、ペアプロ、自動チェック）
- データに基づいて改善を続ける（メトリクス、パレート原則、Six Sigma）
この3点を意識して向き合えば、
ジレンマの中でも自分たちなりのバランスを取れるようになると思います。
これがソフトウェアエンジニアとしての品質への向き合い方ではないでしょうか。
明日からの開発で、レビューが「やらされるもの」から「時間を節約してくれる活動」に見えてきたら、この記事の目的は達成されたことになります。