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

by freee

Slide 1

Slide 1 text

記帳チームにおけるスクラムの応⽤と協同作業の実践 ogawa, wb, toma, hiromitsuuu 2024年6⽉1⽇

Slide 2

Slide 2 text

　本セッションで話すこと ● 記帳チームでは新機能の開発を⾏なうにあたって素早い検査と適応が必要であるためスクラムを採⽤しました ● 機能が世に出て約1年半、使⽤しているユーザー数は着実に増えて定着してきている状態です ● ユーザーに使い続けてもらえるような機能を作るためにどのような取り組みを⾏ってきたかを紹介します

Slide 3

Slide 3 text

3 Engineer wb  QA Engineer toma      会計‧アドバイザーPdM hiromitsuuu  Product Designer ogawa     

Slide 4

Slide 4 text

4 ogawa takahiro  ● freee会計エンジニア ○ React / TypeScript ○ Ruby on Rails ● 2022/12~ freee ⼊社 ○ 中部オフィス所属 Engineer

Slide 5

Slide 5 text

5 wb （読みはwakabayashi）  ● freee会計QA ○ 2020/4~ ○ 2023年秋〜⻑野県在住   QA Engineer

Slide 6

Slide 6 text

6 Toma Tomomori   ⼤分県⽣まれ新卒として⼊社 ● カスタマーサポート ● カスタマーサクセス ● コンテンツ企画‧運営 ● プロダクトマネージャー配属(現職) パートナーと猫と暮らす PdM

Slide 7

Slide 7 text

7 hiromitsuuu  ● freee会計デザイナー ● 2021/10~ freee ⼊社 ● エンジニア→デザイナーキャリアのひと Designer

Slide 8

Slide 8 text

　開発している機能

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

　どのような機能かこれまでのソフト freee 新機能違いが⼤きい… 違いが⼩さい！【仕訳の形式に慣れたユーザー向けの機能】 …使い始めやすくするステップとしての役割→はじめやすい！体験

Slide 11

Slide 11 text

　なぜスクラムだったのか ● 以前のfreeeは会計知識がなくても使いやすい記帳機能が主だった ● 仕訳での⼊⼒に慣れたユーザーが⼊⼒しやすい形はどういうものなのかを探っていく必要があった

Slide 12

Slide 12 text

　記帳チーム記帳チーム toma PdM hiromitsuuu デザイナー wb QA engineers エンジニア

Slide 13

Slide 13 text

　記帳チームのスクラムカレンダー

Slide 14

Slide 14 text

　 Learning Sessionでどんなことしてる？ Action！ Learning Session ⽇頃のハテナチームのカイゼン

Slide 15

Slide 15 text

　記帳チームの取組の紹介 ● コンセプトが正しいかを都度チェックしていくためには開発のイテレーションを素早くやる必要がある ○ Agile 開発/QA ● 作るものの品質を上げる必要がある ○ 作るものの解像度を上げる（実例マッピング） ● 仕訳の⼀覧登録はこれまでのエンドユーザーではなく税理⼠さんに向けた機能であるためそこを探索していく必要があった ○ 業務理解が必要

Slide 16

Slide 16 text

16 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解⽬次

Slide 17

Slide 17 text

17 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解⽬次

Slide 18

Slide 18 text

　 Agile 開発/QA ● PRがマージされると社内検証環境に⾃動でデプロイされる ○ PdM、デザイナーも好きなときに検証環境で動くものを触ることが出来る ● それをトリガーにQAによりチェックされる ● QAもスクラムイベントに参加しているので、受⼊条件も共有済み ● 全ての実装完了を待たなくてもQAチェックを始められる ● チケット単位の個別のテストとは別に実装が全部終わり機能が揃った後のリグレッションテストも実⾏している

Slide 19

Slide 19 text

　 Agile 開発/QA 出典: https://speakerdeck.com/nihonbuson/agile-qa-night

Slide 20

Slide 20 text

　なぜAgile 開発/QAなのか？ ● 仕訳の⼀覧登録⽴ち上げ当初、どのようなUIや操作感ならプロの⽇々の業務になじむか模索する必要があった ● 開発がすべて終わってからQAを⾏なうスタイルではそれに追従できないというのが⾒えていたためこのやり⽅を選んだ

Slide 21

Slide 21 text

　どうなったか？ ● QAがスクラムイベントで同期的に状況把握/レビューに参加プロダクトの他機能の仕様も把握しているQA視点でのレビュー ● 実装前にテストケース作成 ● Engはテストケースも意識しつつ実装できる（参考になったという事例も） ○ 理想はリファインメント時にテストケースができている（テストケースも含めてリファイン）

Slide 22

Slide 22 text

　どうなったか？ 2 ● QAからのフィードバックがリアルタイムにできている ○ 実装後できた順にすぐにテストできるのでバグがあればすぐに知らせる ○ QAからのバグ指摘に対し同スプリント内で修正までできた事例あり →そのスプリント内で品質担保までできた ○ Engは記憶が新しいうちに修正できる ■ バグのSevirity（freeeでは重篤度と呼びます）、ユースケースに準じた発⽣頻度が⾼くないものは後のスプリントで修正し機能開発を優先する判断をする場合もある

Slide 23

Slide 23 text

　どうなったか？ 3 ● Engにより上流でテストされQA開始時のプロダクト品質が良くなった ○ QA引き渡しの時点でバグが判明している事例あり ○ QAでのバグ検出数はさほど多くない [※個⼈の感覚です] ■ Engの品質に対する意識の⾼さの表れかも ■ 後述の活動との相乗効果もあるかも..

