コンテンツにスキップ
Webディレクター・PMのためのモダンWeb制作入門

第6部まとめ

第32講 / 全32講読了目安 約45分

このページで学ぶこと

Section titled “このページで学ぶこと”
  • 変更管理から公開・監視・改善までのつながり
  • Git、CI/CD、監視、SEOが別々の技術ではなく、一つの運用サイクルを作ること
  • 公開・移行時のリスクと責任を管理する方法
  • 保守・改善へ知識と判断を引き継ぐ方法
  • 本書全体の知識を実案件で使うための確認事項

まず全体像

Section titled “まず全体像”

Webサイトは、作って公開する一方向の成果物ではありません。

flowchart LR
    R[要件・改善] --> G[Gitで変更管理]
    G --> C[CIで検査・統合]
    C --> D[承認・デプロイ]
    D --> M[監視・利用データ]
    M --> I[障害対応・分析]
    I --> S[SEO・品質・運用改善]
    S --> R

第6部では、この循環を支える仕組みを学びました。

  • Git：変更の目的・差分・承認を追跡する
  • CI/CD：変更を再現可能な手順で検査・公開する
  • 運用：利用者・システム・業務を観測し、障害・変化へ対応する
  • 技術SEO：検索エンジンが重要ページを発見・解釈できる状態を保つ
  • 移行：既存URL・データ・計測・運用を新環境へ安全に引き継ぐ

第6部で学んだ判断軸

Section titled “第6部で学んだ判断軸”

変更を追跡できるか

Section titled “変更を追跡できるか”
  • 課題
  • ブランチ
  • コミット
  • Pull Request
  • テスト
  • 承認
  • リリース

がつながっているか確認します。

公開を再現できるか

Section titled “公開を再現できるか”
  • 依存バージョン
  • ビルド
  • 成果物
  • 環境変数
  • 承認
  • デプロイ
  • スモークテスト

を、特定担当者の記憶に依存させません。

問題を検知・判断できるか

Section titled “問題を検知・判断できるか”
  • 主要フロー
  • エラー
  • 性能
  • 容量
  • 業務件数
  • セキュリティ
  • 外部サービス

を観測し、行動可能なアラートへします。

元へ戻す・先へ直すことができるか

Section titled “元へ戻す・先へ直すことができるか”
  • ソース
  • CMS
  • DB
  • DNS
  • キャッシュ
  • 外部処理

を含め、ロールバック・ロールフォワードを判断します。

URL・検索・外部参照を引き継げるか

Section titled “URL・検索・外部参照を引き継げるか”
  • 旧新URL
  • リダイレクト
  • canonical
  • 内部リンク
  • サイトマップ
  • Search Console
  • 計測

を整合させます。

公開後も維持できるか

Section titled “公開後も維持できるか”
  • アップデート
  • 権限
  • 証明書
  • 契約
  • バックアップ
  • ログ
  • コンテンツ
  • アクセシビリティ
  • SEO

を保守範囲へ含めます。

Webサイトのライフサイクル

Section titled “Webサイトのライフサイクル”
flowchart TD
    A[企画・要件] --> B[設計・開発]
    B --> C[レビュー・テスト]
    C --> D[公開]
    D --> E[監視・運用]
    E --> F[分析・改善]
    F --> B
    E --> G[障害・外部変化]
    G --> H[復旧・更新]
    H --> E

各工程は前の工程と切り離せません。

  • 公開方法は設計時に決める
  • 監視項目は要件・業務フローから決める
  • ロールバックはデータ設計へ影響する
  • SEO移行はURL・CMS設計へ影響する
  • 保守費用は採用技術・外部サービスで決まる

見積・スケジュールの最後に「保守・公開」を足すのではなく、初期計画へ組み込みます。

ケーススタディ1：コーポレートサイトの定期改修

Section titled “ケーススタディ1：コーポレートサイトの定期改修”

変更

Section titled “変更”
  • サービスページ追加
  • CMS項目追加
  • ナビゲーション変更
  • 旧ページ統合

流れ

Section titled “流れ”
flowchart LR
    I[課題・URL設計] --> B[作業ブランチ]
    B --> P[Pull Request・プレビュー]
    P --> T[テスト・リンク・SEO確認]
    T --> A[承認]
    A --> D[デプロイ]
    D --> M[404・検索・計測監視]

PMが確認すること

Section titled “PMが確認すること”
  • 新旧URL
  • CMS互換性
  • リダイレクト
  • title・内部リンク
  • アクセシビリティ
  • 公開順序
  • キャッシュ
  • Search Console
  • 既知制約

小さな改修でも、URL・CMS・共通ナビゲーションは広範囲へ影響します。

ケーススタディ2：緊急障害対応

Section titled “ケーススタディ2：緊急障害対応”

状況

Section titled “状況”

問い合わせAPIの変更後、送信成功画面は出るがCRMへ登録されていません。

対応

