2.10 ソフトウェア構成管理

概要と動機

ソフトウェア構成管理(SCM)とは、ソフトウェアシステムの構成要素を識別し、それらがどう変わるかを管理し、あらゆる変更の状態を記録し、作って納品したものが意図したものと一致していることを検証する規律です。単純に聞こえるが規模が大きくなると難しくなる問いに答えます。このリリースには正確に何が入っていて、どうやってそこに至り、誰が承認したのか。SWEBOKはSCMを基礎的な知識領域として扱っており、理由は明確です。他のあらゆるエンジニアリング活動は、基準となる、安定した既知の構成を必要とするからです。

大きなチームでは、SCMは何千もの動く部品を一貫させておく結合組織です。ソースコード、ライブラリ、コンテナイメージ、インフラストラクチャの定義、構成データ、ドキュメント、テストの成果物は、すべて自分の時計で変わり、納品されたシステムは、そのすべての特定のバージョンの、特定の組み合わせです。意図した構成管理がなければ、その組み合わせは不明で、再現できません。過去のリリースを再作成することも、欠陥をそれを引き起こした変更までたどることも、本番で何が動いているかを自信をもって言うこともできません。

企業や政府の設定では、賭け金が上がります。規制された、あるいは公共部門のプログラムは、変更が承認され、レビューされ、記録されたこと、納品されたビルドが承認された要求とソースまでたどれること、何も管理されずにシステムに入らなかったことを示さなければなりません。ここではSCMは、エンジニアリングのシステムであると同時に、証拠のシステムでもあります。バージョン管理(2.6章)はソースの履歴を管理し、SCMは構成全体と、それが変わる統制されたプロセスを統治します。それはInfrastructure as Code(8.2章)、デリバリーパイプライン(8.1章)、監査と保証(10.2章)に密接に結びついています。

主要原則

システムの振る舞いを決めるすべては、ソースコードだけでなく、管理下にある構成アイテムです。
ベースラインは、既知で合意された基準点です。変更は、気軽にではなく、意図してベースラインに対して行います。
変更は妨げられるのではなく、管理され記録されます。目標は、承認され追跡可能な変更です。
ステータスアカウンティングとは、構成に何が含まれ、その変更履歴が何かに、いつでも答えられることです。
監査は、ビルドされ納品されたシステムが、記録された構成と承認された要求に一致していることを検証します。
再現性は交渉不可能です。リリースされたどのバージョンも、管理された入力から再ビルドできなければなりません。
識別、記録、検証を自動化します。手作業の記帳はスケールせず、監査を生き延びません。

推奨事項

SCMのプロセスを定義し、責任者を割り当てる

何が構成管理の下にあるか、アイテムをどう識別するか、変更をどう提案し承認するか、状態をどう記録し監査するかを述べるSCM計画を書き留めます。構成マネージャーや責任あるチームのような明確な責任者を割り当て、SCMが皆の仕事で、したがって誰の仕事でもない状態にならないようにします。プロセスをリスクに合わせます。小さな社内ツールには軽い管理が必要で、安全が重要な、あるいは規制されたシステムには、正式な委員会と記録が必要です。監査人やパートナーが従えるよう、IEEE 828のような認められた標準に計画を固定します。

構成アイテムを識別し、ベースラインを確立する

システムの振る舞いを決める構成アイテムを一覧にします。ソース、依存関係、ビルドスクリプト、コンテナイメージ、インフラストラクチャの定義、構成データ、スキーマ、主要な文書。それぞれに安定した識別子とバージョニングの方式を与えます。意味のある時点(リリースされたバージョン、承認された要求の集合、認証されたビルド)でベースラインを設定し、変更の対象となり、戻ることもできる合意された基準を持ちます。ベースラインは不変です。いったん宣言したら、編集しません。変更のプロセスを通じて作られた新しいベースラインで、置き換えるだけです。

定義されたプロセスと適切な委員会で変更を管理する

