UIが頻繁に変わる初期フェーズとテスト自動化の現実
注意事項：
- この記事は自分の備忘録として記載しています。また生成AIを使って作成しています。
- 私が研修で学習したことをベースに書かせていますので、生成AIを単純に使った以上に私の理解力による問題がある可能性があります
はじめに
アジャイル開発や新規サービス開発の初期段階では、UI（画面）が頻繁に変わることは珍しくありません。 にもかかわらず、
- 「最初からE2Eテストを自動化すべき」
- 「UIテストが一番ユーザーに近いから価値が高い」
といった意見を目にすることがあります。
本記事では、研修で学んだ内容と広く知られている実践知（テストピラミッド、CI/CD、アジャイルテストの原則）を根拠に、
- なぜUIが頻繁に変わる初期フェーズとUI自動化は相性が悪いのか
- では、どこから自動化を始めるべきか
- 最終的にどのような状態を目指すのが現実的か
を整理します。
※特定のツールやプロダクトには依存しない、一般論としての内容です。
なぜUIが頻繁に変わる初期フェーズとUI自動化は相性が悪いのか
UI（E2E）テストの特性は、以前から整理されている
UIテスト（E2Eテスト）の特性は、近年突然言われ始めたものではありません。 テストピラミッドやアジャイルテスティングの文脈では、長年次のように整理されています。
- ユーザー体験に最も近い
その一方で
- 作成コストが高い
- 実行時間が長い
- 失敗時の原因特定が難しい
- 変更に弱く、メンテナンスコストが高い
研修でも、UIテストは「テストの忠実度は高いが、コストも最も高い層」として説明されていました。
初期フェーズのUIは「変わること」が前提
新規サービスや立ち上げ期のプロダクトでは、UIは次の理由で頻繁に変わります。
- 仮説検証（UX改善）の繰り返し
- ステークホルダーからのフィードバック反映
- 仕様の未確定・方向転換
これは設計が甘いからではなく、価値探索を行っている健全な状態です。
この状態でUIテストを大量に自動化すると、
- UI変更のたびにテスト修正が発生する
- テスト修正が開発のボトルネックになる
- 「テストが邪魔」という認識が生まれる
という状況に陥りやすくなります。
これは多くの現場で報告されている、典型的なアンチパターンです。
では、どこから自動化するのが現実的か
① UIの裏側にある「変わりにくいもの」から始める
研修や一般的な実践で一貫して推奨されているのは、
UIではなく、UIの裏にある安定した責務から自動化する
という考え方です。
具体例：
- ビジネスルール
- 計算ロジック
- 条件分岐
- ステータス遷移
- 権限制御
これらは、画面レイアウトや文言が変わっても、比較的変更頻度が低い領域です。
事実として、
単体テスト・サービス層テストは
- 実行が速い
- 壊れにくい
- CIに組み込みやすい
という特徴があり、テストピラミッドの下層に位置付けられています。
② API・コンポーネント間の結合点
次の段階として現実的なのが、APIレベルの自動化です。
- フロントエンドとバックエンドの契約（リクエスト／レスポンス）
- 外部API連携（モック・スタブを含む）
ここを自動化すると、
- UIを手動で触りながらも
- 「裏側は壊れていない」ことを機械的に保証できる
状態を作れます。
これはCI/CDの文脈でも、早期フィードバックを得るための実績あるアプローチです。
③ UI自動化は「最小限」にとどめる
初期〜成長フェーズでUI自動化を行う場合も、
- 主要ユーザージャーニーのみ
- 数は極力少なく
- 「壊れたら致命的」なシナリオに限定
という制約付きで行うのが、現場実績として現実的です。
研修でも、
E2Eテストは魅力的だが、万能ではない
と明確に説明されていました。
最終的に目指すべき状態とは
ゴールは「UIを全部自動化すること」ではない
- テストケース数
- UI自動化率
ではありません。
研修では、次の状態が目指す姿として示されていました。
- 変更するたびに
- 自動で品質の最低ラインが確認でき
- チームが安心して変更できる
つまり、
「完成しているかどうか」を早く・頻繁に知れる状態
です。
UI変更は、人が価値を評価する
UIは、
- 使いやすさ
- 分かりやすさ
- 期待とのズレ
といった、人の感覚が重要な領域です。
そのため中長期的には、
- UIの変化 → 探索的テスト・レビューで評価
- 壊れてはいけない約束事 → 自動テストで担保
という役割分担に落ち着くケースが多いことが、実践として知られています。
まとめ
- UIが頻繁に変わる初期フェーズと、UI自動化は構造的に相性が悪い
これは個人の感想ではなく、
初期は
- ロジック
- API から自動化を始めるのが現実的
最終ゴールは
- UI自動化率ではなく
- 「安心して変更できる状態」を作ること
UI自動化は、やらない判断も含めて戦略です。 初期フェーズほど、「何を自動化しないか」を意識することが重要だと、研修を通じて強く感じました。
