システム開発で「品質を高める」と言われても、何を基準に確認し、発注側と開発側のどちらが何を担当するのか分かりにくいことがあります。品質管理は、リリース前にバグを探す作業だけではありません。目的に合う品質目標を決め、要件・設計・実装・テスト・運用を通じて確認し、改善する取り組みです。
この記事では、品質管理・品質保証・品質コントロールの関係、工程ごとの活動、指標の読み方、品質計画と体制づくりを、ITの専門家ではない発注担当者にも分かるように解説します。
この記事でわかること
・ 品質管理・品質保証（QA）・品質コントロール（QC）の関係
・ 要件定義から運用までに確認したい品質活動
・ バグ密度などの指標を単独で判断しないための見方
・ 発注側・開発側・QA担当の役割と品質計画の作り方
システム開発における品質管理の基本
システム開発における品質管理は、必要な品質を計画し、その要求を満たせるように開発プロセスと成果物を確認し、結果を改善へつなげる活動です。対象はプログラムだけでなく、要件定義書、設計書、テスト結果、運用手順などにも及びます。
品質が良いかどうかは、欠陥数だけでは判断できません。利用目的、重要な業務、想定利用者、性能、セキュリティ、保守性などを踏まえて、案件ごとに品質目標と受け入れ条件を決める必要があります。
品質管理・品質コントロール（QC）とは？
品質コントロール（QC：Quality Control）は、定めた品質要求を満たすために成果物や作業結果を確認し、問題があれば是正する活動です。ソフトウェア開発では、レビュー、静的解析、テスト、不具合の分析などが該当します。
QCを完成後の検査だけに限定すると、要件や設計の問題を見逃しやすくなります。各工程で確認対象と合格条件を決め、問題を次の工程へ持ち越さない運用が重要です。
品質保証（QA）との違いと関係
品質保証（QA：Quality Assurance）は、品質要求を満たせるという信頼を与えることに焦点を置く活動です。品質計画、標準や手順の整備、プロセスの確認、監査、改善支援などを含みます。QCは品質要求を満たすことに焦点を置き、成果物のレビューやテストなどを実施します。
QAは予防、QCは検査という説明は理解しやすい一方、実務では活動が重なることがあります。どちらも品質マネジメントの一部として、品質目標の設定、確認、改善と結びつけて考えます。
ISO/IEC 25010:2023が示すソフトウェア品質の考え方
ソフトウェアの品質は、バグが少ないことだけを意味しません。ISO/IEC 25010:2023の製品品質モデルは、ICT製品・ソフトウェアの品質を9つの特性で捉え、要求の定義、評価、受け入れ条件や測定項目の検討に利用できる枠組みを示しています。
2023年版では、機能適合性、性能効率性、互換性、インタラクション能力、信頼性、セキュリティ、保守性、柔軟性、安全性という観点が扱われます。旧版のISO/IEC 25010:2011は8特性でした。案件では9特性をすべて同じ重さで扱うのではなく、業務上のリスクと利用目的に応じて重視する観点、目標、測定・確認方法を決めます。正確な定義は規格本文を参照してください。
工程別に見るシステム開発の品質管理
品質はテスト工程だけで作られるものではありません。要件の明確化、設計レビュー、実装時の確認、テスト、運用後の監視をつなげて管理します。ここでは工程ごとの代表的な活動を整理します。開発工程の全体像は「システム開発フロー」で詳しく紹介しています。
【要件定義・設計】品質目標と受け入れ条件を具体化する
要件定義では、業務目的、利用者、対象範囲、機能、性能、セキュリティ、運用条件を整理します。「使いやすい」「速い」などの曖昧な表現は、利用場面、測定条件、目標値、確認方法へ落とし込みます。
設計では、要件との対応、例外時の動作、権限、データ、外部連携、運用方法をレビューします。後の工程で問題が見つかると影響範囲が広がる場合があるため、業務担当者・開発者・運用担当者が早い段階で確認することが重要です。
【実装】コーディング規約・レビュー・静的解析を組み合わせる
実装工程では、読みやすさや安全性をそろえるためにコーディング規約を定め、コードレビューを行います。静的解析ツールは、プログラムを実行せずに規約違反や潜在的な問題を検出する補助になります。
ただし、ツールで検出できる問題には限界があり、警告件数が少ないだけで品質が高いとは判断できません。重要な業務ロジックやセキュリティ上の判断は、人によるレビューやテストと組み合わせます。
【テスト】リスクと要件に合わせて段階的に確認する
テストでは、単体、結合、システム、受け入れなどの段階で、対象に応じた動作を確認します。正常な操作だけでなく、境界値、エラー、権限、性能、セキュリティ、復旧なども、業務上のリスクに応じて計画します。
テストの件数や合格率だけでなく、重要要件を確認できているか、未解決の不具合にどのような業務影響があるかを確認します。各テストの違いは「システム開発のテスト工程」を参照してください。
【リリース・運用】残存リスクと利用状況を継続的に確認する
リリース前には、未解決の不具合、データ移行、監視、バックアップ、障害対応、切り戻し、利用者への案内を確認します。「不具合がゼロ」であることだけを条件にせず、重要度と業務影響、回避策、対応期限を記録したうえで判断します。
運用開始後は、障害、問い合わせ、応答時間、利用状況、セキュリティ事象などを確認し、傾向を改善へつなげます。監視する項目と連絡・判断の責任者を事前に決めておきます。
開発モデルに合わせた品質管理の進め方
品質目標と確認責任は、開発モデルにかかわらず必要です。ただし、成果物を確認する時期や、変更を取り込む方法はウォーターフォール開発とアジャイル開発で異なります。モデル名だけで品質の良し悪しを判断せず、案件の不確実性、規模、法令・安全上の制約に合わせて活動を設計します。
ウォーターフォール開発では工程の完了条件を明確にする
ウォーターフォール開発では、工程ごとに成果物、レビュー担当、完了条件、未解決事項の扱いを定めます。次の工程へ進む前に確認する「ゲート」を設ける方法もありますが、すべての案件で同じ形式が必須というわけではありません。
文書の承認だけで終わらせず、要件と設計・テストの対応、重大なリスク、変更の影響を確認することが重要です。
アジャイル開発では短いサイクルで品質を確認する
アジャイル開発では、短い開発サイクルごとに、完成の条件（Definition of Done：作業を完了とみなす共通基準）を満たしているか確認します。レビュー、テスト、利用者からのフィードバックを継続的に取り込みます。
継続的インテグレーション（CI：変更したコードを頻繁に統合して確認する仕組み）やテスト自動化は有効な手段ですが、導入自体が目的ではありません。変更頻度、保守負担、誤検知、重要機能のリスクを踏まえて対象を選びます。
品質を可視化する指標（メトリクス）の読み方
品質指標（メトリクス）は、状況を把握し、追加確認や改善の必要性を話し合うための材料です。多くの指標は品質そのものを直接表すのではなく、別の現象を通じて推測する代替指標です。一つの値だけで合否や担当者の評価を決めず、同じ定義での推移、欠陥の重要度、工程、変更量、利用実績などと組み合わせます。
バグ密度は規模・重要度・検出工程と合わせて見る
バグ密度は、一定のソフトウェア規模に対する欠陥数を表します。規模にはコード行数、機能数など複数の数え方があるため、比較する場合は定義をそろえる必要があります。
値が高い場合は問題が多い可能性だけでなく、テストやレビューが有効に機能して多く発見できた可能性もあります。値が低くても、検出活動が不十分な場合があります。重大度、発見工程、修正状況、本番流出欠陥と合わせて判断します。
テスト密度・実施率はテスト内容と合わせて確認する
テスト密度は規模に対するテストケース数、実施率は計画したテストのうち実行した割合を表す指標です。件数が多いほど十分とは限らず、同じ動作を重複して確認している場合や、重要なリスクが抜けている場合があります。
要件やリスクとの対応、失敗したテスト、未実施の理由、テスト環境の制約を確認し、数だけで網羅性を判断しないことが大切です。
レビュー指摘件数は種類・重要度・是正状況を確認する
レビュー指摘件数や指摘密度は、要件定義書、設計書、コードなどの確認状況を知る材料になります。ただし、指摘が多いことは成果物に問題が多い場合も、レビューが丁寧に行われた場合もあります。
誤字などの軽微な指摘と、要件漏れ・セキュリティなどの重大な指摘を分け、原因、再発防止、修正確認まで追跡します。過去の類似案件と比較する場合も、成果物とレビュー方法の違いを考慮してください。
品質管理を機能させる体制と3つのポイント
品質はQA担当者だけが担うものではありません。発注側は業務目的と受け入れ条件を決め、開発側は設計・実装・テストの品質を作り込み、運用側は稼働後の状態を確認します。小規模案件では専任QAを置かない場合もあるため、組織名ではなく、必要な役割と責任が割り当てられているかを確認します。
ポイント1：品質目標・測定条件・合格基準を合意する
「バグを減らす」「3秒以内」といった数値だけを置くのではなく、対象業務、利用者、測定環境、データ量、重要度、確認方法を明記します。例えば応答時間なら、対象画面、同時利用人数、データ件数、ネットワーク条件、測定する位置をそろえます。
バグ密度の0.5件/KLOCなどを全案件共通の基準にすることはできません。自社の過去実績、類似システム、業務リスクを基に基準を決め、途中で妥当性を見直します。
ポイント2：発注側・開発側・QAの役割を明確にする
発注側は業務要件、優先順位、受け入れ条件、リリース判断を担います。開発者は設計・実装の品質を作り込み、レビューとテストへ参加します。QA担当は、品質計画、プロセスの確認、テストや指標の支援、独立した評価などを担当できます。
専任のQA部門が必要かは、規模、リスク、法令、安全性、組織体制によって異なります。役割が重複・欠落しないよう、成果物ごとに作成者、レビュー者、承認者を決めます。
ポイント3：不具合・テスト・変更を追跡できるようにする
BTS（Bug Tracking System：不具合管理システム）や課題管理ツールを使うと、不具合の内容、重要度、担当者、状態、修正結果を一元管理できます。テスト管理ツールでは、要件とテストケース、実行結果を関連付けられます。
ツールの導入だけでは品質は改善しません。小規模案件では既存の課題管理ツールで足りる場合もあります。入力項目、状態の定義、優先順位、完了条件を決め、関係者が同じルールで利用することが重要です。
品質管理を学ぶ際に参考になる主な資格
資格の学習は、テストや品質管理の用語と考え方を体系的に理解する方法の一つです。ただし、資格保有だけで実務能力やプロジェクトの品質を判断することはできません。担当業務、経験、組織のプロセスと合わせて活用し、試験区分や受験条件は必ず各運営団体の最新情報を確認してください。
JSTQB認定テスト技術者資格
JSTQBは、ISTQBの国際的な体系に基づくソフトウェアテスト技術者資格を日本で運営しています。Foundation Levelではテストの基礎的な用語や考え方を学び、Advanced Levelなどではテストマネジメントや分析に関する分野があります。
試験区分、適用されるシラバス、受験条件は改定されることがあります。受験前にJSTQB公式サイトで最新情報を確認してください。
ソフトウェア品質技術者資格認定（JCSQE）
ソフトウェア品質技術者資格認定（JCSQE）は、日本科学技術連盟が案内する資格制度です。ソフトウェア品質の考え方、品質マネジメント、レビュー、テストなどを体系的に学ぶ際の選択肢になります。
資格区分、試験範囲、実施予定は公式サイトで確認してください。
品質管理検定（QC検定）
品質管理検定（QC検定）は、品質管理の知識を評価する検定で、統計的な考え方や改善活動などを学べます。ソフトウェア専用の資格ではないため、ソフトウェアテストや開発プロセスを直接学びたい場合は、JSTQBやJCSQEなどと目的を比較してください。
システム開発の品質管理に関するよくある質問
ここでは、品質目標、費用・納期との調整、アジャイル開発での進め方について、発注担当者が確認したい点を整理します。
システム開発における「良い品質」とは、具体的にどのように定義すればよいですか？
良い品質とは、合意した要求を満たし、想定する利用状況で業務目的を達成できる状態です。欠陥数だけでなく、機能、性能、操作性、信頼性、セキュリティ、保守性などから、案件で重要な品質特性を選びます。
各特性について、対象、目標、測定またはレビュー方法、受け入れ条件、責任者を明確にし、要件変更時には品質目標も見直します。
品質を高めようとするとコストやスケジュールが圧迫されますが、どのようにバランスを取ればよいですか？
すべての機能に同じ確認量を割り当てるのではなく、障害が起きる可能性と影響を考え、重要な業務、個人情報、決済、外部連携などを優先します。上流工程のレビューは問題を早く見つける助けになりますが、必ずコストが下がると断定はできません。
品質目標、対象範囲、残存リスク、追加確認に必要な費用と日程を関係者に示し、リリース判断者が選択できる状態にします。
アジャイル開発のようにスピードが求められるプロジェクトでは、どのように品質管理を行えばよいですか？
短いサイクルごとに、完成の条件、レビュー、テスト、利用者確認を組み込みます。CIやテスト自動化は、繰り返し確認する範囲に有効ですが、保守コストや自動化しにくい確認もあります。
自動化率だけを目標にせず、変更頻度が高く、失敗時の影響が大きい領域から適用します。探索的テストや利用者による確認など、人の判断が必要な活動も組み合わせます。
まとめ｜品質目標・指標・役割を一つの計画で管理する
システム開発の品質管理は、テストやバグ修正だけではなく、品質目標を定め、各工程で確認し、運用後の結果から改善する活動です。ISO/IEC 25010:2023などの枠組みを参考にしながら、案件で重要な品質特性を選びます。
バグ密度、テスト密度、レビュー指摘件数は、単独で品質の良し悪しを示すものではありません。定義をそろえ、重要度や工程、過去の推移と合わせて読み取ります。発注側、開発側、QA、運用側の責任を決め、品質目標、確認方法、残存リスク、リリース判断を一つの品質計画として管理しましょう。