管理対象のアイテムへの変更を、定義された経路で流します。提案、影響評価、承認、実装、検証。より高リスクなアイテムには、変更を承認する前にコスト、リスク、スケジュールを量る変更管理委員会(CCB)を使います。委員会を適切な大きさにします。日常的なコードの変更には軽い自動のゲート、ベースライン、インターフェース、規制された振る舞いに触れる変更には、正式な部門横断のCCB。各決定とその背後の推論を記録し、重要な構成の決定を決定記録(1.6章)に結びつけて、推論が生き延びるようにします。

構成ステータスアカウンティングを維持する

すべての構成アイテムの正確で問い合わせ可能な記録を保ちます。現在のバージョン、属するベースライン、適用された変更要求。このステータスアカウンティングが、いつでも、リリースに何が含まれ、どうやってそこに至ったかに答えられるようにします。現実から乖離する別のスプレッドシートを保守する代わりに、記録の元となるツール(バージョン管理、パイプライン、成果物レジストリ)から自動的に記録を生成します。この記録は、要求から変更、ビルド、デプロイまでのトレーサビリティの背骨です。

構成監査を実施する

定期的に二つのことを検証します。機能構成監査は、構成が要求の規定どおりに動作することを確認します。物理構成監査は、納品された成果物が記録された構成と一致すること、つまりビルドが記録されたソースと依存関係から来ていて、説明のつかないものを何も含まないことを確認します。できる限り自動化します。再現可能なビルド、成果物のチェックサム、ソフトウェア部品表(SBOM)、来歴の証明書は、監査を手作業の検査から継続的なチェックに変えます。

リリースとデリバリーを管理されたイベントとして扱う

リリースを、繰り返し可能なプロセスで届けられる、特定の識別されたベースラインとして扱います。リリースを明示的にバージョン付けし、含まれるものを正確に記述するマニフェストや部品表を作成し、リリースからソースのリビジョン、デプロイされた成果物へのマッピングを記録します。リリースされた成果物に署名しチェックサムを付け、下流の誰もがその完全性を検証できるようにします。リリース管理をデリバリーパイプライン(8.1章)に結びつけ、環境間の昇格自体が管理され、記録され、元に戻せるようにします。

SCMのツールを選び、統合する

規律だけに頼るのではなく、識別、管理、アカウンティング、監査を自動化するツールに頼ります。ソースにはバージョン管理、バイナリには成果物とイメージのレジストリ、ビルドには不変のパイプライン、環境にはInfrastructure as Code、来歴には依存関係とSBOMのツール。それらを接続し、一つの変更がコミットからデプロイされたリリースまで追跡可能に流れるようにします。目指すのは、構成の記録が、別の事務的な雑務ではなく、仕事をすることの副産物になるツールチェーンです。

トレードオフ: 長所と短所

選択	長所	短所
正式な変更管理委員会	強い承認と監査証跡。変更の前にリスクを量る	スループットが遅い。日常的な変更に適用するとオーバーヘッド
軽い自動のゲート	速い流れ。低オーバーヘッド。多くの変更にスケールする	高リスクのベースラインには弱い。熟慮が少ない
厳格な不変のベースライン	再現可能で監査可能な基準点	規律とツールが必要。使いすぎると摩擦
自動のステータスアカウンティング	正確で常に最新の記録。監査に備えられる	前もってのツールと統合への投資
手作業の構成記録	始めるのが簡単。ツール不要	現実から乖離する。規模と監査のもとで失敗する

中心的なトレードオフは、管理と流れです。重い変更管理は強い保証を与えますが、デリバリーを遅くします。軽い管理は速く流れますが、トレーサビリティを弱めます。答えは、全体に一つを選ぶことではなく、リスクで管理の階層を分けることです。日常的な変更は速いゲートを通して自動化し、承認と監査可能性が本当に重要なアイテムのために、正式な委員会と不変のベースラインを取っておきます。二つ目のトレードオフは、前もってのツールへの投資と、継続的な事務のコストおよび監査リスクです。自動のアカウンティングは、設定にはより多くかかり、付き合うにははるかに少なくて済みます。

