No.1ファッションレンタル企業にジョインして2年、SREに転身した話。
株式会社エアークローゼット (以降: エアクロ)でSREをしているCutです。Cutは社内ニックネームです。
この記事では、エアクロにSREが誕生してからの1年間を振り返りながら、エアクロの企業文化に触れていきたいと思います。
この記事はエアークローゼット Advent Calendar 2023 9日目の記事です。
個性豊かなメンバーが記事を投稿していますので、ぜひご覧ください。
長旅の始まり
エアクロは、ファッションレンタルサービス「airCloset」や、家電レンタルサブスク「エアクロモール」を展開しています。その中で、開発チームは全員がフルスタックエンジニアとして日々の開発業務に携わりつつ、2~3名ずつ交代しながらオペレーションを担当しています。
そんなチームの開発品質は、2022年の終わり頃から悪化の一途を辿っていました。機能改修による障害が頻発するようになり、お問い合わせの数が増加。お客様にご迷惑をおかけすると共に社内のオペレーションも逼迫し、チームの開発品質に対する信頼は大きく揺らいでしまいます。
また、オペレーションに関しても障害発生からどの程度の期間でクローズしているのかわからない、毎日固定で発生するタスクが多い、障害対応が適切だったのか振り返りが出来ていないなど、非常に多くの課題を抱えていました。
「まずは (障害が) 起きてからすぐに対応できるようにしよう。」
2023年3月、障害対応速度の改善に向けて、CTOの一声のもとチームにSREポジションが誕生し、私はその1人になったのでした。そして、これが今でも続く長旅の始まりでした。
Site Reliability Engineering
私がSREという単語を初めて聞いたのは、おそらくエアクロにSREが誕生する3ヶ月ほど前、2022年後半の話だったと記憶しています。
アプリケーションエンジニアだった私は、倉庫システムやお洋服の選定システムを中心に幾つかの大型開発案件を経て、エアクロの社内基準で「ミドルクラスエンジニア」と呼ばれる位置に近づいていました (これは偏に、侍CTOはじめ、バックエンドの神や、エアクロの皆さんのおかげです)。
同時に、自身のキャリアとしてこのまま技術を極めていくイメージが出来ず、かといってPMのような業務イメージも出来ない、そんな宙ぶらりんの状態でデスクに向かう日々でした。
そんな折、社内で誰よりも早く、障害の増加とオペレーションの逼迫に危機感を抱いていた先輩エンジニアから、SREという単語を初めて聞きます。チーム課題についてディスカッションする中で、輪読会という形で一緒に勉強することになりました。
そこには、エアクロに欲しいものの全てが詰まっていました。
オペレーションの効率化、障害の早期検知、トイルの撲滅、ポストモーテム…そして「推測するな、計測せよ。」という言葉。これまであまりに抽象的すぎてもはや空想だった考えが形を成していくようなイメージが湧くと同時に、実現したらきっと組織は今より強く大きく成長できると感じました。
こうした背景もあり、チーム内にSREポジションを設立することを進言しました。
そのわずか数日後、SREポジションが設立されました。ポジション設立の進言もなかなか珍しいことですが、進言からポジションの設立までわずか数日というスピード感もエアクロの特徴です。
推測するな、計測せよ。
SREとして、まず始めたのは可視化でした。「障害対応時間を短くしたい」と思っても、対応時間にはいくつかの種類があります。
障害が発生してから検知されるまでの時間
障害を検知してから暫定対応が完了するまでの時間
障害への暫定対応が完了してから恒久対応が完了するまでの時間
障害への恒久対応が完了してから振り返りが完了するまでの時間
そうした情報を含め、改善に必要なあらゆる情報を収集することにしました。幸い、エアクロではBacklogを活用したバグ管理が長く行われており(これは沖縄が生んだロジカルPMOのおかげ)、その仕組みに乗ることで、最小限のリソースで可視化を実現することができました。
ほかにも評価制度を変更したり、障害対応フローを見直したり、監視ツールをNewRelicに移行したり、データウェアハウスをRedshiftに移行したり、インシデント共有会を開始したりと、オペレーションの改善を着々と進めていきました。
この頃は毎日のようにひたすらホワイトボードに文字を書き、SREとしての方向性をすり合わせていたのを覚えています。
方針転換
ある日を境に、SREポジションの役割は「発生した問題をいかに早く解消するか」から、「クリティカルな問題をいかに発生させないか」へと大きく転換します。
可視化を中心にオペレーションの仕組みづくりを着々と進め、集まったデータを基にアクションに出ようとしていた新生SREですが、ある日事件が起こります。
エアークローゼットに新規に登録するための通称「登録ステップ」で、途中から先のステップに進めないという障害が発生したのです。
NewRelic導入の効果もあり、その障害自体は比較的早期に解消しましたが、ちょうどそのタイミングが全社として新規会員様の獲得に注力している期間だったこともあり、獲得計画に大きな影響を与えてしまいました。
ここから、SREポジションの役割は「発生した問題をいかに早く解消するか」から、「クリティカルな問題をいかに発生させないか」へと大きく転換します。もともと、TypeScript化や単体テストのカバレッジ補強など、発生させないことに対して取れるアクションが多く残っていたことも、この方針転換のポイントでした。
再スタート
上記の障害に加えて、最初のSRE2人のうち1人は社内の重要プロジェクト「Disney FASHION CLOSET」の全体設計にテックリードとして関わるためSREポジションを離れ、SREは私1人という状態になりました。
さらに、私にSREを教えてくれた先輩エンジニアがエアクロを去ることになります。SREを教わる以前から大型プロジェクトやキャリアの相談をしてもらっていただけに、冗談抜きで人生で一番悲しかったのを覚えています。先輩がエアクロを去ると聞いた日は全く仕事が手につかず、しまいには先輩の隣で泣きじゃくる始末でした。
ダブルパンチ…いやトリプルパンチ。それでも先輩に教えてもらったSREと、なんとしても品質を改善したいという想い、そしてエアクロのみんな (特に先輩を慕っていた若手メンバーたち) が私を支えてくれました。
2023年6月、SREは体制・方針ともに全く違う形で再スタートを切ったのでした。
最高のUXを実現する
クリティカルな問題を発生させないため、別の可視化が始まりました。今度はバグの発生傾向と原因の分析、メンバーが各自で振り返るためのバグ発生率。
そうして集まるデータから、これまでのKPIに加えて開発品質のKPIを新たに設定し、改善のための施策を動かしていきました。開発フローの変更や、GithubCopilotの導入、自動コードレビューの導入、別チームが動かすE2Eテストツールの導入支援、TypeScript化などなど…現在に至るまで施策を積み重ね、徐々に開発品質の基盤を形成しています。
一つ一つは小さい効果かもしれませんが、それらを一つずつ積み重ねて、お客様に感動いただけるような、最高のUXを実現していきたいと考えています。
おわりに
長いポエムになってしまいましたが、最後までご覧いただきありがとうございました。総じてチームの課題や挑戦したいことに対して、とことん挑戦させてくれるチャレンジ環境が、エアクロの大きな魅力です。そんな様子が少しでも伝わっていればとても嬉しいです。
エアークローゼットアドベントカレンダー2023はまだまだ続きますので、ぜひ個性豊かなメンバーの記事に目を通していただければと思います。
また、エアークローゼットではエンジニア採用活動も行っておりますので、興味のある方はぜひご覧ください。
この記事が気に入ったらサポートをしてみませんか？