リリース当日、クライアントから「表示が崩れてます」「フォームが送れません」。慌ててSlackで関係者に声をかけ、保守会社にも連絡する──でも返ってくるのは毎回同じ質問です。
「何を変更しましたか？」
「影響範囲は？（どのページ／どの機能／どのユーザーが対象？）」
「切り戻せますか？（戻す条件と手順は？）」
答えたいのに、変更内容・手順・戻し方がSlackの断片や個人メモに散っていて、1枚にまとまっていない。だから質問に即答できない。Slackのスレッド、個人メモ、Backlogの断片、口頭の記憶……。関係者が増えるほど、「何を触ったか」の確認に時間が取られ、原因の切り分け（どこを疑うかの当たり付け）が始められません。
制作会社のリリース事故の多くは、技術力の問題というより、必要な前提（変更内容・影響範囲・戻し方・連絡・検証）が揃っていないことが原因で起きます。特にインフラ専任が薄い現場では、ディレクター/PMが「進行管理」だけでなく、「一次窓口」「判断」「障害対応（切り分け・説明・調整）」まで背負いがちです。
この記事では、更新・改修・リリースの前に揃えておきたい「進め方」をチェックリストにまとめました。大げさな運用プロセスは不要です。まずは、既存の保守会社に確認する前に「自分たちの変更内容を説明できる状態」を作るために使ってください。
リリース事故は「作業ミス」ではなく“進め方の欠け”で起きる
制作会社の現場でよく起きるトラブルには、共通するパターンがあります。作業そのものは正しくても、変更内容・影響範囲・戻し方・連絡手順・検証観点が事前に揃っていないと事故につながります。
- 変更内容がSlackや口頭に散らばって、何を変えるのかが1枚にまとまっていない
→ 「今回どこを触ったか」が共有できず、原因の切り分けが遅れます - 影響範囲（どのページ／機能／ユーザーに影響しうるか）が書かれておらず、判断ができない
→ 切り戻すべきか／継続して原因調査するべきかの判断が止まり、クライアント説明も遅れます - 「戻し方（ロールバック）」が決まっておらず、障害が出たときに対応が止まる
→ 「戻す／直す」で迷い、復旧までの時間が伸びます - 連絡が散って、誰が誰に何を伝えるかがその場対応になる
→ 伝言ゲームになり、混乱が拡大します - 検証が見た目中心で、異常の早期発見ができない
→ 表面はOKでも、裏で5xx増加やレスポンス悪化が続き、後から再対応が発生します - 履歴が残らず、同じ原因でトラブルが再発する
→ 「前回どうしたっけ？」が毎回発生します
この記事では、更新・改修・リリースの“進め方を揃える”ことを、便宜上「変更管理」と呼びます。堅い仕組みを導入する話ではありません。制作会社でも回る粒度で、「戻せる・追える・説明できる」状態を作るのが目的です。
これだけで事故が減る：制作会社のリリース前チェック6つ
下の6項目は、どれも「気合い」ではなく「欠けるとトラブルになりやすい前提」を埋めるチェックです。特に効果が出るのは、危険な変更だけ必須にして運用を回し始めることです（危険な変更の例は後半で扱います）。
「全部やろう」とすると形骸化しやすいので、まずは戻しにくい変更／影響が大きい変更にだけ、6項目を必須化してください。
①「何を変えるか」を1枚で説明できる
最初につまずきやすいのがここです。変更点が整理されていないと、以降の判断と説明が全部遅れます。
変更内容がチケットやメモにまとまらないまま本番に入ると、エラーや表示崩れが起きたときに「今回の変更点」を説明できず、原因の切り分け（どこを疑うかの当たり付け）が遅れます。
チェック
- 目的が1行で言える（ついで変更を切る）
例：「フォーム送信エラーを解消するために、バリデーションを修正する」
目的が1行で言えない＝変更の範囲が整理できていません。結果として、当初の目的と関係ない追加の変更（ついで変更）が混ざりやすくなります。検証漏れと履歴漏れを防ぐため、関係ない作業は別日・別チケットに分けます。 - 対象（環境／機能／設定）が特定できる
「本番の問い合わせフォーム」「管理画面の権限周り」「CDNのキャッシュ設定」など、触る対象を特定します。DNS/CDN/WAF/サーバーなど別の管理画面をまたぐ変更ほど、事前に「どこを触るか」を特定しておくのが重要です。 - やらないこと（スコープ）が決まっている
「今回はデザイン微調整はしない」「リダイレクトは触らない」「WAFは変更しない」など、触らない範囲を明確にします。“やらないこと”が決まっていると、当日その場で変更範囲が増えるのを防げます。
②影響範囲が言語化できる
影響範囲を言語化できるだけで、合意形成と意思決定が速くなります。これは「丁寧に書類を作る」話ではなく、障害が出たときに「変更箇所が原因か／別要因か」を最短で当たり付けする準備です。
チェック
- ユーザー影響（誰が困るか）
エンドユーザー／クライアント担当者（管理画面）／社内運用者など、影響が出る“人”を特定します。「一部ユーザー」「特定導線のみ」まで書けると、関係者の認識ズレが起きにくくなります。 - 影響が出る機能（どこが壊れうるか）
TOP／一覧／詳細／フォーム／ログイン／決済／管理画面など、候補を列挙します。障害時は「見に行く場所」が決まっているだけで初動が速くなります。 - 影響が出た時の切り分け方針（誰に何を聞くか）
自社で確認 → 保守会社へ依頼 → クライアントへ確認、のように順番を決めます。ここがないと「とりあえず全員に聞く」になり、状況がさらに散らかります。
③手順が再現可能
「当日いけるだろう」で進めると、イレギュラーが出た瞬間に手順と判断が曖昧になり、何から確認するか／誰に連絡するかがその場判断になって復旧までの時間が伸びます。再現可能とは、担当が変わっても同じ結果が出る状態です。
チェック
- 手順が番号で書ける（当日迷わない）
1,2,3で書けない作業は、実施中に実施順が前後し、確認漏れや戻し忘れが起きやすくなります。「どこを触る」「どこで確認する」をセットで番号化します。 - 担当が変わってもできる（前提情報が揃っている）
URLやログイン先、必要な権限、参照すべき資料が共有されていないと、夜間や担当交代でアクセス確認からつまずき、作業に着手できません。結果として、着手遅れ・確認漏れ・切り戻し判断の遅れが起きやすくなります。 - 危険変更は“もう1人の目”を通す（承認の線引き）
見るべきは「内容の是非」より、抜け（影響・戻し方・連絡・検証）がないかです。もう1人の目が入るだけで、初歩的な抜けがかなり減ります。
④戻せる（ロールバック）
障害が出たときに「戻す／戻さない」で迷うと、関係者調整も含めて長引きます。ロールバックは「最後の手段」ではなく、意思決定のための保険です。
チェック
- 戻す判断条件（この状態になったら戻す）
例：フォーム送信不可／決済不可／ログイン不可／5xxエラー増加／応答が○秒以上
条件があると、関係者に説明しやすくなります。 - 戻す手順（書けないなら実施しない）
戻し方が書けない変更は、障害が出たときに対応が止まります。戻せない変更をするなら、段階的に反映する／事前検証を厚くする／同席できる体制で実施するなど、別のリスク低減策をセットにします。 - 戻す所要時間（説明と意思決定が速くなる）
「戻すなら10分」「直すなら30分」くらいの目安があるだけで判断が速くなります。時間の見積りは、クライアント説明にも直結します。
⑤連絡が散らからない（変更窓・周知・窓口）
制作会社のPMがしんどいのは、事故そのものより「連絡・説明」が一気に自分へ集まることです。連絡が散らからない設計は、問い合わせを一箇所に集め、状況共有を速くすることで混乱の拡大を防げます。
チェック
- 変更窓（体制が薄い時間にやらない／例外条件）
変更窓がないと、体制が整っていない時間に触ってトラブルになりやすいです。例外で日中にやるなら「影響が限定的」「即時ロールバック可能」など条件を決めます。 - 周知（事前／完了／異常時）
事前：内容・日時・影響可能性
完了：結果・確認観点
異常時：現状・影響・次報（いつ何を報告するか）
これだけ揃えば混乱が減ります。 - 窓口とエスカレーション（誰が何を答える）
一次窓口／保守会社への依頼／クライアント報告の役割を分けます。“PMが全部答える”構造を壊すだけで、状況共有が速くなります。
⑥追える（検証・履歴）
「見た目OK」で終わると、5xxエラーの増加やレスポンス悪化などが後から表面化して再対応が発生します。また、履歴がないと切り戻しも再発防止もできません。
チェック
- 検証が「見た目＋指標＋ログ」になっている
見た目：主要導線（TOP／フォーム／ログイン／決済など）
指標：5xxエラー、応答時間、CPU/メモリなど最低限
ログ：見る場所と、異常の判断条件
3点セットが揃うと検知の精度が上がります。 - 変更履歴に最低限が残る（後で戻せる）
立派な台帳は不要です。「いつ／どこを／何から何に／誰が／結果」が追えればOK。リンクやスクショでも十分です。 - 燃えた原因を次回チェックに1つ足す（再発防止が回る）
原因を「次回のチェック項目」として言葉にして追加するだけで、運用が育ちます。小さく直して回すのが制作会社の現実解です。
避けるべき危険な変更パターン5つ
ここからは、制作会社でトラブルにつながりやすい“やり方”を紹介します。「なぜ危険か」と「代わりに何をすればOKか」をセットで押さえてください。
1) 本番での微調整（その場判断）
なぜ危険か：スコープが膨らみ、検証漏れと履歴漏れが発生します。原因特定も遅れます。
代わりに：微調整は別リリースへ。どうしてもやるなら「触る範囲」「戻す条件」を先に決めます。
2) ロールバック不能
なぜ危険か：障害が出た瞬間に復旧戦略がなくなり、判断が止まります。
代わりに：段階リリース、事前検証の強化、保守会社同席など、別の安全策をセットにします。
3) 権限/契約/構成が曖昧なまま触る
なぜ危険か：着手前に止まる／途中で止まる／連絡が迷子になる。結果、復旧が遅れます。
代わりに：DNS/CDN/WAF/サーバーの管理者を先に整理し、作業前にアクセス確認を済ませます。
4) 誰がOKしたか残らない
なぜ危険か：事故後に再発防止ができず、責任が曖昧なまま次回も同じトラブルが起きます。
代わりに：危険な変更だけでいいので、承認者を固定し、記録に残します（コメントでも可）。
5) 履歴が残らない
なぜ危険か：切り戻しポイントが分からない／過去の状態に戻せない／学習できない。
代わりに：変更後に「最低限の履歴」を当日中に残します。
今日から始める最小ステップ
全部を完璧に整える必要はありません。現場が回る形で、まずは最小から始めてください。
- まずは危険変更だけ必須、軽微は任意
いきなり全変更で強制すると反発が出やすいです。戻しにくい・影響が大きい変更だけ必須にするのが現実的です。 - 月1で“燃えた原因”をチェックに追加
再発防止を「気をつけよう」で終わらせず、原因をチェック項目として1つ追加します。積み上げるほどトラブルが減ります。 - ツールは何でもいい
BacklogでもNotionでもスプレッドシートでもOK。重要なのは同じ型で進めることです。
まとめ
リリース事故は、個人の作業ミスというより「進め方に必要な前提が揃っていないこと」で起きます。次のリリースから、この6項目を押さえるだけで、判断と説明が止まりにくくなります。
- リリース前に、6項目のチェックを上から潰す
- 危険な変更だけは必須にする
既存保守会社に確認する前に「説明できる状態」が作れると、初動も説明も速くなり、トラブルの拡大を防げます。
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
