「サイトリニューアル」についてご説明いたします！！

1. ブランドイメージ
2. サイトの機能・利便性
3. サイト管理業務の効率化
4. セキュリティ向上
5. 分析機能の強化

• (a) 経営戦略・経営課題の実現(トップダウン)
• (b) 現行サイトの課題解決のため(ボトムアップ)
• (c) 物理的制約に起因(インフラ・基盤の老朽化で移築せざるを得ない等)

(a)の場合は、経営戦略・経営課題がまず提示され、その実現として前述①～⑤のような刷新ポイントが決まります。
逆に(b)の場合は、現行サイトの運用中に出てきた課題のうち、「サイト改善」では対応しきれないものをリニューアルで対応します。
発端として意外に多いのが(c)ではないかと思いますが、移築に付加価値を付けるため、目的は(a)＋(c)、(b)＋(c)などの抱き合わせになるようです。

要件定義フェーズでは、まず、業務要件の確認とブラッシュアップを行います。プロジェクト開始の段階で判っている要求事項(≒何を踏襲し、何を刷新するか)を念頭に置きながら、新サイトのスコープ･業務フローを確認し、具体化にしていきます。
次に、その実現として、どのようなサイトにするかを定義します。サイト構造、データの取り扱い、機能などです。CMSやサイトテンプレートをベースに構築する場合は、業務要件と標準機能のFit&Gapを行い、新サイトのために個別開発するべき機能が何か、を、定義します。
WEBSASの例では、ワイヤーフレームも要件定義の段階で定義します。ここである程度形にした上で確認することにより、構築フェーズでの手戻りを減らすようにします。
また、「サイトリニューアル」ですので、「現行サイト・現行業務」からどのように「新サイト・新業務」に載せ替えるか、といった点も検討します。

サイト構築フェーズでは、要件定義に基づいて、デザイン及び機能の作成、テストを行っていきます。
設計書・デザイン・コンテンツといった成果物で、完成イメージとの齟齬がないか段階的に確認しながら、開発・テストＵＰ後の受入検証で最終確認を行います。
その後はサイト切り替えの準備期間となり、運用テストとコンテンツ移行を並行して進めます。
運用テストでは、まず運用手順を策定し、実際の運用チームでテスト業務を回します。実施結果に基づいて手順のブラッシュアップを行い、リニューアル後の本番業務に備えます。

「サイトリニューアル」自体は、構築すれば一旦終わりとなりますが、「サイト運用」はその後長く続きます。
コンテンツの更新やサイト分析～改善のサイクルについて、どのくらい(量・間隔)、どうやって(自社かアウトソースか)など、想定を置いて準備します。
ここで大きな想定違いがあると、サイトリニューアル後に業務が回らず困ることになりますから、根拠を持って想定しておくことが重要です。

これはサイトリニューアルに限らないことですが、検討を進めていると、後から想定以上の課題が見えてくることがあります。
よくあるのは、要件定義フェーズで俎上に上がらずスコープ外となっていたものが、構築フェーズに入ってから必要と判明する、といったケースです。
課題は切り替え前に解消したいのが人情ですが、期間・費用は大抵限られているため、解決が難しい場合はスコープアウトも検討しなければなりません。
そんな時は、「サイトリニューアルの目的」に立ち返って優先度付けを行い、取捨選択を行う必要があります。
例えば主目的が経営課題「売上拡大(≒集客)」の対応である場合、サイト運用上の課題はその次以降の優先度になるので、サイト運用上の課題は一旦マニュアル対応とし、次フェーズ以降で対応する、といった判断です。