僕は去年の8月にヌーラボに入社して、そこから Backlog の SRE として働いています。
SRE としての経験は約1年なのですが、ちょうどサービスが成長し、会社もエンジニアを積極的に採用して拡大している時期だったこともあり、色々な経験ができました。そのなかで、SRE の難しさ、SRE の組織の問題にも直面してきました。
このあたりの経緯を整理して話すだけでも SRE にとって面白い話になるのではないか、と思い、今回の SRE Lounge #5 では「Backlog における SRE の事例 〜プロダクトの成長のために SRE はなにをすべきか〜」というタイトルで発表させていただきました。
発表スライドはこちらです。
発表のときは冒頭で説明したのですが、これがベストプラクティスと言うつもりは全然ありません。僕らもまだ悩んでいる最中の問題を、その背景も含めて（話せる範囲で）丁寧にまとめて説明することで、他社の SRE の方々からご意見をいただきたい……という趣旨の発表でした。
その後の質疑応答や、Twitter での反響を見た限り、とても好評だったようでホッとしています。「SREの業務範囲は放っておくと再現なく広がっていく」、「SRE を組織の中でどう配置すべきかはすごく難しい」といった問題意識は多くの方に同意してもらえたようです。
詳しくはスライドの方を見てもらうとして、以下に当日の質疑応答や、懇親会で話したこと、今回のプレゼンの関連資料などをまとめておきます。
質疑応答
覚えている範囲でまとめておきます。発表直後でかなりテンパっていたので、質問者の質問や、僕の回答の表現は、実際に話されたものとは多少ズレているかもしれません。
- Q) 開発チームはスクラムなどに従って開発していると思うが、SRE の仕事はその開発スパンには合わないのではないか。そこはどうしているか
- A) 開発者と SRE で同じカンバンは共有しているが、SRE は独立して動いている。障害対応があるときはそれを優先し、それ以外のときは改善のタスクを取るとか
- Q) SRE が開発チームに入ることで良くなる面があったのはわかった。逆に、SRE が入ることで悪くなった面はあるか？
- A) 開発者の側としては割り込みが増えたと感じているかもしれない。エスカレーションが早くなる分、「調べたけど問題なかった」というハズレも増える
- Q) チームは拠点ごとに分かれているか？ このチームは福岡に全員いる、など
- A) ヌーラボはリモートでのコラボレーションを促進するサービスを提供していることもあり、複数拠点に分かれたチームはたくさんある。自分もそう。ただ、1拠点にまとまったチームもある
- Q) Backlog の開発者の規模はどれくらいで、そのうち SRE は何名いるか
- A) 開発者は30名前後と考えてもらえれば。SRE は講演でも話したとおり、現時点では4名
- Q) SRE を採用するときに重視している点はあるか
- A) 個人的には、技術力が高いこと、自分から問題を定義して仕事を作れること、チームをまたいで仕事をする必要があるのでそういうコミュニケーションを嫌がらないこと、の3点を重視している
懇親会で話したこと、質問を受けたこと
お話できたのは一部の方だけでしたが、SRE やインフラエンジニアが多い印象を受けました。ターゲットに沿った人がうまく集まっていて、SRE Lounge は SRE にとって良い議論・発表の場だと思いました。
オプトの渋谷さんの発表に対する質疑応答でも出ていた質問ですが、SRE は何人いたらいいのか？ 開発者に対する割合としてどれくらい必要なのか？ という質問は何度か受けました。北野さんがツイートしてましたけど、答えはまさにこれ（↓）ですね。何人必要かは、自分たちもまだ模索中です。
SRE 何人いたらいいの問題…w
— かつひささん (@katsuhisa__) 2018年9月26日
職責をどう定義するかでも全然異なってきそう。
#srelounge
あとは、これから新しく SRE チームを作るとしたら何に注意すべきか、という相談も受けました。SRE という用語を生み出した Google 自身もそうですが、自社でサービスを開発・運用している組織でないと、SRE に適切なインセンティブをもたせることは難しいのではないか……というくらいしかわからないですね。僕も答えは持ってませんが、SRE チームをうまく構築するスキルをもったコンサルのニーズは高そうだなあと思いました。スクラムマスターとか技術顧問みたいな感じで。
関連資料
スライドの中で触れた、Backlog SRE による過去の発表資料、ブログ記事はこちらです。
この発表内容がまとまるまでの経緯
スタディスト（ヌーラボ東京事務所の1つ上のフロア）の北野さんから講演のお誘いを受けて、SRE について考え直すいい機会かな、と思ってとりあえずOKしたところから始まりました。
そこから、まずは入社時に聞いた SRE チームの歴史のメモからたたき台を作り、週一の SRE チーム定例で毎回レビューをお願いして、発表内容をブラッシュアップしていきました。そのおかげで発表内容がよくなっただけでなく、SRE チーム内で過去の経緯を共有したり、今後のあるべき姿を考えるいい機会にもなりました。
他の会社の SRE チームでも、同じように過去の経緯をまとめてみる（そして SRE Lounge で発表する）のはいいんじゃないかなーと思います。オススメです。
最後に、SRE Lounge 運営の皆さん、今回の会場をご提供くださったウォンテッドリー株式会社の皆さんに感謝します。僕も今後できるだけ SRE Lounge をお手伝いしたいと思います。また会場でお会いしましょう。
あわせて読みたい（2018-12-13追記）
この講演のときに時間不足で省いたサービスレベル管理の話を、ヌーラボブログに大ボリュームでまとめました。よかったらこちらもどうぞ。
