公開2026.07.18更新2026.09.29 10 人が閲覧（直近 30 日）テスト

システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定の手順

システム開発の品質管理とは、要件定義・設計・実装・テストの各工程に品質基準と検証手順を組み込み、欠陥を早い段階で摘出して手戻りを抑える管理業務を指します。テスト工程だけで品質を確保しようとすると、上流で作り込まれた欠陥の修正費用が膨らみ、納期とコストの両方を圧迫する結果になりがちです。本記事では受託開発の実務を前提に、工程別のレビュー・テスト管理の進め方、テスト密度・バグ密度によるメトリクス運用、品質報告書をQCD判断につなげる読み方までを整理します。メトリクスの判定をPythonで自動化してCIに組み込むコード例と、参考値の出典であるIPAの統計が2022年版で発行終了した後の扱いも追加しました。あわせて、小規模案件で品質管理をどこまで省略してよいかという判断も条件付きで示します。

まとめ：品質は工程ごとの出口基準と定量指標で作り込む

システム開発の品質は、テストで「確かめる」ものではなく、各工程の出口基準で「作り込む」ものです。骨格になるのは、要件定義と設計でレビュー指摘密度を記録し、実装で静的解析とコードレビューの品質ゲートを通し、テスト工程でテスト密度・バグ密度を参考値と突き合わせる、という工程別の定量管理です。密度の判定と収束の確認は人手で表計算するより、スクリプト化してCIで毎回実行するほうが判断の遅れを防げます。

一方で、全案件に同じ厚みの品質管理を敷くと、管理コストが便益を上回ります。利用者が少なく障害時に手作業で代替できる案件なら、メトリクス収集を簡略化し、コードレビューとテスト終了条件だけを残すのが現実的です。逆に決済や基幹業務のように障害影響が大きいシステムでは、信頼度成長曲線による終了判定と品質報告書の運用まで省略しない。この省略判断の軸は規模ではなく「障害時の失敗コスト」です。本文で工程別の実務と判断基準を順に解説します。

システム開発における品質管理の定義とQCD・品質保証との役割分担

最初に用語と守備範囲を確定させます。ここが曖昧なまま体制を組むと、品質保証部門と開発チームの間で検証作業が重複し、管理コストだけが増えます。

プロセス品質とプロダクト品質の違い・受託開発で管理する対象範囲

品質管理の対象は2層に分かれます。成果物そのものの品質（プロダクト品質）と、それを生み出す開発手順の品質（プロセス品質）です。前者はバグ密度や性能の実測値で、後者はレビュー実施率や工程完了基準の順守状況で測ります。

受託開発では、発注者が直接確認できるのは納品物のプロダクト品質だけです。だからこそ発注者は、ベンダーのプロセス品質（レビュー記録・テスト計画・メトリクス報告）を契約段階で確認する必要があります。製造業も含めた品質管理の全体像やQC7つ道具との関係は品質管理の基礎と品質保証との違いを整理した記事で解説しており、本記事はその考え方をシステム開発の工程に落とし込む位置付けです。

品質管理と品質保証（QA）の分担・ISO/IEC 25010による品質特性の定義

品質管理（QC）は開発チームが工程内で欠陥を摘出する活動、品質保証（QA）は独立した立場で基準の整備と監査を担う活動、と分担するのが一般的です。両者を1つのチームが兼ねる小規模組織でも、「作る人と検証基準を決める人を分ける」原則だけは崩さないでください。自分で書いた仕様を自分だけで検証する体制は、思い込み起因の欠陥を素通しします。

「何をもって品質とするか」の定義には、国際規格ISO/IEC 25010の品質特性モデルを使います。2023年11月の改訂版（25010:2023時点）では品質特性が9つに整理され、セーフティが追加されました。特性ごとの内訳はISO/IEC 25010の品質特性を解説した記事を参照してください。全特性を均等に追うのではなく、案件ごとに優先する特性を2〜3個選び、測定方法まで決めるのが実務的な使い方です。

品質コスト（予防・評価・失敗）の内訳と手戻り増幅の経験則1:10:100

