WEB担当者の発注前のお困りごと解決します。
（）
前回の記事では、「要件定義とは何か？」「どこから考え始めればよいのか？」といった概要を解説しました。もし、まだ記事をご覧いただいてない方は「要件定義、どこから手をつければいい？」も是非ご覧ください。また、今回の記事では一歩進んで、要件定義書が「どんな構成で、何を定義する資料なのか」を、より具体的にイメージできるようにしています。
記事では、500P規模のWebサイトのリニューアルを想定したサンプル事例を基に、「私たちが実際にどのような考え方で要件定義書を作成しているか？」をできるだけ解りやすく解説しています。
Webリニューアル、そのまま進めて大丈夫ですか？
ウェブリニューアルや改修で「要件定義」に取り組む方へ。
要件定義書は、Webサイトのリニューアルにおいて「お客様の要望を明確にし、実施内容を定義した」文書です。この文書を基に見積もりが確定し、Webサイトのリニューアルが進行されます。
要件定義書に掲載される項目は、プロジェクトの内容や規模、事業者のポリシーごとに違いはありますが、紹介する事例は一般的な要件定義書に取り入れられている代表的な項目です。
目的と対象を定める要件
掲載内容と構造を定める要件
実装と品質を定める要件
連携と管理を見据えた要件
目的・成果要件は、Webサイトのリニューアルを通じて「何を達成したいのかを明確にする」ための項目です。プロジェクトの目的を見える化（可視化・言語化）することで、Webサイトリニューアルの関係者間でスムーズに情報を共有することができます。
要件定義書で示す「目的」は、Webサイトのリニューアル実施において、決めごとの大前提となります。コンテンツ構成や機能、設計方針を検討する際の基準となるため、誰が読んでも同じ方向性をイメージできる形でまとめることが求められます。
目的を考える際は、「Webサイトのリニューアルでどのような変化を起こしたいのか」を考えます。「問い合わせを増やしたい」「採用応募の質を上げたい」「事業内容を正しく伝えたい」といった期待を起点に、リニューアル後のWebサイトのあるべき状態を「見える化」します。
成果にはさまざまな形があります。例えば、「問い合わせ件数」や「応募数」のように数値化して評価できるものもあれば、「理解しやすさ」や「信頼感」のように定性的に評価するものもあります。成果によって評価方法が変わるので、常に目的を意識しながらリニューアル後のWebサイトがビジネスにどのような変化をもたらすのか？をイメージすることが重要です。
対象ユーザー要件では、Webサイトを誰に向けて提供するのかを明確にします（ターゲット選定）。ユーザーの状況や利用目的を想定し、Webサイト全体の設計方針を定めるための項目です。
対象となるユーザーを定めなければ、コンテンツ内容や情報設計、機能要件を検討することができません。対象を明確にすることで、情報の配置や掲載の優先順位を決めることができます。
対象ユーザーが誰なのか？を考える際は、「このWebサイトは、どのような人に使われるのか」を深く考えます（ペルソナ設計）。顧客、見込み客、求職者、投資家など、ユーザーの属性や性別、目的によって、求められる情報や機能は異なります。
また、ひとつのWebサイトに複数の違った属性のユーザーが存在するケースもあります。その場合は、どのユーザーを主要な対象ユーザーとするのか、どのユーザーを補助的な対象ユーザーとするのかも考える必要があり、要件定義書に明記します。
コンテンツ要件は、Webサイトにどのような情報を掲載するのかを選定します。扱う情報の範囲や種類など、Webサイト全体の情報量や構成を定義する項目です。
コンテンツ要件は、情報設計やページ構成、運用方法を検討する際の土台になります。どの情報を扱うのかが定まれば、必要なページボリュームや更新の有無、Webサイトの管理方法といった検討事項がみえてきます。
リニューアルの目的を実現するために、「対象ユーザーに必要な情報は何か」を考えます。事業内容、サービス情報、販売コンテンツ、IR情報、会社情報、採用情報など、対象ユーザーの目的に応じて必要な掲載情報は変わります。
掲載する情報は、「必ず掲載すべき情報」「状況に応じて更新される情報」「将来的に追加される可能性のある情報」というように、複数のポイントに分けて考えることが、無駄のない構成につながります。
情報設計要件は、掲載する情報をグループで整理したり、重みに応じて階層分けをし、どのようにユーザーに情報を届けるかを設計します。この設計を基に、コンテンツ同士の関係性を明らかにしサイトマップとして全体構造を定義したうえで、必要があればワイヤーフレームを作成しWebサイト全体の構造や導線を見える化します。
リニューアル規模がある程度大きくなると、すべてのページのワイヤーフレームを作成するのは現実的ではありません。主要なページや、構成・導線を検討するうえで重要なページを定義し、ワイヤーフレームを作成します。これらの資料は、要件定義書とは別紙としてまとめられることが一般的です。
情報設計要件は、サイトマップやワイヤーフレームを作成するための前提条件を定義し文書に起こします。Webサイト全体のページ構成や階層を明確にし、デザインや機能を検討するための資料となります。
情報を「どのような配置にすれば」「どのように繋げれば」、効果的に対象ユーザーに届けられるか？を考えます。掲載する情報を単に並べるのではなく、意味の近い情報をまとめたり、複雑な内容であれば段階的に理解できる構造を意識して考えます。
また、全体構造・カテゴリ分け・階層の深さといった、さまざまな情報の配置バランスを考えることで、情報をより効果的に対象ユーザーに届けることができます。
機能要件は、Webサイトでどのような機能を実装するのかを整理する項目です。ユーザーの行動や運用の流れを踏まえ、Webサイトとして必要な機能の範囲を定めます。
機能要件は、開発内容や実装範囲を明確にするための基準になります。後工程での認識違いを防ぎ、見積やスケジュール検討の材料となる項目です。
Webサイトで対象ユーザーの想定利用シーンをもとに、必要な機能を考えます。閲覧、検索、問い合わせ、更新、管理など、対象ユーザーや運用・管理者の行動に沿って機能を考えることが重要です。
※機能要件は大変重要な項目です。是非『要件定義で決める機能要件「やること」「やらないこと」』も合わせてご覧ください。
非機能要件は、Webサイトの性能や品質について定義する項目で、リニューアル後の安定したWebサイト運用のために条件や制約を定めます。
非機能要件は、開発後のトラブルや認識違いを防ぐために重要な役割を果たします。表示速度、セキュリティ、対応環境など、後工程で問題になりやすい点を事前に整理した内容を文書化します。
リニューアル後の安定した稼働のためには、どのような状態であればいいのか？に意識を向けます。対象ユーザーの利用環境だけでなく、Webサイト運用者の体制や制約も含めて考える必要があります。
※非機能要件は要件定義後にトラブルが発生しやすい項目のため、後日あらためて詳しく解説する予定です。
運用・保守要件は、Webサイトのリニューアル後「どのように運用し」「維持していくか」を定義する項目です。日々の更新作業や管理体制を考慮して無理のない運用方法を検討します。
運用・保守要件は、Webサイトを効果的に活用するため、「誰が」「どの範囲まで」「どのように」運用するのかを明確にし、属人化や運用負荷の増大を防ぎます。
「公開後にどのような作業が発生するのか」を想定し、コンテンツ更新、情報修正、問い合わせ対応、障害対応など、日常的な運用作業を洗い出し文書化します。また、運用・保守要件は「運用を社内で行うのか」「外部に委託するのか」を検討する際の判断材料にもなります。
外部連携要件は、Webサイトが外部のシステムやサービスと「どのように連携するのか」を定義する項目です。業務システムや外部サービスとの関係を整理し、連携範囲を明確にします。
外部連携要件は、連携対象（外部サービスなど）を明確にすることで、技術仕様や実装内容、対応範囲に関する認識のズレを防ぎます。
外部連携要件は、「Webサイト内にシステムを構築するのか」「外部サービス（予約システム、決済サービスなど）と連携するのか」大きく二つに分かれます。外部サービス連携の有無によって、開発内容や運用負荷が変わるため早い段階で連携要素をリストアップすることが重要です。
移行要件では、既存のWebサイトやWebシステムから、「新しいWebサイトへ引き継ぐ情報やデータ」について定義します。現行のWebサイトの資産をどのように活用するかを検討し、リニューアル時の効果を最大限に引き上げます。
移行要件は、既存コンテンツやデータの取り扱いを明確にし、作業範囲や工数を把握するための基準となります。移行対象を定めることで、抜け漏れや想定外の作業増加を未然に防ぎます。
移行要件を考える際は、「現行のWebサイトにどのような情報やデータが存在しているのか」を精査し、すべてを移行するのか？一部を整理・削除するのか？新規作成に切り替えるのか？といった方針を考えます。また、ページ数が多いWebサイトでは、移行対象の優先度や移行方法の違いを確認しながら考える必要があります。
未確定要件・リスク管理は、要件定義の段階でまだ決まっていない事項や、将来的に問題となる可能性がある点を整理する項目です。すべてを確定させきれない前提で、プロジェクトを安全に進めるための余白を残します。
未確定要件・リスク管理は、後工程での手戻りやトラブルを防ぐための前提整理として機能します。「決まっていないこと」「判断が先送りになっていること」を明確にすることで、関係者間の認識をそろえます。
「現時点で確定できていない理由」、例えば、情報不足、関係者間の調整待ち、外部要因など、未確定となっている背景を整理して考えることが重要です。また、想定されるリスクについては、発生する可能性や影響範囲を意識しながら、どの時点で再検討・判断するのかを考えます。
今回は、要件定義書がどのような項目で構成され、どのような考え方で作成されるのかを、各項目ごとに一連の流れにして紹介しました。しかしながら、これらの項目名や区分は決まった形式が存在するわけではありません。要件定義書の作成者の考え方や、プロジェクトメンバー間の共通言語、組織の文化によって、項目の分け方や呼び方が変わることもあります。
重要なのは、「何を決めるための要件なのか」「どの判断に使われる情報なのか」を関係者間で共有し、プロジェクトを前に進めるための文書だということです。
次回以降は、今回触れた各要件の中から、特に判断が難しく、後工程に大きな影響を与えやすいテーマについて、もう一歩踏み込んで解説していきます。
※本情報はページ公開時のものです。情報は常に更新され掲載内容と異なる場合がございます。
要件の整理から私たちと一緒に進めたい方は、ゼロベース要件整理もご覧ください。
更新は
SNSnoteでお知らせしています。