はじめに
私は長年、開発エンジニアとしてシステムづくりに携わってきました。
現在は社内のQAチームで、E2Eテストのオペレーターとして一から歩み始めたところです。
そんな私が、E2EやQAを学ぶために、2026年に開催された JaSST'26 Niigata を聴講しました。
その中から、山口 鉄平さん（株式会社LayerX・バクラク事業部）の講演
「プログラミング未経験者を含むQA組織で、コードベースE2E自動テストをどう始め、どう続けるか」 を、自分なりにまとめてみました。
副題は 「書ける」と「続く」の間にある運用設計。
「自動テストのフレームワークは入れた。CIも回っている。でも書く人が増えない」――そんな経験がある方には刺さる内容だったので、自分用のメモも兼ねてまとめます。
この記事は、講演の内容を聴講者の立場でまとめたレポートです。発言の細かいニュアンスは講演者の意図と異なる可能性があります。正確な内容は講演資料をご確認ください。
この記事でわかること
- 自動テストが組織に広がらない「本当の理由」
- 未経験者でも書けるようにするための 「型」 の作り方
- レビューを 集約 → 手放す → 必要なら再開する という運用の進め方
- 生成AI時代に自動テストを「続けられるもの」にするためのヒント
結論から言うと
「みんなで書こう」から始めると、自動テストは普及しない。
講演の結論は、次の3ステップに集約されます。
- 最初の一人が「判断しなくて済む型」を作り切る
- 型ができてから人を巻き込み、レビューは最初の一人に集約してぶれを防ぐ
- 安定したらレビューを手放す（必要なら再開する）
そもそも「コードベースE2E自動テスト」とは？
| 用語 | 意味 |
|---|---|
| E2E（End to End）テスト | ユーザーと同じように「画面を開く → 入力 → クリック → 結果を確認」という一連の流れを、画面の端から端まで通して検証するテスト。例：ログインして申請を出す |
| コードベース | Playwright + TypeScript などを使い、テストを プログラムとして書く こと |
録画やGUIで作るノーコード型のツールと違い、コードベースには次のようなメリットがあります。
- Git で管理・レビューできる
- CI で自動実行しやすい
- 柔軟に書ける
一方で、自由度が高いぶん「どう書くか」の判断が多く、プログラミングの知識も必要 になります。ここがプログラミング未経験者を含むQA組織にとっての壁になります。
背景：「1本でいいから書いてよ」は届かなかった
山口さんは以前の現場で、次のように進めたそうです。
- テストフレームワークを用意し、CIも整備
- 開発チームの3〜4名に「1本でいいから書いてよ」と依頼
- 返事は「やります」
ところが、2ヶ月働きかけて増えたテストは2〜3本。続かず、広がりもしませんでした。
当時は「みんな忙しいんだろう」と考え、業務の優先順位の見直しやテストを書く時間の確保など、相手のやる気を変えようとした とのこと。
でも振り返ってみると、変えるべきはそこではなかった。
普及しない本当の理由は「やる気」ではなく「判断の多さ」
課題①：1本書くまでの判断が多い
テストを1本書くだけでも、次のような判断が次々に出てきます。
プログラミングができる人なら、テスト自体は書けます。
でも判断の一つひとつに自分で答えを出すことになり、「みんなが使うテストの判断を、自分が決めていいのか」がわからない。
判断の基準は、一人では決めにくい。
課題②：テストケース固有の知識がない
「読みやすく書いてね」と伝えても、返ってくるのはこんな問いです。
- 「テストケースとして、どうなっていればいい？」
- 「ファイルの最初に何を書く？」
- 「ログインはどう書く？」
補足：AIで書けても、数年続く自動テストにはならない
ここは生成AI時代ならではの指摘でした。
- パッと作ったテストは、数年使い続けるうちに直す箇所がわからなくなる
- AIがテストを書けても、判断基準がないことは変わらない
- むしろ書ける量が増えるぶん、直せなくなるのが早い
「AIで書ける」と「チームで数年メンテし続けられる」は別問題、という視点はとても大事だと感じました。
普及させるための提案：3ステップで運用を設計する
| ステップ | やること |
|---|---|
| ① 最初の一人が型を作り切る | 判断の回数を減らすガイド、コーディングルール、サンプルコードで「型」を作る |
| ② 巻き込む／レビューを集約する | 型ができたら人を巻き込む。判断がぶれないよう、レビューは最初の一人がまとめて行う |
| ③ 集約レビューをやめる | レビュー指摘がなくなったら、最初の一人によるレビューをやめる |
バクラク事業部では、この「最初の一人」は山口さんご本人だったそうです。
① 最初の一人が「型」を作り切る
ゴールは、次に書く人が「コピペ＆モディファイ」でテストケースを書ける状態 にすることです。
- 自動テスト作成ガイドとコーディングルールを整備する
- 主要なフローを含むテストケースを、サンプルコードとして一通り作り切る（立ち上げ時の約5プロダクト分を山口さんが書いたそうです）
- 完璧は目指さない。書く人が手を動かし始められるところまで作る
ここからは、ガイドやルールで実際に決めていることの例です。
細かい技術用語は省いて、考え方 を中心に紹介します。
(1) 画面の部品の「目印」の付け方に優先順位をつける
自動テストで「保存ボタンを押す」「メールアドレス欄に入力する」といった操作をするには、画面のどの部品なのかをプログラムに教える「目印」 が必要です。
この目印の付け方には、いくつかの方法があります。
- テスト専用の「名札」を部品に付けておき、それで探す
- ボタンに書かれた文字（「保存」など）で探す
- 「上から3番目のボタン」のように、位置で探す
どの方法でもテストは動きます。違うのは、画面が変わったときの壊れにくさ です。
たとえば、ボタンの文字が「保存」から「登録」に変わると、文字で探していたテストは動かなくなります。位置で探す方法は、ボタンが1つ増えただけで別の部品を押してしまいます。
そこで、「なるべくこの順番で目印を選ぶ」という優先順位をガイドで決め、一番上を テスト専用の名札 にしています。名札は自分たちで管理でき、文言やデザインが変わっても壊れないからです。
実は、テストツール（Playwright）の公式ドキュメントは別の順番を勧めています。
それでもこの順番にした理由を、ガイドに書き添えておく のがポイントです。理由がわかれば、次の人も迷わずに済みます。
(2) 名前は「決める」のではなく「決まる」ようにする
テストのファイル名や部品の名前は、人によってばらばらになりがちです。どんな名前でもテストは動きますが、大事なのは 次に書く人とAIが、同じ答えにたどり着けるか です。
そこで、名前は画面のURL（アドレス）から機械的に決まる ようにしています。
| 画面 | URL の例 | 置き場所・名前 |
|---|---|---|
| 申請の新規作成画面 | …/requests/new |
「申請 › requests › new」に沿って決まる |
身近な例でいえば、「書類のファイル名は『日付_取引先名』で付ける」と決めておけば、誰が保存しても同じ名前になり、探すときにも迷わないのと同じです。
部品の名前は 見た目に合わせる のもルールです。中身の作りがどうであれ、画面上でボタンに見えるものは「〜ボタン」と名付けます。
(3) フォルダの役割と「使う向き」を固定する
テストに関わるファイルを、役割ごとにフォルダで分けています。
| フォルダ | 入れるもの |
|---|---|
| テストケース | 「何を確認するか」のシナリオ |
| 手順のまとまり | 「ログインして申請画面へ移動する」など、複数の画面にまたがる一連の操作 |
| 画面ごと | 各画面のボタンや入力欄と、その画面の中での操作 |
| 共通部品 | サイドバーなど、どの画面にも出てくる部品 |
さらに、使う向きを一方通行 に決めています。
テストケース → 手順のまとまり → 画面ごと
テストケースは手順や画面を使いますが、画面の側からテストケースを使うことはありません。向きが決まっていると、何かを直したいときに、どこを見ればよいか迷わなく なります。
ルールを守ると、どうなる？
講演では、「パスワードが未入力の場合、ログインに失敗すること」というテストが例として紹介されました。
- 置き場所と名前は、ログイン画面のURLから自動的に決まる
- 「ログイン」はボタンに見えるので、「ログインボタン」と名付ける
- 「失敗したことを確かめる」部分は、テストケースの側に書く
こうしたルールがそろっていると、誰が書いても、だいたい同じ形のテスト になります。これが「判断しなくて済む型」です。
サンプルのテストケースに含めているもの
「コピペ＆モディファイ」の元になるサンプルには、次のものを入れているそうです。
- そのテストケースのテスト設計書（テストケース表）へのリンク
- テストアカウントの定義
- テストケース内でのログイン方法
- 主要フローの実装と使い方
- 期待値の表現
②-1 型ができてから巻き込む
ペアプロは、セットアップから一緒にやる
- ガイドを書いても、実行環境のセットアップで止まる人がいる
- テストケースを1本一緒に書きながら、ガイドの使い方を見せる
- 分かりにくかったガイドは、その場で直す
「やってみせる会」で、考えていることを実況する
- 「なぜこの順番で書くのか」を声に出しながら書き、「こうしておくと後が楽になる」をその場で共有する
- 同じところでハマっている人を、まとめて助けられる
- VS Code などエディタの使い方も共有できる
- 録画しておけば、あとから見返せる
②-2 レビューを最初の一人に集約する
テストケースが少ないうちは、書き方がばらつきやすいです。
外れのサンプルを真似ると、外れの書き方が広がる。 そして書き方がばらつくと、次に書く人の判断が増えてしまいます。
そのため、レビューは最初の一人に集約します。
レビュアーの負荷は上がる。でも、この期間は引き受けると最初の一人が先に決めておく。
副次効果：レビュー指摘を「AI向けガードレール」に残す
当初は狙っていなかったものの、AIに同じ問題を繰り返させないために、レビュー指摘をAI向けのガードレールとして書く ようになったそうです。たとえば次のような内容です。
- 既存のテストと同じ形で書き、新しい書き方を持ち込まない
- ロケーターは、UI上の意味で狭く定義する
- アサーションは spec3 に残す。意味のないアサーションを作らない
- タイムアウト、ループ、リトライを雑に書かない
- シナリオは、共通化（DRY）より業務としての読みやすさを優先する
「DRYより業務としての読みやすさを優先する」は、プロダクションコードの感覚だと逆になりがちなので、E2Eテストならではのルールだと感じました。
③ 指摘がなくなったら、集約レビューをやめる
同じ指摘が2〜3回出たら、ガイドやガードレールに書きます。書いた分だけ、次のレビューで言うことが減ります。
レビューを手放すまでの流れは次のとおりです。
| STEP | 内容 |
|---|---|
| 1 | 最初の一人が直接レビューする |
| 2 | 慣れてきたら、まず書く人同士でレビューし、最初の一人は最後に見る |
| 3 | どちらのレビューでも指摘が出なくなり、安定したらやめる |
書く人同士のレビューは、レビューの練習 にもなります。未経験者は「レビューのやり方」自体を知らないことが多く、指摘した人と指摘された人の両方が学べるそうです。
そして、レビューを「再開」した
自動テストを書いた経験のある人から順に、約半年で直接レビューをやめた そうです。
ところが最近、AIで書く量が増えてガードレールが追いつかない場面が出てきたため、レビューを再開している とのこと。あわせて、ガードレールやリンターの拡充も進めているそうです。
「やめたら終わり」ではなく、状況に応じて戻す という正直な話が印象的でした。
ここまでの話は、自動テストに絞った「施策レベル」の内容です。講演では、この方法が通用するのは 15人程度まで という感覚だと話されていました。より大きな範囲で広げるには、戦略的な視点も必要になります。
成果と現状
効能：自動テストが「みんなのもの」になった
- 書き始めるまでの迷いが減った
- プログラミング未経験のメンバーも、サンプルコードとガイドを見ながら書けるようになった
- レビュー指摘が、人向けのガイドやAI向けのガードレールとして残るようになった
とはいえ、まだ途中
- テストを書いた人は増えたが、月ごとに書く人数には波がある
- 自動テストでカバーしたい範囲は、プロダクトの成長とともに広がり続けている
- レビューを完全になくせる段階には、まだ至っていない
まとめ
| ポイント | |
|---|---|
| 始め方 | 「みんなで自動テストを書こう」をやめ、まず最初の一人が型を作り切る。型＝判断の回数を減らすガイド、コーディングルール、サンプルコード |
| 続け方 | 巻き込むのは型ができてから。レビューは最初の一人に集約し、指摘がなくなったらやめる。状況に応じて再開することもある |
明日からできる第一歩
それでもすぐには難しいでしょう。ということで、明日からできることを3つ紹介します。
- 自分がやっているテストの書き方を、1枚のドキュメントにまとめる
- 他の人の参考になるテストケースを、「最初の一人」として1本書く
- 誰かとペアで、テストケースを1本書く
質疑応答（講演音声より）
Q. 最初の一人（レビュアー）はどう選ぶ？
決まった基準はないが、ルールを作る人が適任。判断のぶれを防ぐための集約なので、ぶれない人を選ぶ。
Q. 自動テストを習慣的に書いてもらうための動機づけは？
実行状況や、書いている量の多い・少ないを時々共有している。ただし、何が動機になるかは人による。危機感を伝える「北風」が効く人もいれば、「太陽」型が効く人もいるので、相手に合わせて使い分けるとよい。
筆者の解釈： イソップ寓話「北風と太陽」のたとえだと受け取りました。
北風型 は「このままだと不具合が本番に出てしまう」など、危機感を伝えて動いてもらう方法。太陽型 は「書いてくれたテストのおかげでバグが見つかった」など、感謝や成果を伝えて、自分からやりたくなってもらう方法です。
Q. E2Eが増えるとフレーキーさが気になる。APIテストへ下ろすとき、非エンジニアが書けるようにするには？
非エンジニアにとって一番の壁は、「APIテストで何が書けるか」「どう書くか」を知らないこと。E2Eと同じようにガードレールを厚く引くことで、未経験者もAPIテストを書けている。何をAPIでテストすべきかはQAエンジニアでも迷うので、AIに相談しながら学ぶのも有効。
感想
これまで開発者として携わってきた現場には、QA専任の担当者がおらず、テストは開発エンジニア同士で行ってきました。作った側の視点だけで確認していたので、「この動きで当然」と思い込んで見落としていたこともあったかもしれません。
そして今、生成AIでアプリづくりは加速しています。作る人とは別の視点で品質を守るQAの役割は、ますます重要になっていると感じています。
講演で一番印象に残ったのは、自動テストが広がらない原因は「書けないこと」ではなく「判断の多さ」だ、という点で、とても共感しました。
自動テストそのものには長い歴史がありますが、今回の講演を聞いて、非エンジニアやQAが自分たちで自動テストを書く時代は、まだ始まったばかりだと感じました。そして「判断を減らす型」の考え方は、ツールが違っても使えます。それなら、私たちのチームでも型づくりは今から始められる、と思いました。
実際に私たちのチームでも、既存のE2Eテストの改善と、新しいE2Eテストの作成が並行して進んでいます。ただ、型はまだ作っている途中で、私自身も「最初の一人」の方に頼っている段階です。
まずはその段階から卒業し、自らテストケースの書き方のルールをまとめたり、見本になるテストケースを作り切ったりできるQAエンジニアを目指します。試行錯誤しながらも、新たな世界を切り拓いていきたいと思います。
参考
- 講演資料：プログラミング未経験者を含むQA組織で、コードベースE2E自動テストをどう始め、どう続けるか（山口 鉄平 氏／JaSST'26 Niigata）
- 技術導入の障壁と解決のヒント（Speaker Deck）
- Playwright 公式ドキュメント：Locators
-
ロケーター（Locator）：自動テストが操作する「画面の部品（ボタンや入力欄など）」を見つけるための目印のこと。「テスト用の名札で探す」「表示されている文字で探す」などの方法があります。本文の「(1) 画面の部品の『目印』の付け方」で紹介しているのがこれです。 ↩
-
アサーション（Assertion）：テストの中で「結果が期待どおりか」を確かめる部分のこと。たとえば「ログインに失敗したら、エラーメッセージが表示されていること」を確認する処理です。テストの合否はここで決まります。 ↩
-
spec（スペック）：テストケース（何を確認するかのシナリオ）を書いたファイルのこと。Playwright では
ログイン.spec.tsのように、ファイル名に.specを付けるのが一般的です。 ↩