Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
6年で売上40億に成長したサービスのSREチーム結成〜運営
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
isozakisei
May 24, 2022
Business
7.1k
0
Share
6年で売上40億に成長したサービスのSREチーム結成〜運営
202205SRE next
isozakisei
May 24, 2022
Other Decks in Business
See All in Business
CMB.TECH earnings call Q1 2026
cmbtech
PRO
0
910
【ラクス】新卒採用
rakus_career
0
76k
AnyMind Group Credential Deck(EN)
anymind
3
81k
情報を集める時間を チームを進める時間へ-Backlog AIアシスタントで変わった時間の使い方-
yasuhirox
0
300
merpay-overview_en
mercari_inc
1
29k
市場特性に応じたマルチプロダクト戦略と持続的な成長を支える組織デザイン
play_inc
0
3k
Crisp Code inc.|コーポレート・サービス紹介 - Corporate & Services Introduction
so_kotani
0
530
Brush Company Deck ver1.0
brush2026
0
490
Speee_2026年9月期第2四半期 決算説明資料
speee_pr
0
3.2k
【理学療法士・主任ケアマネの方急募】 入職祝い金 一律10万円支給キャンペーン
takanona25
0
210
Mercari-Fact-book_jp
mercari_inc
7
190k
The STORY OF M5STACK 2026年 名古屋Station AI M5Stack名古屋ミートアップにて #M5JPTOUR2026
takasumasakazu
0
170
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
6.1k
Rails Girls Zürich Keynote
gr2m
96
14k
Embracing the Ebb and Flow
colly
88
5k
The agentic SEO stack - context over prompts
schlessera
0
790
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
310
Ethics towards AI in product and experience design
skipperchong
2
290
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
200
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
1.1k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
We Are The Robots
honzajavorek
0
230
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2k
Transcript
7年で売上40億に成長した サービスのSREチーム結 成〜運営
はじめに 磯崎 勢 日立系のSI会社でしばらく働いた後、2015年にミイダスの立ち上げに参画。 開発初期から現在までバックエンドエンジニア兼チーム運営としていろいろやってます。
ミイダスとは 運営7年目の転職サービス
ミイダスでは転職希望者の経歴と、性格診断のデータがあります。 性格診断では ・マネジメント気質、ヴァイタリティ、チームワーク、上司タイプ、部下タイプ などを診断しています。 サービス紹介
経歴だけでなく、そういうのを使うことで、転職させて終わり、ではなく、「適材適所」を実現するためのサービ スになっています。 サービス紹介
2015/8 にサービス開始 2022現在、ユーザーは累計100万人、企業も40万社ほど登録があります。 開発チームとしては70人ほどの体制。 デザイナーやインフラチーム、テストエンジニアや、 PMOなども整備して、ちゃんとした会社になりつつあるとこ ろ。 サービスの状況
7年をざっと、3つの時期に分けてSRE ・サービス黎明期(10人弱ほど) ・成長期(2-3年目 20人程度)(停滞期(-5年目、40人程度)) ・成熟期(5-年目、50人程度 時期別に、SREについては、なにそれ? という状態から、いろいろやってきたので、それを紹介できればと思っ ています。(大体失敗談ではありますが 💦 *
当時〜現在までの状況をデフォルメしているので、中の人は生暖かい目で 🙏
黎明期 (1年目 10人ほどの体制) とりあえずリリースはしたものの、 売上はあまりあがらず、 機能や課金形態など、ピボットが続々 品質もあまり安定していない。
黎明期 運用の最適化(自動化、システム化、 etc)とかいってる場合じゃない ・毎分リリースしていたので、自動化とかは積極的にやっていた (自分が楽するためには、苦労を厭わない) ・誰が何をする、というのも明確ではなく、必要なものは誰かが片手間でやる =>廃れるものや、未メンテのツールがころがっている状態
黎明期 運用の最適化(自動化、システム化、 etc)とかいってる場合じゃない =>こういう時期こそちゃんとやったほうが良かったのかもしれないが、 ・ビジネスの人に「運用を考慮して」といっても通用しづらい ・また、SLIがこうなったら対策するために〜、みたいな仮定の話をしなくても、「そろそろヤバいです」で通じる ことが大事
成長期 (2ー3年目 15人程度の開発チーム) まだまだ、赤字ではあるが、売上がなんと なく上がってきて、毎分HOTFIX、の時期は 脱した頃。 立ち上げからの技術的負債はたまっているが、新機能要求も激しい。
そろそろ。。 ・保守にコストをさけるようにしなければならないので、このタイミングで SLOなどの目線合わせる必要がありま すが、理解があった(というか任されていた)ので、なんとなく保守チームを結成。
当初の目論見 ・大きめの開発案件とは別に、微修正を消化したい ・過去に作り込まれたバグの対応は、作り込み者が対応するのをなるべくやめる ・各プロセスを工夫したいが、まとまった時間がとれない
「SREチーム」と名付ける ==> ・開発チームの大部分を新規機能開発に集中するために、その他全部、みたいな位置づけになってしまった ・ミッションが曖昧なので、なにを優先するか、というところがコンセンがとれない =>やりたいことに作業が流れがち。
あるあるを少し
リファクタリングしたい えっ、それリリースしたばかりでは。。 ==>優先度的に「今じゃない」がつづき、そして伝説へ。。
メンバーの士気が低くなる ・やらないといけないことをこなしながら、いろいろやってはいるが、新規機能開発にくらべて華やかさがない ・なんかうまく行っている感がうすい。
感謝がほしい ・近くの困っている人の声を 優先してしまう。 =>まあ悪いことではないけど、 10人のサポート部門にめっちゃ感謝されるより、 1万社の企業や、10万人の ユーザーを優先したいが、 (具体的には、課金に関わる機能 ビジネスの取れるリスクと兼ね合い)
自分の仕事を減らすことにフォーカス ・管理画面に月に数回しかしないデータ補正の機能を作る (「悪いわけではないけど。。)
ー きちんとした目標が必要だな、とは思ったのですが、 可用性などの指標をもうけようにも、新機能を出すたびにバグがごろごろでてる状態で、保守開発ではコント ロールできない。とりあえずそのままにしておきました 💦
成熟期 (5年目、50人) 売上は2桁億にまで成長し、 複数のチームが並行で開発をすすめられる体制に。 (雰囲気も変わってきた
SREチームはほぼ保守開発チーム。 稼働率や性能指標や品質指標を定義し始めたこともあり、 SREチームを再定義することに。
2代目SREチームの目的 ・性能の維持 ・インフラコストの最適化 ・運用の自動化 (それまでのSREチームは開発チームとして再出発。(名前変更が地味にめんどう。。)
目的のものを監視する体制を構築し、 指標を定め、それによってリソースを集中させることができるようにする。 ということにしました。
けっこうSREっぽいですよね? それでもやっぱりいまいちで。。3つほど、困った事例を紹介します。
事例1:事件 半年で稼働率目標をたてましたが、丸1日のシステム停止が発生して、取り戻せないレベルまで落ちる =>しかも原因は本番での単純な作業ミス。。 =>SREリソースを調整するにはあまりにも微妙な事態 ==>これはどうすればよかったんだろうか。。
事例2:指標の定義 指標がどんどん複雑になっていく。。 =>0.2の重要度の機能が、1時間、10%のユーザーが使えなくなったなら、 月の稼働率低下は0.0027%。。 =>稼働率以外の指標も必要では? みたいな話になる
無駄なことではないが、あくまで指標は目安。ただ、議論を通して価値観が明確になった気がする。
事例3:大きな問題に引っ張られる 大きな問題に直面すると、それにかかりきりになる (ロードテスト環境が必要、抜本的に改善が必要な APIがある、 とかでそちらに全リソース持っていってしまう) ==>監視と改善する担当者分けるのがいいんだろうか。。
以上
まとめ 概念を勉強しているときには、チーム編成までシステム化される ように思えて、スマートな方法だと思っていたのですが、 まだまだ課題が山積み。。
まとめ ・ビジネスとの折衝が必要な場合には有効そう =>保守にかけるコストと、機能開発にかけるコストのバランスは揉めがち ・開発チーム内でも =>セキュリティのリスクと、性能低下によるシステム停止とどっちを優先するの、みたいな不毛な議論はしたくな い。 =>SLIの設定を通じて、チームがなにを重視しているかが明確になるので、「ビジョン」や「ミッション」を補完してくれ るかもしれない。
最後に ミイダスでは、SREエンジニアを募集しています。
以上