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

by freee

Slide 1

Slide 1 text

freeeカード Unlimitedチーム「スクラム実際どうなの？」 junPAY(Jumpei Nomura) 2023年04⽉16⽇

Slide 2

Slide 2 text

ここに円に切り抜いた画像を入れてください junPAY @junpayment 2022年2⽉にfreeeにjoin。エンジニア⼈⽣初のスクラムマスターに挑戦。⼦供3⼈。趣味は釣り。 freeeはAWSだけど実はGCPのほうが好き。エンジニア/スクラムマスター

Slide 3

Slide 3 text

　 3 クレジットカードの仕組みを作ってます We develop a credit card system. freeeカード Unlimited

Slide 4

Slide 4 text

フルスタック‧フルサイクルな開発組織でスモールビジネスを主役にする「⾦融インフラ」を実現したい仲間を募集しています。カード事業エンジニア決済事業エンジニア

Slide 5

Slide 5 text

宣伝終わり

Slide 6

Slide 6 text

本題

Slide 7

Slide 7 text

freeeカード Unlimited の開発チームではスクラムを取り⼊れてます⼩さなMVP(Minimum Viable Product)を出し続けることで、事業の仮説を検証するサイクルを加速させる⽬的でスクラムを採⽤しています。 https://productzine.jp/article/detail/5

Slide 8

Slide 8 text

スクラムチームは仮説検証プロセスに関わってる ● スクラムチームの命題 ○ ロードマップ上のfeatureをいかに細かく形にし、ビジネスサイドに対してフィードバックするか ○ 仮説検証サイクルを素早くまわすことで、実際どうなの？

Slide 9

Slide 9 text

理想事業に関わるみんなでアジリティ高くやってこうぜ！ビジネス PdM 開発者 UXD

Slide 10

Slide 10 text

現実スクラムチームが関わる箇所開発者

Slide 11

Slide 11 text

https://agilemanifesto.org/iso/ja/principles.html

Slide 12

Slide 12 text

実際どうなの？ ● スクラムチームの命題 ○ ロードマップ上のfeatureをいかに細かく形にし、ビジネスサイドに対してフィードバックするか ○ 仮説検証サイクルを素早くまわすこと ● 割り切り ○ 現時点で開発チームとして事業に対して価値を出すための現実的な解としてこの形に落ち着いた ○ いわゆる"アジャイルやスクラムの考え⽅"を局所的に適⽤している

Slide 13

Slide 13 text

コンテンツ ● チームについて ● MVP探索 ● スクラム運⽤ ● まとめ

Slide 14

Slide 14 text

チームについて

Slide 15

Slide 15 text

Scrum of Scrums Scrum of Scrums とは、複数のチームが協⼒して複雑なソリューションを実現する必要があるときに、その連携⽅法を提供する拡張アジャイル⼿法です。 https://www.atlassian.com/ja/agile/scrum/scrum-of-scrums

Slide 16

Slide 16 text

Scrum of scrums Engineers QA Unit A Engineers QA Unit B PdM UXD Common ● エンジニア,QAをまとめたユニットA/B ● PdMとUXDは共有⼈員としてユニットの外に配置 ● ふんわりドメインを決めておく ○ Aは決済,Bは請求まわりなど ○ PdM/UXDの相談⽤

Slide 17

Slide 17 text

なぜSoS？ ● 共有するコンテキストの凝縮度 ○ 1つのプロダクトを開発するためにコンテキストを共有したメンバーが1チームに集まる必要 ● 開発⼒ ○ 実装量が⼤きいのでメンバー数もそれなりになければならない ● 認知負荷 ○ 1チームに集まると今度はコミュニケーションコストが顕著になったのでユニットに分けた。 ● 意思決定をするリソース(PdM, UXD)の⼈数

Slide 18

Slide 18 text

MVP探索

Slide 19

Slide 19 text

MVP探索ここらへんの話

Slide 20

Slide 20 text

MVP探索関わってるのはココ

Slide 21

Slide 21 text

