ENGINEER エンジニア 2026.11.07

テストと確認の手間を減らすチェックリストの作り方

公開前の確認が担当者の記憶頼りだと、似た不具合を繰り返し見落とす。品質を保ちながらレビュー時間を短縮し、再修正の費用を抑…

text: HYPE編集部

公開前の確認が担当者の記憶頼りだと、似た不具合を繰り返し見落とす。品質を保ちながらレビュー時間を短縮し、再修正の費用を抑える。問い合わせフォームの送信不可、誤った料金表示、モバイルの崩れなど、過去に起きた事故と重大な事故を候補にする。単に「見た目を確認」とせず、顧客への損害や問い合わせ逸失に関係する項目を優先する。

チェック項目は、過去の事故から作るのが近道です。損害につながるものから優先しましょう。

Table of Contents

まず事故の種類を洗い出す

リンク切れ、フォーム不達、表示崩れ、権限ミス、誤字、計測漏れを過去案件の不具合から集める。

「確認する」ではなく、判断できる文にすること。誰がやっても同じ判定になる書き方が理想です。

公開事故の種類を洗い出す際は、セキュリティ面の事故も切り分けておくと、確認項目の漏れが減ります。IPA（情報処理推進機構）の情報セキュリティのページでは、組織や個人に向けたセキュリティ対策の情報が発信されています。

項目は判断可能な文にする

「デザイン確認」ではなく「スマートフォンの主要画面で文字が重ならない」など合否が判定できる表現にする。

「問題がないこと」では判定が曖昧になる。たとえば「必須項目を空欄のまま送信するとエラーが表示される」のように、操作、期待結果、実際の結果を同じ行で確認できる形式にする。

テスト条件を書く練習では、操作と期待結果を一行ずつ対応させてみる。体系立てて学びたい場合は、Webスキルを学ぶオンラインスクールデイトラのようなオンラインスクールも選択肢になります。

重要度で順番を決める

決済、個人情報、問い合わせなど業務影響の大きい項目を先に点検する。

購入や申込が止まる不具合、個人情報の表示、決済失敗時の挙動は先に点検する。装飾の微調整と同じ順番に並べず、公開可否を左右する項目を別の欄へまとめる。

環境を記録する

端末やブラウザ、ログイン状態、検証日時、対象URLを残し、再現できるようにする。

ブラウザの種類、端末の画面幅、ログイン状態、テスト用アカウントを記録する。特定の端末だけで起こる表示崩れは「再現しない」で終えず、発生条件を残して担当者へ渡す。

確認した環境を記録に残す運用は、制作物の変更履歴を残す考え方と地続きです。GitHub Docsの入門ページでは、バージョン管理や共同作業の基本的な流れが案内されています。

結果と証跡をセットにする

合否だけでなく画面キャプチャや再現手順、担当者、修正期限を残す。

チェック結果にはスクリーンショットや画面録画、問題が起きたURL、再現手順を添える。コメント欄に「NG」とだけ書くより、直す人が同じ現象を確認できる証拠を付ける方が効率的だ。

画面ごとの重要度を決める課題は、公開前の確認順序を考える材料になる。体系立てて学びたい場合は、Webスキルを学ぶオンラインスクールデイトラのようなオンラインスクールも選択肢になります。

確認責任を分ける

制作者の自己確認、別担当のレビュー、発注者の業務確認は見る対象を明確に分ける。

制作担当が動作確認し、発注者は業務内容や文言を確認するなど、検収範囲を分ける。顧客が管理する決済アカウントや本番メールの確認は、実行できる権限を持つ担当者に割り当てる。

項目が増えすぎると、確認そのものが形だけになります。定期的に棚卸しして、絞り込みましょう。

チェックリストの肥大化を防ぐ

案件ごとの必須項目と共通項目を分け、意味の薄い確認を定期的に整理する。

同じ項目を何度も増やさず、過去の不具合に直結しない確認は統合する。使われないチェック欄より、公開前に必ず通る重要項目を短く保ち、例外だけ案件ごとに追加する。

不具合の再現手順を書いて伝える実習は、差し戻し時の説明に役立つ。材料を広げるなら、雑誌のオンライン書店 Fujisan.co.jpで専門誌を読む方法もあります。

納品後に更新する

公開後の問い合わせから漏れた項目を拾い、次の案件で同じ失敗が起きないようにする。

公開後にフォーム障害が起きたら、原因と再発防止項目を追記する。修正したチェックリストの版も記録し、次の案件では「どの事故を防ぐための項目か」が説明できるようにする。

チェックリスト自体の更新も、いつ・なぜ項目を変えたかが追える形にしておくと、次回の見直しが速くなります。GitHub Docsでは、変更を履歴として残すバージョン管理の考え方が案内されています。

自分の仕事と売上にどうつなげるか

申込フォームを例にすると、テストに必要なのは「正常に送れる」だけではない。必須項目が空欄の場合、メールアドレス形式が誤っている場合、送信先への通知が止まった場合も挙動を確認する。条件を一行ずつ分け、操作した端末と確認結果を記録すれば、発注者はどの状態を検収したか把握できる。次の案件で同じ失敗が起きたときには、チェック表へ具体的な再現条件を加える。

実際に案件へ組み込む場合の確認メモは次のようにまとめられる。