制作会社から「公開前確認をお願いします」と届いたとき、トップページがきれいかを見るだけでは公開可否を判断できません。発注側の検収では、代表的な利用者シナリオを先に決め、入口から主要行動を最後まで完了できるか、PCとスマートフォンで試します。内容の事実、主要導線、表示、フォーム、基本的なアクセシビリティ、公開後の運用条件について、期待結果と実際結果を同じ表に残してください。
見つかった問題は、事業や安全に直結する「公開停止」、主要体験を妨げる「公開前修正」、影響が限定的な「公開後対応」に分けます。ページタイトルやキーボード操作などの簡易確認だけで規格適合を断定しないことも大切です。この記事では、発注側がどこまで試し、誰と何を合意すれば公開してよいかを手順に沿って説明します。
検収は利用者の流れで試す
公開前の画面をページ単位で眺めると、誤字や余白の違和感は見つけられても、「利用者が目的を達成できるか」は抜けやすくなります。検収の単位をトップページ、会社概要、問い合わせページと分けるのではなく、「サービスを知り、比較し、問い合わせを完了する」といった一連の流れに置き換えます。
制作会社の技術テストと発注側の受入テストは目的が違う
制作会社は、仕様に沿って実装されているか、リンクや機能が動くか、想定した環境で表示できるかなどを技術面から確認します。一方、発注側の受入テストは、実際の利用場面で事業目的を果たせるかを確かめる作業です。テスト済みという報告は大切な資料ですが、それだけで発注側の判断が完了するわけではありません。
2024年5月31日版のデジタル庁の実践ガイドブックは、政府情報システムを対象に、発注者側が受入テストの計画やシナリオ、合否判定を扱う考え方を示しています。民間企業のホームページに直接適用される規則ではありませんが、制作会社の技術確認と、発注側の業務目的の確認を分ける枠組みは活用できます。[1]
役割を分けるときは、発注側が技術項目を一切見ない、制作会社が利用者の流れを考えない、という線引きにはしません。制作会社には技術的な再現条件と原因を確認してもらい、発注側は事実の正しさ、業務上の完了条件、公開可否を判断します。契約書やテスト計画に担当範囲がある場合は、その定義を優先します。
代表シナリオは入口と完了条件をセットにする
代表シナリオは、サイトで成果につながる行動から選びます。すべてのページを同じ深さで確認するより、影響の大きい流れを先に通した方が、公開判断に必要な不具合を発見しやすくなります。
- 見込み客がサービス紹介ページに入り、条件を確認して問い合わせを送る
- 求職者が募集情報を読み、応募方法を理解して応募を完了する
- 既存顧客が営業時間や所在地、連絡先を迷わず確認する
各シナリオには、誰が使うか、どのページから始めるか、どの操作をするか、どの状態になれば完了かを書きます。検索結果や共有されたURLから直接下層ページへ入る人もいるため、必ずトップページから始める必要はありません。最重要のシナリオはPCとスマートフォンの両方で、入口から完了まで途中を省かずに試します。
期待結果を先に書く
画面を開いてから感想を書き始めると、「何となく分かりにくい」「思っていた見た目と違う」といった指摘が増え、合否の根拠が曖昧になります。操作前に期待結果を書き、実際結果との差を記録すれば、修正後も同じ条件で再確認できます。
記録項目は、利用者の目的、開始条件、操作、期待結果、実際結果、証拠、判定、担当です。2025年9月30日のデジタル庁「ウェブサイトガイドライン」は各府省のウェブサイトを対象とする文書ですが、品質評価をアクセシビリティ、情報設計、管理機能の使いやすさ、情報の最新性、セキュリティやプライバシーなど複数の観点で捉えています。中小企業の検収では、この評価観点を自社の目的と契約範囲に合わせて絞り込みます。[2]
| 利用者の目的 | 操作と期待結果 | 実際結果と証拠 | 判定と担当 |
|---|---|---|---|
| サービスを確認して問い合わせる | サービスページからフォームへ進み、必須項目を入力すると完了画面が出て、利用者と社内の双方へ通知される | PCで完了。画面A-01、受信メールA-02・A-03 | 合格／営業担当 |
| スマートフォンで応募方法を確認する | 募集詳細から応募ボタンを押し、入力画面へ移動できる | 固定メニューがボタンを覆う。動画B-01 | 公開前修正／制作会社 |
| 採用応募を完了する | 正常送信後、採用担当の指定先へ応募内容が届く | 完了画面は出るが指定先に未着。時刻とテストデータC-01 | 公開停止／採用担当・制作会社 |
この表は、各テストを合格、公開前修正、公開停止のどれとして扱うかを決めるためのものです。第三者が同じ操作を再現でき、期待結果と差分を確認できる状態を目指します。
証拠は「スクリーンショットあり」だけで終わらせず、対象URL、確認日時、端末や画面幅、ブラウザ、入力したテストデータ、画像やメールの識別名を残します。フォームの未着のように画面だけでは判断できない問題では、送信時刻、宛先、受信状況も照合します。
期待結果が合意されていなかった項目は、直ちに不具合と決めつけず、「仕様との不一致」「要件の漏れ」「公開後の改善候補」を分けて記録します。これにより、修正責任の議論と公開可否の判断を分けやすくなるでしょう。
内容・導線・表示を順番に確認する
利用者がサイトを使う順序に合わせ、内容、導線、表示の順で確認します。表示崩れから見始めると、住所や受付条件の誤り、目的ページへ着けない問題など、事業への影響が大きい不具合が後回しになりがちです。
内容は、その事実を管理する部署が照合する
社名、住所、電話番号、営業時間、サービス名称、対応範囲、募集条件、日付、資料の版などは、承認済みの社内資料や現在の運用情報と照合します。制作担当者が原稿どおりに掲載したかだけでなく、その原稿自体が公開日時点で正しいかを、情報を管理する部署が確認します。
同じ情報が会社概要、フッター、問い合わせページなど複数箇所にある場合は、表記が一致しているかも見ます。古いキャンペーン、終了した募集、仮の電話番号、ダミー文言、テスト用画像が残っていないかは、サイト内検索やページ一覧を使って横断的に確かめます。
導線は、入口から戻り方まで操作する
主要なボタンやリンクは、文言から予想したページへ移動するかを確認します。「相談する」を押したのに一般的な会社概要へ移るなど、リンク自体が動いても目的と行き先がずれていれば受入テストでは不合格です。
下層ページから入った利用者が、関連サービス、会社情報、問い合わせへ移れるかも試します。メニューを一度開閉する、前の画面へ戻る、外部サイトやPDFを開くといった操作もシナリオの中で行います。全リンクの機械的な検査は制作会社の技術確認として報告を受け、発注側は主要導線の意味と業務上の完了を重点的に見ます。
表示は、実機で操作できる状態まで見る
PCとスマートフォンでは、同じ情報が表示されるだけでなく、同じ目的を達成できることが判断基準です。スマートフォンでは、メニューや固定ボタンが本文を覆わないか、横スクロールが出ないか、文字や画像が切れないか、電話・メール・地図・PDFへの操作が成立するかを確認します。
すべての機種とブラウザを発注側だけで試すのは現実的ではありません。契約や制作仕様で対象環境を確認し、発注側は自社の主要利用者に近いPCとスマートフォンでシナリオを通します。対象外の環境で問題が見つかった場合も、利用者数、代替手段、事業影響を確認して扱いを決めます。
基本的なアクセシビリティは操作しながら確かめる
発注側でも、ページタイトルが内容を表しているか、見出しの順序が理解しやすいか、画像の意味が代替テキストで伝わるか、文字を拡大しても読めるかを簡易確認できます。マウスを置いてTabキーだけで主要リンクやフォームへ移動し、現在位置を示す枠が見えるか、操作順が不自然でないかも試します。
フォームでは、入力欄の名称、必須項目、エラー箇所と直し方が文字で分かるかを見ます。W3Cの「Easy Checks」は、ページタイトル、代替テキスト、見出し、コントラスト、文字拡大、キーボード操作、フォームなどの初期確認を案内していますが、対象は一部の問題に限られます。簡易確認を通過しても、WCAGやJISへの適合を断定できるわけではなく、包括的な評価には追加の検証が必要です。[3]
フォームと操作完了を確かめる
問い合わせや応募がサイトの主要目的なら、フォームは入力画面が表示された時点では合格になりません。入力前、エラー時、送信後の三つに分け、利用者側の完了と社内側の受信までを一続きで確認します。
- 入力前の状態を確認する
項目名、必須と任意の区別、入力例、個人情報の取扱いを示すリンク、送信ボタンの文言を読みます。スマートフォンで入力欄や選択肢を操作できるか、確認画面がある設計なら入力内容を見直せるかも試します。 2. エラーを意図的に起こす
必須項目を空欄にする、メールアドレスの形式を崩すなど、想定される誤入力で送信します。どの項目に問題があり、どう直せばよいかが分かること、問題のない入力内容まで消えないこと、色だけに頼らずエラーを認識できることを確認します。 3. 送信後の業務まで追う
完了画面、設定している場合の利用者への自動返信、社内の指定先への通知を照合します。件名や差出人が運用担当者に識別できるか、返信が必要な内容を担当部署が受け取れるかも確認対象です。画面に「送信しました」と出ても社内へ届かなければ、利用者の行動は事業上完了していません。
テストには実在顧客の情報を使わず、テストであることが識別できるデータを用意します。受信後の削除方法や、テスト通知を誰が確認するかも事前に決めておくと、本番データとの混在を避けられます。フォーム単体の確認項目は、問い合わせフォームを場面ごとに確認する方法でも整理しています。
不達が起きたときは、フォーム画面、メール送信、受信側の振り分けのどこで止まったかを制作会社と切り分けます。原因が未確定でも、主要な問い合わせや応募を受け取れない状態なら、公開可否の判定を先に行い、原因調査の担当と期限を先に決めてください。
不具合を公開可否で分ける
不具合の件数だけで公開可否を決めると、軽微な余白調整が多いサイトを危険と見なし、フォーム不達が一件だけのサイトを見逃します。同じ現象でも対象者や代替手段によって分類は変わるため、事業への影響と利用者への影響を軸に、次の問いを確認します。
- 売上機会、採用、信用、安全、個人情報の取扱いに直接影響するか
- 代表的な利用者が最重要の行動を最後まで完了できるか
- 影響するページ、端末、利用者の範囲はどこまでか
- 公開中に使える明確な代替手段や、問題発生時に戻せる手順があるか
公開停止にする不具合
事業や安全に直結し、代替手段で十分に回避できない問題は、解消と再確認が終わるまで公開を止めます。主要フォームが送信できない、完了表示と実際の受信が食い違う、個人情報が意図しない宛先へ送られる、重大な事実誤認によって利用者が誤った行動を取る、制作会社から重大なセキュリティ問題が未解決と報告されている、といった状態が該当します。
発注側だけで技術的な深刻度を判断できない場合は、制作会社に影響範囲、再現条件、暫定回避策、修正後の確認方法を説明してもらいます。原因が不明という理由で軽い扱いにせず、最悪時の事業影響を基に公開責任者が判断します。
公開前修正にする不具合
主要行動は一部の条件で完了できるものの、多くの利用者が迷う、離脱する、誤操作する可能性が高い問題は公開前に直します。スマートフォンで応募ボタンが隠れる、主要ページへのリンク先が誤っている、必須の募集条件が欠けている、キーボードではフォーム送信へ進めないなどが例です。
修正後は、問題が起きた操作だけでなく、その前後を含むシナリオを再実施します。一箇所の変更が別の端末や導線へ影響することがあるため、証拠を差し替え、誰が再判定したかまで記録します。
公開後対応に回せる改善
目的達成を妨げず、影響が限定的で、公開中でも安全に修正できるものは公開後対応にできます。優先度の低いページの余白、意味を変えない文言調整、特定条件だけで起きる軽い表示のずれなどが候補です。
「公開後に直す」は放置の言い換えではありません。対象、影響、担当、期限、確認方法を残し、公開後の作業予定に組み込みます。公開日が迫っていることだけを理由に、公開停止や公開前修正の問題を格下げしないようにします。
検収結果を合意して引き継ぐ
検収の終点は、担当者が画面を見終えた時ではありません。未解決事項の扱い、修正担当、期限、再確認方法、公開責任者の判断が一つの記録にそろった時点で、公開作業へ引き継げます。
公開判断の前に、次の項目を確認します。
- 対象となるサイトの版、確認環境、確認日時が記録されている
- 最重要シナリオに期待結果、実際結果、証拠、判定がそろっている
- 未解決事項が公開停止、公開前修正、公開後対応に分類され、理由がある
- 各未解決事項に修正担当と期限が設定されている
- 修正後に再実施するテストケース、必要な証拠、再判定者が決まっている
- 公開当日の連絡先と、問題発生時に公開を止める判断者が決まっている
- 公開後に本番環境で再確認するシナリオと運用担当が決まっている
すべてにチェックが付くことは、不具合が一件もないという意味ではありません。残る問題とリスクを関係者が同じ資料で把握し、誰がいつ何をするか説明できる状態を示します。公開可否と契約上の検収完了が同じ条件とは限らないため、契約書、発注書、検収条件に定めがある場合は別途照合します。
公開後は、検証環境から本番環境へ切り替わったことで、URL、フォーム通知、外部サービスとの接続などに差が出る場合があります。公開直後に最重要シナリオを本番環境で一度通し、問題があれば合意した連絡先へつなぎます。実際に送信を伴う場合は、テストデータであることを明記し、受信担当にも時間を共有してください。
検収後には、更新に使う権限、ドメインやサーバー等の管理情報、納品されるデータ、保守の担当範囲も引き継ぎます。確認する資料や権限の整理には、納品後に受け取るものと管理情報の確認も参照できます。受け取った情報の保管責任者まで決めておくと、公開後の修正依頼や担当交代で迷いにくくなります。
まとめ
ホームページの公開前検収では、ページを眺めるのではなく、利用者が入口から目的の行動を完了できるかを試します。期待結果と実際結果を証拠付きで残し、事業影響と利用者影響から、公開停止、公開前修正、公開後対応を分けてください。
最初の一歩は、自社サイトで最も大切な利用者行動を一つ選ぶことです。「開始ページ」「操作」「期待結果」「確認担当」「残す証拠」を一行のテストケースとして書き出し、PCとスマートフォンで最後まで実施します。
参考資料
- DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック — デジタル庁、2024年5月31日。政府情報システムの整備・管理に関する実践的な参考文書です。本記事では、発注者側が受入テストの計画、シナリオ、合否判定を持つ考え方を参照しました。原文を見る
- DS-680.1 ウェブサイトガイドライン（デジタル社会推進標準ガイドライン） — デジタル庁、2025年9月30日（デジタル社会推進会議幹事会決定）。各府省が設置・公開するウェブサイトを対象とした指針です。本記事では、利用ニーズ、表示環境、品質評価の観点を中小企業の公開前確認へ読み替えて参照しました。原文を見る
- Easy Checks – A First Review of Web Accessibility — W3C Web Accessibility Initiative（WAI）、2023年8月9日更新。ウェブページのアクセシビリティを初期確認するための簡易チェックであり、包括的・確定的な適合評価ではないと明記されています。原文を見る
