ウェブサイト課の野津です。
最近ハマっているテントは空気で膨らませるタイプのエアーテントです。（設営の自動化！）
この記事はヌーラボブログリレー2025夏の3日目として投稿しています。
目次
はじめに
インフラ設定の変更は緊張感がありますよね。
軽微な変更だとしても想定外の影響が出る可能性があり、ちょっとしたミスや考慮不足がトラブルにつながる恐れがあります。
これらを軽減するために「インフラ設定を変更するときのチェックリスト」 を作成しました。
元々ウェブサイト公開に際してのチェックリストはありましたが、今回はインフラ観点（サーバーやネットワーク等）のものを作成しましたので紹介します。
期待される効果
チェックリストの導入によって、以下の効果を狙っています。
セキュリティリスクの削減：セキュリティインシデントを未然に防ぐ
レビューの効率化：セルフチェックにより初歩的なミスが減ることで、より本質的な技術的議論や設計改善に時間を割く
チェックリストの紹介
ver.1として以下のようなチェックリストを作成しました。
1. 変更作業前 1.1 コード全般 - 変数/関数の命名がわかりやすいものになっているか - スペルミスがないか - 不要なコメントアウトが残っていないか - 確認・デバッグ用のコードは残っていないか - コメントがコードと食い違っていないか - コピペした箇所を見直したか - 不要なファイルはコミットされていないか 1.2 URLリダイレクト作業 - リダイレクトの内容以外の影響もチェックしたか 1.3 アップグレード - バックアップが取られているか - リポジトリを検索し古いバージョンのままのコードが残っていないか 1.4 新規ウェブサイト構築 - 脆弱性のチェックができているか - 不要ポートを閉じたか - 障害時の復旧手順を準備したか - 適切な監視設定ができているか - ウェブサイトへの埋め込みタグが必要か検討したか 1.5 レビュー - 些細なことでも変更時に必ずレビューを受けたか - レビュー依頼時に目的、やったこと、確認してほしいことを明確に記載したか - レビュー依頼時にテスト実行時のログを記載したか 2. 変更作業時 - 作業内容を記録しているか - 重要な変更は作業開始・終了を関係者に報告したか 3. 作業後のチェックリスト - 対応課題の依頼内容を再確認したか - インフラ変更後にリポジトリへのマージ忘れがないか確認したか - レビューの承認記録を確認してからマージしたか - アクセスログやエラーログ等を確認し問題がないか確認したか - リリース後にバックアップや監視が正常稼働しているか確認したか - 作業規模や結果に応じてふりかえりを実施したか
各項目の内容を以下で補足します。
変更作業前
コード全般
- 変数/関数の命名がわかりやすいものになっているか - スペルミスがないか - 不要なコメントアウトが残っていないか - 確認・デバッグ用のコードは残っていないか - コメントがコードと食い違っていないか - コピペした箇所を見直したか - 不要なファイルはコミットされていないか
コード修正やレビューの際には、生成AIを積極的に活用しています。
例えば、AIにコードのベースを作成してもらったり、人間がレビューする前に初歩的なミスがないかチェックを依頼したりすることで、作業効率を向上させています。
ただ、冗長なコード、コメントが生成されることもあり、現状は手で修正することも多いです。
URLリダイレクト作業
- リダイレクトの内容以外の影響もチェックしたか
ウェブサイトのページ削除時にリダイレクトをさせることは多くあると思いますが、ページの削除による影響もあわせて考えます。
例えば、削除したページへリンクが貼られていないか、削除したページからしか貼られていないリンクが無いかといった点です。
また、新しいリダイレクト処理が既存のリダイレクト処理ルールに影響していないかについても確認する必要があります。
アップグレード
- バックアップが取られているか - リポジトリを検索し古いバージョンのままのコードが残っていないか
過去にソフトウェアやフレームワーク等の古いバージョンの記載が残っていてうまくウェブサイトが動作しないことがありました。
そのため、アップグレードをする際はリポジトリ全体を古いバージョンで検索するようにしています。
新規ウェブサイト構築
- 脆弱性のチェックができているか - 不要ポートを閉じたか - 障害時の復旧手順を準備したか - 適切な監視設定ができているか - ウェブサイトへの埋め込みタグが必要か検討したか
新規のウェブサイトを構築する際に脆弱性のチェックや不要なポートチェックが必要ですが、各ツールやCI/CDパイプラインを動かすことで省力化が可能です。
ウェブサイトへの埋め込みタグについては、Cookie同意バナーやマーケティングツール等の考慮漏れがないか確認をしています。
レビュー
- 些細なことでも変更時に必ずレビューを受けたか - レビュー依頼時に目的、やったこと、確認してほしいことを明確に記載したか - レビュー依頼時にテスト実行時のログを記載したか
レビューを依頼するにあたっては相手の立場になってできるだけ時間を取らせないように心がけています。
「なぜこの変更が必要なのか、何を変更してどこをチェックをしてほしいのか」を手順を含めて記載しておけば、後で問題が起きにくくなります。
レビュー依頼内容についてもAIを活用しており、内容のベースの作成や補足、人間へのレビューを依頼する前のレビューをしてもらっています。
Backlogの課題作成もそうですが、ベースがあるだけで文章作成にかかる時間をかなり削減できています。
レビュー依頼内容のベース作成のためのプロンプト例
あなたは、課題内容やコードの変更内容を分析し、レビュー依頼内容を作成するアシスタントです。
以下の内容を読み取り、指定されたMarkdownフォーマットでレビュー依頼内容のベースを作成してください。
- 分析する内容（課題内容、コードの変更内容、雑なメモを書く）
- {内容ここから}
- ここに貼る
- {内容ここまで}
- 各項目について、内容から関連する情報を抽出し、記述してください。
- 出力フォーマット
- 以下のMarkdown構文をコピーボタンでコピーできるようにしてください
- 英語と日本語で出力してください
### Summary
(If necessary) Describe the pull request's overview.
### What I did
Describe what I did.
### How to check
(For the code reviewer) Describe the method and procedure for checking and what you want them to check.
### Related issues
(If there are related issues, describe them here)
良い書き方を模索中！
変更作業時
- 作業内容を記録しているか - 重要な変更は作業開始・終了を関係者に報告したか 作業した内容は、他の人がみても変更内容が分かるようなログやスクリーンショットをBacklog課題に記録しています。
重要な変更については関係者に対して作業開始と終了時にチャットでメンションします。
リモートでの作業は特に誰が何をしているかが伝わりにくいため、大袈裟なぐらいに報告をする方が良いと思っています。
作業後
- 対応課題の依頼内容を再確認したか - インフラ変更後にリポジトリへのマージ忘れがないか確認したか - レビューの承認記録を確認してからマージしたか - アクセスログやエラーログ等を確認し問題がないか確認したか - リリース後にバックアップや監視が正常稼働しているか確認したか - 作業規模や結果に応じてふりかえりを実施したか
規模の大きい対応や多くの人が関わる作業、問題のあった作業は関係者でふりかえりのミーティングをセットし、良かったことや改善できる点を共有して次回に活かします。
ふりかえりは事前にカレンダーにミーティングをセットしておくことで忘れずに実施できると思います。
おわりに
こういったチェックリストは作っただけで満足して放置されがちですが、適切な運用、アップデートをしていく必要があります。
今後はチェックの自動化やAI支援をさらに取り入れながら、エアーテントのような使いやすいものにしていければと思います。