ホームページ制作の
失敗を防ぐ。
山梨の発注者が行う
公開前チェック。

「なんとなく使いにくい」だけでは、直す箇所が伝わりません。どの画面で、何をしようとして、どこで止まったかを書きます。配色の好みと、問い合わせできない不具合を同じ欄に混ぜないことが出発点です。

制作中の問題と、公開後の課題を分ける

編集部で、わざと不具合を入れた小さなページと修正版を作りました。2026年10月14日に、同じ幅390pxで3項目を比較しています。実在の顧客サイトではなく、確認方法を説明するためのモデルです。

見た目では分からない結果を記録

この実測で分かるのは、画面の存在と操作結果を別々に調べる必要があることです。修正版も入力確認までで、誰かへ届いた証明ではありません。「何が動いたか」を具体的に残すと、未確認の範囲が見えます。

完成後に「更新できると思っていた」と気付くのを避けるため、必要な操作を見積もり時に伝えます。ページ数に加えて、どの情報を自社で直すか、何を引き渡してもらうかを一緒に確認してください。

社内の事実確認は、発注側に残る

山梨の事業所で立ち会う場合も、画面を見せてもらうだけで終えず、担当者自身が操作する時間を取ります。確認日を制作工程表へ入れ、休業日や繁忙期を避けて予定を合わせます。

スクリーンショットだけでは、押した順番や入力条件は伝わりません。修正担当が同じ状態を作れるよう、URL・端末・操作・期待・実際の5点を書きます。別の問題は行を分け、修正版でも同じ手順を試します。

急ぎの修正と追加依頼を分ける

修正の回数や範囲は契約で異なります。見つけた問題を一律に無料対応と決めず、契約書の修正・保守範囲と照合します。担当と再確認日を残し、対応したという返事だけで完了にしません。

W3CのReflow解説は、狭い画面や拡大時に文章を読み進められることを扱っています。PCの縮小画像だけでなく、実際のスマホでも文字切れ・メニュー・押した後の状態を見ます。

W3Cのフォーム通知の解説は、入力エラーや成功時の案内を説明しています。受付画面の表示と通知の受信は分け、制作担当と合意したテストで照合します。実際の顧客情報は使わないでください。

画面の成功表示と、受信は別の確認

全部にチェックが付いていても、確認対象を間違えていれば判断できません。公開する版と確認した版が同じか、重要な未対応事項が残っていないかを責任者と共有します。次の3問で、確認する範囲をそろえてください。

同じ手順を、修正後にも試す