品質管理に投じる費用は、予防コスト（レビュー・静的解析・教育）、評価コスト（テスト・検査）、失敗コスト（バグ修正・障害対応・信用毀損）に分類できます。品質管理の目的は、予防と評価に先行投資して、金額の桁が大きい失敗コストを圧縮することです。

投資判断の裏付けになるのが手戻り増幅の経験則です。要件定義段階の欠陥修正費用を1とすると、テスト工程での発見はおよそ10、リリース後の発見はおよそ100に膨らむ、という比率がソフトウェア工学の実測研究で繰り返し報告されてきました。倍率は組織や案件で変動しますが、「下流に行くほど桁が上がる」傾向は一致しています。上流レビューに工数を割く判断は、この比率で発注者にも説明できます。

上流工程の品質管理：要件定義・設計レビューで欠陥を作り込ませない方法

本番障害の原因分析をすると、コードの書き誤りよりも要件と設計の欠陥に遡るものが目立ちます。上流の品質管理は「書いた後に見つける」のではなく「書く前に基準を渡す」ことから始まります。

要件定義の品質管理：曖昧要件を検出するレビュー観点と合意基準

要件定義書のレビューでは、曖昧語の検出を機械的に行います。「原則として」「適切に」「高速に」「など」といった語は、テスト可能な条件（応答3秒以内、対象データは受注・出荷の2種類、例外は別紙に列挙）へ書き換えるまで指摘対象にします。曖昧なまま残った1行が、受入テストでの「想定と違う」に直結するためです。章立てと記載項目ごとのレビュー観点は要件定義書の書き方とレビュー観点を作業手順で整理した記事にまとめています。

合意基準の文書化も同じ工程で済ませます。要件ごとに「何で検証するか（テスト・レビュー・実測のいずれか）」を要件定義書に併記し、発注者の承認記録を残す、というやり方です。ここを省くと、仕様起因の手戻りが発生したときに責任の切り分けができず、追加費用の交渉が難航します。

設計レビューの実務：指摘密度・レビュー速度の目安と形骸化の失敗パターン

設計レビューは実施の有無ではなく、密度で管理します。使う指標はレビュー指摘密度（指摘件数÷対象規模）とレビュー速度（1時間あたりの消化ページ数）の2つです。速度が速すぎる記録は「読んでいない」ことを、指摘がゼロに近い記録は形骸化を疑うサインとして扱います。

典型的な失敗パターンは、関係者全員を集めた長時間の一斉レビューです。人数×時間で費用は大きいのに、出てくる指摘は誤字脱字に偏りがちです。対策として、整合性・例外処理・性能・運用の観点表を事前に配って各自で読み込み、会議は指摘の裁定だけに絞る方式へ変えると、同じ工数でも設計欠陥の指摘比率が上がります。

W字モデルによるテスト設計の前倒し・上流工程での欠陥摘出の効果

V字モデルが「設計成果物に対応するテストを後の工程で実施する」対応関係を示すのに対し、W字モデルは要件定義・設計と並行してテスト設計そのものを前倒しする進め方です。テストケースを書く過程で「この要件は検証手段がない」「この分岐の仕様が未定義」という欠陥が、実装前に表面化します。単体・結合・総合・受入の各テストがどの設計工程に対応するかはシステム開発のテスト工程とV字モデルを解説した記事で図解しています。

導入のコツは範囲を絞ることです。全機能でテスト設計を並行させると上流工程の期間が伸びるため、障害影響の大きい機能と外部システム接続部分に限定します。テスト担当者が要件レビューに同席するだけでも、検証不能な要件の早期検出という効果の一部は得られます。

実装・テスト工程の品質管理：静的解析とバグ密度・テスト密度の定量評価

下流工程は測定できる材料が揃うため、定量管理の中心になります。ツールによる自動検査と、指標による終了判定を組み合わせます。

静的解析ツールとコードレビューで作る実装工程の品質ゲート設計

実装工程では、機械で検査できる項目を人手のレビューから外すのが原則です。コーディング規約違反・未使用変数・複雑度の閾値超過は静的解析ツールに任せ、人は設計意図との乖離や例外処理の妥当性に集中します。手法と主要ツールの詳細は静的解析でソースコードの品質を確保する手法の記事で扱っています。

