システム変更管理の進め方：少人数開発の承認・リリース・記録

変更管理は、変更してよいか、どの条件で行うかを確認し、その判断と結果を記録する工程です。リリース管理は、承認された版を本番へ反映し、利用者へ提供する計画と実行を扱います。構成管理は、何がどの版・設定で動いているかを識別し、記録します。

3つは別々の作業というより、互いに情報を渡し合う工程です。何を変えるかを決めるには、現在の版と設定が分かっている必要があり、反映した後は、その版を構成の記録へ戻します。呼び方や区切り方は組織や規格によって異なるため、この記事では上の役割の違いとして扱います。

対象はコードだけではありません。環境変数、権限、ネットワークやクラウドの設定、データの一括修正も、本番の動作を変えるなら変更として扱えます。この記事では製品ごとの操作や全社の監査対応までは扱わず、変更1件を依頼から反映後の確認まで追える手順を示します。

承認があることや、CI（継続的インテグレーション）の自動チェックが成功したことは、それだけで安全であることや、公開してよいことを意味しません。何を確認し、何が未確認かを、判断と一緒に残すことが変更管理の中心です。米国NISTの構成管理のガイド（SP 800-128）も、変更の依頼、影響の分析、テスト、承認、実施に加えて、正しく反映されたことを確かめてから変更依頼を閉じる流れを示しています。

すべての変更に同じ会議や同じ数の承認者を求めると、小さな修正まで止まってしまいます。確認と承認の重さは影響に合わせて変え、記録はどの変更でも残します。次の表は、この記事で使う整理の例です。

表は横にスクロールできます →

この3区分は記事の整理例で、公式のランク分けや特定の規格の基準ではありません。文言の修正でも、URL、入力のルール、法的な表示などに影響するなら、影響が限定された変更と即断しません。事前に範囲を決めた変更を個別の承認なしで進める考え方は、NISTのガイドでも、対象外や事前承認とする変更の種類を手順で定める例として示されています（SP 800-128 3.3.2）。すべての変更に新しい会議や新しいテストコードを求めず、確認と記録の量を影響に合わせます。

変更1件を、依頼から反映後の確認まで次の6段階で追います。段階ごとに、誰が判断し、何を残すかを決めておきます。

表は横にスクロールできます →

仕様や依頼内容への合意、コードレビュー、マージ、本番への反映、業務の受入は、同じ承認ではありません。承認した後で版や設定が変わった場合に、どこまで確認し直すかも決めておきます。チケット、プルリクエスト、テストの記録、デプロイの記録は同じ変更IDで結び付け、複数のツールに同じ内容を書き写す前提にはしません。

反映した時点で終わりにせず、6の「結果確認と終了」で変更を閉じます。NISTのガイドも、問題なく反映されたことを確かめるまで変更依頼を閉じない流れを示しています（SP 800-128 3.3.2）。変更を小さな単位に分けて反映すると、問題があったときに戻しやすく、反映後の結果を確かめながら進められます（Google SRE Workbook：Canarying Releases）。ただし、一部の利用者から段階的に公開する方法を、すべての案件で必須にする必要はありません。

次の表は、変更管理票の10項目と記入例です。例は「CHG-001：社内申請フォームに必須項目の入力チェックを追加」で、コードの確認と一部のテストが終わり、公開の判断を待っている「公開前確認中」の状態です。

表は横にスクロールできます →

未確認の項目は空欄にせず、「未確認」と次に確かめることを書いておくと、公開の判断で何が残っているかが分かります。公開の判断や本番の結果の欄を、確認が終わる前に埋めないことが大切です。

役割の数と人数は同じではありません。少人数でも、次の3つの役割を誰が担うかを決めます。

• 業務としての可否：変更が業務に必要か、影響を受け入れられるかを判断する（例：業務の責任者）
• 技術的な確認：差分、テストの範囲と結果、影響の分析を確認する
• 実行と権限：本番へ反映し、そのための権限を持つ

