引き継いだとき、リリースフローの意味はよくわかっていなかった。
ステージングで確認して、変更管理ドキュメントを書いて、テックリードが承認して、本番にリリースする。ベンダーからそういうフローを受け取って、そのままやっていた。なぜその手順なのかを深く考えたことはなかった。
意味がわかったのは、監査対応のときだ。
監査でCSVを用意することになった
治験依頼会社による監査が入ったとき、変更管理の証跡を準備する必要があった。「いつ・誰が・何を変えたか・誰が承認したか」が追跡できる状態になっているか、という確認だ。
そのとき初めて、ベンダーが設計したリリースフローの構造が腑に落ちた。
変更管理ドキュメントを書くのは、「後で説明できるようにするため」だった。コードレビューをGitLabのMRで残すのも、承認者を記録するためだった。SOPをGitで管理するのも、「いつ・なぜ変えたか」が追えるようにするためだった。
規制産業のリリース管理は、「正しく動く」だけでなく「正しく動いていたことを証明できる」状態を維持するものだということを、監査の準備を通じて理解した。
今のリリースフロー
引き継いだフローを今も基本的に使っている。
- 開発ブランチからMR作成・コードレビュー（GitLab）
- ステージング環境での動作確認（開発者＋業務担当者）
- 変更管理ドキュメントの作成（影響範囲・テスト結果・ロールバック手順）
- テックリード（自分）による最終承認
- 本番リリース実行＋バックアップ確認
- リリース後監視
監査対応を経て、細部を整えた部分もある。変更管理ドキュメントのフォーマットを揃えた、SOPのバージョン管理をWordからMarkdown+GitLabに移した、ロールバック手順を具体的に書くようにした。
「誰でも実行できるレベルで書く」は特に意識している。自分が不在のときでも、チームが同じ手順で動けるようにするためだ。
SOPは「書いて終わり」にしない
SOPが形骸化する原因は、実際の運用と文書が乖離することだ。
Wordで管理していた時期は、最新版がどれかわからなくなっていた。今はMarkdownでGitLabリポジトリに置いて、変更はMRで管理している。「いつ・誰が・なぜ変えたか」が自然に追跡できる。
それでも油断すると古くなる。四半期に一度、実際の運用と突き合わせて差分を直す習慣にした。監査で「文書と実態が違う」と指摘されるのは、技術の問題より深刻に見られる。
バックアップとロールバックは「戻れるか」が基準
リリース前後に必ず確認すること：
- リリース前：RDSのスナップショット取得確認
- リリース後：主要機能のスモークテスト
- ロールバック手順：前バージョンのDockerイメージタグとデプロイコマンドをリリースチケットに記載
ロールバック手順は毎回書いている。一度も使わなくても書く。「いざとなれば戻れる」という状態があることで、リリース判断が変わるからだ。
引き継いだものを「自分のもの」にする
ベンダーが設計した仕組みを、最初は意味もわからず使っていた。
監査を経て、なぜその手順が存在するかを理解した。理解してからは、「守るべきもの」として扱えるようになった。形式的にこなすのではなく、この手順が何を守っているかを意識してやれるようになった。
引き継いだシステムを自分のものにする、ということはコードだけじゃない。運用の設計ごと理解することだ、と今は思っている。
関連記事: