食べログ品質管理部がDevOpsDays Tokyo 2025で登壇！プロジェクトタイプに応じた「手動テストゼロへの挑戦」

はじめに

こんにちは。食べログシステム本部の品質管理部に所属しているSoftware Engineer in Test (SET)のhagevvashiと百瀬です。

この度、2025年4月に開催されたDevOpsDays Tokyo 2025において、「手動テストゼロへの挑戦」というテーマで登壇しました。本記事では、その登壇内容について詳しくご紹介します。

本記事は、発表に興味があったものの参加できなかった方や、テキストで読みたい方向けに作成しています。
実際の講演の資料については、以下のスライドも合わせてご確認いただければ幸いです。

「手動テストゼロへの挑戦」とは何か

まず最初に重要な点をお伝えしておきます。
今回の「手動テストゼロへの挑戦」は、すべてのプロジェクトで手動テストを完全になくすことを目指すものではありません。

私たちが取り組んだのは、プロジェクトの特性に応じて適切な自動化戦略を選択し、一部のプロジェクトタイプにおいて手動テストゼロを実現するという戦略的なアプローチです。

具体的には以下の取り組みを行いました。

プロジェクトタイプに応じた自動化方針
テストピラミッドの正常化

背景：急増するテストケース数への対応

ビジネス好調に伴うテスト工数の増大

食べログはビジネスが好調で戦略案件数が増加しており、戦略案件の根幹に予約システムがあることもあって、品質管理部のQAエンジニアが実施するテストケース数も大幅に増加しています。
戦略案件は、予約登録や予約キャンセルなどの複数のユースケースの組み合わせをテストする必要があり、多くの場合テストケース数が多くなりがちです。

FY23 1Q：テストケース数：約8,000件
FY24 3Q：テストケース数：約13,000件

この負担を減らすため、自動テストによる効率化が急務となりました。しかし、すべての案件を一律に自動化するのは効率的ではありません。そこで、案件の特性を分析して戦略的にアプローチすることにしました。

戦略：プロジェクトタイプに応じた自動化方針

プロジェクト分析の指標

p11

まず私たちは、プロジェクトを以下の2つの指標で評価することにしました。

バグ検出率：テストで検出されたバグの数 / (本番障害の数 + テストで検出されたバグの数)
- 全バグの内リリース前に見つけられたバグ
  - 1(MAX値) に近いほど、バグの見逃しの少ないテストができている
  - 0 に近いほど、バグを見逃している (※ただし本番障害とテストで検出されたバグの両方がない場合も 0 になる)
バグ検出効率：テストで検出されたバグの数 / テストケースの数
- 1 テストケースでバグを見つけることができる可能性
  - 数値が大きいほど、少ないテストケースでバグを見つけられている（=効率的にテストができている）
  - 数値が小さいほど、バグを見つけるのに多くのテストケースが必要だった（=テストが非効率的である） (※ただしバグが見つからなかった場合はテストケースの数に限らず 0 になる)

2つのプロジェクトタイプの定義

p12

次に、バグ検出率の値とバグ検出効率の値により、プロジェクトを「タイプA」と「タイプB」に分類し、それぞれに適した自動化方針を定めました。

テスト結果による2つのタイプ

タイプA「テスト実施により一定数のバグが検出されるプロジェクト」：人間による戦略的テストが必要
タイプB「テスト実施してもバグ検出数が極めて少ないプロジェクト」：自動化中心で効率重視

（数値基準：タイプA = バグ検出効率0.001以上・バグ検出率0.6以上、タイプB = 両方とも未満）

タイプA：「人間がしっかりテストする部分が必要なプロジェクト」

バグ検出効率0.001以上、バグ検出率0.6以上のプロジェクトです。
このタイプでは、実施したテストに対して見つかるバグ件数が標準値以上であり、バグ見逃しリスクも存在するという特徴があります。

人間によるテストが必要な理由

新規機能でナレッジが不足している領域や、リリース跨ぎで手順が複雑なテストでは、案件の特性に合わせた独自のテスト設計が欠かせません。
人間による柔軟な判断でバグ検出率を維持しつつ、自動化可能な領域は積極的に自動化してバグ検出効率の向上も図っていきます。

このタイプでは手動テストが引き続き重要な役割を果たします。

タイプB：「自動化とAIだけでテストを完了していいプロジェクト」

バグ検出効率0.001未満、バグ検出率0.6未満のプロジェクトです。
このタイプでは、実施したテストケース数に対してバグの検出件数が比例せず、多くても1〜2件程度しか見つからないため、バグ見逃しリスクが極めて低いという特徴があります。

自動化とAIだけで完了できる理由

バグ検出率の改善余地が少ないため、手動テストを行っても新たなバグを発見できる可能性が低く、重要機能（食べログの場合は予約関連機能）に絞った最低限のテストを自動化することで十分な品質を確保できます。

