QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する RSGT2026

QAフローが大変で開発したもののリリースに時間がかかってしまうという悩みはありませんか？

クラスター株式会社では障害を最小に抑えるため厚いQAフローを運用していました。このフローによってサービスの可用性品質は非常に高い一方で、開発を終えたものをリリースするまで最低でも10日かかるという課題がありました。

ソフトウェアエンジニアの立場からこの課題を解決するため、、障害数をコントロールした上でリリースまでの期間を最短化する方法を模索・提案し、改善を進めました。具体的に次のことを一つずつ進めました。

- 事業の特性を理解して達成したい品質基準を決める
- 開発フローの制約条件を理解する
- 達成したい品質条件や制約条件を満たすように、QAフローおよびその周辺の開発フローを再検討する
- QAメンバーと一緒に、QAのregressionテストのテストケースや、テストすべき内容を決め直す
- 決定した理想系に向けて移行計画を作る
- 3ヶ月かけて、理想系まで移行する

改善の結果、以前は開発終了からリリースまで12日必要だったものが、今は最短で6日ほどでリリースできるようになりました。さらに新しいフローになった後も顕著な障害増加はなく、可用性品質をコントロールできている状況を作り出せました。

本セッションでは、私がQAフローの運用の最適化を行なった具体的な経験を紹介し、QAフローを最適化する時、もしくはQAフローを新しく始めたい時に何が大切かをお伝えします。

Transcript

