Webサイト要件定義書の書き方
社内説明・制作会社共有に使える構成例

Webサイトリニューアルの要件定義書は、機能を漏れなく並べるための仕様書ではありません。今回のプロジェクトで何を実現し、どこまでを対象とし、何を今後決めるのかを、関係者が同じ言葉で確認するための文書です。

社内の役員や関係部門は、CMSの細かな機能よりも、「なぜ今リニューアルするのか」「どの課題を解決するのか」「費用と期間はどの程度か」を知りたいものです。一方、制作会社やCMSベンダーは、対象範囲、運用体制、移行条件、必須要件を知る必要があります。読み手が異なるため、冒頭で全体像を示し、その後に詳細を配置する構成が有効です。

この記事のポイント

• 要件定義書は、合意形成と外部相談の共通土台として作る
• 冒頭に1枚サマリーを置き、案件の全体像を短時間で理解できるようにする
• 決定事項、仮置き事項、未決事項、提案依頼事項を分けて記載する
• 機能一覧だけでなく、運用体制、コンテンツ、移行、非機能要件を含める

要件定義書には三つの役割があります。第一に、社内の関係者が目的と対象範囲を合意すること。第二に、制作会社やCMSベンダーが案件の前提を理解すること。第三に、プロジェクト途中で要望や判断が変わった際に、当初の合意へ立ち戻れることです。

したがって、要件定義書は一度書いて終わる資料ではありません。検討の進行に合わせて更新し、変更した項目には決定日、決定者、変更理由を残します。最終的には、制作・実装・移行・運用設計の基準文書として利用します。

長い資料を最初から読んでもらうのは難しいため、冒頭にプロジェクトの全体像を置きます。社内説明では、この1枚だけで案件の必要性と判断事項を説明できる状態を目指します。

背景だけでは、現状への不満の説明で終わります。目的だけでは、理想論になりやすくなります。「現在どのような問題があり、その結果どの業務・ユーザーへ影響が出ており、リニューアル後にどの状態へ変えたいか」を一続きで記載します。

対象範囲は一覧と境界条件で書く

「コーポレートサイト一式」だけでは、PDF、フォーム、採用システム、IR外部サービス、英語ページが含まれるか判断できません。ドメイン・サブドメイン、ページ種別、言語、機能、データ、外部サービスの単位で一覧にします。対象外の理由と、リンク・デザイン・ログイン連携など最低限の接続条件も記載します。

ターゲットはサイト内の行動まで書く

「顧客」「求職者」といった属性だけでなく、何を探し、どのページへ到達し、最終的に何をしてほしいかを記載します。これにより、サイトマップやCTAの判断基準になります。

運用要件は実際の業務フローで書く

「承認機能が必要」だけでは不十分です。誰が原稿を作り、誰が確認し、誰が公開承認するのか、通常更新と緊急更新でフローが異なるかを記載します。担当者の異動時のアカウント管理、操作研修、問い合わせ窓口も含めます。

機能要件は利用シーンと優先度を付ける

機能名、利用部門、利用頻度、必要な理由、優先度、想定するデータ、標準対応・個別対応の区分を記載します。これにより、候補CMSの機能表を機械的に埋めるのではなく、自社の運用への適合性を評価できます。

非機能要件は確認方法まで書く

「高いセキュリティ」「表示が速い」のような抽象表現では、提案各社の回答がそろいません。対象となるガイドライン、監視、バックアップ、復旧、ログ、性能目標、アクセシビリティの達成水準、テスト方法などを、現時点で分かる範囲で記載します。

要件一覧は、本文の補足資料として表計算ソフトで管理する方法も有効です。本文では方針と重要要件を説明し、一覧では個々の要件の状態と進捗を管理します。

• 経営・責任者レビュー：背景、目的、対象範囲、予算、スケジュールを確認する
• 関係部門レビュー：コンテンツ、導線、運用、承認、原稿責任を確認する
• 情報システムレビュー：セキュリティ、アカウント、連携、保守、データ管理を確認する
• 制作会社レビュー：実現方法、前提、未決事項、費用・スケジュールへの影響を確認する
• 更新履歴には、変更日、変更箇所、理由、決定者、影響範囲を記録する