Webサイトリニューアルのスケジュール感と工程管理のコツ|期間・ガントチャート例

監修者 河上 智哉

目次

Webサイトリニューアルを検討するとき、「公開まで何ヶ月かかるのか」「社内ではいつ、何を準備すればよいのか」は早いタイミングで確認したい項目です。
UXデザインの設計力と、ブランド構築支援の表現力の高さを強みにするWeb制作会社株式会社デパートがまとめました。規模別の期間の目安と、ガントチャートを使った工程管理のポイントを解説します。

この記事でわかること

Webサイトリニューアルの期間を見積もり、社内と制作会社でスケジュールを管理するために必要な判断材料を整理しています。

  • Webサイトリニューアルにかかる期間の目安

  • スケジュールを左右する条件と遅れやすい工程

  • リニューアルの工程をガントチャートに整理する方法

  • 発注側と制作会社で管理すべきタスクの違い

  • 希望する公開日に向けて事前に確認すべきこと

希望する公開時期は決まっているものの、必要な工程や期間を判断できない場合は、株式会社デパートへご相談ください。

目次

Webサイトリニューアルにはどのくらいの期間がかかる?

Webサイトリニューアルの期間は、デザインや実装にかかる日数だけでは決まりません。既存サイトの調査、社内での合意形成、原稿や画像の準備、CMSへのデータ移行、公開前のテストなども必要です。

特にスケジュールへ影響しやすいのは、次の3点です。

  • どこまでリニューアルするのか決まっているか

  • 誰が、いつまでに確認・承認するのか決まっているか

  • 原稿作成やコンテンツ移行の作業量を把握できているか

ページ数が少なくても、目的や要件を途中で見直したり、社内承認に時間がかかったりすれば、公開時期は遅れます。反対に、関係者と判断期限が明確で、必要な素材が早く揃えば、各工程を並行して進めやすくなります。

そのため、スケジュールを立てるときは、制作会社の作業だけでなく、発注側が担当する準備・確認・承認も一つの工程として扱うことが必要です。

サイトリニューアルの目的設定や進め方の全体像については、「Webサイトリニューアル完全ガイド」で解説しています。

規模別に見るWebサイトリニューアルの期間目安

Webサイトリニューアルの期間は、小規模サイトで2〜3ヶ月、中規模サイトで4〜6ヶ月、大規模サイトでは8ヶ月〜1年以上が一つの目安です。

横にスクロールできます

規模

サイトの例

期間の目安

小規模

10ページ程度、機能が限定的なサイト

2〜3ヶ月

中規模

30〜100ページ程度、CMSやフォームを含むコーポレートサイト

4〜6ヶ月

大規模

100ページ以上、複数部署・多言語・CMS移行を含むサイト

8ヶ月〜1年以上

ただし、ページ数だけで期間を判断することはできません。同じ30ページでも、既存のCMSと原稿をそのまま使う場合と、CMSを変更してコンテンツを作り直す場合では、必要な工程が異なります。

小規模サイトは2〜3ヶ月が目安

10ページ程度で、必要な機能が問い合わせフォームや更新情報などに限られる場合は、2〜3ヶ月が目安です。

既存の文章や画像を利用できれば比較的進めやすい一方、ブランドの見直し、撮影、取材、新規原稿の作成を行う場合は、ページ数が少なくても期間が延びます。

また、短期間のプロジェクトでは、一度の確認遅延が全体へ与える影響も大きくなります。誰がデザインや原稿を確認するのか、着手前に決めておく必要があります。

中規模サイトは4〜6ヶ月が目安

サービス、実績、採用情報、ニュースなど、複数種類のコンテンツを持つコーポレートサイトでは、4〜6ヶ月程度が目安です。

ページのデザインだけでなく、CMSの入力項目、フォーム、アクセス解析、SEO設定、旧URLからのリダイレクトなども設計します。原稿作成とコンテンツ移行の量が多いため、画面設計やデザインと並行して準備を進める必要があります。

複数部署が関わる場合は、部署ごとの確認期間もスケジュールに含めます。

大規模サイトは8ヶ月〜1年以上が目安

100ページ以上のコーポレートサイト、多言語サイト、複数ブランドを扱うサイトでは、8ヶ月〜1年以上かかる場合があります。

