サイトリニューアルの要件定義｜既存サイトの棚卸しから文書化まで

サイトリニューアルの要件定義は、新規制作とは出発点が違います。ゼロから要件を積み上げるのではなく、いま動いているサイトを棚卸しし、「何を残し・何を捨て・何を変えるか」を決めるところから始まります。

この順番を踏まないまま制作会社に依頼したり、社内で作り始めたりすると、公開後に「前のサイトにあった機能が引き継がれていない」「検索順位が下がった」といった手戻りが起きやすくなります。

ここでは、既存サイトの棚卸しから要件定義書の作成までを、事業会社側の担当者が進める前提で手順に沿って整理します。

要件定義はリニューアル全体の一工程にあたるため、企画から公開までの流れ全体はWebサイトのリニューアルの手順をまとめた記事、要件定義そのものの基礎はWebサイトの要件定義とは何かをまとめた記事も参考になります。

リニューアルの要件定義は「現状の棚卸し」から始まる

リニューアルの要件定義でまず必要なのは、理想像を描くことではなく、既存サイトの現状を正確に把握することです。新規制作なら白紙から要件を積み上げられますが、リニューアルには「引き継ぐべき資産」と「解消すべき負債」が必ず存在します。ここを飛ばすと、要件が現場の実態から浮いてしまいます。

棚卸しで確認したいのは、主に次の4点です。

• ページ資産：現在公開している全ページの一覧、アクセス数、更新頻度。残すページ・統合するページ・削除するページの判断材料になります

• 機能・システム：問い合わせフォーム、CMS、外部ツール連携など、いま動いている機能の一覧

• 運用の実態：誰が、どの頻度で、どんな作業をしているか。更新のたびに外部への依頼が発生していないか

• 技術的な状態：使っているCMSやサーバーの種類、最終更新時期、セキュリティ上の懸念

とくに見落とされやすいのが「運用の実態」と「技術的な状態」です。担当者の異動や退職で、サイトの全容を把握している人がいなくなっているケースは珍しくありません。

遊び予約サイト「アソビュー!」を運営するアソビューでは、コーポレートサイトを構築した社員が退職し、オープンソース型のCMSが数年間更新されないまま、全容を把握できる人員が不在の状態になっていました。バナーを1つ追加するだけでもエンジニアの協力が必要で、セキュリティ面からもリニューアルが避けられない状況でした。同社はこの状態を起点に、デザイナー1人で約3ヶ月かけてリニューアルを完了しています（アソビューの事例）。

こうした「ブラックボックス化」は、棚卸しをして初めて全貌が見えることが多いものです。現状把握を最初の工程に置く理由は、ここにあります。

リニューアルの目的とゴールを言語化する

棚卸しと並行して、リニューアルの目的を言葉にします。目的が曖昧なままだと、後続の要件がすべてぶれるためです。

「デザインが古いから」という動機は、リニューアルの出発点になりやすいものです。ただ、見た目の刷新は手段であって目的ではありません。それだけを軸にすると、「何が変われば成功なのか」を測る基準が定まらず、機能・移行・運用といった後続の要件が根拠を持てません。次のように、解決したい課題まで掘り下げます。

• 更新のたびに外部依頼が発生し、情報発信が遅れている → 自社で更新できる体制にしたい

• 数年間アップデートされておらず、セキュリティ上の不安がある → 安全に運用できる状態にしたい

• 問い合わせや採用応募につながっていない → 導線を設計し直したい

目的が定まると、達成度を測る指標（KGI・KPI）も設定できます。指標は「リニューアル後に何が変わればよいか」を具体的な数値で示すもので、公開後の評価基準になります。

たとえば、採用サイトをリニューアルしたウェルスナビでは、公開後にサイト滞在時間が約2倍、自然流入が約55%増となり、採用チーム自身で更新できる体制も実現しています（ウェルスナビの事例）。こうした変化は、目的と指標を最初に定めていたからこそ、成果として確認できるものです。

目的が複数ある場合は、優先順位をつけておきます。予算やスケジュールの制約で、すべてを同時に実現できないことがあるためです。

リニューアル特有の要件（移行・SEO・運用）を洗い出す

現状把握と目的が固まったら、リニューアルならではの要件を洗い出します。新規制作にはない、既存サイトからの「移行」に関わる論点が中心です。移行方針・URL設計・運用体制を詰めきらないまま進むと、公開後にページの抜け漏れや検索順位の下落につながります。

既存コンテンツの移行方針

現在のページやデータを、新サイトへどう引き継ぐかを決めます。全ページをそのまま移すのか、この機会に整理・統合するのか。過去記事が多いサイトほど、この判断が工数を左右します。

見積もりで注意したいのは、「移行ツールを使えば自動で全部移せる」と期待しすぎないことです。本文や記事データは一括で取り込めても、画像の配置やレイアウト、装飾の細部は移行元と移行先で仕様が異なるため、ページごとの手直しが残るのが一般的です。移行工数を見積もるときは、この仕上げの作業分まで含めておくと現実的です。