1人が複数の役割を兼ねる場合は、兼務している実態をそのまま記録します。1人での自己確認や、AIによるコードのレビューは、別の人による独立した確認と同じではありません。変更の範囲を小さく限る、自動のチェックを通す、作業の記録を残す、業務の責任者や別の担当者、必要に応じて外部の確認者を加える、といった方法を組み合わせます。それでも独立した確認と同じ効果になるとは限らないため、影響が大きい変更で確認する人を確保できなければ、延期や範囲の縮小も選択肢です。

社内と委託先が関わる場合は、変更の依頼、実装と検証、公開の可否、本番での実行、結果の確認、緊急時の代行を、それぞれ誰が担うかを決めます。委託先そのものが変わる場合の引き継ぎは、システム開発会社を変更する前にで扱っています。

本番の権限は、共有の管理者アカウントを標準にせず、必要な人に必要な期間だけ与え、操作の記録と結び付けます。緊急時に強い権限を使った場合は、後から何をしたかを確認します。コードへのアクセスを最小限の権限に限ることは、NISTのSSDF 1.1（SP 800-218、2022年）でも示されています（PS.1）。上場準備などで監査の対象になるシステムでは、求められる記録と体制を別に確認します（IPO準備のIT全般統制（ITGC））。この記事だけで監査上の十分性は判断できません。

緊急の変更は、通常の手順を省くことではなく、短くした手順で判断と記録を残すことです。平時に次を決めておきます。

• 緊急の判断をする人と、不在のときの代行
• 連絡先と、関係者へ知らせる方法
• 緊急時に短くできる確認と、短くしない確認
• 後から確認する内容と、その時期（自社で定める条件）

例えば、公開後の入力エラーで申請を受け付けられなくなった場合は、次のように候補を比べて判断し、記録します。

間に合わずに通常の手順を通せなかった場合は、その事実をそのまま記録します。後から行ったレビューを、実際とは異なる事前承認の記録へ書き換えてはいけません。NISTのガイドも、予定外の変更を管理の対象に含め、実施後にできるだけ早くレビューする扱いを示しています（SP 800-128 3.3.2）。事後確認の期限は、全社共通の決まった時間ではなく、自社で定める条件で決めます。

切り戻しにも限界があります。以前のコードや設定に戻しても、送信済みのメール、外部との取引、削除・更新したデータが元に戻るとは限りません。データベースの構造を変えた場合は、以前の版が新しいデータで動くか、反映後に増えたデータをどう扱うかも確認します。戻せない場合は、機能の停止、利用の制限、修正版での前進、データの照合などから判断します。バックアップからの復元を確かめる方法は、バックアップ復元テストの進め方で扱っています。

ツールは、変更の対象、確認の結果、公開の記録を集める手段として使えます。ここではGitHubを例にしますが、GitHubの導入や特定のプランの契約が必須というわけではありません。

• Issueやプルリクエストで変更を識別し、差分とレビューを結び付ける
• 保護されたブランチで、マージの前に必要なレビューやチェックの成功を求める（About protected branches）
• 本番の環境へのデプロイの前に、指定した人の承認を求める（Reviewing deployments）
• テストやチェックの結果を自動で集め、判断の材料として残す

ブランチの保護とデプロイの承認は別の設定です。保護ブランチの制限は、既定ではリポジトリの管理者には適用されず、管理者にも適用するかを別に設定します。デプロイの承認でも、自分が起動した実行を自分で承認できないようにする設定や、管理者が保護を回避できるかの設定は個別に決めます。使える機能は、GitHubのプランと、リポジトリが公開か非公開かによっても異なります（Managing environments for deployment）。承認者に登録しただけで本人が公開できなくなる、管理者を含めた全員が止まる、CIが成功すれば業務として承認された、とは限りません。

自動化の前に、人が判断する範囲と例外を決めます。確認の基準を決めて判断に必要な情報をツールで集めること、テストの範囲と結果を記録することは、NISTのSSDF 1.1でも示されています（PO.4、PW.8）。AIにコードの確認を補助させても、判断の責任と権限、確認の独立性は置き換えられません。AIに実装を任せる開発の仕様と検証はAI開発のSDD（仕様駆動開発）で、APIを変更したときの互換性の確認はAPIファースト開発で扱っています。

変更1件ごとに、次の項目を確認します。