アジャイルコーチとして仕事をしているつもりなのですが、いつの間にか、「QA（品質保証）」に関わる仕事が多くなってきて、専門外の自分なりにいろいろ考える機会が多くありました。この記事では、アジャイルコーチとして直面した、「アジャイル開発におけるテスト・品質」の問題をまとめて、それなりの解決案も考えてみたいと思います。考えがまとまっていない部分があるので乱筆乱文であり、思いついたときに更新する可能性があります。
開発とテストの分離と結合
システムや組織において、はじめはひとつだったものが、大きくなってくるにつれて、徐々に分離していくケースは多くあります。小さい方が考えやすいし管理もしやすいので理にかなった行動です。
遠い昔、はるかかなたの銀河系で、アジャイル開発は「アジャイル開発」でした。職能横断的なチームで課題解決に挑む形を取るため、「アジャイル開発」には開発に関連するすべてのアクティビティ（設計、実装、テストなど）が含まれていたのです。
しかし、気がつかないうちに、どこかのタイミングで、アジャイル「開発」とアジャイル「テスト」になってしまったのではないでしょうか？
もしかしたら、開発がエンジニアリングとともに進化を続けたことで、エンジニアリングの恩恵を受けにくいプロダクトマネジメントやテスト・品質などが置いてけぼりにされてしまったのかもしれません（最近は両者とも議論が活発）。あるいは、アジャイル開発には古くからたくさんのロックスターがいたからかもしれません。
2009年には『実践アジャイルテスト（原題： Agile Testing、2009年）』が登場しましたが、「アジャイルテスティング」という言葉もよく考えると微妙です。アジャイル開発とアジャイルテスティング。両者はもともとひとつだったはずですから。
残念ながらこれは避けられないことなのかもしれません。なぜなら、アジャイル開発はどんどん当たり前に（大きく）なっていますし、ソフトウェアテスト産業や、組織の中でのQA部門という形で分かれていたり、開発とテストが分離された組織構造・社会構造が当たり前でもあるからです。今だに開発部門とQA部門の仲が悪い企業もありますからね。アジャイル以前の問題です。
たしかTAKAKING22に教えてもらった気がしますが、『Clean Agile』か何かに「アジャイル開発が登場した経緯として、もともと、ビジネスと開発の分離を問題視していた」というような記述があるようです（不確か）。
おそらく、これからのアジャイル開発に必要なのは、この10年で進んだ分離を結合する作業なのかもしれません。
開発がアジャイルなのにテストがウォーターフォール
前にも書いたのですが、これは2項対立ではありません。なんで軽量なプロセスを採用しているのに、ウォーターフォールでありがちな重量のあるテストをしているのか？という疑問です。普通に考えれば、そりゃぁ、QAがボトルネックになりますよね。
どうやら、世界を見てみると、アジャイル開発において、自動テストと探索テストを導入するケースが多いようです。なぜなら、スピードに品質がついてこれないからです。
「網羅的なテストだと間に合わないから探索テスト」と書くとなんだかネガティブに感じますが、アジャイル開発が適用できるプロジェクト・システム・アプリ・サービスであれば、「探索テストで十分」という見方もできます。網羅的なテストが、過剰品質である可能性は、どんなときも頭の中に入れて置かなければなりません。人間は不安に弱い生き物です。
じゃぁ、探索テストを学べばいいじゃない。と言いたいところですが、日本だとトレーニングも少なそうだし、時間もかかりそうです。しばらくは、自動テストが先に発達し、問題がおき、「ほーらみたことか、手動テストも大切じゃ～ん」みたいな揺り戻しを経験しながら、ちょっとずつ進んでいくんじゃないかと思います。
もしかしたら、その前に、AIやML技術によって探索テストの自動化が進んでいく可能性もあります。さて、人間と機械、どっちが勝つのでしょうか？
QA＝テストすること、QA＝テストする人
「QA組織を作りたい」とか「QA組織が必要」と相談する人には、「あなたが本当に欲しいものはQA組織ですか？」と聞いています。
もし、「開発者がテストをする時間がない」のであれば、QA組織を作っても同じことが起きます。開発者が開発に専念できて、QAがテストに専念できても、分離したことで発生する結合コストが増えてやれる量は減ります。QA組織の管理コストも増えます。むしろ問題が増えるかもしれません。それでもいいのでしょうか？
先にも書きましたが、開発もテストももともとは表裏一体、ひとつです。どちらかを減らすことはできません。テストをする時間がなければ取ればいいはずです。開発者なら自動化も比較的楽に進められます。開発量が少ないなら、開発者を採用すればいいはずです。
もし、必要なものが「QA＝テストすること、QA＝テストする人」であれば、外注するのも手でしょう。自動化してもいいかもしれません。誰がやっても同じ結果になる仕事は、外注や自動化との親和性は高い。
「自動テストよりも、自分が手動でやったほうが速い」という人もいます。ほうほう、それはすばらしい。自分はしませんが、そう望むならやっていればいいと思います。
あなたが本当に欲しいものはQA組織でしょうか？
ホリスティックテスティングのように、開発チーム全体で品質改善活動に取り組むチームはどうでしょうか？ その中で、QAエンジニアが本当に必要になったとき、その責務はなんでしょうか？
ちょうど、Rettyのスーパーアジャイルコーチの@tunepoloがスクフェス新潟で「3年がかりのQA組織立ち上げ」という経験をお話しするそうです。チャーンス。
品質の保証から品質の同意
「開発がアジャイルなのにテストがウォーターフォール」の話に近いものがありますが、アジャイル開発における品質保証というアプローチがそもそも間違っている気がしています。
従来型の開発だと、「これをテストしますからね」、「ほらテストしましたからね」が「保証」といえたのかもしれません。それはそれで間違いではない。
ただ、アジャイル開発だと、仕様通り動くのは当たり前であり、ビジネスインパクトやユーザビリティなど、プラスアルファでどこまでプロダクトを作り込めるかも重要になってきます。
アジャイル開発では、目指すゴールが「ユーザへの価値提供」なので、「保証」ができないのです。
その代わりに、仮説検証のためのA/BテストやBI基盤によるデータ活用や、ホリスティックテスティングにもあるように、フィーチャトグルやデプロイ環境の工夫といった技術活用によって、リスクを低減しようとします。
そのために、どのレベルまでテストするか？といったテストのスコープぎめが重要になります。そのスコープに対して品質合意（Quality Agreement：QA）をチーム全体で行います。
＊
アジャイル開発とアジャイルテスティングがある場合。なぜアジャイルテスティングがおいてけぼりになってしまったのかをずっと考えてきました（参考：アジャイルテスティングが倒せない）。
その理由として思い浮かんだのは、『実践アジャイルテスト』に書かれているような、根強い精神論や組織や産業の問題。そして、スクリプトテストから探索テスト、手動から自動化といったスキルの問題です。
ただ、よくよく考えると、新しいものへのアップデートが追いつかない「変化に弱い問題」が大きいと感じます。
だとすれば、時間が解決する問題なのかもしれません。
旅と子育てとアジャイルコーチのブログ「世界」 