大規模サイトリニューアルについて考察・1
大規模なWebサイトのリニューアルに携わったことはありますか?
規模の大きなWebサイトリニューアル等を行う場合、小規模なリニューアルや更新ではさほど表面化してこない数々の問題が出てきます。それらの問題はことごとくクリアしていく必要があると思いますが、一体全体、世の中、多々ある制作会社ではどの様に対応してるのでしょうか?
例えば、次の様なテストケースを考えてみます。
- Webサイトのリニューアルの目的は、企業同士の合併。
- 「サイト公開日 = 企業合併日」でマスト。
- 新サイトのコンテンツ = 元の両企業のコンテンツ修正版 + 新コンテンツ。ただし、サイト構成は新サイトに合わせた新しいものとなる。
- サイトの規模は5,000ページ程度
- CMS等は導入されていない。またリニューアル時に導入することも考えていない。
- クライアント企業は大組織であり、多くの部署からWebコンテンツに対する要望がある。窓口も完全に一つに集約するのは現実的には難しい。
- 企業内でのコンテンツチェック、原稿作成等も組織内各部署で行われる。
- 現存コンテンツの更新は、複数の代理店、複数の制作会社に発注されている。また「どのコンテンツはどの会社に」といった明確な切り分けも存在しない
- リニューアルは1つの代理店のみに発注される。
- リニューアル期間は長期(半年程度)にわたる予定で、その間にも既存コンテンツはどんどん更新されていく
ちなみにこの例は、以前私自身が制作会社で関わった案件を多少アレンジしたものです。
それぞれ、主に次の様な分担を担いつつ、リニューアルを進行していきました。
| 企業: | 原稿の作成。制作物のチェック |
|---|---|
| 代理店: | 企業からのヒアリング。原稿の整理。新サイト構成の決定 |
| 制作会社: | 新サイト構成の検討・提案。デザイン、コーディング。 |
もちろん完全にこの様に仕事が分けられる訳ではなく、お互いの範囲を大なり小なりカバーしながら進んでいきます。
前回、私が関わったケースでは、実際にこの規模のリニューアルをやり遂げた訳ですが、決してBESTな方法だったな〜・・とは思っておらず、色々問題点が出てきました。
主だったものは、次の様なものでしょうか。
- リニューアル期間中も、既存のサイトにはどんどん変更が加わっていく。リニューアル中の新サイトにはその変更が反映されないため、結果、先祖返りを起こしてしまう。
- リニューアル期間中も、既存のサイトにはどんどん変更が加わっていく。新サイトの構成にそぐわないものについて、再度の検討が都度発生。
- 上記理由により、チェック&修正を何度も繰り返す。元の規模が5,000ページと大きいため、結果ものすごい作業量となってしまう。
などなど。
数多くできる経験ではないものの、次の機会に向けて、たとえ少しずつでもこれら問題点を解決できる作業フローを検討していくことで、よりよいサイト構築のノウハウに繋げていけると考える訳です。
この規模のものを考え出すと、自分なんかは、bA とか ミツエー なんかが脳裏に浮かぶわけで(本当のところは知らないですけど・・・)、「こういう仕事はそういう所に頼んだ方がいいですよ」と提案したくなることも正直あったりするのですが、やっぱりそれだとプロ失格で、たとえ結果的にそういう提案をするとしても、フローなり何なりをよくよく検討した上で、こうこうこういう理由だから、そちらがお勧めですよ、と言えねばならない訳です。
さて、具体的にどの様な所を改善できて、どの様なフローを確立していけるものか、うだうだ考えたいと思います。(もしこのエントリーに目をとめて頂いた方がいらっしゃれば、コメント頂いたりしながら一緒に考えていければ嬉しいです。)
—
まず今回のエントリーでは、具体的なフローに落とし込んでいくよりまだまだ前のアイデアレベルの小さい改善案や、こうなったら仕事が進めやすいといった案を、幾つか挙げてみようと思います。
- 企業内にWebマスターを立てる
- リニューアル期間中は、通常更新の発注先は、1社限定にする
- 他社に発注して通常更新を行った際には、全ての更新内容、更新したファイル等の情報をリニューアルを担当している代理店&制作会社にも連絡する。
- 通常更新が発生する際には、新旧両サイトに更新を反映させる
- プリントアウトに手書きで指示書く時は、読める字で
- プリントアウトによる先祖返りを防止するため、プリントアウト時のフローを確立する。「○月○日〜○月○日は制作側は更新しません」「○月○日にプリントアウトしてください」「○○をプリントアウトしましたと必ず連絡するのを規則化する」など
- 更新指示には管理番号を付ける。例えばプリントアウトの様なものにも管理番号の記載された表紙を付ける
- バージョン管理を整理して行うため、バージョン毎にテストサーバを用意する
- Webサイトを、例えばコーナー毎等、分解して管理する。それぞれ別途にスケジュールを立て、バージョン管理を行いながら、進行する
- 全体の進行管理は代理店が行う、バージョン管理は制作会社が行う、○○は企業が行う、といった役割分担を明確にする
- 「デザインフェイズ」「情報整理フェイズ」「原稿作成フェイズ」「コーディングフェイズ」等、なるべく明確に分ける。(極端な例だと、デザイン検討してるのに、てにをはの修正依頼をする・・みたいなのを無くす)
まだまだ出てきそうですが・・・。
実際問題、これらの中には実現不可能なものも、あるいは実はそんなに良くないかもってものも、多く含まれてきます。
具体的に「これを行うことで、どういったメリットが得られる」ということを踏まえながら、これらを取捨選択して、業務フローを検討し作り上げていくのが次の大きなステップでしょうか。
その際に、「優先すべき事項については、企業&代理店&制作会社で共通認識を持ち徹底する」、「実現不可能な場合には代替えとなる案、こういうやり方なら可能だといったアイデアを出し合う」、などなどクリアして詰めてくってのが、重要な気がします。例えば、代理店&制作会社だけが認識していても、企業が知らないままの状態だと全くもって不十分だし、三者三様に自分勝手な要望を出すのではなく、共通認識として完成させるのが、かなりかなり大事な部分になってくると思います。
—
ちょっとまだまだまとまらないですが、2 以降に続きます。
11:16 PM
な、何て参考になるエントリイ…orz
プリントアウトによる先祖がえりは盲点でした。
>「プリントアウトに手書きで指示書く時は、読める字で」
すごく同意しました。笑
10:08 PM
>fumopan
プリントアウトとか、そういう普段の日常業務でもできそなところは、今のうちから少しずつフロー化していくのも良い手かも知れないね、関係者もしっかり巻き込んで。
で、相変わらずな字なのかい? 手書き指示書。
6:19 PM
すごい今更レスですが…(すみません
プリントアウトは若干進化したかもしれません。近日の案件では管理番号が導入されました(うちは何もしてませんが…)。ただ、管理番号の整合性がとられていなかったために新たな混乱も発生しました。なかなか難しいですね。
因みに手書きの伝統は今も健在です。最近たまたまOCRの機能を試してみたんですが、お話にならない読み取り結果で笑いました。手書きの壁は高いっすね。
10:49 AM
>fumopan
電○鬼十足にも「振り回されるよりも振り回せ!」なんてのがある様に、もろもろは、先手必勝!です。
そして、ディレクターの鉄則は、「前準備にこそ時間を掛けろ」です。(プロジェクトは後半になるほど実コストが掛かる)
先に手を回して、こちらのペースに乗せる・・・そんな手を常に打てる仕事をしたいね〜〜。
んな簡単ではないかも知れんが。