チームで議論すべき問い

構成アイテムのリストには正確に何が属し、何か新しいものが現れたとき、その決定を誰が所有しますか。 SCMは、管理されるアイテムのリストが、実際に振る舞いを決めるものの集合と一致するときにだけ機能し、大きなシステムでは、その集合はほとんどのチームが考えるより大きいものです。ソース、依存関係、ビルドスクリプト、コンテナイメージ、インフラストラクチャの定義、スキーマ、フィーチャーフラグ、そしてソフトウェアの動作を静かに変える構成データ。誰もリストを所有していなければ、それは古くなり、本番であなたを止めたアイテムは、誰も管理しようと考えなかった唯一のものだったと判明します。現在の一覧を会議に持ち込み、そこにない、振る舞いを決めるアイテムを探してください。責任ある所有者(構成マネージャーや名前のあるチーム)を割り当て、新しいアイテムの追加が偶然ではなく意図した決定になるようにします。皆の仕事であるSCMは、誰の仕事でもないからです。
デプロイされた成果物が、私たちが思うソースとパイプラインから来たことを証明でき、その証明は改ざんに耐えますか。 再現性とトレーサビリティがSCMの要点そのものであり、鋭い形の問いは、実行中のバイナリを、主張ではなく証拠で特定のコミットとビルドの実行までたどれるか、です。規制された、あるいは価値の高いシステムでは、これはサプライチェーンの防御でもあります。署名された来歴の証明書、成果物のチェックサム、ソフトウェア部品表が、「だいたい確かだ」を、監査人やインシデント対応者が検証できるものに変えます。直近のリリースを持ち込み、デプロイされた成果物から承認された変更まで後ろ向きにたどってみてください。どこかの一跳びが、記録され検証可能なリンクではなく手作業の主張なら、そこが攻撃者や誠実な間違いが気づかれずに何かを滑り込ませられる所であり、それを塞ぐことは、記録がデリバリーの副産物になるよう、署名と来歴をパイプラインに組み込むことを意味します。
今日、誰かがリリースをその場で編集できますか。そしてそれは、リリースを信頼する私たちの能力に何をもたらしますか。 ベースラインは不変であるときにだけ有用です。「リリース」が事後に編集できるようになった瞬間、それを再現することも、基準として頼ることもできなくなり、下流のあらゆる監査は考古学になります。典型的な失敗は、本番で直接編集された設定や、静かに動かされたタグであり、それはまさに、無害に感じられ、後でリリースを再構成不能にする近道です。誠実な答えを会議に持ち込んでください。変更のプロセスを通らずに、デプロイされたベースラインを変更できるアクセスを持つのは誰で、それは起きたことがありますか。直し方は、ベースラインを本当に不変にし、すべての変更を提案、影響評価、承認、検証に通し、日常的な変更は速い自動のゲートを流れ、ベースラインや規制された変更は委員会に行くよう、厳密さを階層化することです。
構成ステータスアカウンティングは、記録の元となるツールから自動的に生成されていますか。それとも手作業で保守され、実際にデプロイされているものからどれだけ乖離していますか。ステータスアカウンティングは、いつでもリリースに何が含まれ、どうやってそこに至ったかに答えられるようにする記録であり、大きなシステムでは、その記録は、別のスプレッドシートに打ち込まれるのではなく、仕事から自然に出てくる場合にのみ信頼できます。相反する引力は、手で保つ台帳は始めるのが安く柔軟に感じられる一方、それを自動化することは、記録がデリバリーの副産物になるように、バージョン管理、パイプライン、成果物レジストリを統合することを意味することです。今日頼っている台帳を持ち込み、最近のリリースを三つ無作為に選んで、記録されたバージョン、ベースライン、適用された変更要求が、ツールが出荷したと言うものと一致するか確認してください。企業や政府のプログラムでは、現実から乖離したステータス記録は、整理整頓の問題ではなく、起こりかけている監査の指摘です。一つのギャップを見つけた監査人は、記録全体を信頼するのをやめ、手作業で再構成するよう求めるからです。
変更管理はリスクで階層化されていますか。それとも、何に触れるかにかかわらず、すべての変更を同じ水準の儀式が統治していますか。 管理と流れは互いに引き合います。正式な変更管理委員会は変更を承認する前にコスト、リスク、スケジュールを量りますが、日常的なコードの微調整にその儀式を適用すれば遅延が増えるだけで、共有のベースラインや規制された決済フローを速い自動のゲートに通せば、熟慮を最も必要とするまさにその場所から取り除いてしまいます。失敗モードは対称的です。人々が迂回することを学ぶ一様な重さか、高リスクの変更が精査されずに通り抜ける一様な緩さ。先四半期の変更のサンプルを、それぞれが触れたものごとに分けて持ち込み、受けた厳密さが実際にリスクに見合っていたかを確認してください。規制された、あるいは公共部門の設定では、どのアイテムのクラスが部門横断の委員会に届かなければならず、どれが自動のゲートを流れてよいかを名指しし、その階層化を明示的に記録してください。「判断を使っている」は、監査人や監督機関が検証できる統制ではないからです。
最後に機能構成監査と物理構成監査を実施したのはいつで、その証拠のどれだけが、再構成ではなく生きた記録でしたか。 機能構成監査は、システムが要求の規定どおりに動作することを確認し、物理構成監査は、納品された成果物が記録された構成と一致し、説明のつかないものを何も含まないことを確認します。これらを飛ばせば、ベースラインとステータスアカウンティングが誠実であることを、一度も確かめずに信頼していることになります。緊張はコストです。手作業の監査は遅く苦痛で、だからこそチームはそれを先送りにし、抜け出す道は、再現可能なビルド、成果物のチェックサム、ソフトウェア部品表、来歴の証明書でチェックを自動化し、検証が継続的になるようにすることです。直近のリリースを持ち込み、要求から変更、ビルド、デプロイまでのトレースと、成果物からソースへの証明をその場で作れるか試してください。企業や政府のプログラムでは、この証拠の跡が認証と監督の求めるものなので、誠実な問いは、明日の監査が、すでに持っている記録から答えられるのか、それとも負担できない考古学の演習になるのか、です。

