Upgrade to Pro — share decks privately, control downloads, hide ads and more …

devlove-kansai-sre-scrum

Yutaro Sugai
October 04, 2019

 devlove-kansai-sre-scrum

Yutaro Sugai

October 04, 2019
Tweet

More Decks by Yutaro Sugai

Other Decks in Programming

Transcript

  1. DevLove関西 FearlessChange実践編
    SREチームにおけるスクラムの実践
    株式会社はてな SRE
    id:hokkai7go

    View full-size slide

  2. はてなSREチームか
    ら来ました

    View full-size slide

  3. 突撃!隣のDevOps
    で紹介されました
    https://dev.classmethod.jp/devops/dev-ops-hatena/

    View full-size slide

  4. 今日話すことは既にブ
    ログ記事化済み
    SREチームにおけるスクラムの実践
    https://blog.hokkai7go.jp/entry/devlove-kansai-sre-scrum

    View full-size slide

  5. 概要
    我々SREは日々割り込みを処理しつつ、技術的負債の返済や新し
    い仕組みの導入といった予定されたエンジニアリングタスクにも取
    り組んでいます。プロダクトオーナー兼スクラムマスターの上長か
    らスクラムマスターを引き継いだときから現在に至るまでに取り組
    んだこととチームの変化についてお話します。

    View full-size slide

  6. チーム
    ● 人数数えるのに片手以上必要な大きなチーム
    ● インフラ構築から、SREのいないチームの運用までを担
    当し、SREのいないチームでこぼれたものを拾う役割も
    ある。基盤となるソフトウェアやミドルウェアの面倒を見
    ているチーム

    View full-size slide

  7. チーム
    ● 機能横断的かと言われると、SREに寄りすぎている組織
    ではある

    View full-size slide

  8. チームでのスクラム
    ● スプリントは2週間、スプリントレビューはできていない
    ● チームが見ているスプリントバックログと、POとチーム
    で見ているプロダクトバックログがある。

    View full-size slide

  9. チームでのスクラム
    ● 昼にデイリースクラムをやっている
    ● 東京と京都両方にメンバーがいるので、コミュニケー
    ションは基本的にオンライン(Slack, GitHub projects,
    Hangout meet)
    ● 振り返りもオンラインでKPT→YWT→KPTと変化

    View full-size slide

  10. チームでのスクラム
    ● プロダクトを持っているチームと違って、横断的に全
    チームが使うソフトウェア/インフラを提供するためのリ
    ポジトリがたくさんある状態

    View full-size slide

  11. チームでのスクラム
    ● インクリメンタルな仕事以外、つまり割り込みについては見積もりを付けず
    に管理している。計画可能なインクリメンタルな仕事についてはプロダクト
    オーナーがプロダクトバックログに登録し、チームがタスクの分解、見積も
    り、といったプロセスを関係者で経てからタスク着手としている。
    ● ストーリーポイントにはフィボナッチ数を使っている

    View full-size slide

  12. スクラムマスターを引
    き継ぐ

    View full-size slide

  13. スクラムマスターを引き継ぐ
    ● プロダクトオーナー兼スクラムマスターの上長からスク
    ラムマスターを引き継ぐ
    ● 前職で開発チームの一員(インフラ担当)として働いてい
    たときにスクラムを初めて体験した
    ● スクラムマスターについてはPOとの対話という点にお
    いて大変そうだなとしか思っていなかった

    View full-size slide

  14. スクラムマスターを引き継ぐ
    ● エンジニアリングに集中するものの、マネジメントにも興
    味があるということで入社した。スクラムマスターやりま
    せんかという打診を上長からされて、2019/2にスクラム
    マスターになった
    ● 正式な推進担当者(29)

    View full-size slide

  15. (昔話)スクラム導入時の話
    ● id:hokkai7go入社前(入社後にはすでにスクラム始まってた
    ● プロダクトオーナー曰く、スクラム始める前には、割り込みが多すぎてまじ
    で何もできんって状況だった
    ● 少しでも前進したということを確認しようという意味でスクラムを導入した

    View full-size slide

  16. ここからはスクラムマ
    スターになってから取
    り組んだこと

    View full-size slide

  17. チームのスクラムの知識ベースを揃えた
    ● メンバーによってスクラムについての知識、経験がバラバラだったので、ス
    クラムブートキャンプ本を読んでもらい全員が読み終わるのを見届けた
    ● 外部のお墨付き(12)

    View full-size slide

  18. スクラムマスターになってすぐ直面した問題1
    ● チームがまだスクラムに慣れてない頃、スプリントバックログアイテム着手
    時の違和感をプロダクトオーナーではなくスクラムマスターに伝えられた
    り、プロダクトオーナーとの対立の原因となりうる捉え方をされてしまった

    View full-size slide

  19. スクラムマスターになってすぐ直面した問題1
    ● スクラムマスターとしてはサポートするが、プロダクトオーナーとの直接の
    会話でのみ解決されることを伝えた。また対立するのではなく協調して働く
    必要性を伝えた。対立の原因については、タスク分解のタイミングまたは
    バックログリファインメント、デイリースクラム等で違和感を共有して解決ま
    でもっていけるように促した

    View full-size slide

  20. スクラムマスターになってすぐ直面した問題2
    ● タスク間の重複がないため、昼会(デイリースクラム)が意味のないものに
    なりかけていた
    ○ 昼会についての改善はたくさんやっているので後ほど話します

    View full-size slide

  21. 最近直面した問題
    ● 急に思いつきのように昼会の一部変えようとしたら抵抗された話
    ○ 課題感の共有なしにふわっとした提案だけしてしまった
    ○ 「つまり何が良くなるの?」(=効果測定してほしい) という反応が来た
    ○ 学んだこと: 提案には背景(の考え)を添える、振り返りなど課題に向き
    合いやすい場に持っていく
    ○ 結果的には、振り返りの場で提案が受け入れられた

    View full-size slide

  22. チーム運営の
    オープン化

    View full-size slide

  23. チーム運営のオープン化1
    ● ある日の振り返りからチーム運営についての内容が多く出るようになって
    きた。POとスクラムマスターでチーム運営を考える会議をしていたが廃
    止。チーム運営に関する話題はスクラムイベントで話すようにした
    ● これによりチームメンバーが自分たちの手で日々のプロセスを変えられる
    ようになってきた。例えば昼会のアジェンダとか、スクラムイベントのアジェ
    ンダとか。

    View full-size slide

  24. チーム運営のオープン化2
    ● 最近では、自分たちの手で日々のプロセスを変えるための変更コストにも
    気を使えるようになってきた。スクラムに関するドキュメントをGitHubから、
    scrapboxに移したことで簡単に変更できるようになった。
    ● イノベーター(16)
    ● やってみる(17)
    ● みんなを巻き込む(33)

    View full-size slide

  25. その他にチームとして取り組んだこと
    ● チームランチ開始
    ○ ブラウンバッグ・ミーティング(7)、何か食べながら(9)
    ● 割れ窓タイムの導入
    ○ ふりかえりの時間(5)、グループのアイデンティティ(13)、みんなを巻き込む(33)、お試し期間(47)
    ● 基盤開発タイムの導入
    ○ グループのアイデンティティ(13)、お試し期間(47)
    ● タスク集中タイムの導入
    ○ グループのアイデンティティ(13)、お試し期間(47)
    ● モブレビュータイムの導入
    ○ グループのアイデンティティ(13)、お試し期間(47)
    ● 合宿をしてミッションの確認
    ○ 場所重要(36)
    ● 振り返りのやり方変更 KPT→YWT→KPT
    ○ やってみる(17)

    View full-size slide

  26. その他にチームとして取り組んだこと(昼会関連)
    ● 昼会(デイリースクラム)にコンディション共有追加
    ● 昼会(デイリースクラム)のファシリテーター持ち回り
    ● 昼会(デイリースクラム)にミッションの確認コーナー追加
    ● 昼会(デイリースクラム)で未アサインのタスク確認コーナー追加
    ● 昼会(デイリースクラム)にその日時点のベロシティ確認コーナー追加
    (mackerelでグラフ!!)
    ● 昼会(デイリースクラム)で各自のタスク進捗状況確認コーナー追加、お互
    いに進捗状況にツッコミを入れるようにした

    View full-size slide

  27. その他にチームとして取り組んだこと(昼会関連)

    View full-size slide

  28. 昼会の変更をなぜ行ったのか
    ● コンディション共有追加
    ○ 振り返り時に体調不良者がそこそこいることがわかり、日々のコンディションもお互い気にしてみることに
    した
    ● ファシリテーター持ち回り
    ○ スクラムマスターのファシリテーション疲れ
    ● ミッションの確認コーナー追加
    ○ ミッション作ってみたので日々意識するようにしたかった
    ● 未アサインのタスク確認コーナー追加
    ○ 割り込みタスクアサインしないと進まないことが振り返りでわかったのでその対策
    ● その日時点のベロシティ確認コーナー追加
    ○ 進捗している/前進している感じを日々味わうため
    ● 各自のタスク進捗状況確認コーナー追加、お互いに進捗状況にツッコミを入れるようにした
    ○ 進捗が異常に悪いスプリントの振り返りで出た。止まってる状態を打破するための施策

    View full-size slide

  29. 昼会の変更を行った結果
    ● メンバーそれぞれのコンディションに配慮しつつ仕事できるようになった
    ● スクラムマスターが楽になり、次なる改善に向かえるようになった
    ● ミッションを意識して仕事できるようになった
    ● 割り込みタスクを処理できるようになった
    ● ベロシティ増えてないことが検知できる
    ● 進捗が止まったタスクに気が付き、相互にツッコミできるようになった

    View full-size slide

  30. 振り返りの変更をなぜ行ったのか
    ● KPT→YWT→KPTと変更した
    ● たぶん深い理由はなくKPTで始まった
    ● YWTにした理由
    ○ 新メンバーが他の人の作業がわからないという課題があり、スプリン
    トでやったことを確認したかった
    ○ Pばかり出てくると気が滅入ってくる
    ● チームの改善がまったりしたと感じたためKPTに戻した
    ○ Pを建設的に議論できるチーム状況になった
    ○ Pが出てこないとキレがない。改善のネタが出てきにくい

    View full-size slide

  31. 振り返りの変更を行った結果
    ● 他の人の作業内容がわからないことで困っていることがわかった
    ● Pばかり出ても建設的な議論ができるようになった(と思う
    ● やっぱりKPTの方が改善が進むと感じた

    View full-size slide

  32. 直面している課題
    ● チームのプロジェクト進捗が停滞するときがあり、停滞の本当の原因にたどり着けて
    いるか不安がある
    ● 長く取り掛かっているDoingタスクが片付かないときがある
    ○ 他チームのプロダクトのリリースに関わる作業についてはコミュニケーションコ
    ストも高いし、完了タイミングもこちらではハンドリングしきれないとか
    ● スプリントバックログアイテムの完了の定義が足りているのか、過剰なのかがタスク
    着手後にしか温度感がわからない

    View full-size slide

  33. まとめ
    ● プロダクトオーナーいわく、改善するぞって意識がチームにできたのが一番よかった
    ● スクラムマスターとしてもだいぶ良いチームになったと実感がある
    ● 割り込みたくさんあって大変だけど、インクリメンタルにやる仕事の部分はスクラムの
    エッセンスを取り入れつつやれています
    ● 変化をもたらすということが、スクラムマスターやプロダクトオーナー以外からも起こる
    ようになってきた
    ● とは言え悩みもあるのでお話させてください

    View full-size slide

  34. まとめ
    業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。素
    早く変えてもし仮にダメだったら素早く戻せばよい。
    Songmu
    https://developer.hatenastaff.com/entry/2018/04/04/111410
    変化するには、こうした変化を受け入れる発言や態度とともに同僚、古参、上長とかからのフォロ
    ワーシップつまりやっていきに対するのっていきが重要だと感じている
    参考: https://speakerdeck.com/kentaro/the-secret-of-leadership-and-followership

    View full-size slide

  35. 各職種絶賛募集中
    https://hatenacorp.jp/recruit/career/

    View full-size slide