大規模スクラム×E2E自動テストへの挑戦で見えてきたこと

こんにちは！　アジャイルプロセス推進チームの日下（LINEヤフー株式会社）、岩井（LINEヤフー株式会社）、荒瀬（PayPayカード株式会社）です。私たちは、アジャイルコーチとしてPayPayカードのアジャイル開発を支援しており、現在E2E自動テスト（以下、E2Eテスト）の導入を進めています。この導入における戦略、直面した課題、そしてそれらをどのように克服したかについてお話しします。組織にこれからE2Eテストを導入しようと検討している方や、既に導入済みで安定稼働や運用に課題を抱えている方にとって、お役に立てれば幸いです。

また、私たちアジャイルコーチはLINEヤフー株式会社およびPayPayカードのものづくりに深く関わり、プロセス改善や仕組み作り、最新技術の導入を行っています。過去の事例は以下のリンクからご覧いただけます。

E2Eテスト導入前の状況

E2Eテスト導入前は、次の2つの課題がありました。

新規機能を開発する中で既存機能に対するリグレッションが発生し続ける
複数のチームが並行で開発を進めているため、隣のチームが実装した機能に影響を与えてしまうことに気づけない状況が続きました。
品質担保のためのコストが高い
Tech LeadやEngineering Managerによるレビューを通じてリグレッションの抜け漏れがないかチェックするため、高いオペレーションコストがかかっていました。また新規機能の追加スピードを緩めず品質を高める必要があり、プロダクト品質を担保するコストは増加傾向にありました。

導入に至った背景・経緯

上記の課題に対処するため、私たちはE2E自動テストの導入をすることを決定しました。その理由は以下の2点です。

人に依存しない方法で解決したかった
これまで、プロジェクトごとにチームでテストの範囲を決めていましたが、テスト範囲から漏れた部分が原因で事故が発生しました。人間の記憶に頼って必要なテスト範囲を網羅するのは限界があることが明らかになりました。また、事故の再発防止策として人の経験やスキルに頼るのは再現性が低く、人的コストも増え根本的な解決にはなりません。テストプロセスの自動化は人的コストも依存も低減しつつ品質を安定させられると判断しました。
プロダクトの開発スピードはできるだけ緩めたくなかった
私たちのプロダクトは日々新しい機能の開発が行われており、プロダクト開発を止めて、技術的負債の解消などの品質を高める取り組みに多くの時間を割くことは現実的ではありませんでした。開発スピードを落とすことなく、新規機能開発と品質向上の取り組みを並行して進めるためにも自動化が最適でした。

このように、E2E自動テストの導入は、品質を確保しつつ開発のスピードを維持するための戦略的な選択だと考えました。

何をしたか

E2Eプロセス化の目標を明確にし、それに基づいた戦略を策定しました。この目標は、すべてのスクラムチームが新しいシナリオをE2E（エンドツーエンド）で実装できるようにすること、過去のシナリオも含めてすべてのシナリオがE2Eに対応していること、そしてシステムが安定していることです。この目標を達成するための戦略は、次の3つの柱で構成されています。

全チームのE2Eスキル習得:
すべてのチームメンバーがE2Eテストのスキルを身につけることを目指します。
未対応シナリオの自動テスト実装:
まだE2Eに対応していないシナリオに対して、自動テストを実装します。
CI/CDパイプラインの構築:
継続的インテグレーション/継続的デリバリー（CI/CD）のパイプラインを構築し、テストとデプロイのプロセスを効率化します。

これからは、それぞれの取り組みについて詳しくご説明します。

全チームのE2Eスキル習得

対象チームは10チーム以上あり全チーム導入に向けて取り組んだことは以下になります。

ステップ1: アジャイルコーチの参加
まず、2名のアジャイルコーチが各スクラムチームに加わり、コードを書きながらE2Eテストの方法を指導しました。

ステップ2: ドキュメント化とプランの改善
次に、コーチたちが教えた内容をドキュメント化し育成プランを作成しました。

