← エピソード一覧に戻る Episode 167 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 10回出して4回壊す組織は速いのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の変更失敗率を扱います。DORA の 2024 年レポートでは、elite 層の change fail rate は 5%、low 層は 40% という差が出ています。10 回出して 4 回壊すなら、さすがに速いとは言えませんよね。
ミカ
ミカです。変更リードタイムの回で『早く届くか』を見ましたけど、今日は『届いたあとに壊していないか』を見る感じですね。速く出せても、毎回お客さんをヒヤヒヤさせていたら困りますもんね。
タカシ
その通りです。change failure rate は、デプロイ後に即時の介入が必要になった変更の割合です。典型的には rollback や hotfix ですね。経営目線では、開発がどれだけ安全に学習を回せているかを見る安定性の指標だと考えると分かりやすいです。
ミカ
なるほど。荷物を早く送るだけじゃなくて、破損率も見ろという話ですね。しかも SaaS は一つの変更が全顧客に波及しうるから、失敗率の高さはそのまま信用リスクにもなりそうです。
Chapter 2 基本 ― 何を失敗と数えるかで数字の意味が変わる
タカシ
ここで大事なのが counting rule です。GitLab Docs では、本番 incident を引き起こした deployment の割合として change failure rate を計算しています。つまり分母は PR 数でも工数でもなく、本番 deployment なんですね。
ミカ
でも SaaS だと、コード rollback しなくても、feature flag を切って止血したり、急いで hotfix を入れたりしますよね。そこを失敗に入れないと、数字だけきれいで実態は危ない、みたいなことが起きませんか。
タカシ
まさにそこです。SaaS では rollback、緊急 hotfix、緊急 flag off、S1 や S2 incident、重大顧客影響をどう数えるかを先に決める必要があります。逆に軽微な表示崩れまで全部入れると、現場が数字を恐れて小さな変更すら出しづらくなります。
ミカ
つまり『何か不具合があったか』ではなく、『本番投入後に即時介入が必要だったか』を見るのが肝なんですね。経営としては、現場を萎縮させない線引きを決める仕事でもあるわけだ。
タカシ
加えて、GitLab は incident と deployment の関係が完全ではなく、duplicate incident が二重計上になりうるとも明記しています。つまり change failure rate は自然に出る真実の数字ではなく、定義と記録の整備で初めて経営判断に耐える数字になるんです。
Chapter 3 具体例 ― 失敗率を下げる組織は出荷を止めない
ミカ
具体例で聞きたいです。変更失敗率を意識すると、現場が慎重になりすぎて deployment frequency が落ちる印象もあるんですが、実際はどうなんでしょう。
タカシ
LaunchDarkly の Fortune 100 Health Insurer は面白い例です。月 60〜80 回だったリリースを 150〜200 回まで増やしつつ、change failure rate は 3.91% に抑え、承認から deployment までを 3〜5 分へ短縮しました。速さと安定性は両立できる、という実例ですね。
ミカ
しかも回数を増やして 3.91% なんですね。回数が増えるほど事故も増えそうなのに、むしろ controlled rollout や feature flag で被害を小さくしているのが効いているわけか。
タカシ
その通りです。この事例では年間 5〜10 回の rollback event を回避したとも出ています。ポイントは『失敗しない魔法』ではなく、失敗が起きても全員を巻き込まない仕組みです。SaaS では blast radius をどう制御するかが change failure rate の実力を左右します。
ミカ
数字の見方が変わりますね。失敗率そのものだけじゃなくて、失敗した時にどこまで顧客に広がったか、どれだけ素早く止血できたかまで一緒に見ないと、本当の安全性は分からないんだ。
Chapter 4 運用論点 ― rollbackだけが失敗ではない
タカシ
GitLab の handbook では、rollback は破壊的なので通常は S1 か S2 incident の時だけ検討するとしています。つまり rollback が発生していないから安全、ではなく、そもそも rollback は最終手段なんですね。だから SaaS では flag off や canary 停止も失敗として扱う設計が必要です。
ミカ
なるほど。むしろ『大事故になる前に flag を切って止めた』なら、rollback していなくても change failure として学ぶ価値があるわけですね。見逃すと、同じことをまた繰り返しそうです。
タカシ
さらに GitLab は feature flag を全環境で 2〜4 営業日ほど動かしてから removal を判断するよう求めています。段階 rollout を前提にしているからこそ、失敗率を抑えながら出荷回数を保てるわけです。大きく一気に出すより、小さく観察しながら進めるほうが安いんです。
ミカ
あと、incident 管理が PagerDuty、deploy が CI/CD、顧客影響が support に分かれている会社は多いですよね。それぞれがつながっていないと、どの変更が何を壊したのか、会議で毎回推理ゲームになりそうです。
タカシ
そこも重要です。GitLab Docs は external incident 連携を前提にしていて、PagerDuty webhook から incident を作る方法まで用意しています。変更失敗率を使う前に、deploy と incident と顧客影響を同じ時系列で追えるようにする。ここが計測の最低ラインですね。
Chapter 5 クロージング ― 変更失敗率を経営指標にする5つの条件
タカシ
今日の change failure rate のポイントは、『品質の点数』ではなく、『出荷の仕組みが健全かを見る指標』だということです。低ければ安心ではなく、分母や counting rule が正しいかまで含めて見ないと意味がありません。
ミカ
まずはサービス単位で失敗の定義を決める、分母を production deployment にそろえる、deployment frequency や lead time と並べて見る、そして feature flag や canary で blast radius を小さくする。この順番が実践の入口になりそうですね。
タカシ
今日は SaaS 開発の変更失敗率を扱いました。次回は、その失敗からどれだけ早く戻れるか、平均復旧時間を取り上げます。皆さんの組織では、最近の変更で『即時介入が必要だったもの』をちゃんと数えられているか、ぜひ一度見直してみてください。