QA採用やQA組織立ち上げの前に、確認したい三つのこと

「最近バグが多いんです。QAをもう一人増やしたほうがいいですよね？」

他のエンジニアリングマネージャーや開発リードから、こんな相談を受けることがあります。私もかつては、「そうですね、まずは採用要件を整理しましょう」と返していました。

ただ最近は、その前にいったん確認させてもらうことがあります。「QAを増やせば品質は上がる」という発想は、本当に成立するのか。そこを少しだけ疑うようになったからです。

「QAを増やしたい」は、実は三つの違うものが混ざっている

私の経験上、「QAを増やしたい」という発言の裏には、性質の異なる三つの実態が紛れ込んでいます。

しかも厄介なことに、本人もどれを意図しているのかを自覚していないことが多いんです。「全部です」と言われることもあります。

ですがこの三つは、それぞれ別の問題で、必要な打ち手も違います。混ぜたまま「採用」というひとつの解にまとめてしまうと、人を増やしても品質は上がらず、増えたQAが疲弊するだけ、という結末になりがちです。

実態1：テストが回らない、という人手不足の悲鳴

いちばん多いのは、シンプルに手が回っていないケースです。

リリース前のテストが終わらない。リグレッションが追いつかない。新機能の検証と既存機能の確認を同じ人がやっていて、毎スプリント残業している。「そもそもちゃんとしたQAができていない」と言う人もいます。

これは確かに、人を増やせば短期的には楽になります。ただ、ここで一段深く問いたいのは、「なぜ手が足りないのか」「なぜちゃんとQAができていないのか」のほうです。

私の経験上、ここには共通する構造があります。

• そもそも開発プロセスの中に、検証工程が組み込まれていない

• チームのケイパビリティを、検証込みで見ていない（開発工数だけで計画を立ててしまっている）

• このプロダクト・この案件で大切にすべき品質特性が定まっておらず、「全部テストしないと不安」というバイアスがかかっている

• どのようにQAをしたらいいかわからない

つまり、足りないのはテスターの人数ではなくて、検証を含めた開発の設計と、何を守るかの優先順位、正しい知識です。ここを置き去りにしたまま増員に走ると、増えたぶんだけテスト範囲がさらに広がっていく、という現象が起きます。たくさん入れたはずなのに、いつも足りない。

増やすこと自体が悪いわけではありません。増やす前に「なぜ足りていないのか」を一度だけ分解する。これだけで、採用の優先度は変わります。

実態2：品質責任を、外に置きたいという願望

二つ目は、もう少し言葉にしづらい実態です。

「QAがいてくれれば、私たちは作ることに集中できる」 「最後にQAがチェックしてくれるから、安心して進められる」

この感覚、わかります。私もエンジニア出身なので、品質の最終責任が自分にあると思いながらコードを書くのは、正直しんどいです。だから「品質を見てくれる人」がいてほしくなる気持ちは、痛いほどわかります。

でも、ここに落とし穴があります。

「QAが品質を守る人」になった瞬間、開発チームの中から品質への当事者意識が、抜けていきます。バグが出たら「QAの見落とし」。リリース後に問題が起きたら「テストが甘かった」。気づくと、品質はチームの財産ではなく、QA個人の責任になっています。

これはQAを増やしても解決しません。むしろ増やせば増やすほど、責任の外部化は進み、最終的には戻せなくなります。

ここで必要なのは人ではなく、「品質は誰のものか」を再定義することです。QAは品質を一人で背負う役割ではなく、チーム全体が品質に向き合えるよう支える役割である、という前提を取り戻す。これは採用の前にやる仕事だと思っています。

実態3：「QAがいれば安心」という、ぼんやりした神話

三つ目は、もっとも気づきにくいものです。

「QAがいないと、なんか不安で」

理由を聞いても、明確には返ってきません。「いてくれたほうが安心する」「他社にもいるから」「いないチームは品質が低いと言われそう」。なんとなくの不安を、QAという肩書きで埋めようとしている状態です。

ここで増員しても、何も変わりません。なぜなら、その人が「何をする役割なのか」が定義されていないからです。

採用された側のQAも困ります。期待されているのが、テスト実行なのか、品質設計なのか、開発プロセスへの介入なのか、誰も明確にしないまま、「とにかく品質をなんとかしてほしい」とだけ伝えられる。これでは、その人が成果を出すのは構造的に難しいです。

また、「第三者が客観的に見ることで、品質が担保できる」という声もありますが、第三者が客観的に見るから、品質が担保できるというのはやや飛躍しています。逆に、第三者はどのような価値がプロダクトにあるのかを理解しにくいので、スコープを絞ったテストというよりはブルートフォースのように総当たりなテストを作るほかありません。

QAが活きるのは、「この役割は何を担い、何を担わないか」が明確なときだけです。安心感のために増やすと、最初に消耗するのは、増やしたQAそのひとです。

それでも、QAを増やす価値はある

ここまで「いったん立ち止まろう」という話を続けてきました。ただ、誤解してほしくないので書いておきます。QAを増やすこと自体に意味がない、というわけではありません。

三つの実態を切り分けたうえでなら、増員はとても強い打ち手になります。

• 開発と異なる専門性（テスト戦略、自動化基盤、品質モデリング）を、チームに補強したいとき

• 品質に意識を割き続ける役割が一人に集中していて、属人化が深刻なとき

• リリース頻度や扱うシステムの規模が一段上がって、現体制では構造的に追いつかないとき

こうした場面では、採用を進めると品質改善は前に進むかもしれません。しっかりとした定義のあとであれば、増員は手堅い投資です。

問題なのは、診断なしに採用に走ること、です。

人数の前に、機能の定義が先

ここまで書いてきた三つの実態は、一見似ていますが、必要な打ち手はまったく違います。

• 実態1（人手不足）→ 検証を含めた開発設計と、品質特性の優先順位、開発プロセスの改善が先

• 実態2（責任の外部化）→ 品質の所有権の再定義が先

• 実態3（安心神話）→ QAという役割の機能定義が先

どれも、採用ではありません。採用が必要になるとしても、それは三つを切り分けたあとの話です。

ただ、ここまで書いてきて思うのは、現場ではこの三つが複雑に絡み合っていて、どれが主因なのかは、外からの情報だけではほとんど見えない、ということです。フレームを当てれば一発で診断できる、というほど単純ではありません。

だから最終的には、こうした診断ができる専門知識のある人に相談したり、EM自身が現場に入り込んでよく観察したりしながら、その現場なりの最適解を見つけに行く。

それしかないと、私は思っています。

チーム品質診断

チームの品質診断が出来ます。ぜひこちらもどうぞ！

日々の気づきはXでも発信しています。 品質文化・組織開発・エンジニアリングマネジメントについて、もう少し短い言葉で日常的につぶやいています。この記事のもとになったポストもXで書いたものです。よかったらフォローお願いします。 → @kubop1992