Webサイトリニューアルの検討を始めると、デザイン案やCMS製品を早く見たくなるものです。しかし、プロジェクトの成否を左右するのは、制作物の検討より前に「なぜリニューアルするのか」「どこまで変えるのか」「誰が意思決定するのか」を整理できているかどうかです。

 

目的や対象範囲が曖昧なまま制作会社へ相談すると、各社が異なる前提で提案するため、見積もりもスケジュールも比較しにくくなります。反対に、最初から細かな仕様を決め切ろうとすると、専門知識が必要な論点で社内検討が止まり、相談の開始が遅れることがあります。

 

本記事では、Webサイトリニューアルを進める基本的な順番と、要件定義、システム要件定義、提案依頼書（RFP）の役割を整理します。社内で決めることと、制作会社・CMSベンダーと一緒に具体化することを分け、無理なくプロジェクトを前へ進める方法を解説します。

結論｜Webサイトリニューアルは何から始める？
最初に行うべきことは、デザインやCMSの決定ではなく、背景・目的・対象範囲・体制・優先順位の整理です。その後、要件定義で判断軸をそろえ、システム要件を具体化し、複数社を比較する場合はRFPで提案条件を統一します。

この記事のポイント

  • Webサイトリニューアルは、目的と対象範囲を言語化してから制作・CMS選定へ進む
  • 要件定義はプロジェクトの判断軸、システム要件定義は実装・運用条件、RFPは提案比較のための文書
  • 社内で決める事項と、制作会社の提案を受けて決める事項を分ける
  • SaaS型CMSでは標準仕様を前提にできるため、個別開発の要件整理を抑えやすい

INDEX

Webサイトリニューアルの基本的な進め方

Webサイトリニューアルは、一般に次の流れで進みます。案件の規模や調達方法によって順番は前後しますが、「前提整理」「要件整理」「提案・選定」「設計・制作」「移行・公開」「運用改善」の六つに分けると全体像を把握しやすくなります。

工程

主な作業

主な成果物

1. 前提整理

背景、目的、現行課題、対象範囲、体制、予算感、希望時期を整理する

プロジェクト概要、課題一覧、対象範囲

2. 要件整理

ターゲット、導線、コンテンツ、運用、CMS、移行の条件を整理する

要件定義書、サイト要件一覧

3. 提案・選定

必要に応じてRFPを配布し、制作会社・CMSを比較する

RFP、提案書、評価表

4. 設計・制作

情報設計、画面設計、デザイン、CMS設定・実装を行う

サイトマップ、ワイヤー、デザイン、CMS

5. 移行・公開

コンテンツ移行、URL移行、テスト、関係者確認を行う

移行台帳、リダイレクト表、テスト結果

6. 運用・改善

更新ルールを定着させ、アクセスデータをもとに改善する

運用マニュアル、改善計画

初期段階では、すべてを確定する必要はありません。ただし、何が決定済みで、何が仮置きで、何を提案してほしいのかは区別しておく必要があります。未決事項を隠すより、未決であることを明記した方が、制作会社から現実的な進め方や費用前提を提示してもらいやすくなります。

要件定義、システム要件定義、RFPの違い

要件定義は、今回のプロジェクトで何を実現するのかを整理し、関係者の認識をそろえる工程です。背景、目的、対象範囲、ターゲット、必要条件、公開後の運用イメージまで含めて、案件の土台をつくります。

 

システム要件定義は、その要件をCMS、権限、ワークフロー、フォーム、検索、セキュリティ、性能、保守体制といった実装・運用の条件に落とし込む工程です。ここは社内だけで完結するより、制作会社や実装パートナーとすり合わせながら解像度を上げていくことが多い領域です。

 

RFPは、整理した前提を外部に伝え、比較可能な提案を集めるための文書です。要件定義が案件の土台づくりなら、RFPは比較のためのフォーマットと考えるとわかりやすいでしょう。

 

役割の違い

文書・工程

目的

主な内容

主な利用者

要件定義

プロジェクトで実現したいことと判断基準をそろえる

背景、目的、ターゲット、対象範囲、コンテンツ、運用、優先順位

発注側の関係部門、制作会社

システム要件定義

業務上の希望を実装・運用可能な条件へ変換する

CMS機能、権限、承認、検索、フォーム、連携、性能、セキュリティ、保守

Web担当、情報システム、実装会社、CMSベンダー

RFP（提案依頼書）

複数社が同じ前提で提案できる状態をつくる

案件概要、依頼範囲、必須条件、提案事項、提出形式、評価基準

候補となる制作会社・CMSベンダー、選定委員

社内で先に整理したい7項目

1. リニューアルの背景と目的

「デザインが古いから」だけでは、優先順位を決められません。更新の迅速化、企業理解の促進、採用応募の増加、IR情報への到達性向上、複数サイトの統合、セキュリティ負荷の軽減など、改善したい状態を一文で表現します。可能であれば、公開後に確認する指標も設定します。

 

2. 現行サイトの課題

課題を、情報設計、コンテンツ、デザイン、CMS・更新性、運用体制、インフラ・セキュリティ、アクセス解析の観点に分けます。「更新しにくい」という課題も、画面が複雑なのか、承認に時間がかかるのか、制作会社への依頼が必要なのかによって解決策が異なります。

 

3. 対象範囲と対象外