品質ゲートとしては「静的解析の重大指摘ゼロ」「レビュー承認1名以上」をマージ条件としてCIに組み込みます。条件を満たさないコードは統合されないため、後工程へ欠陥が流れる量を人の注意力に頼らず減らせます。ゼロから基準を作る手間を省くなら、SonarQubeの既定ゲート「Sonar way」を起点にする方法も選択肢です。SonarQube Serverの公式ドキュメントでは、新規コードに対して「新しい指摘を持ち込まない」「セキュリティホットスポットをすべてレビュー済みにする」「カバレッジ80.0%以上」「重複率3.0%以下」の4条件が示されています（2026年9月時点の記載）。既存コードではなく新規コードだけを縛る設計のため、古いシステムの改修案件でも初日から導入できます。ツールの対応言語や料金体系はSonarQubeのできることと料金を整理した記事を参照してください。

テスト工程管理の実務：テスト密度・バグ密度とIPA基準値による評価

テスト工程の十分性は、テスト密度（開発規模あたりのテスト項目数）とバグ密度（開発規模あたりの検出バグ数）で評価します。「テストを十分にやった」という主観ではなく、1KSLOCあたりの件数という規模で正規化した数値に置き換えることで、案件間・工程間の比較が成立します。

自社に蓄積データがない場合は、IPA（情報処理推進機構）が公開してきたソフトウェア開発の実測統計を参考値に使います。基準値の具体的な数字・計算式・外れたときの解釈はバグ密度・テスト密度の目安とIPA基準値の記事に分離して整理しています。注意点は、密度が基準内に収まっても「テストの質」までは保証しないことです。境界値・異常系の項目比率など、内訳の確認を併用してください。

IPA分析データ集2022で発行終了した参考値の使い方と自社基準値への移行

参考値の出典として押さえておきたい事実があります。IPAの統計は「ソフトウェア開発データ白書」から「ソフトウェア開発分析データ集」へ名称を変え、ソフトウェア開発分析データ集2022（2022年9月26日公開）が現行の最新版です。収集データは5,546プロジェクト、分析の中心は直近6年間の1,479件で、信頼性を軸にまとめられています。データ集の索引ページには「事業終了に伴い今後の発行予定はない」旨が掲載されており、2026年9月時点で2022年版より新しい版はありません。

つまり参考値は年を追うごとに古くなり、クラウド・SaaS連携やAI支援コーディングが前提の開発とは母集団の性格がずれていきます。旧版のソフトウェア開発データ白書2018-2019はアーカイブとして残っていますが、新規の判定基準にはデータ集2022を使い、しかも「初期値」としてだけ扱うのが妥当です。移行の手順は、次に示す3段階です。1案件目はIPA値で判定レンジを仮置きし、2〜3案件でテスト項目数・バグ数・規模を自社で記録し、自社実績の分布が出た時点でレンジを差し替えます。レンジを差し替えた日付と根拠案件は品質計画書に残し、発注者にも説明できる状態にしておきます。

信頼度成長曲線とゾーン分析によるテスト終了判定・出荷可否の決め方

「いつテストを終えてよいか」は、累積バグ検出数の推移を描いた信頼度成長曲線で判断します。検出数の伸びが横ばいに収束し、かつ未解決バグの残件が合意済みの許容水準を下回った時点が終了候補です。曲線が右肩上がりのまま納期を迎えたなら、残存バグを抱えた出荷になるため、範囲を削るか期間を延ばすかのQCD判断に差し戻します。

ゾーン分析は、テスト密度とバグ密度の2軸で結果を4象限に分けて解釈する手法です。たとえば「テスト密度が低く、バグ密度も低い」象限は、品質が良いのではなくテスト不足の疑いが濃い、と読み替えます。単独の指標では誤読する評価を、数値の組で読むことで防げます。

品質メトリクスの運用：品質報告書の読み方とPythonによる自動判定の手順

指標は集めるだけでは機能しません。定例で報告し、基準から外れたときに取る行動をあらかじめ決めておくことで、初めて管理として成立します。

品質報告書で確認する主要メトリクス一覧と発注者側チェックの要点

受託開発の品質報告書で確認する指標を整理します。