1. QAフローを最適化し、 品質水準を満たしながら リリースまでの期間を最短化する 2026/01/08 柴﨑優季 (shibayu36) 1
2. 自己紹介 • 柴﨑 優季 (shibayu36) • クラスター株式会社シニアソフトウェアエンジニア ◦ 開発フロー改善などの業務も ◦ ❌ QA担当 ✅ 開発エンジニア • ブログをよく書いています ◦ https://blog.shibayu36.org/ 2
3. 本日話すこと • クラスター株式会社では手厚いQAフローで障害が少な かった • しかし開発〜リリースまで12日以上かかる課題があった • 開発チームの立場からQAフローを最適化し、品質水準 は保ったまま、開発〜リリースまで6日に短縮した • 具体的な改善内容と、振り返って何が成功要因だったか を伝えたい 3
4. 4 Before/After 非常に長いフローがコンパクトに
5. 5 対象聴衆と持ち帰ってほしいこと • QAフローのコスパが悪く最適化したい人・QAフローを新 しく始めたい人 • QAフローの設計のため、まず何から始めるべきかのヒン トを得られる
6. 6 アジェンダ • 前提: クラスターの事業とQAの関係 • これまでのQAの課題 • 改善方針の決定 • サービスリリースQAフローの最適化の実施 • フロー変更後の結果 • 振り返って何が成功要因だったのか？
7. 7 前提: クラスターの事業と QAの関係
8. クラスターの事業は 2つに分かれる • CtoC事業：メタバースプラットフォーム「cluster」を一般 ユーザー向けに提供 • BtoB事業：メタバースを活用したい企業様向けに、 「cluster」を活用したソリューション提供 8
9. 9 CtoC事業：　　　　　　　の一般ユーザー向け提供 • 誰でも使えるバーチャル空間のプラットフォーム • ユーザーは3D空間へ自由に入り、複数人が好きなアバ ターでリアルタイムに遊べる • 3D空間もユーザーが自由に作成・アップロードできる
10. 10 BtoB事業：cluster 上の3D空間を法人活用 • 企業さまの要望をヒアリングし3D空間を制作 • 作った空間を「cluster」上にアップロード。空間を活用し て企業さまの課題を解決 • この事業のための3D空間制作チームがある
11. 11 事例：メタバースイオンでのマーケティング活用 • イオンリテールさまと一般ユーザーも参加できるメタバー スイオンを制作。若い世代にアプローチ • ECサイトで使えるクーポンを配布し、購買まで繋ぐ
12. 12 2事業それぞれの開発を別チームが行うことが特徴 • CtoC事業 ◦ サービス開発チームが「cluster」サービス自体を開発 • BtoB事業 ◦ 3D空間制作チームが「cluster」で動く3D空間を制作 QAチームが事業ごとに別の QAを行っていた
13. 13 2種類のQA • サービスリリースQA ◦ WHY：cluster自体に開発した機能が正しく動くか確認 ◦ WHEN：サービス開発チームがclusterの機能開発をリリースす る時（毎週） • コンテンツQA ◦ WHY：3D空間がcluster上で正しく動くか確認 ◦ WHEN：各案件ごとの納品前
14. 14 非常に手厚い QAで障害数は少ない しかし、課題も ...
15. 15 これまでの QAの課題
16. 16 2つの課題 1. サービスリリースQAでサービス開発チームのコード変 更〜リリースまでの期間が長い 2. サービスリリースQAとコンテンツQA両方が必要でQA チームの負荷が高い
17. 17 (1) QAでサービス開発チームのコード変更〜リリースま での期間が長い
18. 18 コード変更〜リリースが長い時の課題 • あるリリースでバグが発覚しても、修正リリースまで2週 間かかる • 作ったものを早くユーザーに届けられない ◦ ユーザー反応から素早く学びサービス改善に活かせない バグ修正
19. 19 (2) 2種類のQAが必要でQAチームの負荷が高い • 毎週のclusterリリース => 週1のサービスリリースQA • BtoB案件の同時進行 => 複数同時のコンテンツQA • 大量のQA作業が発生している
20. 20 QAとその周辺のフローを最適化し QA目的を達成しながら 2つの課題を解決したい！
21. 21 改善方針の決定
22. 22 改善後にどうありたいか 1. 品質をコントロールできている(QA目的の達成) ◦ 障害数が多少増えるのは許容。クリティカルな障害を防ぐ 2. コード変更〜リリースまでの期間は最短に 3. QAチームのQA作業負担を減らす
23. 23 方針
24. 24 開発チームにサービスリリース QAを引き継ぎ QAチームはコンテンツ QAへ集中する体制へ変 更していく
25. 25 サービスリリース QAフローの最適化の実施
26. 26 最終系のQAフローへ到達するために行ったこと 1. 事業のコア価値を理解して達成したい品質水準を決める 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たすQAフローを設 計する 4. QAメンバーと一緒に、regression QAのテストケースを 決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行し ていく
27. 27 最終系のQAフローへ到達するために行ったこと 1. 事業のコア価値を理解して達成したい品質水準を決め る 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たすQAフローを設 計する 4. QAメンバーと一緒に、regression QAのテストケースを 決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行し ていく
28. 28 なぜ事業のコア価値を理解しにいったか？ • 開発チームは今までの1週間の手厚いフローは引き継げ ない • 重要な部分のみ抽出したい。どうやって決めるか？ 事業やサービスのコア価値を理解し、 担保したい品質水準を決めるべき
29. 29 clusterでのコア価値 • 「ユーザーが作成した3D空間内で複数人が同期的に遊 べる」体験 ◦ サービス利用ユーザー・企業さま両方にとって重要 • たくさんの機能がある中で、ここだけは守りたい • 逆にここ以外は多少障害が起きても許容できる
30. 30 達成したい品質水準 = 3D空間内で複数人が同期的に遊べる 体験を担保できていること
31. 31 最終系のQAフローへ到達するために行ったこと 1. 事業のコア価値を理解して達成したい品質水準を決める 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たすQAフローを設 計する 4. QAメンバーと一緒に、regression QAのテストケースを 決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行し ていく
32. 32 なぜ制約条件を先に理解しにいったか？ • 開発フローを変更する時、変更しにくい部分を無理に変 えようとしても失敗する • 変更しやすい・変更しにくい部分を知ると、無理のない変 更を設計できる 関係各所にヒアリングして、 変更しにくい制約条件を先に理解する
33. 33 3つの制約条件を発見 • リリース日は月曜午前で固定すべき ◦ 理由: 企業さま案件の都合が最も良いのが月曜午前リリース • アプリ審査はiOSが最も遅く、大抵24時間以内だが、さら に長いことも • 開発チームのQAは、週に数時間程度が望ましい ◦ 理由: QAを増やしすぎると機能開発ができなくなってしまう
34. 34 達成したい品質水準と制約が分かった。 これを踏まえて新しいフローを設計する
35. 35 最終系のQAフローへ到達するために行ったこと 1. 事業のコア価値を理解して達成したい品質水準を決める 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たす QAフローを 設計する 4. QAメンバーと一緒に、regression QAのテストケースを 決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行し ていく
36. 36 品質水準と制約条件を踏まえて開発フローを設計 • 制約から逆算して設計していく
42. 42 コード変更〜リリースまで 6日を目指す
43. 43 目指すフローが決まったので 木曜regression QAの テストケースを調整したい
44. 44 最終系のQAフローへ到達するために行ったこと 1. 事業のコア価値を理解して達成したい品質水準を決める 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たすQAフローを設 計する 4. QAメンバーと一緒に、 regression QAのテストケース を決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行し ていく
45. 45 テストケース群の条件 • 「3D空間内で複数人が同期的に遊べる体験を担保でき ていること」の品質水準を満たす • 2時間程度で完了できる
46. 46 既存に詳しい QAメンバーと一緒に決める • 既存の充実したテストケース群から条件を満たすように ピックアップしたい • 既存テストケース一つ一つの目的に詳しいQAメンバーと 一緒に実施
47. 47 ひたすら地道な作業 ... 1. 複数人の同期的な体験のためのテストケースのみ選ぶ 2. さらに機能の利用頻度などを考慮し、重要度を付ける 3. 時間内に終わらせられる範囲で、重要度順にテストケース を選ぶ
48. 48 最終的に70個ほどのテストケースに
49. 49 目指すフローとテストケース群が決まった しかし引き継ぎと期間短縮を 一気に行うと混乱が起きる
50. 50 最終系のQAフローへ到達するために行ったこと 1. 事業のコア価値を理解して達成したい品質水準を決める 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たすQAフローを設 計する 4. QAメンバーと一緒に、regression QAのテストケースを 決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行 していく
51. 51 段階的な移行を行う • 一部ずつフロー変更していき、開発チームを徐々に新フ ローに慣れさせていく • 2ヶ月ほどの移行計画 ◦ (1) リリースまでの期間を変えず、regression QAのみ移行 ◦ (2) 期間は変えず、さらに新機能QAを移行 ◦ (3) 最後にコード変更〜リリースまでの期間を短縮
52. 52 0. 既存フロー
53. 53 1. regression QAのみ開発チームに移行
54. 54 2. 新機能QAを開発チームに移行
55. 55 3. コード変更〜リリースまでを短縮
56. 56 リリースQAを引き継ぎ、 6日でリリース可能に 🎉
57. 57 フロー変更後の結果
58. 58 フロー変更から 1年。結果はどうか？
59. 59 再掲: 達成したかったこと 1. 品質をコントロールできている ◦ サービスリリースQAを開発チームが行っても、3D空間内で複数 人が同期的に遊べる体験を担保 2. コード変更〜リリースまでの期間は最短に 3. QAチームのQA作業負担を減らす
60. 60 品質のコントロール • 2024年に発生した障害は25件 => 2025年に発生した 障害は15件 • サービス完全ダウン・重要機能が全く使えない状態は無 し 障害をコントロールできている
61. 61 コード変更〜リリースまでの期間 • 12日 => 6日へ • ある機能をリリースしたとき、バグ修正や改善を翌週にリ リースできるように バグ修正
62. 62 QAチームの負荷 • 開発チームにサービスリリースQAを完全に移行。週次 のQA負荷が無くなった • QAチームはコンテンツQAに集中できるように
63. 63 品質をコントロールしつつ、 2つの課題を解消できた 🎉
64. 64 振り返って何が成功要因だったのか？
65. 65 2つの成功要因 • 1と2のステップを入れたことに尽きる • QAで絶対担保すべきことを知るため、事業のコア価値を 理解したこと • スムーズな移行のため、フローで変更しやすい・しにくい ことを理解したこと 1. 事業のコア価値を理解して達成したい品質水準を決める 2. 開発フローの制約条件を理解する 3. 達成したい品質水準や制約条件を満たすQAフローを設計する 4. QAメンバーと一緒に、regression QAのテストケースを決め直す 5. 決定した最終形に向けて移行計画を作り、徐々に移行していく
66. 66 QA内容を決めるため、事業のコア価値を理解する • QAを考え始めると、どんな障害も防ぎたくなりがち ◦ そしてQAコストが肥大化していく • 先に絶対守りたいことを明確にし、それを守るQAにする ◦ QAを最適化したい時も新しく始めたい時も同じ • 絶対守りたいことは事業のコア価値の中にある QAフローを考える時、必ず事業理解から始める
67. 67 フローで変更しやすい・しにくいことを理解する • 開発フローを変えたい時、理想だけを考えてしまいがち • フローには慣性がある。変えづらいところを無理に変えると反 発が起こる フロー設計する前に必ず 変更しやすい・変更しにくい部分の理解から始める
68. 68 QAフローの改善・新設するときは、事 業コア価値とフローの制約条件の理解 から始めましょう
69. 69 まとめ
70. 70 まとめ • QAフローで障害を最小に抑えていた一方、リリースまで の期間の長さやQAチーム負荷に課題があった • 最適化していった結果、障害をコントロールしながら2つ の課題を解決できた • 振り返ると、事業コア価値とフローの制約条件の理解が 最も重要だった