こんにちは、
プロダクト開発本部／エンジニアリング部の桜井です。
3か月前に QA エンジニアとして Booost に入社し、このたびオンボーディング期間を終えました。
短期間ではありますが、プロダクトの仕組みや開発フローを理解していく中で、品質に関する課題と、
今後中長期的に取り組むべき領域が明確になってきました。
この記事では、
・スタートアップにおける品質への取り組みに関心がある方
・Booost の品質改善に興味を持ってくださっている方
に向けて、現在の課題と、それらに対して特に重要度が高い「デグレ対策」に焦点を当てて紹介します。
1. Booost のプロダクトと QA 体制
前職では一人目の QA/SET として TestOps を推進していましたが、
Booostでは現在QAエンジニアが3名在籍しています。
複数メンバーで品質改善に取り組める体制が整っており、個人では踏み込みにくかった領域にも組織として取り組める環境があります。また、品質に特化した新しい部門も立ち上がり、
横断的な品質強化に向けた活動が始まっています。
2. 現状の品質課題とその背景
現在の主なテストフローは以下の通りです。
・エンジニア：単体テスト → 結合テスト → システムテスト
・PdM：受け入れテスト
一見すると一般的な流れですが、運用面では次のような課題が浮かび上がっています。
◻️新規要件の品質が設計段階から十分に作り込まれていない
→要件の粒度が揃っていないことで、仕様不整合や認識差分が後工程で発生しやすい
◻️テスト観点の体系化が不十分で、属人性が残っている
→観点が整理されていないため、レビューやテストの抜け漏れが発生するリスクが高い
◻️リソース不足によりテスト工数を十分に確保できない場面がある
→結果として、仕様レビューやテストケースのレビューが十分に機能しない
これらは単なる“テストが不足している”という話ではなく、
「素早く安全に変更できる状態」を損ないやすい構造的な問題だと考えています。
表面的なテストを追加するだけでは解決できず、「どれだけ早く・安全にリリースできるか」という開発組織全体の健全性にも関わります。そのため、これらの課題に対して、
チームとしては「品質を仕組みで底上げする」ことを主軸に改善を進めています。
3. なぜデグレ対策を最優先に位置づけるのか
品質課題の中でも、デグレを最優先とすべき理由は明確です。
（1）既存機能の毀損はユーザー体験を大きく損なうため
新規機能が未完成であることより、
既存機能が壊れるほうがユーザーの信頼を失う影響が圧倒的に大きくなります。
Booost は多くの会社で利用され、データの入力・承認・集計が複雑に連動するため、
一点の不具合が広範囲に波及しやすい特徴があります。
（2）プロダクトの構造上、デグレ検知を「ユニットテストだけ」でカバーすることが難しい
Booost では、
・SQL 集約ロジック
・行指向の DB 計算
など、アプリケーションの特性上ユニットレベルだけでは網羅しにくい領域が多く存在します。
「理想のテストピラミッド」をそのまま適用することが難しく、
後方保証としての結合テスト・E2E・API レベルの検証に投資する価値が高い という判断に至っています。
4. デグレ検知の現状と、これから取り組むべき改善
デグレは本来、複数レイヤーで防ぐべきものです。
・単体テスト
・結合テスト
・システムテスト
・受け入れテスト
・E2E
・手動回帰
しかし現状では、E2E の網羅性がまだ十分ではなく、レイヤー間の役割分担も最適化されているとは言えません。
5. 今後の強化ポイント
品質改善に向けた取り組みは多岐にわたりますが、
とくに 「不具合が発生した際に、リリース前やリリース中の段階で確実に気づける状態を作ること」 を重視し、今後は以下の方針を進めていく予定です。
・受け入れ条件の整理
仕様の期待値を明確にし、テスト観点の作成や自動化の基準として扱えるようにする。
・テスト観点の体系化
複雑な計算処理や月跨ぎなど、影響が大きい領域を中心に観点を整理し、テスト資産として再利用しやすい状態にまとめる。
・E2E／API 自動化基盤の強化
画面操作に依存しない API レベルのテストや、安定した E2E 実行基盤を整備し、回帰検証の自動化を進める。
・CI/CD へのテスト統合
API テスト・E2E などを段階的にパイプラインへ組み込み、変更の影響を継続的に確認できる状態を整える。
これらの取り組みを通じて、
「テストがプロセスとして継続的に回る状態」 を作り、
品質の維持・改善を仕組みとして支えられるようにしていきます。
6. おわりに
品質は QA チームだけが担うものではなく、
プロダクト全体で作り上げていくものです。
Booost のプロダクトは複雑性が高く、機能間の依存も多いため、
「努力で守る品質」ではなく
「仕組みで維持できる品質」
へ転換していくことが今後さらに重要になっていくと考えております。
この記事が、Booost の QA に関心がある方、
あるいはスタートアップで品質向上に取り組む方にとって、
何かしらの参考になれば幸いです。
今後も取り組みを継続的に発信していきます。
Discussion