平成28年度秋期問59マネジメント系

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

ソフトウェア開発において, 構成管理に起因しない問題はどれか。

a開発者が定められた改版手続に従りむずにプログラムを修正したので, 今まで正しく動作していたプログラムが, 不正な動作をするようになった。
bシステムテストにおいて, 単体テストレベルのバグが多発して, 開発が予定どおりに進捗しない。正答
c仕様書, 設計書及びプログラムの版数が対応付けられていないので, プログラム修正時にソースプログラムを解析しないと, 修正すべきプログラムが特定できない。
d一つのプログラムから多数の派生プログラムが作られているが, 派生元のプログラムの修正が全ての派生プログラムに反映されない。

正答：Bシステムテストにおいて, 単体テストレベルのバグが多発して, 開発が予定どおりに進捗しない。

AI解説（初心者・標準・上級）

理解度に合わせて3レベルの解説を無料で読めます。

初心者向けまずはここから。やさしく要点を解説

答えは b「単体テストレベルのバグが多発して進捗しない」 です。

構成管理は「ファイルのバージョン管理」。何を・誰が・いつ変更したか追跡する仕組み。

a/c/d は「バージョン管理がされてない」ことによる問題（修正の手順違反・バージョンの紐付けなし・派生プログラムへの反映漏れ）でいずれも構成管理の不備。

一方bは「そもそも品質が低い・テスト不足」が原因で、構成管理とは別の領域（品質管理）の問題。

👉 覚え方：構成管理＝バージョン・変更履歴の管理／品質管理＝バグの数や深刻度。

標準試験対策の基準レベル

なぜこれが正解か

正解は b。構成管理（Configuration Management）はソフトウェア成果物（ソースコード・設計書・テスト仕様等）のバージョン・変更履歴・派生物の関係を統制的に管理する活動。一方、単体テストレベルバグの多発はコード品質・開発者スキル・テスト戦略といった品質管理／開発プロセスの問題で、構成管理の不備とは無関係。

各選択肢の解説

a 改版手続違反でプログラム不正動作：変更管理プロセス（構成管理の一部）不備による問題。構成管理起因。
b 単体テストレベルバグ多発：正解。構成管理に起因しない。品質管理・開発プロセスの問題。
c 仕様書・設計書・プログラムの版数対応なし：バージョン管理の根幹の不備。構成管理起因。
d 派生プログラムへの修正反映漏れ：派生物管理の不備。構成管理起因。

覚え方・ひっかけ注意

構成管理の管理対象：

構成アイテム（CI: Configuration Item）：ソースコード・ドキュメント・ライブラリ
バージョン：版数・履歴
変更要求（CR）：何を・なぜ・誰が変更するか
派生関係：ベースライン・ブランチ・タグ
ベースライン：承認された安定版

「構成管理＝バージョン・変更・履歴・関係性／品質管理＝バグ・テスト・品質指標」で識別。bは品質管理領域の問題なので構成管理に起因しない。

上級誤答論破・背景理論まで深掘り

理論的背景

ソフトウェア構成管理（SCM: Software Configuration Management）はIEEE 828で標準化、CMMIのレベル2必須プロセスエリア。主要活動は：

1. 構成識別：CI（Configuration Item）の特定と命名

2. 構成管理（変更管理）：変更要求の評価・承認・実施

3. 構成状態の記録：履歴管理

4. 構成監査：物理／機能監査

ツール：Git・Mercurial・Subversion・Perforce（ソース管理）、Jenkins・GitLab CI・GitHub Actions（CI/CD）、Artifactory・Nexus（成果物管理）、Terraform・Ansible（インフラ構成管理）。

実務での使われ方

現代SCMプラクティス：

Git Flow／GitHub Flow／GitLab Flow：ブランチ戦略
トランクベース開発：mainブランチ常時リリース可能維持
Conventional Commits：コミットメッセージ規約
セマンティックバージョニング（SemVer）：MAJOR.MINOR.PATCH
モノレポ vs ポリレポ：リポジトリ構成戦略
Pull Request／Code Review：変更承認プロセス
Continuous Integration：自動ビルド・テスト・統合

IaC（Infrastructure as Code）でインフラも構成管理対象に：

Terraform：宣言型インフラプロビジョニング
Ansible／Chef／Puppet：構成管理ツール
Kubernetes Manifests：コンテナオーケストレーション

試験での位置づけ

ソフトウェア工学・プロジェクトマネジメント分野の頻出テーマ。基本情報・応用情報では構成管理の基本概念、システムアーキテクト・プロジェクトマネージャ・ITサービスマネージャでは変更管理プロセス・CCB（Change Control Board）・CMDB・SCMツール選定まで踏み込む。

選択肢の発展補足

構成管理と関連プロセスの違い：

構成管理：CIのバージョン・変更・関係管理
品質管理：成果物の品質保証・QC/QA
プロジェクト管理：スコープ・スケジュール・コスト・リソース
リリース管理：本番展開計画
変更管理：変更要求の評価・承認（ITIL文脈）

DevOps文脈での発展：

GitOps：Gitを真実の源（Single Source of Truth）として運用
Immutable Infrastructure：変更ではなく置換
Trunk-Based Development + Feature Flags：ブランチ最小化＋機能切替
Blue-Green Deployment／Canary Release：安全なリリース手法
Continuous Delivery／Continuous Deployment：自動化されたリリース

アジャイル開発ではスプリント毎にベースライン更新、Definition of Done（DoD）で各CIの完了基準明確化、振り返り（Retrospective）でプロセス改善がSCMと統合される。クラウドネイティブ時代ではKubernetes・Helm Chart・Argo CDでアプリ＋インフラ構成を統合管理するPlatform Engineeringが新たなSCM形態として確立。試験対策は構成管理の基本目的＋関連プロセスとの差異＋現代SCMプラクティスの理解で上位資格全般に対応可能。

出典・引用について

出典：IPA（情報処理推進機構）公式基本情報技術者試験平成28年度秋期問59／公的機関配布資料につき出典明記の上引用。解説は合格ナビによる独自AI解説です。