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
スクラムを1年回して SREと開発組織がどう変わったのか
Search
licht110
January 25, 2020
Technology
13
15k
スクラムを1年回して SREと開発組織がどう変わったのか
licht110
January 25, 2020
Tweet
Share
Other Decks in Technology
See All in Technology
Makuake*UPSIDER_LightningTalk
upsider_tech
0
200
ココナラのセキュリティ組織の体制・役割・今後目指す世界
coconala_engineer
0
220
トレードオフスライダーにおける品質について考えてみた
suzuki_tada
3
180
Windows Server 2025 へのアップグレードではまった話
tamaiyutaro
2
260
アクセシブルなマークアップの上に成り立つユーザーファーストなドロップダウンメニューの実装 / 20250127_cloudsign_User1st_FE
bengo4com
2
1.2k
Amazon Location Serviceを使ってラーメンマップを作る
ryder472
2
160
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
0
220
企業テックブログにおける執筆ネタの考え方・見つけ方・広げ方 / How to Think of, Find, and Expand Writing Topics for Corporate Tech Blogs
honyanya
0
810
Skip Skip Run Run Run ♫
temoki
0
360
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
snoozer05
PRO
17
4k
業務ツールをAIエージェントとつなぐ - Composio
knishioka
0
110
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
The Cult of Friendly URLs
andyhume
78
6.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
6
220
Building Applications with DynamoDB
mza
93
6.2k
Building an army of robots
kneath
302
45k
How GitHub (no longer) Works
holman
312
140k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.3k
Faster Mobile Websites
deanohume
305
30k
Designing for Performance
lara
604
68k
We Have a Design System, Now What?
morganepeng
51
7.4k
GitHub's CSS Performance
jonrohan
1030
460k
Designing for humans not robots
tammielis
250
25k
Transcript
スクラムを1年回して SREと開発組織がどう変わったのか AS OF 2020.1.25 株式会社ビズリーチ HRMOS採用SRE 1
2 自己紹介 名前 伊藤 理人 所属 株式会社ビズリーチ HRMOS採用事業部 プロダクト開発部SREチーム
None
None
今日のお話 5
6 アジェンダ - なぜスクラムなのか? - スクラムとは - 課題と改善 - SREのタスクに優先度が付けられない
- SREと開発組織の共依存 - SREの属人化 - まとめ
7 なぜスクラムなのか?
なぜSREとスクラムの話? みんなSREのスクラムの回し方に迷ってる 自分たちもスクラムやってきた中で色々課題があった 1年くらいスクラムをやって良かったこと、プラクティスなどを共有して 参考になれば嬉しい 8
9 スクラムとは?
10 スクラムとは スクラム(名詞):複雑で変化の激しい問題に対応するためのフレー ムワークであり、 可能な限り価値の高いプロダクトを生産的かつ創造的に届けるた めのものである。 スクラムとは、以下のようなものである。 • 軽量 •
理解が容易 • 習得は困難 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
11 スプリントのサイクル スプリントの計画 プランニング PBIの優先度付け・詳細化 リファインメント 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ
リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI
12 スプリントのサイクル スプリントの計画 プランニング 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善
デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント
13 スプリントのサイクル 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI
PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング
14 スプリントのサイクル 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース コミットメントの計測・日々の改善 デイリースクラム PBI
PBI PBI PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング スクラムではプロダクトバックログを優先度順に並べ てスプリントバックログ(スプリントで消化するタスク)とし て扱う
15 スプリントのサイクル 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ リリース PBI PBI PBI
PBI SBI SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング コミットメントの計測・日々の改善 デイリースクラム
16 スプリントのサイクル 働き方の改善 レトロスペクティブ リリース PBI PBI PBI PBI SBI
SBI SBI SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング コミットメントの計測・日々の改善 デイリースクラム 成果物の評価・改善 スプリントレビュー
17 スプリントのサイクル リリース PBI PBI PBI PBI SBI SBI SBI
SBI PBIの優先度付け・詳細化 リファインメント スプリントの計画 プランニング コミットメントの計測・日々の改善 デイリースクラム 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ
18 スプリントのサイクル スプリントの計画 プランニング PBIの優先度付け・詳細化 リファインメント 成果物の評価・改善 スプリントレビュー 働き方の改善 レトロスペクティブ
リリース コミットメントの計測・日々の改善 デイリースクラム PBI PBI PBI PBI SBI SBI SBI SBI
19 課題と改善
- 優先度が付けられない - SREと開発チームの共依存 - SREの属人化 20 課題と改善
21 優先度が付けられない
22 開発チームとSREのフォーカスの違い 開発チーム ユーザー 機能 実装 開発チームは機能の実装にフォーカス
23 開発チームとSREのフォーカスの違い SRE 障害対応 キャパシティプ ランニング 依頼対応 セキュリティ インシデント対応 自動化
Toil
24 開発チームとSREのフォーカスの違い SRE 障害対応 キャパシティプ ランニング 依頼対応 セキュリティ インシデント対応 自動化
Toil 特定のタスクに フォーカスするのは難しい
25 SRE同士でも課題に対する認識が違う ❓
26 優先度を定量的に判断する Return Investment 実装もしくはそれに準ずるコスト SREにとってのReturn (価値)とは?
27 HRMOS SREにとっての価値は稼働率 稼働率(Return)とコスト(Investment) イシュースコア:独自のROI指標
28 イシュースコア: 独自のROI指標 停止時間 + 障害対応時間 対応コスト × 頻度 +
セキュリティ指標
29 全員が合意の元 同一の軸で優先度を判断できるようになった
30 SREと開発チームの共依存
31 組織構成 PO チームメンバー SM バックログ バックログ バックログ 開発チーム SREチーム
バックログ CREチーム デザイナーチーム QAチーム
32 SREと開発チームの共依存 チームのアジリティを高めたい 割り込みによって計画通りにタスクが進まない 開発チームはSREへAWSのリソース作成依頼など SREは開発チームへコードの修正を依頼など Problem より効率的な協働の方法を模索
33 SREと開発チームの関係の変化 - 開発チーム - SREとterraformのペアプロ - SRE - アプリケーションコードを自分達で直す
- 権限移譲を推進し依存を減らす
34 SREチームの属人化
35 SREチームの課題 属人化 プランニングで計画が立てられない スプリント中の進捗が把握できない トラックナンバー1 Problem
36 SREチームの課題 属人化 Problem レトロスペクティブ・デイリースクラムで改善 構成図、ドキュメントの整備 タスクの可視化 チームメンバーへの知識・スキルの移譲
37 新たな課題 タスクの進みが遅い 知識・スキルの移譲に時間がかかる スキルの高い人がもどかしさを感じる Problem
38 新たな課題 タスクの進みが遅い Problem Try - 議論で認識を合わせる - 属人化させたままでは継続的な運用は不可能 -
一時的な「速さ」よりもチームとしての長期的な運用可能性が重要 - ペアプロ・ペア作業で速度とのバランスを取る
39 SREチームの変化 - 認識が揃っていることを意識するようになった - 構成図、サンプルコードを以前より書くようになった →コミュニケーションコストの減少、意思決定の速度UP - 誰にでもできるようにすることを意識するようになった -
タスクを細かく分割する・チケットの内容の粒度を合わせるなど →効率的なタスク進行
40 より強固かつ柔軟な スクラムチームへ
41 まとめ
42 大事なこと - 可視化を通じて認識の統一を図る - 同じものを見ることが認識の統一の一番の近道である - 課題を自覚し向き合う - 個人との対話を通じ継続的な改善を実施する
43
44 顧客満足を最優先し、 価値のあるソフトウェアを 早く継続的に提供する
45 SREとスクラムのプラクティス 計測と改善
46 SREとスクラムの共通項 SREもスクラムも初めにやることは計測 計測できないものはコントロール(改善)できない SRE:品質(ユーザーの体験)をコントロールしたい → ユーザーの体験を計測可能な形(SLI)にして計測 スクラム:技術品質をコントロールしたい → 技術品質を計測可能な形(Doneの定義)にして計測
Example
47 Don’t just do agile, be agile.
48 https://bit.ly/2x0ICou
49