記帳チームにおけるスクラムの応用と協同作業の実践 / Application of Scrum and Collaborative Work Practices in Bookkeeping Teams

Transcript

1. 記帳チームにおける スクラムの応⽤と協同作業の実践 ogawa, wb, toma, hiromitsuuu 2024年6⽉1⽇
2. 　 本セッションで話すこと • 記帳チームでは新機能の開発を⾏なうにあたって素早い検査と適応が必 要であるためスクラムを採⽤しました • 機能が世に出て約1年半、使⽤しているユーザー数は着実に増えて定着 してきている状態です • ユーザーに使い続けてもらえるような機能を作るためにどのような取り 組みを⾏ってきたかを紹介します
3. 3 Engineer wb
 QA Engineer toma
 
 
 会計‧アドバイザーPdM hiromitsuuu
 Product Designer ogawa
 
 

4. 4 ogawa takahiro
 • freee会計エンジニア ◦ React / TypeScript ◦ Ruby on Rails • 2022/12~ freee ⼊社 ◦ 中部オフィス所属 Engineer
5. 5 wb （読みはwakabayashi）
 • freee会計QA ◦ 2020/4~ ◦ 2023年秋〜⻑野県在住 
 QA Engineer
6. 6 Toma Tomomori 
 ⼤分県 ⽣まれ 新卒として⼊社 • カスタマーサポート • カスタマーサクセス • コンテンツ企画‧運営  • プロダクトマネージャー 配属(現職)   パートナーと猫と暮らす PdM
7. 7 hiromitsuuu
 • freee会計 デザイナー • 2021/10~ freee ⼊社 • エンジニア→デザイナーキャリアのひと Designer
