構成管理と変更管理の基本

構成管理とは何か - バージョン管理より広い考え方

構成管理とは、ソフトウェアやハードウェアを構成する成果物の版と組み合わせを管理することです。いつでも特定の版を再現できる状態にすることが目的です。ここでいう構成とは、複数の成果物が組み合わさって、ひとつの製品になっている状態を指します。

構成管理とバージョン管理は、しばしば同じ意味で使われます。しかし両者は別の概念です。バージョン管理は、ソースコードの変更履歴を記録する仕組みにすぎません。構成管理は、その仕組みを含みながら、製品全体をどう識別するかを扱います。加えて、変更をどう統制するかというマネジメントの活動でもあります。開発の全体像を押さえたうえで、この管理プロセスを設計する必要があります（「開発の全体像と手戻りを防ぐ設計」参照）。

「バージョン管理をしているから、構成管理は済んでいる」という誤解も少なくありません。ソースコードの版が分かっても、ビルド環境や設定が分からなければ、同じ成果物を再現できません。構成管理は、この抜け漏れを防ぐための、より広い管理の枠組みです。

構成管理が不十分だと、同じ問い合わせに何度も足止めされます。仕様書の版とソースコードの版がずれていたり、テスト結果がどの版のものか分からなくなったりするためです。

構成管理の対象は、ソースコードだけではありません。次のような成果物すべてが管理対象になります。

• ソースコード：機能を実装するプログラム本体と、それをビルドするためのビルドスクリプト。
• ツールチェーン：コンパイラやリンカなど、ビルドに使うツールの種類とバージョン。
• コンパイラ設定：最適化レベルなど、コンパイラに渡すオプション。
• 設定ファイル：機器の動作条件を決めるパラメータファイル。
• ドキュメント：仕様書や設計書。
• テスト関連の記録：テスト仕様書と、実際に得られたテスト結果。

これらは互いに依存しています。どれか一つでも版がずれると、再現できない構成になってしまいます。

組み込み特有の問題 - 出荷したファームウェアの再現性

組み込みソフトウェアの構成管理には、業務システムにはない難しさがあります。中心にあるのは、出荷したファームウェアの再現性という問題です。

市場で不具合が発生すると、開発者は出荷済みのバイナリを調査対象にします。しかし、そのバイナリがどのソースコードから作られたか、特定できないことがあります。どのコンパイラの、どの設定でビルドされたかも同様です。これでは、原因調査そのものが始められません。ソースコードを最新の状態に戻してビルドしなおしても、出荷品と同じバイナリが得られるとは限らないためです（「ビルドの仕組みと実行までの工程」参照）。

原因を特定できないまま、出荷を止めるべきか判断を迫られる場面もあります。構成管理が不十分だと、こうした重大な意思決定にも時間がかかります。

たとえば、出荷から数年たって、特定の条件でのみ発生する不具合が報告されたとします。担当者が異動し、開発環境も入れ替わっていれば、当時の条件を再現することは簡単ではありません。ソースコードの版だけを控えていても、コンパイラや設定の記録がなければ、原因の切り分けに長い時間がかかってしまいます。

見落とされがちなのが、コンパイラのバージョンによる違いです。同じソースコードでも、コンパイラのバージョンが変わるだけで、生成される機械語が変わることがあります。最適化の実装が変わり、処理順序やタイミングが変化することもあります。その結果、動作結果そのものが変わる場合もあるのです。ソースコードだけを構成管理の対象にしていると、この変化を見逃してしまいます。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

ハードウェアとの組み合わせ、機種・仕向地ごとの派生

組み込み開発では、基板のリビジョンとソフトウェアの版を、組み合わせで管理する必要があります。基板が変わると、センサの特性やメモリ容量が変わることがあります。同じソフトウェアでも、動作が変わる場合があるからです。ソフトウェア単体の版管理だけでは、この組み合わせを保証できません（「クロス開発で詰まるポイント集」参照）。

さらに、機種や仕向地ごとに派生が生まれることも、組み込み特有の悩みです。海外向けに電圧や通信規格を変えたり、上位機種だけ機能を追加したりします。すると、ソフトウェアの派生版が急速に増えていきます。どの派生がどの機種向けか、どの基板と組み合わせて出荷されたか。記録がなければ、後から追跡できません。

機種コードや仕向地コードを、ソフトウェアの版と結び付けて管理しておきます。そうすれば、出荷後の問い合わせにも迅速に対応できます。どの派生をどこまで検証済みか、構成管理で把握できていないと、テストが不十分な組み合わせのまま出荷してしまうおそれもあります。

