Web制作の要件定義｜依頼者が決める項目と記入例

Web制作の要件定義では、希望する見た目や機能を並べるだけでなく、誰が、どの場面で使い、何を確認できれば依頼どおりと判断するかを決めます。
専門的な仕様を依頼者だけで書き切る必要はありません。事業の事情を伝え、制作側と一緒に確認できる条件へ整える工程です。

例えば「自分で記事を直したい」という依頼でも、文章だけを編集するのか、表や相談ボタンまで直すのかで必要な作り方が違います。
完成した画面を見るだけでは、更新のしやすさまで確認できません。

この記事では、要望・要件・受入確認を三つの欄に分ける方法を紹介します。
アセントウェブの自社サイトで実際に整理したブロック編集、CTA、問い合わせの分類も例に使い、打ち合わせから公開前の確認へつながる書き方を説明します。

要件定義では、目的と完成条件を合意する

要望と確認可能な条件の違い

要望は、事業者が実現したいことや困っていることです。
要件は、そのために今回の制作で備える内容。受入確認は、それができているかを確かめる操作や確認方法です。

例えば、「必要な相談を増やしたい」は目標として共有できます。
ただし相談数は集客、時期、提供サービスなどの影響も受けるため、サイトを納品した時点の動作確認と同じには扱いません。

同じ要望でも、実現方法が一つとは限りません。
制作側から複数の方法が出たら、操作、費用、管理の負担を比べて採用する条件を決めます。

「見やすくする」「使いやすくする」といった言葉は、話し始めるきっかけにはなります。
その後に、誰が何を見つけたいのか、どんな操作で困っているのかを足すと、確認できる要件に近づきます。

決定者と利用者を整理する

依頼窓口の人と、サイトを毎日更新する人、料金やサービスの説明を承認する人は、同じとは限りません。
それぞれの役割を決めないまま進めると、画面が完成した後で使い方や掲載内容の確認が戻ってくることがあります。

一人が複数の役割を持つ小規模企業でも、この欄は使えます。
人数を増やすためではなく、質問の回答先と判断の順番を分かるようにするためです。

制作全体の流れや依頼先の考え方から整理したい場合は、中小企業のホームページ制作の進め方も参考にしてください。
本記事では、その中でも「今回、何を完成させるか」を文書にする部分を扱います。

制作前に決める情報・機能・運用

読者と必要ページ

最初からページ数を固定するより、利用者が申し込み前に知りたいことを書き出します。
その質問に答える情報を、どのページへ置くかを決めると、ページの役割が説明しやすくなります。

例えば、初めて相談する人が「自社の規模でも頼めるか」と迷うなら、対象事業者や相談できる範囲を説明する必要があります。
その情報がサービスページに収まるなら、別の記事を増やす必要があるとは限りません。

参考サイトを示す場合も、「全体を似せたい」だけで終わらせず、参考にしたい部分と理由を伝えます。
例えば「料金に含まれるものが表で分かる」「スマホで相談先へ進みやすい」といった、必要な性質を共有します。

他社の文章や画像をそのまま使う指示にはせず、自社で説明すべき情報と、利用できる素材を用意してください。
デザインの好みと、掲載する内容の根拠を別々に確認できます。

フォーム・更新権限・外部連携

機能の名前には、具体的な使い方が隠れていることがあります。
「フォームを付ける」だけでは、入力項目、送信後の案内、受信先、エラー時の扱いまでは決まりません。

権限については、操作に必要な範囲を制作側と確認します。
記事を更新する人全員に、サイト全体の設定変更まで任せる必要があるとは限りません。

また、要件シートにアカウントの所在や管理者を書いても、パスワードや認証コードをそのまま貼り付ける運用は避けます。
共有する方法や担当者へのアクセスの渡し方を別に決めておきます。

表示速度や使いやすさも、確認する環境を合わせます。
「どの端末・ブラウザー・ページ・操作を確認するか」が分からない状態で、漠然と速さだけを求めると判断がそろいません。

曖昧な依頼を具体的な受入条件へ変える

ブロックで編集できるという条件

アセントウェブでは、自社の記事について、WordPress標準のGutenbergで個別に編集できる構成へ整理しました。
段落、見出し、表、画像、グループ、ボタンを標準ブロックとして扱い、共通の装飾は追加CSSで管理する方針です。

WordPress公式のブロックエディター解説でも、段落や画像、見出し、リストなどをブロックとして配置する仕組みが説明されています。
ただしWordPressを使っているだけで、希望する箇所がすべて同じように編集できるとは限りません。実際の構築方法と権限で確かめます。

自社サイトの作業では、既存記事のブロック状態と、変更後にエディターのエラーがないことを確認した記録を残しています。
ここでは、その作業を他の依頼にも使える形に整理します。特定の作業時間や、問い合わせ増加を示す事例ではありません。

この条件なら、納品画像を見て「きれいですね」と確認するだけでは終わりません。
更新担当者がどの操作をできる必要があるかを、制作前に共有できます。

逆に、担当者が本文だけ更新できれば十分なページなら、変更できる範囲を狭くする選択もあります。
編集できる箇所を増やすこと自体が目的ではなく、日々必要な作業を安全に続けられる範囲を決めます。

営業除外と成功計測の条件

自社サイトでは、営業の連絡で「その他」が選ばれるという運用上の相談がありました。
その後、問い合わせ種別の表記を「その他・協業・営業」にまとめる方針を反映しています。

