published
published
author
authorDisplayName
Yuki Masuyama
category
QA
mainImage
publishedAt
Dec 25, 2025
slug
Advent-Calendar-20251225
tags
advent calendar
QA
この記事は、「NEWT Product Advent Calendar 2025」Day19 および「ソフトウェアテスト・QAの小ネタ Advent Calendar 2025」Day25 の記事となります。
「NEWT Product Advent Calendar 2025」19日目は、令和トラベル QAエンジニアのmassuが、PM rihoからバトンをもらい執筆。ぜひ、最後までご覧ください！
令和トラベルでは、今期より、AI活用前提で開発が最適化された未来へ向けた、エンジニアリング戦略やQAエンジニアのあり方の再考が行われました。
今回の記事では、実際に自分が所属する海外旅行ツアー事業を扱う「NEWT Tour(ニュートツアー)」チームで起こった変化や、その中でQAエンジニアが目指す役割、その過程で生まれた課題と改善の手応えを紹介します。
※意思決定の背景はmiisanのblogで綴られているため、こちらを一読いただければと思います。
前提
NEWT Tourチームとは？
旅行アプリ『NEWT（ニュート）』には「海外ツアー予約」と「宿・ホテル予約」の大きく2つの機能がありますが、その中で前者の機能開発をするチームです。
2025年9月以前は、スクラム開発の体制を取っており、プロダクトマネージャー / デザイナー / エンジニア（Backendエンジニア / Frontendエンジニア / アプリエンジニア / QAエンジニア）で構成されたメンバーで、1週間のスプリント内でリリースサイクルを回していました。
組織体制・開発体制の変更
組織体制の変更
以前は各職能ごとでチームが分かれていましたが、Backendエンジニア / Frontendエンジニア / QAエンジニアが同じエンジニアリンググループへ内包されました。
NEWT Tourチームの開発体制のアップデート
NEWT Tourチームの開発者全員が同じグループとなり、さらに密接なコミュニケーションができるようになりました。そして、良いものをより早くカスタマーに届ける開発体制にチャレンジするために次の挑戦をしました。
- スプリントを廃止し、柔軟なリリース体制の構築
- Backendエンジニア + Frontendエンジニアのバディ制の開発体制の採用
- 開発者によるセルフテストの拡大
- プランニングなどのスクラムイベントを廃止し、ピッチ制度を導入
※バディ制とピッチ制度の詳細は後述します
NEWT Tourチームの開発体制を変更した背景
NEWT Tourチームは、カスタマーの流入拡大や予約率増加など不確実性の高い課題に取り組むため、仮説を立てデリバリー後に検証して振り返るサイクルを高速に回して精度を高めていく開発体制にする必要がありました。
具体的な開発の進め方
バディ制の導入
BackendエンジニアとFrontendエンジニア1名ずつでペアを組むバディ制を導入しました。この体制を設けた目的としては2つです。
- 開発の並列度を上げて複数課題に着手できるようにするため
- バディメンバーの自律性を高めるため
10名程度の開発者が所属するNEWT Tourチーム内に複数のバディができ、各バディで調査・開発を進めることでチーム内での複数の課題に着手できるようになりました。
次に開発する優先順位や要件などが全てチケットとして、チームのバックログ内にまとめられています。着手するチケットをバディ間で決めて、調査や実装を進めていくなかで必要に応じてアプリエンジニアやQAエンジニアを巻き込み、コミュニケーションを取ることでバディが自律的に開発を進められるようにしています。
また、バディからのコミュニケーションを待たずに、アプリエンジニアやQAエンジニアからも取り組んでいるチケットについて考慮事項や影響範囲を双方向から確認することで、早期に不具合の作り込みを防ぐようにしています。
ピッチ制度
進捗共有と情報連携を最小限にするためにスクラムイベントのスプリントプランニング、スプリントレビュー、レトロスペクティブを廃止して、ピッチを週に1回開催するようにしました。
ピッチでは、プロダクトマネージャーが施策を持ち込み、デザイナー、Backendエンジニア、Frontendエンジニア、アプリエンジニア、QAエンジニアの各視点で仕様や考慮事項の洗い出し、工数のポイント付け、他施策との優先順位などを議論します。
この議論をすることで、考慮漏れの早期発見による手戻りの減少、各ロールの考えや見ているポイントを知ることで相互の知見向上に役立っています。
プランニングのようにスプリント内で着手するタスクは決めず、開発優先順位を決めてバックログに置いておきます。バディが手が空いたタイミングで優先順位の高いものからチケットを取り、開発できるようにするためにこの形式にしております。
また、施策の話だけでなく、障害分析のサマリー共有、リリースが完了した施策の分析結果の振り返りなど、チームで共通認識の構築や開発力の底上げへと繋げています。
リリースサイクルをより柔軟に
これまではスプリント単位が1週間で週に1度リリースしていましたが、良いものをより早くカスタマーに届けるために、週に2回以上スプリントに縛られず柔軟なリリースができるようにスプリントを廃止しました。
現在ではアプリは週1〜2回、Webやバックエンドは週2回以上安定してリリースできるようになりました。
QAエンジニアの役割
テスト業務
開発はバディ体制で進めていますが、QAエンジニアは特定のバディに所属せず、1人で複数のバディチームに関わります。
開発スピードと並列度が上がったことにより、これまでのようにすべてのタスクをQAエンジニアがテストする事が難しくなったため、テスト業務への関わり方を変更しました。
- 影響範囲が広く確認項目が多い施策や、予約 / 決済機能などのクリティカルな機能開発ではQAがテスト計画〜実行までを担当
- 上記に該当しない場合は、考慮事項やテスト項目をピッチや読み合わせで開発者と相談。テストが複雑なものはQA、複雑でなければ開発者がテストを担当
このように状況に応じて、開発者と相談してテスト分担を決めています。
品質向上・インシデント再発防止のための仕組み作り
重篤度の高いインシデントを未然に防ぐこと、検知スピードを早くすることがQAエンジニアのKPIの一つです。インシデント発生率、検知経路、混入した時期などの観点で毎月計測して分析することで傾向をサマリー化しています。
どういった仕組みがあれば未然に防げたのかと、リリース後にどうすれば早く気づけるのかといった視点でプロセス改善しています。
アプリチームと連携したリグレッションテスト
週2回以上のリリースを実現するために一番の課題はアプリのリリースでした。WebはE2Eテストの実装と運用も完了しており、1週間で複数回リリースが可能な基盤が整っていました。
しかし、アプリは技術的制約の解消が必要であったり、E2Eテストの実装中のためリリース前に手動でリグレッションテストする必要があり、1度のリリースに時間が掛かっている状況でした。
元々、週1回で回していたリリースプロセスは下記の通りです。
- 金曜日までに開発環境でそれぞれテストを完了し、Staging環境にマージ
- 土日にPP（*令和トラベルでは、業務委託の方をプロパートナー(PP)と呼んでいます）エンジニアが手動のリグレッションテストを実施
- 月曜日にリグレッションテストの結果確認後、問題なければアプリストアに審査提出
- 火曜日にアプリ公開
スプリントを廃止したことで、決まった曜日に縛られずリリースできるようになりましたが、週2回以上リリースするためには数時間掛かるリグレッションテストの運用を見直す必要がありました。
手動のリグレッションテストを週に複数回実施できるように次の改善をしました。
- リグレッションテストケースをアプリエンジニアと相談して不要ケースを棚卸し
- コード上は依存がない。テストコードで担保されているケースの精査
- 会員登録〜予約・キャンセルというシナリオベースのテストケースをやめ、会員登録 / 検索 / 予約など、機能毎のケースに分解
- 機能毎のテストケースにすることで、リリースしたい内容に応じて実施ケース選定が容易になり、1度に実施すべきケース数も軽減
- アプリエンジニアとも相談して、マイナー / メジャーライブラリアップデートなどで変更内容に応じて見るべき機能とケースを明確化
手動のリグレッションテストに数時間掛かっていたのが平均30分以下、メジャーアップデートなどの全ケース確認する場合でも3時間程度まで効率化できました。
3ヶ月の運用でどうなったか？
導入した効果
リリース回数の増加
10月からバディやピッチ制度、スプリントの廃止によりリリース回数は増加しました。
チーム内の案件以外の開発時間の増加
開発速度が上がったことで、プロダクトマネージャーが企画した施策の流入数よりも開発完了してリリースする消化数が多くなりました。
そのため、優先度が上がらなかった不具合の修正、技術負債やリファクタリングなど将来的な投資に取り組む時間が増えました。
開発とQAエンジニアと連携が活発になった
ピッチでの議論やバディとの影響範囲やテスト観点の相談などで開発とQAエンジニアの間で連携する機会が増えました。
体制変更前に比べてコミュニケーションも増えたこともそうですが、連携忘れや認識齟齬も改善されてきました。
おわりに
令和トラベルでは組織の戦略やチーム体制の変更に応じて、QAエンジニアの役割も進化しています。これからも変化にあわせて、良いものをカスタマーにより早く届けられるように ”品質” と ”スピード” の両立を実現できるように挑戦していきます。
もし、ご興味をいただけたら是非、↓↓からイベント参加やカジュアル面談などお気軽にお申し込みください！
📣 1月のイベント開催のお知らせ
令和トラベルでは、技術的な知識や知見・成果を共有するLT会を毎月実施しています。発表テーマや令和トラベルに興味をお持ちいただいた方は、誰でも気軽に参加いただけます。
【1/28 開催！3社共催】モバイルアプリ開発 ✕ AI ー 組織・技術課題と向き合い、AIと走る
2026年のスタートを切る1月の「NEWT Tech Talk」は、”モバイルアプリ開発 ✕ AI ー 組織・技術課題と向き合い、AIと走る” というテーマで開催。
クラシル株式会社 なぐもさん、株式会社ヤプリ にゃふんたさんをゲストに、令和トラベル やぎにいの3名が登壇します。モバイルアプリ開発の現場で、AI活用に取り組む3社のエンジニアが、個人・チーム・技術課題それぞれの視点から、AIとどのように向き合い、どのように開発を前に進めてきたのか、具体の取り組みをシェアしながら語ります！
そのほか、毎月開催している技術発信イベントについては、connpass にてメンバー登録して最新情報をお見逃しなく！
【NEWT Chat リリース記念】AI × Travel Innovation Week 開催！
12月3日〜6日の4日間、「NEWT Chat」誕生の裏側や開発ストーリーをお届けする特別企画 “AI × Travel Innovation Week” を令和トラベルのnote上で開催しました！
「NEWT Chat」のリリース背景、プロダクトの価値、開発体制、そして今後の展望など、新規事業の “舞台裏” を公開。特に、AIプロダクト開発に関わるエンジニア・PMの皆さまにとって学びの多い内容となりますので、ぜひご覧ください。
▼ AI × Travel Innovation Week のnoteはこちら：
旅行・観光業に特化したAIエージェントチャット「NEWT Chat（ニュートチャット）」についてはこちらから。
令和トラベルでは一緒に働く仲間を募集しています
この記事を読んで会社やプロダクトについて興味を持ってくれた方は、ぜひご連絡お待ちしています！お気軽にお問い合わせください！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください。
1年間の感謝を込めた、”クリスマスセール🎄” 開催中！
NEWTでは現在、海外旅行やホテルをおトクにご予約いただける『クリスマスセール🎄』を12/4〜スタートしています！ぜひこの機会にご利用ください！
📣宣伝
12/1から繋いできたアドベントカレンダーもいよいよ明日がラストです！「NEWT Product Advent Calendar 2025」Day20は、「入社から8か月。AIファーストへ進化する令和トラベルで感じた変化と挑戦」と題して執行役員CIOのtomonagaが担当します。次のブログもお楽しみに！
