オンデマンドデプロイ実現までの展望と現在の取り組み

自己紹介

改めまして、令和トラベルでQAエンジニアをしているOsuです。

令和トラベルでは、主にテストの自動化を主なミッションとして取り組んでいます。いま取り組んでいる1つの目標として、オンデマンドデプロイの実現を掲げています。

この記事では、「なぜオンデマンドデプロイを実現させるのか？」や「オンデマンドデプロイをどうやって実現しようとしているか？」について、現在の取り組みと併せてお話ししたいと思います。

まずは私の経歴について簡単にお話しをさせてください。

【略歴】

1社目：株式会社SHIFT

2社目：株式会社Yappli

3社目：Ubie株式会社

現職：株式会社令和トラベル

SHIFT社でQAエンジニアのキャリアをスタートしてから、さまざまなプロダクトに関わらせていただきました。

その中で、リグレッションテストのような定型的なテスト業務を効率化したいという想いが募ったり、業務の過程で培ったAPIテストの活用などを検討したことがテスト自動化に興味を持ったきっかけだったと思います。

そして、テスト自動化に従事するようになってから、テスト自動化で到達するべきゴールについて考えるようになりました。

2社目以降の会社は自社プロダクトを開発していたこともあり、QAエンジニアとしてプロダクトのリリースサイクル改善について話す機会が多く、そのなかで、自動テストを活用することでプロダクトのリリースサイクルへ貢献することができることを学びました。

それから、半ば「テスト自動化」自体が目的化していた考え方を変えて、リリースサイクルの改善やエンジニアの開発生産性を向上することに寄与するためにできることの1つとして、テスト自動化があると考えるようになりました。

現在令和トラベルでは、開発組織の方向性でもある「品質と開発スピードのトレード・オン」の実現に向けて業務に取り組んでいます。「オンデマンドデプロイの実現」は、その中で取り組んでいる1つの施策です。

オンデマンドデプロイとは?

オンデマンドデプロイ（On-Demand Deploy）とは、ソフトウェアのデプロイメントを、必要に応じて任意のタイミングで実行できる方式を指します。

一般的にアジャイル開発によるソフトウェアのリリースは「n週間に1回」など定期的にリリースするプロダクトが多いと思います。定期的にリリースすることで計画性を上げ、安定したリリースを実現できるからです。

一方で、定期的なリリースにはリリース内容の調整が都度必要であったり、基本的に予定外のリリースは避けるためリリース速度をあげるのが困難な傾向があります。

そこで、さきほど挙げたオンデマンドデプロイを活用することで、リリースを迅速に行いプロダクトのデリバリ速度を上げることができます。

定期リリースとオンデマンドデプロイの大まかな比較は以下の通りです。

比較項目	オンデマンドデプロイ	定期リリース
迅速な機能提供	◎ (任意のタイミングで提供可能)	△ (基本的に決まったタイミングで提供)
自動テストの重要性	◎ (非常に重要)	○ (重要)
デプロイごとのリリースサイズ	○ (小さくなる傾向)	△ (大きくなる傾向)
運用負荷	△ (リリース回数に比例)	○ (リリース回数に比例)
適用シナリオ	絶えず変化するビジネスニーズに迅速に対応する必要がある場合	安定性と品質が特に重要で、周期的なリリースが可能な場合

オンデマンドデプロイにも定期リリースにもフィットするシチュエーションはそれぞれですが、

『NEWT（ニュート）』の開発において、なぜオンデマンドデプロイが適していると判断したのか紹介します。

オンデマンドデプロイを目指すワケ

まずは、令和トラベルのプロダクト開発サイクルを紹介します。

https://speakerdeck.com/reiwatravel_0405/20241106-company-deck-for-engineers

事業KPIのミッションに沿った形でスクラムチームが形成され、1チームの中でPM、デザイナー、フロントエンドエンジニアやバックエンドエンジニア、QAエンジニアなどが所属しています。

基本的に1週間1スプリントのサイクルで進めており、毎スプリントロードマップや企画の議論をはじめとして、仕様策定 ~ リリースまでチーム全員が関わって推進しています。

その中で極小な変更であれば簡易的なテストを実施してリリースすることもできますが、ある程度影響範囲を持っている場合定期リリースに含む必要があるため、どれだけ早く施策を考えても、要件定義 ~ リリースまで最低1~2週間はかかります。

しかし、市場やトレンドは絶えず変化するため、都度、施策を早く正確に打ちたいという想いがあります。

令和トラベルでは、海外旅行予約アプリ『NEWT（ニュート）』というカスタマー向けアプリケーションと、それに関連するデータを管理する基幹システムの2つにプロダクトが分かれています、