8. 　   開発している機能
10. 　 どのような機能か これまでの ソフト freee 新機能 違いが ⼤きい… 違いが ⼩さい！ 【仕訳の形式に慣れたユーザー向けの機能】  …使い始めやすくするステップとしての役割→はじめやすい！体験
11. 　 なぜスクラムだったのか • 以前のfreeeは会計知識がなくても使いやすい記帳機能が主だった • 仕訳での⼊⼒に慣れたユーザーが⼊⼒しやすい形は どういうものなのかを探っていく必要があった
12. 　 記帳チーム 記帳チーム toma PdM hiromitsuuu デザイナー wb QA engineers エンジニア
13. 　 記帳チームのスクラムカレンダー
14. 　 Learning Sessionでどんなことしてる？ Action！ Learning Session ⽇頃の ハテナ チームの カイゼン
15. 　 記帳チームの取組の紹介 • コンセプトが正しいかを都度チェックしていくためには開発のイテレー ションを素早くやる必要がある ◦ Agile 開発/QA • 作るものの品質を上げる必要がある ◦ 作るものの解像度を上げる（実例マッピング） • 仕訳の⼀覧登録はこれまでのエンドユーザーではなく 税理⼠さんに向けた機能であるためそこを探索していく必要があった ◦ 業務理解が必要
16. 16 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
17. 17 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
18. 　 Agile 開発/QA • PRがマージされると社内検証環境に⾃動でデプロイされる ◦ PdM、デザイナーも好きなときに検証環境で動くものを触ることが 出来る • それをトリガーにQAによりチェックされる • QAもスクラムイベントに参加しているので、受⼊条件も共有済み • 全ての実装完了を待たなくてもQAチェックを始められる • チケット単位の個別のテストとは別に実装が全部終わり機能が揃った 後のリグレッションテストも実⾏している
19. 　 Agile 開発/QA 出典: https://speakerdeck.com/nihonbuson/agile-qa-night
20. 　 なぜAgile 開発/QAなのか？ • 仕訳の⼀覧登録⽴ち上げ当初、どのようなUIや操作感ならプロの⽇々 の業務になじむか模索する必要があった • 開発がすべて終わってからQAを⾏なうスタイルではそれに追従できな いというのが⾒えていたためこのやり⽅を選んだ
21. 　 どうなったか？ • QAがスクラムイベントで同期的に状況把握/レビューに参加 プロダクトの他機能の仕様も把握しているQA視点でのレビュー • 実装前にテストケース作成 • Engはテストケースも意識しつつ実装できる（参考になったという事例も） ◦ 理想はリファインメント時にテストケースができている（テストケースも含め てリファイン）
22. 　 どうなったか？ 2 • QAからのフィードバックがリアルタイムにできている ◦ 実装後できた順にすぐにテストできるのでバグがあればすぐに知らせる ◦ QAからのバグ指摘に対し同スプリント内で修正までできた事例あり →そのスプリント内で品質担保までできた ◦ Engは記憶が新しいうちに修正できる ▪ バグのSevirity（freeeでは重篤度と呼びます）、ユースケースに準じた 発⽣頻度が⾼くないものは後のスプリントで修正し機能開発を 優先する判断をする場合もある
23. 　 どうなったか？ 3 • Engにより上流でテストされQA開始時のプロダクト品質が良くなった ◦ QA引き渡しの時点でバグが判明している事例あり ◦ QAでのバグ検出数はさほど多くない [※個⼈の感覚です] ▪ Engの品質に対する意識の⾼さの表れかも ▪ 後述の活動との相乗効果もあるかも..
24. 24 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
25. 　 なぜ解像度を上げる必要性が出てきたか • 登録系から編集系に開発フェーズが移ったとき、複雑なパターンを事前 に把握しておくことが出来ず、プロダクトの品質も悪化してスケジュー ルが爆発しかけた • 編集は登録と違ってスタート地点がたくさんあるため、分岐パターンが 複雑 • ⽂字や⾔葉だけだと理解が空中戦になり、メンバーごとにパターンの理 解にズレがあることがわかった • このリリースのふりかえりから、「実例マッピング」という⼿法を知り 実践してみた
26. 　 実例マッピング 出典: https://speakerdeck.com/nihonbuson/example-mapping?slide=3
27. 　 記帳チームで⾏った実例マッピング Story Rule Example
28. 　 記帳チームで⾏った実例マッピング Story Question Rule Example
29. 　 全体の簡易⾒積もり Story Question Rule
30. 　 どうなったか • 仕訳形式で書いてるとどういう⾒た⽬について話してるか わかりやすい • UI設計の状態パターンの認識も合うようになった • 初期⾒積もりがやりやすくなった • ピンクの付箋でリスクになりそうな部分をあらかじめ⾒れた • 各ケースごとでなく全体としての影響をあらかじめ⾒れていた • 異常系のパスも最初に⾒えていたのでスムーズに進んだ • QA視点も⼊ってプロダクトの前提知識が⼊って設計できた みんなは  どう思う？
31. 31 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解 ⽬次
32. 　 業務理解 • 業務観察 ◦ 業務を観察するための事前勉強をする ◦ ユーザーの事業所を訪問して実際の業務を⾒る（業務観察) • 情報に触れる ◦ PdMやデザイナーが⾏った訪問やインタビューの動画をチームで⾒る • ユーザーがどのように使っているの事実がわかり、業務が理解できる
33. 　 なぜ業務理解が必要？ • プロフェッショナル達が、⽇々業務で使う「道具」を開発している ◦ 要求を知らなければ開発は始まらない ◦ 業務フローとの合わなさが使いにくさに繋がる • 競合ソフトがあるなか、freeeとのコンセプトのバランスが必要 ◦ わたしたちは本質的には何が達成できればいい？ • 何が出来ればいいのか知らなければ「機能要望」しか⾒えなくなる ◦ 限られたリソースを効果的な部分に投資できない
34. 　 ソフトウェアは、業務の道具
35. 　 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 書籍で知れるような業務の⼀般知識 調べにくさ 難しい やさしい
36. 　 どこの情報を⾃分たちは知らないのか？ 業務達成のためのソフトウェアの細かな操作 ユーザーの業務プロセスや⾏動‧⼯夫 会社毎の慣習や独⾃の⼯夫‧ルール 業界‧地⽅の慣習 書籍で知れるような業務の⼀般知識 調べにくさ 難しい やさしい ここを ⾒に⾏く！
37. 　 業務を観察するイメージ • 普段業務を⾏っているデスクの近くに お邪魔する • ⾒せていただきたい業務を再確認する • 普段通り業務を進めてもらって黙って ⾒る • ひとかたまりの業務を⾒せていただい た後に、気になる⾏動などをインタ ビューする
38. 　 どうなったか • ユーザーや業務に対する解像度が段違い ◦ 実際に会計事務所へ訪問し、使われかたを⽬の前で⾒る効果 ◦ PdMとデザイナーからも、情報が補強される • ユーザーのことを考えながら開発できる ◦ 仕様の背景の理解が早くなる ◦ 「ユーザーの業務を⽌めない」指針の腹落ち • 会話のレベル、アウトプットが⾼度になり、プロダクト品質がよくなっ た ◦ エンジニアからも、よりよいアイデアが⽣まれる みんなは どうだった？
39. 　 もっと知りたい⼈はこちら スクフェス⼤阪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
40. 　 さいごに
41. 発表と準備を通して、い ろいろ学びを重ねてきた ことを再確認できまし た！
 41 Engineer 学びや工夫の積み重ね がチームの進化を支えて いるなあと実感しまし た！
 wb
 QA Engineer toma
 PdM ここまで長い道のりでし た。着実にチームは変化 してきてると思います！ やっていき。
 hiromitsuuu
 Product Designer ogawa
 
 
 進化し続けられるチーム であるために、学び続け る姿勢が大事だなと再確 認できました！