バグを見つけるだけがQAの仕事じゃない。上流工程から関わっていって、バグそのものを減らすのもQAの仕事である。
…って話はよく聞くが、そんなん言われても、バグをそもそも減らすって、どうすりゃいいのさ、と悩んでる人がまぁまぁ見受けられるので、今回はそれをテーマにしてみたい。
QAチームは、日々、不具合を見つけます。その不具合を開発チームに報告して、修正してもらうわけですが、修正してもらってオシマイにするのではなく、QAチームに集められた不具合を観察して、そこから「なぜこの不具合が産まれたのだろうか」と想像してみることが大事なのです。
不具合の具体例を集めて、「なぜ不具合が産まれるのか」という問いかけをして、その原因の仮説を立てて、原因を潰すための実行案を考えて、それを実行してみて、結果をモニタリングをする。この一連のプロセスが「上流工程からのQA活動」となるわけです（ちなみに、不具合発生の理由は様々です。採用した技術、プロセス、人、組織の成熟度、などなどが不具合の原因になり得ます)。
不具合を見つけるだけでなく、不具合と向き合うことで、次の一歩に進めるわけですね。
なお、上流工程のQAで一番難易度が高いのは、課題を見つけることでも解決案を考えることでもなく、上流工程のみなさんに、QAの意見をちゃんと聞いてもらうことだったりします。
それを解決するには、QAの意見をちゃんと聞いてもらうためにはどうしたらよいのか？という問いかけして、仮説を立てて、以下略。
んまぁ、そんな感じで、QAって「決められた手順で操作して、決められた期待値が出るかどうかを確認する」という、具体性のカタマリみたいな仕事だと思われてますが、その先には抽象的な問題のカタマリが待ち構えています。そして、その抽象的な問題を解決することが、いわゆる「上流工程からのQA」だと、僕は思うのでした。