基幹システム側では、開発物によりますが、社内への影響がメインになることが多く、自動テストも充実しているため、それを活かしてオンデマンドデプロイに似たリリースを行うこともあります。しかし、NEWT側ではカスタマーへの影響から影響範囲が多岐に渡り、どうしても品質保証工程に時間がかかってしまっています。

先の市場やトレンドの話を踏まえると、最速でフィードバックを得て改善し、再度リリースするといったサイクルを実現し、カスタマーへ最速で価値を提供するためには開発完了次第リリースできることが理想です。

どういったリリースプロセスを構築するとそれが実現可能か考え、事業的な側面や開発生産性などの側面から、組織としてオンデマンドデプロイを取り入れようとしています。

テスト主導のオンデマンドデプロイの特徴

一言でオンデマンドデプロイ導入といっても、導入に際して必要な受け入れ要件は的確に定義する必要があります。

デプロイ回数の向上やデプロイタイミングの柔軟さを実現するためには、これまで定期リリースで行ってきたテストをいつでも実行できることが要求されます。

つまり、これまで定期リリースで行ってきた各機能の個別検証とリグレッションテストまでを自動テストで担保することがオンデマンドデプロイ導入の要件になるということです。

具体的に弊社では直近、下記のようなポイントをクリアしようとしています。

従来のデプロイ課題を解決する

自動テストが不十分である場合、

品質を十分に担保できていない状態でリリースする (リスク高)

品質を担保できるまでリリースしない (定期リリース同様)

人的資源を確保して、都度手動テストを実施してもらう(コスト高)

この選択肢が残るため、不具合もしくは人的、金銭的コストを相当量許容しない限り、実質的に定期リリースと相違ないです。

そのため、いくつかある単位のテスト(Unit Test, Integration Test, E2E Test)を充実させること、そして更にはどの単位のテストがどれだけ整備されていればよいのか明確にしておくことが望ましいです。

信頼性のあるデプロイの実現

迅速なフィードバックとエラー検出の方法を確立できていないと、どれだけリリースしても効果測定や不具合検知を素早くできず、結果として手戻りが発生して定期リリースと同等もしくはそれより遅くリリースすることになり、生産性や安全性の向上が難しくなります。

リリース後に常に人力で見張るのは効率的とはいえず、都度人間の手を必要とすると信頼性高く、冪等性を持ったプロセスにできないため、デプロイのフィードバックやエラーは速やかに回収することが望ましいです。

このなかで、現在は特に自動テストに焦点を当てた取り組みを主に行っているため、それについて紹介させてください。

テストベースのオンデマンドデプロイ装着ステップにおける現在の取り組み

ブランチ戦略とテスト計画の策定:

各ブランチに対応したテストスイートの設定

自動テストの活用:

Unit Test、Integration Test、E2E Test など

モニタリングとテスト結果の活用:

テスト結果を活用したデプロイ判断とモニタリング

このテスト拡充ステップの中で、現在私たちが取り組んでいるのは「自動テストの活用」です。

NEWTは主に「Web」「App(iOS/Android)」「Backend」３つのコンポーネントに分かれています。

それぞれのコンポーネントで現在のテスト拡充の取り組みは異なっており、

Backend：Unit Test, Integration Test カバレッジ向上

Web：Playwrightを用いたリグレッションテスト自動化

App：MagicPodを用いたリグレッションテスト自動化

となっています。

特に、WebとAppの自動テストについては、最も大きい単位のテストであるE2Eテスト、そしてリグレッションテストの自動化を完了させることを目下の目標としており、具体的には、リグレッションテストで利用しているテストケースを自動テストにあった形にコンバートし、そのケースをベースに開発メンバーやQAメンバーで実装を進めています。

本来Unit Testなど小さな単位から進める方が全体像を組みやすく、シナジーのある自動テスト体系を構築しやすいですが、一方でこれを実現できると、リリース前のリグレッションテストを省くことができることを筆頭に、短期で得られるリターンも大きく、それを旗印にして他の自動テストも推進しやすくなります。

これらを実現した上で、それぞれのコンポーネントでUnit TestやIntegration Test、E2E Testをさらに改善していくことでプロダクトの特性にあったテスト分布や構成を構築していきたいと考えています。

また、実装するだけでなく、反復継続してメンテナンスし、新規プロジェクトの開発などに並走しながら自動テストをメンテナンスする運用ワークフローの構築も目標として含まれているので、本来の目的である「自動テストによる従来のデプロイ課題の解決」に対して適切なアプローチとして作用すると思っています。

持続可能な自動テスト運用ワークフローについては、現在、開発メンバーとQAメンバーで議論しはじめたタイミングなので、まだまだこれから突き詰めていく部分はありますが、開発組織全体を巻き込みながら進めていくことで足並みを揃えて、「品質と開発スピードのトレード・オン」というテーマに向き合っていきたいです。