Web制作の要件定義書の書き方｜手戻りと追加費用を防ぐ発注者の決めごと
制作会社が決まった後に行う要件定義で、発注者が決めるべきことを解説します。RFPとの違い、要件定義書に書く項目、AIを使った抜け漏れチェック、合意の取り方まで整理しました。
制作会社が決まり、いよいよ制作が始まる段階で「デザインが出てきてから社長の意見が大きく変わった」「後から会員機能が欲しいと言われて追加費用がかかった」という話はよく聞きます。こうした手戻りの多くは、制作に入る前に「何を作るか」を十分に決めきれていなかったことが原因です。
この「何を作るか」を具体的に決めて文書にする工程が要件定義です。制作会社が主導して進めることが多いものの、決める内容の多くは発注者にしか判断できません。この記事では、要件定義でどんなことを決めるのか、発注者として準備しておくこと、AIを使った抜け漏れの確認方法、合意の取り方を解説します。
RFPと要件定義書の違い
RFP（提案依頼書）と要件定義書は混同されやすいのですが、作るタイミングと目的が異なります。
| 比較項目 | RFP（提案依頼書） | 要件定義書 |
|---|---|---|
| 作るタイミング | 制作会社を選ぶ前 | 制作会社が決まった後、制作に入る前 |
| 主な目的 | 各社から提案と見積もりを集める | 作るものの範囲と仕様を確定させる |
| 主な作成者 | 発注者 | 制作会社と発注者が共同で作ることが多い |
| 詳しさ | 方向性や希望が中心で、未定の部分があってもよい | ページ単位・機能単位で具体的に決める |
| 費用との関係 | 概算見積もりの根拠 | 正式な見積もりと作業範囲の根拠 |
要件定義の結果、当初の見積もりから金額が変わることもあります。ここで範囲を確定させておくことが、後から追加費用が発生するのを防ぐいちばんの方法です。
要件定義書の形式はシンプルでよい
要件定義書というと分厚い仕様書を想像しがちですが、中小企業のWebサイトであれば、表計算ソフトのシート数枚で十分なことが多いです。例えば、1枚目にサイトの目的・ターゲット・公開日などの基本情報、2枚目にページ一覧と各ページの掲載内容、3枚目に機能の一覧、4枚目に素材の準備状況と担当者、といった構成にすると、関係者が全体を見渡しやすくなります。
大切なのは書式の立派さではなく、「どのページに何を載せるか」「何ができて何ができないか」が、発注者と制作会社の双方から同じように読めることです。あいまいな表現が残っていると、解釈の違いがそのまま手戻りにつながります。迷ったら、具体的な数や例を書き添えるようにしましょう。
要件定義で決める主な項目
Webサイトの要件定義では、大きく分けて次のような内容を決めます。
サイトの中身に関すること
- ページの一覧（サイトマップ）と、各ページの目的・掲載内容
- 問い合わせや資料請求など、訪問者にとってほしい行動
- お知らせやブログなど、公開後に更新するページと更新頻度
- 既存サイトから引き継ぐ内容と、削除する内容
機能や環境に関すること
- フォームの項目、送信後の自動返信メール、通知先
- CMS（専門知識がなくても更新できる管理システム）で更新できる範囲と権限
- 対応する端末とブラウザ、表示速度やアクセシビリティ（誰でも使いやすい配慮）の方針
- サーバーやドメインの管理者、SSL（通信の暗号化）などのセキュリティ要件
- アクセス解析の設定や、計測したい行動
進め方に関すること
- 確認・承認する人と、承認の順番
- デザインやページごとの修正回数の上限
- 素材（原稿・写真・ロゴ）の提出期限と担当者
- 公開日と、その日から逆算した各工程の締切
発注者が準備しておくこと
要件定義の打ち合わせを有意義にするために、発注者側では次の準備をしておくと話が早く進みます。
- 社内の関係者を洗い出し、最終決裁者を決めておく
- 決裁者に、サイトの目的と優先順位を事前に確認しておく
- 現サイトのアクセス状況や問い合わせ内容など、手元にある情報をまとめる
- 「絶対に必要なもの」と「あればうれしいもの」を分けたリストを作る
- 社内で用意できる素材と、その準備にかかる期間を見積もる
特に重要なのが、決裁者を早い段階で巻き込むことです。現場の担当者だけで要件を決め、最後に決裁者が見て方向転換するのが、手戻りのもっとも多いパターンです。決裁者が打ち合わせに毎回出席するのが難しい場合は、要件定義の節目ごとに15分程度の確認の場を設け、その場で了承を得ておくだけでも、後半の大きな方向転換をかなり防げます。
AIで要件の抜け漏れをチェックする
要件定義書の案ができたら、生成AIに抜け漏れを指摘してもらうのが効率的です。例えば次のような頼み方が使えます。
- 「以下は中小企業のコーポレートサイトの要件定義書の案です。一般的なWebサイト制作で決めておくべき項目のうち、記載がない・あいまいなものを指摘し、発注者が決めるべき質問の形で列挙してください」
- 「以下のお問い合わせフォームの仕様について、公開後に問題になりやすい点（自動返信、通知先、迷惑メール対策、個人情報の扱いなど）を確認項目として挙げてください」
AIが挙げた項目がすべて自社に必要とは限りません。必要かどうかを判断するのは人の役割です。また、AIの指摘は一般論にとどまるため、業界特有のルールや社内規程は担当者が補ってください。要件定義書に社外秘情報が含まれる場合は、社内のAI利用ルールに沿って入力内容を調整しましょう。
合意の取り方と変更のルール
要件定義書ができたら、発注者と制作会社の双方が内容を確認し、合意したことを記録に残します。メールでの承認でも構いませんが、日付と版数を明記しておくと、後から「どの版で合意したか」がはっきりします。
制作中に要件を変えたくなることもあるでしょう。その場合に備えて、変更の扱いを事前に決めておくと安心です。例えば「合意後の変更は書面で依頼し、制作会社が費用とスケジュールへの影響を示したうえで、発注者が承認してから着手する」といったルールです。これにより、小さな変更が積み重なって予算を超える事態を防げます。
まとめ
要件定義は、作るものの範囲と仕様を確定させ、手戻りと追加費用を防ぐための工程です。サイトの中身、機能や環境、進め方の3つの観点で決めるべきことを整理し、決裁者を早めに巻き込むことが成功のポイントです。AIは抜け漏れの確認に役立ちますが、何が必要かを決めるのは発注者自身です。
次にやることとして、社内の関係者と最終決裁者を一覧にし、「必須」と「あればうれしい」を分けた要望リストを作りましょう。それを持って要件定義の打ち合わせに臨めば、制作会社との議論がぐっと具体的になります。