"いつでも誰でも本番を変えられる"状態では上場できない

上場審査で最も指摘を受けやすいITGC領域のひとつが変更管理（Change Management）です。開発者が本番環境に直接アクセスできる、リリース承認の記録がない、緊急対応の事後承認がない──中小企業ではこうした"スピード重視"の運用が根付いており、監査対応時に困ります。

本記事では、上場審査に耐えるIT変更管理プロセスを中小企業向けに実装する手順を解説します。

"変更"の定義と対象範囲

  • アプリケーションコード変更：業務システム、Webアプリ、APIの改修
  • インフラ設定変更：サーバー、ネットワーク、クラウドリソースの変更
  • マスタデータ変更：会計勘定、取引先、商品マスタの更新
  • SaaS設定変更：M365/Salesforce等の管理者操作による設定変更
  • パッチ適用：OSやミドルウェアのセキュリティ更新
  • 運用手順変更：バッチスケジュール、バックアップ方式の変更

変更カテゴリと承認レベル

カテゴリ例承認
標準変更既存機能の軽微な修正、ユーザー追加情シス責任者
通常変更画面改修、バッチ追加、DBスキーマ変更情シス責任者＋事業部門
重大変更会計システム改修、マスタ変換、外部連携追加CAB（変更諮問委員会）
緊急変更障害対応、ゼロデイパッチ事前：情シス責任者
事後：CAB承認

変更管理ワークフロー（10ステップ）

  • ①申請：変更内容、理由、影響範囲、テスト計画、ロールバック計画
  • ②影響分析：関連システム、依存関係、リスク評価
  • ③承認：カテゴリに応じた承認者による承認
  • ④開発：開発環境で実装、コードレビュー
  • ⑤テスト：単体・結合・受入テスト、テスト結果記録
  • ⑥ステージング検証：本番相当環境での最終確認
  • ⑦リリース承認：Go/No-Go判定、リリーススケジュール確定
  • ⑧本番反映：計画時間内、実行者と確認者の分離
  • ⑨事後検証：監視、ユーザー確認、異常時のロールバック
  • ⑩クローズ：チケットクローズ、変更台帳更新

職務分掌（SoD）の実装

役割できることできないこと
開発者開発環境／ステージング環境への変更本番環境への直接変更
運用担当本番反映の実行開発・コード作成
申請者変更申請自分の申請を自分で承認
承認者申請の承認自己承認、実行作業
⚠️ 小さな組織の工夫

少人数でSoDが厳密に保てない場合、「承認は必ず複数人」「直接本番アクセスは不可、作業時は仮アカウント払出し」などで実質的な牽制を効かせます。

緊急変更の運用

  • 事前手順の明文化：緊急判定基準、連絡網、承認代行者
  • 一時承認：情シス責任者による口頭／メール承認を可
  • 作業後24時間以内のチケット起票
  • CAB事後承認：次回の変更諮問委員会で承認と再発防止策の議論
  • 緊急変更比率のモニタリング：多すぎる場合は設計不備を示唆

監査対応のエビデンス整備

  • 変更申請書・承認記録（チケット／電子署名）
  • テスト結果報告書
  • 本番反映作業記録（日時、作業者、確認者）
  • Git等のコミット履歴、Pull Request承認
  • CI/CDのパイプライン実行ログ
  • 変更台帳（年次サマリ）

ツール構成例

領域ツール
チケット／申請承認Jira Service Management、ServiceNow、Backlog
コード管理／レビューGitHub、GitLab、Azure DevOps
CI/CDGitHub Actions、Azure Pipelines、Jenkins
インフラ構成管理Terraform、Ansible
承認／通知Teams/Slack連携＋承認Bot

よくあるアンチパターン

  • 開発者が本番サーバーにSSHして直接編集
  • 「口頭で指示した」のみで承認証跡なし
  • マスタ変更を業務部門がSQL直接実行
  • パッチ適用のみ手順書外で運用
  • リリース後の検証記録なし

BTNコンサルティングの支援

BTNでは、変更管理規程の策定、ワークフロー設計、ツール導入、CAB運営、監査対応まで支援します。「Project365」での集中整備、「情シス365」での継続運用が可能です。

上場準備・グロース企業向けの包括支援はエンタープライズ向けサービスをご覧ください。

→ 情シス365 Enterprise（上場準備・エンタープライズ向け情シス支援）

まとめ

変更管理は"ルール作成"だけでは通りません。ツール・職務分掌・緊急時の現実解まで含めて"使える仕組み"に仕立てることが、上場審査突破の鍵です。