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

Transcript

1. スクラムを1年回して SREと開発組織がどう変わったのか AS OF 2020.1.25 株式会社ビズリーチ HRMOS採用SRE 1
2. 2 自己紹介 名前 　伊藤 理人 所属 　株式会社ビズリーチ 　HRMOS採用事業部 　プロダクト開発部SREチーム
5. 今日のお話 5
6. 6 アジェンダ - なぜスクラムなのか？ - スクラムとは - 課題と改善 - SREのタスクに優先度が付けられない - SREと開発組織の共依存 - SREの属人化 - まとめ
7. 7 なぜスクラムなのか？
8. なぜSREとスクラムの話？ みんなSREのスクラムの回し方に迷ってる 自分たちもスクラムやってきた中で色々課題があった 1年くらいスクラムをやって良かったこと、プラクティスなどを共有して 参考になれば嬉しい 8
9. 9 スクラムとは？
10. 10 スクラムとは スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレー ムワークであり、 可能な限り価値の高いプロダクトを生産的かつ創造的に届けるた めのものである。 スクラムとは、以下のようなものである。 • 軽量 • 理解が容易 • 習得は困難 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
11. 11 スプリントのサイクル スプリントの計画 プランニング PBIの優先度付け・詳細化 リファインメント 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI
12. 12 スプリントのサイクル スプリントの計画 プランニング 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント
13. 13 スプリントのサイクル 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング
14. 14 スプリントのサイクル 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング スクラムではプロダクトバックログを優先度順に並べ てスプリントバックログ（スプリントで消化するタスク）とし て扱う
15. 15 スプリントのサイクル 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング コミットメントの計測・日々の改善 デイリースクラム
16. 16 スプリントのサイクル 働き方の改善 レトロスペクティブ リリース PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング コミットメントの計測・日々の改善 デイリースクラム 成果物の評価・改善 スプリントレビュー
17. 17 スプリントのサイクル リリース PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング コミットメントの計測・日々の改善 デイリースクラム 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ
18. 18 スプリントのサイクル スプリントの計画 プランニング PBIの優先度付け・詳細化 リファインメント 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI
19. 19 課題と改善
20. - 優先度が付けられない - SREと開発チームの共依存 - SREの属人化 20 課題と改善
21. 21 優先度が付けられない
22. 22 開発チームとSREのフォーカスの違い 開発チーム ユーザー 機能 実装 開発チームは機能の実装にフォーカス
23. 23 開発チームとSREのフォーカスの違い SRE 障害対応 キャパシティプ ランニング 依頼対応 セキュリティ インシデント対応 自動化 Toil
24. 24 開発チームとSREのフォーカスの違い SRE 障害対応 キャパシティプ ランニング 依頼対応 セキュリティ インシデント対応 自動化 Toil 特定のタスクに フォーカスするのは難しい
25. 25 SRE同士でも課題に対する認識が違う ❓
26. 26 優先度を定量的に判断する Return Investment 実装もしくはそれに準ずるコスト SREにとってのReturn (価値)とは？
27. 27 HRMOS SREにとっての価値は稼働率 稼働率（Return）とコスト（Investment） イシュースコア：独自のROI指標
28. 28 イシュースコア: 独自のROI指標 停止時間 + 障害対応時間 対応コスト × 頻度 + セキュリティ指標
29. 29 全員が合意の元 同一の軸で優先度を判断できるようになった
30. 30 SREと開発チームの共依存
31. 31 組織構成 PO チームメンバー SM バックログ バックログ バックログ 開発チーム SREチーム バックログ CREチーム デザイナーチーム QAチーム
32. 32 SREと開発チームの共依存 チームのアジリティを高めたい 割り込みによって計画通りにタスクが進まない 　　　開発チームはSREへAWSのリソース作成依頼など SREは開発チームへコードの修正を依頼など Problem より効率的な協働の方法を模索
33. 33 SREと開発チームの関係の変化 - 開発チーム - SREとterraformのペアプロ - SRE - アプリケーションコードを自分達で直す - 権限移譲を推進し依存を減らす
34. 34 SREチームの属人化
35. 35 SREチームの課題 属人化 プランニングで計画が立てられない スプリント中の進捗が把握できない トラックナンバー1 Problem
36. 36 SREチームの課題 属人化 Problem レトロスペクティブ・デイリースクラムで改善 構成図、ドキュメントの整備 　タスクの可視化 チームメンバーへの知識・スキルの移譲
37. 37 新たな課題 タスクの進みが遅い 知識・スキルの移譲に時間がかかる スキルの高い人がもどかしさを感じる Problem
38. 38 新たな課題 タスクの進みが遅い Problem Try - 議論で認識を合わせる - 属人化させたままでは継続的な運用は不可能 - 一時的な「速さ」よりもチームとしての長期的な運用可能性が重要 - ペアプロ・ペア作業で速度とのバランスを取る
39. 39 SREチームの変化 - 認識が揃っていることを意識するようになった - 構成図、サンプルコードを以前より書くようになった 　→コミュニケーションコストの減少、意思決定の速度UP - 誰にでもできるようにすることを意識するようになった - タスクを細かく分割する・チケットの内容の粒度を合わせるなど 　→効率的なタスク進行
40. 40 より強固かつ柔軟な スクラムチームへ
41. 41 まとめ
42. 42 大事なこと - 可視化を通じて認識の統一を図る - 同じものを見ることが認識の統一の一番の近道である - 課題を自覚し向き合う - 個人との対話を通じ継続的な改善を実施する
44. 44 顧客満足を最優先し、 価値のあるソフトウェアを 早く継続的に提供する
45. 45 SREとスクラムのプラクティス 計測と改善
46. 46 SREとスクラムの共通項 SREもスクラムも初めにやることは計測 計測できないものはコントロール（改善）できない 　SRE：品質（ユーザーの体験）をコントロールしたい 　→ ユーザーの体験を計測可能な形（SLI）にして計測 　スクラム：技術品質をコントロールしたい 　→ 技術品質を計測可能な形（Doneの定義）にして計測 Example
47. 47 Don’t just do agile, be agile.
48. 48 https://bit.ly/2x0ICou