Slide 24

Slide 24 text

24 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解⽬次

Slide 25

Slide 25 text

　なぜ解像度を上げる必要性が出てきたか ● 登録系から編集系に開発フェーズが移ったとき、複雑なパターンを事前に把握しておくことが出来ず、プロダクトの品質も悪化してスケジュールが爆発しかけた ● 編集は登録と違ってスタート地点がたくさんあるため、分岐パターンが複雑 ● ⽂字や⾔葉だけだと理解が空中戦になり、メンバーごとにパターンの理解にズレがあることがわかった ● このリリースのふりかえりから、「実例マッピング」という⼿法を知り実践してみた

Slide 26

Slide 26 text

　実例マッピング出典: https://speakerdeck.com/nihonbuson/example-mapping?slide=3

Slide 27

Slide 27 text

　記帳チームで⾏った実例マッピング Story Rule Example

Slide 28

Slide 28 text

　記帳チームで⾏った実例マッピング Story Question Rule Example

Slide 29

Slide 29 text

　全体の簡易⾒積もり Story Question Rule

Slide 30

Slide 30 text

　どうなったか ● 仕訳形式で書いてるとどういう⾒た⽬について話してるかわかりやすい ● UI設計の状態パターンの認識も合うようになった ● 初期⾒積もりがやりやすくなった ● ピンクの付箋でリスクになりそうな部分をあらかじめ⾒れた ● 各ケースごとでなく全体としての影響をあらかじめ⾒れていた ● 異常系のパスも最初に⾒えていたのでスムーズに進んだ ● QA視点も⼊ってプロダクトの前提知識が⼊って設計できたみんなはどう思う？

Slide 31

Slide 31 text

31 01 Agile 開発/QA 02 作るものの解像度を上げる 03 業務理解⽬次

Slide 32

Slide 32 text

　業務理解 ● 業務観察 ○ 業務を観察するための事前勉強をする ○ ユーザーの事業所を訪問して実際の業務を⾒る（業務観察) ● 情報に触れる ○ PdMやデザイナーが⾏った訪問やインタビューの動画をチームで⾒る ● ユーザーがどのように使っているの事実がわかり、業務が理解できる

Slide 33

Slide 33 text

　なぜ業務理解が必要？ ● プロフェッショナル達が、⽇々業務で使う「道具」を開発している ○ 要求を知らなければ開発は始まらない ○ 業務フローとの合わなさが使いにくさに繋がる ● 競合ソフトがあるなか、freeeとのコンセプトのバランスが必要 ○ わたしたちは本質的には何が達成できればいい？ ● 何が出来ればいいのか知らなければ「機能要望」しか⾒えなくなる ○ 限られたリソースを効果的な部分に投資できない

Slide 34

Slide 34 text

　ソフトウェアは、業務の道具

Slide 35

Slide 35 text

　どこの情報を⾃分たちは知らないのか？業務達成のためのソフトウェアの細かな操作ユーザーの業務プロセスや⾏動‧⼯夫会社毎の慣習や独⾃の⼯夫‧ルール業界‧地⽅の慣習書籍で知れるような業務の⼀般知識調べにくさ難しいやさしい

Slide 36

Slide 36 text

　どこの情報を⾃分たちは知らないのか？業務達成のためのソフトウェアの細かな操作ユーザーの業務プロセスや⾏動‧⼯夫会社毎の慣習や独⾃の⼯夫‧ルール業界‧地⽅の慣習書籍で知れるような業務の⼀般知識調べにくさ難しいやさしいここを⾒に⾏く！

Slide 37

Slide 37 text

　業務を観察するイメージ ● 普段業務を⾏っているデスクの近くにお邪魔する ● ⾒せていただきたい業務を再確認する ● 普段通り業務を進めてもらって黙って⾒る ● ひとかたまりの業務を⾒せていただいた後に、気になる⾏動などをインタビューする

Slide 38

Slide 38 text

　どうなったか ● ユーザーや業務に対する解像度が段違い ○ 実際に会計事務所へ訪問し、使われかたを⽬の前で⾒る効果 ○ PdMとデザイナーからも、情報が補強される ● ユーザーのことを考えながら開発できる ○ 仕様の背景の理解が早くなる ○ 「ユーザーの業務を⽌めない」指針の腹落ち ● 会話のレベル、アウトプットが⾼度になり、プロダクト品質がよくなった ○ エンジニアからも、よりよいアイデアが⽣まれるみんなはどうだった？

Slide 39

Slide 39 text

　もっと知りたい⼈はこちらスクフェス⼤阪2023資料 https://speakerdeck.com/hiromitsuuuuu/how-does-a-designer-ﬁt-in- a-scrum-team スクフェス福岡2024資料 https://speakerdeck.com/hiromitsuuuuu/what-i-want-to-provide-to- scrum-teams-when-developing-products

Slide 40

Slide 40 text

　さいごに

Slide 41

Slide 41 text

発表と準備を通して、いろいろ学びを重ねてきたことを再確認できました！  41 Engineer 学びや工夫の積み重ねがチームの進化を支えているなあと実感しました！  wb  QA Engineer toma  PdM ここまで長い道のりでした。着実にチームは変化してきてると思います！やっていき。  hiromitsuuu  Product Designer ogawa      進化し続けられるチームであるために、学び続ける姿勢が大事だなと再確認できました！ 

Slide 42

Slide 42 text

No content