指標	算出方法	見るべき点
レビュー指摘密度	指摘件数÷対象規模	少なすぎは形骸化の疑い
テスト密度	テスト項目数÷開発規模	参考値との乖離
バグ密度	検出バグ数÷開発規模	高低いずれも要因分析
バグ収束状況	累積検出数の推移	横ばいへの収束
未解決バグ残件	重要度別の残数	重大残ゼロの確認

発注者側チェックの要点は、数値の絶対値ではなく「参考値との比較と要因分析が書かれているか」です。密度の数字だけが並び、乖離に対する解釈が書かれていない報告書は、測定が目的化しているサインとして扱ってください。

品質メトリクスをPythonで自動集計しCIで出荷判定する手順とコード例

ゾーン分析と収束判定は、機能（モジュール）ごとの規模・テスト項目数・バグ数を1枚のCSVに記録しておけば、標準ライブラリだけで自動化できます。まず集計元のCSVを用意します。daily_new_bugs は日ごとの新規検出バグ数を空白区切りで並べた列です。

module,ksloc,test_cases,bugs,daily_new_bugs
受注管理,12.5,820,61,9 12 10 7 5 2 1 0 1 0
請求連携,4.0,96,5,1 2 1 0 1
在庫引当,8.0,560,90,4 8 11 14 15 16 12

次に判定スクリプト quality_metrics.py です。判定レンジの数値は動作説明用の仮置きで、IPAの参考値ではありません。前章の手順で決めた自社のレンジに書き換えて使います。

import csv
import sys

# 自社実績または参考値から決める判定レンジ（1KSLOCあたり）
TEST_DENSITY = (40.0, 100.0)   # テスト項目数の下限・上限
BUG_DENSITY = (2.0, 8.0)       # 検出バグ数の下限・上限


def zone(value, low, high):
    if value < low:
        return "低"
    if value > high:
        return "高"
    return "中"


def judge(test_zone, bug_zone):
    if test_zone == "低":
        return "NG: テスト不足の疑い（バグが少なく見えても信用しない）"
    if bug_zone == "高":
        return "NG: 作り込み品質の問題。原因工程を分析"
    if test_zone == "高" and bug_zone == "低":
        return "要確認: 項目の重複や観点の偏り"
    return "OK"


def converged(daily_new_bugs, window=5, ratio=0.1):
    total = sum(daily_new_bugs)
    recent = sum(daily_new_bugs[-window:])
    return total > 0 and recent <= total * ratio


def main(path):
    failed = False
    with open(path, encoding="utf-8") as f:
        for row in csv.DictReader(f):
            ksloc = float(row["ksloc"])
            td = int(row["test_cases"]) / ksloc
            bd = int(row["bugs"]) / ksloc
            tz = zone(td, *TEST_DENSITY)
            bz = zone(bd, *BUG_DENSITY)
            daily = [int(x) for x in row["daily_new_bugs"].split()]
            result = judge(tz, bz)
            conv = "収束" if converged(daily) else "未収束"
            print(f"{row['module']}: テスト密度 {td:.1f}({tz}) "
                  f"バグ密度 {bd:.1f}({bz}) {conv} -> {result}")
            if result.startswith("NG") or conv == "未収束":
                failed = True
    sys.exit(1 if failed else 0)


if __name__ == "__main__":
    main(sys.argv[1])

上のCSVを渡して python quality_metrics.py metrics.csv を実行すると、次の3行が出力され、終了コード1で終わります（Python 3.14系で確認）。

受注管理: テスト密度 65.6(中) バグ密度 4.9(中) 収束 -> OK
請求連携: テスト密度 24.0(低) バグ密度 1.2(低) 未収束 -> NG: テスト不足の疑い（バグが少なく見えても信用しない）
在庫引当: テスト密度 70.0(中) バグ密度 11.2(高) 未収束 -> NG: 作り込み品質の問題。原因工程を分析

読み方は前章のゾーン分析と同じです。請求連携はバグ密度だけ見れば優秀に見えますが、テスト密度が下限を割っているため「テスト不足」と判定されます。収束判定は、直近5日の新規検出数が累積の10%以下かどうかという単純な近似で、信頼度成長曲線を描く前のふるい分けに使います。窓幅と比率は案件のテスト期間に合わせて調整してください。