事業戦略→ロードマップ→MVP構想→PRD ● スクラムチームが関わるのはMVPを探索する箇所から ○ ロードマップには⼤きな施策単位のアイテムがざっくり置かれる ● ロードマップ、事業戦略をMVP構想として具現化したものがPdMよりスクラムチームにインプットされる ● MVP構想をスクラムチーム(のうちリードエンジニアやその部分に知⾒のあるメンバー)、PdM、UXDと揉んで、実現⽅法や⼤きめのPBI(+ ⾒積もり)としてアウトプット ● それらによって構想とロードマップにフィードバックする ● 上記がだいたい固まってきたらPdM、UXDがPRD(Product requirements document)を作成してスクラムチームにインプットする(あるいはPRDが先に出てたりする）

Slide 22

Slide 22 text

PRD→Design Doc→PBI ● PRD(Product requirements document) ○ ユースケースを1Epicとし、そのEpicにユーザーストーリーがまとめられたドキュメント ○ このユーザーストーリーは粗めの粒度 ● DD(Design document) ○ PRDに書かれたユーザーストーリーをシステム的にどう実現するのかということがまとめられたもの ○ 現在システムとの差分(≒詳細設計) ○ PRDのユーザーストーリー単位を実装単位と合わせることによって、ビジネスとプロダクト開発の認識の単位を合わせる ● PBI(Product backlog item) ○ この時点でざっくりStory pointを⾒積もっておく

Slide 23

Slide 23 text

PBI→逆算 ● 開発アイテムがロードマップにちゃんとハマってるかの検証をする活動 ● ⼤きい粒度のPBIをスプリントごとに、順番に並べてみて眺める⾏為 ● ただ優先順に並べるだけではなくてストーリーを考えて嵌め込む ● 前段のStory pointとベロシティを使って嵌め込む逆算の例

Slide 24

Slide 24 text

各アウトプットの相互フィードバックロードマップ PRD 見積もり PBI Design Doc 事業戦略

Slide 25

Slide 25 text

スクラム運用

Slide 26

Slide 26 text

スクラム運⽤ここらへんの話

Slide 27

Slide 27 text

スクラムイベント ● 1week, 1sprint ● ⽕曜 ○ スプリントレビュー ○ ふりかえり ○ プランニング ○ Learning Session(※) ● 毎⽇ ○ デイリースクラム ○ 横断デイリースクラム ○ リファインメント(※)

Slide 28

Slide 28 text

モノをつくる活動/チームの成⻑スプリントレビュープランニングスプリントタスク FB 活動リファインメントふりかえり PBI SBL 活動インクリメントカイゼン成長 Learning Session PRD

Slide 29

Slide 29 text

イベント共通の取り組み ● スクラムマスター以外のメンバーがファシリテートする ○ ファシリテーション≠進⾏ ■ 進⾏＝会議体を成⽴させるだけ ■ ファシリテーション＝会議の⽬的を達成させる⼈ ○ Weeklyイベントは隔週交代 ○ Dailyイベントは毎⽇交代 ● イベントの最後に5ﬁngersと感想記⼊ ○ イベントそのもののカイゼン ● 物理参加 ● たまーに夜は飲み会

Slide 30

Slide 30 text

スプリントレビュー ● 45min ● デモ ○ ステークホルダーにFBを受ける ● プロダクトゴールに対する進捗の確認 ○ ロードマップ,逆算 ● UndoeやFBの整理 ○ リファインメント ○ 前倒しでプランニング

Slide 31

Slide 31 text

ふりかえり ● 45min ● 「タイムラインのハピネスレーダー」+「Fun/Done/Learn」 ○ 毎⽇のいろんな出来事を記録しておく ○ 直感なども織り交ぜてその時にどう思ったかをタグづけする ● ⽬的 ○ タグづけするのは単なる話のネタ ○ メンバーがどういう考え⽅をしてるのかなんとなく知ることと ○ ネクストアクションを出すこと ■ 別に出さなくても良い ○ ちょっとしたアイスブレーキング ● KPTやシンプルなFun/Done/Learnとか試した ○ 短い時間でTまで出すのは厳しい ○ 1sprintの出来事を忘れてしまう ○ KPTとかは形式ばっててなんかやりにくかった ● コントロールチャート ○ in progress, in reviewとかの滞留時間を眺めて会話

Slide 32

Slide 32 text

コントロールチャート

Slide 33

Slide 33 text

プランニング ● 60min ● キャパシティを出してみる ○ スクラムのユニットがゴールに対して使える時間 ○ 前回,前々回とかと⽐較し「今回ぼくらはきついのか?」 ● ベロシティとキャパシティとタスクを並べてパズルする ● エンジニアがスプリントでやることを決める ○ スプリントゴール ■ ロードマップに載ってるものが対象 ○ スプリントゴール以外のタスク ● QAがやることを決める ○ アジャイルQA→

Slide 34

Slide 34 text

アジャイルQA ● 「作り終わったらQA」じゃない ● 開発とQAが同時に⾏われる ● エンジニアとQAが協⼒して達成するゴール ● ex) ○ スプリント1でQA準備と開発を⾏う ○ スプリント2でQA実施 ● プランニングのQAゴール ○ QA準備やリリースreadyに向けたテスト実施が設定される