セクター別の視点

スタートアップ。 SCMを軽く、しかし本物に保ってください。ソース、インフラストラクチャの定義、構成データをバージョン管理に置き、すべてのリリースを、手で組み立てた成果物ではなく、一つのパイプラインで作られるタグ付きのビルドにします。あなたの規模では過剰な変更管理委員会や正式なベースラインは省きますが、誰にも本番で直接設定を編集させないでください。来週の火曜日に顧客がバグに出会ったとき、その一つの近道が、リリースを再現不能にするからです。

小規模事業者。 構成マネージャーはおらず予算も厳しいので、ほぼ無料でSCMを与えてくれるツールに頼ってください。ホスト型のバージョン管理プラットフォーム、その組み込みのパイプライン、成果物レジストリ。構成の記録が、人員を配置しなければならない仕事ではなく、副産物になります。特注のプロセスを作る代わりに、すでに払っているツールに組み込まれたこの機能を買います。乏しい注意を、最も重要な二つの習慣、再現可能なタグ付きのリリースと、振る舞いを変える設定を手作業の本番編集から外すことに使います。

大企業。 問題は多数のチームにわたる一貫性です。共有のSCM計画、共通の構成アイテムの分類、階層化された変更管理、そしてバージョン管理、成果物レジストリ、パイプラインから自動的に生成されるステータスアカウンティング。正式な変更管理委員会と不変のベースラインは、共有のプラットフォームと規制されたフローのために取っておき、日常的な変更は自動のゲートを流し、署名された来歴とSBOMを標準化して、どのチームのリリースもたどれ、どの監査人も再構成を依頼する代わりに生きた記録を照会できるようにします。

