構成管理の基本の「き」 ～当たり前なことが難しい～
はじめに システム開発／ソフトウェア開発の現場では、日々多くの変更が行われています。機能追加、バグ修正、設計変更。。。そのすべてがソースコードやドキュメントに影響を与えます。この変化の連続を“管理された状態”に保つための仕組みこそが 構成管理（CM） です。今回は、Automotive SPICEのプロセスの１つである、SUP.8：構成管理の基本について、IEEEなどの国際標準も交えて解説します。 なぜ構成管理が必要なのか 構成管理がうまく機能していない現場では、こんな光景がよく見られます。 “誰が”“いつ”“どこを”“なぜ”変更したのか追跡できない 昨日の動くバージョンに戻したいのに、戻せない ドキュメントと実物が噛み合わず、レビューで混乱 変更したつもりが、別の人の作業で上書きされていたこれらはすべて、生産性と品質を静かにむしばむ“構成管理不足”のサインです。構成管理の目的は一言でいえば、変更の見える化と安定した開発の継続です。 構成管理の主要な4つの活動 １．構成識別（Configuration Identification）まず管理対象となる作業成果物を明確にします。この管理対象を構成品目（Configuration Item：CI）と呼びます。ソースコードはもちろん、設計書、テスト仕様書、ビルド手順書など、作業成果物すべてが対象となり得ます。どこまでを管理するのか最初に決めておくことが、とても重要です。Automotive SPICE v4.0では以下のように解説しています。 構成品目とは、単一の実体として構成管理の対象となる作業成果物または作業成果物一式を指す。 構成品目は、システム、ハードウェア、およびソフトウェアのすべての文書を含むシステム全体から、単一のエレメントまたは文書に至るまで、複雑性、規模、および種類が異なる場合がある。 選定基準は、単一の作業成果物または作業成果物一式に適用してよい。また国際標準である、IEEE 828「IEEE Standard for Configuration Management in Systems and Software Engineering」では、以下のように定義しています。 構成管理のために指定され、構成管理プロセスにおいて単一のエンティティとして扱われる作業成果物の集合体。 構成品目は、その複雑さ、規模、種類が多岐にわたる場合があり、ハードウェア、ソフトウェア、ドキュメントをすべて含むシステム全体から、単一のモジュールやマイナーなハードウェアコンポーネントまで多岐にわたる。プロジェクトの範囲や、標準資産の再利用の考慮等によって、構成品目は様々ですが、必ずしも「１ファイル＝１構成品目」である必要がないことは上記からも理解できると思います。「単一の実態として扱われる作業成果物の集合体」が構成品目となります。 2. 構成制御（Configuration Control）構成管理の根幹となる活動は、変更手続きを管理し、変更を追跡することで、製品の構成が常に正確に把握されるようにすることです。構成制御は、ベースラインを完全に識別し、そのベースラインに対して行われたすべての変更を追跡することによって実現されます。Automotive SPICEではベースラインを以下のように定義しています。 1つまたは一連の作業成果物および生成物の一貫性が保たれ、かつ完成した状態であることを識別している。 次のプロセス段階および／または納入のためのベース。 一意であり、変更されてはならない。少しわかりづらいので、再びIEEE 828を参照してみましょう。以下のように定義しています。 正式にレビューされ合意された仕様または製品であり、その後は以降の開発の基礎となり、正式な手順を通じてのみ変更可能である。 媒体を問わず、構成アイテムのライフサイクル中の特定の時点で正式に指定及び確定された、構成アイテムの正式に承認されたバージョンである。 ソフトウェアベースラインとは、ソフトウェアライフサイクル中の特定の時点で正式に指定され、確定されたソフトウェア構成アイテムの集合（1つまたは複数）である。開発ライフサイクルのある時点（たとえば、要件が確定した時点や統合テストを始める時点）で、正式の合意された製品目一式がベースラインであり、以降の開発工程や納入の基となるものです。好き勝手に変更していけないのがベースラインであり、適切にベースライン（構成品目の集合体）を作成＆更新していくことが構成管理の根幹となります。この適切な作成＆更新を行うためには、正式な変更手順だけではなく、構成品目を格納する「ライブラリ」も重要となります。皆さんの中には既に、作業成果物の格納場所として、Git や Subversion などのツールを利用している方もいると思いますが、国際標準であるIEEE 1042「IEEE Guide to Software Configuration Management」で述べているライブラリの概念が基本となっています。 ダイナミックライブラリ（プログラマーズライブラリとも呼ばれる）： 新規作成または変更されたソフトウェアエンティティ（ユニット/モジュール、データファイル、および関連ドキュメント）を格納するために使用されるライブラリ。 これは、作業担当者がコード開発で使用するライブラリで、そのユニットを担当する作業者は、いつでも自由にアクセスできます。 これは作業者の作業スペースであり、作業者によって管理される。 管理ライブラリ（マスターライブラリとも呼ばれる）： 現在のベースラインを管理し、それらに加えられた変更を制御するために使用されるライブラリ。 これは、統合のために生成された構成品目のユニットとコンポーネントが保持されるライブラリ。 通常は検証後にエントリが認められる。 作業者やその他のユーザーが使用するために、コピーを作成できるが、このライブラリ内のユニットまたはコンポーネントへの変更は、責任部署（構成制御委員会または委任された権限を持つ機関）の承認が必要。 スタティックライブラリ（ソフトウェアリポジトリとも呼ばれる）： 一般利用のためにリリースされた様々なベースラインをアーカイブするために使用されるライブラリ。 これは、運用のためにリリースされた構成品目一式のマスターコピーが保管されるライブラリ。 これらのマスターのコピーは、要求する組織に提供される場合がある。 3. 構成ステータス記録（Status Accounting）構成管理下にある構成品目（作業成果物）に関する重要な情報を記録し、管理者と作業者に報告し、「構成品目が今現在どんな状態か」を共有することが、この活動の目的となります。IEEE 828では、構成品目のステータス情報は、以下のことに役立つと述べています。 ある期間における、プロジェクト作業の結果を把握し、とある時点での完了見込みを把握する。 例：要件の数と実装済みの数を比較することで、これまでの進捗状況を把握できる。 開発中の製品の安定性と機能の完成度に関する状態を把握する。 例：機能またはコンポーネントに対して、実装済みおよび保留中の変更の数は、安定性または変動性を示している。 構成品目の管理（構成管理活動自体）を検証する。 必要に応じて、外部コンプライアンス監査の要件（例：SOXなど）を満たす。「構成ステータス記録」は、構成管理活動自体を監視するプロジェクト管理機能でなく、あくまで構成品目（作業成果物）の状態を監視するものであることも理解しておく必要があります。 4. 構成監査（Configuration Audit）「管理されているはずの状態」が、本当に実態と一致しているかを確認する仕組みです。 ドキュメントの記載と成果物が一致しているか 承認フローが守られているか リリース物は正しい構成か監査は厳しいものではなく、「間違いが積み重なる前の安全装置」というイメージです。 構成管理はツールではなく「文化」Git や GitHub、Azure DevOps、Subversion などのツールは SCM を支える重要な存在ですが、ツールを導入しただけでは構成管理ができたとは言えません。大切なのは、そのツールを使って一貫したルールとプロセスを回し続ける文化があるかどうかです。例えば： ブランチ戦略をチームで統一する コードレビューをルール化する 変更理由を残す習慣をつける リリース手順を標準化するといった取り組みが、SCMの“文化”を育てます。 さいごに構成管理は、「開発を安定させるための基盤であり地盤」です。目立たない活動ですが、これがしっかりしているチームはトラブルに強く、改善サイクルも回しやすくなります。地盤が安定していれば、どんな大きな建物（＝プロジェクト）でも安心して積み上げることができます。 内山哲三