この記事でわかること
-
自動テストが失敗する理由と「目的別シナリオ再構成」による解決策
-
手動テストを自動化したときに見落とされがちな「暗黙知」の重要性
-
3年後を見据えたAIとの協働スタイルとエンジニアが追求すべき本質的価値
DevOpsの浸透、アジャイル開発の普及に伴い、ソフトウェアテストの自動化は「コスト削減」から「開発のドライバー」へとその役割を大きく変えつつあります。しかし、多くの現場では「自動化のための自動化」に陥り、その恩恵を十分に受けられていないケースも少なくありません。
「手動テストの自動化をやめ、自動テストを作ろう」というメッセージを掲げ、自動化の「目的」から丁寧に解説した書籍『テスト自動化実践ガイド』。著者の末村拓也氏は、Autify社の品質エバンジェリスト（Quality Evangelist）を務め、2025年7月には10種のテスト手法を体系化した『フルスタックテスティング』の翻訳も手掛けています。
今回は末村氏に、時代に左右されないテスト自動化の原則と、生成AIがもたらす品質保証の未来について伺いました。
末村 拓也
Webエンジニア、QAエンジニアなどを経て、2019年にAutifyに入社。シニアテクニカルサポートエンジニアやQAマネージャーを務める傍ら、カンファレンスでの登壇や記事執筆など精力的に外部発信を行った。 現在は同社の Quality Evangelist として、品質に投資することの重要性を世の中に広める役割を担う。ソフトウェアテストのシンポジウム JaSST Online および Tokyo Test Fest の実行委員を務める。『テスト自動化実践ガイド』(2024) 著者、『フルスタックテスティング』(2025) 翻訳。
【X（旧Twitter）】：https://x.com/tsueeemura?s=20
目次
品質エバンジェリストが語る、自動テストの“本当の目的”
末村さんはWeb開発者からキャリアをスタートされ、現在はQuality Evangelistとしてご活躍ですが、キャリアを通じて「テスト自動化」や「品質」に対する課題意識はどのように変化してきましたか？
立場による変化はあまりないですが、世の中の「自動テスト」に対する期待感が変わってきたのは強く感じています。
かつては、手動テストを自動化して「省力化」や「コスト削減」をしたいという動機が多かったと思います。しかし今は、アジャイル開発やDevOpsの文脈で、自動テストを一種の「ガードレール」のように使い、頻繁なリリースを支えるためのドライバーとして活用する方が増えました。
まさに、自動テストが「守り」から「攻め」の手段にもなっているわけですね。「ガードレール」というのは非常に分かりやすい表現です。
そうですね。この「ガードレール」があるからこそ、開発プロセスの後半で行っていたテストを、もっと早い段階で行う「シフトレフト」の考え方も実践しやすくなります。
末村さんの著書『テスト自動化実践ガイド』では、そうした最新の動向も踏まえつつ、テストの「目的」や「考え方」といった普遍的なテーマについても解説されています。これはどのような問題意識からだったのでしょうか？
この本は、元々「手動テストの自動化をやめ、自動テストを作ろう」というテーマがベースになっています。
手動テストをそのまま自動化しようとすると、本来得られるはずの便益が得られないどころか、テストの質が悪化してしまうリスクさえあります。そこで本書では、自動テスト向けに目的を整理した上で臨もう、というメッセージを込めました。
単なる技術解説ではなく、導入から運用まで、まさにテストの「フルサイクル」を考えられる構成になっていますね。
実践と銘打つ以上、導入時の目的設定から、実装、そしてメンテナンスのテクニックまでを網羅しました。
実際、読者の方からは「第1部の『目的』の部分をチームで読み合わせた」という反応を圧倒的に多くいただきました。自動化ツールの具体的な使い方はネットで見つかりますが、「何のためにそれをやるのか」という部分をみなさんが最も知りたかったのだと思います。
テスト内製化の「落とし穴」。成功の鍵は「目的別のシナリオ再構成」
ソフトウェアテスト自動化の「目的」について、もう少し詳しく伺います。多くの現場で「自動化のための自動化」が失敗に終わってしまうのは、なぜでしょうか。
手動テストをそのまま自動化すると破綻しやすい理由は、大きく二つあります。一つは「自動テストが気づいてくれない」からです。
人間であれば、テストケースに書かれた「機能が正しく動くか」をチェックするだけでなく、その過程で暗黙のうちに多くのことを同時にチェックしています。例えば、「ページのレイアウトが崩れていないか」や「パフォーマンスが劣化していないか」などです。 一方、自動テストは基本的に「言われたことしか実行してくれない一番頭の固いテスター」のようなものです。コードで指示されていないレイアウト崩れには一切気づきませんし、テスト対象のリンクが文字から画像に変わっただけで、人間ならテストを続行できる場面でも、自動テストは失敗して止まってしまいます。
たしかに、人間なら「意味は同じ」と判断できる部分ですね。
おっしゃる通りです。手動テストで暗黙のうちにチェックされていた「レイアウト崩れ」や「パフォーマンス劣化」といった観点を、明確な検証項目として整理しないまま自動化してしまうと、どうなるでしょうか。
自動テストのコードは「機能が動くか」だけをチェックするものになり、それらの観点は検証されなくなってしまいます。その結果、手動テストで防げていたはずの品質問題が見逃される、という事態に陥ります。
なるほど。自動化は万能ではなく、手動テストで暗黙的にカバーしていた「曖昧な部分」をしっかり定義し直す必要があるわけですね。
もう一つは「実行サイクルとメンテナンスの違い」です。手動テストは、仕様変更に気づけばその場でマネージャーに確認してテストケースを修正する、という柔軟な対応ができました 。
一方で自動テストの場合は、仕様が変われば失敗して止まってしまいます 。また、仮にリリース直前に行っていた手動テストをそのまま自動化しても、開発者にとって一番うれしい早い段階でのフィードバックが得られません。フィードバックのタイミングが遅いままでは、自動だろうと手動だろうと開発者にとっては大した違いはないのです。
では、そうした失敗を避けるために、チームはどのようなアプローチを取るべきでしょうか。
解決策は、自動テスト向けにシナリオを再構成することです。以下の表に記載しているような「素朴なテスト自動化」ではなく、「開発者を支える自動テスト」を目指すことが大切です。
具体的な手法としては、例えば元々100ステップあった長大なシナリオを、目的別に10ステップずつの小さなシナリオ10本に分割する。目的を絞った小さなテストをたくさん作ることで、メンテナンス性を上げたり、テスト全体の見通しが良くなったりします。
以前のインタビュー（「2025年の崖」目前に大企業の9割以上が進めている「ソフトウェアテストの内製化」とは？）でも「テストの内製化」が大きなテーマでしたが、まさに今、内製化に取り組むチームが自動化の最初の一歩として、技術選定の前にまずやるべきことなんですね。
おっしゃる通りです。技術選定（How）の前に、まさに「何をテストしたいのか」「何の目的で自動化したいのか」を明確にすることが、特に内製化チームにとっての重要な第一歩になります。
目的が明確になったら、次は何を考えるべきでしょうか？
「何を見つけるか」、そして「どこで見つけるか」を考える必要があります。そこで重要になるのが「テストレベル」の定義です。これは、テストの目的や想定されるバグによって「単体テスト」「結合テスト」「E2Eテスト（※1）」から選ぶのが良いでしょう。
※1 E2E（エンドツーエンド）テスト：実際のユーザー操作を模倣し、アプリケーション全体の動作を最初から最後まで通して検証するテスト手法。
それぞれのテストには、どのような特徴やトレードオフがあるのでしょうか？
例えば、単体テストは高速ですがユーザー体験からは離れており、E2Eテストはユーザーの関心事をテストできますが、一般的に低速である、といったトレードオフがあります。その上で、特にE2Eテスト特有の観点として、「自分たちがサポートをどのぐらい受けたいか」は非常に重要な指標です。
なぜサポートが重要な指標になるのでしょうか。
E2Eテストは、ブラウザ、操作ライブラリ、OS、対象Webサイトなど登場人物が非常に多いんです。何かトラブルが起きた時、どのコンポーネントが原因なのかを自力で調査するのは、膨大な工数がかかります。その工数を有償ベンダーのテクニカルサポートで削減する、という判断は十分にあり得ます。
とはいえ、多くの現場では、テスト自動化のROI（投資対効果）を経営層やビジネスサイドに説明するのに苦労すると思います。この点についてはいかがでしょうか。
かつて「手動テストの工数を自動化の実行回数で割って、3回実行すれば元が取れる」といったROIの説明がありました。これは自動テストの作成・メンテナンスのコストと、そのテストを手動で実施した場合のコストが逆転するのが3回ぐらい、というものなのですが、調査が行われた時期から比べて自動テストの作成・メンテナンスは容易になりましたし、自動テスト自体もCI/CDで高頻度で実行するのが当たり前になった現代においては、3回以上実行するのはほとんど当然と言えると思います。
私がおすすめするのは、自動化の結果として何が改善したかで測ることです。その最たるものが「本番環境に流出したバグの数」、つまりお客様に迷惑をかけた数がどれだけ減ったか、です。
なるほど。「自動テストが何件バグを見つけたか」という指標ではないんですね。
自動テストで検出すべきバグ（リグレッションバグなど）は、本来「見つかって当たり前」で、開発プロセスの中で処理されるべきものです。バグは作らないのが一番ですから、最終的に「お客様への影響」という観点で測るべきです。ちなみに、自動テストがある状態でのリリースまでの流れは以下のようになります。
また、もう一つの重要な指標が障害発生時の平均復旧時間（MTTR）の短縮です。自動テストが「ガードレール」としてしっかり機能していれば、万が一障害が起きても、修正版をデプロイする自信が持てます。「自動テストが通ったから大丈夫」と。迅速に復旧できるのも、ビジネス継続性の観点から経営層には響きやすい価値だと思います。
自動テストは「育てる」。ビジネス成長と「お客様との約束事」を守るために
書籍では「テストコードに意図を込める」という点が強調されています。これは具体的にどのような実践を指すのでしょうか？
自動テストの導入支援などでご相談に乗らせて頂く際に、一番良く聞かれるのが意外にも「E2Eテストって何をテストしたらいいんですか？」というものです。テストを自動化しなきゃ、品質を上げなきゃとは思っているものの、どんなことをテストすればいいのかというのは意外とみなさん迷われるポイントなんですね。
そんなときに、私は大抵「ユーザーマニュアルに何が書いてありますか？」とお聞きします。マニュアルに書いてあるログインの仕方、注文の仕方、それらは「お客様との約束事」です。開発によって、その約束事が守られ続けているかを確認すること。それがテストの目的であり、「意図を込める」ということです。
自動テストは一度作れば終わりではなく、「メンテナンス」こそが本質的な難しさだと感じます。失敗しがちなテストを、チームでうまく『育てていく』ための心構えを教えてください。
それも「約束事」で説明できます。ビジネスの成長と共に、返品機能の追加など、お客様との約束事は増えていきますよね。
その機能追加によって過去の約束事が壊れては意味がありません。ビジネスの成長に合わせて、テストも一緒に積み重ねていく必要があります。テストが失敗しがちなのは分かりますが、それを育てていくのは開発者全員の責務だと考えています。
とはいえ、個人の心構えだけでは限界があります。プロジェクトリーダー（PL）やプロジェクトマネージャー（PM）といった立場のエンジニアが、チーム全体の品質レベルを「仕組み」で引き上げていくためのアイデアはありますか？
もちろんマインドセットが一番大事ですが、あえて仕組みの例を挙げるなら二つあります。一つは、開発チケットが作られたら、対応するテストチケットも自動で付与する仕組みです。そして、そのテストチケットをクローズしない限り、開発チケットもクローズできないようにします。
それは徹底されていますね。
もう一つは、コードカバレッジ（※2）に注目する仕組みです。例えば「テストカバレッジが80%を切ったらアラートを出す」のような基準値（閾値）を設定し、それをプルリクエスト（コード修正の申請）の段階で自動的にチェックします。
これにより、カバレッジが意図せず下がっていないかを確認でき、少なくとも「機能は作ったが、それに対するテストを書いていない」という事態は防げます。
※2 コードカバレッジ：テストがコード全体のうち何%を実行したかを示す指標。
テスターがAIでコードを修正。エンジニアの「能力拡張」と新たな役割
ここからはテーマを変えて、生成AIについて伺います。専門家のお立場から、現在のAI技術がソフトウェアテストの現場に与えている影響を、率直にどのようにご覧になっていますか？
多くの企業がAIコーディングエージェントを導入し、一人のエンジニアが出せるアウトプットを増大させるために使っていると思います。これまではコードを書くのが得意な人、テストするのが得意な人、と役割が分かれていましたが、AIがその間のギャップを埋め始めています。
特に注目されている事例はありますか？
あるカンファレンスで聞いた事例ですが、テスターがバグを発見し、その再現手順をAIに渡してから原因を特定し、自分でコード修正まで一貫して行った、という話がありました。
それは非常に興味深いですね。
テスターはバグの再現手順を作るプロですが、これまではコーディングの壁がありました。その壁の多くは「既存コードの理解」ですが、AIはまさにコードを説明し、理解を助けるのが得意です。AIによって、一人のエンジニアができるケイパビリティ（能力）が劇的に広がっていると感じます。
なるほど。「テスト内製化」の課題、例えば「社内リソースの負担増」や「テスト方法の標準化」といった点も、AIは解決してくれるでしょうか？
AIの導入が、それらの課題の直接的な解決策にはならないと思います。もちろん、将来的に「プロのようにテストしておいて」と頼んだら完璧にやってくれるAIが生まれれば、話は変わってきますが。
やはり現状では、人間のチェックが不可欠だと。
現状ではAIが生成したコードのレビューが非常に重要です。例えば、AIにユニットテストを作らせると、プライベートな関数をテストコード側にコピーしてきて、「テストコードの中のコードをテストする」という全く意味のないテストを作ってしまうことがあります。
ただ、これまで「仕方なく人間がやっていた」領域が、AIに任せられるようになり始めています。例えば「ここに表示される画像は、猫ではなくゴリラであることを確認する」といったテストにおいて、従来の自動化では、画像が存在するかはわかっても、それが何であるかを判定するのは非常に困難でした。
それは従来の自動化では難しい部分ですね。
しかし、今のマルチモーダルな生成AIなら、「これはゴリラですね」「これは猫ですね」と評価できるはずです。このように、AIによって自動化できる領域が拡大しています。
目指すべきは、アプリケーションのコア機能など、必要な部分は全て自動化を進め、人間はUX評価や感覚的な部分（主観的な使用感）など、より本質的に人間にしかできない領域に注力することだと思います。
「AIが使える」は3年後に評価されなくなる。エンジニアが追求すべき価値
AIが登場したことで、前半で伺った「自動化の目的」や「意図を込めたテスト」といった普遍的な原則の重要性に変化はありますか？
変わりません。むしろ、より重要になると思います。というのも、今のLLM（大規模言語モデル）は、基本的には言語を扱う計算機です。ということは、「人間が読んで分かりにくいもの」は、「AIにとっても分かりにくい」と考えられます。
AIが理解しやすいように書くことが、結果的に人間にとっても分かりやすいということですね。
チーム開発において、コードに意図を込め、読みやすくするという従来の流儀は、そのままAIとの協働にも有効です。AIの速度によってプロセスのボトルネックが変わることはあっても、原則は変わりません。
最後に、AI時代と向き合うエンジニアに向けて、キャリアを築いていく上でのメッセージをお願いします。
エンジニアが持つべき軸は、AIという「道具」を使いこなすことではなく、常に「ユーザーに価値を届けること」だと考えています 。今は「AIを使いました」ということ自体が評価される、いわばAIバブルのような状態です 。しかし、このバブルは3〜5年後には終わり、AIは当たり前の技術になるでしょう 。その時に「AIが使える」ことを強みだと過信していると危険です 。
AIが物を作る時代になっても、プロダクトの価値は「ユーザーがそれを使って嬉しいかどうか」でしか測れません 。AIは素晴らしい道具ですが、道具は目的を達成するためにあります。エンジニアはその軸を失わず、高い品質と顧客価値を目指し続けてほしいと思います。
ライター
