SRE？インフラエンジニア？ ~初期スタートアップにおける一人目SREの取り組みと学び ~ by 髙石 諒

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

スピーカーは現在アーリーステージのB2Bスタートアップに所属し、一人目のSRE・インフラエンジニアとして2年半活動してきました。入社当初の組織は、十数名規模の開発チームで、スケールするインフラ構築やエラー通知の改善など、プロダクト開発を前に進めることが最優先のフェーズでした。

そんな環境でSREという肩書きを持つ自分に求められた役割は、GoogleのSRE本に書かれているような理想像とは異なります。現実には、クラウドインフラの構築や開発環境の整備、監視や通知の整備、セキュリティチェック、場合によっては脆弱性診断のハンドリングまでインフラに関わることはなんでもやる人として取り組むことが必要でした。

本セッションでは、この2年半で自分が取り組んできたことを具体的に紹介しながら、なぜそうしたのか、そこからどんな学びが得られたのかを整理してお話しします。また、アンチパターンとされがちな属人化をあえて戦略的に選んだ場面について、その背景とトレードオフを共有したいと思います。

■ 発表の詳細（1000字程度）

アーリーステージのスタートアップにSREやインフラの専門家として参画すると、役割はSRE業務だけにとどまりません。クラウドインフラやプラットフォーム、セキュリティなど幅広い領域に対応し、その時々の状況を見てバランスよく取り組む必”要があります。また、SRE本に書かれるようなプラクティスをそのまま導入すればうまくいくわけでもありません。限られたリソースとスピードが求められる環境では、理想と現実の折り合いをつけながら進めることが大切です。

取り組みの一例が「自分がやるか、チームにやってもらうか」です。本来SREの活動には開発チームに知識や文化を広げるEnablingが含まれます。しかし、少人数体制では得意な人がまとめてやる方が速いケースもあります。例えばちょっとしたECSサービス追加であれば他のメンバーが追加を試みてもそこまで時間はかかりませんが、新規サービス開発にともなうインフラのゼロイチ開発は自分で一気に実装する方が効率的でした。将来チームが大きくなればやり方を変える必要があると思いますが、今のフェーズでは「こだわらない属人化」をあえて選びました。

一方で、監視や通知の整備はSREらしい仕事として比重を置きました。既存の監視が機能していない部分を修正し、エラー通知を整理しました。SLOは運用しきれないと判断して設定せず、レイテンシーベースの通知やDatadogを用いたフロントエンドからDBまでの一貫したトレースを導入し、問題発生時の調査効率向上に力を注ぎました。SRE本に忠実にやるのではなく、現実的に使える範囲で手をいれました。

また、レバレッジが効く仕組みには初期から投資しました。入社当時、Terraformは導入されていたもののCI/CDがなく、各自がローカルでplan/applyを実行しており非常に危険な状況でした。そこでGitHubActions用いたCI/CDを最優先で導入しました。こうした仕組みはプロダクトが存在する限り使い続けるため、早期に整備するほど価値が大きいといえます。

さらに、リリースサイクル高速化に繋がる開発環境も整備しました。productionとstaging環境しかない状況では検証や修正後の確認がやりづらく、誤ってstaging環境を壊す危険もあります。そこで専用のdev環境やPullRequest毎の環境を用意し、安心して検証・確認できる仕組みを実現しました。

これらの経験から得た学びは、SREの方法論をそのまま適用しようとするのではなく、状況に応じて属人化をいとわないこと、レバレッジが効く仕組みを大事にすることです。本セッションでは、アーリーステージにおけるSREの理想のリアルな実践と判断基準を共有します。

■ 対象聴衆とその人たちが得られるもの

対象聴衆は似たような環境にあるSREです。理想と現実のバランスの取り方について、参考にしてもらえるとうれしいです。

■ なぜこのトピックについて話したいのか（モチベーション）

スタートアップで一人目のSRE・インフラ専任として働く経験は初めてであり、SREに関する取り組み方もプラクティスをそのまま使えないことを身をもって体験した。その体験を伝えることで、少しでも他の開発チーム・SREの参考になるとうれしいです。