スクラムを1年回して SREと開発組織がどう変わったのか

by licht110

Slide 1

Slide 1 text

スクラムを1年回して SREと開発組織がどう変わったのか AS OF 2020.1.25 株式会社ビズリーチ HRMOS採用SRE 1

Slide 2

Slide 2 text

2 自己紹介名前　伊藤理人所属　株式会社ビズリーチ　HRMOS採用事業部　プロダクト開発部SREチーム

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

今日のお話 5

Slide 6

Slide 6 text

6 アジェンダ - なぜスクラムなのか？ - スクラムとは - 課題と改善 - SREのタスクに優先度が付けられない - SREと開発組織の共依存 - SREの属人化 - まとめ

Slide 7

Slide 7 text

7 なぜスクラムなのか？

Slide 8

Slide 8 text

なぜSREとスクラムの話？みんなSREのスクラムの回し方に迷ってる自分たちもスクラムやってきた中で色々課題があった 1年くらいスクラムをやって良かったこと、プラクティスなどを共有して参考になれば嬉しい 8

Slide 9

Slide 9 text

9 スクラムとは？

Slide 10

Slide 10 text

10 スクラムとはスクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。スクラムとは、以下のようなものである。 • 軽量 • 理解が容易 • 習得は困難 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

Slide 11

Slide 11 text

11 スプリントのサイクルスプリントの計画プランニング PBIの優先度付け・詳細化リファインメント成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブリリースコミットメントの計測・日々の改善デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI

Slide 12

Slide 12 text

12 スプリントのサイクルスプリントの計画プランニング成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブリリースコミットメントの計測・日々の改善デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化リファインメント

Slide 13

Slide 13 text

13 スプリントのサイクル成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブリリースコミットメントの計測・日々の改善デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化リファインメントスプリントの計画プランニング

Slide 14

Slide 14 text

14 スプリントのサイクル成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブリリースコミットメントの計測・日々の改善デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化リファインメントスプリントの計画プランニングスクラムではプロダクトバックログを優先度順に並べてスプリントバックログ（スプリントで消化するタスク）として扱う

Slide 15

Slide 15 text

15 スプリントのサイクル成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブリリース PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化リファインメントスプリントの計画プランニングコミットメントの計測・日々の改善デイリースクラム

Slide 16

Slide 16 text

16 スプリントのサイクル働き方の改善レトロスペクティブリリース PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化リファインメントスプリントの計画プランニングコミットメントの計測・日々の改善デイリースクラム成果物の評価・改善スプリントレビュー

Slide 17

Slide 17 text

17 スプリントのサイクルリリース PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化リファインメントスプリントの計画プランニングコミットメントの計測・日々の改善デイリースクラム成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブ

Slide 18

Slide 18 text

18 スプリントのサイクルスプリントの計画プランニング PBIの優先度付け・詳細化リファインメント成果物の評価・改善スプリントレビュー働き方の改善レトロスペクティブリリースコミットメントの計測・日々の改善デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI

Slide 19

Slide 19 text

19 課題と改善

Slide 20

Slide 20 text

- 優先度が付けられない - SREと開発チームの共依存 - SREの属人化 20 課題と改善

Slide 21

Slide 21 text

21 優先度が付けられない

Slide 22

Slide 22 text

22 開発チームとSREのフォーカスの違い開発チームユーザー機能実装開発チームは機能の実装にフォーカス

Slide 23

Slide 23 text

23 開発チームとSREのフォーカスの違い SRE 障害対応キャパシティプランニング依頼対応セキュリティインシデント対応自動化 Toil

Slide 24

Slide 24 text

24 開発チームとSREのフォーカスの違い SRE 障害対応キャパシティプランニング依頼対応セキュリティインシデント対応自動化 Toil 特定のタスクにフォーカスするのは難しい

Slide 25

Slide 25 text

25 SRE同士でも課題に対する認識が違う ❓

Slide 26

Slide 26 text

26 優先度を定量的に判断する Return Investment 実装もしくはそれに準ずるコスト SREにとってのReturn (価値)とは？

Slide 27

Slide 27 text

27 HRMOS SREにとっての価値は稼働率稼働率（Return）とコスト（Investment）イシュースコア：独自のROI指標

Slide 28

Slide 28 text

28 イシュースコア: 独自のROI指標停止時間 + 障害対応時間対応コスト × 頻度 + セキュリティ指標

Slide 29

Slide 29 text

29 全員が合意の元同一の軸で優先度を判断できるようになった

Slide 30

Slide 30 text

30 SREと開発チームの共依存

Slide 31

Slide 31 text

31 組織構成 PO チームメンバー SM バックログバックログバックログ開発チーム SREチームバックログ CREチームデザイナーチーム QAチーム

Slide 32

Slide 32 text

32 SREと開発チームの共依存チームのアジリティを高めたい割り込みによって計画通りにタスクが進まない　　　開発チームはSREへAWSのリソース作成依頼など SREは開発チームへコードの修正を依頼など Problem より効率的な協働の方法を模索

Slide 33

Slide 33 text

33 SREと開発チームの関係の変化 - 開発チーム - SREとterraformのペアプロ - SRE - アプリケーションコードを自分達で直す - 権限移譲を推進し依存を減らす

Slide 34

Slide 34 text

34 SREチームの属人化

Slide 35

Slide 35 text

35 SREチームの課題属人化プランニングで計画が立てられないスプリント中の進捗が把握できないトラックナンバー1 Problem

Slide 36

Slide 36 text

36 SREチームの課題属人化 Problem レトロスペクティブ・デイリースクラムで改善構成図、ドキュメントの整備　タスクの可視化チームメンバーへの知識・スキルの移譲

Slide 37

Slide 37 text

37 新たな課題タスクの進みが遅い知識・スキルの移譲に時間がかかるスキルの高い人がもどかしさを感じる Problem

Slide 38

Slide 38 text

38 新たな課題タスクの進みが遅い Problem Try - 議論で認識を合わせる - 属人化させたままでは継続的な運用は不可能 - 一時的な「速さ」よりもチームとしての長期的な運用可能性が重要 - ペアプロ・ペア作業で速度とのバランスを取る

Slide 39

Slide 39 text

39 SREチームの変化 - 認識が揃っていることを意識するようになった - 構成図、サンプルコードを以前より書くようになった　→コミュニケーションコストの減少、意思決定の速度UP - 誰にでもできるようにすることを意識するようになった - タスクを細かく分割する・チケットの内容の粒度を合わせるなど　→効率的なタスク進行

Slide 40

Slide 40 text

40 より強固かつ柔軟なスクラムチームへ

Slide 41

Slide 41 text

41 まとめ

Slide 42

Slide 42 text

42 大事なこと - 可視化を通じて認識の統一を図る - 同じものを見ることが認識の統一の一番の近道である - 課題を自覚し向き合う - 個人との対話を通じ継続的な改善を実施する

Slide 43

Slide 43 text

Slide 44

Slide 44 text

44 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する

Slide 45

Slide 45 text

45 SREとスクラムのプラクティス計測と改善

Slide 46

Slide 46 text

46 SREとスクラムの共通項 SREもスクラムも初めにやることは計測計測できないものはコントロール（改善）できない　SRE：品質（ユーザーの体験）をコントロールしたい　→ ユーザーの体験を計測可能な形（SLI）にして計測　スクラム：技術品質をコントロールしたい　→ 技術品質を計測可能な形（Doneの定義）にして計測 Example