ステップ3: エバンジェリストの育成
その後、スクラムチームからE2Eトレーナー候補を選び、「エバンジェリスト」として育成しました。彼らへ育成プランを用いて教育を行いました。

ステップ4: エバンジェリストによる教育
最後に、エバンジェリストが自チームおよび他のチームに対してE2Eテストの教育を実施しました。

見つかった課題と乗り越え方

10チーム以上が日々新たなシナリオを開発している中、新たなシナリオが増えていくスピードの速さにE2E対応のスピードが追いつけないことがステップ3の時にわかりました。未対応シナリオ増加スピードを鈍化させるためにより早くチームが習得できるように取り組んだことは2つです。次の2つの改善に取り組みました。

改善1: 育成カリキュラムの更新

育成プランは、対象者の経験とフィードバックに基づいて2段階で改善されました。

1段階目のプラン: コーチが複数チームで実施した共通タスクを時系列で整理し、E2E対応が可能になるインクリメンタルな育成プランを作成しました。
2段階目のプラン: エバンジェリストの育成後、チーム数を増やして育成を進める中で、各シナリオの実装難易度や不要なカリキュラムが明確になりました。

これにより必須カリキュラムを厳選し、難易度の低いテストから高難易度のテストへと段階的に進めるインクリメントかつイテレーションの育成プランに変更しました。

改善2: 役割分担とフォローアップ

ステップ4では、アジャイルコーチはフォローアップに専念し、エバンジェリストが教育をリードしました。エバンジェリストはスクラムチームのメンバーでもあるため、教育対象メンバーとの関係性が深く、プロジェクト状況も把握しているため、現状に即した育成が可能です。アジャイルコーチは、相談役としてサポートを提供しました。

現場のことに詳しいエバンジェリストに育成を託し難易度の低いシナリオからどんどん対応していただき、難易度の高いシナリオにフォーカスしたサポートにアジャイルコーチが専念することで習得スピードアップに繋げました。

未対応シナリオの自動テスト実装

専門部隊の設立

スクラムチームとは別にアジャイルコーチ、エンジニアとQAの混合部隊を設立しました。未対応シナリオの優先順位を明確にしROIの高いシナリオから対応していくためです。ユーザーアクションが多いシナリオ（いわゆる正常系パス）や、不利益度合いなど考慮して優先順位付けし順次対応していきます。プロダクトの重要機能のカバレッジを向上させることを目標としたE2E専門部隊です。

スキルセットとドメイン知識のギャップをスクラムで克服する

混合部隊のチームワークの促進、技術課題の改善のために私たちはスクラムやアジャイルのプラクティスを活用しました。デイリースクラムを通じて、課題解決の方法やドメイン知識の習得方法についてメンバー間で積極的に対話を行いました。また、ペアプログラミングなどの協働作業を取り入れることで、チーム全体で知識を共有する機会を増やしました。このアプローチにより、個々のメンバーが持つ暗黙知をチーム全体に広げることができました。このように、日々の改善を重ねることで、実装スピードは徐々に向上していきました。

CI/CDパイプラインの構築

E2Eテストの自動実行環境を構築

AWSのCI/CDツールを活用し、E2Eテストの自動実行環境を構築しました。以下の2つのトリガーを設定することで、リリース前に問題を検知できる仕組みを整えました。

ステージング環境への差分追加時
AWS Step FunctionsとCodePipelineを用いて、ブランチへのコミットが検証環境に反映されるタイミングでE2Eテストを自動実行します。これにより、コード変更の初期段階で潜在的な問題を早期に検出可能にしました。
リリース用PR作成・更新時
CodeBuildを使用し、本番リリース用のPRが作成・更新されるタイミングでステージング環境に対してE2Eテストを実行します。リリース直前にクリティカルな問題を検出し、リリースの安全性を確保しました。

E2Eテストの実行環境とログ出力にはECSとCloudWatchを採用し、効率的かつ安定したテスト実行を実現しています。

各スクラムチームの運用フローを整備

複数のスクラムチームが効率的にE2Eテストを運用できるよう、以下のフローと仕組みを導入しました。

