個人開発を公開する前のチェックリスト
公開前の確認は、「トップページが表示された」で終わりません。利用者が目的を達成できること、失敗から戻れること、運営者が問題に気づけることを、小さな一覧で確認します。全部を完璧にするより、致命的な穴を残さないことが重要です。
主要な流れを本番相当で通す
開発用データではなく、公開時に近い設定で中心操作を一周します。
初めて訪れた状態から始める
入力、保存、再表示まで進む
ページを再読み込みする
別の画面幅でも同じ操作を行う
JavaScriptが失敗しても必要な説明へ到達できるか見る
正常時に加え、空データ、不正な入力、通信失敗、存在しないURLも確認します。エラー画面には内部のパス、秘密情報、例外の全文を表示しません。
公開設定を見直す
本番環境に、デバッグ画面、サンプル用アカウント、不要なテストページが残っていないか確認します。OWASPのWeb Security Testing Guideでも、不要な既定ファイルやデバッグ用機能を本番から除き、ログの仕組みを見直すことが挙げられています。
最低限、次を確認します。
秘密情報がコードや公開ファイルに含まれていない
本番とプレビューの設定先が分かれている
書き込み権限が必要な処理だけに絞られている
依存サービスが停止したときの表示がある
元へ戻す手順が記録されている
読みやすさと操作を確認する
キーボードだけで主要操作を通し、フォーカスが見えるか確認します。画像には役割に合う代替テキストを付け、飾りだけの画像は読み上げ対象から外します。入力エラーは色だけに頼らず、場所と直し方を文章で示します。
表示速度を数字で見る
Core Web Vitalsは、読み込み、操作への応答、表示の安定性を見る指標です。良好の目安は、75パーセンタイルでLCP 2.5秒以内、INP 200ミリ秒以内、CLS 0.1以下です。計測値は端末や回線で変わるため、開発機の一回だけでなく、公開後の実測も確認します。
大きな画像には表示寸法を与え、最初に見えない画像は遅延読み込みを検討します。使っていないJavaScriptを減らし、読み込み中に領域が動かないようにします。
公開後の最初の確認を予約する
公開直後、翌日、一週間後に見る項目を先に決めます。問い合わせ、エラー、主要操作の完了、速度の悪化を確認し、異常があれば戻すか修正します。公開は作業の終了ではなく、観察を始められる状態です。
公開を止める条件を先に決める
確認項目には、合否と判断者を付けます。次のような問題が一つでも残る場合は、日時が迫っていても公開を止めます。
中心操作を完了できない、または保存結果が失われる
認証を越えて他人の情報を閲覧・変更できる
秘密情報や内部エラーが画面・ログ・成果物へ出る
課金額、契約内容、解約方法が表示と一致しない
重大な障害から戻す手順を実行できない
法務・権利・プライバシー上必要な確認が未完了である
一方、軽微な余白や文言の好みは、影響と修正予定を記録した上で公開後の改善へ回せます。すべての指摘を同じ重要度にしないことが、重大な問題を見落とさないために役立ちます。
公開記録を残す
公開した版、実行した確認、未解決事項、戻し先、確認担当者を一つの記録へ残します。公開後に問題が起きたとき、「何が変わったか」「どの状態へ戻せるか」をすぐ判断できるためです。
公開日時:
対象バージョン:
本番設定の確認者:
中心操作の結果:
未解決事項と影響:
ロールバック先と手順:
公開直後・翌日・一週間後の確認予定: