ECサイト制作・構築

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

ECサイト制作・構築

「いつ何を決め、誰がどこまで担当するのか」が曖昧なまま始めると、納期も品質もぶれやすくなります。結論は、工程ごとの成果物（完了条件）を先に合意し、性能（ページ速度）と法対応をスケジュールに組み込むこと。この記事では、標準スケジュール表／フェーズ別タスク／遅延の芽の潰し方まで、現場でそのまま使える型をお渡しします。

全体像：標準スケジュールと工程の関係

最初に“地図”を共有すると意思決定が速くなります。本記事は要件→設計→デザイン→実装→計測・法対応→移行→テスト→公開準備→公開の順で進めます。各フェーズの成果物と完了条件（Exit Criteria）を先に決めると、追加要件が出ても調整点が明瞭。小規模〜中規模の期間目安も表で示し、着地までの見通しを立てやすくします。

標準スケジュール（目安）

フェーズ 小規模 中規模 主な成果物
企画・要件定義 2–3週 4–6週 要件定義書、KPI、WBS
情報設計/ワイヤー 2–3週 4–6週 画面一覧、ワイヤー、計測設計草案
デザイン 3–4週 6–8週 デザイン一式、UIガイド
実装（FE/BE） 4–6週 8–12週 テンプレ/機能、API、単体・結合試験
計測・法対応・非機能 1–2週 2–4週 GA4実装、最終確認画面、性能予算
移行・外部連携 2–3週 4–6週 移行計画/試行、連携試験
総合/受入テスト 2–3週 4–6週 シナリオ・UAT記録、修正完了票
公開準備・リハーサル 1週 2週 切替手順、ロールバック計画
公開（ハイパーケア） 1–2週 2–3週 監視・是正対応ログ

企画・要件定義：目的・KPI・範囲を固める

ここで目的・KPI・対象範囲を明確にし、以降の工程と見積の“物差し”を作ります。機能要件（Must/Should）に加えて非機能＝性能（ページ速度）と法対応を数値・画面レベルで要件化しておくと、後工程の手戻りが激減。検収基準やWBSもこの段で合意します。

やること

  • 事業目標・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

情報設計／ワイヤー：ナビと画面の骨格を確定

IAとワイヤーは、UI/UXと開発見積の共通土台。回遊導線・検索導線・購入導線を決め、ページ粒度を決定します。並行して計測設計の草案（GA4の推奨イベント）を作ると後戻りが減少。画面レベルでイベント名まで先に決めておくのがコツです。

やること

  • サイトマップ、ファセット（絞り込み）設計、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コンポーネントとデザインルール（スタイルガイド）を整えるのが肝。公開後の更新速度とA/Bテストの回転率が変わります。ボタンの状態やフォームのエラー表示、読みやすいコントラストなど基本的な視認性・わかりやすさは、この段でルール化しておきましょう。

やること

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

成果物

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

実装（フロント/バック）：手戻りを抑える進め方

実装は重要ページ→横展開の順で“見せる→広げる”。バックエンドは会員・在庫・決済・配送などコア領域を先行し、API契約を固めます。

やること

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

成果物

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

計測・法対応・性能（ページ速度/セキュリティ）

計測（GA4）・特商法の最終確認画面・ページ速度は“あとで”にすると火種になりがち。性能予算（Performance Budget）やCWVの具体値を工程に埋め込み、最終確認画面の文言・表示は設計段階で原稿まで作っておきます。セキュリティは決済や管理画面の基本対策を運用設計と併せて決めます。

やること

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

成果物

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

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

データ移行・外部連携：失敗率の高い山場

移行は件数×難易度で工数が跳ねます。まず試行移行（PoC）で“汚れ”を把握し、変換ルールとリダイレクト表を確定。連携は責任分界と試験手順を明記しましょう。

やること

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

成果物

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

テスト（総合/受入/UAT/性能）：合否の線を先に引く

テストは“作る”と同じくらい“定義する”が大事。UATの合格基準、端末/ブラウザの対象表、性能の合否ライン（CWV）を先に引き、リグレッションはチェックリストで反復します。フォームのエラー案内や代替テキストなど基本的な使いやすさも併せて点検しましょう。

試験観点

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

成果物

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

公開準備・ローンチ：切替手順とロールバック

公開前はリハーサル（ステージ→本番）を行い、DNS/キャッシュ/検索インデックス/計測/タグ/リダイレクトの切替手順を時系列で確認します。ロールバック計画と連絡体制、ハイパーケア期間の対応ルールまでセットで定義すると、当日の混乱を最小化できます。

やること

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

成果物

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

よくある落とし穴と先回りの解決策

スケジュール崩れの多くは定義不足と前提差が原因です。成果物ベースの完了条件、性能の数値化（CWV）、連携・移行の早期PoCで“後半の遅延”を止めます。性能予算と特商法の最終確認画面は必ず前倒しに。

典型例と対処

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

フェーズ横断チェックリスト（保存版）

“何となく不安”を消すには、同じ定点を毎回確認するのが早道。依頼前／進行中／公開直前の3段でポイントをチェックリスト化しました。プロジェクト規模に合わせて増減し、社内稟議やベンダー共有でも使い回してください。

依頼前

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

進行中

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

公開直前

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

よくある質問（FAQ）

Q1：企画〜公開までの“ふつう”の期間は？

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

Q2：GA4のイベントは独自命名でもいい？

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

Q3：公開当日のリスクを最小化するポイントは？

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

まとめ

最短距離で公開する鍵は、成果物ベースの完了条件と性能（CWV）の数値化、そして早期の移行/連携PoCです。スプリントを短く刻み、性能予算と特商法の最終確認画面を前倒しで設計すれば、納期と品質は安定します。

大阪でECサイトの構築やリニューアルをご検討の方は、ぜひ一度ご相談ください。
無料相談はこちらから
関連サービス：大阪のECサイト制作・構築

この記事を書いた人

digrart編集部

大阪市中央区のweb制作会社のメンバーが、Webサイト制作、ECサイト構築、SEO対策、Webコンサルティングの最新情報や実践的なハウツーをお届けします。初心者からプロまで役立つノウハウや業界トレンドを分かりやすく解説。web戦略の成功をサポートするための情報が満載です！

関連記事

ブログ一覧に戻る