PdM視点で振り返る、CI × E2Eテストがもたらしたチームの変化

この記事はウィルゲート Advent Calendar 2025 9日目の記事です。

こんにちは、開発室の吉田です。

今回は運営しているプロダクトにE2EテストをCIに組み込んだことでリリースの安心感が生まれ、結果として開発チーム全体の生産性が向上した話をPdM目線でまとめてみます。

もともと私たちのチームでは、デグレがたびたび発生し、その影響で毎回エンジニアが手動でリグレッションテストを行う必要がありました。テスト工数は増え、リリースは遅れ、PdMとしても「安心してリリースできない」状態が続いていました。最終的には、デグレが重なることで開発チームに対する不信感が生まれそうになってしまったほどです。

デグレが続き、生産性が低下していた
まずは「何が壊れてはいけないか」を整理した
PdMとエンジニアで相談しながら、必要なテストを決めていった
E2EをCIに入れた結果、生まれた変化
全てをテストしない、という運用ルール
おわりに：安心感が生産性を生む

デグレが続き、生産性が低下していた

当時は、機能追加よりもテストに時間を割くことが多く、明らかに生産性が低下している状況でした。影響範囲の見極めが不十分なまま変更が行われてデグレが発生したり、どこまでテストすれば安全なのかが曖昧だったりと、リリースのたびに不安要素が積み上がっていきました。その結果、毎回時間のかかる手動テストが欠かせず、チームの負担は増すばかりでした。

PdMとしては、より多くの機能をリリースしプロダクトを前に進めたいものの、開発チームの生産性が落ちていることが障害となり、思うように進められない状況が続いていました。品質への不安を抱えながらリリース判断を求められる場面も増え、チーム全体の心理的な負荷も大きくなっていました。

まずは「何が壊れてはいけないか」を整理した

こうした状況を改善するため、E2Eテストの導入を検討し始めました。導入にあたっては「できるだけ少ないコストで最大限の効果を出す」ことを重視し、まずは開発チームと議論しながら、プロダクトとして絶対に動いていなければならない箇所を整理しました。

特に、プロダクトのコア体験を損なわないことを最優先にし、E2Eテストの最初の対象範囲を明確にしました。この割り切りによって、過剰な自動化による保守負荷を避けつつ、確実に守るべきところをテストでカバーする方針を立てることができました。

PdMとエンジニアで相談しながら、必要なテストを決めていった

E2Eテストで何を担保すべきかは、PdMとエンジニアが対話しながら一つずつ決めていきました。特に「この機能が落ちたときにユーザーへどんな影響があるか」「どの操作フローが最も致命的か」「どこまでの粒度をテストすべきか」といった観点で検討を進めました。

また、テストの実行時間や保守コストも考慮し、必要最低限で効果の高いテストケースを選ぶようにしました。こうした認識合わせのプロセス自体が非常に有益で、導入前に感じていた不信感が徐々に解消され、プロダクトの安全性をチーム全員で守っていく意識につながりました。

E2EをCIに入れた結果、生まれた変化

E2EテストをCIに組み込んでから、最も大きく変わったのは心理的な安心感です。致命的なデグレがほとんど発生しなくなり、これまで手動で行っていたリグレッションテストの多くを自動化できたことで、リリースにかかる負担が大きく軽減されました。また、想定外の不具合もリリース前に発見されるようになり、問題を早期に修正できる体制が整いました。

こうした変化によって開発スピードは向上し、プロダクト改善のサイクルも以前よりスムーズに回るようになりました。

全てをテストしない、という運用ルール

現在の運用でも「全てをE2Eで担保する」のではなく、重要な部分に絞ってテストを維持する方針は変わりません。テストが落ちた際のトリアージ方法も整理しており、過剰な自動化による保守コストを抑えつつ、必要な品質を確保するバランスを意識しています。テストケースを追加する場合も、PdMとエンジニアが都度議論しながら判断しています。

この方針により、無理なく「壊れていないことの担保」を継続できる仕組みが維持できています。