バクラク請求書発行開発チームにおける QA活動のこれまでとこれから

LayerX では各QAエンジニアがインプロセスQAとして各プロダクト開発チームに入り込んで活動しています。請求書発行プロダクトでの取り組みを具体例に LayerX でのインプロセスQAが取り組んでいることをお話しします。

1. © LayerX Inc. バクラク請求書発⾏開発チームにおける QA活動のこれまでとこれから LayerX ⼯藤 元 ( genny )
2. © LayerX Inc. 2 株式会社LayerX 経歴 - 株式会社ユーザベース(2016/02-2020/06) - 株式会社SmartHR(2020/07-2023/05) - Slalom株式会社(Slalom Build) (2023/06-2024/08) - 株式会社LayerX(2024/09-) 画像を入れてね ⾃⼰紹介 ⼯藤 元 （ genny / GennyBoy ）
3. ⽬次 Agenda • はじめに • バクラク事業部の開発/QAチーム体制について • 請求書発⾏プロダクトにおける取り組み • ⼯夫したこと • おわりに
4. はじめに
5. © LayerX Inc. 5 事業概要
6. © LayerX Inc. 6 バクラク事業
7. © LayerX Inc. 7 プロダクトリリースの変遷 2021年1月 2021年4月 2021年12月 2022年5月 2022年8月 バクラクビジネス カード バクラク 請求書 バクラク 申請 バクラク 経費精算 バクラク 電子帳簿保存 Invoice/AP Workflow Box Expense Card 2023年3月 Card SaaS 経費精算＋ バクラクカー ド連動 2023年8月 Invoice/AR バクラク 請求書発行 サービス開始4年で7+のサービスを展開 2025年1月 HR バクラク 勤怠
8. バクラク事業部の 開発/QAチーム体制について
9. © LayerX Inc. 9 コンパウンドを実現するバクラクの組織とアーキテクチャ プロダクト開発チーム - 各プロダクトにPdM、EM、TL, QA, デザイナーをアサイン、 各プロダクトの意思決定はプロダクト 内で完結する⾃律的なチーム群 - 各プロダクトは3〜5名のエンジニアで、少⼈数の職能横断チームを構成 - プロダクトのフェーズは様々(0->1 〜 10->100) - ユーザー規模の⼤きいサービスほど、よりドメインは複雑になり、品質が重要視される - チームでの意思決定の幅は広い - プロダクトやチームの⽬標設定 - ex. インセプションデッキ、四半期のOKRやロードマップ - ⽇頃の開発サイクル - ex. 要望、プロダクトバックログ、 顧客へのヒアリング、 スクラムの会議体の管理 プロダクト開発チーム 申請・経費精算 Web 請求書受取 電子帳簿保存 ビジネスカード 請求書発行 勤怠 申請・経費精算 App
10. © LayerX Inc. 10 QAチームの体制 • チームは全員で10名（社員7名、協⼒会社からのメンバー3名） • 基本的にはそれぞれのメンバーが主担当するプロダクトを持っている ◦ プロダクトがリリースされてからの期間やプロダクトの規模や複雑度は様々なの で、必ずしも QAE:プロダクト が 1:1 ではない ◦ QAE:プロダクトが 2:1 にようになっているプロダクトもある • 各プロダクトチームでのQAEでの⽴ち回りはそれぞれ違う ◦ みんながチームの状況に応じて必要なことを適宜判断して⾏っている バクラク事業部のQAチーム体制について
11. 請求書発⾏開発チームにおける 取り組み
13. © LayerX Inc. 13 バクラク事業部におけるテストの進め⽅ • ⽉に2回のリリース(⼤体2週間スプリント) • 1リリースにつき3⽇間のテスト期間 ◦ Staging環境で実施 ◦ 社内では「QA期間」と呼ばれている • QAエンジニアがメインで新機能テスト‧リグレッションテストを実施 前提：テストの進め⽅
14. © LayerX Inc. 14 ⼊社直後に感じた課題 ⼊社してから8ヶ⽉弱経ちますが、⼊社直後は下記のような課題を感じていました。 • QA期間直前やQA期間中に仕様の話が出てくることがそれなりの頻度である • QA期間で⾒つかるバグが多い • QA期間の負荷が⾼い、みんなきつい ◦ (新機能テスト&リグレッションテスト)テスト実施 → バグ修正 → 再テスト(必要に応じ てリグレッションテストのやり直し)をQA期間前の3⽇間でやる必要がある 課題
15. © LayerX Inc. 15 インプロセスQAとして働く上で⼤事にしていること • 「チームの状況に応じて、お客様に安定的になるべく早く価値を届けるために今やるべきだ と思ったことをやる」 ◦ 開発者の⼈数や習熟度、プロダクトのフェーズや特性などによって、やるべきことやそ の優先順位は常に変動する • 経緯や現状は尊重しつつ、必要なことはここだと思ったタイミングで⾔い、変化をもたらす ◦ HRT ⼤事 請求書発⾏開発チームにおける取り組み
16. シフトレフト！！
17. © LayerX Inc. 17 この8ヶ⽉間でチームとして下記のようなことに取り組んできました。 本⽇は★がついているものに絞ってお話をします。 1. もっと早く(みんなで)仕様の話をする a. 実例マッピング (★) b. バックログリファインメント 2. もっと早くにテストする a. こまめに早めにET会の実施(★) b. できた機能から早めにdev環境でテストをする 取り組んだこと 請求書発⾏開発チームにおける取り組み
18. © LayerX Inc. 18 実例マッピング • コミュニケーション濃度は前半に上げる • PdM、SWE、QA、Designer で実例マッピングを実施 良かったこと • 様々な視点からの「これってどうだっけ？」の議論が実装前に⾏われるようになった ◦ 実装しようとしている機能の規模や複雑度に早く気づける • チームとして feature の理解が進む もっと早く(みんなで)仕様の話をする
19. © LayerX Inc. 19 こまめに早めにET会 LayerX バクラク事業部における探索的テストの取り組み もっと早くにテストする “ ”
20. © LayerX Inc. 20 こまめに早めにET会 • ET会をQA期間の2⽇前に1時間枠を取ってやるのが慣例だった（⼤体の機能が出揃うのがこ れくらいなので） ◦ できた機能から30分単位などでこまめに早めにET会を実施 ◦ 早めに実装が完了した機能などもQA期間の2⽇前まで置いておかれていた ▪ このタイミングで⼤きめの仕様考慮漏れが⾒つかるとリカバリが⼤変（多くの場 合QA期間に⾷い込んでしまう） ▪ 問題がある場合は早めに気付けた⽅が代替策の検討なども可能 良かったこと • ⼤⼩様々な課題に早いうちに気づいて修正できる（仕様の考慮漏れ、デザインの細かい調整 など） ◦ ただ⽇程調整が⼤変… もっと早くにテストする
21. ⼯夫したこと
22. © LayerX Inc. 22 ⼯夫したこと • まずはチームの信頼関係を築くことを最優先する（率直なFeedbackができる関係性の構築 => Trustful Team） ◦ 今あるプロセスや業務をとにかく早くキャッチアップして回せるようになる ◦ テスト実施やMTGなどで少しずつでも何か貢献する • できるだけ実際に⽬に⾒えるデータを元になぜ今これをやるかを話す(Fact Base) ◦ Staging環境 でのバグの数、問い合わせの数などが増えていることを⽰してアクションする必 要性を伝える • これをやった結果どう「みんな」が嬉しいか、という視点から話すように⼼がける ◦ 例）仕様考慮漏れを実装前に発⾒することで開発者の時間を無駄に使わないようにできる • ⼀度に全部やらない(タイミングを⾒計らって⼩出しでやる) ◦ 実際にプロセスや業務上不具合が⾒えたタイミングで、「こういうのやってみませんか？」っ て提案してみる ▪ ET会などで仕様に対する認識が関係者間で違う => ユーザーストーリーの書き⽅改善し ませんか？受⼊条件書きませんか？など 請求書発⾏開発チームにおける取り組み
23. おわりに
24. © LayerX Inc. 24 基本的にインプロセスQAとして働くのが好き • というよりプロダクト開発チームの⼀員として働くのが好き ◦ プロダクトにコミットできる • プロダクトを伸ばしたい、お客様に価値を届けたいと⼼の底から思っているメンバーと⼀緒 に働ける • 事業やプロダクトの成⻑をメンバーと⼀緒に喜べる とはいえ難しさも... • バクラク開発全体の⽅針と、とはいえここは変えるべきとアクションを起こす、ここは今は⼀旦触 れない、というような判断がなかなか難しい • 割と場当たり的になってしまっている感がある ◦ ポコポコ出てきている問題に対して都度打ち返している感がある • 兼務やQAチームとしてのタスクや業務が忙しくなると、プロダクト側の改善などが中々進められな くなる（定常業務を回すだけで終わってしまい、プラスアルファの部分が中々⾏えない） インプロセスQAとして働くことの魅⼒と難しさ
25. © LayerX Inc. 25 今後のチャレンジ: ⾃動テストへの取り組み強化 • 現状の課題： ◦ 新機能に対するテスト、リグレッションテストともにまだマニュアルテストが中⼼で負 荷が⾼く時間もかかる ◦ プロダクトのリリースから1年半以上が経過し、仕様/コードベースともに複雑度が上が り、コードの変更が意図しないところでバグを⽣むことなどが起こることも • 今後取り組んでいくこと ◦ より開発プロセスに⾃動テストを組み込んでいく ▪ 実装前に誰がどのレイヤーでどんな⾃動テストを書くかの議論をする ◦ 既存機能の⾃動テストも並⾏して拡充していく おわりに
26. © LayerX Inc. 26 • 請求書発⾏開発チーム：全体⽅針とのバランスに留意しつつ、シフトレフトを⽬指す施 策を推進してきた • 現状：チーム‧バクラク全体どちらも課題は⼭積みだが、プロダクトに真摯に向き 合っているメンバーの熱意により改善しやすい⼟壌はある • 今後：⾃動テスト‧AI活⽤など伸びしろはまだまだあるので、引き続き改善の取り組み をやっていき！ もし他のプロダクトを含めバクラク事業部での取り組みで気になることがあれば、お声がけくだ さい！ぜひ皆様のお話も聞きたいので後ほど情報交換しましょう！ まとめ おわりに
27. おわり ご清聴ありがとうございました！