このタイプにおいて「手動テストゼロ」を目指します。

設計：テストピラミッドの正常化

これまでの食べログの品質管理部で受け持つテストプロジェクトでは全てのテストを手動E2Eレベルで実施しており、テストピラミッドとしてはいわゆるアイスクリームコーン型と呼ばれるいびつな形をしていました。

このいびつなテストピラミッドを正常化するため、テストカテゴリごとに適切なテストレベルを選択しました。

p14

p15

①単体レベルで自動化するテスト

「組み合わせ網羅テスト」や「モジュールをまたがないテスト」という特性を持つテストカテゴリです。

なぜ単体レベルでの自動化が適切か
- 組み合わせ網羅テスト
  
  テストケース数が膨大になるため、手動実行では工数が爆発的に増大してしまいます。
  従来手動E2Eで実施していたテストを単体レベルの自動テストに移行することにより、効率的に網羅することが可能になります。
- モジュールをまたがないテスト
  
  テスト対象が限定的で依存関係がシンプルなため、単体レベルでの実装・保守が容易に行えます。

②E2Eレベルで自動化するテスト

「単純な操作テスト」「仕様が固まっている機能のテスト」という特性を持つテストカテゴリです。

なぜE2Eレベルでの自動化が適切か
- 単純な操作テスト
  
  基本的なUI操作の組み合わせであるため、自動化ツールで容易に実装できます。
- 仕様が固まっている機能のテスト
  
  要件変更が少なく、一度作成したテストを長期間使用できるため、自動化投資の回収効果が高く、保守性・再利用性にも優れています。

③手動E2Eとして残るテスト

上記①②以外のテストカテゴリは、引き続き手動E2Eテストとして実施します。

実装における3つの工夫

工夫1：単体テスト可能な構造に整理

飲食店予約システムの「在庫」は、日時・人数・席種別・コースなど様々な条件の組み合わせパターンについて、それぞれ予約可能な残数を管理するデータ構造です。

飲食店予約の「在庫」の複雑さ

飲食店予約の「在庫」は物理的に存在せず、「予約の衝突を避けるための概念的なリスト」でしかありません。
ECサイトの在庫のように倉庫に実在する商品とは異なり、飲食店予約システムの在庫は予約可能な残数という抽象的な概念を管理しています。

p18

AsIs：E2Eテストでしか検証できない複雑なデータ構造

上記で説明した「在庫」の概念的な性質により、ビジネス要件の変化に応じてアドホックに機能が追加されがちで、結果として在庫を構成するモジュールがソースコードの至る所に散らばってしまいました。

そのため、在庫のテストには複数のモジュールを同時に立ち上げて連携動作を含めた検証が必要となり、手動テストでしか対応できない状況になっていました。
例えばコース在庫だけでも、Courseクラス（エンドユーザー向け設定）とPlanクラス（在庫管理）に分かれており、テストには複数モジュールの連携動作確認が必要でした。

ToBe：在庫ドメインの整理によって単体テストができる

「在庫」ドメインを「卓」「営業時間」「コース」の3つのモジュールに整理し直しました。

例えば「コース」モジュールでは、コース情報の管理から在庫作成まで全ての機能を1つのモジュール内で完結できるよう設計しました。
これにより、他モジュールに依存しない独立した単体テストが可能になり、効率的なテスト実行を実現しました。

工夫2：画面数に応じたスケーラブルな構造で自動テストを実装

各画面で基本的な入力操作が正常に動作するかを確認する「画面単体・入力（正常系）」テストは、単純なテストですが、大量の画面・要素に対して実行する必要があります。

よくある実装パターンの問題点
画面数に比例してモジュール数が線形に増加し、新画面追加のたびに類似操作（入力・クリック）を重複実装することで、保守コストが画面数に比例して増大していました。

問題の解決策

この線形増加問題を解決するため、ウェブ画面の一般的な操作をテンプレート化し、3つの役割に分けてモジュールを整理しました。

p20

テスト手順：プロダクト固有の動的な仕様を定義するモジュール（Feature）
このモジュールでは、テストシナリオを手順（例えば「検索ページで店舗名入力欄に店舗001を入力する」など）の集合体として定義します。
画面固有要素：プロダクト固有の静的な仕様を定義するモジュール（PageObject）
このモジュールでは、画面上の要素（ボタン、入力フィールド、テキストなど）のセレクタを定義し、画面レイアウトの変更時にも一箇所の修正で対応できるようにしています。
ウェブ画面一般的な操作ロジック：ウェブ画面一般的な仕様をテンプレート化したモジュール（Step）
このモジュールでは「ボタンをクリックする」「テキストを入力する」などの基本的な操作を定義し、どの画面でも再利用できるようにしています。

