はじめに
事業部MVPを取った優秀な後輩から「イベントだし、おまえも記事書くよな？」的な圧を感じたので記事を書いたのですが、「まだまだ書けるよな？」と新しい圧を感じたので、もう一記事書くことにしました。
大規模リリースって、意外とあるよね
プロダクト開発をしていると、ちょっと大きめのリリースってありますよね。
本当は細かくリリースしていきたいけど、いろんな事情で大きくリリースすることになったりしますよね。
大規模リリースは戦？祭り？オーケストラ？
大規模リリース と聞いた時、どんなイメージを持ちますか？
戦？祭り？オーケストラ？
人それぞれ印象が違うと思います。
その違いは、それまでの過去の経験によって左右されている気がします。しらんけど。
私にとっての大規模リリースはなんだろう？
祭りに近いかもしれません。たぶん。
この記事で書くこと
大規模リリースで気をつけたいこと、気をつけていることをまとめてみようと思います。
おっしゃ Let's 大規模リリースだ！
ぱみゅぱみゅ先生の歌詞をオマージュしました。
なんとなく。なんとなくです。
ただ言ってみたかっただけです。
ここから先は真面目に書きます。
1. テスト期間 - 不具合ゼロ って不安じゃない？
「よし！今回は完璧だ！テストで不具合も見つからない！」
これはもう完全に個人的な経験則ですが、 テストで不具合が見つからないときほど不安になることはない です。
だって、大規模リリースですよ？
多くの新機能だったり、多くの改修だったり、リリース対象が多いんです。
そんな状況で不具合ゼロって、 テストが機能していなくて絶対何かを見落としている可能性の方が高い と考えてしまいます。
不具合が出すぎても不安ですが、不具合ゼロの方が圧倒的に不安になります。
2. リリース準備 - 「リリース手順書は猿でも分かるように書け！」
「自分でリリース作業するし、イメージできてるから、手順書とか省いちゃっていいか！」
SIerにいた頃、上司から口酸っぱく言われていました。
「もしお前が体調崩したり急遽休まなきゃいけなくなったらどうするつもり？そこまで考えて準備するのがプロの仕事だぞ？」
猿でも分かる手順書って、どんな手順書？
手順書作成や、手順書のレビューをする際に気をつけている点は、こんな感じです。
- 手順は とにかく細かく
- CUI操作があるときは、手順書にコマンドを省略せずに書き、そのままコピペできるようにする
- GUI操作があるときは、〇〇の画面で□□というボタンを押下するといったレベルで書く
- 完了条件を 明示 する
- 手順を実行した結果、どうなっていたら次のステップに移れるか明確に書く
- リトライ判断や切り戻し 基準も明確 にする
- 初めて作業する人でも判断に迷わない基準がBest
- 例えば、このような感じです。
- ここまで行って、△△となっていない場合は、N番の手順をリトライする
- このメッセージが表示されたら、リリース作業を中止して切り戻し手順のXを実行する
リリースのリハーサルをやるなら、できる限り本番と同じ状況で実施
リリースリハを行う場合、できる限り本番と同じ状況で確認しましょう。
本番リリースが平日午前中なら平日午前中に。
週末の深夜帯なら週末の深夜帯に。
バッチ処理とぶつかって、作業が止まってしまう。
その時間帯はネットワーク負荷が高くて、リモート操作がスムーズに行かない。
そんな 予期せぬ事態 が潜んでいるかもしれないです。
なので、できるだけ本番と同じ状況でのリハーサルが吉です。
3. リリース作業 - 勝手なことをするな！
「手順書を何回も見たし、覚えているから安心！」
せっかく丁寧に猿でも分かるような手順書を書いて、それに沿ったリハーサルをしたのですから、手順書通りに作業しましょう。
「こっちのコマンドの方が効果的だから！」
「こっちの画面から操作しちゃおう！」
といった、その場の判断はやめましょう。
手順書は、 料理のレシピ のようなものです。
小さじを計らず目分量にしたり、手順をすっ飛ばしたり、勝手にアレンジを加えて、料理が台無しになった経験ありませんか？
リリース作業も同じです。
冷静に、丁寧に、レシピ（手順書）通りに。
4. リリース後の臨戦態勢 - リリース後は心もスケジュールも余裕を持って！
「よし、無事にリリースも終わったし、次の開発スタートしちゃうか！」
いくら本番同等のステージング環境でテストを行っても、
いくら本番同様の状況でリハーサルを行っても、
完璧に同じ状況ではないので、何かが起こるかもしれません。
そんな時、だれも気付けなかったら？
そんな時、だれも対応する余裕がなかったら？
考えるだけでもゾッとしますよね。
リリース後は 心に余裕 を！
リリース後は スケジュールに余裕 を！
もし仮に何かがあっても即座に対応できる余力を作っておきましょう。
個人的には、システムステータスとかアラートチャンネルを横目に雑談してるくらいでちょうど良いと思っています。
（まぁ、そこまでの余裕は難しい場合がほとんどですが・・・）
まとめ
大前提として、避けられるのであれば大規模なリリースは避けたいっていうのが本音ではあります。
それでも、様々な事情で避けられないこともあります。
リリースは、祭りかもしれないし、戦いかもしれないし、オーケストラかもしれません。
でも、どんな形であっても、「良いリリースだった」と言える日になるよう、冷静に、丁寧に、そして少しの余白をもって臨んでいきたいですね。
最後に - 私たちの最近のリリース
私もつい先日、PdMを担当しているプロダクトで大きめのリリースを行いました。
別プロダクトとの連携のあるリリースで、事業部MVPを取っちゃうような優秀な後輩の所属する部署のみんなとリリース前日まで調整と確認を繰り返していましたが、無事にリリースが完了しました。
後輩もその部署のみんなも全員優秀で全員が協力的でとても助かりました。助けられました。本当にありがとうございました。
