7年で売上40億のSREチーム結成〜運営
7年で売り上げ40億に成長したサービスのSRE結成から運営までということで発表させていただきます。ミイダスの磯崎です。
自己紹介とサービスについて
まずはじめに自己紹介をさせていただきます。
日立系のSI会社でしばらく働いた後、2015年ミイダスの立ち上げに参画してます。開発初期から現在まで、バックエンドエンジニア兼チームメンバーとして、色々取り組んでいます。
それでは次に、ミイダスのサービスについて紹介させてください。
ミイダスは、入社後の活躍を目的としたアセスメントリクルーティングで、適材適所の採用を実現するためのサービスです。簡単に言うと、リクナビやdodaのような転職を斡旋するサービスをイメージしていただければと思います。
私が参画した時に開発をスタートし、今ではユーザー数が78万人となっています。そこそこ大きなサービスに成長したように思います。
通常の転職サービスとの違いについてですが、ミイダスは性格診断などのデータをきちっと取っていて、マネジメント気質やバイタリティーなど、チームワークに関してどう思ってるのかといったことを診断してくれます。
興味がありましたらぜひやってみてください。面白い結果が出てくるのではないかなと思います。また、どの会社でどのようなWebエンジニアをやっていたなど経歴の情報だけでなく、あなたの性格的にもこういう会社が合っているのでは？といった観点で診断をしてくれます。単純に転職させて終わりではなく、アセスメント採用でミスマッチを減らし適材適所を実現できたらなと思ってサービスを運営しています。
7年間をざっと3つの時期に分けて、SREに関する取り組みを紹介
2015年の8月にサービス開始してから2022年の現在、先ほどお伝えしたようにユーザーは78万人以上で、40万社ほど企業の登録があります。
開発チームとしては70人ほどの体制になっています。1つのプロダクトで70人は相当多いと思うかもしれませんが、デザイナーやインフラチームやテストエンジニア、PMOも含めて多人数です。
そしてこの7年間、本当にゼロからの立ち上げでここまで大きくなりました。
この7年間をざっと3つの時期に分けて、SREに関してどういう向き合い方をして来たのか、乗り越えてきた課題などについてお話しさせていただきます。
当初はSREって何？と言う状態から、こういう感じでやっていけばいいんじゃない？と試行錯誤して取り組んでいました。上手くいかなかったこと、もっとこうすればよかったことの共有になると思いますが、それぞれの期でSREがどのような取り組みをしていたのかをご紹介したいと思います。
黎明期 1年目約10人の開発メンバー
まずはサービスの黎明期についてです。開発メンバーは10人弱ほどで、一心不乱にサービスを作ってる頃です。その後、2、3年目で成長期に入りました。20人程度のチームでやってた頃です。それから少し停滞期を挟んで5年目以降、50人以上のチームが働いてる成熟期に入りました。
この写真は「開発チームはどんな状態だったの？」という説明を社内でする機会があったので、その時に使った画像です。
そのシステムを立ち上げた頃は、みんな原始人みたいな感じで徒党も組まずに一人一人が黙々と一心不乱に「やることをやる！」みたいな感じでした。
この頃は、ミイダスをとりあえずリリースするところまではなんとかできたのですが、売上もあんまり上がってない状態で機能や課金の形態がどんどん変わっていって、品質も全然安定してない頃でした。そういう時期だったので、運用の最適化などを言ってる場合ではない状況でした。
ただ、毎分リリースしてたので自動化などは積極的にやっていましたね。そして、エンジニアあるあるなのですが、自分が楽をするためには苦労を厭わない、といったところがあったので、エンジニアの作業っていう意味では結構自動化がされていました。
この時は誰が運用チームでといったチームや役割は一切なく、必要なものは誰かが片手間でやるような体制になってました。その時に体系立てて考えていなかったので、結果、廃れたツールやメンテナンスツールが転がってる状態で、結構非効率なことをやっていたなと思います。
こういう時期にこそ、ちゃんとやった方が良いといった意見もあるとは思いますが、その当時のビジネスの人に「運用を考慮して」と話しても、多分通用しなかったんじゃないかなと思います。逆に、例えば「SLIがこうなったら対策するためにリソースを集中させましょう」みたいな仮定の話をわざわざしなくても、「そろそろヤバイので、ちょっとこういうことをやらせてください」と言えば話が通じる組織だったので、むしろ理解があるんじゃないかなと思っています。
成長期 2.3年目約15人の開発メンバー
続いて成長期についてですが、例えると、マンモスを狩るぐらいのイメージです。15人から20人程度の開発チームでみんながチームとして動けるようになってきた時期ですね。
サービス自体は赤字ではあるものの、売上が徐々に上がってきていました。しかし毎分ホットフィックスしてるような品質状態で、技術的な負債は溜まり、新規機能の要求も激しく...結構大変な時代でしたね。
そろそろ保守にコストを割かないといけないよねと思っていたので、ビジネス側と目線合わせをしました。弊社のビジネスの人は理解があったというか、エンジニアで方向性を決めて好きにやっていいよ、というところがあったんで、なんとなく保守チームを結成しました。
ーー保守チームとして1代目SREチームの結成
当初のチームの目論見としては、大きな開発案件とは別に微修正がすごく溜まっていたのでそういうのを消化していく予定でした。バグの対応などで、新規機能開発が遅れるのが嫌だったので、担当を分けたかったのと、生産性向上などに取り組みたいが、まとまった時間が取れないのでチームを分けて、それはそれで別でやろうっていう感じで結成しました。
実はこのチームを、SREのことをよく知らないまま「SREチーム」と名付けてしまったのです。
これは結果的にあんまり上手く行きませんでした。
開発チームの大部分を新規機能の開発に集中するために、その他全部を担うという位置づけになってしまって。何を優先してやったらいいのか、全然コンセンサスが取れていなかったのです。
そのコンセンサスが取れてない結果、必要な作業よりも、やりたい作業が優先されてしまいました。
ーーリファクタリングをしたい欲求
あるあるかもしれませんが、まず「リファクタリングをしたい」という欲求がめちゃめちゃ上がってくるようになりました。
リリースしたばかりの機能から、昔から作ってそのままになっている機能も「なんか小汚いから何とかしたい」という声が結構上がってきたのです。
これはやりたいけど、今じゃないでしょう...っていうのが続いて。そのうち開発チームの中で、伝説のリファクタリングって呼ばれるようになってしまいました（笑）
これは、あんまり良くない状況ではあったのですが、揶揄するくらいの元気はあったのかなって感じています。
ーーメンバーの士気の低下と業務の優先順位
そういうところも相まって、メンバーの士気がちょっと低くなっている状況でした。
新規の機能開発は、使われることで「嬉しい」とか色々なフィードバックが入るところに良さがあるんですよね。反面、保守や生産性向上というのは、うまくいってる実感が薄いのでそのあたりを上手くやらないといけないと思います。しかし当時はメンバーへのケアができていなくて、士気が低くなったままの状態になってしまいましたね。
また「感謝が欲しい」というのがあると思います。やらなきゃいけないことより、近くの困ってる人の声を優先してしまう状態にもなりました。もちろんそれは悪いことではないのですが、10人のサポート部門にめちゃくちゃ感謝されることよりも、その1万社の企業や10万人のユーザーの求めるものをまずはやりたいんですよね。
例えば、課金に関わる機能をシステム化する必要があるのかと議論がありましたが、経理はその課金の作業を手作業でやるとミスも起こるので、システム化したいという要望でしたが、課金の金額を間違えるリスクとその工数を開発に使えることを比較し、後者の方向になりました。これはビジネス側でこだわりのある部分だったこともあるんですけどね。
この例は、サービスの立ち上げの時と同じようなところもあると思っていて。誰しも自分の仕事を減らすことを優先したいでしょう。例えば定期的に運営側から指示される作業をわざわざそのシステム管理画面に作り込むかどうか、などですね。
その月に数回しかしない作業だったら、手でやればすぐ終わるし早いのです。それをわざわざシステムに一生懸命落とすようなことをする。
もちろんこれも悪いことではないのですが、ちゃんと頻度や効果、リスクを考えてやらないといけません。単純にその手作業をなくしたいだけで機能改善を要求される、そういうことも結構ありますね。
結果的にきちんとした目標がチームに必要だなと当時思ってはいたので、その目標に対する指標などを考え始めていました。しかし、新機能を出すたびにバグがごろごろ出ている状態で、目標を立てても、保守チームではコントロールできないことが多すぎる状況でしたので、何か上手い指標はないかな？と思いながら、そのままになっていました。
成熟期 5年目約50人の開発メンバー
それから成熟期に入りました。この間、先程ご紹介したSREチームは保守開発中心としていて、SREっぽい活動はあまり出来ないまま、少し停滞してる時期がありました。
成熟期ということで5年目に突入し、開発メンバーも50人ぐらいのチームになった頃ですね。売上が2桁億円にまで成長していて、複数のチームが並行で開発を進められる体制になってきました。
それに伴って、今までの原始人のような感じから、ちょっとずつチームワークができるような体制になりました。雰囲気も変わってきた時期ですね。
ほぼ保守開発チームになってしまったSREチームはさておき、稼働率や性能指標、品質指標を使ってSREチームを再定義したいなと考えるようになりました。
そこで、2代目のSREチームを結成することにしました。そのチームの目的としては性能の維持とインフラコストの最適化、運用の自動化などで、新しくSREを立て直そうと思いました。そしてこれまでのSREチームは開発保守チームとして、再出発ということにしました。
この名前の変更が地味に面倒で（笑）何も考えずに名前を付けてしまうのは、本当に良くないなと思いました。
先程お話しした、目的のものを監視する体制を構築して指標を定め、それによってリソースを集中させることができるようにする。を目標にチームを結成させてます。SREっぽい感じになるように。
しかし、それでもイマイチなところが色々あったので紹介しようと思います。
ーー半年の稼働率目標を立てるも、丸1日のシステム停止障害により取り戻せないレベルまで落ちる
まず、半年の稼働率の目標を立てて、それが落ちてきたなら改善チームを立ち上げようとおもっていたのですが、たまたまその期が始まった直後頃に丸1日のシステム停止が発生して、のこりの半年では取り戻せないレベルまで稼働率が落ちてしまったのです。しかも原因が本番での単純な作業ミス。
これをトリガーにして改善チームを立ち上げるわけにいかず、せっかく自分たちで作ったルールをいきなり無視をするみたいな状況になってしまいました。稼働率が落ちたなら、機械的にトリガーが引かれて...といったことを考えていたのですが、全然うまくいきませんでした。
これに関しては、ルールをガチッと決めずにもう少しふんわり考えればいいじゃないかといった話もあると思います。しかしこういう状況が続くと、結局何のためにトリガーを定義してるんだみたいなところになるんですよね。どちらにしても、良くない状況だったなと思いました。
ーー指標の定義がどんどん複雑になる
次に指標がどんどん複雑になってしまったことです。
正確にその現実を捉えようとすると、指標って結構複雑にしようという力が働いてしまうっていうところですね。そこそこ重要な機能がバグで1時間止まってました。という時に、0.2%の重要度の機能が1時間10%のユーザーで使えなくなったら、稼働率の低下は0.0027%と計算してしまうといったところですね。
稼働率が逆に落ちないっていう状態になってしまって。そのバグの影響度などを過去にさかのぼって計算すると、すごく大きな数値になってしまい、稼働率の計算が安定しない。その計算方法が間違ってるんじゃないか、とその計算方法やそもそもその指標の議論が始まったりと、本来時間をかけるべきところにかけることができない状態になっていました。
こだわりだすと議論の収拾がつかなくなる状況に陥るので、そういうのは気をつけないといけないと思いましたね。
議論自体無駄なことでは全然ないとは思うのですが、指標はあくまで目安なんですよね。しかし、その議論を通じて価値観が明確になったような気がするので、議論ができてよかったと思っています。
ーー大きな問題に直面するとSREの全リソースが埋まる
それから3つ目は、大きな問題に引っ張られるということについてです。SREチームを作ったのは良いものの、スモールスタートだったため、大きめの問題が発生するとそれに全員がかかりきりになってしまいました。
その結果、SREチームって言ってるのに、やったのってこれだけなの？といった感じで。もちろん工数のかかる大きなことをやったっていうのは理解してるのですが、その細かい改善とかをするチームだったはずなのに...という状態でした。
この問題に関して、どうすれば良いのか答えを持ってないのですが、ちゃんとリソースが使えるような状況にSREは持っていかなきゃいけないんじゃないかと今は考えています。現状だと、また色々状況が変わっているところもありますが。
まとめ
SREの概念を勉強する時には、チーム編成までシステムみたいにしていくのはすごくスマートなやり方だなと思ってはいたのですが、実際、課題は山積みでしたし運営もなかなか思った通りにはいかなかったですね。
きちんと指標を定義することに関しては、ビジネスとの折衝が必要な場合にはすごく有効なんじゃないかなとは思っています。保守にかけるコストと機能開発にかけるコストのバランスっていうのは結構揉めがちな問題ではあるので。
それを客観的にできるっていうのは、すごくいいなと思ってます。
あと、開発チーム内でもセキュリティのリスクと性能低下によるシステム停止、どっちを優先するの？といった抽象的な議論に入らずに、もっと具体的に「この指標がこれをやったらこのぐらい上がる」みたいな議論になるのはいいことなのかなと思います。
その設定を通じてチームが何を重視しているのかみたいなのが明確になる。そしてチームのビジョンやミッションなど、そういうものを補完してくれるものになるのではないかなと思いました。
最後に、ミイダスでは、SREエンジニアを募集しています。
色々とちゃんと取り組みができていない状態なので。これを一緒に何とかしてくれる方でも、SERの何たるかをこう教えてくれるような方でも大歓迎です。絶賛募集中なのでよろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？