この依頼を要件にする場合、選択肢の文字を変えることと、成果の集計条件を変えることを分けます。
文字が変わっても、計測側が従来の条件のままなら、意図した集計になるとは限りません。

当社が使うContact Form 7では、公式資料に入力不備、スパム判定、メール送信成功、送信失敗などのイベントが分かれて示されています。
そのため、「ボタンを押した」と「メール送信が成功した」は、要件の段階でも区別します。

GA4のキーイベントの公式説明では、事業上重要な行動を測るイベントにキーイベントとして印を付ける流れが案内されています。
先に何を成果とするかを決め、その条件で動くイベントかを確認してから登録します。

自社の通常問い合わせ、テイガクウェブ、アセントグルメの3フォームについては、テスト送信と受信の確認を行ったやり取りを残しています。
ただしメールが届くことと、計測が正確であることは別の確認です。仕様変更後も、送信・受信・計測をそれぞれ照合する必要があります。

分類欄の選択だけで、すべての営業送信を見抜けるわけではありません。
相談を装った営業が含まれる場合に備え、実際の内容を確認した有効相談の件数と、システム上の記録をどう扱うかも決めておきます。

予算と期限の中で優先順位を付ける

必須・後回し・不要の整理

希望した機能がすべて、今回の公開に必要とは限りません。
まず、欠けると利用者が目的の行動をできないもの、運用を続けられないものから確認します。

例えば、問い合わせの受信先が決まっていないなら、公開しても連絡を処理する担当がいません。
一方、事例を絞り込む高度な機能は、掲載件数や更新体制によっては、初期段階でなくてもよいかもしれません。

「後で対応」とだけ書かず、何がそろったら再検討するかを残します。
例えば、担当者が決まったら、公開できる事例が集まったら、といった条件です。件数や時期は実際の状況から決めます。

制作費の比較では、同じ要件が見積もりに含まれるかを照合します。
詳しくはホームページ制作の見積もり確認表で、納品物と検収条件の整理を紹介しています。

未決事項と変更見積もり

要件定義が終わるまで、すべての疑問に答えが出るとは限りません。
分からないことを消して見せるより、未決のまま進めてよい範囲と、決まるまで止める範囲を明記します。

上の記入例は説明用です。
実際には、制作会社と依頼者で期限と影響を確認して埋めます。

途中で追加したいことが出たら、元の要件、追加内容、費用・納期・運用への影響を一緒に確認します。
誰の承認で変更するかも決め、承認前の案を確定事項として実装しないようにします。

要件シートには版と更新日を付けます。
「最新のファイルがどれか」「どこが変わったか」が分かれば、以前の打ち合わせ内容を誤って採用するのを防ぎやすくなります。

要件シートを打ち合わせと検収に使う

資料・素材・権限をそろえる

初回の打ち合わせでは、完成した仕様書より、判断の材料が役立つこともあります。
サービス資料、よく受ける質問、現在困っている画面、使える写真などを、公開可能な範囲でまとめてください。

1. 今の困りごとと、サイトで支えたい業務を書く。
2. 閲覧者が判断するために必要な情報を集める。
3. 自社で更新する箇所と、外部へ依頼する箇所を決める。
4. 要望・要件・受入確認の三つの欄へ整理する。
5. 未決事項に回答者と確認期限を付ける。
6. 制作範囲と費用・期限を照合し、採用する版を合意する。

素材には、使ってよい範囲や確認する担当者も付けておきます。
例えば社内資料として持っている写真でも、サイト掲載の確認が済んでいるとは限りません。迷う素材は掲載可否を確認してから渡します。

公開前の確認に戻す

画面ができたら、最初に作った要件シートを開いて、一つずつ確認します。
担当者の記憶だけに頼らず、合意した要件に対応する確認結果を残します。

この表の空欄へ、自社の要件を一行ずつ入れて使えます。
テストの方法を相談する際は、実際のメール送信や予約、決済が発生するかも確認し、試験用の入力と受信先・処理方法を決めておきます。

表示の確認では、見出しや文章だけでなく、表、画像、ボタンを見ます。
PCで読めても、スマホで横にはみ出して操作できない箇所があれば、その確認結果を残します。

未解決の項目がある場合は、公開を止める問題か、条件付きで後から対応する内容かを判断します。
その判断者、対応期限、確認方法まで記録してから、公開と引き継ぎへ進みます。

サイトを運用する人には、管理画面への入り方、変更してよい範囲、困ったときの連絡先を渡します。
要件定義で決めた「誰が更新するか」が、実際に運用できる状態になっていることまで確認してください。

Web制作の要件定義でよくある質問

専門用語が分からなくても作れますか

依頼者は、まず業務で困る場面を自分の言葉で書けば大丈夫です。
「記事の表を自分で直せない」「営業の送信と相談を区別したい」など、実際の操作や判断に結び付く説明が役立ちます。

実現方法や技術的な制約は制作会社へ確認し、回答を受けて要件を具体化します。
専門用語を増やすより、完成後に何を試せばよいかが双方に伝わる文書を目指しましょう。

途中で要望を変更できますか

変更の検討はできますが、費用や納期への影響を確認してから判断します。
変更前の合意を上書きするだけでなく、変える理由と影響、承認した人を記録してください。

要件定義は、依頼者の希望をなくすための作業ではありません。
希望を制作・確認できる単位に分け、今回どこまで実現するかを決めるためのものです。

まずは気になる要望を三つほど書き、それぞれに「完成したら何を操作して確認するか」を添えてみてください。
確認方法がまだ分からない箇所こそ、次の打ち合わせで相談する項目になります。