Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
freeeカードUnlimitedチーム「スクラム実際どうなの?」 / freee-card-...
Search
freee
April 20, 2023
Technology
0
26k
freeeカードUnlimitedチーム「スクラム実際どうなの?」 / freee-card-real-scrum
freee
April 20, 2023
Tweet
Share
More Decks by freee
See All by freee
品質の高速フィードバックへの取り組み / Commitment to Fast Quality Feedback
freee
3
790
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / Incorporating the “essence of product development” into organizational development and continuing to face uncertainty
freee
0
1.1k
LGBTQ__support_WOMEN_女性として働くということ_DEI
freee
2
420
QAエンジニア_Summer Internship説明会(26卒)
freee
0
220
権限管理基盤の開発とQAの今 / Authority Management Infrastructure Development and QA Now
freee
1
2.2k
国籍と専門性を超えてのコラボレーション / Collaboration across nationalities and specialties
freee
1
2.2k
デザインリサーチの広げ方 〜XDの姿勢・態度・思考〜 / How to Expand Design Research 〜˜XD's Attitude, Attitude, and Thinking
freee
1
2.2k
グローバルなQAエンジニア・・・ってナニ!? / Global_QA_Engineer..._What_s_that.pdf
freee
1
2.2k
ぶきっちょPMによるfreeeのカルチャーとプロダクトのつながりについて / The Connection Between Freee's Culture and Product by a Clumsy PM
freee
1
2.2k
Other Decks in Technology
See All in Technology
【shownet.conf_】持続可能な次世代Wi-Fi運用に向けて
shownet
PRO
0
260
YAPC::Hakodateの映像記録を支える技術
godan
2
100
Product Utilization of Large Language Models Starting Today
ymatsuwitter
3
800
OPENLOGI Company Profile for engineer
hr01
1
12k
【shownet.conf_】3Dアプローチで守るセキュリティ
shownet
PRO
0
280
【shownet.conf_】ShowNet伝送改めShowNet APN 2024
shownet
PRO
0
330
山手線一周のパフォーマンス改善
suzukahr
0
120
【shownet.conf_】AI技術とUX監視の応用でShowNetの基盤を支えるモニタリングシステム
shownet
PRO
0
280
Pythonを活用したLLMによる構造的データ生成の手法と実践
brainpadpr
3
230
LINEヤフー新卒採用 コーディングテスト解説 アルゴリズム問題編
lycorp_recruit_jp
0
13k
VS CodeでF1〜12キーつかってますか? / Do you use the F1-12 keys in VS Code?
74th
2
280
スクラム導入の舞台裏:QAエンジニアがスクラムマスターになるまで
bubo1201
0
130
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Testing 201, or: Great Expectations
jmmastey
38
7k
Raft: Consensus for Rubyists
vanstee
136
6.6k
The Invisible Customer
myddelton
119
13k
Designing Experiences People Love
moore
138
23k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
41
9.2k
How to name files
jennybc
77
98k
WebSockets: Embracing the real-time Web
robhawkes
59
7.3k
Faster Mobile Websites
deanohume
304
30k
Designing for humans not robots
tammielis
249
25k
Transcript
freeeカード Unlimitedチーム 「スクラム実際どうなの?」 junPAY(Jumpei Nomura) 2023年04⽉16⽇
ここに円に切り抜いた画像を入れてく ださい junPAY @junpayment 2022年2⽉にfreeeにjoin。 エンジニア⼈⽣初のスクラムマスターに挑戦。 ⼦供3⼈。趣味は釣り。 freeeはAWSだけど実はGCPのほうが好き。 エンジニア/スクラムマスター
3 クレジットカードの 仕組みを作ってます We develop a credit card system.
freeeカード Unlimited
フルスタック‧フルサイクルな開発組織で スモールビジネスを主役にする「⾦融インフラ」を実現したい 仲間を募集しています。 カード事業エンジニア 決済事業エンジニア
宣伝終わり
本題
freeeカード Unlimited の開発チームではスクラムを取り⼊れてます ⼩さなMVP(Minimum Viable Product)を出し続けることで、事業の仮 説を検証するサイクルを加速させる⽬的でスクラムを採⽤しています。 https://productzine.jp/article/detail/5
スクラムチームは仮説検証プロセスに関わってる • スクラムチームの命題 ◦ ロードマップ上のfeatureをいかに細かく形にし、ビジネスサイド に対してフィードバックするか ◦ 仮説検証サイクルを素早くまわすこと で、実際どうなの?
理想 事業に関わるみんなでアジリティ高くやってこうぜ! ビジネス PdM 開発者 UXD
現実 スクラムチームが関わる箇所 開発者
https://agilemanifesto.org/iso/ja/principles.html
実際どうなの? • スクラムチームの命題 ◦ ロードマップ上のfeatureをいかに細かく形にし、ビジネスサイド に対してフィードバックするか ◦ 仮説検証サイクルを素早くまわすこと • 割り切り
◦ 現時点で開発チームとして事業に対して価値を出すための現実的な 解としてこの形に落ち着いた ◦ いわゆる"アジャイルやスクラムの考え⽅"を局所的に適⽤している
コンテンツ • チームについて • MVP探索 • スクラム運⽤ • まとめ
チームについて
Scrum of Scrums Scrum of Scrums とは、複数のチームが協⼒して複雑なソリューションを実現する必要 があるときに、その連携⽅法を提供する拡張アジャイル⼿法です。 https://www.atlassian.com/ja/agile/scrum/scrum-of-scrums
Scrum of scrums Engineers QA Unit A Engineers QA Unit
B PdM UXD Common • エンジニア,QAをまとめたユニットA/B • PdMとUXDは共有⼈員としてユニットの 外に配置 • ふんわりドメインを決めておく ◦ Aは決済,Bは請求まわりなど ◦ PdM/UXDの相談⽤
なぜSoS? • 共有するコンテキストの凝縮度 ◦ 1つのプロダクトを開発するためにコンテキストを共有したメン バーが1チームに集まる必要 • 開発⼒ ◦ 実装量が⼤きいのでメンバー数もそれなりになければならない
• 認知負荷 ◦ 1チームに集まると今度はコミュニケーションコストが顕著になっ たのでユニットに分けた。 • 意思決定をするリソース(PdM, UXD)の⼈数
MVP探索
MVP探索 ここらへんの話
MVP探索 関わってるのはココ
事業戦略→ロードマップ→MVP構想→PRD • スクラムチームが関わるのはMVPを探索する箇所から ◦ ロードマップには⼤きな施策単位のアイテムがざっくり置かれる • ロードマップ、事業戦略をMVP構想として具現化したものがPdMより スクラムチームにインプットされる • MVP構想をスクラムチーム(のうちリードエンジニアやその部分に知
⾒のあるメンバー)、PdM、UXDと揉んで、実現⽅法や⼤きめのPBI(+ ⾒積もり)としてアウトプット • それらによって構想とロードマップにフィードバックする • 上記がだいたい固まってきたらPdM、UXDがPRD(Product requirements document)を作成してスクラムチームにインプットす る(あるいはPRDが先に出てたりする)
PRD→Design Doc→PBI • PRD(Product requirements document) ◦ ユースケースを1Epicとし、そのEpicにユーザーストーリーがまと められたドキュメント ◦
このユーザーストーリーは粗めの粒度 • DD(Design document) ◦ PRDに書かれたユーザーストーリーをシステム的にどう実現するの かということがまとめられたもの ◦ 現在システムとの差分(≒詳細設計) ◦ PRDのユーザーストーリー単位を実装単位と合わせることによっ て、ビジネスとプロダクト開発の認識の単位を合わせる • PBI(Product backlog item) ◦ この時点でざっくりStory pointを⾒積もっておく
PBI→逆算 • 開発アイテムがロードマップにちゃんとハマってるかの検証をする活動 • ⼤きい粒度のPBIをスプリントごとに、順番に並べてみて眺める⾏為 • ただ優先順に並べるだけではなくてストーリーを考えて嵌め込む • 前段のStory pointとベロシティを使って嵌め込む
逆算の例
各アウトプットの相互フィードバック ロードマップ PRD 見積もり PBI Design Doc 事業戦略
スクラム運用
スクラム運⽤ ここらへんの話
スクラムイベント • 1week, 1sprint • ⽕曜 ◦ スプリントレビュー ◦ ふりかえり
◦ プランニング ◦ Learning Session(※) • 毎⽇ ◦ デイリースクラム ◦ 横断デイリースクラム ◦ リファインメント(※)
モノをつくる活動/チームの成⻑ スプリントレ ビュー プランニング スプリント タスク FB 活動 リファインメ ント
ふりかえり PBI SBL 活動 インクリメント カイゼン 成長 Learning Session PRD
イベント共通の取り組み • スクラムマスター以外のメンバーがファシリテートする ◦ ファシリテーション≠進⾏ ▪ 進⾏=会議体を成⽴させるだけ ▪ ファシリテーション =会議の⽬的を達成させる⼈
◦ Weeklyイベントは隔週交代 ◦ Dailyイベントは毎⽇交代 • イベントの最後に5fingersと感想記⼊ ◦ イベントそのもののカイゼン • 物理参加 • たまーに夜は飲み会
スプリントレビュー • 45min • デモ ◦ ステークホルダーにFBを受ける • プロダクトゴールに対する進捗の確認 ◦
ロードマップ,逆算 • UndoeやFBの整理 ◦ リファインメント ◦ 前倒しでプランニング
ふりかえり • 45min • 「タイムラインのハピネスレーダー」+「Fun/Done/Learn」 ◦ 毎⽇のいろんな出来事を記録しておく ◦ 直感なども織り交ぜてその時にどう思ったかをタグづけする •
⽬的 ◦ タグづけするのは単なる話のネタ ◦ メンバーがどういう考え⽅をしてるのかなんとなく知ることと ◦ ネクストアクションを出すこと ▪ 別に出さなくても良い ◦ ちょっとしたアイスブレーキング • KPTやシンプルなFun/Done/Learnとか試した ◦ 短い時間でTまで出すのは厳しい ◦ 1sprintの出来事を忘れてしまう ◦ KPTとかは形式ばっててなんかやりにくかった • コントロールチャート ◦ in progress, in reviewとかの滞留時間を眺めて会話
コントロールチャート
プランニング • 60min • キャパシティを出してみる ◦ スクラムのユニットがゴールに対して使える時間 ◦ 前回,前々回とかと⽐較し「今回ぼくらはきついのか?」 •
ベロシティとキャパシティとタスクを並べてパズルする • エンジニアがスプリントでやることを決める ◦ スプリントゴール ▪ ロードマップに載ってるものが対象 ◦ スプリントゴール以外のタスク • QAがやることを決める ◦ アジャイルQA→
アジャイルQA • 「作り終わったらQA」じゃない • 開発とQAが同時に⾏われる • エンジニアとQAが協⼒して達成するゴール • ex) ◦
スプリント1でQA準備と開発を⾏う ◦ スプリント2でQA実施 • プランニングのQAゴール ◦ QA準備やリリースreadyに向けたテスト実施が設定される
デイリースクラム • 15min ◦ スプリントの進捗確認&障害検知する&⼀緒に仕事してる感を醸し 出す場所 ◦ 体調や休みの予定、とりとめもないことを会話 • 昨⽇あったこととかを書く
→ ふりかえりで使う • 進捗確認 • チケット移動 ◦ JIRA上でコントロールチャートを使うので正確にする • 共有,相談困りごと(アラカルト) • 横断デイリーで会話したいことを挙げる
横断デイリースクラム • 10min ◦ Scrum of scrumsのイベント ◦ 各ユニットの情報をマージする場所 •
リリースのスケジュールの確認 • 簡単なスプリントゴールの進捗の報告 • A,Bどちらにも属さないちょっとしたタスクの割り振り
リファインメント • 毎⽇30min ◦ PBIやDesign docをネタにスプリントに投⼊できるように解像度あげる活動 ◦ ちりつも、リファインメント貯⾦ • コンテンツ
◦ 詳細設計のレビュー ▪ 担当のエンジニアが設計して解像度を⼀度⾼めて他メンバーに伝播させるスタイル ◦ プランニングポーカー/乖離の発⾒ • 分割のしかた ◦ 縦の分割(ストーリーを分ける) ◦ 横の分割(タスクに分ける) ◦ 機能要件と⾮機能要件を分ける ▪ 共通部分とユーザーストーリーに分ける • ⾮機能要件を作り込むスプリントもたまにある ◦ ex) ▪ 共通部分はモデルとかDBスキーマとか ▪ ユーザーストーリーはそれらを利⽤するビジネスロジック層(usecase的な層)
検証したい単位 VS エンジニアが作業しやすい単位 user story PBI 検証した い単位 フロント実 装
バックエ ンド実装 データ ベース フロント実 装 バックエ ンド実装 データ ベース
変遷の話 • 最初は10⼈くらいでスクラム ◦ プロダクトの成⻑に合わせて⼈員増加したが、コミュニケーション コストが顕著となった。 • LeSS ◦ コミュニケーションコストを抑えるがチームの⼀体感は残したいと
いう⽬的から選択。 ◦ 上⼿くハマればよかったが全ユニットのマージ部分で苦戦。 • SoS ◦ 前段で⼀体感を醸成できたので、この形になってもコミュニーケー ションが断絶することは無かった。
Less(Large scale scrum)
チームの健康状態 https://note.com/konta_k/n/nef5db5f0158b • 少なくとも無関⼼ゾーンには居ない状態。 • チームが成⻑するほどコンフォートゾーン への引⼒が強くなる。 • ストレッチ、勝率50%を念頭に置き、チー ムがラーニングゾーンに居続けられるよう
にする。 • ラーニングゾーンと不安ゾーンを⾏ったり 来たりするくらいがいいかも。
勝率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
まとめ • スクラムはアジャイル開発するための「軽量のフレームワーク」とい いつつ「まあまあやること多いよね」 • (phase1としては)「事業戦略やロードマップなどビジネスサイドも巻 き込む」というところまでは踏み込めてはない • プロダクトへの貢献、チームの成⻑という2軸で頑張っていきますよ
フルスタック‧フルサイクルな開発組織で スモールビジネスを主役にする「⾦融インフラ」を実現したい 仲間を募集しています。 カード事業エンジニア 決済事業エンジニア
None