こんにちは！クオカード デジタルイノベーションラボ（以下、ラボ）の採用担当・金子です。
今回は、プロダクトの品質を支えるQAチームのリーダー・dobbyさんにインタビューを行いました。
2回目のインタビューとなる今回は、QAチームが要件定義の段階から関与するようになったことでの効果や自動化の推進、生成AIの活用についてお話を伺いました。
なお、1回目のインタビューでは、dobbyさんの入社理由や入社後のエピソード、「dobby」の由来についてもお話いただいています。ぜひ、あわせてご覧ください。
開発チームとの密な連携と主体的な行動
──2度目のインタビュー、ありがとうございます！ 前回から半年ほど経ちましたが、改めて現在の開発チームとの連携について教えてください。
大きな変化はありませんが、引き続きQA観点での早期キャッチを目的に、開発チームのデイリースクラムに参加し、スプリントプランニングの結果も都度確認しています。 また、テストケースの観点出しでは開発メンバーにレビューを依頼するなど、日々連携しながら進めています。
──日々の業務で意識していることはありますか？
こちらも引き続きになりますが、「主体的に動くこと」を大切にしています。 たとえばバグ起票の通知を受け取った際には、受け身にならず自ら内容を確認し、テスト項目の追加や影響範囲の調査を行っています。
また、質問やチケットを起票する際には「なぜこの対応が必要なのか」「背景は何か」といった意図を明確に伝え、認識のズレが起きないよう心がけています。
シフトレフトとUSDM方式による上流品質の向上
──QAチームで進めている「シフトレフト」について、どのように捉えていますか？
「バグの早期検出を通じて、上流の品質を高める手法」として捉えています。 そのため、要件定義の段階から関与し、仕様の曖昧さや漏れを早期に検出して改善に繋げることを重視しています。
──特に効果を感じた取り組みはありますか？
USDM方式を活用したテストケースの洗い出しは、とても有用だと感じています。 USDM方式（Universal Specification Describing Manner）は、要求仕様を正確に記述するための手法で、ユーザーストーリーを起点に要件や仕様を整理することができます。 これにより、仕様の抜け漏れを早期に発見できるようになり、重要度の高いテストケースを優先的に洗い出すことが可能になります。
わかりやすくまとまっている参考記事として、Skyさんが公開されている以下のページをご紹介します。
ある案件では、USDM方式を活用したことで、仕様の抜けやエラー処理ステータスの不足を早期に発見することができました。開発チームから「助かりました」と言ってもらえたのが、印象に残っています。
──導入の背景と現在の運用は？
一人目QAエンジニアとして入社した当初から、「限られたリソースの中で、ユーザー視点で優先度が高いテストを、いかに効果的に行うか」という課題感がありました。その解決策として、USDM方式を導入しました。
現在は、要求仕様書をもとにQAチームで観点を洗い出し、Miroのマインドマップに整理。その内容を開発チームにレビューしてもらい、テストケースの作成に活用しています。
すべてをUSDM方式で進めているわけではなく、詳細なAPI仕様に基づき、網羅的に確認したいフェーズでは機能ベースのテストも併用しています。プロジェクトの目的やフェーズに応じて、使い分けています。
──運用面での課題や今後の展望は？
マインドマップの情報量が増えるにつれて視認性が低下し、レビュー時の負荷が高くなる点が課題です。 また、観点を掘り下げていく中で、本来の目的を見失ってしまうこともあります。
今後は、視認性を担保しつつ、「この要件は何を解決するためのものか？」という本質を捉えた観点抽出ができるよう、フォーマットの整備を進めたいと考えています。
さらに、担当者によって観点の粒度にばらつきが出やすいため、チェックリストの共通化などを通じて、チーム全体の品質の平準化にも取り組んでいきたいです。
自動化の戦略と段階的な推進
──テスト自動化の現状と今後の方針を教えてください。
現在、APIテストとE2Eテストの一部について自動化を進めています。
APIテストは、主にバックエンドの安定性を担保する目的で進めており、発行や決済などの主要フローに加え、エラー系や境界値のケースも網羅的にカバーしています。 PostmanとNewmanを用いたテストを、GitHub Actionsと連携し、プルリクエスト単位での自動実行を実現しています。
現在は、ローカル環境で実行しているAPIテストを、検証環境でも動かせるよう整備中です。インフラチームの協力で環境構築は完了しており、今後はCodeBuildを活用してGitHub Actionsから検証環境で自動実行できるようにしたいと考えています。
フロントエンドのE2EテストにはPlaywrightを導入し、社内システムの動作確認やフォーム送信、画面遷移など、クリティカルパスとなるユーザーフローを中心に自動化を進めています。Headlessモードでの高速な実行に加え、失敗時にはスクリーンショットやログ出力を活用し、原因特定の効率化にもつながっています。今後は、ECサイトやモバイルアプリへの対応を進めていく予定です。
──自動化における優先順位は？
ユーザーへの影響が大きい機能、特に決済部分などを優先しています。 ユーザーシナリオに沿ったテスト設計をベースに、自動化が難しい箇所については手動テストも併用しながら、効率と網羅性のバランスを意識したテスト戦略を進めています。
生成AIの活用と今後の活用方針
──生成AIの活用状況を教えてください。
APIテストの自動化やE2Eテストの実装、自動テストのコードレビュー、仕様の一次確認など、さまざまな場面で活用しています。
現在は主にDevinとCursorを使っています。 使用感としては、Devinはコードレビューや仕様の一次確認に、Cursorはテストケースの洗い出しやコードの実装支援に適していると感じており、特性を踏まえて使い分けながら活用しています。
──生成AIを活用する際に意識していることは？
ツールごとに得意・不得意があり、さらに日々進化しているので、常に最新の情報をキャッチアップしつつ、適材適所で活用することを意識しています。
また、最終的には必ず人の目での確認を行うことで、品質を担保するようにしています。
──今後、新たに生成AIを活用したい箇所はありますか？
今後は、機能ベースでの網羅的なテスト設計にもAIを活用し、さらに効率的かつ抜け漏れの少ないテストを目指していきたいです。
今後のチャレンジと、応募を考えている方へのメッセージ
──今後、チャレンジしたいことはありますか？
まずは、チーム全体のスキルの平準化に向けて、観点だしやテスト設計のフォーマット整備、ナレッジ共有の仕組み作りに注力していきたいと考えています。
また、今後はモバイルアプリのE2Eテストにもチャレンジしたいです。Webアプリと比べて使用ツールも異なるため、まずはチームでインプットしながら、段階的に進めていけたらと考えています。
──最後に、ラボへの応募を検討している方にメッセージをお願いします。
ラボは、新しい技術や手法について、課題解決につながるものであれば積極的に受け入れてくれる環境です。
責任者の齋藤さんをはじめ、チーム全体が生成AIの導入や業務改善に前向きなので、主体的に動いて業務改善など進めていきたい方、新しい手法にチャレンジしてみたい方にはぴったりの職場だと思います。
以上、dobbyさんへのインタビューをお届けしました。
プロダクト品質の向上に向けて、USDM方式の導入や、生成AIの活用など、日々工夫と挑戦を重ねている様子がとても印象的でした。
最後に
ここまでお読みいただき、ありがとうございました！
クオカード デジタルイノベーションラボでは、一緒に働く仲間を募集しています。 「課題を自ら見つけて解決していきたい」 「新しい技術や手法にもどんどんチャレンジしてみたい」
そんな思いをお持ちの方は、まずはぜひカジュアル面談でお話しましょう！
