Web制作の納品前、誰がどこまで確認する？発注者と制作会社のチェック項目

「確認をお願いします」だけでは、見落とす範囲が残る

制作会社から確認用のURLが届くと、まず文章や画像の間違い、会社情報や電話番号を確認することが多いでしょう。こうした確認は欠かせませんが、画面を眺めるだけでは、フォームが送れない、予約が重なる、別の会員の情報が見えるといった問題を十分に確かめられません。利用者が実際に行う操作まで、確認の予定に含める必要があります。

発注者にしか分からない内容と、制作側が確認しやすい内容を分けて整理します。発注者は、商品情報、業務のルール、利用者に伝える説明が正しいかを判断します。制作側は、実装した機能が想定した条件で動くか、利用環境や設定に問題がないかを確認します。ただし、これは一般的な整理であり、実際の担当範囲は契約や体制に合わせて合意してください。

特に、公開の可否を決める人を明確にしておきます。文章を確認した担当者の返事を、すべての機能を確認した承認として扱わないようにしてください。「会社情報は確認済み」「フォームの送受信は確認中」というように範囲を言葉にすると、どこまで終わったかを共有できます。確認済みという一言の中に、異なる作業をまとめないことが出発点です。

納期が近いときほど、確認できていないことを早めに伝えます。確認環境へ入るためのアカウントがない、外部サービスの契約が終わっていないなど、作業を止めている条件を書き出してください。問題が見つからなかったことと、そもそも確認できなかったことは分けて記録します。

確認を始める前に、発注時の要件と、途中で決まった変更内容を並べておくことも有効です。会議で決めたことが担当者の記憶だけに残っていると、完成画面を見てから認識の違いに気づきます。決定した日と内容を短く記録し、判断が必要な事項を一覧にして、納品前の確認で参照できるようにします。

画面の見た目より先に、利用者の一連の操作をそろえる

最初に、サイトで利用者にしてほしいことを短い文章で並べます。問い合わせであれば、内容を入力し、間違いを修正し、送信し、完了を確認するまでが一連の操作です。管理側へ届く通知や、利用者へ返す案内まで含めると、画面単位の確認では抜けやすい部分も見えてきます。

次に、正常に進む場合と、途中で困る場合を分けます。必須項目を空欄にした、入力をやり直した、前の画面に戻った、同じボタンを続けて押した場合などです。どの条件を確認するかは、機能の仕様に合わせて決めます。「エラーが出る」だけでなく、「入力した内容を保ったまま、直す場所が分かる」といった期待する結果まで共有すると、修正の相談がしやすくなります。

ログイン機能がある場合は、一般の利用者と管理者で操作できる範囲を分けて確認します。認証は本人かを確かめること、権限はその人が何をしてよいかを決めることです。ログインに成功しただけでは、この両方を確認したことにはなりません。利用者の区分と見られる情報を整理し、確認を行う権限を持った担当者へ依頼します。

Webのセキュリティ確認を整理する資料として、OWASPはWeb Security Testing Guideを公開しています。専門的な確認を依頼する際には、資料名だけを指定するより、自社の対象画面と対象外の範囲を先に伝えることが有効です。診断のために本番環境へ負荷をかけたり、許可のないサイトを操作したりしないよう、実施条件も合意します。

端末・性能・使いやすさも、確認する条件を具体的にする

スマートフォン対応は、横幅に収まっていれば完了とは限りません。入力中にボタンが隠れないか、押したい場所を操作できるか、横向きにしたときも必要な情報を読めるかなど、利用の場面で確認します。対象端末やブラウザは、想定する利用者と契約内容に合わせて決め、確認していない環境も報告に残します。

性能は「なんとなく遅い」という感想で終わらせず、どの画面の、どの操作に待ち時間が生じるかを記録します。表示されるまでなのか、検索結果が返るまでなのかで、調べる場所が変わるからです。計測を依頼する場合は、通信環境、データ量、確認した日時も合わせて残します。小規模な確認の結果だけで、多数の人が同時に使う場面まで問題がないとは判断できません。

基本的なアクセシビリティ、つまり利用する人の特性にかかわらず情報や操作へたどり着きやすいかも見直します。キーボードで操作できるか、文字を大きくしたときに必要な内容が隠れないか、入力項目の説明やエラーの場所が分かるかといった点です。色だけで注意を伝えず、言葉も添えると、確認する担当者同士の認識もそろえやすくなります。

W3CのWCAG 2.2は、Webのアクセシビリティを考えるための資料です。ここで挙げた基本確認を実施しただけで、規格全体への適合を示すことはできません。基本の点検と、特定の基準に対する専門的な評価を区別し、依頼する範囲を明確にしてください。

確認結果には、担当者・判断条件・未確認事項を残す

確認表には、項目名だけでなく、担当者、実施日、期待する結果、実際の結果を残します。「問い合わせを送る」という項目なら、どの宛先に通知が届き、利用者にはどの案内が表示されるかまで書くと判断が具体的になります。画像や短い記録を添える場合も、個人情報やパスワードをそのまま残さないようにします。

不具合を見つけたときは、発生した画面、操作の順番、利用環境、業務上の影響をまとめます。担当者が同じ状態を確認できれば、修正の相談が進みます。優先度は文字のラベルだけで決めず、受付が止まるのか、一部の表現の修正なのか、公開を待つ必要があるのかを関係者で判断してください。

制作担当者とは別の視点で確認したい場合は、Custosの公開前診断も選択肢です。依頼前に、確認できる機能や環境、必要なアカウント、対象外の項目を確認します。第三者に依頼する場合も、業務の仕様や公開の最終判断まで自動的に引き渡せるわけではありません。発注者と制作側で判断する範囲を残してください。

納品時には、修正済みの項目と、未対応・未確認の項目を分けて渡します。修正後に再確認したかも必要です。公開を優先して残す項目がある場合は、その理由、対応予定、担当者を合意します。引き継ぎ資料は問題の存在を責めるためではなく、次の担当者が迷わず対応できる状態をつくるために使います。

依頼時はサービスの対象範囲にも注意してください。Custosの公開前診断はWebアプリを対象とし、端末へインストールするネイティブアプリは対象外です。負荷試験、プログラムのコードレビュー、修正代行、WCAGへの適合判定は含まれません。セキュリティの詳しい評価は、別の脆弱性診断の範囲を確認して相談します。必要な確認を一つの依頼ですべて済ませたと思い込まないことが大切です。

まとめ｜納品前の合意を、公開後の保守へつなげる

納品前チェックは、文章やデザインの確認に加え、利用者の操作、権限、端末の違い、性能、使いやすさまで範囲を整理する作業です。誰がどこまで見たか、何をもって完了とするかを決めると、発注者と制作会社の行き違いを減らせます。未確認の部分を隠さず、次に何をすべきかが分かる形で残しましょう。

公開後には、更新や機能追加に合わせてセキュリティ上の弱点を確かめる機会も必要です。CustosのURL診断などを検討する際も、診断できる範囲を確認し、修正を相談する担当者まで決めておきます。公開前の不具合確認と公開後の脆弱性診断をつなげ、納品で確認の流れを切らないことが大切です。

制作会社が顧客へ提案する場合は、見積もりの段階から、公開前の確認と公開後の保守を分けて説明すると相談しやすくなります。自社ブランドでの提供を含む連携については、SELF-CONSULTINGへご相談ください。確認の対象と運用体制をそろえ、利用者にとって使いやすいサイトを継続して育てていきます。