先日JaSSTソフトウェアテストシンポジウム-JaSST'21 Tokyoで「アジャイル開発にQAはホントに要らないのか？」という企画セッションが行われました。
本記事では、上記セッションに関連して、アジャイル開発における独立したQAチームの要否、または、開発チームにおけるQAエンジニアの要否について、私見を述べたいと思います。開発チームやQAチームの体制について考えている方に少しでも参考になれば幸いです。
（以下のぱと隊長さんの記事を参考にさせていただきました。ありがとうございます）
目次
結論
独立したQAチームや開発チームにおけるQAエンジニアの要否は、高品質なプロダクトを素早くリリースするために会社としてスケールしやすい体制を選べばよい。
QAチームやQAエンジニアが不要な開発チームの方が開発者に品質向上の意識を持たせやすく効率が良いかもしれない。
ただし、QAエンジニアが不要な開発チームの作りやすさは、求められるテストスキルの高さや開発者のテストスキルの向上のしやすさといった事情で変わる。
話の前提
話を単純化するため、背景や言葉の定義は以下のものとして話を進めます。
対象の会社
Webサービス、または、ネイティブアプリを提供する事業会社で社内に開発チームを持つ。
独立したQAチーム、または、QAエンジニア
いわゆるシステムテスト（E2Eテスト）工程をメインで担当するテスト担当者。テスト計画、テスト分析、テスト設計、テスト実施等を行う。テストスキルが高い。コードを書く、CIの環境を作る、といったことは苦手。テストの仕事が好き。
テストスキル
テスト技法を知っているだけでなく、何をテストすべきかの観点を洗い出すことができるスキル、効率的にテストケースを削減できるスキル、仕様の妥当性を確認するスキルなど、質の高いテストを行うことができるスキル。
QAエンジニアが不要な開発チーム
開発者のみで品質が高い状態でプロダクトをリリースできるチーム。テストも全て開発チーム内で行う。システムテストは開発を担当した人自身がやっても良いし、他の開発者に依頼しても良い。必ずしもチームメンバー全員のテストスキルが高度である必要はない。
ソフトウェアのテストに関する時代の変化
最終工程での欠陥検出に注力する時代から、各工程で欠陥を検出する時代へ
例えば、要求定義で混入した欠陥を最終工程のテストフェーズで検出した場合、要求定義工程で欠陥を検出した場合よりも修正コストが膨大にかかり効率が悪い。そのため、ソフトウェア開発の各工程でテストを行うことで最終工程での品質を高め、欠陥の修正コストを減らして開発スピードを上げる*1*2。
開発するものを全て計画してから開発する時代から、顧客からのフィードバックを得ながら少しずつ開発する時代へ
顧客の欲しいものが不明確であり市場のニーズの変化も激しい時代となった。そのため、最初に顧客の要求を全て定義して開発する従来の手法よりも、少しずつ開発・リリースを実施して顧客のフィードバックを得ながらプロダクトを発展させていく手法の方が顧客の要求を満たすものを作りやすい。
この新しい手法は、リリース回数が増え、顧客からのフィードバックに基づく仕様変更も絶えず行われる。また、市場からプロダクトに対するフィードバックを得る場合は、リリース毎に製品として利用できる品質にする必要がある。そのため、リグレッションテストがリリース毎に必要となる。そして、リリース毎にリグレッションテストの対象機能が増えるため、リリースを繰り返すと将来的にリグレッションテストの工数がボトルネックになってくる。したがって、リグレッションテストの自動化(E2Eテストに限らない)が必要になってくる。
以上の時代の変化は、開発者がコードレビューや自動テストの開発といった品質を向上させるための活動を行うべき理由を説明できます。しかしながら、開発チームにQAエンジニアが必要か否かの理由を説明できていません。
QAエンジニアがいない開発チームのメリット
開発者自身がテストを行いQAエンジニアがそのサポートをするという体制であるAtlassian社の記事*3*4*5などを参考に、QAエンジニアがいない開発チームのメリットを挙げます。
- 開発者自身がシステムテストもすることで、開発者自身に品質に対する責任の意識が強制される。その結果、開発者は品質を向上させようとする意識が働く
- 開発者自身がシステムテストもすることで、自分が苦労して実施するテストを効率化しようとする意識が働く。例えば、システムテスト前の品質を向上させて必要なシステムテスト量を減らす、システムテストを自動化するなど
- テスト担当者を置かないことで、テスト担当者のリソースに依存したテスト工程のボトルネックが生じなくなる。必要ならば、開発チーム全員でテストする
上記を見ると、QAエンジニアを不要とする開発チームにする主な理由は、開発者のマインドセットを変革し、開発者に効率的な活動を促している点にあるように思います。なので、開発者のマインドセット次第では、QAチームやQAエンジニアが存在しても、効率的な開発を行う開発チームになることは可能だと思います。
QAエンジニアが不要な開発チームを作る難易度
QAエンジニアが不要な開発チームを作る難易度は、開発チームに求められるテストスキル、テストスキルの向上させやすさによって変わります。
プロダクトに求められる品質
プロダクトに求められる品質が高ければ、より網羅的・多面的なテストが要求されるため必要とされるテストスキルも高くなります。
プロダクトの仕様やシステム構成の複雑さ
プロダクトの仕様やシステム構成が複雑であれば、考慮すべきテスト条件が増えるため必要とされるテストスキルも高くなります。
ノーコードやローコードでの開発、SaaSの利用など、すでに品質が担保されている機能を利用する場合は、考慮すべきテスト条件が減少する可能性があります。
テストスキルを補助する仕組みの有無
観点リストやチェックリストといったナレッジ、テストツール*6などを利用すれば、テストスキル不足を補える可能性があります。
開発者のテストスキルの向上のしやすさ
開発者に求められるスキルが多ければ、テストスキル向上に割ける時間が減るためテストスキルを向上しにくくなります。また、社内にテストスキルの高い人がいるか、テストスキルに関する教育体制があるかなどもテストスキルの向上しやすさに影響します。
そして、開発者自身がテストスキルを身に着けたいと思えることも重要です。
もしQAエンジニアが不要な開発チームを作ることが困難であれば、QAエンジニアが必要な前提で上手くいく方法を考える必要があります。
まとめ
以上のような事情を考慮しつつ、短期的な体制、中長期的な体制を検討すると良いと思います。Atlassian社は「Jira Software チームが現在の品質マインドセットのレベルに到達するには 5 年かかりました」と言っていますので長期戦です。
独立したQAチームやQAエンジニアの有無は、高品質なプロダクトを素早くリリースするための手段であって、目的ではありません。また、高品質なプロダクトを素早くリリースするために必要であれば、開発者やQAエンジニア、ここに記載のないプロダクトマネージャーやデザイナーなどの役割も自由で良いと思います。大事なことは、スクラムガイドや海外の動向だけではなく、各人が自分たちの状況を理解し、自分たちで理想のチームを考えることだと思います。本記事の内容も正解ではありません。
本記事が皆さんの理想のチームを考える上で少しでも参考になれば幸いです。
