基本情報 平成25年度 秋期 問50：テクノロジ系に関する問題

答えは b です。

「構成管理」とは、ソフトの設計書・プログラム・修正履歴を整理整頓して管理する仕組みのこと。GitやSubversionで版数管理するのがイメージ近い。

• a：手続きを守らずに修正→構成管理の問題
• b：単体テストレベルのバグが多発→これは「テストの質の問題」で構成管理とは別
• c：版数の対応が取れてない→構成管理の問題
• d：派生先に修正が反映されない→構成管理の問題

つまりb だけが構成管理に起因しない。

👉 覚え方：「構成管理＝整理整頓のルール。バグの多さは別の問題」。

なぜこれが正解か

正解は b。構成管理（Software Configuration Management, SCM）とは、ソフトウェアの構成品目（プログラム、設計書、仕様書、テスト計画書等）の版数・変更履歴・関連性を体系的に管理し、変更を制御する活動。bは「単体テストレベルのバグがシステムテストで多発」という品質保証・テスト設計の問題であり、構成管理の不備が直接の原因ではない。

各選択肢の解説

• a：改版手続違反でプログラムが不正動作→変更管理プロセスの逸脱（構成管理の典型問題）。
• b：単体テストレベルのバグが多発→単体テスト工程の品質問題で構成管理とは別の論点。
• c：版数対応の不備でプログラム特定困難→構成識別・トレーサビリティの欠如。
• d：派生元修正が派生先に反映されない→ベースライン管理・派生バリアント管理の問題。

覚え方・ひっかけ注意

「構成管理＝変更・版数・トレーサビリティの管理」。

a/c/d は「変更を追跡・制御できていない」という共通点があるが、bは「テストで漏れたバグ」という品質保証側の問題。「構成管理は予防、テストは検出」と役割を区別する。CMMI/JIS X 0161 等で構成管理プロセスは独立したプロセスエリアとして定義されている。

理論的背景

ソフトウェア構成管理（SCM）はIEEE 828で定義され、主要活動は①構成識別（CI: Configuration Item の特定）、②構成制御（変更の承認・記録）、③構成状況記録（変更履歴の追跡）、④構成監査（ベースラインの整合性検証）、⑤リリース管理、の5要素。CMMI のレベル2に「Configuration Management」プロセスエリアが置かれており、組織的に成熟したソフトウェア開発に不可欠。

変更管理プロセスでは変更要求（CR）→影響分析→変更管理委員会（CCB）承認→実装→検証→ベースライン更新のフローを取る。これによりa・c・dのような問題（無断改版、版数混乱、派生バリアントの分岐）を防ぐ。

実務での使われ方

バージョン管理システム（Git、Subversion、Mercurial）が中核ツール。Gitの分岐戦略（Git-flow、GitHub-flow、Trunk-based development）、タグによるリリース管理、CHANGELOG、セマンティックバージョニング（SemVer: MAJOR.MINOR.PATCH）が現代の構成管理の実装。CI/CDパイプラインに組み込み、コミット→ビルド→テスト→デプロイを自動化することで、構成管理と品質保証を統合運用する。

アジャイル開発・DevOpsでは「Everything as Code」（Infrastructure as Code、Configuration as Code、Documentation as Code）で構成管理対象が拡大。Terraform、Ansible、Kubernetes Manifests等がコードとして管理される。

試験での位置づけ

FE/APのマネジメント系（プロジェクトマネジメント、サービスマネジメント）で頻出。①構成管理 vs 変更管理 vs リリース管理の役割分担、②構成品目（CI）と構成データベース（CMDB）、③ITIL/ITSMにおける構成管理プロセス、が主要論点。本問のように「構成管理に該当しないもの」を選ばせる消去法問題も多い。

選択肢の発展補足

bの「単体テストレベルのバグがシステムテストで多発」は単体テストカバレッジ不足、結合不良、テストファースト未実施などが原因で、これは品質マネジメント・テスト計画の問題。XP（エクストリームプログラミング）のTDD/BDD、フォーマルレビュー（Fagan審査）、静的解析（SonarQube）等で予防する。d の派生バリアント管理はソフトウェア・プロダクトライン（SPL）開発、フィーチャーモデリング、コンディショナルコンパイル（#ifdef）などで体系化されており、組込み系・モバイルアプリ等での「機種別バリアント爆発」対策の主要技法となっている。