大規模サイトでは、次の作業が期間に影響します。

  • 複数部署へのヒアリングと合意形成

  • CMSやサーバーの変更

  • 大量のコンテンツ移行

  • 外部システムやデータベースとの連携

  • 多言語対応

  • アクセシビリティの検証

  • セキュリティ診断

  • 複数サイトの公開切り替え

着手時点ですべての作業量を確定できないこともあります。その場合は、既存サイトの調査と要件整理を先に行い、その結果をもとに制作期間を確定します。

Webサイトリニューアルの基本工程

リニューアルでは、新しいサイトを制作するだけでなく、既存サイトから何を引き継ぎ、何を変更するのかを決める必要があります。

横にスクロールできます

工程

主な作業

期間の目安

調査・企画

現状分析、目的・課題・対象範囲の整理

2〜4週間

要件定義

機能、CMS、運用、計測、セキュリティの整理

2〜4週間

情報設計・画面設計

サイトマップ、導線、コンテンツ構造、ワイヤーフレーム

3〜6週間

デザイン

デザイン方針、主要画面、下層画面の制作

4〜8週間

実装

フロントエンド、CMS、フォームなどの開発

6〜12週間

コンテンツ制作・移行

原稿・画像の準備、既存データの移行

4〜12週間

テスト・公開準備

表示・動作確認、リダイレクト、計測、公開作業

2〜4週間

公開後確認

不具合、フォーム、計測、検索状況の確認

1〜4週間

これらの工程はすべて順番に進める単純なロード マップではありません。情報設計が固まったページから原稿作成を始め、デザインの承認が完了した画面から実装へ進むなど、複数の作業を並行させます。

一方で、要件定義が終わらなければCMS設計を確定できないなど、前の工程が終わるまで開始できない作業もあります。工程管理では、作業期間だけでなく、タスクの前後関係を整理することが必要です。

6ヶ月で進めるガントチャートの例

ガントチャートとは、各タスクの開始日と終了日を時間軸に沿って配置し、工程の前後関係や進捗を確認するための表です。

中規模のコーポレートサイトを6ヶ月でリニューアルする場合、全体の流れは次のようになります。

横にスクロールできます

工程

1ヶ月目

2ヶ月目

3ヶ月目

4ヶ月目

5ヶ月目

6ヶ月目

調査・企画

●

要件定義

●

●

情報設計・画面設計

●

●

原稿・素材準備

●

●

●

●

デザイン

●

●

フロントエンド実装

●

●

CMS・フォーム開発

●

●

コンテンツ移行

●

●

テスト・修正

●

●

公開準備・公開

●

この表は全体の流れを示したものです。実際のガントチャートでは、各工程をさらに細かいタスクへ分けます。

たとえば「デザイン」を一つのタスクにすると、どの画面が確認中で、どこから実装を始められるのか判断できません。次のように、制作・確認・承認の単位で分解します。

  • デザイン方針の作成

  • トップページ初稿の作成

  • トップページの社内確認

  • トップページの修正

  • トップページの承認

  • 下層ページテンプレートの作成

  • 下層ページテンプレートの確認・承認

ただし、すべての細かな作業を顧客側と共有すると、全体の進捗が見えにくくなることもあります。制作チームが使う詳細なガントチャートと、発注側を含む関係者が確認する主要工程のスケジュールを分けて管理する方法もあります。

ガントチャートに入れるべき管理項目

ガントチャートには、最低限、次の項目を入れます。

  • タスク名

  • 担当者

  • 開始日

  • 完了予定日

  • 先に完了する必要があるタスク

  • 確認者と承認者

  • 確認期限

  • 現在の進捗

  • 遅延した場合に影響する工程

制作タスクと確認タスクを分ける

「ワイヤーフレーム作成:2週間」と記載するだけでは、制作会社の作業期間と発注側の確認期間を区別できません。

次のように分けることで、どこで進行が止まっているのか確認しやすくなります。

  • ワイヤーフレーム初稿作成:5営業日

  • 発注側確認:3営業日

  • 修正:2営業日

  • 最終確認・承認:2営業日

確認期間を明示すると、関係部署もいつまでに意見をまとめる必要があるか把握でき、案内やお知らせをする場合にも役立ちます。

タスクの完了条件を決める

進捗率だけでは、実際に次の工程へ進める状態か判断できないことがあります。

たとえば、デザインが90%完成していても、決裁者の承認がなければ実装へ進めない場合があります。タスクごとに「初稿提出」「関係部署確認済み」「決裁者承認済み」などの完了条件を決めます。

