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

記帳チームにおけるスクラムの応用と協同作業の実践 / Application of Scrum...

freee
June 06, 2024
2.2k

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

freee

June 06, 2024
Tweet

More Decks by freee

Transcript

  1. 4 ogawa takahiro
 • freee会計エンジニア ◦ React / TypeScript ◦

    Ruby on Rails • 2022/12~ freee ⼊社 ◦ 中部オフィス所属 Engineer
  2. 6 Toma Tomomori 
 ⼤分県 ⽣まれ 新卒として⼊社 • カスタマーサポート •

    カスタマーサクセス • コンテンツ企画‧運営  • プロダクトマネージャー 配属(現職)   パートナーと猫と暮らす PdM
  3. 7 hiromitsuuu
 • freee会計 デザイナー • 2021/10~ freee ⼊社 •

    エンジニア→デザイナーキャリアのひと Designer
  4.   どのような機能か これまでの ソフト freee 新機能 違いが ⼤きい… 違いが ⼩さい!

    【仕訳の形式に慣れたユーザー向けの機能】  …使い始めやすくするステップとしての役割→はじめやすい!体験
  5.   記帳チームの取組の紹介 • コンセプトが正しいかを都度チェックしていくためには開発のイテレー ションを素早くやる必要がある ◦ Agile 開発/QA • 作るものの品質を上げる必要がある

    ◦ 作るものの解像度を上げる(実例マッピング) • 仕訳の⼀覧登録はこれまでのエンドユーザーではなく 税理⼠さんに向けた機能であるためそこを探索していく必要があった ◦ 業務理解が必要
  6.   Agile 開発/QA • PRがマージされると社内検証環境に⾃動でデプロイされる ◦ PdM、デザイナーも好きなときに検証環境で動くものを触ることが 出来る • それをトリガーにQAによりチェックされる

    • QAもスクラムイベントに参加しているので、受⼊条件も共有済み • 全ての実装完了を待たなくてもQAチェックを始められる • チケット単位の個別のテストとは別に実装が全部終わり機能が揃った 後のリグレッションテストも実⾏している
  7.   どうなったか? 2 • QAからのフィードバックがリアルタイムにできている ◦ 実装後できた順にすぐにテストできるのでバグがあればすぐに知らせる ◦ QAからのバグ指摘に対し同スプリント内で修正までできた事例あり →そのスプリント内で品質担保までできた ◦

    Engは記憶が新しいうちに修正できる ▪ バグのSevirity(freeeでは重篤度と呼びます)、ユースケースに準じた 発⽣頻度が⾼くないものは後のスプリントで修正し機能開発を 優先する判断をする場合もある
  8.   なぜ解像度を上げる必要性が出てきたか • 登録系から編集系に開発フェーズが移ったとき、複雑なパターンを事前 に把握しておくことが出来ず、プロダクトの品質も悪化してスケジュー ルが爆発しかけた • 編集は登録と違ってスタート地点がたくさんあるため、分岐パターンが 複雑 •

    ⽂字や⾔葉だけだと理解が空中戦になり、メンバーごとにパターンの理 解にズレがあることがわかった • このリリースのふりかえりから、「実例マッピング」という⼿法を知り 実践してみた
  9.   どうなったか • 仕訳形式で書いてるとどういう⾒た⽬について話してるか わかりやすい • UI設計の状態パターンの認識も合うようになった • 初期⾒積もりがやりやすくなった •

    ピンクの付箋でリスクになりそうな部分をあらかじめ⾒れた • 各ケースごとでなく全体としての影響をあらかじめ⾒れていた • 異常系のパスも最初に⾒えていたのでスムーズに進んだ • QA視点も⼊ってプロダクトの前提知識が⼊って設計できた みんなは  どう思う?
  10.   業務理解 • 業務観察 ◦ 業務を観察するための事前勉強をする ◦ ユーザーの事業所を訪問して実際の業務を⾒る(業務観察) • 情報に触れる

    ◦ PdMやデザイナーが⾏った訪問やインタビューの動画をチームで⾒る • ユーザーがどのように使っているの事実がわかり、業務が理解できる
  11.   なぜ業務理解が必要? • プロフェッショナル達が、⽇々業務で使う「道具」を開発している ◦ 要求を知らなければ開発は始まらない ◦ 業務フローとの合わなさが使いにくさに繋がる • 競合ソフトがあるなか、freeeとのコンセプトのバランスが必要

    ◦ わたしたちは本質的には何が達成できればいい? • 何が出来ればいいのか知らなければ「機能要望」しか⾒えなくなる ◦ 限られたリソースを効果的な部分に投資できない
  12.   どうなったか • ユーザーや業務に対する解像度が段違い ◦ 実際に会計事務所へ訪問し、使われかたを⽬の前で⾒る効果 ◦ PdMとデザイナーからも、情報が補強される • ユーザーのことを考えながら開発できる

    ◦ 仕様の背景の理解が早くなる ◦ 「ユーザーの業務を⽌めない」指針の腹落ち • 会話のレベル、アウトプットが⾼度になり、プロダクト品質がよくなっ た ◦ エンジニアからも、よりよいアイデアが⽣まれる みんなは どうだった?
  13. 発表と準備を通して、い ろいろ学びを重ねてきた ことを再確認できまし た!
 41 Engineer 学びや工夫の積み重ね がチームの進化を支えて いるなあと実感しまし た!


    wb
 QA Engineer toma
 PdM ここまで長い道のりでし た。着実にチームは変化 してきてると思います! やっていき。
 hiromitsuuu
 Product Designer ogawa
 
 
 進化し続けられるチーム であるために、学び続け る姿勢が大事だなと再確 認できました!