20190118_srelounge.pdf - Speaker Deck

20190118_srelounge.pdf

by pataiji

Slide 1

Slide 1 text

事業成長事業成長×キャリア形成キャリア形成という観点でのという観点でのSRE立ち上げ立ち上げ 2019/01/18 SRE Lounge #7 2019/01/18 SRE Lounge #7

Slide 2

Slide 2 text

天野天野太智太智 @pataiji Speee DX事業本部エンジニアリングマネージャー SREチームのリーダーもやってます最近は初めてやることばかりで冷や汗書く日々 2 2 2

Slide 3

Slide 3 text

今日は今日は2018年年5月に月に SREチームを立ち上げた背景と狙いをチームを立ち上げた背景と狙いを開発組織的な面を絡めてお話させていただ開発組織的な面を絡めてお話させていただきますきます 3 3 3

Slide 4

Slide 4 text

ていうかていうかSpeeeってって... 4 4 4

Slide 5

Slide 5 text

5 5 5

Slide 6

Slide 6 text

立ち上げの背景と狙い立ち上げの背景と狙い 6 6 6

Slide 7

Slide 7 text

現在のチーム規模現在のチーム規模開発チームは15名程度その内バックエンドエンジニアは8名 SREエンジニアは2名 7 7 7 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 8

Slide 8 text

これまでの開発組織これまでの開発組織 8 8 8 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 9

Slide 9 text

不動産領域で2サービスそれを横断する開発開発の中心に案件DB インフラチームは無く、サーバーサイドがインフラまで見る立ち上げの背景と狙い立ち上げの背景と狙い 9 9 9

Slide 10

Slide 10 text

各メンバーが案件起票立ち上げの背景と狙い立ち上げの背景と狙い 10 10 10

Slide 11

Slide 11 text

PMが内容を精査立ち上げの背景と狙い立ち上げの背景と狙い 11 11 11

Slide 12

Slide 12 text

PMとリードで最終調整立ち上げの背景と狙い立ち上げの背景と狙い 12 12 12

Slide 13

Slide 13 text

各エンジニアにタスクを割り振り立ち上げの背景と狙い立ち上げの背景と狙い 13 13 13

Slide 14

Slide 14 text

課題だらけ課題だらけ 14 14 14

Slide 15

Slide 15 text

リードエンジニアが圧倒的SPOF 全体を把握できるのがリードだけ各エンジニア感での情報流通の滞りそれにより相互フォローできない各エンジニアが社内受託のような状態フットワークが重く攻めの開発ができないフットワークが重く攻めの開発ができない 15 15 15

Slide 16

Slide 16 text

攻めの開発攻めの開発 = 事業の未来を見据えた開発事業の未来を見据えた開発事業/プロダクトの未来を描く → 事業責任者/PM それを実現する手段を考え実行する → リードエンジニア (SPOF ) それを支えるシステムの未来を描え実行するアプリケーション/インフラ x 複数サービス → リードエンジニア (SPOF ) 16 16 16

Slide 17

Slide 17 text

リードエンジニア (SPOF ) → 未来のことを考える余裕なんて無く、足元の開発がメイン未来のことを考える余裕なんて無く、足元の開発がメイン 17 17 17

Slide 18

Slide 18 text

改善改善 18 18 18

Slide 19

Slide 19 text

プロジェクト制を導入 PMがプロジェクト立案プロジェクトの初期段階からエンジニアをアサインこの組織変更によりエンジニアの裁量が増え、事業成長に繋がる攻めの開発をやりやすくなった立ち上げの背景と狙い立ち上げの背景と狙い 19 19 19

Slide 20

Slide 20 text

事業/プロダクトの未来を描く → 事業責任者/PM それを実現する手段を考え実行する → プロジェクトチームプロジェクトチームそれを支えるシステムの未来を考え実行するアプリケーション/インフラ x 複数サービス → リードエンジニア (SPOF ) 20 20 20

Slide 21

Slide 21 text

さらに改善さらに改善 21 21 21 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 22

Slide 22 text

プロジェクトチームを組み事業成長のための攻めの開発速度が格段に上がった結果として、各所で部分最適が進みプロダクト全体の信頼性が落ちやすい状態に → SREチームの立上げチームの立上げ 22 22 22 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 23

Slide 23 text

事業/プロダクトの未来を描く → 事業責任者/PM それを実現する手段を考え実行する → プロジェクトチームそれを支えるシステムの未来を考え実行するアプリケーション/インフラ x 複数サービス → SREチームチーム 23 23 23

Slide 24

Slide 24 text

信頼性を向上させる開発にSREチームが責任を持つことで、攻めの開発に集中できる体制に立ち上げの背景と狙い立ち上げの背景と狙い 24 24 24