公開日に影響するタスクを把握する

一部の作業が遅れても、ほかの工程を先に進められる場合があります。一方で、要件確定、主要画面の承認、CMS開発、コンテンツ移行、公開前テストなどは、遅延すると公開日に直接影響しやすい工程です。

こうしたタスクは、進捗確認の優先度を上げ、問題が起きた時点で公開日への影響を判断します。

リニューアルのスケジュールを立てる手順

1. 公開希望日と変更できない予定を確認する

最初に、希望する公開日と、その日付を変更できるか確認します。

新商品の発表、採用活動、決算、キャンペーンなどに合わせる場合は、公開時期を動かせないことがあります。長期休暇、繁忙期、社内行事、システムを変更できない期間も確認が必要です。

公開日を変更できない場合は、公開時に必要なページ・機能と、公開後に追加できる内容を分けて考えます。

2. リニューアルの対象範囲を決める

既存サイトの全ページを作り直すのか、一部を継続利用するのかによって、必要な期間は変わります。

次の内容を整理します。

  • 対象となるサイトとページ

  • 残すコンテンツと削除するコンテンツ

  • 新しく作成するコンテンツ

  • 変更する機能と継続する機能

  • CMSやサーバーを変更するか

  • 外部サービスとの連携を変更するか

  • URLを変更するか

対象範囲を決めきれない場合は、既存サイトの調査とコンテンツの棚卸しを最初の工程として設定します。

3. タスクと成果物を分解する

各工程について、誰が何を作成し、何が完成すれば次へ進めるのかを整理します。

たとえば情報設計であれば、サイトマップ、コンテンツ一覧、主要なユーザー導線などが成果物です。タスク名だけでなく完了条件を決めることで、認識の違いによる手戻りを減らせます。

4. タスクの前後関係と並行作業を整理する

各タスクについて、ほかの作業と並行できるか、先に何を決める必要があるかを確認します。

原稿作成は、サイト構成と各ページの役割が決まった段階から進められます。一方、CMSへの登録は、入力項目やテンプレートが確定しなければ開始できません。

前工程の遅れが後工程へ影響する箇所を把握し、公開日に直結する作業には余裕を持たせます。

5. 担当者・確認者・決裁者を決める

制作会社の担当者だけでなく、発注側の担当者もスケジュールへ入れます。

  • 原稿や画像を準備する担当者

  • 掲載内容を確認する担当者

  • デザインを確認する担当者

  • システムやセキュリティを確認する担当者

  • 最終的な承認を行う決裁者

担当者が決まっていても、確認者や決裁者が決まっていなければ、社内確認で進行が止まります。複数部署から意見を集める場合は、制作会社へ戻す前に誰が内容をまとめるのかも決めます。

6. 確認期間と修正回数を設定する

各工程について、確認に何営業日かけるのかを決めます。あわせて、ワイヤーフレームやデザインの修正回数も確認します。

確認が遅れた場合は、後続工程も同じ日数だけ遅れる可能性があります。公開日を変えずに進めると、テストや修正の期間が短くなり、品質面のリスクが高まります。

期限だけでなく、遅延した場合にどの工程へ影響するかも共有しておくことが必要です。

7. テストと公開作業に予備期間を設ける

公開直前まで実装やコンテンツ登録を続けるスケジュールでは、追加修正や公開作業の問題に対応できません。

特にCMS移行、外部システム連携、ドメイン変更、サーバー変更を伴う場合は、テストと公開準備の期間を確保します。公開後にも、フォーム送信、アクセス解析、リダイレクト、検索エンジンの登録状況などを確認します。

スケジュールが遅れやすい5つの原因

目的や対象範囲が途中で変わる

制作中に目的や要件が変わると、サイト構成、デザイン、実装など、全体的に制作の進め方を見直す必要があります。

変更が必要になった場合は、追加する内容だけでなく、納期、費用、既存タスクへの影響を合わせて判断します。公開日を維持する場合は、対象範囲を減らすなどの調整も必要です。

社内確認に時間がかかる

複数部署から異なる意見が出ると、制作会社側ではどの内容を採用すべきか判断できません。

制作会社へ意見を返す前に、社内の窓口担当者が内容を整理します。最終判断を行う人と確認期限を決めておくことで、相反する修正指示や確認待ちを減らせます。

原稿や画像が揃わない

原稿、写真、会社情報、製品情報などが揃わなければ、デザインや実装が完了しても公開できません。

