🐣

ワンオペQAがチームを作るまでの半年間を全部書く

に公開

この記事は、2025年3月にワンオペでスタートしたQAチームの立ち上げを、振り返りながらまとめたものです。

テストが属人化し、文書化もされていない状態からのスタートでしたが、半年かけて仕組みやドキュメント整備、採用まで手を広げながら、少しずつチームを形にしていきました。これからQAチームを立ち上げる方の参考になれば幸いです。

半年のタイムライン

2025年3月 ── ワンオペでQAチームスタート
       │
       ├─ リリース前のブラックボックステストを開始(QAチーム用の検証端末の用意なども)
       │
       ├─ ドキュメント整備開始(テスト分析→設計→実行の型)
       │
       ├─ 採用開始(経験者限定 → 応募ほぼゼロ)
       │
2025年4月 ── 採用条件変更(未経験可)→ 応募増
2025年6月 ── メンバー2名内定
       │
       ├─ ポストモーテムのルール整備
       │
2025年7月 ── 1人目のメンバー入社(テスト実行業務)
       │
       ├─ QAプロセスにおける課題洗い出し
       │
       ├─ プロダクト仕様書のGitHub管理開始
       │
       ├─ メイン業務フローのリグレッション用シナリオ作成開始
       │
2025年8月 ── 2人目のメンバー入社
       │
       ├─ 7,8月入社メンバーがテスト設計業務を担当開始
       │
2025年9月 ── 仕様書とテストドキュメントの自動生成フローの運用開始

参考:2025年8月に導入したClaude Codeによるテスト設計業務について
https://zenn.dev/lil_ikeda/articles/5b4ff343a60855

背景と課題感

当時のプロダクトでは、テストがほぼ属人化しており、行った内容を文書化して再利用する仕組みもありませんでした。

PDCAを回す体制も整っておらず、品質に関する学びは個人の経験の中にとどまりがちでした。ポストモーテムは立ち上げの数か月前から実施されていましたが、テストの標準観点には十分に反映されていませんでした。

最初の一歩

立ち上げ当初は、社員は私ひとりだけで、第三者検証機関のメンバーに支援してもらいながら進めることになりました。彼らは当初ドメイン知識を持っていなかったため、設計からテストの実行まで、多くの工程を自分で担当する必要がありました。

まずは「テストケースとは何か」を理解するところから始め、リリース前に機能単位のブラックボックステストを行う体制を整えました。

同時に、テストのためのドキュメントの型を整備しました。テスト分析、テスト設計、テスト実行という基本の流れをベースに、それぞれのフォーマットを決めていきました。

また、主要な業務シナリオについては、リグレッションテストを意識して再利用できるシナリオテストを作成しました。

半年で見えた成果

半年を経て、QAチームは少しずつ形を変えていきました。新たに2名のメンバーが加わり、そのうち1人にはテスト設計を任せられるようになりました。
リリース前にテストを実施するフローはプロジェクト全体に定着し、テスト実行の期間がリリーススケジュールに自然と組み込まれるようになりました。

さらに、ポストモーテムの結果をテストの標準観点に取り込めるようになり、PDCAサイクルを回す体制が整いました。資産性の高いテストドキュメントを作れるようになったことも大きな前進です。

数字で見ても一定の成果がありました。2025年3月から6月の間に、100件以上の不具合が起票されました。控えめに見積もっても、そのうち少なくとも50件程度のインシデントは未然に防げたと考えています。

また、採用条件を変更した効果も出て、ソフトウェアテストに準ずる経験を持つ方から応募が増え、半年の間にチームの基盤を支えるメンバーを確保することができました。

現状の課題と今後の展望

一方で、まだ課題も多く残っています。
以下に記すとおり、課題に応じていくつかの方向性を描いています。

親課題 小課題 今後の展望・対応策
テスト設計の負荷が高く、リリースボトルネックになりがち └ テストケースを画面・要素単位で厳密に管理できず、差分把握が困難 GitHub上でテストケースを構造化し、差分把握を自動化
└ 仕様書とテストドキュメントの形式が異なり、変換に手間がかかる LLMを用いてコードから仕様書・テストドキュメントを自動生成するワークフローの検討
テスト準備作業の属人化 └ テストデータやバッチ処理の準備が属人化しており、作業の標準化が進まない QA専用環境とテストデータ準備ツールを導入し、作業を標準化・自動化
テスト実行環境の制約 └ QA専用環境がなく、テスト実行時とリリース時のバージョンが異なるリスクが残る 専用QA環境を構築し、リリース前の動作確認を安定させる

おわりに

振り返ってみると、この半年は「とにかく動く」ことの連続でした。最初はワンオペで、採用も思うように進まない時期もありましたが、試行錯誤を重ねる中で、ようやく「QAチーム」と呼べる体制が見えてきました。

これからQAチームの立ち上げに挑む方にとって、この記録が少しでもヒントになれば幸いです。

Discussion