← エピソード一覧に戻る Episode 165 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 速く出す会社ほど事故るのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発のデプロイ頻度を扱います。Etsy は web で 1 日最大 50 回、GitLab.com は 15 分ごとに新しい package を流します。ところが、速い会社ほど雑に出しているわけではありません。
ミカ
ミカです。正直、デプロイ頻度って『多ければ偉い』指標だと思っていました。毎日何十回も本番反映していたら、むしろ怖そうにも聞こえます。
タカシ
そこが重要な誤解です。SaaS におけるデプロイ頻度は、回数自慢ではなく、小さな変更を安全に届けて学べるかを見る指標です。速いこと自体より、変更サイズと安全装置の設計が問われます。
ミカ
なるほど。大きな荷物を月末に一気に運ぶより、小包でこまめに運ぶ感じですね。でも小包でも落としたら困るから、運び方の仕組みが大事そうです。
Chapter 2 基本 ― デプロイ頻度は回数ではなく学習速度
タカシ
Google Cloud の Cloud Deploy では、deployment frequency は本番へ届けた deployment day の頻度として扱われます。同じ日に 4 回出しても、その日は 1 日です。つまり、単発の量より継続的な到達リズムを見る考え方なんですね。
ミカ
へえ、回数を単純集計しないんですね。それなら『夜中に小さい設定変更を何回も流して数字だけ増やす』みたいなごまかしはしにくいです。
タカシ
その通りです。経営的に見れば、頻度が高いほど顧客の反応を早く学べて、失敗した時の変更単位も小さくできます。ただし SaaS は全顧客に同じコードが波及しやすいので、安全策なしの高頻度化は危険です。
ミカ
つまり、速く出すことと広く壊すことは紙一重なんですね。ここで canary とか feature flag が出てくるわけか。
Chapter 3 具体例 ― EtsyとGitLabは何が違うのか
タカシ
Etsy の面白い点は、頻度の裏に責任の近さがあることです。push train 方式で、変更を書いたエンジニア自身が staging から production まで見届ける。リリース専任の誰かへ丸投げしないので、学習が現場に戻ります。
ミカ
それは健全ですね。作った人が出すなら、障害の気配にも早く気づけそうです。逆に、出す人と直す人が別だと、学びが分断されそう。
タカシ
GitLab はさらに仕組み化が進んでいます。15 分ごとに package 候補を拾い、まず canary へ流し、自動 QA と実トラフィックを見て、30 分問題がなければ本番昇格する。しかも incident や change request があれば本番反映を止めます。
ミカ
速いのに、ちゃんとブレーキもあるんですね。高速道路に見えて、ところどころに検問と避難所がある感じです。
タカシ
うまい例えです。しかも GitLab は post-deploy migration を通常デプロイから分けて、rollbackability を守ろうとしています。頻度を上げるほど、『戻せる設計』の価値が大きくなるわけです。
Chapter 4 経営論点 ― 速さと顧客の予測可能性をどう両立するか
ミカ
でも B2B SaaS だと、顧客によっては『毎日 UI が変わるのは困る』って言われそうです。技術的に出せることと、顧客が歓迎することは別ですよね。
タカシ
その通りです。Atlassian Cloud は continuous track のほかに bundled track を用意し、働き方に影響する visible change は月次のまとまりで受け取れるようにしています。sandbox は preview track で先に試せます。
ミカ
なるほど。中では高頻度に改善していても、顧客への見せ方は予測可能に整えるんですね。プロダクト側の都合を、そのまま顧客に押しつけない。
タカシ
さらに Google SRE は canary で全量一斉反映のリスクを下げる考え方を示していますし、LaunchDarkly の progressive rollout や release policy のように、段階展開と承認ルールを標準化する発想も広がっています。速さは統制とセットです。
Chapter 5 クロージング ― 良いデプロイ頻度を作る5つの視点
タカシ
最後に整理しましょう。良いデプロイ頻度とは、たくさん出すことではなく、小さく出して、安全に学び、まずければ早く戻せることです。Banorte が bi-weekly から multiple deployments per day へ進めたのも、運用自動化と指標整備があってこそでした。
ミカ
METRO.digital も、2 週間に 1 回から週 3 の deployment day に改善して、MTTR まで良くなったんでしたね。頻度だけ独立して伸ばしたわけじゃないのが印象的です。
タカシ
明日からの実務では、まず本番ベースで deployment frequency を定義し、lead time、change failure rate、平均復旧時間と一緒に見てください。そのうえで、変更サイズ縮小、canary、feature flag、migration 分離を優先すると改善しやすいです。
ミカ
そして enterprise 顧客が多いなら、sandbox や preview、告知の運用も忘れない。速く出すことと、安心して受け取ってもらうことを両立するのが SaaS 経営なんですね。
タカシ
今日は SaaS 開発のデプロイ頻度を取り上げました。次回は、この速さをさらに立体的に見るための指標、変更リードタイムを扱います。皆さんの開発組織では、速さと安全、どちらをどう両立しているか、ぜひ振り返ってみてください。