本文へスキップ
  1. TOP
  2. Web制作
  3. 実務知識
  4. フォームの送信確認で、通知・自動返信・保存データ・担当振り分けまでどう検証するか

03 / BUILD

つくるフェーズの実務知識

フォームの送信確認で、通知・自動返信・保存データ・担当振り分けまでどう検証するか

送信完了画面だけでなく、利用者への返信と社内の受付業務までを確認する

Webフォームの入力から通知までを検証する作業デスク

PRACTICAL KNOWLEDGE 実務知識

WRITTEN BY

FHW制作チーム

反省会と日々の制作記録をもとに、担当スタッフが実際に迷い、確認し、判断した過程を整理しています。

フォームへ入力し、送信完了画面が表示されれば、機能は完成したように見えます。しかし実際の受付業務では、管理者通知が担当部署へ届かない、自動返信の内容が申込条件と合わない、管理画面やCSVに必要な値が残らない、といった問題が起こり得ます。

フォームは入力画面だけで完結しません。入力条件、確認画面、送信処理、管理者通知、自動返信、データ保存、担当者への振り分け、外部サービスとの連携までが、一つの受付業務としてつながっています。

私たちが担当した制作にも、申込・一般問い合わせ・取引希望を分けるもの、企業問い合わせと求人応募を同じ運用基盤で扱うもの、会員情報や外部システムと連携するものがありました。案件は違っても、毎回立ち止まるのは同じところです。「送信できた」だけで、利用者と運用担当の双方にとって本当に受付が完了したと言えるのか。そこから確認を始めます。

送信完了画面が出ても、受付業務が完了したとは限らない

ブラウザ上で完了画面へ進めたことは、確認項目の一つです。その後にメール送信やデータ保存を行う構成では、画面表示と各処理が別々に動いていることがあります。

少なくとも、次の状態を分けて確認します。

  • 入力内容が送信処理へ渡った
  • 管理者向け通知が正しい宛先へ送られた
  • 利用者向け自動返信が入力された宛先へ送られた
  • 管理画面やデータベースへ必要な値が保存された
  • 担当部署や外部システムへ正しく振り分けられた
  • 利用者が完了後に必要な案内を確認できた

フォームを画面ではなく、一つの業務として整理する

問い合わせ、申込、応募、資料請求では、似た入力欄を使っていても、受付後の担当者や確認内容が異なります。見た目が似ているという理由だけで一つのフォームへまとめると、利用者に不要な入力を求めたり、社内で内容を適切な担当へ渡せなくなったりします。

実装前に、用途ごとに次の項目を対応させます。

  • フォームを利用する人と、その目的
  • 必要な入力項目と必須・任意の条件
  • 選択内容による項目や送信先の分岐
  • 管理者通知の宛先、件名、本文
  • 自動返信で利用者へ伝える内容
  • 保存するデータと、保存しない情報
  • 受付後に対応する部署・担当者
  • 対応完了とする状態

この対応表を、画面仕様、メール仕様、管理画面、テスト項目で共通して使います。

入力・確認・戻る・エラーを組み合わせて確認する

すべての項目を正しく入力した場合だけでは、実際の利用状況を確認できません。入力途中の変更やエラーからの復帰も含めてテストします。

  • 必須項目が不足している
  • メールアドレスや電話番号の形式が異なる
  • 選択肢によって表示項目や通知先が変わる
  • 確認画面から入力画面へ戻る
  • 長い文章、改行、機種依存文字を入力する
  • ファイルを添付する、または添付しない
  • 送信ボタンを続けて操作する

エラーが出ることだけでなく、該当箇所と理由が分かり、修正後もそれまでの入力内容が適切に保持されるかを確認します。

管理者通知と自動返信は別々に検証する

管理者通知と自動返信は、目的も宛先も異なります。片方が届いたことを理由に、もう片方も正しいとは判断できません。

管理者通知では、担当部署、CC・BCC、返信先、入力内容、管理画面への導線を確認します。自動返信では、利用者名、申込内容、受付後の流れ、問い合わせ先、返信不要などの案内が用途に合っているかを確認します。

また、システム上の送信処理が成功したことと、受信箱へ到達したことも分けます。差出人ドメインの設定、迷惑メール判定、受信側の制限によって、処理が成功しても利用者が確認できない場合があります。

保存データと担当振り分けを確認する

管理画面、CSV、CRMなどへ保存・連携する場合は、入力画面の項目名と保存される値を対応させます。選択肢が画面上の文言ではなく内部コードで保存される場合や、未入力値の表現が画面と出力で異なる場合もあります。

代表データを使い、管理画面の表示、CSVの列、外部システムの項目、担当振り分けの条件を照合します。フォームだけを修正した結果、通知や出力側が古い項目のまま残っていないかも確認します。

本番環境でしか確認できない条件を分ける

メール到達、外部サービス連携、reCAPTCHA、ドメイン設定、アクセス制限などは、制作環境だけでは最終状態を確認できない場合があります。

公開前に確認できる入力・分岐・表示と、本番反映後に確認する通知・到達・外部連携を分けます。本番確認の担当者、使用するテストデータ、通知先を一時的に変更するか、確認後に戻す設定も事前に決めます。

個人情報を使うテストの条件を決める

フォームの確認に、実在する顧客情報や応募者情報を安易に使いません。テスト用の氏名、メールアドレス、電話番号を用意し、保存されたテストデータを誰がいつ削除するかを決めます。

本番の通知先へテストメールを送る場合も、事前に対象者へ共有します。個人情報を扱うフォームでは、入力内容の確認だけでなく、閲覧権限、出力、保管期間、削除方法までを運用条件に含めます。

