ECサイト制作の進め方｜企画〜公開までのスケジュール設計

• 事業目標・KPI（売上、CVR、AOV、LTV）
• 機能要件（会員・検索・カート・定期購入など）
• 性能KPI：Core Web Vitals（LCP/INP/CLS）の目標（後述）
• 法対応の範囲化（特商法の最終確認画面、規約類）
• スコープ/除外、体制、WBS、検収条件

• 要件定義書、画面一覧、KPIシート、WBS

Core Web Vitals は一般的に LCP≤2.5s / INP≤200ms / CLS≤0.1 が良好の目安。INPは2024年にFIDの後継として正式採用されました。75パーセンタイルの実測で満たすことが推奨されています。
参考：https://web.dev/articles/defining-core-web-vitals-thresholds?hl=ja

• サイトマップ、ファセット（絞り込み）設計、SKU/バリエーション表現
• 主要画面ワイヤー（トップ/商品/カート/チェックアウト）
• 計測設計草案（view_item, add_to_cart, begin_checkout, purchase など）

• 画面一覧、ワイヤーフレーム、イベント一覧表

ECの推奨イベントはGA4公式ドキュメントで整備されています。標準名を採用するとレポート互換が高く、分析が安定します
参考：https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja&client_type=gtag

• デザイン一式（トップ/下層/商品/カート/会員）
• UIガイド（色・タイポ・余白・コンポーネントの使い方）
• 画像切り出し規約（比率/解像度/軽量化方針）

• デザインカンプ、UIガイド、コンポーネント一覧

• FE：基礎テンプレ → 重要ページ → モジュール横展開
• BE：ドメイン分割、API契約（OpenAPI）と結合試験

• テンプレ/機能、API仕様、単体・結合試験記録

• GA4実装（推奨イベント／拡張計測）
• 性能予算（総転送量、JS/画像上限、LCP/INP/CLS 目標）
• 特商法：申込直前画面の表示・ボタン文言・訂正機会の提供（原稿化）

• 計測タグ、性能計測レポート、最終確認画面原稿

CWVの各指標の定義や最新の扱い（INPの正式採用）も公式記事で確認できます。施策の優先度付けの根拠に有効です。
参考：https://web.dev/articles/lcp?hl=ja

• 商品/顧客/注文/レビューの抽出→整形→投入→差分移行
• URL変更時の301リダイレクト設計とリスト作成
• 決済・WMS/POS・会計・MA/CRMの連携試験（誰が/何を/いつ）

• 変換仕様、移行スクリプト、リダイレクトリスト、連携試験記録

• 機能：カート/決済/返品、B2Bは見積〜承認
• 端末/ブラウザ網羅（対象表を事前合意）
• 性能：LCP/INP/CLSの計測と是正サイクル
• ユーザビリティ：フォームエラー表示、代替テキストの有無など

• テスト計画/シナリオ、UAT記録、是正完了票

• リハーサル実施（チェックリスト順）／最終の速度計測
• DNS切替、301適用、サイトマップ送信、GA4/タグの本番有効化
• アラート監視と初動対応（エラーレート/売上監視）

• 切替Runbook、ロールバック手順、連絡網、初動ログ

• デザイン修正が長期化 → UIガイドと修正回数の合意
• 連携が詰まる → 役割分界・テスト手順の早期合意
• 速度劣化 → 性能予算・画像/JSポリシーで抑制
• 法対応の後回し → 申込直前画面の原稿を先出し

• KPI・機能・性能（LCP/INP/CLS目標）を要件化
• 画面一覧・イベント一覧（GA4の推奨イベント採用）
• 成果物・検収条件・WBSの合意

• UIガイド／修正回数の合意
• 性能予算と最終確認画面の原稿作成

• UAT合格、端末/ブラウザ表クリア
• リダイレクト・サイトマップ・GA4本番切替
• Runbook/ロールバック手順・連絡網

A. 中規模なら4〜6か月が目安。要件の明確さと移行の難易度で上下します。

A. できますが、ECは推奨イベント名を使う方がレポート互換が高いです。

A. 事前リハーサル、Runbookとロールバック計画、そして初動監視（エラー/売上アラート）。この3点を固めると事故が起きても被害を局所化できます。