原稿作成を発注側と制作会社のどちらが担当するのか、既存原稿をどこまで使用するのか、取材や撮影が必要かを早い段階で決めます。

仮の文章でデザインを進める場合も、実際の文字量や情報量が大きく変わると、レイアウトの再調整が必要です。

コンテンツ移行の工数を見落とす

既存サイトの記事や実績を新しいCMSへ移す場合、データをコピーするだけでは完了しません。

新しい入力項目への変換、画像の調整、リンク切れの確認、公開日やカテゴリーの引き継ぎなどが必要です。旧CMSからデータを出力できない場合は、手作業での移行が増える可能性もあります。

移行対象を一覧化し、自動化できる範囲と手作業になる範囲を事前に確認します。

公開直前にテストを集中させる

表示確認、フォーム送信、CMS操作、アクセス解析、リダイレクトなどを公開直前にまとめて確認すると、修正時間が不足します。

実装が完了したページから順番に確認し、テストを一つの期間へ集中させない進め方が必要です。

スケジュールを短縮するときの判断基準

制作期間を短くするには、単純に作業日数を削るのではなく、対象範囲と意思決定の方法を見直します。

短縮を検討しやすいのは、次の項目です。

  • 公開時に必要なページへ対象を絞る

  • 既存の原稿や写真を継続利用する

  • ページごとではなくテンプレート単位で確認する

  • 社内の確認者と決裁者を限定する

  • 確認日をあらかじめ確保する

  • 公開後に追加できる機能を分ける

一方で、要件定義、セキュリティ確認、フォームの動作確認、リダイレクト、バックアップなどを省略すると、公開後の不具合やアクセス減少につながる可能性があります。

短納期が必要な場合は、品質確認の期間を削るのではなく、初回公開の範囲を調整することが現実的です。

工程管理ではツールより更新ルールを決める

スケジュール管理には、ExcelやGoogleスプレッドシート、Backlog、Jiraなどを使用できます。しかし、どのツールを使っても、情報が更新されなければ正確な進捗は把握できません。

プロジェクトの開始時に、次の運用ルールを決めます。

  • 誰が進捗を更新するか

  • どの頻度で更新するか

  • 遅延が発生したときに誰へ共有するか

  • 仕様変更をどこに記録するか

  • 最新の原稿やデザインをどこで管理するか

  • 定例会議で何を確認し、何を決定するか

定例会議では、完了した作業の報告だけでなく、遅れているタスク、次の工程を止める可能性がある課題、期限までに必要な判断を確認します。

自社で管理する範囲と制作会社へ相談する範囲

自社で管理する範囲

リニューアルの目的、予算、公開時期、社内の担当者・確認者・決裁者は、自社で整理する必要があります。

原稿や画像をどこまで用意できるのか、各部署が確認に何営業日必要なのかも、制作会社だけでは判断できません。詳細を決められない場合でも、誰がいつまでにやることなのか、いつまでに判断するのかを決めておきます。

制作会社へ相談する範囲

次の内容は、既存サイトやシステムの状態を確認しなければ必要な工数を判断できません。

  • CMSやサーバーの変更

  • 既存コンテンツの移行

  • URL変更とリダイレクト

  • 外部システムとの連携

  • フォームや会員機能の改修

  • アクセシビリティ対応

  • セキュリティ診断

  • SEO設定やアクセス解析の移行

希望する公開時期が決まっている場合は、実現できるかどうかだけでなく、どの工程にどの程度の確認期間が必要かまで相談します。

スケジュール作成前のチェック項目

  • リニューアルの目的を説明できるか

  • 希望する公開日と、変更できる日付かを確認したか

  • 対象となるサイトやページを把握しているか

  • 新しく必要になる原稿や画像を把握しているか

  • CMSやサーバーを変更する予定があるか

  • 社内の担当者、確認者、決裁者が決まっているか

  • 関係部署の確認に必要な日数を把握しているか

  • 既存コンテンツの移行方法を確認しているか

  • 公開前のテスト期間を確保しているか

  • 公開後の更新担当者が決まっているか

よくある質問

Q. Webサイトリニューアルのスケジュールとは何ですか?

A. 調査、要件定義、設計、デザイン、実装、コンテンツ移行、テスト、公開までの予定を整理したものです。制作会社の作業だけでなく、発注側が担当する原稿提出、社内確認、承認も含めます。各タスクの担当者と期限、前後関係を明確にすることで、遅延の影響を判断しやすくなります。

