対象試験と出題頻度
構成管理（バージョン管理）は、基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア開発管理技術の定番論点で、「変更管理」「リリース管理」「ベースライン」といった近接概念との区別、そしてGitに代表されるバージョン管理ツールの基本動作が問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「構成管理とバージョン管理って同じ？それとも違うもの？」と混乱しがちです。ここを整理しておきましょう。
構成管理（Configuration Management）とは、一言で言うと
「ソフトウェアを構成するファイルや設定の変更履歴を識別・記録・統制し、いつでも特定の状態を再現できるようにする活動」
のことです。その中核機能を担うのがバージョン管理で、ファイルの「いつ・誰が・何を・なぜ変えたか」を1つずつ記録していきます。
イメージとしては、「ゲームのセーブデータ」です。
RPGでは要所ごとにセーブを取り、もしボスに負けても直前の状態に戻れます。複数のセーブ枠を使えば、別ルートを並行して試すこともできます。
構成管理もまったく同じ発想で、開発中のソースコードに「セーブポイント」を打ち、いつでも過去の状態に戻したり、別の修正案を並行で試したりできるようにする仕組みです。
📊 構成管理（バージョン管理）の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Software Configuration Management（SCM）／ Version Control |
| 分類 | ソフトウェア開発管理技術／開発プロセス支援 |
| 対象（成果物） | ソースコード、設計書、設定ファイル、ビルド成果物など |
| 代表的なツール | Git、Subversion（SVN）、Mercurial、CVS |
| 関連規格 | ISO/IEC/IEEE 12207（ソフトウェアライフサイクルプロセス） |
解説
ソフトウェア開発はチーム作業です。複数人が同じファイルを同時に編集し、機能追加・バグ修正・リファクタリングが日々入り混じります。
何の管理もしないと、最新版がどれか分からず、過去の動いていた状態にも戻せません。この「変更の混沌」を秩序立てて扱うために構成管理が生まれました。
構成管理が担う4つの機能
| 機能 | 役割 |
|---|---|
| 構成識別 | 管理対象（ソース、設計書など）に一意な識別子を付け、版数で区別する |
| 変更管理 | 変更要求の受付・審査・承認を経てから反映する仕組み |
| 状態記録 | いつ・誰が・何を変えたかを履歴として残す |
| 構成監査 | 記録通りの状態が保たれているかをレビュー・検証する |
図解：バージョン管理の動き（コミットとブランチ）
バージョン管理ツールでは、変更を記録する単位を「コミット」、並行作業のための分岐を「ブランチ」と呼びます。
下図は、main（本流）から派生したfeatureブランチで開発を進め、完了後にmainへ統合する流れです。
バージョン管理のブランチモデル
▲ 青：本流(main) ／ 緑：派生ブランチ(feature) ／ 赤：マージコミット
代表的なGitコマンド
試験で深いコマンド知識は不要ですが、何をするものかは触れておきましょう。
git add .
git commit -m “ログイン機能を追加”
# 並行作業のために枝分かれ
git branch feature/login
git checkout feature/login
# 本流に統合
git checkout main
git merge feature/login
# 過去の状態に戻す
git log # 履歴を確認
git checkout <commit-id>
集中型と分散型
バージョン管理の仕組みには2タイプあります。
SVNのような集中型は中央サーバーに唯一の履歴を持ち、Gitのような分散型は各開発者の手元にも完全な履歴を持ちます。
集中型（例：SVN）
履歴は中央のみ。サーバーに繋がらないと作業できない。
分散型（例：Git）
各端末に完全な履歴。オフラインでもコミット可能。
近接概念との整理
試験で混同しやすい用語を一表にまとめます。
| 用語 | 対象と目的 |
|---|---|
| 構成管理 | 成果物全体の識別・統制・記録・監査（傘の概念） |
| バージョン管理 | 構成管理の中核。ファイルの版（バージョン）を記録・追跡 |
| 変更管理 | 変更要求の受付・影響分析・承認といった「意思決定」の管理 |
| リリース管理 | 本番環境への配布版を取りまとめて公開する活動 |
| ベースライン | ある時点で正式に承認・凍結された成果物の版 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 構成管理の核心を3行で
・ソフトウェアの成果物を識別し、変更履歴を記録・統制する活動全般
・中核機能がバージョン管理。Gitのような分散型ツールが現在の主流
・「変更管理」「リリース管理」「ベースライン」と役割が違うので混同しないこと
試験ではこう出る！
FE・APの午前問題では、ソフトウェア開発管理技術の小問として安定的に出題されます。出題パターンは大きく3つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R元秋 午前 問49 |
ソフトウェア構成管理の対象として適切なものを選ぶ問題。 | ・対象は「成果物（ソース・ドキュメント等）」 ・要員管理や進捗管理は対象外 |
| FE H30秋 午前 問50 |
バージョン管理ツールの説明として正しいものを選ぶ問題。 | ・「変更履歴の記録と過去版の取り出し」が正解 ・テストツール・ビルドツールの説明がひっかけ |
| AP H29春 午前 問50 |
構成管理におけるベースラインの説明を問う問題。 | ・「正式に承認・凍結された成果物の版」 ・テスト基準値・性能目標値はひっかけ |
📝 IPA試験での出題パターン
パターン1：「対象の範囲を問う」
「構成管理の対象として適切なものはどれか」という形式。正解は成果物（ソース・設計書・設定ファイル等）。要員配置・スケジュール・コストといったプロジェクトマネジメント領域を選ばせるひっかけが定番です。
パターン2：「ツールの役割を問う」
バージョン管理ツールの説明を選ばせる形式。キーワードは「変更履歴」「過去の版を取り出す」。コンパイラ・デバッガ・静的解析ツール・CIツールの説明が選択肢に紛れ込みます。
パターン3：「近接用語との区別」
ベースライン・変更管理・リリース管理との違いを問う形式。特に「ベースライン＝正式承認された凍結版」という定義は丸暗記推奨。
試験ではここまででOKです。Gitの個別コマンドの細かな挙動（rebaseとmergeの違いなど）は午前では問われないため、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発における構成管理（バージョン管理）の説明として、最も適切なものはどれでしょうか？
- A. ソースコードや設計書などの成果物に識別子を付け、変更履歴を記録・統制して、いつでも特定時点の状態を再現できるようにする活動。
- B. プロジェクトの作業範囲・スケジュール・コスト・要員配置を計画し、進捗を管理してプロジェクト目標を達成するための活動。
- C. 完成したソフトウェアを本番環境へ配布し、利用者に提供できる状態にするための取りまとめ活動。
正解と解説を見る
正解：A
解説：
選択肢Aは、構成識別・状態記録・統制という構成管理の中核的な機能を正しく述べています。バージョン管理はこの活動の中心を担うため、Aが最も適切です。
選択肢Bはプロジェクトマネジメントの説明です。要員配置やスケジュール管理は構成管理の対象外で、PMBOKなどで扱う領域になります。選択肢Cはリリース管理の説明です。本番配布の取りまとめは構成管理から派生する別の活動で、過去問でも構成管理の選択肢に紛れ込むひっかけパターンとして頻出します。
よくある質問（FAQ）
Q. GitとGitHubは同じものですか？
違います。Gitは手元のPCにインストールして使う分散型バージョン管理「ツール」そのものです。GitHubはGitのリモートリポジトリをクラウド上でホスティングし、Pull Requestやレビュー機能を追加した「Webサービス」です。同様のサービスにGitLab、Bitbucketがあります。試験ではこの両者を区別する直接の出題は少ないものの、用語として正確に使い分けてください。
Q. マージ時に発生する「コンフリクト」とは何ですか？
同じファイルの同じ行を、複数の開発者がそれぞれ別の内容に変更したまま統合しようとしたときに発生する「衝突」のことです。ツールは自動で解決できないため、開発者が手動でどちらの変更を採用するか決めます。コンフリクトを減らすには、頻繁に小さくコミット・マージする運用が有効です。AP午後のソフトウェア開発分野では、ブランチ戦略を絡めた記述問題でこの概念が登場することがあります。
Q. 構成管理はインフラ運用でも使う言葉ですか？
使います。サーバーのOS設定やネットワーク機器の設定値を識別・統制する「インフラ構成管理」の領域があり、Ansible、Chef、Terraformといったツールで設定をコード化（Infrastructure as Code）して管理します。応用情報やネットワークスペシャリストでは、こちらの文脈で構成管理が問われることもあります。基本的な考え方（識別・記録・統制）は共通です。
Q. なぜZIPで日付別にフォルダを保存する方法ではダメなのですか？
小規模な個人作業なら成立しますが、複数人での開発では破綻します。誰がどこを変えたかが追えず、同じファイルを別々に編集した場合の統合（マージ）も手作業になり事故が頻発するためです。バージョン管理ツールは差分のみを効率的に記録し、自動マージ・コンフリクト検知・ブランチによる並行開発を可能にする点で、ZIP管理とは別次元の仕組みになっています。
