タイトルだけ中途半端にふざけました、ZOZOの@sasamukuです。
この記事は ZOZO Advent Calendar 2022 カレンダー Vol.4 の 6 日目の記事です。
開発未経験のSREがバックエンドエンジニアに転籍した話を書いていきます。
転職エントリならぬ"転籍"エントリです。
以下は組織の戦略を示すものではありません。
個人としてのキャリアを考えつつ組織の中でどう立ち回るのかをまとめたものです。
ざっくり概要
- SREからバックエンドに転籍しました
- キャリアにも組織にも良い選択だった
- 今後SREに頼らないチームを目指していく
SREから転籍した理由
理由は大きく2つあります。
- 技術領域をスケールしたい
- 組織の境界線を曖昧にしたい
技術領域をスケールしたい
僕はWEARのSREとして、2021年4月にZOZOに中途入社しました。その前は某通信会社でインフラエンジニアとしてオンプレやAWSを触ったり、稟議書を書いたり、稟議書を書いたりしていました。（某通信会社2年、ZOZO1.5年）
SREと一口で言っても、会社や組織によって役割に幅があります。アプリケーションにガンガン踏み込んでいく場合もあれば、インフラ運用を主な任務としアプリケーションはバックエンド（BE）チームに任せる場合もあります。
WEARのSREはどちらかと言えば「インフラ寄りのSRE」です。BEチームとコミュニケーションを取りつつアプリケーションの改善は基本的にBEチームに任せるスタイルです。アプリケーションのコードを書く機会はほとんどありません。
とりわけ自分はBEの開発経験がなかったのでインフラエンジニアに毛が生えたSREでした（今もそうですが）。コードもなんとなくしか追えませんし、パフォーマンス悪化の原因を深堀るのは至難の業です。
そのためこのままの環境でSREを続けていっても、扱える技術領域もキャリアもスケールしにくいと考えました。
組織の境界線を曖昧にしたい
チーム内には開発経験を持つSREもいますし、アプリケーションの領域に全く取り組んでないわけではありません。ただBEとSREの間に見えない境界線があり、無意識あるいは意識的に責務分掌がなされていました。
それもあってか互いの技術領域に関してそれほど踏み込まず、依頼ベースでのやり取りを行うシーンも多かったです。例えば、S3バケットを作成するだけであってもBEからSREへ依頼が行われていました。逆に、実装を追えば分かるものでもSREからBEにヒアリングすることもあります。これらはスキルの問題も一部ありますが「そういうものだから」という潜在意識がそうさせているのだと思います。自己完結できる人もいますが自身の周りの傾向としてそうなっていました。
このような専業化はコミュニケーションコストを増やしたり、認識齟齬による手戻りや品質の劣化をもたらします。結果的に開発速度は低下し、サービスに良くない影響を生じます。
こうした課題感からSREとBEとの間にある境界線を曖昧にし、互いの技術領域の重なる面積をもっと広げたいと考えました。ちょうど下のベン図のように。
よしBEチームへ転籍だ
「自分が取るべき最良の選択は何だろう？」と考えた結果がBEチームへの転籍でした。ZOZOに転職したときもいずれは開発を経験したいとぼんやり思っていましたが、このような摩擦を肌で体験することで、自身と組織の課題のどちらにもアプローチできる転籍を強く希望しました。そして自身を信頼してくれた上司陣によって転籍が実現されました。
Embedded SREという立ち回り
なぜ転籍が自身の成長だけでなく組織の課題にもアプローチできると考えたのかというと、それは「Embedded SRE」という考え方を知っていたからです。Embedded SREはプロダクトチーム（開発チームと読み替えてよい）にSREを埋め込み、チームの一員としてSRE活動を推進する組織形態を指します。
ちなみに僕がEmbedded SREを初めて知ったのはメルカリの0gmさんの発表を聞いたときでした。
プロジェクト横断で編成されることの多いSREチームを開発チームに埋め込むことで、考え方としてのSREを浸透させチーム一丸となって信頼性の向上に取り組むことができます。そして一定の成果が得られたら開発チームを離れ、また別のチームに埋め込まれます。
僕はZOZOに転職してからSREに注力してきました。信頼性向上はもとより、開発体験向上、コスト、セキュリティといった事柄を考える時間が多かったです。そしてAWSやK8sといったインフラ領域も得意です。BEチームに自身をEmbeddedすることで、チームの内側からこうしたノウハウや知見を浸透させることができると考えました。
転籍してみてどうか
「えらそうなこと言ってるけど実際バリュー出せてるのか？」
耳が痛いです。まだ転籍して数ヶ月なのとSREの頃の宿題が残っており全然出せていません。
ただ早くもよかったことがいくつかあります。
まず、SREの頃は拾えなかった声が拾えるのがよかったです。
SREの責務に開発者体験の向上があります。SREの頃はバックエンドチームが実際に何に困っているのか把握できていませんでした。そこで「開発体験向上アンケート」と題して課題を抽出するための取り組みを行っていました。これはこれで良かったのですが、実施できても数ヶ月に1回です。アンケートを集計する手間も掛かります。ならば発生ベースでチケットを起票するなどの方法も考えられます。しかしチケットを起票するほどでもない、困ってるけど致命的ではないといった理由から不満の声は届くことなく消えてしまいます。
自分が転籍したことでチーム内部から生まれるこうした声を以前よりも拾えるようになりました。そしてそれらをSREに依頼するのではなく、モブプロをしながらコーチングする取り組みもしています。課題の大きさにも依りますが、簡単なものはBEチームでチャッチャと片付けてしまうのがよいという考えのもとです。
アプリケーションとインフラは地続きであるため、何か変更を加えようとするときどちらか片方だけ考慮していてはNGなケースがあります。そうしたシチュエーションにおいて自身の経験が生かされると感じています。
バックエンド未経験でもついていけるか
気になるのは開発未経験でもやれるのか、という点です。
僕のレベルはというと、現場で使える Ruby on Rails 5速習実践ガイドを一通りやったのと、簡単なAPIを趣味で作ったくらいのヒヨコレベルでした。とはいえ基本的なノウハウは身につけられていたので割とスムーズにキャッチアップできている感覚があります。
技術的な知識不足も課題ですが、実装がなぜそうなっているのか背景を理解する方がより大変だなと感じています。その辺りはDiscordでチームメンバに聞いて解消したり、ドキュメントを読み漁って当たりをつけたりしています。
SREに頼らないチーム作り
当面はSREに頼らないチーム作りに貢献したいと考えています。
SREとコミュニケーションするな、というわけではありません。SREには開発スピードを上げるための本質的な改善に時間を割いてもらいたいのです。直近では負荷試験環境の整備、オンプレからの脱却、K8s移行など様々なミッションが山積しています。それらに集中してもらう方がBEチームの生産性が向上していくはずです。
今後のキャリア
パワーアップしてSREに戻りたい。
おわりに
今回は個人としてのキャリアと組織での立ち回りの話でしたが、WEARのSREではSLO運用やK8s移行といった活動を進めており、組織として信頼性にコミットしていくムーブをかましています。もしご興味のある方がいればTwitterのDMからでも結構ですのでお声がけいただければと思います。
明日は@pae_26さんの記事です。お楽しみに。