テスト結果の対応フローを明確化
E2Eテスト実行時に失敗したシナリオについて、以下の対応方針を整備しました：
- プロダクトの重要な機能の失敗または本番影響がある場合：リリースまでに修正。
- それ以外の場合：期日を設定し修正対応。各シナリオの対応スクラムチームは持ち回りで決定し、負担が特定のチームに集中しないよう配慮しました。
レビュー体制の構築
E2Eテストのレビューは、育成したエバンジェリストが担当。品質基準を統一しつつ、各チームの自主性を尊重する運用体制を確立しました。
不安定なテストの管理と改善
成果の可視化と改善の効率化を目指し、E2Eテスト結果を集約したダッシュボードを作成しました。
成功率が低いテストはエバンジェリストやQAと協力し改善対応を実施しています。これにより、不安定なテストの影響を最小限に抑える仕組みを構築中です。

振り返り

このプロジェクトは現在も進行中ですが、以下の4つの要素を明確にすることが重要であると感じました。

1. ゴールおよび中間地点

ゴールや中間地点とは、プロジェクトの実践者やステークホルダーが共通して理解するべき目標の状態と、その達成期限を指します。これらの状態は、定量的であるほどゴールが明確になります。たとえば、「5月までに5チームが新しい技術を習得する」や「200のシナリオをE2Eで対応する」などです。未踏領域の取り組みほど最初に決めるのは難しいのですが、進行しながらなるべく早いタイミングで決めます。

2. 現実的な戦略・戦術

新しい取り組みには既に多くの事例があり、最短でゴールを達成したり、副次的な効果を狙いたくなることもあります。しかし、現状のシステム環境、プロジェクト状況やリソースを考慮した上で計画を立てることが重要です。今回のプロジェクトでは、人的リソースやゴール、チームの状況、システム環境を考慮し、自動化ツールの選定やCI/CDパイプラインのチューニングラインを決めました。

3. 役割ごとの期待値

戦略上、3つの柱を立て、それぞれの役割と期待値を明確にしました。協働タスクも存在し相互協力する場面もあり一見すると責任と裁量は似ていますが柱ごとに、また同一柱内でもそれぞれ役割と期待値を明確にしました。これは各々の責任範囲を限定するためではなく場面場面でそれぞれが意思決定をスムーズにすることが狙いです。

4. 顧客価値

新しい取り組みでは、テスト量やシステム性能（機能価値）に注力しがちですが、これらがチームやプロダクトにどのような価値をもたらすのかを考えることが重要です。オーバークオリティは運用コストの増加につながるため、バランスを取ることが求められます。

これらの4つの要素を明確化することで取り組みが前進したと思います。そしてこれらを現場の実践メンバーからマネージャー、さらには執行役員クラスまで、さまざまなレイヤーからフィードバックいただきわれわれのファシリテートを助けていただきました。

今後

E2E適応を進めつつ今後はエラーの自動検知と修正までのリードタイムの短縮を目指します。

最適なテスト実施タイミングを組み込んだスプリント内のプロセス

開発プロセスの前工程でE2Eテストを実装し、自動テストによるフィードバックループを短縮する仕組みを構築します。これにより、バグの早期発見と迅速な対応が可能とし、開発効率の向上を図ります。さらにはテスト実施時間の待ちによるボトルネックを減らすためのプロセスのガイドも策定する予定です。

エラーの自動検知

E2Eテストは、その性質上flaky（不安定）な挙動を示す場合があります。具体的には、実際に問題があるにもかかわらずエラーを検知しない（偽陰性）ケースや、正常であるにもかかわらずエラーを検知する（偽陽性）ケースが発生します。これらの課題に対応するため、厳選したメトリクスを活用し、異常値が検知された際には自動で通知する仕組みを構築します。これにより、E2Eテストの信頼性と効率性を向上させ、開発プロセス全体の改善を実現します。

これらの取り組みによって開発効率と品質の向上に努めていきます。これから組織にE2Eテストを導入しようと検討している方や、既に導入済みで安定稼働や運用に課題を抱えている方にとって、お役に立てれば幸いです。