公開は作業ではなく段取りです。誰がいつ押すか、うまくいかなかったらどう戻すかが決まっていれば、当日の判断はほとんど必要なくなります。
1. 公開の日時と体制を決める
公開の時間帯は、利用者が少なく、かつ関係者が起きて動ける時間を選びます。深夜は利用者への影響が小さい一方で、問題が起きたときに動ける人が限られます。金曜の夕方は、問題がそのまま週末まで残りやすいため避けるのが無難です。多くの場合、平日の午前から午後の早い時間が扱いやすい時間帯になります。当日に誰が待機し、何かあったときに誰が判断するかを、事前に名前で決めておいてください。
- 公開の日時（利用者が少ない時間帯か、関係者が対応できる時間か）
- 公開作業を行う人と、確認する人
- 公開後、しばらく様子を見る人と、その時間の長さ
- 問題が起きた場合に判断する人（不在時の代理を含む）
- 公開を延期する判断の期限（当日の何時までに決めるか）
2. 中身の確認
公開するものが、合意した範囲と一致しているかを確認します。検収が済んでいる場合でも、その後に加えた修正が含まれているか、逆に今回は入れないと決めたものが混ざっていないかを見てください。前提として、検証環境で最終確認したものと、これから公開するものが同じ内容であることを確かめます。ここが違っていると、事前の確認がすべて意味を失います。変更点の一覧を文書でもらうのが確実です。
- 検証環境で確認したものと、公開するものが同じ内容か
- 今回の変更点の一覧を受け取り、内容を把握しているか
- 検収で「公開前に直す」とした項目がすべて反映されているか
- テスト用のデータや表示が残っていないか
3. 設定と外部サービスの切り替え
本番の公開でつまずきやすいのが設定です。プログラムそのものは正しくても、検証用の設定のまま公開してしまうと、メールが届かない、決済が動かない、といった問題が起こります。しかも、こうした問題は公開直後には気づきにくく、利用者からの問い合わせで発覚することが多いものです。特にお金と個人情報に関わる部分は、担当者が声に出して一つずつ読み合わせるくらいの確認が見合います。
- 決済が本番の設定になっているか（テスト用の設定が残っていないか）
- メールの差出人・返信先・文面が本番のものか
- 外部サービスの鍵やアカウントが本番用のものか
- 独自ドメインで表示され、通信が暗号化されているか（証明書の有効期限も確認）
- 検索エンジンに登録されない設定が、検証用のまま残っていないか
4. 戻す手順を先に確認する
問題が起きたときに元に戻せるかどうかは、公開の前に確認しておくべき事柄です。作業を始めてから「戻せません」と分かるのが最も避けたい展開です。データベースの構造を変える場合など、単純には戻せない変更が含まれることもあります。その場合は、戻せないという事実を事前に把握したうえで、確認の手順を厚くし、より慎重に進めてください。直前のバックアップの取得時刻を記録しておくことも忘れずに。
- 公開直前のバックアップを取得したか（取得時刻を記録する）
- 元に戻す手順と、所要時間を確認したか
- 戻すと失われるもの（公開後に入ったデータなど）があるか
- 戻せない変更が含まれる場合、その内容と代替の対処
- 戻す判断をする基準（何分たっても復旧しなければ戻す、など）
5. 公開直後に確認する項目
公開してすぐ、あらかじめ決めておいた項目を順に確認します。開発側の確認とは別に、発注側も自分の手で触ってください。開発者の環境は、過去に保存された表示内容やログイン状態の影響を受けやすく、初めて訪れる利用者と同じ見え方をしているとは限らないためです。可能であれば、普段その作業に関わっていない人にも一度触ってもらうと、見落としが減ります。
- トップページと主要な画面が正しく表示されるか
- 新規登録から主要な操作までを、実際に一度通す
- 自動メールが実際に届くか
- 決済が本番として正しく通るか（少額で実際に試す方法も検討する）
- スマートフォンからも同じ確認をする
- エラーの通知や監視の画面に、異常が出ていないか
6. 公開後しばらく見るもの
直後の確認で問題がなくても、時間が経ってから表面化する問題があります。利用者が増えたときの表示の遅さ、夜間に動く定期処理の失敗、意図しない通知の大量送信などです。これらは公開から数時間、あるいは翌日になって初めて現れます。公開後の一定期間は、誰かが定期的に様子を見る時間を業務として確保してください。見る項目を決めておけば、専門の知識がなくても異常には気づけます。
- アクセスが増える時間帯に、表示が遅くなっていないか
- エラーの通知が普段より増えていないか
- 問い合わせの内容に、公開に関係するものが混ざっていないか
- 定期的に動く処理（集計、通知など）が最初の実行で成功したか
- サーバーの利用状況が想定の範囲に収まっているか
7. 関係者への周知
システムが正しく動いても、社内がその変更を知らなければ運用は回りません。問い合わせを受ける人、営業の担当者、運営の担当者に、何がどう変わるかを公開前に伝えてください。特に問い合わせ対応の担当者が新しい画面を一度も見ていない状態は、公開後の混乱につながります。利用者への案内が必要な変更であれば、文面を用意し、公開のタイミングに合わせて出せるよう準備しておきます。
- 社内の関係者に、変更点と影響を事前に伝えたか
- 問い合わせ対応の担当者が、新しい画面を触ったことがあるか
- 利用者への案内が必要な変更か。必要なら文面を準備したか
- 操作方法が変わる場合、案内やヘルプの記載を更新したか
8. 記録に残す
公開のたびに記録を残しておくと、後から「いつから挙動が変わったか」を調べるのが容易になります。障害が起きたときの調査でも、直前にどんな公開があったかは最初に確認される情報です。形式は簡素で構いません。日時、公開した内容、作業した人、気づいた点が残っていれば十分に役立ちます。回を重ねるほど、この記録自体が自社の手順書として育っていきます。
- 公開した日時と、作業を行った人
- 公開した内容（変更点の一覧へのリンクで可）
- 当日に起きた問題と、その対処
- 次回に向けて改善する点（手順の抜け、時間の見積り違いなど）
関連するインサイト
- アジャイル開発と契約 — 準委任で進める場合の合意事項アジャイル開発と請負契約の相性、準委任契約で進める理由、目的とスコープ・体制・検収・変更・知的財産権・中途終了など事前に合意すべき事項と発注側の責務を、発注者の視点で整理します。
- コンテナとクラウドの活用 — 小規模チームでの現実的な構成コンテナで環境差を解消し、マネージド実行環境・サーバーレス・PaaSから小規模チームに合う構成を選ぶ判断軸を整理します。IaCとCI/CD、監視・ログ・バックアップ、コスト管理まで実務の要点を解説します。
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開