逃げずに、対峙する！ 大規模Webリニューアルの「移行」マネジメント

これに対処するため、ロフトワークでは折々メンバー間でノウハウを共有し、『移行駆け込み寺』などの社内共有ナレッジを蓄積してきました。

このコラムでは、その一端をご紹介します。ちなみに冒頭の「7,000ページ」を捌いた京都産業大学プロジェクトでは、代々の資産を活かして、事後アンケートで「移行がよかった」とわざわざ書いてもらえたほど、移行プロセスをスムーズに進めることができました。移行プロジェクトを仕切るディレクター・PMの視点でぜひお読みください。

数百ページを超える「移行」に対処するには、まず広い視点での「戦略」が必要です。カギになるのは、Webの目的と、予算です。

まずは、Webリニューアルの目的——問合せ獲得や資料請求なのか、物販なのか、メディアサイトとしての広告収入なのか、顧客サポートなのか…　を見極め、ひとつひとつの既存コンテンツの役割を「目的」に照らして整理しましょう。この作業のゴールは、優先順位をつけること。

京産大の場合、「在校生が誇りを持てるサイト」というキーコンセプトを第一に掲げ、以下のような判断基準に照らして、移行優先度の高い約1,000ページを抽出しました。

このように、移行戦略は「情報設計」に密接に関係します。プロジェクトのかなり早い段階から、既存コンテンツの整理と活用を意識しておくことが重要です。

仮にWebサーバ上にHTMLファイルが14,000個あったからといって（実話）、全てを手作業でCMSに登録するなど土台無理な話。経験上、気合いでなんとかなるのは「2〜300ページ」、手作業で移行できる限界が「1,000ページ」。千を超えると全く別のアプローチが必要になります。

手作業の移行作業は、1ページごとにコストがかかります。コストは、1ページあたりの作業難易度によっても変動します。プロジェクト全体でかけられる予算に照らして、現実的な量まで、移行ボリュームを削っていきましょう。優先度の低いページを「切り捨てる」視点には次のようなものがあります。

移行戦略の中で検討したいのが「残置」という方法です。

静的HTMLで作られた過去ページや特設サイトなど、デザインは異なるが閲覧には差し支えない既存ページは、「ディレクトリごとそのまま新サーバにアップして置いておく」という処置ができます。ユーザーの体験上は別サイトのように見えてしまいますが、主要なメニューにはリダイレクトをかけ、必要なら中身のHTMLを更新することもできます。

旧サイトが別の動的CMSで動いている場合など、そもそも残置できない場合は仕方ありませんが、コストをかけずに情報を維持する方法として、「残置」の効果的な活用はひとつの武器になります。

これに似た方法に「ヘッダーフッター差し替え」があります。旧HTMLのヘッダー・フッターのみを新デザインに当て替え、本文部分は旧デザインを保つ方法です。これは新旧ページを行き来した際の違和感を和らげるのに有効です。

しかし、ヘッダーフッター差し替えは、旧HTMLの構成パターンごとに手順を調整する必要があり、特に新デザインでスマホ対応を行った場合など、想像以上に不具合のリスクが高い方法です。同一テンプレートで記事が大量にある場合など、限定的に検討することを勧めます。他にも、CMSの機能によっては「CSV一括登録」などで数が稼げることもあります。

さて、移行の総量が見えたら、登録の手順を具体的に計画していきましょう。段階的に、クライアントと確実に合意を得ながら計画を立てていくことが肝要です。

「移行計画書」は、「移行プロジェクトのプロジェクト計画書」あるいは契約書のような存在。次のような項目立てで、移行作業全体のプランを、関係者と合意します。

これらを決めていく上では、例えば「何日時点のデータをもとに作業するのか」「作業時点から公開までの更新はどうするのか（差分反映や二重更新と呼ばれる手順があります）」「校正の手順や着眼点は」「承認のフローは」など、手続き的なことを細かく決めていく必要があります。逆に、こういった取り決めを曖昧にしたまま進めると、「全体の8割作業が終わった段階で最初からやり直し」みたいな失敗につながりかねません（実話）。

