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
記帳チームにおけるスクラムの応用と協同作業の実践 / Application of Scrum...
Search
freee
June 06, 2024
1
2.2k
記帳チームにおけるスクラムの応用と協同作業の実践 / Application of Scrum and Collaborative Work Practices in Bookkeeping Teams
freee
June 06, 2024
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.2k
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.3k
国籍と専門性を超えてのコラボレーション / 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
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
425
64k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
109
6.9k
Building Applications with DynamoDB
mza
90
6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
158
15k
Faster Mobile Websites
deanohume
304
30k
The Pragmatic Product Professional
lauravandoore
31
6.2k
4 Signs Your Business is Dying
shpigford
180
21k
Designing with Data
zakiwarfel
98
5.1k
Docker and Python
trallard
40
3k
Code Review Best Practice
trishagee
62
16k
Six Lessons from altMBA
skipperchong
26
3.4k
Optimizing for Happiness
mojombo
375
69k
Transcript
記帳チームにおける スクラムの応⽤と協同作業の実践 ogawa, wb, toma, hiromitsuuu 2024年6⽉1⽇
本セッションで話すこと • 記帳チームでは新機能の開発を⾏なうにあたって素早い検査と適応が必 要であるためスクラムを採⽤しました • 機能が世に出て約1年半、使⽤しているユーザー数は着実に増えて定着 してきている状態です • ユーザーに使い続けてもらえるような機能を作るためにどのような取り
組みを⾏ってきたかを紹介します
3 Engineer wb QA Engineer toma 会計‧アドバイザーPdM hiromitsuuu
Product Designer ogawa
4 ogawa takahiro • freee会計エンジニア ◦ React / TypeScript ◦
Ruby on Rails • 2022/12~ freee ⼊社 ◦ 中部オフィス所属 Engineer
5 wb (読みはwakabayashi) • freee会計QA ◦ 2020/4~ ◦ 2023年秋〜⻑野県在住
QA Engineer
6 Toma Tomomori ⼤分県 ⽣まれ 新卒として⼊社 • カスタマーサポート •
カスタマーサクセス • コンテンツ企画‧運営 • プロダクトマネージャー 配属(現職) パートナーと猫と暮らす PdM
7 hiromitsuuu • freee会計 デザイナー • 2021/10~ freee ⼊社 •
エンジニア→デザイナーキャリアのひと Designer
開発している機能
None
どのような機能か これまでの ソフト freee 新機能 違いが ⼤きい… 違いが ⼩さい!
【仕訳の形式に慣れたユーザー向けの機能】 …使い始めやすくするステップとしての役割→はじめやすい!体験
なぜスクラムだったのか • 以前のfreeeは会計知識がなくても使いやすい記帳機能が主だった • 仕訳での⼊⼒に慣れたユーザーが⼊⼒しやすい形は どういうものなのかを探っていく必要があった
記帳チーム 記帳チーム toma PdM hiromitsuuu デザイナー wb QA engineers
エンジニア
記帳チームのスクラムカレンダー
Learning Sessionでどんなことしてる? Action! Learning Session ⽇頃の ハテナ チームの カイゼン
記帳チームの取組の紹介 • コンセプトが正しいかを都度チェックしていくためには開発のイテレー ションを素早くやる必要がある ◦ Agile 開発/QA • 作るものの品質を上げる必要がある
◦ 作るものの解像度を上げる(実例マッピング) • 仕訳の⼀覧登録はこれまでのエンドユーザーではなく 税理⼠さんに向けた機能であるためそこを探索していく必要があった ◦ 業務理解が必要
16 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
17 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
Agile 開発/QA • PRがマージされると社内検証環境に⾃動でデプロイされる ◦ PdM、デザイナーも好きなときに検証環境で動くものを触ることが 出来る • それをトリガーにQAによりチェックされる
• QAもスクラムイベントに参加しているので、受⼊条件も共有済み • 全ての実装完了を待たなくてもQAチェックを始められる • チケット単位の個別のテストとは別に実装が全部終わり機能が揃った 後のリグレッションテストも実⾏している
Agile 開発/QA 出典: https://speakerdeck.com/nihonbuson/agile-qa-night
なぜAgile 開発/QAなのか? • 仕訳の⼀覧登録⽴ち上げ当初、どのようなUIや操作感ならプロの⽇々 の業務になじむか模索する必要があった • 開発がすべて終わってからQAを⾏なうスタイルではそれに追従できな いというのが⾒えていたためこのやり⽅を選んだ
どうなったか? • QAがスクラムイベントで同期的に状況把握/レビューに参加 プロダクトの他機能の仕様も把握しているQA視点でのレビュー • 実装前にテストケース作成 • Engはテストケースも意識しつつ実装できる(参考になったという事例も) ◦
理想はリファインメント時にテストケースができている(テストケースも含め てリファイン)
どうなったか? 2 • QAからのフィードバックがリアルタイムにできている ◦ 実装後できた順にすぐにテストできるのでバグがあればすぐに知らせる ◦ QAからのバグ指摘に対し同スプリント内で修正までできた事例あり →そのスプリント内で品質担保までできた ◦
Engは記憶が新しいうちに修正できる ▪ バグのSevirity(freeeでは重篤度と呼びます)、ユースケースに準じた 発⽣頻度が⾼くないものは後のスプリントで修正し機能開発を 優先する判断をする場合もある
どうなったか? 3 • Engにより上流でテストされQA開始時のプロダクト品質が良くなった ◦ QA引き渡しの時点でバグが判明している事例あり ◦ QAでのバグ検出数はさほど多くない [※個⼈の感覚です] ▪
Engの品質に対する意識の⾼さの表れかも ▪ 後述の活動との相乗効果もあるかも..
24 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
なぜ解像度を上げる必要性が出てきたか • 登録系から編集系に開発フェーズが移ったとき、複雑なパターンを事前 に把握しておくことが出来ず、プロダクトの品質も悪化してスケジュー ルが爆発しかけた • 編集は登録と違ってスタート地点がたくさんあるため、分岐パターンが 複雑 •
⽂字や⾔葉だけだと理解が空中戦になり、メンバーごとにパターンの理 解にズレがあることがわかった • このリリースのふりかえりから、「実例マッピング」という⼿法を知り 実践してみた
実例マッピング 出典: https://speakerdeck.com/nihonbuson/example-mapping?slide=3
記帳チームで⾏った実例マッピング Story Rule Example
記帳チームで⾏った実例マッピング Story Question Rule Example
全体の簡易⾒積もり Story Question Rule
どうなったか • 仕訳形式で書いてるとどういう⾒た⽬について話してるか わかりやすい • UI設計の状態パターンの認識も合うようになった • 初期⾒積もりがやりやすくなった •
ピンクの付箋でリスクになりそうな部分をあらかじめ⾒れた • 各ケースごとでなく全体としての影響をあらかじめ⾒れていた • 異常系のパスも最初に⾒えていたのでスムーズに進んだ • QA視点も⼊ってプロダクトの前提知識が⼊って設計できた みんなは どう思う?
31 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
業務理解 • 業務観察 ◦ 業務を観察するための事前勉強をする ◦ ユーザーの事業所を訪問して実際の業務を⾒る(業務観察) • 情報に触れる
◦ PdMやデザイナーが⾏った訪問やインタビューの動画をチームで⾒る • ユーザーがどのように使っているの事実がわかり、業務が理解できる
なぜ業務理解が必要? • プロフェッショナル達が、⽇々業務で使う「道具」を開発している ◦ 要求を知らなければ開発は始まらない ◦ 業務フローとの合わなさが使いにくさに繋がる • 競合ソフトがあるなか、freeeとのコンセプトのバランスが必要
◦ わたしたちは本質的には何が達成できればいい? • 何が出来ればいいのか知らなければ「機能要望」しか⾒えなくなる ◦ 限られたリソースを効果的な部分に投資できない
ソフトウェアは、業務の道具
どこの情報を⾃分たちは知らないのか? 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 書籍で知れるような業務の⼀般知識 調べにくさ 難しい やさしい
どこの情報を⾃分たちは知らないのか? 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 書籍で知れるような業務の⼀般知識 調べにくさ 難しい やさしい
ここを ⾒に⾏く!
業務を観察するイメージ • 普段業務を⾏っているデスクの近くに お邪魔する • ⾒せていただきたい業務を再確認する • 普段通り業務を進めてもらって黙って ⾒る
• ひとかたまりの業務を⾒せていただい た後に、気になる⾏動などをインタ ビューする
どうなったか • ユーザーや業務に対する解像度が段違い ◦ 実際に会計事務所へ訪問し、使われかたを⽬の前で⾒る効果 ◦ PdMとデザイナーからも、情報が補強される • ユーザーのことを考えながら開発できる
◦ 仕様の背景の理解が早くなる ◦ 「ユーザーの業務を⽌めない」指針の腹落ち • 会話のレベル、アウトプットが⾼度になり、プロダクト品質がよくなっ た ◦ エンジニアからも、よりよいアイデアが⽣まれる みんなは どうだった?
もっと知りたい⼈はこちら スクフェス⼤阪2023資料 https://speakerdeck.com/hiromitsuuuuu/how-does-a-designer-fit-in- a-scrum-team スクフェス福岡2024資料 https://speakerdeck.com/hiromitsuuuuu/what-i-want-to-provide-to- scrum-teams-when-developing-products
さいごに
発表と準備を通して、い ろいろ学びを重ねてきた ことを再確認できまし た! 41 Engineer 学びや工夫の積み重ね がチームの進化を支えて いるなあと実感しまし た!
wb QA Engineer toma PdM ここまで長い道のりでし た。着実にチームは変化 してきてると思います! やっていき。 hiromitsuuu Product Designer ogawa 進化し続けられるチーム であるために、学び続け る姿勢が大事だなと再確 認できました!
None