← エピソード一覧に戻る Episode 169 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― テストが多いのに遅い会社は何を間違えているか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発のテスト自動化を扱います。Slack では一時、1 日に 100 万件の test suite を回していました。それでも安全と速さの両立に苦しんだ。ここに自動化の本質があるんです。
ミカ
ミカです。テストって多ければ多いほど安心だと思っていたんですが、100 万件も回してなお苦しいんですね。なんだか筋トレ器具を増やしたのに、部屋が狭くなって動けなくなるみたいで、数だけでは強くなれない感じがします。
タカシ
いい例えです。SaaS のテスト自動化は、QA の工数削減ではありません。変更失敗率を下げ、壊してもすぐ戻せる状態を作り、継続リリースを経営として成立させる仕組みです。人手確認だけでは、もう回らないんですね。
ミカ
前回の平均復旧時間ともつながりますね。壊さないための仕組みであり、壊した時に被害を小さくする前提でもある、と。テストって現場の話に見えて、売上や解約率、それにサポート負荷にまでちゃんと効いてくるんですね。
Chapter 2 原則 ― 良い自動化は速くて信頼できる
タカシ
DORA は、良い test automation の条件をかなり明快に示しています。開発者が主に作って保守すること、失敗を自分の環境で再現して直せること、そして flaky test を許容しないこと。この三つが揃って初めて、速い学習が起きます。
ミカ
なるほど。専任の誰かが遠くで守ってくれるものじゃなくて、変更した本人がすぐ直せるところまで含めて自動化なんですね。テストがあるだけで満点、ではなく、直しやすさまで問われるのがかなり厳しい世界なんですね。
タカシ
その通りです。Accelerate では、自動テストのフィードバックはローカルでも CI でも 10 分未満が望ましいと整理されています。40 分待って赤になれば、誰でもまとめて変更を入れたくなる。すると一件あたりの壊し方が大きくなるんです。
ミカ
テストが遅いと、慎重になるんじゃなくて、逆に大きくまとめて出したくなるんですね。レジが遅いから買い物を小分けにせず、カゴいっぱいにして一回で並ぶ感じに近いかもしれませんし、その分だけ会計ミスも増えそうです。
タカシ
加えて、全部を E2E で守ろうとしないことも重要です。認証、課金、権限、テナント分離のような論点は、単体、契約、統合、スモークへ分散して守る。E2E は顧客価値に直結する少数の導線だけに絞る。これが SaaS では現実的です。
Chapter 3 具体例 ― Slackが教えるE2E偏重の罠
ミカ
その E2E の絞り込みって、実際にはどう判断するんですか。現場だと『この導線も不安、あれも不安』で、結局なんでも merge blocker にしたくなりそうですし、外した瞬間に事故が起きそうで怖いです。
タカシ
Slack の Web アプリ事例が参考になります。多くの PR に 60 本超の E2E suite を pre-merge で課していたため、各 suite の flaky 率が 1% 以下でも、理論上 55% の PR が少なくとも 1 本の flaky failure に当たる計算になってしまいました。
ミカ
1 本 1 本は優等生でも、人数が増えると学級崩壊する感じですね。つまり『良さそうなテストを足す』を続けるだけだと、全体としてはだんだん信用できなくなるわけだし、しかも待ち時間まで増えてしまうんですね。
タカシ
そこで Slack は、高重要度だけを pre-merge に残し、残りを post-merge や定期 regression に移しました。大事なのは、全部を同じ門番にしないことです。壊した時の被害と検知の速さに応じて、関所を分けるんですね。
ミカ
なるほど。『全部通さないと危険』ではなく、『何をどこで落とすかを設計する』なんですね。これなら速度を捨てずに安全も守れそうですし、どこに自動化投資をするかも経営会議でかなり判断しやすそうです、本当に。
タカシ
Slack のモバイルでも、Calabash から Espresso と Firebase Test Lab へ移して、テスト時間を約 350 分から約 60 分へ短縮しました。さらに flaky 対策で、main branch の失敗のうち flaky 起因を 57% から 4% まで下げています。速さと信用は一緒に作れるんです。
Chapter 4 運用設計 ― feature flagとmerge queueまでが自動化
ミカ
でも SaaS って、本番に出してからしか分からないこともありますよね。feature flag を使えば安心、と言う人も多いですが、あれはテスト自動化の代わりになるんでしょうか。それとも別の安全装置として考えるべきなんですか。
タカシ
代わりではなく補助線ですね。LaunchDarkly も、専用の test environment を分けて API で flag 条件を固定する方法や、Relay Proxy の offline mode を紹介しています。flag は検証しやすい構造とセットで使わないと、複雑性だけが増えます。
ミカ
安全装置を増やしたつもりが、レバーが多すぎて誰も触れない飛行機みたいになるわけですね。flag も期限やテスト条件、誰が片付けるかまで決めないと、あとでかなり重い借金になるんだなあと改めて強く思いました。
タカシ
さらに組織が大きくなると、CI の中だけでは守れません。GitHub は merge queue で 3 万件超の PR と 450 万回の CI run を回し、平均の出荷待ち時間を 33% 短縮しました。Block では週に複数回あった post-merge build failure をほぼ解消できたとされています。
ミカ
つまり、テスト自動化ってテストコードの話だけじゃないんですね。どの順でマージし、どこで required check を走らせ、失敗したら誰が外れるかまで含めて、出荷システム全体を設計する話なんだと見えてきました。
Chapter 5 クロージング ― 明日から直すべきは本数ではなく信号の質
タカシ
実務ではまず、unit、integration や contract、E2E や smoke の三層で棚卸ししてください。その上で、テスト時間、flake 率、再実行率、Time to Merge を毎週見ます。多いか少ないかではなく、速くて信頼できるかで管理するんです。
ミカ
今日は『自動化は安心の量産ではなく、信号の設計』だと分かりました。課金や権限みたいな事故コストの高いところから先に自動化しつつ、flaky test と長すぎる CI を放置しない。そこが SaaS 経営の地味だけど強い差になるんですね。
タカシ
その通りです。テスト自動化は、速く出すことと壊さないことを二者択一にしないための基盤です。皆さんの組織でも、まずは『本当に merge を止めるべきテストは何か』から見直してみてください。それではまた次回。