datatech-jpのCasual Talks#4での発表資料です。

1. 2022/12/12
タイミーのデータ基盤チーム(DRE)における
ユーザーストーリー導入
@marufeuille
datatech-jp Casual Talks #4

2. 石井 正浩 / @marufeuille
株式会社タイミー
データ統括部 DRE
タイミーには8月に正社員として入社
データ基盤の開発・運用やってます

5. なぜスクラムをするのか？
スクラムを導入するチームには色々な理由がある
- 開発の速度をあげたい
- 不確実性が高いものに対して、変更を反映させやすい
- 経験的に見積もりをすることで、最終的には工数が比較的正確に見積もれる
- 流行ってる

6. なぜタイミーのDREチームがスクラムをするのか
ユーザーに使われるものを作りたいから

7. タスク: ダッシュボードの障害に気づくための通知を入れる
例

8. タスク: ダッシュボードの障害に気づくための通知を入れる
これだとわからないこと
- 誰が気づくための通知か？
- どのダッシュボードか？
- どの障害に気づけばよいのか？
- なぜこれをやりたいのか？
- 結局何を作れば終わりなのか？
など
=> これをユーザーストーリーとして言語化することにした
例

9. ユーザーストーリーの例
ユーザーストーリー = 提供するユーザーの価値にフォーカスをして、検証したい要求事項を整理したもの

10. 書くだけだとおこる問題
https://www.slideshare.net/jeffpatton/user-story-mapping-discovery-the-whole-story より

11. 重要なこと
https://www.slideshare.net/jeffpatton/user-story-mapping-discovery-the-whole-story より
やりたいことを
まとめておく
プロダクト責任者/
開発者でガッツリ議論す
る
何をもって完了
かを握る

12. ストーリーを入れて開発者としてよかったこと
1. 開発者間の目線が統一され開発フェーズでの議論がしやすくなった
2. 開発者間の目線が統一され開発フェーズでの議論がしやすくなった
3. プロダクト責任者との役割分担が進んだ
課題感: 解釈に差がでて作るものの想定に差が出がちだった
どうなったか: 認識の差分が減り、 1つあたりの議論に費やす時間が減った
課題感: タスクの枝葉までプロダクト責任者に確認しないといけなかった
どうなったか: ストーリーレベルで認識が揃っているので、開発者だけでタスクレベルの議論が進められる
課題感: プロダクト責任者が本来やるべき業務に時間を回せない
どうなったか: プロダクト責任者が見る範囲が適正化され、本来の業務に回せる時間が増えた
(ように見える)

13. ユーザーストーリーを導入することで、
自己組織化された開発チームに一歩近づいた
(と思う)

14. DREチームのバイブル
https://www.oreilly.co.jp/books/9784873117324/

15. もしこの発表を見てタイミーに興味を持った方がいればこちらをご覧ください！
Timee Product Org Entrance Book
https://timee.notion.site/timee/Timee-Product-Org-Entrance-Book-b7380eb4f6954e29b2664fe6f5e775f9

16. https://tech.timee.co.jp/entry/2022/01/24/113000
https://speakerdeck.com/ttccddtoki/datatech-jp-casual-talks-number-3
その他、開発状況について知りたい方向け

17. Thank you