QA to AQに挑戦するチームの話
はじめに
とにもかくにも、QA to AQを読みましょう。
この記事は
- スプリントの頭では開発者が開発し、スプリントの終わりにQAがテストをする
- 品質保証はQAがテスト実施で担保してくれる
- 自動テストはとりあえずカバレッジを上げるため
そんなチームの開発とQAの障壁の解体について実践している内容の備忘録です。
まだまだ試行錯誤中ですが、今までに得られた変化と実践について振り返りも兼ねて記録しています。
QAtoAQを元にした取り組み
機能開発が進む一方で、テストサイクルの遅さや品質のばらつきに頭を悩ませているチームは少なくないのではないでしょうか。
私たちのチーム（TL（私）、PdM、開発者5名、QA2名のチーム）でも、開発とQAの役割が明確に分かれていたことで、品質保証のプロセスが分断されておりいくつかの課題に直面していました。
これまでは開発者がフィーチャーに取り掛かると同時に、QA設計者が仕様書をもとにテスト観点を洗い出し、詳細なテスト項目書を作成。
開発完了後にQA実施者がその項目書に沿ってテストを行う、という流れでした。
しかし、以下のような課題が浮き彫りになってきました。
- 属人的なテスト設計と実施により、開発がスケールしてもQAが追いつかない
- 開発者が「テストはQAの仕事」と認識しており、品質への主体性が希薄
- QA側は仕様書からテストを設計するため、背景や設計意図の変遷が把握しきれず、変更に弱い
こうした状況の中で、私たちは「QAと開発の壁を壊し、品質をチーム全体で担う」方向に舵を切ることにしました。
その際に参考にしたのが、冒頭リンクを載せた「QA to AQ」という考え方です。
このフレームワークに沿って、チームにフィットする形での改善を模索し始めました。
なぜ「壁を壊す」必要があるのか
開発とQAの間にある「役割の壁」は、一見効率的な分業体制のように見えますが、実際には情報の断絶や責任意識の偏りを生み出し、プロダクト全体の品質に大きな影響を及ぼします。
私たちのチームでも、まさにこの壁が原因となり、仕様の意図が十分に伝わらないままテストが設計・実施されたり、開発者が品質に対して受け身になってしまったりという問題が顕在化していました。
過度な職能の最適化は組織のサイロ化を産んでしまいます。
「品質はチーム全員で担うべき」というマインドは、本来であれば当然の姿勢であり、時代によって変わるようなものではありません。
しかし現実の現場では、役割分担や工数管理の中でその意識が薄れてしまうことも多く、「QA＝品質担当者」という暗黙の前提が存在していることもあるでしょう。
この辺りについては、QA to AQの2章「中核」で深く語られておりますので、ご一読ください。
このサイロ化（というまでひどくは無かったがあえてそう呼ぶ）状態を抜け出すために、QA to AQパターンの中でも特に「QAを含むOneチーム」「品質作業の分散」「できるだけ自動化」「品質エキスパートとシャドーイング」「重要な品質の発見」に着目しました。
具体的な取り組み紹介
QAを含むOneチーム
以前の私たちのプロセスでは、「仕様書が完成したタイミング」で初めてQAがテスト設計に入っていました。
これは一見自然な流れに思えますが、振り返ってみると、この構造こそが品質をすり抜けさせる大きな原因でした。
仕様が完成したあとでは、機能自体の設計や構造に対してQAが影響を与えることはできません。
つまり、テスト観点が設計に反映されず、「実装されたものをどうテストするか」に終始してしまうのです。
これは無意識のうちにQAを出荷のための最終工程と捉えている証左でもあると感じました。
この課題に対し、私たちは開発プロセスを見直し、以下のような運用に切り替えています。
- 詳細な仕様書ではなく、DesignDocをベースに設計段階からQAが関与する
- DesignDocには背景・課題・選択肢・設計判断などが含まれており、QAはその時点で疑問点を出し、テスト観点を練り始められる
- 仕様が「固まってから」ではなく、設計が「固まりつつある段階」でテスト視点が入り込む
この変更により、QAはテスト観点をより自立して作成できるようになりつつも、設計意図を的確に捉えた設計が可能になりました。
また、開発者側も「QAからのフィードバック＝仕様が甘い部分の検知」として捉えるようになり、品質を設計に内包するカルチャーが徐々に根づき始めています。
品質作業を分散、できるだけ自動化
QA設計者が観点表を作成した後、テスト実施は今まで別の QA担当者が実施していましたが、これを開発者自身が行う運用に切り替えました。
これにより、開発者は観点を確認しながら、自らの実装に対して動作確認を行うプロセスが定着してきました。
開発者がテストパターンや観点表に触れる機会が増え、開発者自身もテスト設計に関する知見を得る機会にもなっていくと期待しています。
また、単に手動で確認するだけではテストの持続性や網羅性が担保されないため、観点表に記載されたテスト観点が、「自身が実装した自動テストで担保されているか」を開発者自身が確認するフローを設けています。
• 観点A → ユニットテスト内で網羅されているか？
• 観点B → 結合テストに含まれているか？
• 網羅されていなければ、自動テストを追加する or 手動で記録を残す
このようなプロセスを明確化したことで、テスト観点がそのまま仕様化・再利用される状態に近づき、開発とテストの一体化が進んできました。
また、観点表がそのまま「自動テストのレビュー項目」としても活用されるようになります。
この辺りはさらにAIエージェントの活用も推進しており、QAが挙げた観点表をAIに分析させ、自動テストの項目として不足がある部分を追加するようエージェントに依頼するなどして開発者の負荷軽減も行えています。
重要な品質の発見
チーム内ではプロダクトに対する品質トレードオフスライダーを定義しています。
それによると私たちのプロダクトは使用性（使いやすさ、UI/UX、利用時の品質特性）がかなり重要な品質特性であると定義されており、これはチーム内でも納得感の高い定義です。
にもかかわらず、特に使用性に対するテストは行われておりません。
というよりも一般的なテスト項目の観点で使用性をテストするのは困難であり、より専門性を持ったユーザビリティテストなどが必要になります。
QAがフィーチャーのテストに終始している状態ではこのような取り組みの実現は難しいです。
そこで、これまでの取り組み（主に「品質作業の分散」）によりQAの余力を作り、使用性にフォーカスしたチャーターを元に探索的テストを実践していこうとしています。
この取り組みはまだ道なかばであり、具体的な効果を実感できるレベルには到達してませんが、プロダクトの価値（重要としている品質特性）に対してのアプローチを行えているという期待値はチーム内でも高く、特にQAからも高いモチベーションを感じています。
現時点では私が率先して「この挙動は明らかに不適切」「統一感はあるが画面要素として邪魔」「明確な入力項目なのに初期値が入っていないのは不親切」などの不具合を挙げて、今までは「仕様書通りだから」と見逃されていた部分のUX不具合をどんどん報告して良いんだ！、という空気作りが進んでいます。（行きすぎると「プロダクト批判」みたいに捉えられてしまい組織の雰囲気に悪影響があるかもしれないので、穏便に、でも的確に、を心がけています。）
機能性のテストというは開発者・QA共に得意な領域だと思います、そこを一つ飛び出した先に「品質」というのはまた違ったスキルが必要で難しい分野だと実感しています。
まとめ
QAtoAQを読みましょう！
プロダクト品質チャンピオンになりましょう！
アジャイル時代のQAは、納品に向けたチェック工程ではない、という意識と取り組みがどんどん広がっていくと、より良いプロダクト作りが捗りますね。
Discussion