サービス紹介だけを新しくしたら、予約ボタンの先には以前の料金が残っていた。旧ページでは電話、新ページではフォームを案内しており、受付担当もどちらが正しいか迷っている。ページを少しずつ改修すると、このような新旧の境目を管理する仕事が生まれます。
段階的なリニューアルでは、公開するページ数と日程に加えて、その期間に利用者が何を読み、どこで申し込むかを決めます。各段階の共通情報、受付先、不具合時に戻す範囲を対応させれば、部分公開の条件を制作会社と具体的に話せます。本稿は、改修範囲を選んだ後のつなぎ方を扱います。予約付きサービスの例と段階表は、実績ではなく説明用の架空案です。
一回の公開で、利用者が目的を終えられる範囲を選ぶ
「今月は三ページ」という区切りだけでは、公開できる範囲は決まりません。サービスを選び、条件を読み、予約を送るまでに必要なページをたどります。新しくするページの枚数が少なくても、その先の受付が説明と食い違えば、利用者の目的は途中で止まります。
架空の体験サービス会社で、最初にサービス紹介、次に予約フォーム、最後に残りの案内を改修する案を考えます。第一段階で新しい紹介ページから旧フォームを使うなら、旧フォームでそのサービスを選べること、料金や対象条件が一致することが公開条件です。旧フォームが対応できなければ、紹介とフォームを同じ段階で直す案に組み替えます。
旧画面を経由すること自体で失敗と決める必要はありません。色や余白が異なっていても、会社名、サービス名、申し込む内容がつながり、次の操作を理解できるかを見ます。反対に、見た目をそろえても、新しい説明にある日時をフォームで選べなければ、受付まで完成したことにはなりません。
公開単位を決める打合せでは、入口、詳しい説明、受付、完了後の案内を一続きにして示します。旧側に残す部分にも確認担当を置きます。「今回は改修しない」と「今回の公開確認から外す」は別の判断です。新しいページから使う既存機能は、部分公開の確認範囲に含めてください。
担当を割り当てる際は、画面を操作できる人と、掲載条件が正しいか判断する人を区別します。兼務でも構いませんが、制作側の表示確認だけで料金や受付条件まで承認済みにはしません。事業担当の確認が済んでいない箇所は、次の段階へ送るのか、今回の公開を待つのかを決めます。
段階を細かくすると、毎回の確認や共通情報の二重更新が増える場合もあります。小さく出すほど費用が下がるとは限りません。同時に直す必要があるページと、独立して公開できるページを整理し、制作量だけでなく併存期間の更新作業も見積もりへ含めます。
共通情報は、正しい内容と反映先を先に決める
新旧ページに繰り返し出る情報を集めます。料金、受付時間、サービス名、電話番号、予約へのリンク、会社情報などです。同じ内容でも、共通部品から表示する箇所と、原稿へ直接書き込んだ箇所が混ざっていることがあります。一か所を変更すれば全部が変わると思い込まないようにします。
最初に決めるのは、内容を確定する人と、確定済みの情報を置く場所です。たとえば料金なら事業担当が適用日を含めて決定し、更新担当が新旧の掲載箇所へ反映します。古い画面の文章を正本にするのではなく、確認済みの内容を基に両方を照合する形にします。
次に反映先を記録します。料金表だけでなく、予約フォームの選択肢、確認画面、自動返信の案内にも同じ条件が出る場合があります。共通部品の更新で変わる範囲は制作担当が調べ、個別に直す原稿と区別します。新ページの担当と旧ページの担当が違うなら、作業の受け渡し先も必要です。
改修の途中に通常業務の変更が入ることも想定します。料金改定が決まったとき、公開中の旧ページだけを直すと、制作中の新ページが古い内容で公開されかねません。公開中と制作中の両方へ変更を知らせ、どの版まで反映したかを残します。公開直前には、初稿時の内容ではなく、その時点で有効な条件を照合します。
ただし、すべての情報を同じ日に一律で切り替えるとは限りません。既に予約した人と、変更日以降に申し込む人で適用条件が異なる場合は、対象と日付を案内へ書きます。その区分は事業側が決め、制作側が画面の都合で変更しないようにします。
名前とメニュー順は、新旧をまたいで確かめる
同じ予約フォームへ進むボタンが、旧側では「体験予約」、新側では「お問い合わせ」になっていると、別の窓口に見えることがあります。リンク先だけでなく、その操作で何ができるかを名前から判断できるかも確認します。予約が確定しない相談窓口なら、予約できるように見せる名称は避けます。
W3Cの一貫した識別に関する解説では、ページ群の中で同じ機能を持つ要素を一貫して識別できることを扱っています。すべてのボタンを同じ文字列にするという意味ではありません。自社の新旧ページでは、同じ機能の呼び方が理由なく変わっていないかを点検する観点として使えます。W3C：一貫した識別
共通メニューも並べて見ます。旧側が「サービス・料金・予約」の順で、新側だけ「予約・サービス・料金」に変わるなら、ページを移るたびに探す位置が変わります。追加した詳細メニューと、繰り返し現れる共通項目の順序を区別し、共通項目を探す手がかりを保てるか検討します。
W3Cの一貫したナビゲーションの解説は、繰り返すナビゲーションの相対的な順序を扱っています。ページに応じた下位項目の追加を一律に禁じるものではありません。新旧の全画面を同じ見た目にする義務と読み替えず、共通の移動先を見つけやすくする確認へ用います。W3C：一貫したナビゲーション
文字で表示する名前と、読み上げられる名前が異なる要素も確認対象です。アイコンだけのメニューや画像のリンクは、制作担当に操作時の名称も見てもらいます。ここで挙げた二つの観点を点検しただけで、サイト全体がアクセシビリティの基準に適合したとは判断しません。
公開段階ごとに、受付先までの対応を一行にする
次の表は、架空の体験サービスサイトで使う打合せ案です。第一段階では旧フォームが新しい説明の内容を受け付けられ、第二段階では新フォームの受信確認まで準備できることを前提にしています。どのサイトにも同じ順番を当てはめるための表ではありません。
| 公開段階 | その時点の共通情報 | 利用者の受付先 | 不具合時に検討する戻し先 |
|---|---|---|---|
| 第一段階：サービス紹介 | 新旧の料金・サービス名・予約リンクを照合 | 新紹介から、対応確認済みの旧フォームへ | 紹介ページと関連リンクの直前版 |
| 第二段階：予約フォーム | 旧側の予約ボタンも新しい受付先へ更新 | 新旧の案内から、新フォームと完了案内へ | 再利用できるか確認済みの旧受付経路 |
| 第三段階：残りの案内 | 暫定案内や重複した掲載箇所を整理 | 全対象ページから、決定済みの受付先へ | 今回変更した案内・共通部品の範囲 |
表には実際のURL、公開予定日、作業者、確認者を添えます。「旧フォーム」とだけ書くと、複数あるフォームのどれを指すか分かりません。戻し先も、保存した画面の画像だけでは再開できないため、制作担当が実際に復旧可能な状態と条件を確認します。
第二段階では、新ページの予約ボタンだけを確認して終えないことが大切です。旧記事、トップページ、料金案内など、公開を続ける入口から新フォームへ進みます。ブックマークや配布済み資料から旧受付URLへ来る人をどう案内するかも決め、入口が残っているのに誰も受信を見ていない状態を避けます。
テストでは、送信後の画面表示と、担当者が受信して内容を把握できることを別々に確かめます。自動返信に古い窓口や受付条件が残っていないかも見ます。テスト用の送信は担当者間で取り扱いを決め、実際の予約として処理されないよう区別します。
戻す画面と、残す受付記録を混同しない
公開後に問題が出た際の判断を、公開前に用意します。文字の欠けを修正して継続できる場合と、申し込みを送れず受付経路の変更が必要な場合では、対応する範囲が違います。想定する不具合、連絡先、継続か切り戻しかを決める人を段階表へ添えます。
ここでいう切り戻しは、直前の画面や設定など、決めた範囲を元へ戻す対応です。サイト全体の過去の状態を一括で復元すればよい、と考えないでください。新フォームの公開後に受け付けた予約や、その後に変更した業務情報は、画面を戻す作業とは分けて保持・照合する必要があります。
たとえば新フォームを停止し、旧受付経路を再開する案なら、既に受信した申し込みを誰が処理するかを決めます。利用者へ再送を頼む前に、受け付け済みかを担当者が調べられる状態にします。二つの窓口で同じ予約を受けた場合の照合担当も決めておくと、画面の復旧だけで対応を終えずに済みます。
旧フォームが今の条件を受け付けられない場合、戻せるとはいえません。旧経路を維持する期間、再開できる条件、使えないときの案内を事業側と制作側で決めます。代替の電話受付を載せる場合も、実際に対応できる時間と担当が必要です。未確認の窓口を緊急用として書き足さないようにします。
復旧方法は、使うシステムとデータの保存先によって異なります。制作担当には、戻るページや設定、戻らず残る記録、復旧後に照合する内容を説明してもらいます。実行手順と所要時間が未確認なら、段階表でも「確認待ち」とし、単にバックアップがあることを公開可否の根拠にしません。
次の段階へ進む条件と、併存を終える条件を残す
第一段階の公開後は、予定日になったことだけで次へ進めないようにします。新旧の主要な入口から受付まで進めること、共通情報の修正が反映されていること、発生した問題の対応先が決まっていることを確認します。残っている問題が次の改修へ影響するなら、公開範囲や日程を調整します。
途中で段階を組み替えた場合は、旧版の予定表を残したまま口頭だけで進めないようにします。何を前倒しし、どの入口と受付先が変わるかを更新し、担当者へ共有します。変更日と判断理由が分かれば、後から古い予定に沿ってリンクを戻してしまう行き違いも防ぎやすくなります。
URL変更も伴う場合は、画面の段階表に加え、旧新URLの対応を制作担当と整理します。Googleのサイト移転の公式資料は、URL変更を伴う移転について、条件に応じた段階的な進め方や、ドメイン・CMS・レイアウトなどの変更を一つずつ進める考え方を示しています。すべての改修で段階公開が適する、という保証ではありません。Google：サイトを移転する方法
小さな範囲で問題が出なかったことだけで、残りの全ページも同じと判断しないことも必要です。別のサービスには別フォームがあり、共通部品の仕組みも違うかもしれません。次の段階で増える入口、扱う条件、操作を確認対象へ追加します。
最後に、暫定の案内を外す条件を決めます。旧ページの更新担当をいつまで置くか、旧受付先の監視をいつ終えるか、二重に管理していた情報をどこへ集約するかを確認します。旧経路への利用が残る場合は、その人が現在の案内へ進める状態を整えたうえで、運用を終える判断をします。
まずは最初に公開したいサービスを一つ選び、入口から受付までをたどってください。新しくする部分と残す部分を対応させ、共通情報の更新先と、問題が起きた場合の対応を一行にします。その案を基に、どこまでを一度に改修すれば利用者が迷わず使えるかを制作会社と決められます。
参考・出典
- W3C：Understanding SC 3.2.4 Consistent Identification — 同じ機能の要素を一貫して識別する観点。
- W3C：Understanding SC 3.2.3 Consistent Navigation — 繰り返すナビゲーションの相対的な順序。
- Google検索セントラル：サイトを移転する方法 — URL変更を伴う移転の計画部分を参照。
確認日：2026年9月21日。サービス会社、三段階の計画、表と図は編集上の架空例です。公開条件と復旧方法は実際の構成に応じて確認してください。
