イベントレポート：t-wada氏講演「開発生産性の観点から考える自動テスト」を開催しました！

はじめに

こんにちは、株式会社メンバーズDevOpsLeadカンパニーの山﨑です。

先日、テスト駆動開発（TDD）の第一人者であるt-wada（和田 卓人）さんをお招きして社内講演会を開催しました！

前回の講演（2026年2月）に続き2回目のご登壇となった今回のテーマは、「開発生産性の観点から考える自動テスト」です。

最近はAIによるコード生成が身近になりましたが、だからこそ「書いたコードをどう検証し、安全に変更し続けられる状態を保つか」というテストの役割が改めて重要になっています。

今回の講演は、2024年6月に開催された「開発生産性カンファレンス」のセッションをベースに、弊社向けにアレンジしていただいたものになります。

当日はGoogle MeetとSlack実況チャンネルを繋ぎ、現場のリアルな悩みを交えながら大盛り上がりの2時間となりました。

講演で特に印象に残ったポイント

講演では自動テストの目的から具体的な運用の工夫まで幅広くお話しいただきました。その中でも、個人的に特に学びが多かった3つのポイントをご紹介します。

1. 自動テストの目的を「コスト削減」にしない

「手動テストの工数を減らすため」を目的にテストを書こうとすると、書く手間やメンテナンスの重さに負けて挫折しがちです。

t-wadaさんが強調されていたのは、「素早く躊躇なく変化し続ける力を得るため」にテストを書く、という視点でした。

なぜ今この「変化し続ける力」が必要なのか。その背景として語られたのが、AIやコーディングエージェントの存在です。競合他社もAIを使って高速にコードを書く時代において、生き残るためにはこちらも躊躇なくプロダクトを変化させ続けなければなりません。だからこそ、より早く・より安全に攻めの開発を進めるための判断基準として、自動テストの重要性が以前にも増して高まっているのだそうです。

自動テストは単なるコスト削減ツールではなく、ソフトウェアが本来持っている「変化できる柔軟さ」を守るためのアクセルなんだと改めて実感させられました。

2. 「単体・結合テスト」の認識のズレをなくす「Test Size」

開発現場でよくあるのが、「どこまでが単体テストで、どこからが結合テストか？」という認識のズレです。

実際、講演の中で「何をもって単体テストと呼ぶか」について5つの項目（DB、ネットワーク、ファイルへのアクセスなど）でアンケートが実施されたのですが、参加者の回答パターンは15通りに分かれました。同じチームや社内であっても、人によって「単体テスト」のイメージが大きく異なることがよく分かります。

こうした言葉の曖昧さをなくし、明確なテスト分類基準として紹介されたのが、「Test Size」です。

• Small：1つのプロセス内で完結
• Medium：1つのマシン内で完結
• Large：制限なし
  

  
  実行制約による基準が明確なため、たとえば「Smallは速度が早く安定しやすい」「Largeは遅く安定性が低い」といった特徴も捉えやすくなります。
  
  検証する範囲（Test Scope）と実行する制約（Test Size）の二軸で考えることで、チーム内の認識のズレが抑えられ、どのテストに投資すべきかという費用対効果も判断しやすくなるというお話でした。

「単体・結合」という言葉に振り回されず、実行速度や安定性の軸で整理するアプローチは非常に明快で、自分のプロジェクトでもすぐ取り入れたいと感じる学びでした。

3. テストの信頼性を維持したまま実行速度を上げる「サイズダウン戦略」

実際の開発現場では、手動テストやE2E自動テストに依存しすぎた「アイスクリームコーン」と呼ばれるアンチパターンに陥っているケースが少なくありません。これは、土台となる軽量な単体テストが少なく、その上に重いE2Eテストや膨大な手動テストが積み重なって、まるでアイスクリームコーンのような逆三角形になってしまっている状態を指します。

手動テストの膨大な工数はもちろん、自動化されたE2Eテストであっても実行速度が遅く不安定になりがちなため、結果として開発のスピード感を損なってしまう原因になります。

こうした状況から抜け出し、健全なテストピラミッドへ移行するためのアプローチとして紹介されたのが、テストダブルなどを活用した「サイズダウン戦略」です。

• Large から Medium へ：本物のデータベースや外部APIを叩く代わりに、Fake（DynamoDB LocalやLocalStackなどの代替品）をコンテナで動かし、単一マシン内に収める。
• Medium から Small へ：テストしづらい原因となっている依存関係を切り離し、単一プロセス内で動く軽いテストへ寄せる。

講演では、重いテストをそのまま放置するのではなく、テストダブルや設計の見直しを行い、テストのサイズを小さく落としていくアプローチが提示されました。

「テストが遅い・不安定」という課題に対して、ただテストを増減させるのではなく、アーキテクチャや設計にフィードバックしてサイズを落としていくという考え方は非常に参考になりました。

参加者の声

講演後のアンケートでも、参加者から今後の開発に活かせる多くの気づきや共感の声が届いており、その一部をご紹介します。

「これまで単体・結合という言葉の範囲が人によって違っていて悩んでいました。Small/Medium/Largeという実行制約での分け方は明確で、わかりやすいと思いました。」

「AIでコードを書くのが当たり前になりつつある今だからこそ、普遍的な『変化に対応できるコードとテスト』の話が刺さりました。新規開発ではテストの書きやすさを意識して設計していきます。」

「体系立ててテストの重要性や設計について理解することができました。また、AI時代におけるテストの考え方についても再確認することができました。」

「現場で仕事しているだけでは糸口が見えてこなかった問題に対する気づきが得られました。今後の新規開発にあたっては、テストが書きやすいことを重視して設計していきたいと思います。」

「"Test Size" と "Test Scope" の考え方の整理に加え、最後はやっぱりチーム内のコミュニケーションが大事だという点にとても共感しました。」

おわりに

単なるテストの書き方にとどまらず、「どうすればチームでアジリティ高く開発を続けられるか」を深く考える素晴らしい時間になりました。

ご登壇いただいたt-wadaさん、本当にありがとうございました！

今回持ち帰った気づきを、さっそくチームのテスト設計や日々の開発プロセスに活かしていきます。