こんにちは、支出管理のプロダクトで QA エンジニアをしている sawa です。
freee QA Advent Calendar 2025 3日目です。
Agile QA について語ります。
The 1st anniversary of Agile QA in freee
私はこれまで、シーケンシャルモデルをメインとするシステム開発で QA として携わってきました。
そんな私が freee に入社して Agile 開発を採用しているプロダクトチームに加わり 1 年が経ちました。
今日はそんな 1 年を振り返りたいと思います。
Sequential QA vs. Agile QA
まずは私の経験 + 教科書をもとにシーケンシャルと Agile の主な違いを整理してみます。
| 項目 | シーケンシャル（ウォーターフォール） | Agile（スクラム等） |
|---|---|---|
| QA役割 | 品質のゲートキーパー（門番） | 品質のイネイブラー（実現者、促進者） |
| バグとの向き合い方 | 「見つける」ことに集中 | 「防ぐ」ことに注力 |
| QA業務の開始 | 開発プロセスの後半に集中（実装完了後など） | 開発プロセスの全期間（企画・設計段階から） |
| テストの自動化 | 選択的ツールとして戦略的に導入する 回帰テストとして開発が安定するプロジェクト後半に導入されることが多い |
マストツールとして最初のスプリントから構築する 継続的デリバリーを実現するための不可欠な要素である |
| 品質責任 | QAチームが担保する傾向が強い | QAや開発者を含むチーム全体で担保する |
| チーム構成 | BA, SA, Dev, QAの縦割り傾向がある | One チームで常にコラボレーションする |
| コミュニケーション | 仕様書や設計書を正とし、ドキュメントベースで認識合わせをすることが多い | ドキュメントよりも対話を重視する 仕様が流動的なため、プロダクトオーナーや開発者と頻繁に連携して認識合わせをする |
My hands-on experience in both Sequential QA and Agile QA
比較表で整理したことは Agile の教科書などで幾度も目にする（耳にする）ポイントかと思います。
次に、実際に私が実務を通して感じたことをメインに振り返ります。
テスト工程がまとまって確保されているので、テストタイプ、スコープ、順番などを計画フェーズで一気に決めます。範囲が広い分、計画フェーズで多くの工数を要しますが、一度決まればあとは計画に沿って実行するのみです。
とはいえ、実行フェーズがすんなりいくことはなく、よく言われているとおり、開発ライフサイクルの後半にテストが実施されるため、不具合発見時に非常に大きな手戻りコストと工数が発生します。
（個人的には、手戻り工数を削減するために施策を打つのがシーケンシャル QA の重要責務であり、QA としての腕の見せ所とも思っています。）
シーケンシャルの良いところは、各テストタイプの品質基準となるテストベースがそれぞれ用意されており、テストフェーズごとに観点の棲み分けが可能な点です。テストベースと観点が明確だと不具合分析や品質改善の対象領域を絞りやすいです。
一方の Agile です。
リリース単位を細かく刻んで、小さいスコープで要件確認→実装→テスト→ユーザーレビューのサイクルを回していきます。
Agile では、特定のテストタイプや機能テストスキルだけでなく、テスト自動化、探索的テスト、回帰テスト、性能テストなど、幅広い QA スキルが求められる（身に付く）と感じています。
テストタイプやテスト技法だけでなく、「何をテストすべきか」という要件の領域自体も多岐に渡ります。
上のスクラム画像のイテレーションに「test」とありますが、この中で複数の異なる要件をまたいだ品質検証が内包されています。
機能の仕様だけでなく、業務要件を満たしているか、セキュリティやパフォーマンス、プロセス品質までもスプリント内で継続的にチェックできる体制が理想です。
広い範囲の要件をカバーする必要があるものの、 Agile の原則「ドキュメントより動くソフトウェア」で定義されているとおり、ドキュメントが簡素な傾向があり、シーケンシャル育ちにとってはテストベースに物足りなさを感じることがあります。
ですが、1 年過ごしてようやく、テストベースの不足を整備・補完するのも Agile QA の重要責務なのだと理解し始めたところです。
おわりに
ざっくりとした振り返りでしたが、私にとって 2025 年は freee QA として Agile QA としての「移行期」であり、日々新しい価値観に触れ、新たな経験を積む 1 年でした。
2026年は Agile QA として「起こしてはいけない不具合を起こさない品質の作り込み」で成果が出せるよう、チームで邁進していきたいと思います！
さて、明日は SEQ (Software Engineering in Quality) の tatsukom さんが「1年かけてE2Eの実装基盤と実行基盤をリプレイスした話」の記事を書いてくれますのでお楽しみに。
よい品質を〜