Q. ガントチャートとは何ですか?

A. タスクの開始日と終了日を時間軸に沿って表示する工程管理表です。担当者、進捗、タスクの前後関係も合わせて管理できます。Webサイトリニューアルでは、制作作業だけでなく、原稿準備や社内承認も登録し、どの確認待ちが後続工程へ影響するか把握するために使用します。

Q. Webサイトリニューアルには何ヶ月かかりますか?

A. 小規模サイトは2〜3ヶ月、中規模サイトは4〜6ヶ月、大規模サイトは8ヶ月〜1年以上が目安です。ただし、ページ数だけでは決まりません。CMS移行、原稿作成、撮影、外部システム連携、複数部署による承認がある場合は、必要な工程と確認期間が増えます。

Q. 希望する公開日まで時間がない場合はどうすればよいですか?

A. 公開日に必要なページと機能を絞り、優先度の低い内容を公開後に追加する方法があります。テストやセキュリティ確認を省略すると、公開後の不具合につながるため避けるべきです。公開日を変更できるか、初回公開の範囲を分けられるかを制作会社と確認します。

Q. スケジュールが遅れた場合はどう対応しますか?

A. まず、遅れているタスクが後続工程と公開日へ与える影響を確認します。そのうえで、公開日の変更、対象範囲の縮小、作業順序の変更、担当者の追加を検討します。公開日を維持するためにテスト期間だけを短縮すると、確認漏れや不具合が残る可能性があります。

Q. スケジュール作成は制作会社に任せてもよいですか?

A. 制作会社は制作工程を管理できますが、社内承認や原稿準備に必要な期間を単独で決めることはできません。自社側でも担当者、確認者、決裁者を決め、確認期限を管理する必要があります。双方のタスクと前後関係を一つのスケジュールで確認できる状態が適切です。

リニューアルの進行は確認と承認の設計で変わる

Webサイトリニューアルのスケジュールでは、デザインや実装の期間だけでなく、対象範囲の決定、原稿の準備、社内確認、コンテンツ移行、公開前テストまで管理する必要があります。

まずは、希望する公開時期、リニューアルの対象範囲、社内の担当者・確認者・決裁者、CMSやサーバーの変更有無を確認してください。そのうえで、タスクの前後関係と確認期限をガントチャートへ整理すると、実行可能なスケジュールを作成しやすくなります。

株式会社デパートでは、既存サイトの調査や要件整理から、デザイン・実装、コンテンツ移行、公開後の運用までを含めてリニューアルを支援しています。公開時期は決まっていても必要な工程や対象範囲を判断しにくい場合は、現状の整理からご相談いただけます。

Webサイト制作サービスをご紹介

Contact

制作のご依頼やサービスに関するお問い合わせ、
まだ案件化していないご相談など、
お気軽にお問い合わせください。

お問い合わせはこちら

監修者

河上 智哉部長 | シニアディレクター

前職ではモバイル関連コンテンツおよび周辺機器のテストディレクターとして、品質管理や進行管理、クライアントとの調整業務に従事。テスト計画の策定から実施管理、課題抽出・改善提案まで幅広く担当し、品質向上とプロジェクト推進を担う。 一方で、学生時代から趣味で培っていたWeb制作の知識や、Photoshop・Illustratorを用いたデザインスキルを活かし、本業の傍ら自社サービスのWebサイト運営を担当。コンテンツ更新や改善施策の実施に加え、取引先企業のWebサイトリニューアルや運用支援に携わる。 業務を通じてWeb領域への興味を深める中で、必要な知識や技術を自ら習得しながら実践経験を積み重ね、約10年間勤務した前職からWeb業界への転職を決意。現在はWebディレクターとして、顧客・ユーザー双方の課題を俯瞰的に捉えながら、要件整理、情報設計、制作進行管理、運用改善まで一貫して担当している。toB・toCを問わず多様な業界のプロジェクトに携わった経験を活かし、柔軟性と実行力をもってプロジェクトを推進し、成果創出に向けて伴走している。

専門領域Webディレクション, 運用・保守, 撮影, プロジェクトマネジメント, 要件定義・仕様策定, 取材・ライティング, 品質管理 (検品・テスト), Google Search Console, Google Analytics 4 (GA4), Google 広告 / Yahoo!広告

関連ブログ