こんにちは、ニーリーでSET（Software Engineer in Test）を担当している宮内です。
本記事では、私が入社して最初に取り組んだ「E2Eテスト自動化ツールの移行」について、特に「なぜ移行を決断したのか」という背景と、「移行の準備・設計で工夫したこと」を中心に、その舞台裏を書きます。
E2E自動化ツールの移行は、単にツールを置き換えるだけではありません。現場の運用や開発体制にも大きな影響を与える、重要な取り組みです。
「ノーコードツールからコードベースへの移行を検討している」 「E2Eテスト自動化の体制づくりに、まさに今悩んでいる」
そんな方々にとって、私が歩んできた道のりが、少しでも参考になれば幸いです。
1. なぜ移行を決めたのか
壁1：コストと実行回数のジレンマ
移行を検討する最初のきっかけは、コストの問題でした。もともと使っていたノーコードツールは従量課金制であったため、テストの実行回数には常に制限が伴います。事業の成長と共に「もっと頻繁にテストを回したい」という現場のニーズは高まる一方、「でも、コストがかかる…」と実行を躊躇してしまう。そんなジレンマを抱えていたのです。
プロダクトの品質を守り、さらに向上させていくためには、コストや回数を気にせず、必要な時にいつでも気兼ねなくテストを実行できる環境が不可欠でした。
壁2：「手軽さ」の裏に潜んでいた、運用の複雑さ
ノーコードツールは当然ながら手軽にテストを作成できる点が大きな魅力でした。しかし、実際の運用では「どうしてもコードでなければ対応できない場面」が頻繁に発生していました。
例えば、日付カレンダーの複雑な選択、審査結果に応じた条件分岐、バーチャル口座への入金処理など、ノーコードの枠組みだけでは対応しきれないケースが次々と出てきます。その結果、「ノーコードのシナリオ＋それを補うためのコード」という二重管理が生まれ、運用は日に日に煩雑になっていきました。
「これなら、最初からコードで一元管理した方が、むしろシンプルで効率的なのではないか？」 そんな思いが、日に日に強くなっていったのです。
これらの壁を乗り越えるため、新たなツールを探し始めました。
- コードベースで、柔軟かつ一元的にテストを管理できる
- 実行速度が速く、並列実行など運用の自由度も高い
といったメリットを持つPlaywrightへの移行を決断しました。
その結果がこちらです。移行により、実行速度は平均で88%も向上しました。
（ちなみに、移行当初はあまり意識していませんでしたが、TypeScriptでテストを記述するようになったことで、型安全による品質向上や開発効率アップといった、嬉しい副次効果も得られました。）
2. 移行プロジェクト、まず何から始めたか？
今回の移行は、テストシナリオの構成を根本から見直す時間はなかったため、「既存のテストシナリオを、いかに早くPlaywrightで実行できる状態に持っていくか」にフォーカスしました。
まず取り組んだのは、「移行後に最低限クリアすべき条件」を定義し、そこから逆算してマイルストーンを引くことです。品質や運用レベルが現在よりも下がってしまうことだけは避けるため、各フェーズの目的とタスクを整理し、計画的に準備を進めました。
半年間の道のり：マイルストーンの設定
本プロジェクトは、2024年11月から2025年4月までの約半年間にわたる長期計画で進めました。プロジェクトを円滑に進めるため、以下のようなマイルストーンを設定しました。
準備フェーズ（11月中旬〜12月中旬）
- Playwrightのローカル環境構築
- ノーコードツール継続可否の最終検討
- サンプルテスト作成と設計方針の検討など
検証フェーズ（12月〜1月末）
- メール機能の検証
- 主要な業務フローの動作確認
- コードベースの設計
- 必要リソースの算出など
移行フェーズ（2月）
- 全テストケースの本格的な移行実装
最終調整・運用開始（3月〜4月）
- ノーコードツールとの並行運用
- テスト結果のレビュー
- 改善点の洗い出し
- 最終的な完全移行の判断など
各フェーズの目的を明確にしたことで、関係者との認識を合わせやすくなり、計画的にプロジェクトを推進できました。結果的に移行フェーズが少し後ろ倒しになりましたが、もともと最終調整期間にバッファを持たせていたため、無理なく乗り切ることができました。
技術的な壁を乗り越える：事前検証でやったこと
マイルストーンに沿って、特に重要だった事前検証についてご紹介します。
メール機能の検証
ノーコードツールには便利なメール受信検証機能があり、これがPlaywrightで再現できるかは、文字通り死活問題でした。当初は社内のGoogle Workspaceに直接アクセスしようとしましたが、認証の壁が…。最終的にはSREチームに協力してもらい、DynamoDBに蓄積されたメールデータを参照するという方法でこの課題をクリアしました。幸いなことに、もともと社内に存在したメールログシステムを流用できたためスムーズな検証が可能でした。
主要な業務フローでの検証
保証審査やバーチャル口座への入金処理など、当社のプロダクトには「ここが動かなければ話にならない」という重要な業務フローがあります。これらがPlaywrightでも問題なく動作するか、ノーコードツール時代にコードで補っていた処理も含めて、一つひとつ丁寧に検証を進めました。
並列実行の確認
ノーコードツールでは10並列でテストを実行し、テスト時間を大幅に短縮していました。これが失われるのは致命的です。簡単なサンプルテストで確認したところ、Playwrightでもコマンド実行による並列実行が可能であることを確認できました。この時は安堵したのですが、実はこの並列実行で、後に深く悩まされることになります…。
基本導線のサンプルシナリオ作成
「駐車場検索→申込→審査→契約」という、プロダクトの最も基本的なユーザーシナリオをPlaywrightで実装しました。これが問題なく動くことを確認できたことで、「このやり方なら、他の複雑なシナリオにも展開できる」という確信を持つことができ、本格移行への大きな一歩となりました。
これらの地道な事前検証を通じて、「移行しても現場の運用や品質は損なわれない」という確証を得られたことが、プロジェクト成功の鍵だったと感じています。
3. 移行をスムーズに進めるための3つの工夫
限られた時間とリソースの中でプロジェクトを円滑に進めるため、設計や体制面でもいくつかの工夫を重ねました。
工夫1：「完璧を目指さない」コード設計
移行期限が迫る中、「どこまでコードを共通化するか」は大きな悩みどころでした。全てを完璧に共通化しようとすると、膨大な時間がかかってしまいます。
そこで、「使用頻度の高い共通部品はきっちり作るが、そうでない部分はベタ書きも許容する」という現実的な方針を採りました。まずは移行を完遂させることを最優先し、リファクタリングは後から進める、という「割り切り」です。
この判断が功を奏し、最初は2週間かかっていた量のシナリオ作成が、共通部品が揃うにつれて1〜2日で終わるようになり、生産性が劇的に向上しました。
工夫2：社内連携によるリソース確保
テストシナリオを本格的に移行するフェーズでは、どうしても人手が必要でした。外部リソースの活用も検討しましたが、プロダクトのドメイン知識をゼロから学ぶコストを考慮し、最終的には他チームから有識者に期間限定で協力してもらう形で、この山場を乗り越えました。
役割分担を明確にし（私がシナリオ実装、もう一人が共通処理の整備など）、お互いの実装が衝突しないよう密に連携することで、スムーズに開発を進めることができました。
工夫3：日々の開発・保守との両立
移行作業中も、プロダクトの日々の開発は止まりません。弊社は1日に平均2.5回もリリースが行われるスピード感なので、新機能のテスト対応や既存テストのメンテナンスも、並行して行う必要がありました。
実装に集中したい時に限って、テスト環境の準備や関係者への説明といったタスクが舞い込んでくることもしばしば…。プレッシャーを感じる場面もありましたが、その都度チームで相談して優先順位を決め、冷静に進めることで、無事に移行を完了させることができました。
4. これから移行を考えているあなたへ
E2Eテスト自動化ツールの移行は、技術的な挑戦であると同時に、チームや組織を巻き込むプロジェクトだと、身をもって実感しました。この経験を通して、私が「やっておいてよかった」と感じることを、3つのポイントに絞ってお伝えします。
Point 1：判断軸を明確にしておく
「なぜ移行したいのか」「移行によって何を実現したいのか」。この目的を明確にしておくと、プロジェクトの途中で迷った時の道しるべになります。コスト、保守性、実行速度…現場ごとに重視する点は違うはずです。一度、ご自身の理想と現実を棚卸ししてみることを強くお勧めします。
Point 2：事前検証は「しつこい」くらい丁寧に
「今のツールでできている、あの当たり前の機能」が、新しいツールでも本当に再現できるのか。これを早めに確認しておいて、本当によかったと感じています。特に、今回のケースではメール検証や並列実行など、運用に直結する部分は優先的に、そして徹底的に検証しておくと安心です。
Point 3：「完璧」のハードルを、一度下げてみる
最初から100点満点の設計を目指すと、時間も気力もいくらあっても足りません。「まずは移行をやりきること」をゴールに設定し、段階的に改善していくアプローチが、結果的に成功への近道になることもあります。
移行は大きなチャレンジですが、丁寧な準備と現場の工夫次第で、きっと乗り越えられるはずです。
5. おわりに
本記事では、E2Eテスト自動化ツールをノーコードツールからPlaywrightへ移行した際の「決断・準備・設計」の道のりについて、私自身の体験をもとにご紹介しました。
振り返ってみると、決して平坦な道のりではありませんでしたが、その時々の状況に合わせて、周囲と協力しながら柔軟に進めていくことの大切さを改めて感じています。
これからE2Eテスト自動化ツールの移行を検討されている方や、同じような悩みを抱えている方にとって、本記事でご紹介した道のりが、何か一つでもヒントになれば、これほど嬉しいことはありません。
次回の記事では、移行の現場で直面した「具体的な苦労話」や、それをどう乗り越えたのか、そしてPlaywrightの「実践的な運用ノウハウ」について、さらに詳しくご紹介する予定です。引き続きご覧いただけますと幸いです。
