MIXI・ZOZO・CAMPFIRE　SRE合同採用イベント〈３社でSREを再考してみる〉イベントレポート

2023年2月9日、MIXI・ZOZO・CAMPFIREの３社でSRE（Site Reliability Engineering）にまつわるイベントを実施しました。

当日は「SREを再考してみる」をテーマにそれぞれの取り組みを紹介しながら、SREというキャリアの実践について掘り下げる時間となりました。

この記事では、当日のスライドと、後半に行われた座談会の様子を抜粋してご紹介します。

プロフィール

当日は自己紹介と自社でのSREの位置づけ、取り組みについての紹介からスタート。当日のスライドは以下に公開されています。

MIXI
吉野純平　開発本部本部長
2008年4月に新卒エンジニア職でミクシィに入社。数年間ネットワークを担当し、その後はアプリケーションの運用にシフト。物理インフラ、サーバ運用、ネットワークから、映像処理や撮影などIP通信に関連する開発を手掛ける。2019年5月にはインフラ室の室長を担当。2022年4月開発本部本部長就任。

ZOZO
瀬尾直利　技術本部本部長兼 VPoE
2019年1月 ZOZOテクノロジーズ入社（前職：DeNA）
2019年4月 MLOps立ち上げ
2020年4月 ZOZOTOWNリプレイス戦略、PF-SRE立ち上げ
2021年4月 EC基盤本部本部長兼 CTO委員会委員会長
2022年4月技術本部本部長兼 VPoE
Medium：@sonots

CAMPFIRE
岩崎雄三　VPoE 兼プロダクト開発部部長
2016年にCAMPFIRE入社後、負荷対策やデプロイ改善、SREチームの立ち上げなどに関わる。元リードSRE / SREチームマネージャー。
Twitter：@yuzoiwasaki

当日の発表の様子

ここでは、当日の吉野の発表の一部と、瀬尾さん、岩崎さんの発表をダイジェストで紹介します。

まずはMIXIの開発本部本部長である吉野の発表から。

開発本部は横串の組織であり、SREグループはその中で様々な事業を横断しながら業務を行っていると紹介し、技術領域まで紹介。その後の話の中でも印象的だったのは「キャリアパス」について。

特定のキャリアパスがあるのではなく、あくまでも本人の指向性を前提に様々なキャリアパスが考えられると前置きした上で、「一人目のエンジニアになってほしい」と続けました。検証したいサービスがある場合、まずこの人にお願いしてみようと思われるエンジニアになること、専門外のことにも積極的に発言できたり、非エンジニアと業務を進める際にエンジニアリングに比重を置きすぎないコミュニケーションが取れたりと、自らの得意とするスキルを特化させることで、キャリアの道にも繋がる、と語っています。

その後、ZOZO瀬尾氏からの発表。

『ZOZOTOWN』『WEAR』などのサービスを展開する同社のSREの役割は「非機能要件の守護者」を定義にしていると説明。「環境分離、サービス分離の原則」「Multi-AZ（3AZ）の原則」といったルールを設け、スケーラビリティの構造、負荷試験、独自に定めたセキュリティ要件などを紹介しました。

続いて、CAMPFIRE岩崎氏からの発表。

『CAMPFIRE』のSRE組織は3名でどのような業務を行っているかを紹介。サービスの信頼性を担保するために、小さい組織でどのような実践を行ったかという話の中で「チームワークのよさ、チーム間の垣根の低さ」などをメリットとしてあげながら、課題として「属人化しやすい、兼任が多い」などのデメリットを紹介。それぞれへの対策、実践をどのように行っているかを説明しました。

視聴者からの質問パート

それぞれのセッションを終えたところで、視聴者からの質問パートへ。登壇者が互いに質問を重ねながら話に花を咲かせた内容と合わせて一部抜粋してご紹介します。

Q.SREとして「面白い」と感じる課題はどのようなものがありますか？

瀬尾（ZOZO）