こういったモジュールに整理することで、新しい画面やテストシナリオを以下の手順だけで追加することができます。

既存Stepを再利用/追加実装
一般的な操作（入力、クリック、確認など）が既に実装済みのため、操作ロジックを即座に利用可能です。
特殊な操作が必要な場合のみStep層に追加実装を行います。
PageObjectを再利用/追加実装
操作ロジックの実装は不要で、新しい画面の要素情報を既存画面との整合性を保つよう定義するだけで済みます。
これにより画面レイアウト変更時の修正箇所を一箇所に集約し、保守コストを最小化できます。
Featureにシナリオを追加
具体的なテストシナリオを業務フローに沿って記述するだけで、既存のStepを組み合わせることで大部分の実装が完了します。
これにより新規実装が必要な部分を最小限に抑制できます。

工夫3：テスト対象データのライフサイクルを整理

E2Eレベルで自動化するテストカテゴリのもう1つの例が「予約経路」です。

食べログのシステムの中でも、予約機能は最重要機能で、エンドユーザー向けメディアサイト、店舗担当者向け予約台帳システム、飲食店向け自社予約フォームといった複数の「モジュール」から、予約データに対して登録・変更・キャンセルの操作を行えます。私たちはこうした予約機能に対するモジュール別のテストを「予約経路」と呼んでいます。

予約データは登録から完了・キャンセルまで複雑なライフサイクルを持ち、その過程で予約登録・予約変更・予約キャンセルといった様々な「ユースケース」によって状態が変化します。
たとえば、エンドユーザーがメディアサイトから予約を作成した後、店舗担当者が予約台帳システムから内容を変更したり、キャンセル処理を行ったりします。

p22

細部の設計方針
予約データのライフサイクルを考慮しないと、モジュールとユースケースの組み合わせに比例してテストコードが線形に増加します。
この問題を解決するため、以下の設計を採用しました。

共通「予約情報」フォーマットの定義
全てのモジュールとユースケースで統一的な「予約情報」フォーマットを定義し、Featureファイルでは共通フォーマットでシナリオを記述しました。これにより、変換処理を追加するだけで新しいユースケースに容易に対応できるようになります。
データオブジェクトによるバリデーション
フォーマットの妥当性を早期チェックし、予期せぬバグを防止します。
例えば、予約日を固定化すると毎日テスト実行できないという課題に対して、テスト実行タイミングから相対的な「N日後」フォーマットを採用し、有効な日付として解釈できるかをチェックしています。
データオブジェクトによる変換処理の一元管理
各モジュール・ユースケース固有のフォーマットへの変換を一箇所で管理することで、共通予約情報から各モジュール（例：エンドユーザー向けメディアサイトなど）用のフォーマットへの変換を効率的に行えるようになりました。

この設計により、複雑な予約データのライフサイクル全体を、保守しやすく拡張しやすい自動テスト構造で検証できるようになりました。

成果と今後の課題

p24

達成した成果

私たちの取り組みにより、以下の成果を得ることができました。

タイプA「人間がしっかりテストする部分が必要なプロジェクト」
テストピラミッドの正常化の結果、リスクの高いテスト実施に手動QAチームが集中できる環境ができました（手動テストは継続して実施）。
タイプB「自動化とAIだけでテストを完了していいプロジェクト」
自動テストの整備により手動テスト0でリリースできる準備ができました。

なお、このDevOpsDays Tokyo 2025での発表時点では、まだ手動テスト0での実運用は実現できていませんでしたが、現在では実際に、ほぼ手動テスト0でのリリースを達成しています。

残された課題：手動テスト0に対する恐怖心

自動化のための技術的な課題は乗り越えましたが、チームメンバーと向き合った結果、技術ではなく心理的な障壁があることが判明しました。

手動テスト0に対する恐怖心

最大の課題は、手動テスト0で障害が出た時の責任に対する恐怖でした。「バグが出た時に品質管理部が怒られるのでは？」「手動テスト0でリリースしてよいという判断をして大丈夫なのか？」といった不安がチーム内に広がっていました。

恐怖心との向き合い方

この問題に対処するため、私たちは品質管理の考え方を見直しました。

食べログの品質管理部立ち上げから1年半の間、どこでどんな不具合が起こるかわからなかったため、慎重にテストを行ってきました。
しかし、1年半テストしてきた結果、不具合やリスクの偏在に気づいてきました。改めて実績として見ていくことで恐怖心も少なくなり、現在はリスクの高いところはしっかりテストし、リスクの低いところは迅速にリリースする方針に変更することができました。

具体的には、重大な不具合は0件になるようしっかりテストしますが、自分たちの恐怖心のために3ヶ月かけて徹底的にテストするよりも、3日でテストしてリリースし、小規模な不具合が出た場合はすぐに直す方がユーザーにとって価値が高いという共通認識を持つようになりました。