プロダクトエンジニア×QAエンジニアでもっと”一緒に”つくるリグレッションテスト

2026春QAエンジニアリレーブログ QA

この記事は「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。

2026春QAエンジニアリレーブログの、3本目の記事です。

こんにちは！サイボウズでQAエンジニアをしている tagashira です！

kintone システム管理/外部連携チームの機能開発のQAを担当しています。

このたび、社内カンファレンスのセッション企画にて、各チームのQAエンジニアが「テスト実施以外の、QAエンジニアの活動」をテーマに発表を行う機会がありました。

そこで私は「プロダクトエンジニア×QAエンジニアでもっと”一緒に”つくるリグレッションテスト」というテーマで発表したので、その内容を紹介します。

目次

機能開発の中で、どのようにリグレッションテストを作ってますか？

これまでのリグレッションテストのつくりかた

さっそくですが、みなさんのチームでは、日々の機能開発の中でリグレッションテストをどのように作っていますか？

私の所属するチームでは、次のような作り方をしていました。

  • テストケース設計：QAエンジニア（以下QA）、プロダクトエンジニア（以下PdE）

  • テストケース実装：PdE が実装し、別の PdE がレビュー

このような役割分担になっていたことにより、

  • テストケースの設計/設計の見直しはQAの責任（※ただし、実装に備えて PdE も設計から関与する）

  • テストコードの実装/メンテはPdEの責任

という暗黙の了解が生まれていました。

気になっていたこと

上記の進め方をしていたことによって、QAである私は、テストコードの責任が暗黙的にPdEに寄ってしまうことが気になっていました。

また、実装のプロセスに関与していないことによって、実装の観点をQAが持ちづらいことや、その後の運用・保守の観点をQAが持ちづらいといった機会損失があると感じていました。

「越境」してみよう！

そう考えた私は、次のようなTryをチームで行うことにしました。

テストコードの実装をQAが担当してみる

リグレッションテストの作り方を、次のように変更しました。

  • テストケース設計：引き続きQA, PdEで実施
  • テストコード実装：実装 → QA, レビュー → PdE

テスト実装のタイミングとしては、PdEがプロダクションコード, 単体テストコード実装完了後、QAに完了連絡をしてもらうようにしました。そのタイミングでQAが、プロダクションコード実装ブランチからリグレッションテスト実装用のブランチを切って、実装を行うようにしました。

得られたもの -QAの視点から-

実際にテスト実装をやってみて

本体実装の詳細を知らなくてもテスト実装できるという気づきがありました。

これまで、「本体実装の詳細を知らないとテスト実装ができないかも？」という思い込みがあったのですが、実際には、正しい振る舞いや仕様と公開インターフェースを理解できていればテスト実装は可能でした。

また、副次的ではあるのですが、実装の詳細を知らないことによって、内部構造に依存しない、変更に強いテストが書けるという気づきもありました。

これを裏返すと、実装の詳細を知らないと書けないテストは、設計を見直した方がよさそうといった会話もチームの中で生まれました。

コードレビューを通じて

テスト実装を担当してみると、テストケースの観点を満たせてはいるものの、実装観点からみて愚直なコードや不要な処理を書いてしまうことがありました。

今回のTryでは、コードレビューでPdEに関与してもらう形で進めていたため、実装の観点からレビューをもらい、洗練されたコードに磨き込むことができました。

普段の業務の中で、あまりコードレビューをしてもらう機会は多くないため、QAにとって貴重な実装観点の学びの場になりました。

テスト運用から得られたフィードバック

テストの運用の中で、CI での不安定な挙動といったトラブルにも遭遇しました。

テストケースに複数の観点が混在し実行時間が伸びて時々タイムアウトする問題については、テストケースを分割するという運用から設計へのフィードバックがありました。

また、タイミングに依存している実装になっているため、実行時の状況に応じて時々失敗する問題については、不安定になりにくい実装への見直しという運用から実装へのフィードバックがありました。

いずれも、運用を通じて設計・実装へとフィードバックが生まれた事例です。

得られたもの -チーム全体の視点から-

得られた効果

① テスト設計・実装の両プロセスで知識が共有されるように

PdE/QAお互いがそれぞれのプロセスに関わることで壁が崩れ、これまで一緒に行っていたテスト設計だけでなく、テスト実装も含めた両プロセスで知識が共有されるようになりました。

② リグレッションテストがPdE/QA両方の資産であるという実感を得られるように

QA視点では、実装・運用まで関与したことで、テストコードまで含めた今後の改善に積極的に取り組みやすくなりました。

③ PdE/QA間でのリソースの融通が効くように

チームでの開発の進め方として、機能開発の中でQAにテスト設計だけではなく実装まで担当してもらうことを選択できるようになりました。これにより、PdE/QA間でのリソースの融通が効くようになるという効果が得られました。

「テストコードはPdEに実装してもらうもの」という認識だと、そこに主体的に改善を入れていくのはなかなか難しいと感じていましたが、設計から実装、運用まで関わることで、QAにもテスト全体へのオーナーシップが生まれました。

高速化する開発と、リグレッションテストの必要性

プロダクションコードの実装がCoding Agentで日に日に高速化していく時代ですね。

変更量が増えるほど、既存機能を壊していないことの保証が重要になります。高頻度かつ高速な保証のために、自動化されたリグレッションテストが整備されていることが今後の高速な開発における前提になると考えます。

Coding Agent とテスト実装の落とし穴

Coding Agent はテスト実装も担ってくれますが、落とし穴があると考えています。

それは、「人力よりも実装コストがかからないのだから、とにかくテストを増やしてカバレッジを上げればいい」という思考に陥りやすいというものです。

何をテストしているのかが曖昧になりやすく、目的が不明瞭な大量の既存のテストをベースにさらにたくさんのテストが実装されます。

その結果、メンテナンスコストが膨らみ、テストの恩恵を感じにくくなることに繋がります。

チームでリグレッションテストの方針を明確にし、AIにはその方針に沿って作業を代替してもらうことが重要です。

おわりに - 世は大 Coding Agent 時代！-

今回の取り組みを通じて、メンバー間で「越境」してお互いの領域に踏み込むことが、リグレッションテストをチーム全員がオーナーシップを持った資産にする第一歩になると感じました。

Coding Agent がテストを量産できる時代だからこそ、「何を・なぜテストするのか」の手綱を握れるチームをつくることが、これからの備えになると考えています。

読んでいただいたみなさんにとって、何か少しでも参考になる箇所があれば幸いです。

次回のセッションの記事もお楽しみに！