Section titled “対応”
  1. インシデント宣言・影響確認
  2. 新規送信の案内・一時停止
  3. デプロイ版・APIログを確認
  4. 旧版へ戻せるか判断
  5. 未登録データを特定・再処理
  6. 利用者・クライアントへ報告
  7. 修正版公開
  8. ポストモーテム
  9. 部分成功の監視・テスト追加

Gitの切戻しだけでは、送信済みデータの整合は戻りません。

技術・業務・連絡を一つの対応として扱います。

ケーススタディ3：ドメイン変更を伴う統合

Section titled “ケーススタディ3：ドメイン変更を伴う統合”

条件

Section titled “条件”
  • 二つのブランドサイトを一つへ統合
  • URL・CMS・デザイン変更
  • 広告・メール・QRが旧URLを利用
  • 検索流入が大きい

必要なもの

Section titled “必要なもの”
  • 両サイトの全URL棚卸し
  • 維持・統合・削除判断
  • 旧新URL対応
  • 直接301
  • 新canonical・内部リンク
  • 多言語・PDF・画像
  • Search Console所有
  • 広告・外部設定
  • 旧ドメイン維持
  • 公開後404・検索流入監視
  • コンテンツ統合の効果確認

新しい情報設計だけでなく、旧サイト利用者を目的地へ導く移行設計が重要です。

ケーススタディ4：静的サイトの保守契約

Section titled “ケーススタディ4：静的サイトの保守契約”

誤解

Section titled “誤解”

サーバーレスで静的配信だから、保守は不要。

実際に残るもの

Section titled “実際に残るもの”
  • Git・CI/CD
  • Node.js・依存パッケージ
  • CMS・API
  • ビルド・Webhook
  • CDN・DNS
  • 外部フォーム
  • 証明書・契約
  • 監視・ログ
  • SEO・リンク
  • コンテンツ・アクセシビリティ

OS・Webサーバーの管理は減っても、保守対象はなくなりません。

構成に合う軽量な保守へ再定義します。

変更から公開までの最小テンプレート

Section titled “変更から公開までの最小テンプレート”

変更前

Section titled “変更前”
  • 目的
  • 影響範囲
  • URL・データ・権限
  • 確認方法
  • 公開方法
  • 切戻し
  • 監視

Pull Request

Section titled “Pull Request”
  • 差分
  • プレビュー
  • テスト結果
  • スクリーンショット
  • 既知制約
  • リリース注意

公開前

Section titled “公開前”
  • 必須チェック
  • 成果物
  • 承認
  • バックアップ
  • 外部連絡
  • 公開時間

公開後

Section titled “公開後”
  • スモークテスト
  • エラー・性能
  • 主要フロー
  • 計測
  • Search Console
  • 連絡
  • 残課題

保守契約の最小テンプレート

Section titled “保守契約の最小テンプレート”
項目決めること
対象サイト、CMS、API、クラウド、外部サービス
受付時間、窓口、緊急度
監視URL、主要フロー、ログ、アラート
更新CMS、ランタイム、依存物、証明書
バックアップ対象、RPO、RTO、復元
障害一次切り分け、復旧、外部問い合わせ
セキュリティ脆弱性、権限、インシデント
品質リンク、性能、アクセシビリティ、SEO
報告月次、障害、変更
費用固定、時間枠、緊急、別見積
終了データ、ソース、権限、引継ぎ

「何でも対応」ではなく、対応可能な時間・技術・契約を明確にします。

PMが技術提案をレビューする質問

Section titled “PMが技術提案をレビューする質問”

Git

Section titled “Git”
  • 変更と要件を追跡できるか
  • 本番ブランチを誰が変更できるか
  • 緊急修正はどうするか

CI/CD

Section titled “CI/CD”
  • 何を自動検査するか
  • 検証した成果物と本番が同じか
  • 失敗・同時実行・シークレットをどう管理するか
  • 何分で戻せるか

運用

Section titled “運用”
  • 何が使えないと重大か
  • 誰がどう検知するか
  • 夜間に誰が何をするか
  • RPO・RTOは何か

SEO

Section titled “SEO”
  • 重要URLをどう発見・取得できるか
  • URLの状態をHTTPで正しく返すか
  • JavaScriptなし・失敗時に主要内容はどうなるか
  • Search Consoleを誰が見るか

移行

Section titled “移行”
  • 旧URL・データ・計測をどう引き継ぐか
  • 公開前に全件検査できるか
  • 公開後に何を何週間見るか
  • 旧環境をいつ止めるか

本書全体とのつながり

Section titled “本書全体とのつながり”

第1部 Webの仕組み

Section titled “第1部 Webの仕組み”

DNS・HTTP・HTTPSを理解すると、公開切替・ステータス・証明書障害を判断できます。

第2部 インフラ

Section titled “第2部 インフラ”

クラウド・CDN・責任分界を理解すると、監視・保守・外部障害の担当を決められます。

第3部 フロントエンド

Section titled “第3部 フロントエンド”

レンダリング・ビルドを理解すると、CI/CD、JavaScript SEO、ロールバックを設計できます。

第4部 API・CMS

Section titled “第4部 API・CMS”

