4年ほど前のプロジェクトの話ですが、自身の棚卸しのために思い出しながら書いておきます。
ドメイン移行とサーバー移行にあたり各工程で対応したことや、気をつけたことを主に書いていきます。
役割としてはプロジェクトリーダーを担当していました。
ベンチャー企業でリソースも限られているため、いかに最短・最小コストで達成するかを重視しプロジェクトを進めていきました。
背景
アフィリエイトサイトを運営していてSEO改善の施策の一環としてドメインを変更することになりました。
また、話し合いの結果サーバー移行もあわせて行うこととなりました。
ドメイン移行の背景の話
- 移行前のサイトURL
https://aaa-service.com/media
- 移行後のサイトURL
https://media.aaa-service.com
SEOはドメインに対してコンテンツの種類を判断しています。
aaa-service.comは別の事業のドメインでコンテンツの種類も違います。
移行前のサイトURLでは、同じドメインの中にある同じサイトと判断されてしまいドメインが持つコンテンツのパワーが分散してしまいます。
というわけで、サブドメインを作りドメインを分けることで別のドメインの別のサイトとして認識するように対応することになりました。
新規のドメインを採用しなかったのは、それぞれの事業は親和性があり相互にSEOのパワーを支え合っていけると考えました。
また、ページが持つSEOパワーを引き継ぐために、各ページの301リダイレクトも対応していきます。
サーバー移行の背景の話
ミドルウェアのバージョンが古くSEO改善の施策のひとつにあがっていました。
また、メディア事業という特性上アクセスが多いのと、サービス開始から5年以上経過していてサーバーのスペックも不足し始めていました。
別の事業のサーバー上にプログラムが置かれていたため、サーバーの障害発生やミドルウェアレベルで影響するためバージョンアップがやりづらいといった課題もありました。
これらを踏まえてサーバー移行も合わせて行うこととなりました。
また、サーバー監視や保守は外部の代行会社を利用していたため移行にあたり連携や費用も意識する必要がありました。
移行の流れ
移行のざっくりとした流れ
- 要件定義フェーズ
- プロジェクトの合意形成をする
- 設計フェーズ
- 移行方針に関する合意形成をする
- 開発フェーズ
- 本番環境を構築する
- テストフェーズ
- 問題ないことを確認する
- リリースフェーズ
- 問題ないことを確認する
- 運用フェーズ
- 大きな機会損失がない限り、バグを潰しまくる
各工程での成果物や実施したこと
要件定義
要件定義にあたって対応したこと
プロジェクト憲章の作成
- 目的
- 何のためにやるのか
- 背景
- なぜ目的を達成する必要があるのか、現在の課題
- 成果物
- なにをもってプロジェクト完了とするのか、完了とする条件
- 対応範囲
- 対応する範囲だけでなく対応しない範囲も明確にしておく
- ステークホルダー
- 相談や連携する組織または部門の担当者
- 予算
- 簡易的な工数見積、費用見積
- 3案ぐらいを作業内容・メリット・デメリットでまとめると尚良い
- スケジュール
- 各工程（要件定義〜リリース）の期間
- 体制図
- 工程に関わるメンバーと役割
- コミュニケーション計画
- 進捗や社内レビューなど各種MTGの実施タイミング、頻度、参加対象者
上長との合意形成
- ミーティングの日程調整
- ステークホルダー含めプロジェクトに関わる人が対象
設計
システム移行計画書
- 概要
- 詳細、影響範囲
- システム構成図をAs-Is/To-Beで記載するとわかりやすい
- リリース日、予備日
- 最も売上影響が少ない時間帯を確認しておく
- サーバー仕様
- 利用サービス、OS、CPU、メモリ、HDD、ミドルウェアやパッケージのバージョンなど記載する
- 費用
- ドメイン、SSL証明、サーバー、保守代行会社など
- WBS、ガントチャート、工数見積
全体テスト計画書
- 目的
- 各テストの実施有無、観点、対象範囲、方法（利用するツール）、実施環境
社内レビュー
上長との合意形成
- 特に費用とリリース日
ワークフロー申請
開発
サーバー環境構築
- サブドメイン発行、SSL対応、DNS登録
マーケティングサービスの登録情報修正
- Google Search Console,Google Analyticsなど
代理店の対応
- マーケとやり取りし代理店、広告の抜け漏れないか
- アフィタグ埋め込み
社内、社外のステークホルダーへの連絡
- 社内
- CSへメンテ日時の告知依頼、マーケへ受入テスト依頼、ライターへ記事更新停止依頼など
- 社外
- アフィリエイト代理店、運用代行業者等
単体テスト計画書の作成
- 観点：WEBサイトが正常に動作しているか手動でテストする
- 実施者：エンジニア部門
結合テスト計画書の作成
- 観点：現環境から本番環境へトップ、記事、カテゴリページなどのリダイレクトが正しいか確認する
- 実施者：エンジニア部門
受入テスト計画書の作成
- 観点：部署や関連ステークホルダに影響する機能を確認する
- 実施者：部署や関連ステークホルダの担当者
リハーサルテスト仕様書の作成
リリース計画兼手順書のリリース手順のベースとなる資料
- 概要
- リリース手順
- ロールバック手順
リリース計画兼手順書の作成
- 概要
- リリース日時、予備日時
- 時間は余裕を持って設定する
- 担当者、役割、緊急連絡先
- リリース作業前開始チェックリスト
- 緊急連絡先の不足がないか、正常稼働しているか、クロスチェック担当がいる等
- リリース手順
- 前作業（メンテナンス、バックアップ等）、本作業、後作業（動作確認等）
- リリース作業完了チェックリスト
- 作業ログ取得、DNS切り替え、ステークホルダーへ連絡等
- ロールバック手順
- 実施基準、前作業（メンテナンス等）、本作業、後作業（動作確認等）
- ロールバック作業完了チェックリスト
- 問題発生時の対応方針
テスト
単体テスト仕様書兼結果報告書の作成
結合テスト仕様書兼結果報告書の作成
結合テスト仕様書兼結果報告書の作成
- 概要
- 観点
- 環境
- テスト項目
- No、区分、手順、期待動作、結果、日付、担当者
リハーサルテストの実施
- 本番を想定して検証環境でリリース手順を実行していきます。
- ここで発生した問題があれば、手順書やプログラムを適宜修正していきます。
リリース
リリース計画兼手順書の実施
- リリース作業前開始チェックリストで条件を満たしているか確認する
- リリース手順を実施する
- 問題発生時の対応方針に従って適宜対応していく
- ロールバック手順の実施基準に従って適宜対応していく
- リリースまたはロールバック作業完了チェックリストを確認する
運用
1. バグチケット管理
バグが発生した場合はチケットに起票してもらい、対応ログを残しておく。