Slide 35

Slide 35 text

デイリースクラム ● 15min ○ スプリントの進捗確認&障害検知する&⼀緒に仕事してる感を醸し出す場所 ○ 体調や休みの予定、とりとめもないことを会話 ● 昨⽇あったこととかを書く → ふりかえりで使う ● 進捗確認 ● チケット移動 ○ JIRA上でコントロールチャートを使うので正確にする ● 共有,相談困りごと(アラカルト) ● 横断デイリーで会話したいことを挙げる

Slide 36

Slide 36 text

横断デイリースクラム ● 10min ○ Scrum of scrumsのイベント ○ 各ユニットの情報をマージする場所 ● リリースのスケジュールの確認 ● 簡単なスプリントゴールの進捗の報告 ● A,Bどちらにも属さないちょっとしたタスクの割り振り

Slide 37

Slide 37 text

リファインメント ● 毎⽇30min ○ PBIやDesign docをネタにスプリントに投⼊できるように解像度あげる活動 ○ ちりつも、リファインメント貯⾦ ● コンテンツ ○ 詳細設計のレビュー ■ 担当のエンジニアが設計して解像度を⼀度⾼めて他メンバーに伝播させるスタイル ○ プランニングポーカー/乖離の発⾒ ● 分割のしかた ○ 縦の分割(ストーリーを分ける) ○ 横の分割(タスクに分ける) ○ 機能要件と⾮機能要件を分ける ■ 共通部分とユーザーストーリーに分ける ● ⾮機能要件を作り込むスプリントもたまにある ○ ex) ■ 共通部分はモデルとかDBスキーマとか ■ ユーザーストーリーはそれらを利⽤するビジネスロジック層(usecase的な層)

Slide 38

Slide 38 text

検証したい単位 VS エンジニアが作業しやすい単位 user story PBI 検証したい単位フロント実装バックエンド実装データベースフロント実装バックエンド実装データベース

Slide 39

Slide 39 text

変遷の話 ● 最初は10⼈くらいでスクラム ○ プロダクトの成⻑に合わせて⼈員増加したが、コミュニケーションコストが顕著となった。 ● LeSS ○ コミュニケーションコストを抑えるがチームの⼀体感は残したいという⽬的から選択。 ○ 上⼿くハマればよかったが全ユニットのマージ部分で苦戦。 ● SoS ○ 前段で⼀体感を醸成できたので、この形になってもコミュニーケーションが断絶することは無かった。

Slide 40

Slide 40 text

Less(Large scale scrum)

Slide 41

Slide 41 text

チームの健康状態 https://note.com/konta_k/n/nef5db5f0158b ● 少なくとも無関⼼ゾーンには居ない状態。 ● チームが成⻑するほどコンフォートゾーンへの引⼒が強くなる。 ● ストレッチ、勝率50%を念頭に置き、チームがラーニングゾーンに居続けられるようにする。 ● ラーニングゾーンと不安ゾーンを⾏ったり来たりするくらいがいいかも。

Slide 42

Slide 42 text

勝率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

Slide 43

Slide 43 text

まとめ ● スクラムはアジャイル開発するための「軽量のフレームワーク」といいつつ「まあまあやること多いよね」 ● (phase1としては)「事業戦略やロードマップなどビジネスサイドも巻き込む」というところまでは踏み込めてはない ● プロダクトへの貢献、チームの成⻑という２軸で頑張っていきますよ