こんにちは。freee会計のQAをしているakariです。
freee Developers Advent Calendar2023 8日目です。
私が所属する開発チームでは、QA含むスクラムチームで開発をしています。スクラムチームの中で QAがどのような動きをしているかについて先日インボイス制度に対応した際の例を挙げて書きたいと思います。 まだまだ改善点はありますが参考程度に読んでいただけると嬉しいです。
過去にはfreeeカードUnlimitedのテストでの事例をymtyさんが紹介していますのでご覧ください。
開発エンジニアとQAエンジニアについて
freeeでは多くの開発チームが各プロダクトや各機能別に分かれています。QAチームの場合は、プロダクト横断で存在していますが普段は各開発チームごとに分かれ1開発チーム5~6人に対してQAエンジニアが1~2人（兼務あり）という構成になっています。
今回私が入っていたチームも同様の構成となっており、QAエンジニアはスクラムチームの一員として動きました。
なぜスクラムチームにQAが入るのか
今回のインボイス制度に対応する開発は開発期間が約1年と長期のプロジェクトでした。当然、1年の間にフェーズを分けて段階的リリースをするのですが、それでも各フェーズの開発期間は2ヶ月〜半年はかかります。
従来のウォーターフォールでテストした場合、バグがあった時の手戻りは複雑かつ影響度が大きいものになります。
よくある例えで、家を建てる時には設計図がありその通りに建て始めます。ですが途中で「やっぱり壁はこの素材にしたい」「設計図上ではこの壁紙と書いてあるけど実際は違う壁紙が貼られている」なんてことが出てきます。これが完全に家を建て終わってから気づくと手戻りの複雑度と影響度、コストは大きくなってしまいます。
普段のテストでも同じことが起きていて、これはfreeeのQAチームで目標とする「品質の高速フィードバックをすることでハッピーの作り込みを防ぎ、プロダクトリリースを早める」と相反することになります。
また、インボイス制度という法改正への対応の場合、PMや開発エンジニアはもちろん、QAエンジニアも可能性のあるパターンをテストケースに落とし込むためには改正内容や仕様の背景まで理解しておく必要があります。
スクラムチームにおけるQA
では、実際にスクラムチームの一員であるQAがどういったスクラムイベントに参加したのか、どういった動きをしたのかについてです。
<参加したスクラムイベント>
- デイリースクラム
- スプリントレビュー
- スプリント計画ミーティング（リファインメント含む）
- レトロスペクティブ
<不参加だったスクラムイベント>
- プランニングポーカー
この他にも、上流工程では設計書の読み合わせ会やPM主体の要件相談会などにも参加しました。
今回スプリントは2週間で、普段の開発はJIRAを利用してチケットベースでタスクをこなしていきます。 ストーリーチケットの配下に開発エンジニアがタスクチケットを作成し、タスクチケットを全て完了したらストーリーチケットも完了になります。 ストーリーチケットにはQAエンジニアが受け入れ条件を記載し、開発エンジニアは受け入れ条件を全て完了していることを確認した上で、QAエンジニアがテストに着手します。テスト実施中に見つけたバグはバグチケットとして起票し、開発エンジニアに連携します。
このような運用を始める際には下記のようなフロー図を作成し、どのステータスになったら誰がボールを持つのか、どのステータスに遷移すべきなのかをチームで合意しておきました。
他にもアジャイルの場合は途中でデグレードに気づくのが難しいという課題もあったので、手動テストと並行して、バグが出ると深刻な箇所を優先的に自動テストを作成して日次で回す運用も始めました。
スクラムチームに入って良かったこと
仕様からつっこんでいける
ウォーターフォールの場合は、仕様も開発もほぼ終わった状態でQAエンジニアにテストの依頼が来ます。明らかなバグやユーザに誤解させてしまうような表現の時は修正になりますがこの時点では基本的に仕様を覆すことは難しくなります。
スクラムの場合は、設計書の読み合わせから参加しているため、仕様決めの背景やユーザ目線での小さな違和感を開発に入る前の段階から提案することができます。これが先述の手戻りを最小限に抑えることにつながります。
また、QAエンジニアはユーザ視点を大事にしているので影響範囲を事前に広く確認しています。
下記は実際にスプリントレビューで開発エンジニアからもらったフィードバックです。
チームのコミュニケーションが円滑
これまでの経験上、開発エンジニアとQAエンジニアはテストを依頼する側、修正を依頼する側として見えない壁が出来がちだと思っています。
スクラムの場合は、デイリースクラムで日々開発とテスト進捗を共有し、時にはPMやデザイナーも交えて修正方針やあるべき姿（freeeでいうマジ価値）について話し合うこともあります。なので一緒のゴールを追っているという仲間意識が自然と生まれやすくなります。（その分達成感もひと塩）
テスト設計の段階でも開発エンジニアにレビューをもらうことでテストするべき箇所を明確にし、開発エンジニアとのテスト箇所の重複を避ける効果もありました。
おわりに
ここまでインボイス制度に対応した機能のテストをスピード感を持って取り組んだ事例を紹介しました。 freee QAは、より品質の高いプロダクトをより早く届けるために、挑戦を続けていきます。
明日は、同じfreee会計を担当するazuminさんが開発チームと輪読会をやったお話について記事を書いてくれます。楽しみですね！ 最後まで読んでいただきありがとうございました。
それでは、よい品質を〜