政府。 調達規則、透明性、公的な説明責任がプロセスを形づくります。IEEE 828のような認められた標準に沿った正式なSCM計画に従い、構成アイテムを契約上のマイルストーンでベースライン化し、管理されたベースラインへのあらゆる変更を、影響、決定、根拠を記録する委員会に通します。納品された成果物が、管理された入力から再現可能で、チェックサムが付けられ、承認された要求から納品されたビルドまで端から端までたどれることを求めてください。その文書化された証拠の跡こそが、認証、監査、公的な監督が求めるものだからです。

事例

スタートアップ。 6人のスタートアップは、SCMを軽く、しかし本物に保ちます。ソース、インフラストラクチャの定義、構成データのすべてがバージョン管理にあり、すべてのリリースは手で組み立てられるのではなく、同じパイプラインで作られるタグ付きでバージョン付きのビルドです。顧客が先週の火曜日に現れたバグを報告したとき、推測する代わりに、数分でデプロイされた成果物を正確なコミットまでたどります。彼らの規模では過剰な変更管理委員会と正式なベースラインは省きますが、誰にも本番で直接設定を編集させません。その一つの近道が、後でリリースを再現不能にするからです。

大企業。 大手の金融サービス会社が、すべてのデプロイ可能な成果物、インフラストラクチャの定義、構成データを構成管理の下に置いています。すべてのリリースは、生成されたソフトウェア部品表を伴う不変でバージョン付きのベースラインであり、デプロイされた各成果物は、特定のソースのリビジョンとパイプラインの実行に結びつく署名された来歴の証明書を持ちます。日常的なアプリケーションの変更は自動のパイプラインのゲートを流れ、共有のプラットフォームのベースラインや規制された決済フローへの変更は、変更管理委員会に行きます。ステータスアカウンティングは、バージョン管理、成果物レジストリ、パイプラインから自動的に生成されるので、監査人は再構成を求める代わりに生きた記録を照会します。

政府。 防衛関連のプログラムが、IEEE 828に沿った正式なSCM計画に従っています。構成アイテムは一覧にされて契約上のマイルストーンでベースライン化され、変更管理委員会が、管理されたベースラインへのあらゆる変更を承認して、影響、決定、根拠を記録します。機能構成監査は、納品されたシステムが規定された要求を満たすことを確認し、物理構成監査は、納品された成果物が記録された構成と正確に一致することを確認します。リリースは管理された入力から再現可能で、チェックサムが付けられ、承認された要求から変更要求、納品されたビルドまで端から端までたどれます。それがまさに認証と監督が求める証拠の跡です。

ビジネスケース: 動機、ROI、TCO

SCMは、システムの寿命にわたるリスクとコストを管理するために存在します。見返りは再現性とトレーサビリティから来ます。あらゆるリリースを再作成でき、欠陥をそれを引き起こした変更までたどれ、監査の質問に考古学ではなく記録から答えられます。それはインシデントの診断時間を縮め、監査のコストと長さを減らし、何が動いているか、あるいはどうやって再ビルドするか誰にも言えないという、高価な種類の失敗を防ぎます。

総所有コストは自動化に有利です。手作業の構成記録は始めるのに安く、保守するにはだんだん高くなり、最も必要とされるまさにそのとき、インシデントや監査の間に、現実から乖離しているために失敗します。自動の識別、アカウンティング、監査は前もっては多くかかりますが、構成の記録を、デリバリーパイプラインのほぼ無料の副産物に変えます。リーダーシップに論拠を示すには、SCMを、リリースを再現可能にし、変更を監査可能にする統制として枠づけ、再現不能なリリース、長引く監査、管理されない変更のコンプライアンスリスクのコストと比べてください。

アンチパターンと落とし穴

