要件定義
大規模Webサイトリニューアルの進め方|失敗しないための要件定義と体制設計
大規模Webサイト(数千〜数万ページ規模)のリニューアルは、次の5ステップで進めるのが基本です。
①Webサイトに求められる機能の変化(潮流)を理解する→②リニューアルの目的を明確化し、経営陣・関係部署と合意形成する→③要件定義で「更新性・拡張性・マーケティング機能・AI活用」の4つの観点を整理する→④それらを踏まえて予算とスケジュールの全体設計を行う→⑤推進体制を構築し、ベンダー選定・関係部署の巻き込みを進める。
特に大企業では前回のリニューアルから10年前後が経過しているケースが多く、社内に経験者がいないまま、目的が曖昧なまま進めてしまうことが失敗の最大の原因になります。本記事では、実務担当者が押さえるべき順に、要件定義と体制設計のポイントを解説します。
目次
大規模サイトのリニューアルが「進め方」でつまずく3つの理由
大規模なコーポレートサイトのリニューアルで最初につまずく最大の理由は、担当者に経験がなく、かつ参考になる情報が少ないために、何から着手すればよいか分からないことです。具体的には、次の3つの壁に直面します。
①社内に経験者がいない
大企業のCMS基盤は、一度構築すると10年前後にわたって使い続けられる傾向があります。そのため、前回のリニューアルを担当した人が社内に残っていないケースが非常に多く、正しい段取りやスケジュール感、コスト感を知る手がかりがありません。また、10年前には存在しなかった要件(シングルサインオン(SSO:Single Sign-On、複数システムを1つの認証情報でログインできる仕組み)との連携、MA(マーケティングオートメーション)・SFA(営業支援システム)との連携、クラウド型の認証基盤など)に、初めて向き合うことになる点も難易度を上げています。
②世の中の情報の多くが中堅・中小企業向けである
Web検索で「サイトリニューアル 進め方」と調べても、出てくる情報の多くは中堅・中小規模のサイトを前提にしたものです。そこに書かれていること自体は間違っていなくても、数千〜数万ページ規模・複数部署・複数システムが絡む大規模サイト特有の論点(後述する基幹システム連携やグループガバナンスなど)は扱われていないことがほとんどです。自社の規模に合った情報かどうかを見極めながら参考にする必要があります。
③リニューアルの目的が定まらないまま進んでしまう
リニューアルの理由は「システムのEOL(End of Life:サポート終了)」がきっかけになることが少なくありません。しかしEOL対応だけを理由にすると後ろ向きな企画に見えてしまい、予算確保のハードルが上がります。何のためにリニューアルするのかという目的が曖昧なままだと、後工程の要件定義や部門間調整でも一貫性を欠き、プロジェクト全体が停滞しやすくなります。
大規模サイトリニューアルの進め方:5つのステップ
大規模Webサイト(数千〜数万ページ規模)のリニューアルは、次の5ステップで進めるのが基本です。特に大企業では前回のリニューアルから10年前後が経過しているケースが多く、社内に経験者がいないまま、目的が曖昧なまま進めてしまうことが失敗の最大の原因になります。
| ステップ | やること | 目的 |
|---|---|---|
| STEP1 | Webサイトに求められる機能の潮流を理解する | 要件定義の抜け漏れを防ぐ全体像を持つ |
| STEP2 | 目的を明確化し、社内で合意形成する | 経営陣・関係部署から予算とコンセンサスを得る |
| STEP3 | 要件定義(4つの観点で整理) | 何を実現するプロジェクトかを具体化する |
| STEP4 | 予算・スケジュールの全体設計 | 実現可能な計画に落とし込む |
| STEP5 | 推進体制の構築とベンダー選定 | プロジェクトを実行できる体制を整える |
STEP1:Webサイトに求められる機能の「潮流」を理解する
大規模サイトは、「更新性→拡張性→マーケティング機能→AI活用」という順で求められる機能が高度化していく流れの中にあります。この全体像を先に押さえておくことで、目先の課題だけでなく将来の拡張要件まで見据えた要件定義ができます。
| 観点 | 具体的な内容 |
|---|---|
| 更新性 | 現場の担当者がHTML/CSSの知識なしにコンテンツを更新・管理できるか。大量ページを扱う場合はカテゴリー階層(ツリー型)による管理のしやすさも重要 |
| 拡張性 | 将来のグローバル展開(多言語・多地域対応)、マルチサイト運用、会員サイト化などに対応できるか |
| マーケティング機能 | MA(マーケティングオートメーション)連携、SFA/CRM連携、パーソナライズ、レコメンド機能など |
| AI活用 | コンテンツ生成・翻訳・ワークフロー自動化など、AIを前提とした運用効率化に対応できるか |
これら4つに加えて、セキュリティ・ログ監視・パフォーマンス・可用性・アクセシビリティ対応(法令対応を含む)といった大規模サイト特有の非機能要件も、企画段階で考慮しておく必要があります。
「見た目」と「中身」は別の評価軸で考える
要件定義でもう一つ見落とされやすいのが、「見た目(一見して整って見えるかどうか)」と「中身(実際の運用のしやすさ)」は必ずしも連動しないという点です。デザインやユーザビリティを磨き込んで一見して整った印象になったとしても、それだけでは運用担当者が日々使いこなせるCMSになっているとは限りません。実際に、リニューアル後に外部評価ランキングで上位に入るなど見た目の完成度は大きく向上した一方で、「更新のたびに外部委託が必要になり、運用の負荷はむしろ変わらなかった」という声が上がったケースも見られます。
| 評価軸 | 含まれる観点 |
|---|---|
| 見た目(一見して整って見えるかどうか) | グラフィカルデザイン、ユーザビリティ、情報デザイン(サイト構成・ナビゲーションのわかりやすさ) |
| 中身(実際の運用のしやすさ) | 更新性・拡張性、SEO対策のしやすさ、SNS連携のしやすさ |
要件定義の初期段階で「見た目」と「中身」の両方をバランスよく評価軸に含めておくことで、公開後に「評価は上がったのに運用は楽にならなかった」という事態を防ぎやすくなります。
STEP2:目的の明確化と社内の合意形成
リニューアルの目的が曖昧なまま進めてしまうと、後工程のあらゆる意思決定で判断基準がぶれてしまいます。特に大企業では、一担当者の判断だけでは大規模リニューアルの実施を決定できないケースが多く、経営陣を含めた合意形成のプロセスが不可欠です。
プロジェクトの起点が「経営陣がリニューアルを判断し、トップダウンで降りてきたテーマ」なのか、「現場の担当者が必要性を感じ、経営陣を説得していく必要があるテーマ」なのかによって、進め方は大きく変わります。後者の場合は特に、目的を言語化し、費用対効果を説明する準備に時間をかける必要があります。
目的の合意形成がどこまでできているかは、プロジェクトの成否を大きく左右します。広報部門だけで検討を進めるのではなく、事業部門・情報システム部門・経営層など関係者を集め、現状の課題と目指す姿を自分たちの言葉で言語化してもらう場を設けることが有効です。具体的には、次の4つのステップで進めると、目的の言語化から経営陣への説明まで一貫した流れを作りやすくなります。
- 関係部署(広報・事業部門・情報システム部門など)の責任者クラスを集める
- 現状のWebサイトについて「何がダメなのか」を、各部署自身の言葉で挙げてもらう
- それが改善された場合に「どうなっていたいか」を、同じく自分たちの言葉で言語化してもらう
- そこで出た内容を、目的・費用対効果・スケジュール感として資料化し、経営陣への説明に用いる
STEP3:要件定義で押さえるべき大規模サイト特有の論点
大規模サイトの要件定義では、中堅・中小規模のサイトでは登場しない論点への対応が必要です。代表的なものは次のとおりです。
- シングルサインオン(SSO)・認証基盤との連携:「IDを一つにしたいだけ」という単純な要望に見えて、実装難易度が高いケースが多い論点です
- 基幹システム(CRM・SFA・PIM(Product Information Management:商品情報管理システム)など)との連携
- グループ会社・複数事業部のサイトが乱立している場合のガバナンス設計(デザイン統一、ドメインパワーの分散防止など)
- グローバル対応(多言語・多地域でのコンテンツ管理、GDPR等の法令対応)
- アクセシビリティ対応(大企業サイトでは対応の必要性・範囲を要件として明記すべき項目)
これらは、社内に前回のリニューアル経験者がいない場合、特に検討が漏れやすい領域です。過去に何十社もの大規模案件を見てきた第三者の知見を借りながら整理することで、抜け漏れを防ぎやすくなります。
なぜ「前回の経験」がそのまま使えないのか:技術基盤の変遷
大企業のCMS基盤が10年前後使われ続けることを踏まえると、前回リニューアル時の知見がそのまま通用しない領域があることも押さえておく必要があります。代表的なのが認証基盤と多言語翻訳の仕組みです。
- 認証基盤:かつて主流だったオンプレミス型のディレクトリサービスから、クラウド型の認証基盤(Microsoft Entra ID、Oktaなど)へと標準が移り変わっています。10年前の知見のままでは、現在の標準的な連携方法とズレが生じます
- 多言語翻訳:かつては「原稿をExcel/Wordに書き出す→翻訳会社に依頼→翻訳結果をCMSに再入力する」という手作業が一般的でしたが、現在は翻訳会社とのシステム連携やAI翻訳の活用によって、依頼から反映までを大幅に効率化できるようになっています
こうした技術基盤の変化は、前回リニューアルを経験した担当者がいたとしても見落としがちなポイントです。現在の標準がどこにあるかを把握したうえで要件定義に反映することが重要です。
要件定義・体制設計でチェックすべき6つの観点
Webディレクションの観点から、要件定義や体制設計の場でヌケモレを確認する際は、次の6項目をチェックリストとして使うと網羅性を確保しやすくなります。
- グラフィカルデザイン:見た目・配色などのビジュアル品質
- ユーザビリティ:ボタンの配置やリンクの分かりやすさなど、使いやすさ
- 情報デザイン(同一性設計):グローバルナビゲーションやサイト構成など、サイト全体での情報の探しやすさ
- 更新性・拡張性:現場担当者が更新しやすいか、将来の機能追加に対応できるか
- SEO:検索エンジンに正しく評価される設計になっているか
- SNS連携:SNSとの連動を前提とした設計になっているか
予算・スケジュールの全体設計と推進体制の構築
目的と要件の骨格が固まったら、それを実現するための予算・スケジュールの全体像と、プロジェクトを推進する体制を並行して設計します。
予算・スケジュール設計のポイント
大規模サイトのリニューアルは、要件定義から公開まで数ヶ月〜1年以上かかることも珍しくありません。企画段階で、どこまでの機能を今回のスコープに含めるか(段階的にリリースするかどうかを含め)を整理し、経営陣に説明できる形で費用対効果とスケジュール感を可視化しておくことが重要です。
進め方は「要件定義→設計→実装・移行→テスト→公開」という大枠の流れ自体は変わりませんが、大規模サイトの場合はこのうち要件定義・設計にかける時間を十分に確保できるかどうかが、その後の手戻りの少なさを左右します。実際に、日々のWebサイト更新やHTML/CSSの知識はあっても、CMS導入の経験がないまま「企画は数ヶ月、CMS導入も半年程度で終わる」という前提でスケジュールを組んでしまい、後から見直しが必要になったケースもあります。テンプレート設計、ワークフロー設計、権限設計など、CMS導入時に決めるべき事項を過小評価してしまうと、このようなズレが起こりやすくなります。
また、「まずはPoC(概念実証:Proof of Concept、小規模に試作して実現性を検証すること)から始めたい」という要望が出ることもありますが、大規模サイトのリニューアルにおいては、PoCの実施よりも要件定義をどれだけ丁寧に行えるかが成否を分けます。スケジュール感が曖昧なまま進めてしまうと、その前提の上に組まれる予算感も的外れになりやすい、という点には注意が必要です。
推進体制のポイント
- プロジェクトオーナー(経営層または責任ある役職者)を明確にする
- 各関係部署(広報・事業部門・情報システム部門など)から窓口担当を出してもらう
- ベンダーには要件定義段階から伴走してもらい、社内調整のファシリテーションも含めて依頼できるかを確認する
大規模サイトリニューアルでよくある失敗パターン
- 中堅・中小企業向けの一般的な情報を参考にしてしまい、大規模特有の論点(システム連携・ガバナンスなど)を見落とす
- 目的の合意形成をせずに、手法やベンダーの機能比較といった各論から議論を始めてしまう
- EOL対応など後ろ向きな理由だけを説明材料にしてしまい、前向きな投資対効果を経営陣に示せない
- 目先の課題だけを見て、将来の拡張要件(会員サイト化、パーソナライズ、基幹連携など)を要件定義に含めない
LYZONが大規模Webサイトリニューアルの相談先として選ばれる理由
LYZONは、国内最大手100社のうち20社以上との取引実績を持ち、190サイト以上の構築実績があります。約52,000ページ規模のCMS移行や、23か国18言語にわたるグローバルサイト構築など、数千〜数万ページ規模の大規模サイト構築を得意としています。
大企業向けCMS「Sitecore」では国内No.1クラスの構築・運用実績を持ち、Sitecore Practice Excellence Award 2024ではアジア地域No.1として受賞しました。要件定義の段階から参画し、基幹システムやSSOとの連携を含めた設計力を評価いただいています。
また、広告代理店経由の案件は0件で、資本的にも独立した立場から、下請けではなく直接取引・対等なパートナーシップでご支援しています。短期的な構築で終わらせず、10〜20年使えるWebサイト基盤を整える思想で伴走します。
よくある質問(FAQ)
Q. 大規模サイトのリニューアルにはどれくらいの期間がかかりますか?
要件定義から公開まで数ヶ月〜1年以上かかることが一般的ですが、注意したいのは「企画3〜4か月、CMS導入は半年程度」といった楽観的な前提でスタートし、後から見直しが必要になるケースが実際に起きている点です。CMS導入にはテンプレート設計・ワークフロー設計・権限設計など決めるべき事項が想像以上に多く、要件定義・設計にどれだけ時間を確保できるかが、その後の手戻りの少なさを左右します。
Q. 何から手をつければよいですか?
目的を言語化するだけでなく、関係部署(広報・事業部門・情報システム部門など)の責任者クラスを集め、①現状の何がダメなのかを自分たちの言葉で挙げてもらう→②改善後にどうなっていたいかを言語化してもらう、という2ステップの場を設けることから始めるのが効果的です。この順序を踏むと、後工程で「目的が経営陣に伝わらない」という事態が起きにくくなります。
Q. 経営陣への説明はどう進めればよいですか?
システムのEOLだけを理由にすると後ろ向きな企画に見えてしまう点に注意が必要です。また、プロジェクトの起点が「経営陣主導のトップダウン」か「現場からのボトムアップ」かによって、必要な説明の準備量は大きく変わります。ボトムアップ型の場合は特に、費用対効果を資料化し、経営陣が判断しやすい形に整えるプロセスに時間をかける必要があります。
まとめ
大規模Webサイトのリニューアルを成功させるには、目先の課題だけでなく「Webサイトに求められる機能の潮流」を理解したうえで、目的の明確化・社内合意形成・要件定義・予算スケジュール設計・推進体制構築という順序で進めることが重要です。社内に経験者がいないことは大規模サイトでは珍しくありません。だからこそ、数多くの大規模案件を見てきた第三者の知見を活用することが、失敗を避ける近道になります。