一番大変なものが一番面白いですね。今は注文周りの負荷対策に注力していて。転売目当てのユーザーから、商品が売り切れになっていてもbotでアクセスされ続けるようなこともあるので、負荷に耐えられるようなアーキテクチャに変えて対策していますね。本当にやめてほしいですけど（笑）。

岩崎（CAMPFIRE）

私も同じく負荷対策が最も大きな課題ですね。サービスの性質上、プロジェクトが公開されて一気にリクエストが来る設計になっているので、そこをいかに対策できるか、というところですね。

吉野（MIXI）

『みてね』は海外に展開しているサービスなので、海外からのアクセスのレスポンスタイムの改善活動が楽しい部分はありますね。世界を相手にやることはなかなかないことなので、貴重な機会なのかなと。

Q.属人化を減らすためにどのような取り組みをしていますか？

吉野（MIXI）

ある一定仕方ない部分はあると思いますが、減らすためには適切なレビューを増やしていくことが大切かなと思います。いいレビュワーがいて、適切なレビューがあることでデプロイできるのがいい組織なのかなと思います。そのために、リードエンジニアには事業部内の方にもレビューをお願いするよう伝えていて、このような動きを周囲に浸透させてもらえるように動いてもらっています。

瀬尾（ZOZO）

レガシーシステムに関しては運用が属人化している課題もあって、今進めているリプレイスの中で Infrastructure as Code化するようにしています。そうするとコードレビューもできるようになるので、ナレッジのシェアもしやすくなります。

また、担当を主担当・副担当に分けるような人的な冗長設計もしておくことで、より属人化しにくくなるような体制を築くことは意識しています。

岩崎（CAMPFIRE）

お二人が仰ることはそのとおりですね。あとは、特定ドメインの実装やオンコール対応時の役割をローテーションすることでリスクヘッジできる部分はあるのかなと思います。

Q.時に運用チームの看板をSREに変えただけの組織もあるように感じますが、どのように感じられますか？

瀬尾（ZOZO）

そんなに目くじら立てなくても…（笑）。ZOZOもSREの走り出しはインフラチームだったのですが、ZOZOではSREを「非機能要件の守護者」と掲げていて、「SRE」という名前を持ち込んだことで、メンバーのキャリアのゴール意識も変わりましたし、その意識変革の影響は小さくないと思います。

岩崎（CAMPFIRE）

看板を変えることで自分たちの仕事を見つめ直す効果はありますよね。

吉野（MIXI）

組織名は、ビジョンであったり組織の目指す姿を冠したものであったりするので、そこと実態が違うことはよくないことですよね。名前をつける以上はプラクティスを実践していく必要もあるし、あくまでも看板の通りの仕事を行う組織でありたいなとは思います。

Q.レガシーなインフラの運用のモチベーションはどう保っていますか？（MIXI吉野）

瀬尾（ZOZO）

そこはとても意識する部分でもありますね。基本的には「リプレイスは自分たちでやる」ということにしていますね。他のチームがリプレイスする構造になってしまうと、どうしてもモチベーション低下に繋がってしまうので、自分たちでリプレイスをしながら、ボリュームを減らせばその分別のチャレンジに還元できるように意識していますね。

岩崎（CAMPFIRE）

特定の人への負荷が集中してしまうと、その人は自身がやりたいことが出来なくなってしまいますよね。

瀬尾（ZOZO）

SREは作ったものを運用するので、それで30%リソースが取られて、そこへ新しいプロダクトを構築するとさらに30%リソースが減って、この時点ですでにもう40％しか余地がない。そこへさらにまた新しいプロダクトを構築すると、もう90%が運用になってしまい、新しいチャレンジができない。なので、この運用工数をいかに減らしていけるか、というのが重要になると思います。

吉野（MIXI）

そうですね。メンバーの望むやりたい仕事がある中で、あまり緊急度の高くない作業をノルマとして課すのはマネジメント側としても難しい問題ではありますよね。それはマネジメントとして丁寧に提案しなければいけない部分でもありますが、まだまだ私も模索している最中です。

