お問い合わせフォーム制作のヒアリング項目｜クライアントと決める仕様一覧

「お問い合わせフォームを付けてください」という依頼だけでは、必要な作業を決められません。受付の目的、入力内容、送信先、利用環境、公開後の担当を確認すると、画面を作った後の大きな修正を減らしやすくなります。

この記事では、制作着手前の打ち合わせに使える質問と、回答を仕様へまとめる方法を紹介します。価格の計算はフォーム制作費用の見積もり方、完成後の確認は納品前チェックリストで扱っています。

最初の質問は「受け付けた後に何をするか」

フォームの目的を「メールを送ること」で止めず、その後の対応を聞きます。資料を送る、見積もりを作る、予約の空きを調べるなど、次の作業によって必要な情報が変わります。

• 誰から、どんな相談を受けたいですか。
• 届いた内容を最初に確認するのは誰ですか。
• 返信までに確認しなければならない情報は何ですか。
• フォーム送信だけで確定することはありますか。
• 対応できない相談には、どう案内しますか。

例えば予約なら、希望を受けるだけなのか、空き枠を押さえるのかで要件が違います。自動確定を求める回答があれば、通常のメール受付とは分けて検討します。

入力項目は名称・必須条件・使い道を一組にする

打ち合わせで埋める仕様表の例

確認対象	記録する内容
入力項目	名前、入力形式、必須条件、補足文
選択肢	表示名、選べる個数、未定やその他の扱い
添付	必要性、形式、点数、容量
条件分岐	表示する条件と、サーバー側の必須条件
確認画面	表示内容、戻って修正するときの扱い

「電話番号は念のため必須」など理由が曖昧な項目は、使う場面を確認します。担当者が後で使う情報でも、初回の相談で必須とは限りません。入力項目の設計を見ながら、必須と任意を分けましょう。

通知と自動返信は、完成文まで確認する

通知先は部署名だけでなく、実際に管理しているアドレスを確認します。送信元や返信先は通知先とは役割が違うため、それぞれ誰が管理するかも記録します。認証情報は仕様書へ直接書き込まず、受け渡し方法を別に決めます。

自動返信では、差出人名、件名、受付の意味、返信目安、署名を確認します。完了画面にも同じ受付条件を反映します。「問い合わせ受付」と「契約成立」のように意味が変わる表現を混在させないことが大切です。

サーバーと運用の制約を制作前に確認する

公開先のホスティング、PHPを利用できるか、メールの送信方法、HTTPSの利用状況を確認します。サーバーを変更できない案件では、その環境に合う実装を選ぶ必要があります。公開日に初めて設定情報が届く進め方では、検証期間を取りにくくなります。

管理画面、データ保存、外部連携、予約枠の管理などを希望する場合は、メールフォーム本体の範囲と分けて記載します。製品の名前だけで機能の有無を推測せず、実際の機能一覧や説明書と照合してください。

未決定の項目を、そのまま仕様にしない

打ち合わせで決まらない内容は「未決定」として、決める担当者と期限を残します。文面や掲載する個人情報の取り扱いの案内は、依頼主が実際の運用に合わせて確認する必要があります。制作者が仮の文を入れた場合は、仮であることを共有します。

合意事項の記録例：今回は相談内容のメール受付までを対象とします。通知先と返信目安は依頼主が確認し、画面実装前に確定します。問い合わせ管理画面と予約の自動確定は今回の対象に含めません。

この例は実際の案件に合わせて書き換えます。変更が出たら、画面だけでなく通知・テスト・費用への影響も確認します。

仕様表を、テストと引き継ぎへつなげる

「添付PDFは一つ」「電話番号は任意」と決めたら、その条件が動くかをテスト項目にします。誰が合格を確認するかまで決めると、完成の判断がしやすくなります。公開後に通知先を変える担当者も同じ表へ追記できます。

FreelanceFormを候補にする場合は、用途別テンプレートと設置環境を仕様表に照らして選びます。質問への回答を集めるだけで終わらせず、実装と確認に使える形へまとめることがヒアリングの役割です。