フレームワーク活用ガイドひとことで言うと#
プロジェクトの成果物やプロセスが要求される品質水準を確実に満たすために、品質基準・測定方法・管理活動・改善手順を事前に計画する手法。「品質は計画するもの」という考え方に基づき、検査で不良を発見するのではなく、プロセスで品質を作り込む。
押さえておきたい用語#
- QA（Quality Assurance）
- プロセスが正しく運用されているかを確認する品質保証活動のこと。不良を「防ぐ」ための予防的アプローチ。
- QC（Quality Control）
- 成果物が基準を満たしているかを検証する品質管理活動のこと。不良を「見つける」ための検査的アプローチ。
- COQ（Cost of Quality）
- 品質コスト。予防コスト・評価コスト・内部失敗コスト・外部失敗コストの4つを合計した品質にかかる総コストである。
- パレート図
- 不具合の原因を発生頻度順に並べた棒グラフと累積折れ線グラフを組み合わせた図。上位20%の原因が80%の問題を生むという法則を可視化するツール。
- COPQ（Cost of Poor Quality）
- 低品質コスト。不具合の修正・手戻り・クレーム対応など、品質不良が原因で発生するコストを指す。
品質管理計画の全体像#
こんな悩みに効く#
- 成果物の品質にばらつきがあり、顧客満足度が安定しない
- テスト工程で大量の不具合が見つかり、手戻りコストが膨大
- 「品質」の定義が人によって異なり、合格基準が曖昧
基本の使い方#
成果物の品質を測定するための具体的な基準と指標を設定する。
- 機能要件: 要件定義書の全項目を満たしているか
- 非機能要件: パフォーマンス、セキュリティ、ユーザビリティの数値目標
- プロセス品質: コードレビュー実施率、テストカバレッジ率
ポイント: 品質基準は「測定可能」であること。「使いやすい」ではなく「ユーザビリティテストの完了率90%以上」のように数値化する。
品質をプロセスに組み込む予防的な活動を計画する。
- 設計レビュー・コードレビューの実施タイミングと参加者を決める
- コーディング規約やドキュメント標準を整備する
- テスト戦略（単体・結合・システム・受入テスト）を策定する
ポイント: 品質保証は「検査」ではなく「予防」。工程の早い段階で品質を作り込むほど、後工程のコストが下がる。
成果物が品質基準を満たしているかを検証する仕組みを構築する。
- チェックリストの作成と運用方法を決める
- 不具合管理のフロー（検出→分類→修正→再検証→クローズ）を定義する
- 品質メトリクスの収集と報告の頻度を決める
ポイント: 不具合は「件数」だけでなく「重要度」「検出工程」「原因分類」も記録する。これが改善活動のインプットになる。
品質データを分析し、プロセスを継続的に改善する。
- 不具合の根本原因分析（なぜなぜ分析）を定期的に実施する
- パレート図で頻出する不具合パターンを特定する
- 改善策をプロセスに反映し、効果を測定する
ポイント: 品質管理は一度決めて終わりではない。PDCAサイクルを回し、プロジェクト期間中も品質プロセスを進化させる。
具体例#
品質基準定義: クラッシュ率0.1%以下、アプリ起動時間2秒以内、テストカバレッジ80%以上、ユーザビリティテスト合格率90%以上。
QA活動計画: 毎スプリントのコードレビュー必須化（レビュアー2名以上）。UIデザインレビューを各スプリント開始時に実施。自動テストをCI/CDパイプラインに組み込み。
QC仕組み構築: 不具合管理にJiraを使用。重要度4段階（Critical/Major/Minor/Trivial）。毎週の品質レポートでバグ検出数・修正数・残存数を報告。
継続的改善: Sprint 3終了時にCriticalバグの80%が結合テストで発見されていた問題を分析。原因はAPI仕様の認識齟齬。対策として「API仕様レビュー」を設計工程に追加。Sprint 5以降、Criticalバグが50%減少し、手戻り工数が月40時間から20時間に半減した。
背景: 従業員500名の食品メーカー。基幹システム刷新プロジェクトで、旧システムからのデータ移行品質が最大のリスク。
品質基準: データ移行精度99.99%以上（10万件中エラー10件以下）。業務テスト合格率100%。移行後の性能劣化5%以内。
QA活動: データ移行手順書を3回レビュー。本番同等環境でのリハーサルを4回実施。各部門の業務担当者による受入テストシナリオを120件作成。
QC仕組み: 移行リハーサルごとにデータ突合チェック。差異件数・差異内容・原因分類をスプレッドシートで管理。週次品質会議で進捗を報告。
結果: リハーサル1回目はエラー率0.3%（300件）。原因分析で文字コード変換ルールの不備を特定。ルール修正後、リハーサル4回目でエラー率0.005%（5件）を達成。本番移行はゼロ障害で完了し、移行後の業務停止時間もゼロだった。
背景: 人口15万人の自治体が住民向けオンライン申請システムを構築。年間申請件数8万件を処理する重要システム。
品質基準: 24時間稼働率99.9%以上。ページ表示速度3秒以内。WCAG 2.1 AA準拠（アクセシビリティ）。セキュリティ診断で重大脆弱性ゼロ。
QA活動: セキュリティ専門ベンダーによるコードレビュー（月1回）。アクセシビリティチェッカーをCI/CDに組み込み。高齢者モニター10名による操作テストを3回実施。
QC仕組み: 外部セキュリティ診断を2回実施（中間・最終）。負荷テストで同時1,000アクセスを検証。全18種類の申請フローについて画面遷移テストを完了。
結果: セキュリティ診断で中間段階の指摘12件を全件修正。高齢者テストで「戻るボタンが小さい」など操作性の問題を8件発見し改善。リリース後6ヶ月間の障害件数ゼロ、住民満足度調査で「使いやすい」回答率が78%を達成した。
やりがちな失敗パターン#
- 品質管理を「テスト工程」に丸投げする — テストは品質を確認する活動であり、品質を作り込む活動ではない。設計・実装の段階からQA活動を組み込む
- 品質基準が曖昧なまま進める — 「高品質」の定義が人によって異なると合格判定が揉める。プロジェクト初期に測定可能な基準を合意する
- 品質データを収集するだけで分析しない — データは改善に使わなければ意味がない。定期的に分析し、プロセス改善のアクションにつなげる
- COPQを計算しない — 品質活動のコストばかり気にして、低品質がもたらすコスト（手戻り・クレーム対応・顧客離脱）を無視する。**品質への投資は「コスト」ではなく「節約」**であることを数字で示す
まとめ#
品質管理計画は、品質基準の定義・QA活動・QCの仕組み・継続的改善の4要素で構成される。「品質は検査で確保するのではなく、プロセスで作り込む」が基本原則。プロジェクト初期に測定可能な品質基準を設定し、工程全体に品質活動を組み込むことで、手戻りコストの削減と顧客満足度の向上を両立できる。