こんにちは、クラスター株式会社のソフトウェアエンジニアの
id:shiba_yu36です。最近はソフトウェアエンジニアとして機能改善を行うと同時に、開発フロー改善にも取り組んでいます。
開発フロー改善の一環で、QAフローについて課題を感じていました。手厚いQAフローによって障害を最小に抑えていた一方で、機能開発〜リリースまでの期間が長くなってしまっているという課題です。この課題の改善のため、QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する取り組みを行いました。
今回はその取り組みについて紹介します。QAと開発速度のバランスに苦労している方や、QAフローを新しく始めたい方の参考になれば嬉しいです。
背景: クラスターの事業とQAの関係
QAフロー改善を説明する前の前提知識として、まずクラスターにおける事業とQAの関係について、簡単に紹介します。
クラスター株式会社はメタバースプラットフォームである「cluster」というサービスを一般ユーザー向けに提供しています。このサービスでは、ユーザーは3D空間へ自由に入ることができ、複数人が好きなアバターでリアルタイムに遊べます。また、その3D空間自体もワールドクラフトという機能やUnityを活用して、ユーザーが自由に作成しアップロードできます。
引用元URL
一般ユーザー向けにサービス提供している以外に、メタバースを活用したい企業様向けに法人向けメタバース事業を行っています。色々な活用がありますが、その1つとして、メタバースを活用してマーケティング施策をしたい企業さまから依頼を受け、弊社側で3D空間を制作してcluster上にアップロードすることで、一般ユーザーを引き込むような施策を行うというものがあります。この事業のために弊社には3D空間制作チームがあります。
このようにクラスター株式会社では、一般ユーザー向けにclusterというサービスを提供すると同時に、clusterを活用して法人向けメタバース事業も行っています。この構造に対応して、QAチームは2種類のQAを行っていました。
- サービスリリースQA: サービス開発チームがclusterサービスの機能開発をリリースする時に、開発した機能が正しく動くかテストするQA
- コンテンツQA: 法人向けに制作した3D空間が、cluster上で正しく動作するかテストするQA
ここまで紹介したように、クラスター株式会社のQAチームは事業に合わせて2種類のQAを行っていることが特徴です。
これまでのQAの課題
これまでのQAの課題として、次の2つがありました。
- 課題1: QAによって開発チームのコード変更からリリースまでの期間が長くなってしまう
- 課題2: サービスリリースQAとコンテンツQA両方が必要でQAチームの負荷が高い
課題1: QAによって開発チームのコード変更からリリースまでの期間が長くなってしまう
QAチームが行うサービスリリースQAは非常に手厚いフローになっていました。これはサービスの障害を最小に抑えるためです。
以前のコード変更〜QA〜リリースまでの全体像を図にしたものがこちらです。clusterは毎週リリースしているため、このフローを毎週繰り返していました。
簡単な流れを説明すると
- ある機能やバグ修正を次のリリースに含めるときは、QA週より前の木曜日までにコード変更を完了し、開発チーム内で動作確認を行なっておく。ここで発見した問題は金曜までに修正しておく
- 月曜にrelease用のgit branchを作成する
- QA週にQAチームが1週間かけてテストを行う。主に3つのQAを行う。
- 新機能QA: 新規開発した機能について詳細にテストを行う。月〜水曜に行う
- regression QA: サービスの主要機能が全て動作するかを包括的にテストする。水〜木曜に行う
- バグ修正確認: 今回のリリースに含まれるバグ修正が正しく動作するかテストする。水曜 or 木曜に行う
- 木曜にQA承認されたら、開発チームがiOS/Androidアプリの審査を提出する
- 審査が通過したら、QAの翌週の月曜にリリースを行う
このQAフローによって、サービスの障害は非常に少ない状態に保たれていました。しかし一方で、コード変更からリリースまで最短でも12日かかってしまう課題がありました。
コード変更からリリースまでの期間が長いと、次のような問題が起きます。
- あるリリースでバグが発覚しても、直してリリースするまで2週間かかってしまう
- 作ったものを早くユーザーに届けられない。結果としてユーザーの反応から素早く学びサービス改善に活かすことがしづらい。
そこで障害数をコントロールした上で、リリースまでの期間を最短化するため、QAフローを最適化したいと考えました。
課題2: リリースQAとコンテンツQA両方が必要でQAチームの負荷が高い
前述したとおり、QAチームは毎週のサービスリリースQAとは別に、コンテンツQAも行っています。さらに法人向けメタバース事業は複数企業の案件を同時並行で進行しているため、コンテンツQA自体も複数同時に走っている状態でした。
毎週のリリースQAと複数同時並行のコンテンツQAのため、QAチームの負荷が非常に高いという課題もありました。
改善全体方針と改善後のフロー
これら2つの課題を解決するため、全体的な方針は次のようにしました。
- サービスリリースQAは開発チームが行う。QAメンバーと相談し最適なテストケースを決めて、障害数をコントロールした状態でリリースまでの期間を短縮することを目指す
- QAチームにはコンテンツQAに集中してもらい、企業さま向けの事業の品質水準を担保した上で、チームの負荷を軽減する
先に改善後の結果が分かりやすいように、改善後の開発チームのサービスリリースフローを載せておきます。
このフローへの改善の結果、コード変更からリリースまでの期間を最短で6日程度に短縮できました。またこのフローを実施し始めてから半年経ちましたが、顕著な障害増加は起こっておらず、品質もコントロールできている状態を保てています。
サービスリリースの改善後のQAフローに到達するために何を行なったか
ここまでで、サービスリリースのQAフローにどのような課題があり、それを改善して最終的にどのようなQAフローになったかの概要を説明しました。
ではこのサービスリリースの改善後のQAフローに到達するため、どのような手順で改善を進めたかを紹介します。大まかには次のような手順で実施していきました。
- 事業の特性を理解して達成したい品質基準を決める
- 開発フローの制約条件を理解する
- 達成したい品質条件や制約条件を満たすように、QAフローおよびその周辺の開発フローを設計する
- QAメンバーと一緒に、regression QAのテストケースを決め直す
- 決定した最終形に向けて移行計画を作り、徐々に移行していく
ではそれぞれの手順について詳しく説明します。
1. 事業の特性を理解して達成したい品質基準を決める
開発チームでサービスのリリースQAを引き継ぐ場合、開発リソース的に今までの1週間の手厚いフローをそのまま引き継ぐことは難しいです。そのためQAの中で重要な部分のみ抽出する必要があります。
QAの重要な部分を抽出するために、事業やサービスの特性を理解し、達成したい品質基準を先に決めると良いと考えました。
clusterの場合、サービスのコアになっているのは、「ユーザーが作成した3D空間内で複数人がアバターで同期的に遊べる」という体験です。サービス利用ユーザーはもちろん、企業さまもこのコア体験を活用し3D空間内でイベントなどを開催しています。そのため、この体験が担保できていることが最重要であると考えました。
以上から、サービスとして最低限の品質基準を「3D空間内で複数人が同期的に遊べている体験を担保できていること」と決めました。この部分は自動テストでチェックしづらいポイントなので、そういう意味でもQAすべきポイントでしょう。
2. 開発フローの制約条件を理解する
さらに開発フローやQAを調整するにあたって、変更しづらい制約条件を理解しておかなければ、理想的なフローを設計できません。関係各所にヒアリングしつつ整理したところ、3つの制約条件を意識しておく必要があると分かりました。
- 開発チームでQAをやるとしても、週に数時間程度が望ましい
- 理由: QAを増やしすぎると今度は開発時間が取れなくなり、機能開発ができなくなってしまうため
- リリースは今のまま月曜午前で固定する
- 理由: 企業さまとの案件の関係でリリース周りもビジネスメンバーとのコミュニケーションが必要だが、その調整のためにもリリース曜日は固定したい
- アプリ審査はiOSが最も遅く、たいていは24時間で終わるが、もっと伸びることもある
3. QAフローおよびその周辺の開発フローを設計する
ここまでで、達成したい品質基準と開発フローの制約条件を理解できました。これらを踏まえて、QAフローおよびその周辺の開発フローを設計していきます。以下の思考の流れで開発フローを整理しました。
- 審査が24時間以上かかる可能性があり、かつ月曜にリリースしたいなら、木曜夜には審査提出し金曜中に審査が終わっていて、あとは月曜にリリースするだけという状態にしたい
- 木曜夜に審査を提出するなら、逆算すると木曜昼〜夕方にQAを終わらせたい
- 開発チームで全員で集まって木曜昼に一気にQAを終わらせるのが最短のやり方であろう。ミーティング調整の関係で13:00~15:00の2時間で終わらせる方法が良い
- 木曜昼のQAの前に一度も新機能の動作確認していないのは困る。逆算すると水曜までにせめて機能開発している人が動作確認をし、何かバグが見つかったら修正した上でQAに持ってきてもらいたい
この結果、次のようにコード変更〜リリースまでが6日ほどの開発フローを目指すことにしました。
- 機能開発した人は、最悪でも水曜までに自分以外の数名集めて動作確認をしておく。バグを見つけたら修正をしておく
- 水曜夕方にrelease用のgit branchを作成する
- 木曜の昼に開発チーム全員が集まり、新機能QA、regression QA、バグ修正確認を一気に終わらせる
- 2時間程度で完了させられるように、QAのテストケースは調整する
- 木曜夕方にQA含めてリリース承認を行い、iOS/Androidアプリの審査を提出する
- 審査が通過したら、翌週の月曜にリリースする
4. QAメンバーと一緒に、regression QAのテストケースを決め直す
目指す開発フローとして、木曜に2時間で一気にQAを終わらせると決めました。この時間内で「3D空間内で複数人が同期的に遊べている体験を担保できていること」を満たせるようなテストケースを考えなければなりません。
テストケース検討のため、既存のregression QAのテストケースに詳しいQAメンバーと一緒に必要最低限の項目をピックアップしていきました。ここは非常に地道な作業で、二人で既存QAテストケースを眺めて、以下の順で作業をしました。
- 複数人の同期的な体験の担保のためのテストケースのみピックアップ
- さらにそのテストケース群に対して、利用頻度などを考慮し、1つ1つ重要度付けていく
- 時間内に終わらせられる範囲で、重要度順にテストケースを選定していく
この作業の後、僕の方で開発チームがQAしやすいような粒度にテストケースを調整し、最終的に70ほどのテストケースを作りました。
5. 決定した最終形に向けて移行計画を作り、徐々に移行していく
ここまでで最終形の開発・QAフローと、regression QAのテストケースを決められました。しかしフローの変化が大きいため、一気に変更すると混乱が生まれそうです。
そこで少しずつ移行していく計画を作り、開発チームがQAしていくフローに徐々に慣れていくようなやり方を取りました。
- リリースまでの期間は変えずに、regression QAとバグ修正確認のみを開発チームに移行し、2週間ほど実施する
- 図の斜線部を廃止し、丸の部分をフロー変更
- regression QAとバグ修正確認を問題なく行えたら、さらに新機能QAを開発チームに移行する
- 開発チームでのQAに慣れてきたら、コード変更〜QA〜リリースまでの期間を短縮する
ここまでで計画を作れたので、あとは淡々とフロー変更を行い、問題が起きたら調整をしていきました。
移行後の結果
何度も再掲しますが、移行後のフローは次のようになりました。
このフローへの変更によって、コード変更〜リリースまでの期間を最短で6日ほどに短縮できました。この結果、バグ修正リリースに時間がかかる、作ったものを早くユーザーに届けられないという2つの課題が改善されました。
また今年初めからこのフローを実施し始めてからしばらく経ちましたが、次のような状態となっており、障害数をコントロールできていることが確認できました。
- 2024年に発生した障害数が25件に対し、2025年に発生した障害数は16件ほど
- サービス完全ダウン・特定の重要な機能が全く使えなくなるなどのクリティカルな問題も起きていない
さらにQAチームから開発チームにサービスのQAを引き継いだことで、逆にQAチームはコンテンツQAに集中できる状況も作り出せました。
これらから最初の課題であった、「コード変更からリリースまでの期間が長い」「リリースQAとコンテンツQA両方が必要でQAチームの負荷が高い」という2つの課題が解決できたのではないかと感じています。
まとめ
今回はQAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する取り組みについて紹介しました。今回の取り組みや考え方は、QAと開発フローのバランスを調整したい時にも、QAフローを新しく始めたい人にも役立つものになっていると考えています。ぜひ参考にしてみてください。
