基本情報 平成24年度 秋期 問54：マネジメント系に関する問題

答えは c「成果物ごとのレビュー時間」 です。

品質を管理する指標とは「品質の良し悪しを数字で測れるもの」。レビュー（みんなで成果物をチェックする会議）にしっかり時間をかけていれば、バグが少なく良い品質になる可能性が高いです。

👉 覚え方：「レビュー時間が長い＝品質チェックを丁寧にしている」。

ほかの選択肢：a 作業の完了数は進捗の指標（品質ではない）／b 個人生産性はコストや効率の指標／d バージョン番号は管理情報であって品質指標ではない。

なぜこれが正解か

正解は c。成果物ごとのレビュー時間は品質管理の代表指標で、適切なレビュー時間が確保されているほど欠陥検出率が高まり、後工程への欠陥流出を防止できる。レビュー密度（成果物単位時間あたりのレビュー時間）はソフトウェア品質保証の標準指標。

各選択肢の解説

• a WBSワークパッケージ完了数 → 進捗管理（スケジュール）の指標。
• b 個人別プログラミング生産性 → コスト・生産性の指標（品質ではなく効率）。
• d プログラムのバージョン → 構成管理の指標（変更履歴の管理情報）。

覚え方・ひっかけ注意

PMBOKのQCD（Quality / Cost / Delivery）の対応で覚える：レビュー時間=Q、生産性=C、進捗=D。品質指標は他にも (1) 不具合検出密度（バグ/KLOC）、(2) テストカバレッジ、(3) ピアレビュー指摘件数、(4) 品質ゲート通過率などが頻出。ゾーン分析（管理図）で異常値を検出する手法も併せて押さえる。

理論的背景

ソフトウェア品質管理ではISO/IEC 25010（旧9126）で製品品質モデル（機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の8特性）が標準化されている。プロセス品質はCMMI、ISO 9001、PMBOK 品質マネジメントで体系化。レビュー（Inspection、Walkthrough、Technical Reviewなど）の効果は (1) 早期欠陥検出（修正コスト指数関数増を回避：要件段階の1に対しテスト段階100、運用段階1,000以上）、(2) 知識共有、(3) 標準準拠検証にある。Fagan Inspectionでは検査時間とログ密度を厳密管理。

実務での使われ方

GoogleやAmazonなどの大規模開発ではコードレビュー必須化、プルリクエスト単位のレビュー指摘数・時間・コメント数をメトリクスとして収集。SonarQube・CodeClimate等の静的解析ツールで自動品質チェック（Cyclomatic Complexity、技術的負債、重複コード率）を実施。アジャイル開発ではペアプログラミングがレビューの一形態として機能。Shift Left Testing思想で早期テスト・早期レビューを徹底するのが現代潮流。

試験での位置づけ

FE・APマネジメント分野で頻出。品質メトリクス、レビュー技法（インスペクション・ウォークスルー・ペアプロ）、テストプロセス、欠陥密度、信頼度成長曲線（ゴンペルツ曲線、ロジスティック曲線）と併せて押さえる。応用情報・PMでは品質計画・保証・コントロールの3プロセス、品質コストモデル（予防・評価・内部失敗・外部失敗の4分類）まで踏み込む。

選択肢の発展補足

バージョン管理（d）はSCM（Software Configuration Management）の中核で、Git・SVN等のVCSで実装。ブランチ戦略（Git Flow、GitHub Flow、Trunk-Based Development）、CI/CD連携（GitHub Actions、Jenkins、CircleCI）が実務スキル。WBS（a）はプロジェクトスコープの分解構造で、100%ルール（親=子の総和）・8/80ルール（末端タスク8〜80時間）が原則。生産性（b）はFP/人月、SLOC/人時で測るが、本数指標は品質を反映しないため、ベロシティ（アジャイル）+ 品質メトリクスの併用が現代的アプローチ。