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

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

freee
April 20, 2023

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

freee

April 20, 2023
Tweet

More Decks by freee

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. 宣伝終わり

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  13. チームについて

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. MVP探索
    ここらへんの話

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. スクラム運用

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. コントロールチャート

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. 検証したい単位 VS エンジニアが作業しやすい単位
    user story
    PBI
    検証した
    い単位
    フロント実

    バックエ
    ンド実装
    データ
    ベース
    フロント実

    バックエ
    ンド実装
    データ
    ベース

    View full-size slide

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

    View full-size slide

  38. Less(Large scale scrum)

    View full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

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

    View full-size slide