freeeカードUnlimitedチーム「スクラム実際どうなの？」 / freee-card-real-scrum

Transcript

1. freeeカード Unlimitedチーム 「スクラム実際どうなの？」 junPAY(Jumpei Nomura) 2023年04⽉16⽇
2. ここに円に切り抜いた画像を入れてく ださい junPAY @junpayment 2022年2⽉にfreeeにjoin。 エンジニア⼈⽣初のスクラムマスターに挑戦。 ⼦供3⼈。趣味は釣り。 freeeはAWSだけど実はGCPのほうが好き。 エンジニア/スクラムマスター
3. 　 3 クレジットカードの 仕組みを作ってます We develop a credit card system. freeeカード Unlimited
4. フルスタック‧フルサイクルな開発組織で スモールビジネスを主役にする「⾦融インフラ」を実現したい 仲間を募集しています。 カード事業エンジニア 決済事業エンジニア
5. 宣伝終わり
6. 本題
7. freeeカード Unlimited の開発チームではスクラムを取り⼊れてます ⼩さなMVP(Minimum Viable Product)を出し続けることで、事業の仮 説を検証するサイクルを加速させる⽬的でスクラムを採⽤しています。 https://productzine.jp/article/detail/5
8. スクラムチームは仮説検証プロセスに関わってる • スクラムチームの命題 ◦ ロードマップ上のfeatureをいかに細かく形にし、ビジネスサイド に対してフィードバックするか ◦ 仮説検証サイクルを素早くまわすこと で、実際どうなの？
9. 理想 事業に関わるみんなでアジリティ高くやってこうぜ！ ビジネス PdM 開発者 UXD
10. 現実 スクラムチームが関わる箇所 開発者
11. https://agilemanifesto.org/iso/ja/principles.html
12. 実際どうなの？ • スクラムチームの命題 ◦ ロードマップ上のfeatureをいかに細かく形にし、ビジネスサイド に対してフィードバックするか ◦ 仮説検証サイクルを素早くまわすこと • 割り切り ◦ 現時点で開発チームとして事業に対して価値を出すための現実的な 解としてこの形に落ち着いた ◦ いわゆる"アジャイルやスクラムの考え⽅"を局所的に適⽤している
13. コンテンツ • チームについて • MVP探索 • スクラム運⽤ • まとめ
14. チームについて
15. Scrum of Scrums Scrum of Scrums とは、複数のチームが協⼒して複雑なソリューションを実現する必要 があるときに、その連携⽅法を提供する拡張アジャイル⼿法です。 https://www.atlassian.com/ja/agile/scrum/scrum-of-scrums
16. Scrum of scrums Engineers QA Unit A Engineers QA Unit B PdM UXD Common • エンジニア,QAをまとめたユニットA/B • PdMとUXDは共有⼈員としてユニットの 外に配置 • ふんわりドメインを決めておく ◦ Aは決済,Bは請求まわりなど ◦ PdM/UXDの相談⽤
17. なぜSoS？ • 共有するコンテキストの凝縮度 ◦ 1つのプロダクトを開発するためにコンテキストを共有したメン バーが1チームに集まる必要 • 開発⼒ ◦ 実装量が⼤きいのでメンバー数もそれなりになければならない • 認知負荷 ◦ 1チームに集まると今度はコミュニケーションコストが顕著になっ たのでユニットに分けた。 • 意思決定をするリソース(PdM, UXD)の⼈数
18. MVP探索
19. MVP探索 ここらへんの話
20. MVP探索 関わってるのはココ
21. 事業戦略→ロードマップ→MVP構想→PRD • スクラムチームが関わるのはMVPを探索する箇所から ◦ ロードマップには⼤きな施策単位のアイテムがざっくり置かれる • ロードマップ、事業戦略をMVP構想として具現化したものがPdMより スクラムチームにインプットされる • MVP構想をスクラムチーム(のうちリードエンジニアやその部分に知 ⾒のあるメンバー)、PdM、UXDと揉んで、実現⽅法や⼤きめのPBI(+ ⾒積もり)としてアウトプット • それらによって構想とロードマップにフィードバックする • 上記がだいたい固まってきたらPdM、UXDがPRD(Product requirements document)を作成してスクラムチームにインプットす る(あるいはPRDが先に出てたりする）
22. PRD→Design Doc→PBI • PRD(Product requirements document) ◦ ユースケースを1Epicとし、そのEpicにユーザーストーリーがまと められたドキュメント ◦ このユーザーストーリーは粗めの粒度 • DD(Design document) ◦ PRDに書かれたユーザーストーリーをシステム的にどう実現するの かということがまとめられたもの ◦ 現在システムとの差分(≒詳細設計) ◦ PRDのユーザーストーリー単位を実装単位と合わせることによっ て、ビジネスとプロダクト開発の認識の単位を合わせる • PBI(Product backlog item) ◦ この時点でざっくりStory pointを⾒積もっておく
23. PBI→逆算 • 開発アイテムがロードマップにちゃんとハマってるかの検証をする活動 • ⼤きい粒度のPBIをスプリントごとに、順番に並べてみて眺める⾏為 • ただ優先順に並べるだけではなくてストーリーを考えて嵌め込む • 前段のStory pointとベロシティを使って嵌め込む 逆算の例
24. 各アウトプットの相互フィードバック ロードマップ PRD 見積もり PBI Design Doc 事業戦略
25. スクラム運用
26. スクラム運⽤ ここらへんの話
27. スクラムイベント • 1week, 1sprint • ⽕曜 ◦ スプリントレビュー ◦ ふりかえり ◦ プランニング ◦ Learning Session(※) • 毎⽇ ◦ デイリースクラム ◦ 横断デイリースクラム ◦ リファインメント(※)
28. モノをつくる活動/チームの成⻑ スプリントレ ビュー プランニング スプリント タスク FB 活動 リファインメ ント ふりかえり PBI SBL 活動 インクリメント カイゼン 成長 Learning Session PRD
29. イベント共通の取り組み • スクラムマスター以外のメンバーがファシリテートする ◦ ファシリテーション≠進⾏ ▪ 進⾏＝会議体を成⽴させるだけ ▪ ファシリテーション ＝会議の⽬的を達成させる⼈ ◦ Weeklyイベントは隔週交代 ◦ Dailyイベントは毎⽇交代 • イベントの最後に5fingersと感想記⼊ ◦ イベントそのもののカイゼン • 物理参加 • たまーに夜は飲み会
30. スプリントレビュー • 45min • デモ ◦ ステークホルダーにFBを受ける • プロダクトゴールに対する進捗の確認 ◦ ロードマップ,逆算 • UndoeやFBの整理 ◦ リファインメント ◦ 前倒しでプランニング
31. ふりかえり • 45min • 「タイムラインのハピネスレーダー」+「Fun/Done/Learn」 ◦ 毎⽇のいろんな出来事を記録しておく ◦ 直感なども織り交ぜてその時にどう思ったかをタグづけする • ⽬的 ◦ タグづけするのは単なる話のネタ ◦ メンバーがどういう考え⽅をしてるのかなんとなく知ることと ◦ ネクストアクションを出すこと ▪ 別に出さなくても良い ◦ ちょっとしたアイスブレーキング • KPTやシンプルなFun/Done/Learnとか試した ◦ 短い時間でTまで出すのは厳しい ◦ 1sprintの出来事を忘れてしまう ◦ KPTとかは形式ばっててなんかやりにくかった • コントロールチャート ◦ in progress, in reviewとかの滞留時間を眺めて会話
32. コントロールチャート
33. プランニング • 60min • キャパシティを出してみる ◦ スクラムのユニットがゴールに対して使える時間 ◦ 前回,前々回とかと⽐較し「今回ぼくらはきついのか?」 • ベロシティとキャパシティとタスクを並べてパズルする • エンジニアがスプリントでやることを決める ◦ スプリントゴール ▪ ロードマップに載ってるものが対象 ◦ スプリントゴール以外のタスク • QAがやることを決める ◦ アジャイルQA→
34. アジャイルQA • 「作り終わったらQA」じゃない • 開発とQAが同時に⾏われる • エンジニアとQAが協⼒して達成するゴール • ex) ◦ スプリント1でQA準備と開発を⾏う ◦ スプリント2でQA実施 • プランニングのQAゴール ◦ QA準備やリリースreadyに向けたテスト実施が設定される
35. デイリースクラム • 15min ◦ スプリントの進捗確認&障害検知する&⼀緒に仕事してる感を醸し 出す場所 ◦ 体調や休みの予定、とりとめもないことを会話 • 昨⽇あったこととかを書く → ふりかえりで使う • 進捗確認 • チケット移動 ◦ JIRA上でコントロールチャートを使うので正確にする • 共有,相談困りごと(アラカルト) • 横断デイリーで会話したいことを挙げる
36. 横断デイリースクラム • 10min ◦ Scrum of scrumsのイベント ◦ 各ユニットの情報をマージする場所 • リリースのスケジュールの確認 • 簡単なスプリントゴールの進捗の報告 • A,Bどちらにも属さないちょっとしたタスクの割り振り
37. リファインメント • 毎⽇30min ◦ PBIやDesign docをネタにスプリントに投⼊できるように解像度あげる活動 ◦ ちりつも、リファインメント貯⾦ • コンテンツ ◦ 詳細設計のレビュー ▪ 担当のエンジニアが設計して解像度を⼀度⾼めて他メンバーに伝播させるスタイル ◦ プランニングポーカー/乖離の発⾒ • 分割のしかた ◦ 縦の分割(ストーリーを分ける) ◦ 横の分割(タスクに分ける) ◦ 機能要件と⾮機能要件を分ける ▪ 共通部分とユーザーストーリーに分ける • ⾮機能要件を作り込むスプリントもたまにある ◦ ex) ▪ 共通部分はモデルとかDBスキーマとか ▪ ユーザーストーリーはそれらを利⽤するビジネスロジック層(usecase的な層)
38. 検証したい単位 VS エンジニアが作業しやすい単位 user story PBI 検証した い単位 フロント実 装 バックエ ンド実装 データ ベース フロント実 装 バックエ ンド実装 データ ベース
39. 変遷の話 • 最初は10⼈くらいでスクラム ◦ プロダクトの成⻑に合わせて⼈員増加したが、コミュニケーション コストが顕著となった。 • LeSS ◦ コミュニケーションコストを抑えるがチームの⼀体感は残したいと いう⽬的から選択。 ◦ 上⼿くハマればよかったが全ユニットのマージ部分で苦戦。 • SoS ◦ 前段で⼀体感を醸成できたので、この形になってもコミュニーケー ションが断絶することは無かった。
40. Less(Large scale scrum)
41. チームの健康状態 https://note.com/konta_k/n/nef5db5f0158b • 少なくとも無関⼼ゾーンには居ない状態。 • チームが成⻑するほどコンフォートゾーン への引⼒が強くなる。 • ストレッチ、勝率50%を念頭に置き、チー ムがラーニングゾーンに居続けられるよう にする。 • ラーニングゾーンと不安ゾーンを⾏ったり 来たりするくらいがいいかも。
42. 勝率50% もしこの達成率が80%や90%となった場合、何かしらのバッファを含めた ゴール設定となっている可能性があり、ジェームス‧コプリエン⽒は『こ れはチートだ！』と仰っていました。またパーキンソンの法則にあるよう に、バッファは常に使い切ってしまうというフォースが働きます。 https://dev.classmethod.jp/articles/the-essence-of-scrum-that-i-want-to-explain-to-customers/#toc-6 Sprint_1 Sprint_2 Sprint_3 Sprint_4
43. まとめ • スクラムはアジャイル開発するための「軽量のフレームワーク」とい いつつ「まあまあやること多いよね」 • (phase1としては)「事業戦略やロードマップなどビジネスサイドも巻 き込む」というところまでは踏み込めてはない • プロダクトへの貢献、チームの成⻑という２軸で頑張っていきますよ
44. フルスタック‧フルサイクルな開発組織で スモールビジネスを主役にする「⾦融インフラ」を実現したい 仲間を募集しています。 カード事業エンジニア 決済事業エンジニア