1万ページ超の大規模コーポレートサイトのリニューアルプロジェクトに携わった経験をもとに、
本記事では、プロジェクトを振り返りながら、自身の学びや今後に活かすべきポイントを整理していきたいと思います。
クライアント: 情報通信業界
制作期間: 1年9ヶ月
プロジェクト概要
1万ページ超の大規模コーポレートサイトの全面リニューアルプロジェクト。
一般ユーザーから法人顧客まで、幅広いステークホルダーに向けたサイトで、動的CMSのリプレイスを主軸に、インフラ整備、デザイン刷新、サイト構造の最適化、問い合わせ基盤の構築等が求められていました。
新ビジョン発信の基盤となるオウンドメディア統合も同時に構築し、ユーザー体験と情報構造を見直す必要がありました。
＜重要ポイント＞
- CMS刷新: 動的CMSから静的CMSへのリプレイス
- インフラ強化: 大規模サイトに対応する安定したインフラ構築
- 情報設計改善: 複雑化したサイト構造とUIの最適化
- オウンドメディア統合: 分散した情報発信チャネルの一元化
- 問い合わせ基盤構築: 効率的なリード管理システムの導入
課題
クライアントが抱えていた主な課題は以下の通りです。
＜主な課題＞
- 動的CMSの運用負荷: ページ更新時の負荷増大やページ表示速度の低下などが顕在化
- インフラの脆弱性: アクセス集中時のパフォーマンス低下と安定性の問題
- 複雑な情報構造: 情報構造が煩雑で、ユーザーが必要な情報にアクセスしづらい状態
- 分散した情報発信: サイト内の複数ディレクトリに散在し、一貫した情報発信ができていない
- 非効率なリード管理: メール受付が非効率になっており、分析の仕組みも欠如
解決策
今回実施したアプローチは以下の通りです。
＜アプローチ＞
- 次世代CMSの導入: コンテンツ配信をシームレスに行えるよう静的CMSに切り替え、柔軟な拡張性とセキュリティが強固なCMSを選定。1万ページ超のコンテンツを効率的に管理できる基盤を構築
- クラウドネイティブアーキテクチャの実装: サーバーレス構成による自動スケーリングと負荷分散機能を導入し、トラフィック変動に強いインフラを実現
- ユーザー中心の情報設計: 徹底したユーザビリティ分析に基づくサイト構造の再構築と直感的UIの導入。高機能な検索エンジン実装でコンテンツ到達性を向上
- 統合型コンテンツハブの構築: 分散していた情報発信カテゴリを統合するため、オウンドメディアを構築し、一貫した発信基盤を確立
- デジタル顧客対応システムの実装: 従来のメール対応からWebフォームとCRM連携システムへ移行。問い合わせ管理の効率化と顧客データの戦略的活用を実現
制作プロセス
タイムライン
- 要件定義：4ヶ月
- 設計：4ヶ月
- 開発：4ヶ月
- コンテンツ移行・制作：6ヶ月
- UAT・追いつき・並行運用：3ヶ月
- リリース
プロジェクト体制
- PM：1名
- リーダー：1名
- ディレクター：2名
- エンジニア：4名
- コーダー：2名
振り返り
期日までにリリースできたものの、コンテンツを移行・登録する工程でかなり苦戦しました。
要件定義→設計→開発の各工程の成果物や確定事項が手戻り、後続工程でしわ寄せが来る事態になったため、前工程での認識合わせと網羅的な検証が必要だと感じました。
各工程の詳細と振り返りを以下で整理していきます。
①要件定義工程
概要
RFPに基づき、具体的な要件を顧客と協議しながら整理しました。
要件定義書の目次は以下です。
- プロジェクト概要（背景・目的、要件定義書の範囲）
- ビジネス要件（達成目標、ターゲット分析、サイトの位置づけ）
- 機能要件（システム構成図、機能一覧、CMS要件、検索機能要件、CRM連携）
- コンテンツ要件（サイト構造・ナビゲーション、アクセシビリティ対応、コンテンツ移行計画）
- デザイン要件
- 非機能要件（CMS/Webサイト、検索機能）
- スケジュール（タイムライン、マイルストーン）
- リスクと制約（リスク評価、法的要件）
- 承認プロセス
主なアウトプット
- 要件定義書
課題
認識の齟齬による後続工程への影響
発生した問題：
顧客との議論やレビューを繰り返し要件定義書を作成したものの、重要な点での認識違いが後続工程で発覚。仕切り直しで検討することとなり、スケジュール調整が必要となった。
改善策：
- 要点集約版ドキュメントの作成：詳細な要件定義書とは別に、重要ポイントをまとめた要約版を作成し、全関係者の理解促進を図る
- 意思決定者の明確化: 各要件の最終判断者を明確にし、承認プロセスの透明化を実現
インプット情報や網羅性の検証不足
発生した問題：
施策の妥当性検証や要件の網羅性確認が不十分なまま定義が進められ、開発・テスト段階での手戻りや追加要件による影響が発生した。
改善策：
- 要件定義前プロセスの強化: 要件定義着手前の準備段階で、プロジェクト目標との整合性を検証するフェーズを設ける
- 専門分野別レビュー体制の構築: UI/UX、セキュリティ、パフォーマンスなど専門領域ごとに有識者レビューを実施
- 標準チェックリストの導入: 過去プロジェクトの知見を活かした網羅性確認チェックリストを作成し、検証漏れを防止
- ステークホルダーマップの活用: 関係者の役割と影響度を可視化し、適切なタイミングで適切な関係者を巻き込む
- 未確定事項の明示管理: 要件定義時点で決定できない事項を明示的に管理し、決定スケジュールと影響範囲を共有
②設計工程
概要
コンテンツ管轄部門や各ステークホルダーと密に連携しながら設計を推進。
新ビジョンに沿ったビジュアルデザインの具体化とオウンドメディア統合の方針を策定し、同時にCMS画面設計およびサイト内検索ツールの要件整理を行った。
プロトタイプを活用した早期フィードバックにより、多部門間の合意形成と技術的実現性を効率的に検証した。
主なアウトプット
- ワイヤーフレーム
- プロトタイプ
- CMS設計書
- サイト構成・コンテンツ設計方針
課題
画面設計・ビジュアルデザインのレビュープロセス
発生した問題：
設計工程で決定した方針に対するレビュー不足により、後続工程での手戻りが発生した。
開発後のCMS仕様変更が必要になり、プロジェクト遅延の原因となった。
また、現行サイトの表示仕様維持という重要要件がUAT工程で初めて明らかになり、設計工程の成果が十分に活用されなかった。
加えて、CMSベンダーとのコミュニケーション不足により、CMS実装上の制約を考慮した現実的な設計ができていなかった。
改善策：
- 画面設計仕様の明文化とビジュアル化：設計内容を確定事項として文書化し、ビジュアル資料とともに顧客との合意形成に活用
- レビュー前提の明確化：設計成果物の後続工程での活用方法を事前に説明し、レビューの重要性と影響範囲を関係者に理解してもらう体制の構築
- ベンダーとの連携強化：CMSベンダーとの早期段階からの協業により、画面設計の意図共有とCMS実装における制約の把握を徹底
- 実装を見据えた設計：CMS管理画面の操作性も考慮した実践的な設計アプローチの採用と、プロトタイプを活用した検証プロセスの導入
SaaS製品の検討プロセス
発生した問題：
要件定義段階で選定したSaaS製品が、詳細設計フェーズでの精査により実際の要件に適合しないことが判明。
「できること」「できないこと」の境界が明確でないまま進行したため、検討作業の遅延が発生し、計画変更を余儀なくされた。
この状況により、スケジュール遅延とコスト増加というプロジェクトリスクが顕在化した。
改善：
- 複数製品の並行評価: 要件定義時点で複数の候補製品を比較検討し、代替案を事前に用意
- 技術検証の前倒し: 設計工程前にSaaS製品の設定・制約を確認する技術検証フェーズを設け、実現可能性を早期に判断
- 明確な判断基準の策定: SaaS製品評価のための客観的な基準とチェックリストを作成し、感覚的な判断を排除
- 影響範囲の事前分析: 製品変更が生じた場合のプロジェクト全体への影響を予測し、リスク低減策を準備
- ベンダー情報の積極的活用: SaaSベンダーの技術サポートやドキュメントを積極的に活用し、製品の制約や特性を正確に把握
③開発工程
概要
CMSの各種機能開発とテンプレート実装を中心に進行。
CMSテンプレート用にモックアップを納品し、CMSの開発元会社でテンプレート実装と、各コンテンツのインターフェース開発を実施。
主なアウトプット
- モックアップ
- CMS受け入れ結果
課題
CMS開発受け入れの精度
発生した問題：
前工程での画面要件に基づきCMSベンダーが開発を行ったが、受け入れ検証時の評価視点が不十分であったため、機能の不備や仕様との不一致が発見された。
このため、度重なる変更対応が必要となり、スケジュールの遅延につながった。
改善：
- 受け入れ基準の明確化: 開発着手前に具体的な受け入れ基準を設定し、ベンダーと合意形成
- 中間レビューの強化: 開発途中での中間成果物レビューを複数回実施し、早期に不具合を発見
- ユースケースベースの検証: 実際の運用シナリオに基づいた検証を行い、理論上の要件充足だけでなく実用性も評価
- 専門チームによる検証: CMS専門知識を持つメンバーによる受け入れ検査体制の確立
モックアップの納品遅延と開発スケジュール管理
発生した問題：
モックアップ納品の期限が短期間に設定されていたため段階的納品アプローチを採用したが、CMSベンダー側のリソース不足が重なり、予定していた開発範囲を期日通りに完了できなかった。これにより開発スケジュール全体に遅延が生じ、後続工程への影響が拡大した
改善：
- 現実的な納品スケジュールの設定: リソース状況と工数を正確に見積もり、余裕をもった納品計画を立案
- 優先順位付けの徹底: 機能の重要度に基づく明確な優先順位を設定し、リソース不足時でも主要画面・機能から確実に実装
- 早期警告システムの確立: スケジュール遅延の兆候を早期に検知する進捗管理の仕組みを導入
- リソース計画の見直し: 繁忙期に備えた柔軟なリソース配分計画とバッファの確保
- コミュニケーション強化: ベンダーとの週次進捗会議でリスクを事前共有し、問題発生時の迅速な対応体制を構築
問い合わせフォーム化の開発遅延
発生した問題：
Webフォーム化の開発過程で、メール配信先アドレスに2段階認証を必須とするセキュリティ要件が判明し、既存の配信先アドレス体系の再考が必要となった。
さらに、対象ページの特定や各問い合わせ先の正確な抽出作業にも想定以上の時間を要し、開発スケジュールに遅延が生じた。
改善：
- 事前要件調査の徹底: セキュリティ要件など技術的制約を開発前に包括的に調査
- 現行システム分析の強化: 問い合わせフロー・配信先の完全な棚卸しを計画段階で実施
- 段階的実装計画の策定: 優先度の高い問い合わせフォームから順次実装するアプローチの採用
- 関係部門との早期連携: セキュリティ担当や各部門の問い合わせ管理者との事前協議体制の確立
- 代替案の事前準備: 技術的制約発生時の対応策をあらかじめ用意
④コンテンツ移行・制作工程
概要
約1万ページの既存コンテンツ移行と約200ページのコンテンツ登録・制作を並行して実施。
主なアウトプット
- 移行計画書
- 移行・新規制作対象リスト
課題
移行コンテンツの評価とスケジュール管理
発生した問題：
現行サイトのコンテンツ品質評価が不十分なまま移行作業を開始したため、予想外の修正作業が発生し、スケジュールに大幅な遅延が生じた。
改善策：
- 移行前に現行コンテンツの品質と複雑性を体系的に分析・評価する時間を確保
- 重要度と技術的複雑さに基づいた優先順位付けを実施
- リスクの早期発見と対応のための余裕を持ったスケジュール設計
検証方法の見直しと確認体制
発生した問題：
機械的な処理に依存した検証方法により、特にレスポンシブ対応においてスマートフォン表示の不具合を見逃し、顧客レビューで多数の指摘を受けた。
改善策：
- ソースコードの記述揺れを事前分析し、想定されるバリエーションを網羅的に洗い出す
- 確認項目ごとの責任者を明確化した目視確認プロセスの強化
- 対象機種や環境ごとの確認パターンを事前定義し、網羅的な検証体制を構築
手動作業のチェックプロセス
発生した問題：
手動によるコンテンツ移行・修正作業でのミスが多発し、品質問題の原因となった。
改善策：
- 手動作業タスクの事前レビューと複数人チェック体制の評価・導入
- マネージャーによる確認フロー設計と作業負担分散の最適化
- タスク分割によるシングルポイント作業の削減と相互確認体制の確立
⑤UAT・追いつき・並行運用
概要
前工程で移行した既存コンテンツのユーザー受け入れテスト（UAT）を実施し、実際の運用環境での機能検証と品質確認を行った。
同時に、期間中に発生した新規コンテンツの追いつき対応を進め、リリース1ヶ月前からは現行サイトと新サイトの並行運用体制に移行した。
主なアウトプット
- UAT・追いつき対象リスト
- リダイレクト設計書
課題
コンテンツ修正管理の非効率性
発生した問題：
ページ確認を段階的に実施していたが、各事業部門とのコンテンツ修正管理が煩雑化。
その結果、指摘事項の抜け漏れが発生し、進捗状況の把握が困難になったため、当初想定を大幅に超える確認・修正作業が発生した。
改善策：
- Backlogなどの課題管理システムを活用したタスクの可視化と進捗管理の徹底
- 修正の優先順位や確認ルールを事前に定め、対応負荷を軽減する仕組みの構築
リリース計画の検討遅延
発生した問題：
コンテンツ修正やUAT対応に追われたことでリリース計画書の作成が後回しとなった。
顧客側のリリース判定期限を十分に考慮せずに進行したため、最終的にリリース予定日を2週間延期する事態に陥ることとなった。
改善策：
- UATフェーズ開始前にリリース計画を策定し、顧客側のリリース判定期限を事前に共有・調整
- UAT進行と並行してリリース準備作業を進め、遅延発生時にもスケジュールに影響しない余裕を確保
- 定期的な進捗確認を通じてリリースリスクを早期に検知し、迅速な対応が可能な体制を整備
今後に活かすべきポイント
各工程の振り返りを通して、今後に活かすべきポイントを整理します。
①意志決定・設計内容の共有・管理体制の強化
- 体系的なドキュメント管理システムの構築: 設計や意思決定履歴を追跡できるよう、フォルダ構造と命名規則を標準化し、版管理を徹底する
- 統一タスク管理ツールの導入: チーム全体で同一のツールを使用し、アクセス権限や更新ルールを明確化する
- 設計ドキュメントのテンプレート整備: モックアップやデザインでは表現できない機能要件や動作仕様を文書化するためのフォーマットを作成する
- 定期的な共有会議の設定: 重要な決定事項や設計変更について週次で共有し、認識齟齬を早期に解消する
②顧客社内コミュニケーションの最適化
- 事業セグメント別の窓口と責任範囲の明確化: 担当者ごとの決裁権限と対応範囲を文書化し、合意を得る
- 質疑応答プロセスの体系化: タスク管理ツールを活用し、問い合わせから回答までのフローと期限を設定する
- 情報共有プラットフォームの事前構築: 顧客とベンダー間で安全かつ効率的に資料を共有できる環境を整備する
- コミュニケーション計画書の作成: 定例会議、レポート提出、エスカレーションルート等を明記した計画書を策定する
③コンテンツ確認方法の事前確立
- 確認項目・基準の明確化: 1万ページ規模のCMS移行に適した段階的かつ効率的な検証方式を策定する
- 検証環境と対象機種の選定基準の合意: 優先度に基づく検証対象の選別方法を確立し、顧客の同意を得る
- 自動テスト導入の検討: 繰り返し確認が必要な基本機能については自動テストを実装し、効率化を図る
- ユーザー参加型の検証計画: 実際のエンドユーザーを交えた検証機会を計画的に設定し、本番環境に近い使用感を早期に確認する
④現実的なプロジェクト計画と柔軟な対応体制
- 段階的リリース計画の採用: 完成形を早期に提示できるよう、コア機能から順にリリースする方式へ変更する
- バッファを含めたスケジュール設計: 変更要求に対応できる十分な修正期間を最初から計画に組み込む
- リソース配分の最適化: 修正フェーズでの人員増強を見込んだ要員計画を立案する
- 変更管理プロセスの厳格化: スコープ変更時の影響評価と承認フローを明確にし、計画への反映方法を確立する
⑤要件の明確化と契約内容の充実
- 包括的な要件定義書の作成: 実施内容だけでなく、明示的に「対象外」とする項目も詳細に文書化する
- 契約条項の精緻化: スコープ外対応の取り扱いや追加開発に関する料金体系を契約書に明記する
- 変更管理手続きの契約化: 要件追加・変更時の承認プロセスと費用・期間への影響評価方法を契約に含める
- 定期的な要件レビュー会議の設定: プロジェクト進行中も要件の認識合わせを行い、齟齬を早期に解消する仕組みを構築する
まとめ
今回、規模・難易度ともに高いサイトリニューアルプロジェクトに取り組み、無事リリースまで完遂できたことは大きな成果となりました。
約2年にわたるプロジェクト期間を通じて、初期段階でどのポイントをすり合わせるべきか、数多くの学びを得ることができました。
これらの経験を今後に活かすため、各ポイントについて整理し、改めて記事としてまとめていきたいと思います。
コメント