はじめに
こちらの記事は、アソビュー！ Advent Calendar 2024の５日目（表面）です。
アソビュー！でバックエンドを担当している島田です。
皆さん、開発者とQAの役割が分断されているせいで、品質や効率が低下していると感じたことはありませんか？例えば、開発者が作り上げた機能をQAがテストする段階で認識のズレから不具合が見つかり、手戻りが発生する。こんな経験はありませんか？
私が所属するスクラムチームでは、効率的な開発と高品質なプロダクトの提供を目指しています。しかし、役割意識が強すぎることや、協働不足が原因で、開発や品質に課題を感じる場面が少なくありませんでした。この記事では、こうした課題を解決するために導入した『受入基準』について、具体的な方法や効果を紹介します。
背景と課題
私が所属するスクラムチームは、プロダクトオーナー（PO）1名、バックエンドエンジニア（BE）6名、フロントエンドエンジニア（FE）1名、QAエンジニア1名の計9名で構成されています。現在のチーム体制になったのは2024年2月からで、それ以前は30名以上が開発に関わり、機能軸（管理機能やユーザー機能などの大きな範囲）で複数のチームが編成されていました。
詳しくはこちらの記事を参照してください。
以前の体制では、QAは外部委託でテスト専任のような役割でしたが、現在では内製化が進みました。しかし、開発者とQAの役割意識が強く、協働が進まないことに課題を感じていました。
また、チームだけでなく組織全体を見ても同様の課題があり、具体的には以下のような問題がありました。
協働意識の欠如
開発者とQAが別々の作業に集中しすぎて、『どうせあちらがやってくれる』という状態に。これでは品質の向上は難しいと感じていました。一因として、設計・開発が終盤に差し掛かる頃にQAが要件・仕様の確認を行い、テストケースの作成に取り掛かるという開発プロセスの問題がありました。さらに、開発を進める中で新たな検討事項が生まれ、それらの変化に対応できていませんでした。
これにより、スプリントのスケジュールが遅延したり、リリースが計画通りに進まないケースもありました。
テストケースレビューでの指摘が多い
仕様の曖昧さや認識のズレから、テストケースのレビュー時に多くの指摘が出てしまい、手戻りが増えることがありました。これは各自が仕様書や設計書を読み込む中で、理解度に差異が生じていたためです。
レビュアーも、概要レベルではなくテストケースレベルまで詳細化されたものを最初にレビューするため、どのユースケースのパターンなのか、前提条件はどうなっているのかといった確認に工数がかかっていました。
さらに、実際にテストを進めると設計書に記載されていない挙動や記載と異なる箇所が見つかり、蓋を開けてみると開発者とPO間での決定事項によって実装が正しいというケースも発生していました。その結果、メンバーの負担が増加し、本来の作業に集中できない状況が発生していました。
プロダクトごとのテスト密度や品質のばらつき
組織全体に目を向けると、あるプロダクトではテストは実施しているものの障害が多く発生し、別のプロダクトではテストケースが細かすぎて時間が掛かりリリースが遅れるなど、バランスが取れていない状況でした。
これらの課題に対して、私たちが取り組んだ解決策の一つが『受入基準（Acceptance Criteria）』の導入です。この取り組みによって、課題解決の糸口が見えてきました。
受入基準（Acceptance Criteria）の導入
受入基準（Acceptance Criteria）とは
Acceptance Criteriaとは、日本語で受け入れ基準といいます。国際ソフトウェアテスト資格認定委員会（International Software Testing Qualifications Board）の用語集では以下の通りです。
ユーザー、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない基準。
仕様や要件が曖昧なまま進行すると、開発後に『こんな動きだと思っていなかった』という認識のズレが発生します。このズレを未然に防ぎ、チーム全員で共通理解を持つために役立つのが受入基準です。
例えば、ログイン機能を開発するとき、受入基準がなければ『ログイン後にどの画面に遷移するべきか』『エラーが出る場合のメッセージ内容はどうするか』といったポイントが曖昧になり、後からズレが発生することがあります。受入基準を決めておけば、これらの疑問点を事前に解消し、チーム全員で同じゴールを共有できます。
受入基準の重要性
受入基準は、機能がどのように動作し、どのように見えるべきかを具体的に定義したものです。これを事前に決めておくことで、開発者とQAの連携が強化され、曖昧な仕様や認識のズレを防ぎつつ効率よく進められると考えました。
受入基準を取り入れることで、以下のような大きな効果が期待できます。
共通認識が取れる
PO・開発者・QAの間で受入基準を通して共通理解が生まれます。 また、共通して確認する場所が集約されることで情報が錯綜せずに一元管理されます。
機能の設計ミスを防げる
必要なユースケースや仕様が明確になり、大事なポイントを見落としたまま最終段階まで進んでしまうような事態を防ぎやすくなります。
また、要件や仕様が曖昧なままだと、「この部分はこう動くべきだろう」と推測に頼ることが増えて思い込みにより認識齟齬が生まれることもありますが、受入基準があることで、求められている動作をはっきり理解しながら作業を進められるようになります。
QAがテストすべきポイントを把握できる
一見正常に動いている機能でも、プロダクトオーナーの期待とは違う挙動をしている場合があります。受入基準がないと、QAがその違いを指摘するのが難しくなってしまいますが、基準が明確であれば、テスト中の疑問点を減らし、正確な確認ができるようになります。
受入基準の作成プロセス
開発者/QAが主導して作成：開発者/QAが中心となり、協力して各機能の受入基準を詳細に定義します。基本的な要件はプロダクトオーナーが提示し、それを開発者とQAが具体化します。
具体的な基準の設定：シナリオベース（Given/When/Then形式）やルールベース（チェックリスト形式）で受入基準を明文化します。
シナリオベース
主にユースケースに沿った形でユーザーの行動を詳細に記載します。- 例）ログイン
- Given：ユーザーが登録済のメールアドレスとパスワードを入力したとき、
- When：ログインボタンをクリックすると、
- Then：ユーザーは管理者画面のTOPに遷移する。
- 例）ログイン
ルールベース
その機能がどのように見えるか／機能するかについてのシンプルな「ルール」のリストとなります。- 例）ログイン
- メールアドレスフィールドは有効なメールアドレスのみ受け付けること。
- パスワードは8文字以上の英数字記号であること。
- ログインボタンは常に青色で表示され、クリック可能であること。
- 例）ログイン
PO・開発者・QA間で認識齟齬が無いか確認：PO・開発者・QAの3者で認識を揃えるため、確認することで認識を揃えています。曖昧な部分があればステークホルダーを召集して別途ミーティングで詳細を詰めるようにしています。
QAにて品質リスクを設定する：上記のシナリオ、ルールで品質リスクがあるものをテストケース作成前に分類します。
- 品質リスク高：業務遂行やシステムに大きな影響を与え、業務遂行不可になる可能性のある部分
- 品質リスク中：業務遂行に影響を与えるが、代替手段などがあり業務は遂行できる部分
- 品質リスク小：ユーザー体験や見た目に関する影響があるが、業務遂行にほぼ影響を与えない部分
受入基準に基づいた開発とテスト
開発者の取り組み
ユースケースや制約について、受入基準を参考にしながら機能を設計/実装します。
設計や実装中に新たな検討事項が発生した場合は、決定事項などを受入基準に追加しながらコミュニケーションを取っていきます。
QAの取り組み
受入基準をもとにテストケースを作成し、実装された機能が仕様通りに動くかを確認します。無効な入力に対するエラーメッセージの表示など、細かい部分までテストを行います。
フィードバックと修正
受入基準やテストケース作成時に問題や改善点が見つかった場合は、すぐにフィードバックして必要な検討や修正を行い、仕様の考慮漏れの可能性や異なる点を早期に対応します。
施策導入の効果
品質向上と安定したリリース
受入基準の導入により、明確な基準に基づいて開発が進められるため設計漏れや誤解が減り、不具合も少なくなりました。 また、仕様が曖昧だった場合に発生しやすい「想定外の動作」や「見落とされた機能」が受入基準により事前に防止され、受入基準に沿ったテストを行うことで、より正確な品質保証が可能になりました。 この取り組みによって、プロダクトの品質が目に見えて向上し、障害もぐっと減ったと実感しています。
効率的なプロジェクト管理の実現
開発者とQA、プロダクトマネージャーの間の認識が統一され、曖昧さが減り、フィードバックのやり取りがスムーズになりました。
また、これまでテスト実施時に起きていた仕様の考慮漏れによる手戻りが無くなり、不確実性が減少したと感じています。
チーム全体の生産性向上
開発者とQAが一緒に協力することで、手戻りが減り、生産性が向上したと感じています。 明らかに想定と違っているところが早めに分かったり、受入基準作成に伴うコミュニケーションを通じて、考慮してなかった要件に気づけることもありました。 知識の共有も進み、各メンバーが自身の作業に集中することでより高いパフォーマンスを発揮できるようになりました。
まとめ
受入基準の導入は、スクラムチームにおける開発者とQAの連携を強化し、プロダクトの品質と開発効率を大きく向上させる一つの手段であったと感じました。
私達のチームでミニマムに導入してみましたが効果を感じられたので、他チームでも続々と導入を進めているので実践して良かったと感じています。
しかし、まだ改善すべき課題は残っています。
例えば、
- プランニングの段階で受入基準作成を出来ていない
- 設計書と内容が被ることがあるので2重管理になっている
- 不確実性の高い改修の場合に受入基準を作成するのが難しい
などが挙げられます。
受入基準はチーム全体の共通認識を形にし、プロジェクトの成功を支える強力なツールです。まだ課題は残りますが、導入の効果を実感できたからこそ、これからも改善を続けていきたいと思います。受入基準をまだ使っていないチームにも、ぜひ試してみてほしいと思います！
おわりに
アソビューでは、一緒に働くメンバーを大募集しています！カジュアル面談も実施しておりますので、少しでもご興味をお持ちいただけましたら、ぜひお気軽にご応募ください！