岩崎（CAMPFIRE）

やりたいこと、やらなければいけないことのバランスを取るのは難しいですよね。私はなるべく仕事の半分はやったことがないことをやってもらったり、何かしらのソフトウェアエンジニアリングを使ってコードの一部を自動化してもらったり、と次のチャレンジに繋がるように意識しています。

トークセッション

それぞれのSRE組織を掘り下げたところで、トークセッションへ。まずは「SREのキャリアパス」から探り始めました。

SREのキャリアパスは？

瀬尾（ZOZO）

最近だとアプリケーションを作っていた方がSREになられる方も増えましたよね。SREの先のキャリアとしては、サービスのアーキテクト設計をやったり、その次は会社全体のアーキテクト設計を担当したりが現実的でしょうか。私も実際にそうで、今VPoEを務めているので、その可能性はあるのかなと。

吉野（MIXI）

キャリアップの観点でいくと、IC（Individual Contributor / 個人貢献者）になるか、マネジメントロールになるかという感じでしょうか。MIXIの場合は事業部のSREをやるか、横断組織のSREをやるかといった選択肢もある割と自由な会社なので、逆に決まったキャリアパスはないのかもしれません。

岩崎（CAMPFIRE）

ICかマネジメントかの選択は弊社もそうですね。SREをやっていると組織横断的な動きを求められることも多いので、マネジメントとも親和性が高いのかなと思います。DevOps的な視点もありますし。組織設計も含めるとマネジメントそのものもエンジニアリングとそう遠くないように思います。

どんなSREが活躍できる？

吉野（MIXI）

これはエンジニアに限りませんが、「自分だけの得意分野がある」人は活躍しやすいのかなと思いますね。あと、どこに問題を設定して、どう解釈しているかといった説明が上手いとスキル高いなとは感じますね。解くべき問題の設定は、色々なものを見てきているかが表に出る部分ではあるのかもしれません。

岩崎（CAMPFIRE）

そうですね。私が思うのは、「越境できる」人でしょうか。開発チームの中でもそうですし、コミュニケーションを色々な人ととりながら一緒に取り組んでいけるスキルがあると成長しやすいような印象があります。

瀬尾（ZOZO）

とにかくボールを拾いにいくような人は成長する傾向がありますよね。なぜこれがアラートになっていて、これをどうすれば解決できるんだっけ？と考えて着地までさせられる人はどんどん成長していくイメージですね。

あとは、吉野さんと同じく、問題の設定が適切なのは大事です。SREなので裏側の仕組みばかり意識してしまいますが、その先のユーザーがどう思うかや導線がどうなってるかを意識しながら問題を設定できる人は活躍しているイメージがあります。

これからのSREに求められるスキルは？

瀬尾（ZOZO）

SREはとにかく「非機能要件の守護者」なので、課題があればどんどん解決していける力は普遍的に求められると思います。そのためには幅広い技術力も必要なので。

岩崎（CAMPFIRE）

DevOpsの文脈でお話しすると、『チームトポロジー』にもあるように、ストリームなどチーム一連の流れを見て動ける人は特に重宝されていくのかなと思います。あとおすすめの本でいえば、SREの文脈ですと『SREエンタープライズロードマップ』や『オブザーバビリティ・エンジニアリング』とかは読んでおくといいのかなと思います。

瀬尾（ZOZO）

実は私が『オブザーバビリティエンジニアリング』のレビューをさせていただいて（笑）。いい本なので参考にされるといいと思います。

吉野（MIXI）

思わぬつながりがありましたね。最後にひっくり返すようですが、SREという枠にとらわれずに事業やサービスの改善に取り組めるようになると、エンジニアとしてもっと強くなれるなとは思いますね。もちろんそれはSREとしての経験を充分に積んだ上での課題にはなると思いますが。『プロフェッショナルの条件』をよく見返しますが、思わぬかたちで気づきを得られるのでおすすめです（笑）。