変更管理表

概要とマーケティングにおける位置づけ

Web サイトの仕様変更や改修内容について、「いつ・何を・なぜ・誰が判断して行ったか」を記録する表。「変更履歴」とも呼ばれる。

エンジニアが書く Git のコミットログ（コードの細部）と、サイトの設計思想ドキュメントの中間に位置する記録であり、システムの細部よりも「ビジネスとしての判断の足跡」を残すためのものである。

現場の核心：「継ぎ接ぎ化（ブラックボックス化）」を防ぐ防衛装置

最大の目的は、担当者の異動や外部業者の入れ替わりによって失われがちな「過去の判断理由」を組織の資産として残すこと。

記録がないと、「過去の担当者が A/B テストの末に意図的に消したバナーを、事情を知らない後任が復活させて CVRが暴落する」といった悲劇（先祖返り）が起き、サイト全体が一貫性のない「継ぎ接ぎ(継ぎ接ぎ化)（フランケンシュタイン化）」になってしまう。これを予防する強力な運用層の装置となる。

実務における運用ルールと記録項目

全ての微細な変更を網羅しようとすると挫折するため、後で振り返って意味のある「主要変更」だけに絞るのが長続きする現実的なやり方である。Notion のデータベースや Google スプレッドシート、Backlog 等を用いて一元管理する。

• 必須項目：変更日 / 変更箇所（該当 URL や機能）/ 変更内容（何をどう変えたか）/ 【重要】判断理由（なぜその判断をしたか・代替案との比較）/ 意思決定者（担当者・業者・経営層など）/ 関連する KGI・KPI。
• 運用サイクル：月次定例会議で「今月の主要変更 3 件」と「判断理由」を 1 ページで振り返り、2〜3 ヶ月後に「影響観察（効果があったか）」を追記。さらに半期・年次で「主要変更 30 件」を見返し、効かなかった場合は「失敗データベース」として連携させる。

やってはいけない「現場の落とし穴」と防衛策

• 更新の形骸化と細かすぎる罠：表を作っただけで誰も更新しない。あるいは、Git ログレベルで細かすぎる作業履歴を書いてしまい、情報過多で誰も読み返さなくなる。
• 判断理由（Why）の欠如：「ボタンの色を赤にした」という事実（What）だけ書き、AI 生成などで機械的に処理した結果「なぜ赤にしたのか」という一番重要なビジネス判断の理由が薄く、後から見ても何も学べない。
• 業者への依存と消失：管理を制作会社に丸投げし、契約終了やリプレイス時に過去の履歴がすべて消滅してブラックボックス化する。（※対策：業者の保守契約内に「月次の変更管理表の提出・更新」を必須要件として組み込み、自社環境でデータを保持すること）。
• その他の崩壊パターン：担当者個人のローカルメモになって組織で共有されない。変更後の「影響観察（やりっぱなし防止）」を怠ってチームの学習に繋がらない。設計思想ドキュメントとの役割が曖昧で二重管理になる。