スタートアップにおけるSREを考えてみる
SRE Magazine 第11号の巻頭言は「スタートアップにおけるSREを考えてみる」ということで、スタートアップ企業においてSREをどのように扱えばよいのか？ということを考えていきたいと思います。
きっかけ
きっかけとしては以下のRedditのスレッドでした。
The reality of SRE in early-stage startups & The biggest time-sinks in 2025. What’s your experience?
物凄くざっくり概要を説明すると、「初期段階のスタートアップ（シリーズA以下）で専任SREを雇用していますか？その中での大きな悩みはなんですか？」といった質問でした。
つい最近作成されたスレッドなのですが、コメントを読んでると「なるほどなぁ」と思わされるものもあります。
例えば以下のようなコメントです。
私は複数のスタートアップでSREとして働いてきましたが、どこも同じような状況です。
・可観測性がまったくない。もちろん観測ツールのプロバイダは使っていて、クラウド予算の5〜10％を占めているのに、何の役にも立っていません。
・多くの人はKubernetesを本当に理解していませんし、それが何をしているのかもよくわかっていません。
・開発者やCTO、セキュリティ担当者が厳しい環境の中でなんとかプラットフォームを作ろうとしたものの、完全に崩壊寸前。スケーラブルでなく、専門家がいれば簡単に解決できたような問題であふれています。
・あなたは多くの時間を「正しく」物事を行うことに費やし、その理由を「なぜ急がずにやるのか」を人に説明することにも時間を使うでしょう。
実際のところ、スタートアップにSREは必要ありません。
スタートアップにSREは必要ない、とバッサリ断言していますね。
かくいう私も 初期のスタートアップ段階では"専任"のSREポジションは要らないのでは？ と思っているクチです。
私自身、総勢３人の超初期のスタートアップ企業にいたり、40人ほどのある程度の規模の資金調達にも成功したスタートアップ企業にもいたりしましたが、その経験を持って言うとするならば 「自然発生的にSREプラクティスが生まれるので、その時に小さな成功体験を積み重ねていく」 というのがベターだと思っています。要するに “実情として組織が必要としていないならやるな” です。
この辺りのスタートアップ企業におけるSREのバランス感覚の話はSREConでも語られています。
SREcon23 Americas - SRE in Transition: From Startup to Established Business
元Google, 現Datadogのスタッフエンジニア・Laura devizine氏による2023年のSREConのセッションです。
この中ではスタートアップからハイパーグロースを果たすまでのSREの役割について言及しています。
まず、“スタートアップ"とは何かの定義ですが、先程のRedditでは資金調達ラウンドがシリーズA以下を初期段階のスタートアップと述べていましたが、こちらでは dead by default と定義していて、後ほど紹介するセッションでも説明しますが 「PMFの未達や、コスト超過などにより簡単に会社が消滅する状態」 であることを示しています。
そういった「死が隣りにある」状態にあるスタートアップではいかにプロダクトや機能を素早くリリースするか？に全神経を集中させねばなりません。そんな中で、悠長にSLOを定義しましょう、とか精緻なダッシュボードを作りましょう、とか言ってられません。そんなことやってる間に潰れます。
要はスピード感をスポイルするようなSREプラクティスをやっている場合ではないのです。
技術的負債と言いますが、その中に含まれるSRE的負債を抱えながらグロースしていかなければなりません。
また、本セッションではインシデントレビューも省略すべき、とありますが、それには自分としてはNOな立場です。セッション内で「スタートアップの段階では一人の顧客を怒らせる余裕がない」という言説が出てくるのですが、それに反するだろうとは個人的に思うのです。（インシデントレビューが起因で防げる障害を防げなくなる）
無事、ハイパーグロースへ移行し default to live 状態になれば、ここから負債を返していきましょうという話になるのですが、そこからは今回のお話の軸からはズレてくるので、ぜひ動画を見てみてください。
個人的には「視座ごとの信頼性の確立」について述べているところが好みでした。
さて、このセッションの話を省みるに、スタートアップにとって死活問題なスピード感を失わせるようなSREプラクティスの発揮はよろしくない、という結論でした。ともなると、専任SREというのが必要あるか？と問われるとNOと言われそうですね。それよりもプロダクト開発に携わりながらトイルの予防（撲滅より前のフェイズなので）を進めていくのが良さそう、という感想です。
SREcon22 Europe/Middle East/Africa - Unified Theory of SRE
先程のセッションの中で登壇者が「明確に参考にしたセッションがある」ということを仰られており、それが2022年のSREConでの「Unified Theory of SRE」というこちらのセッションです。
このセッションは、「97 Things Every SRE Should Know」の共著者の一人であるEmil Stolarsky氏によるセッションで、スタートアップの状況に合わせたSREの再定義を試みるという内容になっています。 （どうでもいい話ですがこの「SREが知るべき97のこと」の翻訳書出ないかなと待ち続けています…）
このセッション内では、まず「私たちがよく知るSREに対して信頼を失った」という不穏な入りから始まります。
法律によってオンコールが阻まれた、というところからなのですが、原典であるSRE本をまずは疑うことを通して、「なぜSRE本をそのまま模倣するのは駄目なのか？」「SRE本はほとんどの企業にとっては無用の長物であって、既に腐敗した内容ではないのか？」 というなかなか苛烈な触れ方をしています。
次に目線をスタートアップに向けて、SREをスタートアップにアジャストして考えてみる、という試みを行います。
ここで前述したセッションの中でも語られていた「Default Dead / Default Alive」が登場します。Default Aliveについては、ハイパーグロースした後のような"プロダクト開発が停止しても会社が存続する状態” ですね。究極的にはプロダクトの一つが死んでも存続する状態です。
このような会社状態の変化は機能開発の速度が優先的に行われるべきか？に関わってきます。要するに、SREの役割が機能開発の速度を高めるためのプラクティスに傾倒するか否かの違いが出てくるわけです。
ここでは痛烈な言葉として 「会社が6ヶ月後に存在しないなら、信頼性は重要ではありません」 ということも述べられていました。
ただ、将来への備えを全くやらないというのも考えにくく、“過剰なエンジニアリング"にならない範囲で「ユーザーがいないうちにやっておくと楽なインフラストラクチャ作業」に最小限の投資をしておくのもDefault Deadな状況のSREの役割です。
この中で一番刺さる話が 「SREは常に技術の最先端で運用しようとしますが、ほとんどの企業にはその必要はありません。Metaのような大規模な問題を抱えていないのに、大規模な問題を抱えているふりをするのはやめるべきです」
これは本当にご尤もだと思っていて、私の好きなSRE記事である
Niall Murphy氏の"SRE in the Real World"には「Googleでは、成功への確信は、Googleが抱える複雑で大規模な問題を解決するためにGoogle製のソフトウェアを使うことと強く結びついています。一方で、他の場所では「どのように解決するか」は重視されず、 「解決されること」だけが重要 とされています。」と書かれており、つまりは “解決されること"が重要視される指標であり、そのための技術に"最先端"は必ずしも必要はない のです。
また、SLOの導入についてはベロシティが高い場合、設定したSLOはすぐに陳腐化する可能性があると指摘し、「顧客にとって何が重要かという原則を定めるべき」 と言及しています。
たしかに信頼性を測る尺度としてのSLOは非常に大事な概念ですが、そもそもSLOが定義している顧客価値の部分を組織として重要視するだけでもいいのではないか？ というお話ですね。
その他、インシデントレスポンスやオンコールについてもお話されていますが、こちらもぜひ動画で確認してみてください。
まとめ
ということで、スタートアップにとってのSREを考えてみたわけですがいかがだったでしょうか？
今回取り上げた２つのセッションは概ね私の考えとも合うものだったので紹介させていただきました。実際に生きるか死ぬか？の瀬戸際のようなスタートアップ企業に勤めたことのある人にとっては納得感があったかなと思います。
間違ってはいけないのはスタートアップにとってのSRE不要論を唱えたわけではありません。SREはあくまでもプラクティスなので、必要なタイミングで必要なプラクティスを振るえばいいのです。
ただ、専任SREやSREチームを組閣するといったことは"Default Alive"な時にやるのが良いタイミングかな？というのが今の結論ではあります。
あくまでもこれは一つの例で、SREの形は会社の形が多種多様あるように千差万別です。四苦八苦しながらもあなただけのSREを見つけていきましょう！