変更管理表
サイトの仕様変更・改修内容を、いつ・何を・なぜ・誰が判断したかを記録する表。「Change Log」「変更履歴」とも。Git のコミットログ + 設計思想ドキュメント([[design-doc]])の中間に位置する記録で、エンジニアレベルの細部より「ビジネス判断」を残す形。継ぎ接ぎ化([[patchwork]])の予防の運用層の装置。
本書のスタンス(Lesson 8-5)は「担当者・業者の入れ替わりで失われがちな『過去の判断理由』を残し、継ぎ接ぎ化を最小限にするのが目的」。月 1 回の振り返りで『今月の主要変更 3 件』と『判断理由』を 1 ページにまとめる現実解。全変更を網羅する必要はなく、後で振り返って意味のある「主要変更」だけ記録する。
記録項目の例:変更日、変更箇所(該当 URL / 機能)、変更内容(何をどう変えたか)、判断理由(なぜその判断か / 代替案との比較)、意思決定者(担当者 / 業者 / 経営層)、関連する事業 KGI / KPI、変更後の影響観察(2〜3 ヶ月後の効果)、失敗 DB との連動(効かなかった場合)。月次定例で「今月の変更 3 件」を振り返り、半期 / 年次で「主要変更 30 件」を見返す運用。
落とし穴は、変更管理表を作って更新しない、業者依存で契約終了時に消える、Git ログレベルで細かすぎて読み返さない、判断理由が表面的で「なぜ」が薄い、担当者個人のメモになって組織で共有されない、変更後の影響観察を怠って学習なし、AI 生成で機械的になり判断理由が薄い、変更管理表と設計思想ドキュメントの役割が曖昧で重複、半期振り返りを怠って継ぎ接ぎ化が進行。
言葉をよく利用する人
- Web 担当者(発注側)
- プロデューサー
- ディレクター
- コーダー / フロントエンドエンジニア
会話上での使用例
月次定例で変更管理表を運用する場面
-
Web 担当者
変更管理表、今月の主要変更 3 件をまとめます
-
マーケター
「フォーム項目を 8 → 5 に削減(理由:CVR 改善仮説)」「トップ KV 画像を冬向けに切替(理由:季節性)」「事例ページ 3 本追加(理由:営業現場からの要望)」の 3 件。3 ヶ月後の効果検証日もカレンダーに登録
業者交代時に変更管理表を引き継ぐ場面
-
Web 担当者
新業者に変更管理表と設計思想ドキュメントを共有します
-
業者ディレクター
助かります。過去 2 年の変更経緯が読めれば、改修判断のブレを抑えられます。新業者になっても同じ表に追記、継続性を保つルールでお願いします