Slide 1
Slide 1 text
DevLove関西 FearlessChange実践編
SREチームにおけるスクラムの実践
株式会社はてな SRE
id:hokkai7go
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
はてなSREチームか
ら来ました
Slide 4
Slide 4 text
突撃！隣のDevOps
で紹介されました
https://dev.classmethod.jp/devops/dev-ops-hatena/
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
今日話すことは既にブ
ログ記事化済み
SREチームにおけるスクラムの実践
https://blog.hokkai7go.jp/entry/devlove-kansai-sre-scrum
Slide 7
Slide 7 text
概要
我々SREは日々割り込みを処理しつつ、技術的負債の返済や新し
い仕組みの導入といった予定されたエンジニアリングタスクにも取
り組んでいます。プロダクトオーナー兼スクラムマスターの上長か
らスクラムマスターを引き継いだときから現在に至るまでに取り組
んだこととチームの変化についてお話します。
Slide 8
Slide 8 text
チーム
● 人数数えるのに片手以上必要な大きなチーム
● インフラ構築から、SREのいないチームの運用までを担
当し、SREのいないチームでこぼれたものを拾う役割も
ある。基盤となるソフトウェアやミドルウェアの面倒を見
ているチーム
Slide 9
Slide 9 text
チーム
● 機能横断的かと言われると、SREに寄りすぎている組織
ではある
Slide 10
Slide 10 text
チームでのスクラム
● スプリントは2週間、スプリントレビューはできていない
● チームが見ているスプリントバックログと、POとチーム
で見ているプロダクトバックログがある。
Slide 11
Slide 11 text
チームでのスクラム
● 昼にデイリースクラムをやっている
● 東京と京都両方にメンバーがいるので、コミュニケー
ションは基本的にオンライン（Slack, GitHub projects,
Hangout meet)
● 振り返りもオンラインでKPT→YWT→KPTと変化
Slide 12
Slide 12 text
チームでのスクラム
● プロダクトを持っているチームと違って、横断的に全
チームが使うソフトウェア/インフラを提供するためのリ
ポジトリがたくさんある状態
Slide 13
Slide 13 text
チームでのスクラム
● インクリメンタルな仕事以外、つまり割り込みについては見積もりを付けず
に管理している。計画可能なインクリメンタルな仕事についてはプロダクト
オーナーがプロダクトバックログに登録し、チームがタスクの分解、見積も
り、といったプロセスを関係者で経てからタスク着手としている。
● ストーリーポイントにはフィボナッチ数を使っている
Slide 14
Slide 14 text
スクラムマスターを引
き継ぐ
Slide 15
Slide 15 text
スクラムマスターを引き継ぐ
● プロダクトオーナー兼スクラムマスターの上長からスク
ラムマスターを引き継ぐ
● 前職で開発チームの一員(インフラ担当)として働いてい
たときにスクラムを初めて体験した
● スクラムマスターについてはPOとの対話という点にお
いて大変そうだなとしか思っていなかった
Slide 16
Slide 16 text
スクラムマスターを引き継ぐ
● エンジニアリングに集中するものの、マネジメントにも興
味があるということで入社した。スクラムマスターやりま
せんかという打診を上長からされて、2019/2にスクラム
マスターになった
● 正式な推進担当者(29)
Slide 17
Slide 17 text
(昔話)スクラム導入時の話
● id:hokkai7go入社前(入社後にはすでにスクラム始まってた
● プロダクトオーナー曰く、スクラム始める前には、割り込みが多すぎてまじ
で何もできんって状況だった
● 少しでも前進したということを確認しようという意味でスクラムを導入した
Slide 18
Slide 18 text
ここからはスクラムマ
スターになってから取
り組んだこと
Slide 19
Slide 19 text
チームのスクラムの知識ベースを揃えた
● メンバーによってスクラムについての知識、経験がバラバラだったので、ス
クラムブートキャンプ本を読んでもらい全員が読み終わるのを見届けた
● 外部のお墨付き(12)
Slide 20
Slide 20 text
スクラムマスターになってすぐ直面した問題1
● チームがまだスクラムに慣れてない頃、スプリントバックログアイテム着手
時の違和感をプロダクトオーナーではなくスクラムマスターに伝えられた
り、プロダクトオーナーとの対立の原因となりうる捉え方をされてしまった
Slide 21
Slide 21 text
スクラムマスターになってすぐ直面した問題1
● スクラムマスターとしてはサポートするが、プロダクトオーナーとの直接の
会話でのみ解決されることを伝えた。また対立するのではなく協調して働く
必要性を伝えた。対立の原因については、タスク分解のタイミングまたは
バックログリファインメント、デイリースクラム等で違和感を共有して解決ま
でもっていけるように促した
Slide 22
Slide 22 text
スクラムマスターになってすぐ直面した問題2
● タスク間の重複がないため、昼会(デイリースクラム)が意味のないものに
なりかけていた
○ 昼会についての改善はたくさんやっているので後ほど話します
Slide 23
Slide 23 text
最近直面した問題
● 急に思いつきのように昼会の一部変えようとしたら抵抗された話
○ 課題感の共有なしにふわっとした提案だけしてしまった
○ 「つまり何が良くなるの？」(＝効果測定してほしい) という反応が来た
○ 学んだこと: 提案には背景(の考え)を添える、振り返りなど課題に向き
合いやすい場に持っていく
○ 結果的には、振り返りの場で提案が受け入れられた
Slide 24
Slide 24 text
チーム運営の
オープン化
Slide 25
Slide 25 text
チーム運営のオープン化1
● ある日の振り返りからチーム運営についての内容が多く出るようになって
きた。POとスクラムマスターでチーム運営を考える会議をしていたが廃
止。チーム運営に関する話題はスクラムイベントで話すようにした
● これによりチームメンバーが自分たちの手で日々のプロセスを変えられる
ようになってきた。例えば昼会のアジェンダとか、スクラムイベントのアジェ
ンダとか。
Slide 26
Slide 26 text
チーム運営のオープン化2
● 最近では、自分たちの手で日々のプロセスを変えるための変更コストにも
気を使えるようになってきた。スクラムに関するドキュメントをGitHubから、
scrapboxに移したことで簡単に変更できるようになった。
● イノベーター(16)
● やってみる(17)
● みんなを巻き込む(33)
Slide 27
Slide 27 text
その他にチームとして取り組んだこと
● チームランチ開始
○ ブラウンバッグ・ミーティング(7)、何か食べながら(9)
● 割れ窓タイムの導入
○ ふりかえりの時間(5)、グループのアイデンティティ(13)、みんなを巻き込む(33)、お試し期間(47)
● 基盤開発タイムの導入
○ グループのアイデンティティ(13)、お試し期間(47)
● タスク集中タイムの導入
○ グループのアイデンティティ(13)、お試し期間(47)
● モブレビュータイムの導入
○ グループのアイデンティティ(13)、お試し期間(47)
● 合宿をしてミッションの確認
○ 場所重要(36)
● 振り返りのやり方変更 KPT→YWT→KPT
○ やってみる(17)
Slide 28
Slide 28 text
その他にチームとして取り組んだこと(昼会関連)
● 昼会(デイリースクラム)にコンディション共有追加
● 昼会(デイリースクラム)のファシリテーター持ち回り
● 昼会(デイリースクラム)にミッションの確認コーナー追加
● 昼会(デイリースクラム)で未アサインのタスク確認コーナー追加
● 昼会(デイリースクラム)にその日時点のベロシティ確認コーナー追加
(mackerelでグラフ！！)
● 昼会(デイリースクラム)で各自のタスク進捗状況確認コーナー追加、お互
いに進捗状況にツッコミを入れるようにした
Slide 29
Slide 29 text
その他にチームとして取り組んだこと(昼会関連)
Slide 30
Slide 30 text
昼会の変更をなぜ行ったのか
● コンディション共有追加
○ 振り返り時に体調不良者がそこそこいることがわかり、日々のコンディションもお互い気にしてみることに
した
● ファシリテーター持ち回り
○ スクラムマスターのファシリテーション疲れ
● ミッションの確認コーナー追加
○ ミッション作ってみたので日々意識するようにしたかった
● 未アサインのタスク確認コーナー追加
○ 割り込みタスクアサインしないと進まないことが振り返りでわかったのでその対策
● その日時点のベロシティ確認コーナー追加
○ 進捗している/前進している感じを日々味わうため
● 各自のタスク進捗状況確認コーナー追加、お互いに進捗状況にツッコミを入れるようにした
○ 進捗が異常に悪いスプリントの振り返りで出た。止まってる状態を打破するための施策
Slide 31
Slide 31 text
昼会の変更を行った結果
● メンバーそれぞれのコンディションに配慮しつつ仕事できるようになった
● スクラムマスターが楽になり、次なる改善に向かえるようになった
● ミッションを意識して仕事できるようになった
● 割り込みタスクを処理できるようになった
● ベロシティ増えてないことが検知できる
● 進捗が止まったタスクに気が付き、相互にツッコミできるようになった
Slide 32
Slide 32 text
振り返りの変更をなぜ行ったのか
● KPT→YWT→KPTと変更した
● たぶん深い理由はなくKPTで始まった
● YWTにした理由
○ 新メンバーが他の人の作業がわからないという課題があり、スプリン
トでやったことを確認したかった
○ Pばかり出てくると気が滅入ってくる
● チームの改善がまったりしたと感じたためKPTに戻した
○ Pを建設的に議論できるチーム状況になった
○ Pが出てこないとキレがない。改善のネタが出てきにくい
Slide 33
Slide 33 text
振り返りの変更を行った結果
● 他の人の作業内容がわからないことで困っていることがわかった
● Pばかり出ても建設的な議論ができるようになった（と思う
● やっぱりKPTの方が改善が進むと感じた
Slide 34
Slide 34 text
直面している課題
● チームのプロジェクト進捗が停滞するときがあり、停滞の本当の原因にたどり着けて
いるか不安がある
● 長く取り掛かっているDoingタスクが片付かないときがある
○ 他チームのプロダクトのリリースに関わる作業についてはコミュニケーションコ
ストも高いし、完了タイミングもこちらではハンドリングしきれないとか
● スプリントバックログアイテムの完了の定義が足りているのか、過剰なのかがタスク
着手後にしか温度感がわからない
Slide 35
Slide 35 text
まとめ
Slide 36
Slide 36 text
まとめ
● プロダクトオーナーいわく、改善するぞって意識がチームにできたのが一番よかった
● スクラムマスターとしてもだいぶ良いチームになったと実感がある
● 割り込みたくさんあって大変だけど、インクリメンタルにやる仕事の部分はスクラムの
エッセンスを取り入れつつやれています
● 変化をもたらすということが、スクラムマスターやプロダクトオーナー以外からも起こる
ようになってきた
● とは言え悩みもあるのでお話させてください
Slide 37
Slide 37 text
まとめ
業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。素
早く変えてもし仮にダメだったら素早く戻せばよい。
Songmu
https://developer.hatenastaff.com/entry/2018/04/04/111410
変化するには、こうした変化を受け入れる発言や態度とともに同僚、古参、上長とかからのフォロ
ワーシップつまりやっていきに対するのっていきが重要だと感じている
参考: https://speakerdeck.com/kentaro/the-secret-of-leadership-and-followership
Slide 38
Slide 38 text
各職種絶賛募集中
https://hatenacorp.jp/recruit/career/