datatech-jp Casual Talks #3

Transcript

1. 2022/07/27　土川 稔生 DREチームのスクラム運用 @tvtg_24 1 datatech-jp Casual Talks #3
2. 目次 • 自己紹介 • タイミーのデータチーム • スクラム運用 2
3. 土川 稔生 (Tsuchikawa Toshiki) • 愛知県出身 • 2020年 東工大情報理工学院卒 • 株式会社タイミー ◦ DRE (Data Reliability Engineering) チーム ◦ データ基盤の開発・保守・運用 ◦ 分析基盤の開発・保守・運用 • Twitter @tvtg_24 3 自己紹介
6. 1 データチームについて 6
7. データ統括部組織図 データ統括部 BIチーム DSチーム DREチーム 現在3人！！
8. 8 最近のデータ基盤
9. 2 スクラムイベント 9
10. 10 DREチーム運用全般 💡 Notionでのチーム運用 • 基本的に全てのデータを Notionに集約 ◦ ロードマップ、データ基盤の概要、スクラムイベ ント、議事録など • 全社的にNotionが使用されているので、ステークホル ダー含め、様々な人が DREの運用の様子を把握 • チーム内に閉じる情報などでバージョン管理したいも のなどに関しては Githubを使用 ◦ 開発のルール、監視のルールなど
11. 11 スクラムとは 市谷 聡啓,新井 剛. 「カイゼン・ジャーニー たった1人からはじめ て、「越境」するチームをつくるまで」より引用
12. 12 DREチームのスクラムイベント (1週間スプリント) 💡 スプリントプランニング (毎週金曜 16:45 - 18:00) • スプリントの起点。スプリントの目標を定義し、プロ ダクトバックログアイテムからスプリントバックログを 作成し、優先度をつけ、見積もりを行うことで計画を 立てる。 (後に詳しく) • タスクをどう実行するかはなるべく別機会に話す か、タスク実行者に任せるようにする 💡 デイリーミーティング (毎日 17:00 - 17:15) • タスクを進める上での悩み共有 • バックログのリファインメント • 着手中のタスクの進捗確認 • 次のデイリーまでにやるタスクの確認 💡 レトロスペクティブ (毎週金曜 16:00 - 16:45) • スプリント中に感じた「チームの動きに関する振り返 り」をし、チームの動きを最適化する • チームの動きに関係ない技術的な改善などについ てはなるべく別の機会に行う 💡 スプリントレビュー ? (毎月末金曜 13:00 - 14:00) • スプリントの成果物、次の月にやっていくことなどを ステークホルダと共有し、フィードバックをもらうこと でチームの開発方針を確認する
13. 13 スプリントプランニング 💡 スプリントプランミーティングアジェンダ (75min) • 目標ストーリーポイントの設定 (10min) ◦ メンバーの休み事情や、過去のストーリーポイント消 化量を踏まえながら目標を設定 • 優先度が高いタスクをスプリントバックログへ (15min) ◦ チームの中でプロダクトバックログの優先度を最終 チェックし、スプリントバックログに移動 • スプリントバックログの優先度付、ポイント付 (35min) ◦ スプリントバックログ内での優先度をつけた後、上か ら一つづつ完了条件を確認しながらプランニング ポーカーでストーリーポイントをつける ◦ ポイントが見積もりづらい不確実要素が多いアイテム に関しては不確実性ラベルで評価する • スプリントバックログ最終調整 (5min) ◦ ポイント数がはみ出したり、足りなかったりしたらアイ テムを増やしたりして調整
14. 14 レトロスペクティブ 💡 レトロスペクティブ (45min) • ストーリーポイントの差分修正 (5min) ◦ 見積もりポイントと、実際アイテムを消化した際 の差分をここで修正 • 割り込みタスクの振り返り (5min) ◦ 割り込みタスクを全ストーリーポイントの何割に するとDREチームもステークホルダーも都合が 良さそうかを計測し話し合う • ストーリーポイント消化量の推移確認 (5min) ◦ チームがどのくらいの消化ができたかを話し合 い、過去分と照らし合わせることでチーム生産 性を計測 • スプリントの振り返り (25min) ◦ 左図の各項目に合わせてチームの動き方 + α に関する振り返りをする ◦ • チーム改善タスクの作成 (5min) ◦ 上記の振り返りでネクストアクションが生まれ たらチーム改善タスクとしてプロダクトバックロ グに追加する
15. 15 チーム改善から生まれた良さそうな施策 • 不確実性ラベルの運用 ◦ ストーリーポイントの見積もりがしづらいアイテムを実行した際にポイントが膨らみすぎたりすることでスプリン ト目標が達成できなくなる課題から生まれた ◦ 不確実性ラベルが大きいアイテムは積極的にデイリーで確認し、できるだけ細かくアイテムを切り、見積もりを 再度したりすることで目標を達成しやすくなった • ペアプロ ◦ 新メンバーjoinの際に積極的に取り入れることで、文章で伝え漏れている設計思想、コーディング規約などの 統一を目指す ◦ 一時的にチームとしてのポイント消化量は減少するが、チームメンバーのスタックが揃い、チームとしてスプリ ントをこなしやすくなった • 1日開発デー ◦ 連続してやれば早く終わりそうかつ、１日で終わるくらいのタスクをチームメンバーで実行する ◦ オフサイトでペアプロ的に進めることで、非日常感を味わいつつ楽しく開発ができている (個人の感想) • インセプションデッキの実施 ◦ DREチームとデータ統括部全体との役割などを定義、合意することでステークホルダーとの関わり方などに迷 わなくなることを期待 ◦ まだ一部のチーム間でしかできてないがチーム内でもやって良さそうと思っている
16. 16 まとめと課題 💡 まとめ • スプリントを短めにして実行することでかなりの改善が回せてこれた • notionで全部運用できていてすごい便利 💡 課題 • ユーザーストーリーの概念を取り入れれてない ◦ 現状ストーリーポイント消化量がチームベロシティみたいな数値になっている ◦ 本来ならステークホルダーへの価値の基準だったはず ◦ データ基盤チームのユーザーストーリー定義が難しい ... • チームのベロシティが変化した理由が追いづらい ◦ どんな施策が寄与してストーリーポイント消化量が変化したのかがいまいち分かりにくい ◦ 4keysなどと合わせて確認したり ...? 他の会社さんのデータに関わるチーム運用について議論したいです ! ぜひ懇親会やmeetyで!
17. 17 さいごに https://meety.net/matches/mEJpInxGNfUY
 https://www.wantedly.com/projects/579810