現場のQAを自分で再現してみた──本番運用レベルのテスト基盤をゼロから作り上げた話

なぜ、このQA基盤を作ったのか（PM視点）

要件が固まりきらないまま開発が進み、
「どこまで作っていいのか」
「何を信じてリリース判断をすればいいのか」
が曖昧なままプロジェクトが進んでしまう。

PMとして関わる中で、
この状態こそが最もリスクが高いと感じてきました。

テストが後回しになること自体が問題なのではなく、
品質に関する判断材料が揃わないまま、決断を迫られる構造
そのものが問題だと考えています。

そこで今回、
「現場で本当に判断に使えるQA基盤」を
個人開発としてゼロから再現してみることにしました。

これは技術デモではありません。
PMとして、判断の拠り所を自分で用意するための試みです。

今回構築したQAフレームワークでは、
単にテストを自動化することではなく、
どの判断を安全に行える状態を作るかを重視しました。

結果として、以下の要素を統合しています。

重要なのは「全部やったこと」ではありません。

この構成があれば、
どこまで変更しても安全か／どこから先が危険かを
早い段階で判断できる
その状態を作ることが目的でした。

最も難しかったのは、
「テストがテスト自身のために壊れる」問題です。

これは単なる実装バグではなく、
設計判断の不足が原因で起きる問題でした。

そこで、

といった、本番QAで求められる設計思想を取り入れました。

机上で学んだ知識ではなく、
作って壊し、判断を修正し続けた結果
ようやく「使える基盤」になった感覚があります。

最終的に、
52のテストを並列実行しても安定して回る状態を
ひとつの到達点としました。

これ以上テストを増やすこともできましたが、
PMとして重要なのは
「ここまであれば、この判断はしてよい」
と言えるラインを引くことだと考えています。

完璧なQAではなく、
判断に耐えうるQA。

その観点で、
この基盤は十分に本番運用レベルだと判断しました。

このQA基盤を作ったことで、
初めて触るプロダクトであっても、

を、短期間で整理できるようになりました。

Wantedly経由で関わる企業に対しては、
以下のような形で貢献できます。

単にテストを書くのではなく、
PMとして、品質に関する判断の土台を整える役割です。

この取り組みを通じて改めて感じたのは、
QAは「守り」ではなく
意思決定を前に進めるための仕組みだということです。

テストが整うことで、
開発者は安心して実装でき、
PMは判断を先送りせずに済む。

その結果として、
プロジェクト全体の速度と安定性が上がる。

これからは、
こうした判断のためのQA設計を、
個人開発だけでなく、実際のチーム・プロジェクトでも
活かしていきたいと考えています。

カジュアルにでも、
「この状況、どう判断します？」
という話ができれば嬉しいです。

現場のQAを自分で再現してみた──本番運用レベルのテスト基盤をゼロから作り上げた話

H M