属人的な知識による構成: リリースの本当の中身が、どの記録でもなく、エンジニアの頭の中にだけあること。
可変のベースライン: 「リリース」がその場で編集され、もう再現できず、基準として信頼できないこと。
管理されない構成データ: コードはバージョン管理されているが、その振る舞いを変える設定が本番で場当たり的に編集されること。
変更管理の芝居: すべてを形だけ承認する委員会で、本物の精査を加えずに遅延を加えること。
手作業のステータスアカウンティング: 実際にデプロイされているものから、静かに乖離していくバージョンのスプレッドシート。
再現不能なビルド: 管理された入力から再ビルドできないリリース。監査と再ビルドが当て推量になります。
追跡不能なリリース: デプロイされた成果物からソースのリビジョン、変更要求、承認へのマッピングがないこと。

成熟度モデル

レベル1(開始): SCMは場当たり的で反応的です。ソースだけが管理され、リリースは手で組み立てられ、ベースラインも、何がデプロイされているかの信頼できる記録もなく、過去のビルドを再現する方法もありません。
レベル2(発展): 基本的な実践はありますが、チームごとに異なります。構成アイテムと変更のプロセスを定義し、リリースをバージョン付けするシステムもあり、ベースラインはあちこちにありますが、記録は部分的に手作業で、管理の厳密さは組織全体で一貫しません。
レベル3(標準化): 実践は文書化され、組織全体で徹底されています。共通の構成アイテムの分類、不変のベースライン、階層化された変更管理、ステータスアカウンティングが確立され、大部分が自動化され、リリースは再現可能で追跡可能で、監査は記憶ではなくツールに支えられます。
レベル4(管理): SCMがデータで測定され、制御されています。再現率、要求からデプロイされた成果物までのトレーサビリティのカバレッジ、各管理階層を通る変更のリードタイム、構成のドリフトのインシデント、監査の指摘がベースラインと目標に対して追跡されます。逸脱は是正を引き起こし、あらゆる継続・中止の判断は、主張ではなくこの証拠に基づきます。
レベル5(オーケストレーション): SCMは継続的に改善され、組織全体に統合されています。再現可能なビルド、SBOM、来歴の証明書、生きたステータスアカウンティングで完全に自動化され継続的に検証され、プロセスはデリバリー、セキュリティ、監査に織り込まれ、リスクとデリバリーの成果の変化に応じて適応し、証拠に基づいて統制を退役させ、スコープを見直します。

議論のためのアイデア

今日、直近のリリースを管理された入力から正確に再現できますか。そしてどれくらい時間がかかりますか。
振る舞いを決めるが、実際には管理下にない構成アイテムはどれですか。特に構成データとインフラストラクチャは。
変更管理はリスクで階層化されていますか。それとも、どこでも一様なオーバーヘッドか一様な緩さを加えていますか。
構成の記録はどこにあり、実際にデプロイされているものからどれだけ乖離していますか。
明日の監査でどんな証拠を出せますか。そしてそのどれだけが記録ではなく再構成でしょうか。
再現可能なビルド、SBOM、来歴は、監査が自動的に検証できるものをどう変えますか。

要点

SCMは、ソースだけでなく、構成全体(コード、依存関係、インフラストラクチャ、構成データ)を管理します。
ベースラインは不変の基準点です。変更は妨げられるのではなく、それに対して承認され記録されます。
ステータスアカウンティングは、いつでも、リリースに何が含まれ、どうやってそこに至ったかに答えられるようにしなければなりません。
監査は、ビルドされ納品されたものが、記録された構成と承認された要求に一致することを検証します。
管理をリスクで階層化し、識別、アカウンティング、監査を自動化して、記録がデリバリーの副産物になるようにします。

参考文献とさらなる読み物

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Configuration Management knowledge area
IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (configuration management process)
Jez Humble and David Farley, Continuous Delivery
Bob Aiello and Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work in the Real World
NIST guidance on software supply chain security, software bills of materials (SBOM), and artifact provenance
CNCF and open standards for build provenance and attestation (as reference frameworks)