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
14k
スクラムを1年回して SREと開発組織がどう変わったのか
licht110
January 25, 2020
Tweet
Share
Other Decks in Technology
See All in Technology
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
200
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
180
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
150
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
220
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
15
3.7k
スタートアップにおける組織設計とスクラムの長期戦略 / Scrum Fest Kanazawa 2024
yoshikiiida
13
3.6k
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
DevIO2024_レガシー運用からの脱却 -クラウド活用の実践事例とベストプラクティス-
jun2882
0
210
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
頼られるのが大好きな 皆さんへ - 支援相手との期待の合わせ方、突き放し方 -/For_people_who_like_to_be_relied_on
naitosatoshi
1
290
LLMアプリケーションの評価の実践と課題 ~PharmaXにおける今後の展望~
pharma_x_tech
2
160
Featured
See All Featured
Become a Pro
speakerdeck
PRO
15
4.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
23
1.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
Navigating Team Friction
lara
181
13k
Build The Right Thing And Hit Your Dates
maggiecrowley
28
2.2k
Building Applications with DynamoDB
mza
89
5.8k
Gamification - CAS2011
davidbonilla
78
4.9k
Building an army of robots
kneath
301
42k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
Fireside Chat
paigeccino
25
2.8k
Side Projects
sachag
451
42k
Automating Front-end Workflow
addyosmani
1362
200k
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