ベースラインとリリース管理 - 再現ビルドができる状態をつくる

この問題への対策が、ベースラインという考え方です。ベースラインとは、ある時点でのソースコード、設定ファイル、ツールチェーンの版を、ひとまとまりとして固定した状態を指します。名前を付けて記録し、リリースのたびにタグを打ちます。あとから同じ状態を、いつでも呼び出せるようにするためです。タグには、ビルド番号や日付だけでなく、対象機種や仕向地がわかる名前を付けておきます。そうすれば、あとから探しやすくなります。

ベースラインに含める要素は、コンパイラだけにとどまりません。標準ライブラリやOSのバージョン、リンカの設定なども、生成されるバイナリに影響します。これらをまとめて記録しておく必要があります。必要なときに、いつでも同じビルド環境を用意できるようにしておくことが、再現性を支える土台になります。

重要なのは、ソースコードだけでなく、ビルド環境ごと固定することです。コンパイラのバージョンや設定を記録しておかないと、数年後に同じソースコードを使っても、出荷時と同じバイナリを作れません。ビルド環境を仮想化やコンテナで固定します。いつでも同じ手順で、同じバイナリを作れる状態を再現ビルドと呼びます。この状態を用意しておくことが、構成管理の実務上のゴールです。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

変更管理 - なぜ勝手に直してはいけないのか

構成管理によって成果物の状態を固定しても、開発は変更を止められません。バグ修正や仕様変更のたびに、構成は更新されていきます。この更新を無秩序に行わず、手順に沿って進める活動が変更管理です。

変更管理は、一般的に次の流れで進みます。

• 変更要求の受付：何を、なぜ変更したいのかを明確にします。
• 影響分析：変更が他の機能や、既存のテスト結果に及ぼす範囲を洗い出します。
• 承認：影響と工数を踏まえ、変更を実施するかどうかを判断します。
• 実施：承認された内容どおりに、変更を加えます。
• 検証：変更が意図どおりに動き、副作用がないことを確認します。
• 記録：何を、なぜ、誰が変更したかを残します。

現場でよくあるのが、担当者の判断だけで、ソースコードを直接修正してしまうケースです。一見軽微な修正でも、他の機能や過去のテスト結果との整合性が崩れることがあります。影響分析を省くと、直した箇所とは別の場所で、不具合が再発するおそれがあります（「エンバグを防ぐ回帰テスト」参照）。変更管理を徹底することは、不具合が起きたあとの原因追跡にも直結します（「不具合起票の方法と修正フロー」参照）。

変更管理では、誰が承認するかを、事前に決めておくことも重要です。影響範囲が小さい変更は、担当リーダーが承認します。安全にかかわる変更は、複数人でレビューします。このように、変更の重さに応じて承認の重みを変える運用が現実的です。

規格が求める構成管理、そして管理コストを下げる仕組み

構成管理と変更管理は、品質保証の観点からも重視されています。医療機器ソフトウェアの国際規格であるIEC 62304は、リスクマネジメントや問題解決とならび、構成管理を必須のプロセスと位置づけています。これは安全クラスによりません。自動車の機能安全規格ISO 26262も、支援プロセスを定めたPart8のなかで、構成管理と変更管理を扱っています。

自動車以外の分野の読者には直接の適用対象ではありませんが、安全が要求される分野で構成管理が重視される一例として捉えていただければと思います。安全にかかわる分野で構成管理が重視されるのは、変更の影響を追跡できないことが、そのまま安全上のリスクにつながるためです。

規格の要求を満たすこと自体が目的ではありません。変更の影響をたどれる体制を保つことが、本質的な狙いです。組み込みソフトの品質を、V字モデルに沿って検証していく土台としても、構成管理は欠かせません（「V字モデルで学ぶテスト工程と品質保証」参照）。

最後に触れておきたいのが、管理コストの問題です。構成管理と変更管理は、台帳やドキュメントを手作業で更新する運用にすると、更新が追いつかず形骸化しがちです。テストを実施した版と、その結果を自動的にひもづけて記録できる環境があります。そうした環境を整えておくと、どの版で何を検証済みかが常に明確になります。担当者が変わっても、状況を追いやすくなります。こうした環境の整備が、日々の管理の手間を大きく減らします。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

構成管理は、ソースコードだけでなく、ツールチェーンや設定、ドキュメントまで含めて版を管理する活動です。いつでも再現できる状態を保つことが目的です。組み込みでは、出荷後のファームウェアを再現できるかどうかが、特に重要になります。変更管理の手順を守り、版とテスト結果を結び付けて記録する仕組みを持つことが、市場不具合に強い開発体制につながります。