コーポレートサイト本体、IR、採用、サステナビリティ、製品・サービス、グループ会社、多言語サイトのうち、今回どこまでを対象にするかを決めます。対象外の領域も明記すると、見積もり範囲の認識違いを減らせます。

 

4. ターゲットと主要行動

顧客、求職者、株主・投資家、取引先、地域社会、従業員など、主要な閲覧者を整理します。各ターゲットが何を知り、どのページへ進み、最終的にどのような行動を取ることを期待するのかを定義します。

 

5. プロジェクト体制と意思決定

責任者、実務担当者、意見を出す部門、最終承認者、情報システム・法務・セキュリティの確認者を整理します。全員がすべての会議へ参加するのではなく、論点ごとの確認者と決定期限を決めることが重要です。

 

6. 予算の考え方と希望時期

確定した予算がなくても、想定レンジや上限、初期費用と運用費の考え方を共有します。公開希望日には、決算発表、採用時期、株主総会、周年事業など、動かしにくい事情があるかも記載します。

 

7. 優先順位と未決事項

必須、望ましい、将来対応の三段階に分けます。すべてを必須にすると、費用と期間が膨らみ、候補も狭くなります。未決事項には、決める担当者、判断材料、期限を設定します。

制作会社・CMSベンダーと一緒に詰める項目

社内で目的と判断軸を整理した後は、専門家の知見を活用して具体化します。特に次の項目は、制作・実装・移行の方法によって費用やリスクが変わるため、相談しながら決める方が合理的です。

 

  • サイトマップとページテンプレートの最適な分け方
  • CMSで管理する領域と、外部サービス・個別実装で対応する領域
  • 部門別・サイト別の権限、承認段階、公開ルール
  • サイト内検索、フォーム、MA・CRM、採用管理、IR情報配信などの連携方法
  • 既存ページ、PDF、画像、ニュース、フォームデータの移行方法
  • URL変更の有無、301リダイレクト、SEO評価の引き継ぎ
  • テスト、アクセシビリティ、セキュリティ審査、公開判定の進め方
  • 公開後の保守、問い合わせ、改善支援の範囲

RFPが必要なケースと、簡易ブリーフで進められるケース

正式なRFPが向くケース

簡易ブリーフ・事前相談が向くケース

3社以上を同じ条件で比較したい

相談先が1〜2社に絞られている

社内調達ルール上、コンペが必要

伴走型で要件定義から一緒に進めたい

提案範囲や見積もり条件を統一したい

CMSの標準機能を確認しながら要件を決めたい

選定理由を役員・調達部門へ説明する必要がある

公開時期が迫っており、まず実現性を相談したい

複数のCMS・構築方式を広く比較したい

対象範囲や予算感がまだ流動的である

RFPを作ること自体が目的ではありません。候補各社が同じ前提で提案でき、発注側が根拠を持って選べる状態をつくることが目的です。案件に合わないほど詳細なRFPを作ると、作成負荷だけでなく、提案の自由度を不必要に狭めることがあります。

SaaS型CMSで要件整理が変わる理由

個別構築型のCMSでは、サーバー構成、CMS本体の更新方法、バックアップ、監視、セキュリティ対策、障害対応などを個別に設計し、役割分担を決める必要があります。SaaS型CMSでは、これらの一部がサービス標準として提供されるため、ゼロから設計する要件を減らせます。

ShareWithなら

ShareWithは、企業サイト向けのCMS、サーバー・セキュリティ、サポートを一体で提供するクラウドCMSです。

そのため、要件定義ではサーバーやCMS機能をゼロから設計するより、「標準機能でどこまで実現するか」「自社の承認・運用ルールをどう当てはめるか」「どのコンテンツを移行するか」に重点を置きやすくなります。

ただし、SaaS型CMSでも、対象範囲、権限、承認者、コンテンツ責任者、移行方針、外部連携、公開後の運用体制は自社で整理する必要があります。

Webサイトリニューアルで起こりやすい失敗

失敗

起こる理由

対策

デザインから議論を始める

目的やコンテンツ方針が曖昧なため、好みの議論になる

目的、ターゲット、主要導線を先に合意する

対象範囲が途中で増える

対象外や次フェーズが明記されていない

対象・対象外・将来対応を一覧化する

全要件を必須にする

優先順位がなく、過剰な構築になる

Must／Should／Couldで分類する

CMS機能だけで選ぶ

運用、移行、サポート、保守を評価していない

運用シナリオと5年間の総費用で比較する

移行を後から考える

ページ数、URL、PDF、フォームの実態を把握していない

選定前にコンテンツとURLを棚卸しする

承認者が終盤で増える

意思決定者と確認者が不明確

体制表とレビュー期限を初期に作る

よくある質問

まとめ

Webサイトリニューアルでは、最初に細かな仕様を決め切ることより、判断軸をそろえることが重要です。背景、目的、対象範囲、体制、優先順位を整理したうえで、制作会社やCMSベンダーとシステム要件や移行方法を具体化します。複数社を比較する場合は、RFPで前提と回答形式をそろえます。

 

「社内で決めること」「提案してほしいこと」「プロジェクト開始後に決めること」を分けると、検討は進めやすくなります。CMSを選ぶ際も、機能数だけではなく、自社の運用に無理なく適合し、公開後まで継続して運営できるかを確認してください。