終了コードで合否を返すので、そのままCIのジョブにできます。GitHub Actionsなら、プルリクエストごとに次のワークフローを実行します。

name: quality-metrics
on:
  pull_request:
jobs:
  metrics:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python tools/quality_metrics.py qa/metrics.csv

このジョブをマージの必須条件にするには、リポジトリのブランチ保護で「マージ前にステータスチェックの合格を必須にする」を有効にし、上のジョブを指定します。設定項目の意味はGitHub Docsの「保護されたブランチについて」に記載されているとおりです。ワークフローの書き方そのものはGitHub Actionsでビルド・自動テストを設定する方法の記事で手順を追って説明しています。テスト工程の終盤だけは人の判断を残すため、このジョブを必須にするのは結合テスト以降のブランチに限定する運用も選べます。

数値が基準を外れたときのQCD判断：納期・コスト・品質の優先順位付け

バグ密度が参考値を大きく超えた場合の選択肢は、実質的に3つしかありません。テスト期間を延長する（納期を譲る）、検証要員を追加する（コストを譲る）、リリース範囲を削る（スコープを譲る）。どれも譲らず「現場の頑張りで挽回」を選ぶのが、再発率の高い失敗です。長時間労働は検証の質を下げ、リリース後の失敗コストとして返ってきます。

実務では、障害影響の大きい機能から順にテストを消化する優先順位を計画段階で決めておきます。全機能を同じ深さで検証する計画は、遅延したときにどれも中途半端になる結末を招くためです。優先順位が決まっていれば、期限到来の時点で「未検証部分はどこか」を明示した上でリリース可否を判断できます。工程管理・リスク管理と品質管理をプロジェクト全体でどう束ねるかはシステム開発のプロジェクト管理とQCDの進め方を解説した記事で扱っています。

開発手法別の品質管理：ウォーターフォールとアジャイルの使い分け

工程の進め方が違えば、品質基準の置き方も変わります。自社の契約形態と開発体制に合わせて読み替えてください。

ウォーターフォール型の品質管理：工程完了基準と品質ゲートの運用

ウォーターフォール型では、工程完了基準（レビュー指摘の解消・成果物一式の承認・メトリクスの基準内収束）を満たすまで次工程に進まない品質ゲート運用が基本です。工程が区切られて進むため密度系の指標を計画値と比較しやすく、IPA系の参考値もこの形態の実測が母体になっています。

弱点は、要件の誤りがテスト工程まで表面化しにくいことです。前述のW字モデルや画面プロトタイプの早期確認を組み合わせ、上流の検証を厚くする設計で補います。

アジャイル開発の品質管理：Definition of DoneとCIによる継続的検証

アジャイル開発では、工程ゲートの代わりにDefinition of Done（完成の定義）が品質基準になります。スクラムガイド（2020年版）は完成の定義を「プロダクトに求められる品質基準を満たしたインクリメントの状態の正式な記述」と位置付け、満たさないプロダクトバックログアイテムはリリースもスプリントレビューでの提示もできず、プロダクトバックログに戻すと定めています。「コードレビュー承認済み・自動テスト通過・静的解析の重大指摘ゼロ」といった条件をチームで明文化し、満たさない成果物はスプリント完了に数えません。検証はCIでコミットごとに実行されるため欠陥の検出が早く、修正費用が小さいうちに直せます。

一方、規模あたりのバグ密度のような従来型メトリクスは、反復開発では計測単位が揺れて比較しにくくなります。テストカバレッジの推移や欠陥修正までの平均時間など、継続的に取れる指標へ置き換えるのが現実的です。

過剰品質を避ける判断基準：規模とリスクで品質管理の実施項目を絞る条件

品質管理は厚いほど良いわけではありません。管理工数が開発工数を圧迫すれば、納期遅延という別の品質問題を生みます。ここでは省略してよい条件を言い切ります。

小規模・低リスク案件で省略してよい品質管理と省略できない下限

