リリースの仕組み

デプロイはコードを本番に出すこと、リリースはその機能をユーザーに見せることです。この2つを分けると、コードは先に出しておき、機能を見せるタイミングや相手を後から選べます。その切り替えに使うのが Feature Flag（機能のオン・オフを設定で切り替える仕組み）です。問題が起きたら、コードを戻さずにフラグを切るだけで止められます。

フラグは増えるほど組み合わせが複雑になるので、全員に公開したら消す作業もタスクに入れます。

Web の「安全なリリース」

審査・段階的な公開・古い版

SRE の「デプロイ戦略」

書いたコードは、ほかのエンジニアのレビュー、自動テスト、本番に近い環境での確認を通ってから本番に出ます。コードを入れるたびにテストを自動で流すことを CI（継続的インテグレーション）、本番に出すまでを自動にすることを CD（継続的デリバリー・デプロイ）といいます。

ステージングで動いても、本番で問題が出ることがあります。データの量や種類、外部サービスの設定が違うからです。本番で社員だけに見せる（Feature Flag の社内公開）と、本物のデータで確かめられます。テストのために本番のデータを勝手に変えない、個人情報をステージングに持ち出さない、も大事な決まりです。

カナリアとブルーグリーンは主にコードの出し方、Feature Flag は機能の見せ方です。PdM が直接決めるのは多くの場合 Feature Flag ですが、大きな変更ではどの出し方かを聞いておくと、問題が起きたときの影響と戻る時間が分かります。

リリースの後で問題が出たら、原因を調べるより先に影響を止めるのが基本です。前の版に戻すことをロールバック、直した版を出して進むことをロールフォワードといいます。

PdM は事前に「どうなったら戻すか」（エラー率・問い合わせ・指標の悪化の基準）と、誰が決めるかを合意しておきます。その場で迷う時間を減らせます。

Google の DORA という研究チームが、開発チームの速さと安定性を測る指標を示しています。速さと安定性は取り合いではなく、良いチームは両方とも良い、というのが研究の結論の1つです（指標は年によって少しずつ見直されています）。

PdM にとっては、小さく何度も出せるチームほど、仮説を早く確かめられることが大事です。デプロイの頻度が低い・リードタイムが長いなら、負債やテストの自動化への投資を考えるきっかけになります。指標を人の評価に使うと数字が歪むので、チームの改善のために使います。