Main menu

Column コラム

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

Satoshi Iritani

クリエイティブディレクター / ファシリテーションエヴァンジェリスト
入谷 聡

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

突然ですが、問題です。
あなたは、7,000ページの既存コンテンツを持つWebサイトのリニューアルプロジェクトを担当することになりました!
50ページくらい、デザイナーと一緒にデザインを制作します。
では、残る6,950ページは、一体どうなるのでしょう?

情報設計⇒デザイン⇒コーディング⇒CMS開発…
さまざまな本でWeb制作のワークフローが紹介される中、見過ごされがちなのが「移行」というプロセスです。

Webリニューアルプロジェクトでは、過去に「自由な」ポリシーで作られた多様な既存ページを、新しいコンセプトと目的に沿って統合していかねばなりません。CMSの導入はその基礎になりますが、表組や、画像や、複雑なレイアウトや、アニメーションや独自プログラムなど、一筋縄ではいかないコンテンツ群が大抵存在し、プロジェクトの終盤はその処遇に頭を悩ませることになるでしょう。CMSへのコンテンツ登録を中心としたこの過程をロフトワークでは「移行」と呼んでいます。

移行は、難しいです。

難しいことすらイメージしにくい移行ですが、実際多くのプロジェクトで「炎上」の原因になり、スケジュール遅延やコスト超過をもたらしています。たとえば…

● 登録作業開始後にテンプレートのバグが見つかり、入力をやり直す羽目に…
● 想定していた手順通りに作業したのに、レイアウトが大きく崩れる
● 一覧ページ用のサムネイル画像を用意し忘れ、全ページ再作業になる
● スケジュールが押しまくり、3日で500ページ確認しないといけない(無理)
● リンク切れ、リンク貼り忘れ、リンク先がテスト環境 etc...


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

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

(1) 戦略設計 - 目的こそ全て

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

目的に照らした優先順位付け

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

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

1. 「見てほしい」ページ ⇒キーコンセプトに合致する、課外活動や研究紹介のアーカイブ
2. 「見られている」ページ ⇒アクセス解析で直近3年間のPV数が一定基準を上回るもの
3. 「見られやすい」ページ ⇒新しいサイト情報設計に沿って2クリック以内にあるもの
4. 「見えなければならないページ」 ⇒大学広報の「情報公開」業務上、更新が必須のページ


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

コストに照らした分量のスリム化

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

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

● ディレクトリの「深さ」で切る(例:第5階層以下は原則移行しない)
● 記事の「鮮度」で切る(例:2年前より古いニュース記事は移行しない)
● ページの「更新可能性」で切る(賞味期限の過ぎた特設サイトは移行しない)



「移行」の定義と移行以外の方法

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

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

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

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

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

(2) 計画づくり - 成功を描く

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

「移行計画書」を書く

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

● スコープ(作業範囲)
● 作業手順定義
● 品質基準
● スケジュール


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

移行ガイドラインを書く

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

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

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

サンプル移行を行う

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

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

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

(3) 監視とコントロール - 網羅せよ

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

全件リストを作ってステータスを更新

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

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

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

● 00_未着手
● 10_移行作業完了
● 20_校正作業完了
● 21_質問有
● 30_LW確認
● 31_要修正
● 40_LW保留
● 50_LWOK
● 60_FIX


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

細かいやりとりはBacklogで

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

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

侮れない「校正」の力

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

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

最後に:PJ成功のカギを握る「コンテンツ」へのコミット

さて、これほど重厚な手順を踏んでまで行う「移行」の意味とは何でしょうか?

それは、「コンテンツ」こそ、Webサイトの価値であるということです。

例えば、マーケティングサイトで製品の具体的な使い方を伝える「事例」コンテンツ。
例えば、過去の実績訴求につながる、ニュースリリースのアーカイブ。
例えば、大学サイトにおける教員プロフィールや学生の活動レポート。

こういったコンテンツを、表面的なリニューアルで捨ててしまうのは、あまりにももったいない。Webは育てていくメディアであって、蓄積されたコンテンツを活かすことは、リニューアルプロジェクトの「裏目的」の一つですらあるかもしれません。

ユーザーのニーズに対して、価値のあるコンテンツを提供していくこと。これを実現するプロジェクトマネージャーには、一方で多大な「時間」が要求されます

精緻な計画を立てる時間、チームメンバーやクライアントにじっくり説明をして合意形成をしていく時間、何百ページにわたるリストを何回も目視して、イレギュラーを拾い質問に答えて品質を上げていく時間。

でも、そうやって「コンテンツ」にコミットすることが、Webリニューアルプロジェクトを成功に導くカギだと思います。この記事で紹介した移行のナレッジが、一つでも多くのプロジェクトを助けることにつながれば幸いです。

執筆者

Satoshi Iritani

クリエイティブディレクター / ファシリテーションエヴァンジェリスト入谷 聡

ロフトワーク京都でWebサイト制作プロジェクトを主導するクリエイティブディレクター。堅実なプロジェクトマネジメントを得意とする、ロフトワークきっての理論派。優れた情報整理能力と洞察力・言語化スキルで数々のクリエイティブを飛躍させてきた。PMI認定PMP(*)。1児の父。

最近執筆した記事

コメント

blog comments powered by Disqus