API制限・CMS公開フローを理解すると、Webhook監視・部分失敗・移行を設計できます。

第5部 品質

Section titled “第5部 品質”

セキュリティ・テスト・アクセシビリティを、必須チェック・監視・継続改善へ組み込めます。

第6部は、それまでの知識を公開後まで持続させる章です。

PMチェックリスト

Section titled “PMチェックリスト”
  • 変更目的からコミット・Pull Request・リリースまで追跡できる
  • 小さな変更を頻繁に統合し、自動検査で早く問題を見つけている
  • 検証済み成果物、承認、本番デプロイの経路を図示している
  • シークレット、環境、同時実行、外部Actionを管理している
  • ソース・CMS・DB・DNSを含む切戻し・修正版公開を計画している
  • 利用者フロー・システム・業務の監視とSLOを決めている
  • アラート、重大度、指揮、連絡、Runbook、事後検証を用意している
  • バックアップ、RPO、RTO、アップデート、期限・容量を保守している
  • 重要URL、内部リンク、ステータス、canonical、robots、サイトマップを管理している
  • JavaScript、モバイル、多言語、構造化データを最終HTML・応答で確認している
  • 旧新URL対応、差分移行、DNS、計測、Search Consoleを移行計画へ含めている
  • 公開直後・数週間の監視と旧環境停止条件を決めている
  • 保守範囲、受付時間、費用、対象外、契約終了時の引継ぎを明記している
  • 本書の付録チェックリストを案件条件に合わせて更新している

よくある誤解・失敗

Section titled “よくある誤解・失敗”

「公開作業は開発の最後の一日」

Section titled “「公開作業は開発の最後の一日」”

Git・CI/CD・移行・監視・切戻しは、要件・設計段階から準備する必要があります。

「自動化すると担当者が不要になる」

Section titled “「自動化すると担当者が不要になる」”

自動化は再現・検知を支援しますが、事業判断、例外、障害指揮、外部連絡の責任は残ります。

「運用は現状維持」

Section titled “「運用は現状維持」”

ブラウザ、依存物、API、検索、利用者、法令、コンテンツが変化するため、更新・改善が必要です。

「SEOは公開後に専門会社へ任せる」

Section titled “「SEOは公開後に専門会社へ任せる」”

URL、HTML、ステータス、JavaScript、移行は制作・開発時に決まります。コンテンツ・マーケティングと技術を連携します。

「リニューアル公開で案件は完了」

Section titled “「リニューアル公開で案件は完了」”

安定化、検索・計測監視、残課題、旧環境停止、引継ぎまでを完了条件にします。

理解度チェック

Section titled “理解度チェック”

Q1. Git、CI/CD、監視の関係を説明してください。

Section titled “Q1. Git、CI/CD、監視の関係を説明してください。”
回答と解説 Gitで変更と承認を追跡し、CI/CDで同じ手順の検査・公開を行い、監視で本番の結果を確認して次の修正へフィードバックします。

Q2. 公開可能な成果物を毎回同じ条件で作るために何を管理しますか。

Section titled “Q2. 公開可能な成果物を毎回同じ条件で作るために何を管理しますか。”
回答と解説 ソース、依存バージョン、ロックファイル、ランタイム、ビルドコマンド、環境変数、実行環境、外部データ、成果物を管理します。

Q3. Webサイトの可用性をトップページ監視だけで判断できない理由は何ですか。

Section titled “Q3. Webサイトの可用性をトップページ監視だけで判断できない理由は何ですか。”
回答と解説 検索、ログイン、フォーム、予約等の主要機能や業務連携が失敗していても、トップページだけは200を返す場合があるためです。

Q4. 技術SEOとサイト移行が密接に関係する理由は何ですか。

Section titled “Q4. 技術SEOとサイト移行が密接に関係する理由は何ですか。”
回答と解説 移行でURL、HTTPステータス、内部リンク、canonical、サイトマップ、内容、JavaScriptが変わり、検索エンジンの発見・理解・評価の引継ぎへ直接影響するためです。

Q5. Webサイトの保守対象を決めるとき、サーバー以外に何を含めますか。

Section titled “Q5. Webサイトの保守対象を決めるとき、サーバー以外に何を含めますか。”
回答と解説 CMS、API、フロント・依存物、Git・CI/CD、DNS・CDN、外部フォーム、証明書・契約、ログ・監視、コンテンツ、SEO、アクセシビリティ等です。

この教科書を読み終えたら

Section titled “この教科書を読み終えたら”

すべての技術を自分で実装できる必要はありません。

Webディレクター・PMとして重要なのは、

  1. 構成とデータの流れを図示する
  2. 技術が解決する課題と増やす責任を理解する
  3. 未確定事項を質問に変える
  4. 担当・費用・期限・障害時の動きを決める
  5. 利用者と事業への影響で優先順位を判断する
  6. 公開後まで結果を追う

ことです。

技術用語を知ることを目的にせず、案件の判断・説明・合意形成へ使ってください。

参考資料

Section titled “参考資料”