社内利用のみ・利用者が数十人規模・障害時は手作業で代替可能、という条件が揃う案件なら、信頼度成長曲線の運用と週次の品質報告書は過剰です。この条件では採用しません。管理が目的化し、実装と検証に使うべき工数を食うためです。メトリクスはテスト項目数と未解決バグ残件の2つに絞って構いません。

ただし、どんな小規模案件でも省略してはならない下限があります。第三者によるコードレビュー、テスト項目と実施結果の記録、本番障害の記録の3点です。これらを欠くと障害時に原因追跡ができず、担当者の記憶だけが頼りになります。逆に決済・個人情報・基幹業務のように失敗コストが大きい領域では、案件規模が小さくても定量管理を維持してください。判断の軸は「規模」ではなく「障害時の失敗コスト」です。

ベンダーの品質管理体制を発注前に見抜く確認項目と選定の判断基準

外注先の品質管理体制は、契約前の質問でかなりの精度で見抜けます。有効なのは「テスト密度・バグ密度の実績値を提示できますか」「品質報告書のサンプルを見せてもらえますか」「レビュー記録は納品物に含まれますか」の3問です。実績値を即答できないベンダーは、測定の習慣そのものがない可能性が高いと判断できます。あわせて「判定レンジの根拠はIPAの何年版か、自社実績に切り替えているか」を聞くと、参考値を更新し続けている組織かどうかが分かります。

もう1つの見極めどころが、リリース後の品質維持体制です。開発時の品質管理が機能していても、保守フェーズで体制が変わり品質が劣化するシステムは珍しくありません。一創では開発後の保守運用・内製化支援として、障害対応・テスト整備・改修時の品質ゲート維持までを請け負っています。開発契約と保守契約で品質基準が連続しているかは、発注前に確認しておくべき項目です。

よくある質問

システム開発の品質管理について、検索で多い疑問に簡潔に答えます。

品質管理と品質保証はどちらを先に整備すべきですか？

開発チーム内の品質管理が先です。レビューとテストの記録、終了条件の明文化という土台がない状態で品質保証の監査体制を作っても、監査する対象の記録が存在せず機能しません。工程内のQC活動が回り始めてから、独立した立場で基準を点検するQAを重ねる順番が、少人数の組織でも無理なく成立します。

バグ密度やテスト密度の参考値はどこで確認できますか？

国内で最も参照されるのは、IPA（情報処理推進機構）のソフトウェア開発分析データ集2022です。工程別・業種別の分布が公開されており、自社実績がない場合の初期値に向いています。ただし同データ集は事業終了により2022年版で発行が止まっており、母体もウォーターフォール型の実測が中心です。反復型開発にそのまま適用すると判断を誤るため、まず1案件分の自社データを取り、参考値は乖離の点検に使う運用が安全です。

品質管理はどの工程から始めると効果が大きいですか？

要件定義からです。手戻り増幅の経験則が示す通り、上流の欠陥は下流で発見されるほど修正費用が桁違いに膨らみます。すでに走っている案件で今から着手する場合も、次の工程の入口に「レビュー完了条件」を1枚定義するだけで、欠陥の流出を減らす効果が出ます。テスト工程の強化だけで品質問題を解決しようとするのが、費用対効果の最も悪い選択です。

アジャイル開発でもバグ密度による品質評価は必要ですか？

必須ではありません。反復開発では計測単位が揺れるため、バグ密度よりDefinition of Doneの順守とテストカバレッジ・欠陥修正時間の推移で品質を追うほうが実態に合います。ただし、発注者への品質説明や検収条件としてバグ密度の提示を求められる契約では、リリース単位で規模と検出数を集計して算出する折衷が現実的です。契約時に評価指標を合意しておくと揉めません。

発注者側はどこまで品質管理に関与すべきですか？

最低限の関与は3点です。要件の確認方法（何をもって合格とするか）への合意、受入テスト基準の事前定義、そして品質報告書を毎回読み、乖離の説明を求めることです。開発の内部レビューまで発注者が立ち入る必要はありませんが、この3点を放棄すると、検収時に品質を判断する材料がなくなり、問題発覚がリリース後にずれ込みます。検収と受入検査の違いや支払期日との関係は検収の意味と受入検査との違いを解説した記事で確認できます。