品質の高速フィードバックへの取り組み / Commitment to Fast Quality Feedback

Transcript

1. 品質の高速フィードバックへの取り組み 
 フリー株式会社 清⽔あかり（akari） 2024.08.08
2. 2 ・出身
 　神奈川県川崎市
 ・経歴
 2017- Sierでシステムエンジニア
 2019- 旅行会社でランドオペレーター@ベトナム
 2020- QAにキャリアチェンジ
 2022/7 フリー株式会社入社
 ・担当プロダクト 
 　2022/7-2024/6 freee会計
 　2024/7- freee人事労務
 ・趣味
 旅行、編み物（刺繍、かぎ針）、カメラ
 QA エンジニア
 清水あかり (akari)
 Akari Shimizu

3. 会社概要
 会社名
 設立年月日 
 CEO
 資本金 
 従業員数
 事業内容 
 フリー株式会社
 2012年7月9日
 佐々木 大輔
 161億603万円（資本準備金など含む）
 1,299名（2023年6月末時点、連結会社の総数）
 クラウド型バックオフィスサービスの 開発 ・販売

4. 4 freeeの プロダクトラインアップ 
 freee会計 freee申告 freee⼈事労務 freee福利厚⽣ freee会社設⽴ freee開業 freee資⾦調達 freeeカード freeeサイン freee請求書 freeeプロジェクト管理 freeeアプリストア
5. QA/開発組織・体制の紹介 

6. 6 QAは開発組織の部署の 1つという立ち位置
 開発組織における QAの立ち位置 
 開発組織全体
 QA
 • プロダクト別で案件を担当
 • やっていること
 ◦ 品質可視化、課題特定
 ◦ リスク管理
 ◦ テスト設計、実行
 プロダクトQA
 • 横断で基盤を開発
 • やっていること
 ◦ 品質企画
 ▪ 品質向上のための企画
 ◦ SEQ
 ▪ 自動テスト基盤の開発・運用
 品質企画 / SEQ

7. 7 開発チームあたり開発エンジニアがおよそ5~6人に対してQAエンジニアが1~2人（兼務あり）という構成
 開発チームの一員として設計書のレビューやテスト実施などプロダクト品質の責任を担う
 実際の案件における QAの体制
 主な担当領域：会計、人事労務、請求書、支出管理、販売、決済、外部連携、API etc…

8. 品質の高速フィードバックへの取り組み 

9. 9 なぜスクラムにQAが入っているのか？
 →　freee QAが目指す姿を実現するため
 • 品質の高速フィードバック 
 • バグの作り込み防止 
 • プロダクトリリースを早める 
 
 それらを実現するためにQAができるアプローチ
 • 要件の段階から会議やレビューに参加
 • 各スクラムイベントへの参加
 • ストーリーまたはタスク毎のテスト設計と実行
 • リグレッションテストの自動化　など
 
 スクラムチームでの QA
 仮説定義 課題整理 設計 実装 テスト コード レビュー QA テスト フィードバック
 フィードバック
 フィードバック
 フィードバック
 フィードバック
 効果測定 振り返り リリース
10. 最近取り組んでいること 

11. 11 チームの状態を可視化した上でコミュニケーションすることで品質の高速フィードバックに貢献！
 
 開発・テストステータスの認識合わせ 
 
 コミュニケーションの見直し① 

12. 12 • 複数人で開発している場合、人によってチケットのステータスの認識がばらばら
 ◦ フローを可視化することで各ステークホルダーが迷うことなくチケットを移動させられる 
 
 • 案件の途中から参画したメンバーには都度各ステータスがどういう状態かを口頭で説明しなければならない
 ◦ 決めたフローを見てもらうことで説明コストが省ける 
 
 • テスト実施に必要な開発タスクの状況やデプロイステータスをQAから開発エンジニアに逐一確認する必要があり、コミュニ ケーションが発生していた
 ◦ ステータスをリアルタイムでトラッキングできるので、それに合わせてテスト設計と実行準備ができる 
 ◦ 開発側に逐一確認しなくてもボードを見れば一目瞭然！ 
 見直す前の課題と成果① 

13. 13 バグチケットの詳細の可視化 
 コミュニケーションの見直し② 

14. 14 • 発生しているバグが他のテストケースのブロッカーになっているがなかなか修正に着手してもらえない（開発エンジニアもどれ がブロッカーになっているのか見えづらい）
 ◦ 優先度をQA側で付与することでブロッカーかどうかが開発側に伝わり、優先的に修正してもらえる（開発エンジニアか らも好評） 
 • スケジュールの関係でバグの修正見送りをせざるをえない状況の場合に、どれを見送って良いのか判断がしづらい
 ◦ 重篤度（事象のひどさ）が低いバグに対して PdMを中心にリリース対象から見送るかどうかの判断がつきやすくなった 
 ▪ 「重篤度」について詳しくはこちら
 ハッピーの重篤度でみんなで品質の目線合わせするぞ！ / We're all going to be quality line of sight on the severity of Happy's! (https://speakerdeck.com/freee/were-all-going-to-be-quality-line-of-sight-on-the-severity-of-happys)
 見直す前の課題と成果② 
 次にやりたいこと 
 • 案件や機能毎に集計している重篤度のデータの活用

15. 15 テスト管理ツールの移行 
 
 コミュニケーションの見直し③ 
 テストケース側からチケットの起票、
 ステータス参照が可能
 （JIRA側からテストケースの作成も可能）

16. 16 • 従来のテスト管理ツールは予算の都合上QAにしかアカウント発行されていなかったため、都度進捗をSlack等でチームに 共有する必要があった
 ◦ Jiraのアカウントがあれば見れるツールに移行したため、開発チーム全員がリアルタイムでテストケース、進捗状 況を見ることができるようになった。これにより品質の高速フィードバックに貢献！ 
 
 • 開発タスクやバグチケットとテストケースの関連付けから相互のステータスが見えづらく、都度双方のツールを開いていた
 ◦ テスト管理ツール上のテストケースから開発タスクやバグチケットの関連付けができるようになったので、相互の ツールを開かずにステータスが見えるようになった 
 見直す前の課題と成果③ 
 次にやりたいこと 
 • 各ステークホルダー（PdM / SWE / QA）によるテストケースの活用
 ◦ テストケースは資産！！なので、一度作ってその後放置はもったいない！
 ◦ 過去のテストケースやテスト結果から影響範囲を把握したり、バグが出そうな機能が事前に把握できると尚ヨシ

17. 17 今後もスピードと品質を両立させるためにQAエンジニアの役割にとらわれずに柔軟に取り組んでいきます！！
 
 freee Developer hubには各開発チームの様々な取り組みについてQAエンジニアも記事を書いていますので
 よければのぞいてみてください！
 
 freee Developers Hub
 (https://developers.freee.co.jp/archive/category/QA)
 
 スクラムチームの中でのQAの動きについてもこちらで記事を書いています
 スクラムチームのメンバーとしてQAが入ってみる (https://developers.freee.co.jp/entry/qa-member-join-to-scrum)
 最後に