移行計画書が合意されたら、より詳細な「手順」を記述していきます。

「移行ガイドライン」は、新旧のページデザインを見比べながら、見出し・本文・画像・リンクなどの各要素をどのように対応させながらページを作成していくかを定義する資料です。CMSの仕様に沿った「原則編」と、それに素直にはまらない「イレギュラー対応編」の大きく2部で構成されます。

移行ガイドラインは、登録作業を行うスタッフへの指示書としても使われ、校正時に準拠する資料にもなる、実用性の高いドキュメントです。一方、イレギュラー対応を網羅的に盛り込むには、移行対象ページを何度も何度も目視して怪しいものを洗い出す必要があります。「使える」ガイドラインを作るには、経験と「時間」が必要です。

移行ガイドラインを一通り作って、さあ移行着手！

…といきなり始めるのは危険すぎます。準備運動なしでプールに飛び込むようなもの。 ここで必要な準備は「サンプル移行」です。1,000ページの移行に挑む京産大プロジェクトでは、全体の10%に当たる「100ページ」をテスト登録し、その結果をじっくりレビューして、移行ガイドラインを調整した上で、残り90%の作業に臨みました。

「机上」の計画と、実際にCMSで登録した結果には、得てして大きな乖離があるもの。この現実を、ディレクターも、作業者も、クライアントも直視した上で、本移行に臨みましょう。

数百のページを漏れなく管理するには、ツールの力が欠かせません。各種Webサービスを使い倒して、移行をスムーズに進めましょう。

移行作業に欠かせないのが「ページリスト」。主に移行範囲の絞り込みに使う「全ページリスト」（これはWebサーバデータやクローラーを使って作成）と、全移行対象ページの一覧がありますが、ここでは後者について説明します。

移行用のページリストでは、作業対象となるすべてのページに「ID」を振るとともに、「ステータス」を切り替えられるようにします。数十ページならGoogle Spreadsheetでいいのですが、数百ページ規模だと「データベース」ツールが必要。伝統的にはサイボウズデヂエ、最近ではAirtableが便利です。

ページごとの作業用ステータスは、例えば次のような形で準備します。

さらに、クライアント向けの確認用ステータス（OK/NG）を別項目で追加します（ステータスに含めてもいいのですが、確認体制上別にしたほうがスムーズなことが多い）。このステータスが常に正しく更新されるようにメンテし、すべてのページが「クライアントOK」になれば、移行プロジェクトは完了です。

作業が進むと、ページ単位で質問・コメントの応酬が進みますが、複数のページにまたがる質問や手順変更などのやりとりを行うには、別途Backlogなどの課題管理ツールを用意するのがおすすめです。ページリストが情報過多になると一覧性が下がるので、個別の課題をBacklogでつぶしていくと、テンポがよくなります。

作業者とディレクターが必ずしも同じ場所にいない場合、コミュニケーションラインは複数必要です。京産大プロジェクトでもChatwork・Backlog・サイボウズデヂエを併用しましたが、Chatworkは急ぎの連絡のみ（Backlog何番を見てください、というような）、電話はほぼ一度もせずに進めることができました。

移行作業は「ダブルチェック」が鉄則。その分コストはかかりますが、ガイドラインの読み落としやイレギュラーの解釈など、作業者同士のダブルチェックを行うだけでも、品質がかなり安定します。

校正を依頼する場合は、校正の「作業定義」が必要。これは、移行計画書時点で合意しておきましょう。difffなどのテキスト比較ツールを使って文章コピペ時のヌケモレを抽出したり、公開までリンク先が異なる場合の確認方法を規定するなど、校正担当者が「迷わない」ルール決めをすることが、校正品質の向上につながります。