私は2019年に認定スクラムマスターの資格を取得し、これまでに複数の案件でアジャイル開発における品質保証活動に従事してきました。
アジャイル開発は従来型開発（ウォーターフォール開発など）と異なり、"スピード"が早いことが特徴としてあります。
従来型開発に比較して、要件定義から実装・リリースまでの期間が早いアジャイル開発でのQAを複数やってきて、
「ここが従来型開発とは大きく違ったこと」について思ったことをざっくばらんに紹介したいと思います。
①開発ドキュメントが（ほとんど）ない
以下に掲載しているのは、有名な「アジャイルソフトウェア開発宣言」です。
このアジャイルソフトウェア開発宣言を読む時に、人によっては左記を軽視する方もいらっしゃいます。
「とにかく動くソフトウェアを！」となってしまうことが多々あり、
そうなってしまうと起きてしまうのが、「ドキュメントが存在しない」もしくは「ドキュメントはあるが更新されていない」です。
従来型開発でのＱＡは仕様書などのドキュメントからテストを進めていきますが、
アジャイル開発案件では、その方法が取れないので、その解決方法を考えることが重要なのだなと思いました。
※どのように解決したかを④に記載しようと思います。
②それぞれ独自のアジャイル文化を持っている
アジャイル開発とは、「アジャイルソフトウェア開発宣言」を基本とする開発手法のことで、
具体的にどのようなプロセスで開発を行えばいいのかまで言及されていません。
そのため、数多くのフレームワークが存在します。
代表的なものだと 「スクラム」 です。
ただ、このスクラムに「カンバン」を合わせた 「スクラムバン」というやり方があったり、独自の進化を遂げていたり、
企業や組織、チームによってさまざまなアジャイル開発のプロセスが存在します。
従来型開発では、ある程度QAプロセスが似通った現場が多く、取り組み手法をほぼそのまま横展開することができました。
アジャイル開発案件では、組織が変わると文化が異なる場合が多く、
各組織のにあったQAプロセスを構築する必要があるだと思いました。
（合わないQAプロセスでやっていくと、開発者とQAとでスピード感が違ってしまい不協和音をとなってしまう と思っています。）
③QAエンジニアに求められている領域が広い
これまで多くの現場でQAエンジニアとして活動してきて、
多くの場合が「システムテスト」や「ユーザー受入テスト」などのUIに対してのQA活動がメインでした。。
これがアジャイル開発案件では、場合によっては要件定義の場からQA目線でのコメントを求められたり、
デザインを決める場に同席したりとこれまでよりも、上流工程から関わる機会が増えました。
いわゆる シフトレフト の取り組みが非常に大切で、単にテストの事を考えるのではなく、
「利用者の価値」をどれだけ考えてQA活動するのかを要求されるのだと思いました。
④これまでのQA技術をより進化させる必要がある
従来型開発のプロセスが異なること、そのプロセスに合わせられる柔軟性、幅広い知識が必要なことがより重要なのだと思っています。
そのためには、QA技術をより進化させる必要があるのだと思いました。
具体的には、モデルベースドテスト（MBT）や探索的テストにおけるレベルアップ。
ドキュメントがないシステムをテストする上でモデル化は非常に有効な取り組みだと思っており、
このモデルを上手く活用することで、より早くより価値を提供できるQA活動が出来るのではと思っています。
また、ドキュメントが無くても実施できる探索的テストについても有効だと考えています。
もちろん、ドキュメントがあればこれまでの取り組み方でも良いと思いますが、それではスピードについていけないこともあります。
私個人の取り組みの中で、よりスピード感を追求している組織では、このモデルベースドテストと探索的テストはとても有効的に活用が出来ました。
その他にも、何か有効な手段はないのかと日々考えながらQA活動をしており、
もっともっとQA技術を進化させる必要があると日々考えています。
おわりに
ここまで、私個人が思ったアジャイル開発におけるQA活動についてを書いてみました。
まだまだアジャイル開発におけるQA活動は課題が多く、解決すべき問題も多岐に渡ります。
正直なところ、QA活動としてやることは変わっていないと思っていますが、
考え方や意識は異なっていて、そこに上手く合わせることが大切なのだと思っています。
いわゆる「アジャイルマインド」ですね。
この「アジャイルマインド」のQA版を考えられれば、アジャイルQA人材育成にも使えると思っています。
これについては、またどこかでまとめられたらと思っています。
以上