Slide 25

Slide 25 text

SRE立ち上げの狙いはもうひとつ立ち上げの狙いはもうひとつ 25 25 25 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 26

Slide 26 text

これまで Speeeのエンジニアの多くが求められた守備範囲 26 26 26 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 27

Slide 27 text

バックエンド 27 27 27 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 28

Slide 28 text

バックエンドインフラ 28 28 28 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 29

Slide 29 text

バックエンドインフラフロントエンド 29 29 29 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 30

Slide 30 text

Web開発におけるだいたい全部開発におけるだいたい全部 30 30 30 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 31

Slide 31 text

ここまでが一定以上できて一人前として扱われる (必ずしもそうだったわけではないが空気感としてはたしかにあった) 31 31 31 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 32

Slide 32 text

当時、バックエンド開発はできるがインフラ/フロントエンドまでガンガンいけるぜ！という人は少なかった 32 32 32 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 33

Slide 33 text

結果結果インフラ/フロントを伸ばしたい！のモチベーションの渋滞 → 機会を用意できず成長の足枷に特定の領域に強みを持った人の採用がやりにくい → 活かせるフィールドが限定的 → 既存エンジニアとの不整合 33 33 33 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 34

Slide 34 text

改善改善 34 34 34 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 35

Slide 35 text

組織のマトリックス化を進める立ち上げの背景と狙い立ち上げの背景と狙い 35 35 35

Slide 36

Slide 36 text

SREチームは必然、インフラ周りの開発も多くなるためインフラや基盤系の開発を伸ばしたい人はSREチームに SREチームにはその道のスペシャリストがいる状態 (フロントエンドも同様) 36 36 36 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 37

Slide 37 text

結果結果開発組織内の役割が明確化実際にアプリケーション開発に強みを持つ人を採用もできた採用計画も引きやすくなったエンジニアのキャリア形成の計画も立てやすくなっためっちゃよかった 37 37 37 立ち上げの背景と狙い立ち上げの背景と狙い

Slide 38

Slide 38 text

立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題 38 38 38

Slide 39

Slide 39 text

立ち上げ時の課題立ち上げ時の課題事業としてはまだまだ成長をガンガン狙いたい中、社内でSREチームを立ち上げることが初の試みだったので存在意義を実感してもらうこと既存のシステムに対する問い合わせ、バグ修正は誰がするのか 39 39 39 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 40

Slide 40 text

社内でSREチームを立ち上げることが初の試みだったので存在意義を実感してもらうこと → SREチームの目標としてまず必要性を認識してチームの目標としてまず必要性を認識してもらうことを織り込んだもらうことを織り込んだ 40 40 40 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 41

Slide 41 text

立ち上げ時の立ち上げ時のOKR 41 41 41 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 42

Slide 42 text

42 42 42

Slide 43

Slide 43 text

ちなみにOKRの運用はこの本をベースにしてます 43 43 43

Slide 44

Slide 44 text

既存のシステム/プロジェクトで新規開発したものに対する問い合わせ、バグ修正は誰がするのか → 全て一旦全て一旦SREチームが受ける形にチームが受ける形に (そのほうがトイルの改善も進むことを見込んで) 44 44 44 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 45

Slide 45 text

実際に取り組んだことの例問い合わせフローを整理し定量化、トイルを見定め解消新規開発のインフラ構築(コンテナ運用を試験的に実施) 監視体制の整理 SLOを定義して計測しようと思ったら監視体制に不備があることが分かったｗエラー通知の整理、ISMSへの対応 Specガチャの修正 45 45 45 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 46

Slide 46 text

結果として結果としてトイルの削減や、問い合わせフローの整理などによりプロジェクト開発に集中できた実績を作ることができ PM/エンジニアへのヒアリングからも SREがいて良かったという意見をもらうことができた 46 46 46 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 47

Slide 47 text

47 47 47 立ち上げ時にぶつかった課題立ち上げ時にぶつかった課題

Slide 48

Slide 48 text

今ぶつかっている課題今ぶつかっている課題 48 48 48

Slide 49

Slide 49 text

採用採用 49 49 49

Slide 50

Slide 50 text

SREは比較的新しい役職なので経験者がいない各社SREをやっている人が少ないので重要なポジションをしているケースが多く、転職しにくい 50 50 50

Slide 51

Slide 51 text

まとめまとめ 51 51 51

Slide 52

Slide 52 text

SREチーム立ち上げの狙いは2つ攻めの開発に安心して注力できるように採用/キャリア形成を無理なく計画的に実行できるように SREの必要性を理解してもらうためには定量的な目標を立て、実感してもらうのが早い人が、足りない 52 52 52