レビュー・品質管理
レビュー・品質管理とは
レビューは、成果物（設計書、ソースコード、ドキュメント等）を作成者以外の第三者が確認し、誤りや改善点を指摘するプロセスである。品質管理は、プロジェクト全体を通じて成果物の品質を計画・測定・改善する活動を指す。レビューは品質管理を実現するための最も基本的な手段の一つである。
なぜ SIer で重要か
SIer のプロジェクトでは、開発の各工程で多くの成果物が生まれる。設計書のミス、コードのバグ、ドキュメントの不整合は、後工程に進むほど修正コストが大きくなる。レビューによって早期に問題を発見・修正することで、手戻りを防ぎ、プロジェクト全体のコストと品質を最適化できる。また、顧客に対して品質を定量的に説明する責任があるため、メトリクスに基づく品質管理が不可欠である。
基本概念
レビューの種類
| 種類 | 対象 | 目的 |
|---|---|---|
| 設計レビュー | 基本設計書、詳細設計書 | 設計の正確性、要件との整合性、設計方針の妥当性を確認 |
| コードレビュー | ソースコード | バグの検出、コーディング規約の遵守、可読性・保守性の確認 |
| ドキュメントレビュー | テスト仕様書、マニュアル等 | 内容の正確性、記載漏れ、表記の統一性を確認 |
レビューの目的
レビューには大きく3つの目的がある。
- 品質向上 --- 作成者だけでは見落としがちな誤り・矛盾・曖昧さを、他者の視点で発見する。
- 知識共有 --- レビューを通じて設計方針やコーディング技法がチーム内に共有される。特に若手メンバーにとっては、先輩のレビュー指摘から多くを学べる場でもある。
- リスク低減 --- 特定の人にしか分からない設計や実装（属人化）を防ぎ、チームとしてのリスクを分散する。
レビューの実施形態
| 形態 | 概要 | 適しているケース |
|---|---|---|
| インスペクション | 事前に資料を配布し、レビュー会議で指摘を行う正式なレビュー | 重要な設計書、品質基準が厳しい案件 |
| ウォークスルー | 作成者が成果物を説明しながら、参加者が指摘する | 設計の全体像を共有したいとき |
| ピアレビュー | 同僚同士で 1 対 1 でレビューする | コードレビュー、日常的なチェック |
| セルフレビュー | 作成者自身がチェックリストに基づいて確認する | レビュー前の事前チェック |
SIer での使われ方
レビュー指摘票
SIer の現場では、レビューでの指摘を「レビュー指摘票」として記録・管理する。指摘票には以下の項目が含まれる。
| 項目 | 内容 |
|---|---|
| 指摘 ID | 指摘を一意に識別する番号 |
| 対象成果物 | レビュー対象のドキュメント名・画面 ID 等 |
| 該当箇所 | 指摘のあったページ、章、行番号 |
| 指摘内容 | 具体的な問題点の記述 |
| 指摘区分 | バグ / 改善提案 / 質問 / 誤字脱字 |
| 重要度 | 高（修正必須）/ 中（修正推奨）/ 低（修正任意） |
| 対応内容 | 指摘に対してどう修正したかの記録 |
| 対応状況 | 未対応 / 対応中 / 対応済 / 対応不要 |
指摘票を管理することで、「どんな種類の指摘がどのくらいあったか」を集計でき、品質の傾向分析に活用できる。
メトリクスによる品質管理
SIer のプロジェクトでは、品質を数値で管理する「メトリクス管理」が行われる。代表的なメトリクスは以下の通り。
レビュー密度
レビュー指摘密度 = 指摘件数 / 成果物の規模（ページ数 or ステップ数）
レビュー指摘密度が極端に低い場合、レビューが形骸化している（しっかり見ていない）可能性がある。逆に極端に高い場合は、成果物の品質が低い可能性がある。過去のプロジェクトの実績値と比較して、妥当な範囲に収まっているかを確認する。
バグ密度
バグ密度 = バグ件数 / プログラムの規模（KLOC: 1000行単位）
テスト工程で検出されたバグの密度を測定する。バグ密度が過去の実績値と比べて著しく低い場合は、テストが不十分である可能性がある。業界の目安として、単体テストで 10〜50 件/KLOC 程度が一般的とされるが、プロジェクトの特性によって大きく異なる。
テスト網羅率
テスト網羅率 = 実行済テストケース数 / 計画テストケース数 × 100
テスト消化の進捗を示す指標。テスト網羅率が 100% であっても、テストケース自体に漏れがあれば品質は保証されないため、テスト観点の網羅性と合わせて評価する必要がある。
バグ収束曲線
テスト期間を横軸、累積バグ発見数を縦軸にプロットしたグラフ。テスト後半に向かってバグ発見数が減少し、曲線が収束に向かっていれば品質が安定してきていると判断できる。収束しない場合は、根本的な品質問題がある可能性を示唆する。
品質管理のプロセス
SIer のプロジェクトでは、以下のような品質管理プロセスを運用する。
- 品質計画 --- プロジェクト開始時に品質目標（バグ密度の目標値、レビュー密度の目安等）を設定する。
- 品質測定 --- 各工程でメトリクスを収集し、品質ダッシュボードで可視化する。
- 品質分析 --- 目標値との乖離がないかを定期的に確認する。異常値が出た場合は原因を分析する。
- 品質改善 --- 分析結果に基づいて、レビューの強化、テストケースの追加、再テスト等の改善施策を実施する。
このサイクルを各工程で繰り返すことで、最終的なシステム品質を担保する。
まとめ
- レビューには設計レビュー、コードレビュー、ドキュメントレビューがあり、品質向上・知識共有・リスク低減が目的である
- SIer ではレビュー指摘票で指摘を管理し、指摘の傾向を分析する
- バグ密度、レビュー指摘密度、テスト網羅率などのメトリクスで品質を定量的に管理する
- バグ収束曲線でテスト工程の品質安定度を判断する
- 品質計画 → 測定 → 分析 → 改善のサイクルを回すことが品質管理の基本である