受け入れ基準(Acceptance Criteria)の導入から改善までの道のり

アソビュー! - Qiita Advent Calendar 2024 - Qiitaの12日目(表面)です。

はじめに

こんにちは、アソビューでQAエンジニアを担当しております、石川和尚です!
私は主に品質改善プロセスの立案やテスト設計、実行を担当しており、テストの効果的な実施と品質向上に向けて日々取り組んでいます。

その中で、今回は受け入れ基準について焦点を当てていこうと思います。

受け入れ基準とは、ユーザーや顧客、その他の認可団体が、コンポーネントやシステムを受け入れる際に満たすべき基準のことです。明確な目標や条件を基準として定めることで、認識のズレや手戻りを防ぎ、チーム全員で共通理解を持つことができます。
導入背景やその重要性、期待される効果についての詳細は、こちらのブログに詳しく記載されていますので、ぜひご覧ください。

tech.asoview.co.jp

本記事では、チームが受け入れ基準を導入後に直面した課題や、それに対する改善策、得られた成果を中心にお伝えします。プロセスを通じて得た学びが、他のプロジェクトやチームの参考になれば幸いです。

受け入れ基準の導入と改善

プロジェクトマネージャー(PM)からの提案

受け入れ基準の導入は、プロジェクトマネージャー(PM)からの提案がきっかけでした。プロダクトごとに異なるテスト密度や品質の課題に対して、品質の底上げを目指し、シナリオベースおよびルールベースで詳細な受け入れ基準を策定し、これをQA主体で運用することが提案されました。

JIRAチケットでの初期導入と試行

JIRAで作成した受け入れ基準
初期段階では、JIRAチケットを活用して受け入れ基準を管理しました。基準へのアクセス性や透明性を向上させる点では有効でしたが、以下の課題も明らかになりました。

  • 情報の整理が困難:SlackやJIRAのコメントで行われるやり取りが散在し、基準ごとの議論内容が追いにくい。
  • 変更履歴の管理が困難:JIRAでは変更履歴を残すことができず、変更内容の管理に手間がかかる。

これらの課題を解決するため、新たな管理方法を模索しました。

Confluenceへの移行による運用の強化

開発者からのコメント
JIRAの運用を試行した結果、効率的な情報共有を目指してConfluenceへの移行を決定しました。

Confluenceの主な利点は次の通りです。

  • コメント機能:基準の記載箇所に直接コメントできるため、認識齟齬や要件のすり合わせがスムーズに行えます。
  • 変更履歴の管理:基準変更の履歴を簡単に追跡でき、どのタイミングで何が変更されたかを明確に把握できます。

この移行により、チーム内での認識合わせがスムーズになり、運用効率が大幅に向上しました。
今回、私たちのチームではConfluenceを活用しましたが、Excelのコメント機能など他にも活用できるツールは多く存在します。チームの状況やニーズに合わせて、最適なツールを選んで活用してみてください。

品質リスクを取り入れた品質強化

Confluenceの運用が安定してきたタイミングで、新たに品質リスクの観点を受け入れ基準に組み込む取り組みを始めました。
リスクの高い部分には詳細な基準を設定し、リスクの低い部分では効率化を図るという柔軟なアプローチを採用しました。この手法により、品質と効率のバランスをとりながら、テスト全体の精度をさらに高めることができました。

振り返りの実施

受け入れ基準導入後、しばらくしてからKPT(Keep, Problem, Try)方式で振り返りを行い、以下のような成果と課題、改善提案が挙がりました。

Keep:成功したポイント

  • テストケースのレビュー指摘数が減少。
  • 顧客にとっての価値を整理することで、品質向上に寄与。
  • 品質リスクの検討により、テストケースのボリュームを最適化。
  • 要件や仕様の抜け漏れが減少。
  • 認識齟齬の解消による手戻りの削減。

Problem:課題点

  • 要件が十分に詰められていない場合、基準レビューが難しい。
  • 基準作成の過程で、全ての仕様が十分に考慮されているか不安が残る。
  • 仕様検討において、開発者とQAの作業が重複することがある。

Try:次に試みるべき改善案

  • 必要なステークホルダーを召集し、適宜ミーティングを実施。
  • 流出した不具合を対象に分析を実施。
  • 開発者とQAの連携強化(ユースケース記載と因子水準の分担)。

この振り返りを通して、チーム全体での共通認識が深まり、改善策の具体化と今後の行動指針の明確化が進みました。

開発者と連携した基準作成による効率化

現在は、振り返りの中で挙げられた「QAと開発者間で作業が重複している」という課題に対して、開発者と連携しながら基準作成を行う新たなプロセスを試行中です。

具体的には

  1. 開発者が要件や仕様を整理し、ユースケースや関連する画面、機能を箇条書きで記載。
  2. QAがそれを基に検証因子や品質リスクを定義し、受け入れ基準を完成させる。

この取り組みにより、作業効率化と認識の統一を目指しています。

今後の方針と展望

品質リスクのさらなる活用とテストの最適化

リスク分析プロセスの標準化
リスク分析の一貫性と迅速化を図るため、全プロジェクトで利用可能なガイドラインとテンプレートを導入することを検討しています。これにより、各プロジェクトでのリスク評価にばらつきが生じるのを防ぎ、どのプロジェクトでも正確かつ効率的なリスク分析を実施できる体制を構築したいと考えています。また、標準化によってリスクの見落としや重複が減少し、品質リスクへの対応がさらに強化されることを期待しています。

不具合傾向に応じたリスク検討
過去の不具合傾向や修正頻度を分析し、高リスクエリアを特定して重点的な対応を行いたいと考えています。リスクが高いと判断された領域には、より詳細な受け入れ基準を設定し、テストリソースを重点的に割り当てることで、リスクに応じた効率的なテストと品質管理を推進する予定です。これにより、不具合の予防や早期検出の精度が向上し、全体的なテストの最適化が図れると考えています。

AI活用

テストケース生成の自動化
受け入れ基準からユースケースや機能要件を解析してテストケースを自動生成することを目指しています。これにより、テストケース作成にかかる工数を大幅に削減でき、頻繁に仕様変更が発生するプロジェクトでも効率的にテスト対応できる体制を構築することが可能になると考えています。

AIによるレビューと追加観点洗い出し
受け入れ基準の妥当性をチェックし、カバーされていないリスクや考慮点を洗い出すレビュー支援を実施したいと考えています。これにより、受け入れ基準がより包括的かつ実用的なものとなり、見落としが少なく高品質な基準策定が可能になることを期待しています。

まとめ

受け入れ基準の導入から改善に至る一連の取り組みを振り返ると、チーム内での認識の統一や仕様の抜け漏れへの対応力が向上しました。その結果、レビューでの指摘事項や不具合の発生率が減少し、テストケースの作成も効率化されるなど、様々な成果が現れています。

今後も受け入れ基準を定期的に見直し、改善を重ねることで、品質向上を持続的に目指していく方針です。この取り組みが他のチームやプロジェクトにとって参考となり、全体の品質向上につながることを期待しています。

さいごに

アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく様々なエンジニアを募集しています。 QAエンジニアについても、上記のような施策を一緒に推進するための仲間を増やせたらと考えています。

カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください! お待ちしております。

www.asoview.co.jp

speakerdeck.com