なぜ「QAは遅れて呼ばれる」のか？現場のモヤモヤとROIの壁
森田麻沙美氏は、VoicyのQAリーダーとしてプロダクト品質を牽引しつつ、JaSST Tokyo実行委員やJSTQB翻訳WGで専門性を磨いてきた、品質保証の実践者だ。
森田氏が一貫して掲げるQAの使命は、「エンジニアが品質に自信を持ってリリースできる状態をつくる」こと。QAとは、未知の領域へ進む開発チームの隣で同じ方向を照らす「懐中電灯」のような存在だ。
同時に森田氏は、QAを「Question Asker」として、「問いを立て、曖昧さを明らかにする存在」でもあるべきだと定義する。そこには、QAが適切に機能してこそ開発者は価値創出に集中でき、より良いプロダクトを送り出せるのだという確信がにじむ。
ただし現場では、この理想が十分に根付いているとは言いがたい。森田氏がまず指摘するのは、「QAエンジニアは遅れて呼ばれる」という典型的なアンチパターンである。
現場内で仕様が固まり、実装が最終段階に差し掛かった頃に「そろそろテストが必要だからQAを呼ぼう」と声がかかる。あるいは、QAを「テストだけをする人」と誤解し、初期の議論に参加させない。こうした体制では、QAは完成した仕様を後追いするだけとなり、早期に曖昧さを照らすという本来の役割を果たせない。
しかし「開発側が無理解だと糾弾したいわけではない」と森田氏は説明する。むしろ問題は「どこからQAを巻き込むべきか、現場が判断できない」ことだ。企画・要件定義・設計が高速に流れる開発現場では、適切な参画タイミングを見極めること自体が難しい。その結果、「気付いたら後工程で呼んでいた」という状況が常態化してしまうという。
またQA参画の遅れは、情報の非同期をも加速させる。口頭ベースで決まった仕様変更は共有されにくく、ドキュメントはすぐに実態と乖離してしまう。その結果、QAがテストを開始するやいなや重大な齟齬が発覚したり、最悪の場合、リリース直前になって大量の不具合が噴出したりする事態に至る。これこそが、QAと現場の双方にモヤモヤを残す「現場あるある」なアンチパターンである。
この構造的問題の根底にあるのは、 ROI（投資対効果）の不透明さだ。QAが早期参画するメリットは明らかだが、定量的には説明しづらい側面がある。品質保証は後工程に押し込まれ十分な効果が出ず、QAへの期待も下がっていく。この構造こそが、現場を疲弊させる悪循環の正体だ。
では、この悪循環からどう抜け出せば良いのか。ここからは、森田氏が自身の歩みから得た学びを解説した。
