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