🛠️

スクラム開発のQA改善で効果的だった5つの取り組み

に公開

こんにちは。

クリフォアアプリチームでエンジニアをしているキタです。

クリフォアアプリチームではスクラム開発を実践していますが、QA に関してさまざまな課題を抱えていました。
抱えている課題の解決に向けて約 1 年間、チームの QA エンジニアや所属メンバーと協力して改善に取り組んできました。
その結果、成果が出始めているので、今回は効果的だった 5 つの取り組みについて紹介します。

実施した取り組み

本記事では以下の 5 つの改善活動について、課題・取り組み・効果を具体的に紹介します。

  1. テストの目的を明文化 - メンバー間の認識齟齬を解消
  2. スプリント内でテストまで完結 - リードタイム短縮とアジャイル体制の確立
  3. QA エンジニアがリファイメントに参加 - シフトレフトによる早期課題発見
  4. マニュアルテストのケース数を最適化 - 自動テストとマニュアルテストの役割分担明確化
  5. QA はチーム全員の責任という文化づくり - 開発と QA の協力体制構築

テストの目的を明文化した

テストの目的やゴールが明確ではなく、メンバー間で認識齟齬がありテストの内容に個人差があり、結果的に品質にばらつきがありました。

取り組んだこと

  • 「ユーザーの満足度向上」をテストの目的として明文化し、チーム全体に共有
  • ユーザー目線での品質(不具合がない、使いやすい、迷わない、ストレスがない)を基準にすることで、テストの軸を明確にした

効果

どのようなテストを重視すべきかが明確になり、メンバー間でのテスト品質のばらつきが解消されました。また、テストレビュー時に「ユーザー視点で見てどうか?」という共通の判断軸ができたことで、建設的な議論ができるようになりました。

スプリント内でテストまで完結

前提としてスプリントを 2 週間で回しているのですが、スプリント内でテストが行われないことでリリースまでのリードタイムが長くなりリリースまで平均 3 週間かかっていました。
また、スプリントが終わってからその時点で開発が終了している機能のテスト設計を始めるフローだったので、仕様の確認のタイミングが遅く不用意な手戻りが発生することがありました。

取り組んだこと

  • スプリント内で完結するアジャイルな QA 体制に変更
  • テスト設計はスプリント開始と同時に着手し、開発と並行して進行
  • 毎日のスタンドアップで早期の課題解決を実施

効果

スプリント内でテストの設計と実行を行うことにより、リリースまでにかかる期間は平均 2 週間に短縮できました。

QA エンジニアがリファイメントに参加

QA エンジニアが仕様や要件の共有や議論をするリファイメントに参加していなかったことで、情報不足が生じたり確認のタイミングが遅れていました。

取り組んだこと

  • QA エンジニアの「シフトレフト」を実施し、リファイメントから参加
  • 仕様検討段階でテスト観点からのリスク指摘や確認事項の洗い出し

効果

リファイメント参加により、仕様確認の往復が削減されました。また、仕様段階でのテスト観点の指摘により、実装後に発覚していた課題を減らすことができました。

メンバーからは「新機能の主旨や大まかな挙動のイメージを最初にインプットできるので不要な確認は減った」と好評です。

マニュアルテストのケース数を最適化

自動テストで行っている内容が QA エンジニアに共有されず、マニュアルテストとの重複が発生し非効率なテストケースがありました。また、マニュアルテストでどこまで担保するかが明確になっていないので、過剰に思えるようなテストケースが存在しておりテスト工数が逼迫してました。

取り組んだこと

  • 自動テストのカバレッジを QA エンジニアと共有し、重複テストケースを特定・削除
  • 自動テストとマニュアルテストの役割分担を明確化
    • 自動テスト: validation(機能が仕様通り動作するかの検証)
    • マニュアルテスト: verification(ユーザー視点での妥当性確認)
  • バグランクの定義と優先順位付け
    • S:リリース不可(サービス停止レベル)
    • A:早急な改修対象(主要機能に影響)
    • B:将来的な改修対象(使い勝手に影響)
    • C:可能なら改修対象(軽微な問題)

効果

テストケースを約 40%削減できました。結果、テスト実行時間も短縮され、より重要なユーザー体験テストに時間を割けるようになりました。

QA はチーム全員の責任という文化づくり

品質の担保は基本的に QA エンジニアが行うことになっていたので、QA エンジニアへの依存が高すぎました。また QA エンジニアが不在の場合、テストが停滞するリスクがありました。

取り組んだこと

  • 「QA はチーム全員の責任」という意識を醸成
  • 開発初期の段階からエンジニアも品質を意識し、不具合を上流工程で発見・修正するよう取り組みを強化
  • チームメンバー全員が積極的に QA に関わる体制を構築
  • ときには開発メンバーが QA として受け入れテストを実施し、開発とテストを分離せず協力する文化を醸成

効果

QA エンジニアに過度に依存していた従来の体制から、開発と QA エンジニアが連携し品質を共創する体制へと変化しました。この変化により、チーム全体の品質に対する当事者意識が向上し、より一体感を築くことができました。

まとめ

以上の取り組みにより、私たちのチームでは次のような成果が得られました。

  • QA 目的が明確化され、効率化が進んだ
  • QA をスプリント内で完結し、迅速なリリースを実現
  • シフトレフトによりリスクの早期発見・回避が可能に
  • マニュアルテストケースが最適化され、QA 業務の効率が向上
  • QA エンジニアへの過度な依存を脱却し、開発と QA が協力して品質を担保

今後も継続的な改善活動により、さらなる QA の最適化を図っていきます。
私たちの QA 改善の取り組みに興味を持っていただけたら、ぜひカジュアルにお話ししましょう!

https://recruit.linc-well.com/contact

改善のために参考にした資料

【この 1 冊でよくわかる】 ソフトウェアテストの教科書

https://tech.smarthr.jp/entry/qa_series_article_vol9

https://www.scrum.org/resources/blog/how-the-four-agile-testing-quadrants-support-scrum-teams-jp

https://nihonbuson.hatenadiary.jp/entry/TestingManifesto

Linc'well, inc.

Discussion