やまずん(ごまずん)氏のnoteがQAエンジニア界隈でバズリました。

これらの記事をきっかけにいろんな人がいろんな意見なりアンサーブログを書いて・書き始めているのでとても良いなぁと思ってみています。


で、自分が気になったところが、上記「QMファンネルってなんだったの?」記事におけるフェーズゲートQAに関する箇所です。

イマドキのweb系QAエンジニアはフェーズゲートQAに否定的かもしれません。 これはアジリティが求められるプロダクトでは邪魔になるのは間違いではありません。 一方でミッションクリティカルな製品や、人の生死が関わるような製品では、重厚な品質保証としての出荷判定を行い、それらが今生きる我々の財産や人命を守っているということを忘れてはいけないと思っています。 そういったことを忘れてフェーズゲートQAを見下すのはいいプラクティスではないと考えます。(そもそも誰かを見下すことは自己満足以外のメリットはないかもしれません)

これはほんとうにそう。そもそも誰かを見下すことは~はその通りですね。

一方、自分はこれまで「フェーズゲートQA」とか「最後の砦」とか「品質の門番」などと表現されるQAのスタイルや、あるいはそうしたQAを募集するページなどは嫌だ、と思ったり表明したりしていました。

これはもちろん見下してはいません。し、やまずん氏の言う「重厚な品質保証としての出荷判定だって要る場面がある」というのはその通りです。

これらの一見矛盾しそうな点について、整理すると・・・

仮説:フェーズゲートQAにも2通りある

このように考えています。

具体的には

  1. フェーズゲート・門番もするQA
  2. フェーズゲート・門番しかしないQA

があって、会話や文章の中で使い分けが曖昧な気がしています。

自分が「フェーズゲートじゃだめだ」と思っているのは2の、フェーズゲートしかしないQAです。

つまり、たとえば出荷判定や、その手前のリリース前テストなどを行って「OK」とか「だめ、やり直し」と言うだけのQA仕事があったとしたら、それは良くないと考えています。

一応注意点として、「**業界の**の場面ではフェーズゲートに徹するQAに価値があって~」的な話は当然出てくると思います。が、一切例外があってはならないと言われるともはや何も物を言えなくなるので・・・。

話を戻すと。 出荷判定など文字通り「通す・通さない」を判断する役回りだけでは、品質向上や開発組織全体を良くするのにはあまり寄与しないでしょう。昨今のQAの役割に対する一般論としては、開発工程全体を通じ、より早い段階からできることをやるべし、という意見が指示されるように思います。

つまり、フェーズゲート・門番というのはQAがやる可能性のあることのうちのひとつ。 必要に応じてフェーズゲート・門番としての立ち回りもしつつ他のこともやるべきであって、フェーズゲートしかやりませんは貢献度低くなりそう。

というのが私の意見です。