公開前・公開後チェックリスト

  • 用途ごとの入力項目、分岐、通知先、自動返信が対応しているか
  • 必須不足、形式エラー、戻る操作、二重送信を確認したか
  • 管理者通知と利用者向け自動返信を別々に確認したか
  • 通知メールの宛先、差出人、返信先、件名、本文が正しいか
  • 管理画面、CSV、外部連携へ正しい値が保存されるか
  • 受付内容が適切な部署・担当者へ振り分けられるか
  • 本番環境で確認するメール、ドメイン、外部サービスの条件を分けたか
  • テストデータと本番の個人情報を区別しているか
  • 通知先や担当変更時の再確認手順があるか
  • 公開後にテストデータと一時設定を戻したか

PRACTICAL KNOWLEDGE 同じフェーズの実務知識

私たちが別の制作で得た判断や確認方法を、同じ制作フェーズからご覧いただけます。

複数社でWeb制作の引き継ぎ内容を確認する作業デスク

自社で公開できないWeb制作で、入稿・納品・確認の責任範囲をどう決めるか

外部CMSや別会社の環境へ入稿・納品する制作で、利用できる技術、確認段階、修正の戻し先、完了条件をどう決めるか整理します。

支給デザインを共通ルールと例外へ分けて確認する制作チーム

支給デザインを、共通ルール・例外・動作仕様へどう変換するか

Figma、画像、印刷物、参考サイトなどの支給物から、共通部品、例外、可変条件、レスポンシブ、動作仕様を整理し、複数人で再現できる実装ルールへ変換する方法をご紹介します。

急増したAPI利用料金の請求明細とグラフを確認する制作チーム

55万円請求を生んだ、公開ページと従量課金APIを直結する落とし穴

公開ページへの機械的な大量アクセスが従量課金APIの大量実行へ増幅され、約55万円の請求に至った経験から、外部APIの費用上限、クォータ、キャッシュ、監視の設計を整理します。

公開日時と素材の進行状況を確認するWeb制作の作業デスク

公開日を動かせないWeb制作で、未確定素材・版管理・日時公開をどう管理するか

公開日時が固定された制作で、後から届く素材、複数の版、日時指定公開、公開直前の変更を安全に管理する方法をご紹介します。

Web制作中に増えた要望と工程への影響を整理する制作チーム

その追加要望、今入れますか? Web制作中の変更をどう判断するか

Web制作中に増えた要望を、目的、合意範囲、影響する工程、費用、日程、公開時期から確認し、修正・追加対応・公開後対応へ整理する方法をご紹介します。

短納期の制作で公開条件と後工程をカードに分ける制作チーム

短納期のWeb制作で、削ってよい工程・削ってはいけない確認は何か

短い制作期間で、共通ルール、未確定素材、確認範囲、公開後へ送る改善を整理し、速さのために品質判断まで省略しない進め方をまとめます。

受付窓口で申込書と処理の流れを確認する担当者と利用者

紙・PDFで続けてきた申込・注文業務を、どうWebへ移すか

紙やPDFで行ってきた申込・注文業務をWeb化するとき、利用者の操作、受付側の確認、例外処理、計算、保存、外部連携までを一続きで設計する方法を整理します。

公共空間でスマートフォン、タブレット、ノートPCを使う人々

対応端末・ブラウザは、利用場面からどう決めるか

Web制作の対応端末とブラウザを、利用者、場所、主な操作、重要度から優先・代表・簡易確認へ分け、境界の内容と再現情報を確認する方法を整理します。

CSVの一括更新結果と既存データへの影響を確認する資料

CSVで一括登録・更新するとき、既存データをどう守るか

CSVの一括登録・更新で、識別キー、空欄、部分失敗、事前確認、再実行、復旧を安全に扱う確認方法を整理します。

更新担当者と制作会社がページテンプレートの編集範囲を確認する作業台

お客さまもHTML・CSSを更新するサイトで、編集範囲をどう設計するか

お客さまがHTML・CSSを直接更新するWebサイトで、編集できる範囲、共通部品、CSSの影響範囲、変更履歴、制作会社へ相談する条件をどう決めるか整理します。

会員の登録状態と役割ごとの権限、外部連携を整理した立体模型

会員サイトで、登録状態・役割・権限・外部連携をどう設計するか

会員サイトの登録途中を含む状態、役割ごとの操作権限、外部サービスとの状態差、機能を段階公開する場合の判断方法を整理します。

少量のサンプルから本番規模の多様なコンテンツへ広げて検証する模型

少量のサンプルで動くWebサイトを、本番規模でも崩さないために何を試すか

数件のきれいなデータだけでは見つからない、最大件数、長文、画像量、空欄、ページ送り、一括処理の問題を公開前に確かめる方法を整理します。

原稿から複数言語のページと公開状態へ展開する編集工程

多言語サイトで、翻訳原稿・共通部品・段階公開をどう同期するか

多言語サイト制作で、ページと言語の対応、翻訳原稿の状態、共通部品の文字量差、言語ごとの段階公開を安全に管理する方法を整理します。

共通基盤でつながりながら役割を分けた複数サイトの建築模型

複数サイト・複数部署で、共通部分と運用範囲をどう分けるか

複数サイトや複数部署で運用するとき、共通化する見た目・情報・仕組み、権限、公開日、正となる情報源をどう分けるかを整理します。

光と布の動きが段階的に変化する展示空間

動きのあるデザインを、雰囲気ではなく実装仕様へどう変えるか

参考サイトやデザインの動きを、開始条件、時間、順番、終了状態、読み込み、端末ごとの代替表現へ分解し、安全に実装する方法を整理します。