検索評価（SEO）を引き継ぐURL設計

リニューアルでURLが変わると、それまで積み上げた検索エンジンからの評価が失われることがあります。旧URLから新URLへの転送（301リダイレクト）の設計は、要件定義の段階で盛り込んでおく必要があります。公開後に慌てて対応すると、順位下落が長引くことがあります。詳しくはサイトリニューアルでSEO評価を落とさない方法にまとめています。

公開後の運用体制

リニューアルは公開がゴールではなく、その後の運用が続きます。誰が、どのツールで、どの範囲を更新するのか。ここを要件に含めておくと、ツールやCMSの選定基準が明確になります。

運用体制を要件に組み込むと、リニューアルそのものの進め方も変わります。ソラコムでは、移行と同時にCMSのテンプレート化・ルール化を実施し、公開後は専門知識がなくてもコンテンツを更新できる状態を整えました。ツールの移行は、運用フローを整備し直す好機でもあります。

要件定義書に盛り込む項目と書き方

洗い出した内容は、要件定義書として文書にまとめます。文書化することで関係者間の認識が揃い、制作の途中で判断がぶれたときの拠り所になります。

要件定義書に盛り込む項目は、おおむね次のように整理できます。

• 背景・目的：なぜリニューアルするのか、現状の課題、達成したいゴール

• プロジェクト体制：関わるメンバーと役割、スケジュール、予算

• サイト構成：サイトマップ、残す/統合する/削除するページの一覧

• 機能要件：必要な機能（フォーム、CMS、外部連携など）

• 移行要件：既存コンテンツの移行方針、URL設計、リダイレクト方針

• 運用要件：公開後の更新担当・頻度・使用ツール

• 非機能要件：表示速度、セキュリティ、対応デバイスなど

すべての項目を一度に完璧に埋める必要はありません。棚卸しと目的整理で得た情報を土台に、関係者と対話しながら埋めていくものです。

制作を外部に依頼する場合は、この要件定義書がそのまま提案依頼（RFP）の中身になります。社内で制作する場合も、文書化しておくことで途中参加のメンバーが状況を把握しやすくなります。

要件定義でつまずきやすい4つのポイント

要件定義の段階でつまずきやすい点を、あらかじめ押さえておきます。

• 現状把握を省く：既存サイトの棚卸しをせず理想像から入ると、公開後に「前にあった機能が新サイトに引き継がれていない」といった抜け漏れが起きます

• 目的が「デザイン刷新」で止まる：見た目の刷新だけを目的にすると、成果を測る指標を設定できず、リニューアルの効果を評価できません

• 移行工数を軽く見る：コンテンツやデータの移行は、想定より手作業が発生しがちです。とくに過去記事の多いサイトは要注意です

• 運用体制を後回しにする：公開後の更新担当を決めないまま進めると、リニューアル直後から更新が滞ります

これらは、要件定義を「制作会社に丸ごと任せる工程」と捉えたときに起きやすくなります。制作の専門知識は外部に頼れても、自社サイトの現状と目的を一番把握しているのは社内の担当者です。棚卸しと目的整理は、社内で主体的に進める価値があります。

要件定義に合わせてツールや進め方を選ぶ

要件が固まると、それを実現する手段の選択肢も見えてきます。制作を外部に委託するのか、社内で進めるのか。どのツールを使うのか。この判断は、要件を出す前に決めるものではなく、要件に照らして選ぶものです。

たとえば「公開後は自社で更新したい」という運用要件が強いなら、非エンジニアでも扱えるツールが候補になります。ノーコードでWebサイトを制作・運用できるStudioのようなプラットフォームは、こうしたケースで選択肢の一つになります。アソビューの導入事例では、リニューアル後の日々の運用作業工数が体感で2〜3割削減され、広報担当者が他業務と兼任しながら更新できる体制になりました。

一方で、決済機能や会員登録機能が必須の要件であれば、ノーコードツール単体では対応しきれず、外部サービスとの連携や別の手段が必要になります。ツールには向き不向きがあり、要件と照らして判断することが欠かせません。

外部への委託にも、社内制作にも、それぞれ合理性があります。内製化を急ぐ必要はありませんが、要件定義を自社で主導しておくことは、どちらを選ぶ場合でも土台になります。要件が明確なら、外部に依頼するときも認識のずれが減り、社内で進めるときも判断に迷いにくくなります。

まとめ

サイトリニューアルの要件定義は、既存サイトの棚卸しから始まり、目的の言語化、リニューアル特有の要件（移行・検索評価の引き継ぎ・運用体制）の洗い出しを経て、要件定義書にまとめる流れで進めます。新規制作と違い、いまあるサイトの資産と負債を正確に把握することが出発点です。

現状把握と目的整理は、制作の専門知識がなくても、むしろ社内の担当者だからこそ進められる工程です。ここを主体的に固めておけば、外部に委託する場合も社内で制作する場合も、公開後の手戻りを減らせます。まずは自社サイトの全ページと運用実態を書き出すところから始めてみてください。