Shadowverse流開発手法～QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発～

by Cygames, Inc.

Embed

Start on current slide

Slide 1

Slide 1 text

Shadowverse流開発手法 1/76 ～QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発～株式会社Cygames

Slide 2

Slide 2 text

Shadowverseでは膨大なカードの組合せによるQAコストが開発、運営をしていく中で大きな課題となった。その課題に対して、プランナー自身がカードの振る舞いをテストできる環境や、AIの調整、システムの堅牢性を担保するテストツールなどを駆使することにより大幅改善を実現した。本講演では、これらの実践方法と運用方法にShadowverse での実例を交えつつ解説する。 2/xx 本講演の主旨

Slide 3

Slide 3 text

柴田有輝 2015年度新卒として株式会社Cygamesに入社。エンジニアとして、リリース前からShadowverse の開発に携わる。現在はバトルパートのリーダーを担当、開発と運用を行いながらバトル開発全体の管理を行っている。 3/xx 自己紹介

Slide 4

Slide 4 text

4/xx 自己紹介鄒一舟（ソウイッシュウ）中国出身。2012年来日し、早稲田大学に修士入学。 2015年新卒として株式会社Cygamesに入社。 Shadowverseリリース前から UI、バトルロジックやAIなどの実装に携わる。現在はAIの設計と実装を担当している。

Slide 5

Slide 5 text

• ジャンル：デジタルTCG（Trading Card Game） • 2016年6月17日リリース • 運用4年目に突入 • 現在（9/5時点）までに2100万DLを突破 • ４プラットフォーム展開（GooglePlay、AppStore、DMM、Steam） 5/xx Shadowverseとは

Slide 6

Slide 6 text

6/xx Shadowverseにおけるリリースサイクル

Slide 7

Slide 7 text

Agenda 7/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ

Slide 8

Slide 8 text

Agenda 8/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ

Slide 9

Slide 9 text

9/xx Shadowverseの課題 … カードプール増加バグ増加テスト工数増加堅牢性の低下 QAコストの増加組み合わせ爆発

Slide 10

Slide 10 text

直近の1年間カードスキルの組み合わせ数(理論値)がカードパック更新ごとに平均18.5%増えている 10/xx Shadowverseの課題 0 200 400 600 800 1000 1200 Ver2.2.0 Ver2.3.0 Ver2.4.0 Ver2.5.0 スキル組み合わせ数 /万

Slide 11

Slide 11 text

11/xx QAコスト削減と堅牢性強化に我々が必要だったこと 1. 実装から既存機能を守る 2. 手戻りの発生しないことを保証 3. 組み合わせに対して網羅的なデバッグこれらを踏まえテスト駆動開発を提案

Slide 12

Slide 12 text

12/xx テスト駆動開発導入に当たっての問題点挙動的に非常に高い不確定性を持っており、機能の正確性と有効性を両方担保できるテストシナリオは作れないスキルの組み合わせ数が膨大すぎて、シンプルなテストシナリオでは堅牢性の担保をするには不十分で QAコストが右肩上がりに増えていく ■AI開発において ■スキル開発において

Slide 13

Slide 13 text

13/xx 問題点に対する解決方法 • AIの不確定性に対して、要件の細分化で良し悪しの判断をシンプルにし、テストシナリオを作りやすく。 • 回帰テストと網羅的自動デバッグを併用し、膨大なスキル組み合わせの堅牢性の担保とQAコストの削減を実現。 • ツール開発時にゲームの既存機能を流用し、ツールの開発コストおよび学習コストを抑える

Slide 14

Slide 14 text

Agenda 14/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ

Slide 15

Slide 15 text

AI開発におけるテスト駆動開発 15/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果

Slide 16

Slide 16 text

AI開発におけるテスト駆動開発 16/全ページ 2.1 テスト駆動開発を導入するための必要条件 • AIのテスト駆動開発フロー • 不確定性による影響と導入要件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果

Slide 17

Slide 17 text

17/xx AIにおけるテスト駆動開発フロー要件作成テストケース作成コーディング単体テスト回帰テスト AI調整デバッグ効果検証プランナー主導の仕様段階エンジニアによる実装段階プランナーによるバランシング段階

Slide 18

Slide 18 text

18/xx AIにおけるテスト駆動開発フロー要件作成テストケース作成コーディング単体テスト回帰テスト AI調整デバッグ効果検証プランナー主導の仕様段階エンジニアによる実装段階プランナーによるバランシング段階今回はプランナー主導の要件作成/テストケース作成について話します

Slide 19

Slide 19 text

AI開発におけるテスト駆動開発 19/全ページ 2.1 テスト駆動開発を導入するための必要条件 • AIのテスト駆動開発フロー • 不確定性による影響と導入要件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4得られた成果

Slide 20

Slide 20 text

20/xx AIの不確定性ゲームの不確定性 … 実戦では… AIの取るべき行動を定義しづらい対戦相手のデッキは不明カードドローはランダムランダム性の高いスキル

Slide 21

Slide 21 text

21/xx AIの不確定性によるテスト駆動開発の難点① プランナーがテストプレイし、主観で判断する自動的にテストを実行することはできない ■AIのプレイング優劣はどうやって判断する？

Slide 22

Slide 22 text

22/xx AIの不確定性によるテスト駆動開発の難点② ■開発中によく起きるエンジニアへの手戻りバグが発生した仕様通り動いたけど、やっぱり使えなかった 20%未満 80%超えエンジニアプランナー

Slide 23

Slide 23 text

23/xx AIの不確定性によるテスト駆動開発の難点② AIの不確定性により、カードの振る舞いに対して正確な仕様が作りづらい ■なぜテストプレイしないと「使えない」ことがわからない？仕様の信頼度低下

Slide 24

Slide 24 text

24/xx テスト駆動開発を導入するための必要条件 AIの不確定性自動的にテストを実行することはできない機能要件の有効性を保証挙動の正確性を機械的に判断仕様の信頼度低下テスト駆動開発を導入するための必要条件は…

Slide 25

Slide 25 text

AI開発におけるテスト駆動開発 25/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す • 要件細分化とその実例 • プランナーによるテストケース作成 2.3 テストケース作成ツール 2.4 得られた成果

Slide 26

Slide 26 text

プランナー 26/xx 問題を解決する「鍵」はプランナーにある人的判断仕様の信頼性判断する人は誰？仕様を考える人は誰？虎の首に鈴を付けた人がその虎から鈴をはずすことができる原因を作った人こそが、問題の解決に最も適任

Slide 27

Slide 27 text

27/xx AI開発においてのプランナーの重要性スケジュール管理 AI設計思想とデータ構造 TCGプランナーが担当新規カードの設計とバランス調整を担当する TCGゲームデザインに特化したプランナー

Slide 28

Slide 28 text

AI開発におけるテスト駆動開発 28/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す • 要件細分化とその実例 • プランナーによるテストケース作成 2.3 テストケース作成ツール 2.4 得られた成果

Slide 29

Slide 29 text

29/xx 不確定性を回避するための提案エンジニアでは、簡単な要素単位で実装して、その組み合わせをプランナーで調整できるようにしましょうか。プランナー一つ一つの思考要素は簡単だが、実戦では考える要素が多すぎて… 要件を細分化してロジックをシンプルにする

Slide 30

Slide 30 text

30/xx 要件細分化により不確定性の影響が収束される子要件A 子要件B 機能A 機能B 高度な戦術 … … 複雑な要件組み合わせ AIの不確定性に影響されるのは組み合わせ調整だけ実装&テストテストA テストB 任せて^_^ プランナー

Slide 31

Slide 31 text

31/xx 要件の細分化にはエンジニアリングの考え方が必要複雑な要件複雑なシステム細かい要件A 細かい要件B … コンポーネントA コンポーネントB … プランナーとエンジニアのさらなる連携が求められるエンジニアプランナー ≒

Slide 32

Slide 32 text

デモンストームお互いのリーダーとフォロワーすべてに３ダメージ。これはどういう意味なのか実際のゲーム画面をご覧ください 32/xx 要件細分化の実例：全体ダメージ能力

Slide 33

Slide 33 text

33/xx 要件細分化の実例：全体ダメージ能力フォロワーリーダーリーダー赤い盾：体力

Slide 34

Slide 34 text

34/xx 要件細分化の実例：全体ダメージ能力

Slide 35

Slide 35 text

35/xx 全体ダメージの運用要件相手を倒す味方フォロワーを生存させる相手のフォロワーを倒す相手リーダーの体力を削る味方を生存させる味方リーダーを守る

Slide 36

Slide 36 text

36/xx 全体ダメージにおいての「相手を倒す」要件の細分化相手を倒す相手リーダーの体力を削る相手のフォロワーを倒すなるべく多くの相手フォロワーにダメージ倒しきれない場合は自陣フォロワーを使う返り討ちを食らうかどうかを警戒 … なるべく大打点を出す自陣フォロワーをリーダーに攻撃 …

Slide 37

Slide 37 text

AI開発におけるテスト駆動開発 37/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す • 要件細分化とその実例 • プランナーによるテストケース作成 2.3 テストケース作成ツール 2.4 得られた成果

Slide 38

Slide 38 text

38/xx テストシナリオ設計の仕方プランナー自陣フォロワーをリーダーに攻撃この要件はどうのように定義する？テストシナリオは要件の元となる実戦ケースから生まれる

Slide 39

Slide 39 text

39/xx テストシナリオ①：自陣フォロワーをリーダーに攻撃相手を倒す相手リーダーの体力を削る相手のフォロワーを倒すなるべく多くの相手フォロワーにダメージ倒しきれない場合は自陣フォロワーを使う返り討ちを食らうかどうかを警戒 … なるべく大打点を出す自陣フォロワーをリーダーに攻撃 …

Slide 40

Slide 40 text

40/xx テストシナリオ①：自陣フォロワーをリーダーに攻撃相手のフォロワーは全体ダメージに任せる自陣フォロワーは相手リーダーの体力を削る

Slide 41

Slide 41 text

41/xx テストシナリオ①：自陣フォロワーをリーダーに攻撃

Slide 42

Slide 42 text

42/xx テストシナリオ②：倒しきれない場合は自陣フォロワーを使う相手を倒す相手リーダーの体力を削る相手のフォロワーを倒すなるべく多くの相手フォロワーにダメージ倒しきれない場合は自陣フォロワーを使う返り討ちを食らうかどうかを警戒 … なるべく大打点を出す自陣フォロワーをリーダーに攻撃 …

Slide 43

Slide 43 text

43/xx テストシナリオ②：倒しきれない場合は自陣フォロワーを使う全体ダメージだけで相手フォロワーを倒せない場合自陣フォロワーの攻撃も使うダメージ:3 体力: 4

Slide 44

Slide 44 text

44/xx テストシナリオ②：倒しきれない場合は自陣フォロワーを使う

Slide 45

Slide 45 text

45/xx テストシナリオをエンジニアに共有する手間図のように盤面を配置 AI場のファイターで敵場のデスドラゴンそれぞれに攻撃敵場のデスドラゴンが4/2になり AI場のファイターが破壊デモンストームをプレイ双方の場のフォロワーが全部破壊この資料の作成時間は… 30分！

Slide 46

Slide 46 text

46/xx テストシナリオをエンジニアに共有する手間見づらい疲れたテストシナリオ遷移図を作成 N

Slide 47

Slide 47 text

47/xx プランナーにテストケースを作ってもらうエンジニアがテストシナリオを設計するプランナーにテストケースを作ってもらうテストケース作成ツールを実装するテストシナリオ共有の手間をなくす方法テストシナリオの設計は要件作成と分離出来ないプログラミングが出来ない

Slide 48

Slide 48 text

AI開発におけるテスト駆動開発 48/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果

Slide 49

Slide 49 text

■機能 • テストケース登録 – 手動スタート盤面再現 – 手動行動再現 – スタート盤面と正解結果の保存 • テストケース再生 – スタート盤面再現 – AI思考呼び出し – 正解結果と比較し、差分があるならNG、一致するならOK 49/xx バトル機能を流用したツール「AITestKun」

Slide 50

Slide 50 text

50/xx テストケース登録

Slide 51

Slide 51 text

51/xx テストケース実行

Slide 52

Slide 52 text

52/xx AIのテストケースの判断において重要なのは「結果」のみ細かい行動の正解を定義する必要なしホワイトボックステストも必要なし

Slide 53

Slide 53 text

53/xx プランナー主導のテスト駆動開発まとめ要件細分化テストケース作成ツールエンジニアプランナーテストケース作成実装+テスト

Slide 54

Slide 54 text

AI開発におけるテスト駆動開発 54/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果

Slide 55

Slide 55 text

• AI開発の作業効率は約2倍に増加しスケジュール遅延の消滅 • AIのバグ報告数が約25%減少し、システム安定化 55/xx 得られた成果 0 10 20 30 40 50 60 70 80 90 2018年7月から年末 2019年初から6月末バグ報告数

Slide 56

Slide 56 text

56/xx 得られた成果プランナーとエンジニアの連携力向上エンジニアリング思想を取り入れた要件分析 TCG戦術に合わせたアルゴリズム設計開発チームの士気とスムーズなコミュニケーション

Slide 57

Slide 57 text

Agenda 57/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ

Slide 58

Slide 58 text

58/xx スキル開発におけるテスト駆動開発 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト 3.3 スキル開発で得られた成果

Slide 59

Slide 59 text

59/xx 3.1 スキルはどうやって動いているのか • スキルの仕組み 3.2 スキルの堅牢性を担保するテスト 3.3 スキル開発で得られた成果スキル開発におけるテスト駆動開発

Slide 60

Slide 60 text

スキルは以下のような構成で、独自のスクリプト言語で制御 60/xx スキルの仕組み Skill=メイン挙動の指定 Timing=発動タイミング Condition=発動条件 Target=発動対象 Option=ダメージ量などの細かい制御

Slide 61

Slide 61 text

冥府への道自分のターン終了時、自分の墓場が30枚以上なら、相手のリーダーと相手のフォロワーすべてに6ダメージ。これを分解すると 61/xx スキルの仕組み

Slide 62

Slide 62 text

冥府への道このように分解される 62/xx スキルの仕組み Skill=ダメージ Timing=自分のターン終了時 Condition=自分の墓場が30枚以上なら Target=相手のリーダーと相手のフォロワー全て Option=6

Slide 63

Slide 63 text

63/xx 発動時の実際のゲーム画面相手のリーダー相手のフォロワーすべてに6ダメージ墓場×30 ターン終了時

Slide 64

Slide 64 text

スキル開発はこれら５つの要素に対して新たな振る舞いを追加することで新規実装を行う 64/xx スキルの仕組みどのような形でスキルの堅牢性を担保しているのか？

Slide 65

Slide 65 text

65/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果スキル開発におけるテスト駆動開発

Slide 66

Slide 66 text

1. 単体テストスキル最小要素ごとの単体動作のテストシナリオを使用したテスト 2. 結合テストスキル最小要素を組み合わせた動作のテストシナリオを使用したテスト 3. 回帰テスト以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト 4. 自動テストカードを実際にプレイするAI同士が行うデバッグおよび網羅テスト 66/xx スキル開発におけるテスト

Slide 67

Slide 67 text

Slide 68

Slide 68 text

68/xx 単体テストテストシナリオ作成エンジニアが主導テストテストテストテストテスト Skill=メイン挙動の指定 Timing=発動タイミング Condition=発動条件 Target=発動対象 Option=ダメージ量などの細かい制御

Slide 69

Slide 69 text

Slide 70

Slide 70 text

70/xx 結合テストテストテストシナリオ作成エンジニアが主導 Skill=メイン挙動の指定 Timing=発動タイミング Condition=発動条件 Target=発動対象 Option=ダメージ量などの細かい制御

Slide 71

Slide 71 text

Slide 72

Slide 72 text

バグ報告の件数 72/xx 回帰テストを行わなければならない理由結合テスト（カード単体）＞複雑なカード組み合わせ複雑なカードの組み合わせ挙動を厚めにカバーしなければならない

Slide 73

Slide 73 text

73/xx テストシナリオの作成に関して問題が… プランナー複雑なカードの組み合わせの算出を正確かつ迅速にできるが、プログラミング知識がないエンジニア複雑なカードの組み合わせの算出を正確かつ迅速にできないテストシナリオ作成手段と正確性に問題

Slide 74

Slide 74 text

74/xx テストシナリオ作成、検証にあたっての要件複雑なカード組み合わせのバグ報告を減らしたい面倒なテストシナリオの作成手順は踏みたくない再開機能の流用を検討

Slide 75

Slide 75 text

75/xx 再開機能とは中断再開プレイログバージョンごとに変動をしないバージョンをまたいでも結果が不変なプレイログを生み出すことが可能

Slide 76

Slide 76 text

76/xx 再開機能を回帰テストツールに流用する利点プランナーエンジニアプログラミング知識無しでテストシナリオ作成が可能車輪の再発明回避再現性が非常に高い再開機能をもとに回帰テストツール開発を決断！

Slide 77

Slide 77 text

77/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果スキル開発におけるテスト駆動開発

Slide 78

Slide 78 text

78/xx 回帰テストツールで保証したいことプレイログプレイログバトルバトルバトル回帰テストバトル結果(プレイログ) = 回帰テスト結果新規実装、ソースコード改修、リファクタリングの結果以前と挙動（結果）が同じであることを保証する

Slide 79

Slide 79 text

79/xx 回帰テストツールに必要な追加情報追加情報をもとに挙動の差分チェックカードの位置情報カードパラメーターその他各カードがどの位置にあるかの情報カードのパラメーターの数値ターン数、リーダー別の状態等の情報アクション情報ユーザー任意のアクション情報(手順情報) 回帰テストツール用の追加情報

Slide 80

Slide 80 text

80/xx 追加情報の記載、チェックのタイミングスキルの発動A ユーザー任意のアクションスキルの発動B スキルの発動C ・・・各スキルの発動後情報の記載 or チェックアクション完了後情報の記載 or チェックアクション開始

Slide 81

Slide 81 text

81/xx なぜこんなに細かく行う必要があるのか？テストの過程を無視してテストを行うと結果の保証が得られなくなってしまうテストA テストB 過程A 過程B 希望通りの結果過程C 希望通りの結果ではない重要度低重要度高過程B

Slide 82

Slide 82 text

82/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果スキル開発におけるテスト駆動開発

Slide 83

Slide 83 text

83/xx 回帰テスト用のテストシナリオ作成の流れテストしたいカードの組み合わせをプレイプレイログを保存する

Slide 84

Slide 84 text

84/xx 回帰テスト用のテストシナリオの作成方法

Slide 85

Slide 85 text

チェックタイミングで記録時と差分がない 85/xx テスト実行時の正常パターン相手の場に体力1のカードが1体存在ダメージスキルを持っているカードをプレイ相手の場の体力1のカードに1のダメージを与える相手の盤面が空になるチェック

Slide 86

Slide 86 text

86/xx 正常パターンのイメージ

Slide 87

Slide 87 text

何らかの改修で記録時との差分が発生 87/xx テスト実行時の異常パターン相手の場に体力1のカードが1体存在ダメージスキルを持っているカードをプレイ相手の場の体力1のカードに0のダメージを与える相手の盤面が空にならない！チェック

Slide 88

Slide 88 text

88/xx 異常パターンのイメージ

Slide 89

Slide 89 text

89/xx 差分が発生！！！

Slide 90

Slide 90 text

90/xx エラー内容が出力される [スキル(damage)発動後] でエラー発生記録されていないカードが存在しています :フェアリー (場) 相手の場の体力1のカードに0のダメージを与える相手の盤面が空にならないチェック

Slide 91

Slide 91 text

チェックタイミングで記録した情報と差異がなければOK 91/xx 最終的に相手の場に体力1のフォロワーが1体存在ダメージスキルを持っているカードをプレイ相手の場の体力1のカードに1のダメージを与える相手の盤面が空になるチェック

Slide 92

Slide 92 text

• バージョンごとにフォルダ分けして管理 92/xx 回帰テストのテストシナリオの管理 recovery_single_0001.json

Slide 93

Slide 93 text

93/xx 回帰テストツールによりできた事と不安な事発覚済みの組み合わせバグの再発を防止とQAコストを削減未発覚バグは依然として人力で見つけるしかない人的コストをかけずに未発覚のバグを検知できないか…？

Slide 94

Slide 94 text

94/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果スキル開発におけるテスト駆動開発

Slide 95

Slide 95 text

Slide 96

Slide 96 text

1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 96/xx 網羅的自動デバッグ機能とは

Slide 97

Slide 97 text

1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 97/xx 網羅的自動デバッグ機能とは

Slide 98

Slide 98 text

98/xx モンキーテストシーン遷移やタッチ操作に不具合がないか網羅的に調査する

Slide 99

Slide 99 text

1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 99/xx 網羅的自動デバッグ機能とは

Slide 100

Slide 100 text

• 自動デッキ編成機能で作成したデッキを使用し、網羅性と偶発性の高いAI により膨大な組み合わせを自動でバトルする機能 ■規模 • 1バトル当たり5分 • 10:00~19:00まで動作 • 2端末で約108試合/日 • 約25セットで実行 = 約2700試合/日 100/xx 自動バトルデバッグ ①デッキ編成 ②マッチング ③バトル ④レポート実行サイクル

Slide 101

Slide 101 text

101/xx 自動バトルデバッグの様子

Slide 102

Slide 102 text

1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 102/xx 網羅的自動デバッグ機能とは

Slide 103

Slide 103 text

網羅的自動デバッグ機能の起動中に発生したエラーを社内SNSに自動投稿する機能 103/xx 社内SNSへの自動レポート送信機能

Slide 104

Slide 104 text

• ユーザー情報(ID等) • バージョン情報 • 接続先情報 • 端末情報(GPU、メモリ等) • カード情報（バトル時） • スタックトレース • スクリーンショット 104/xx 実際に社内SNSに投稿された内容

Slide 105

Slide 105 text

105/xx 高頻度でバグ報告されるカードバグ報告 NGカード登録自動デッキ編成自動バトルで使用不可バグ報告無駄な報告が減る

Slide 106

Slide 106 text

106/xx 網羅的自動デバッグ機能を使用することでチェックリストから漏れたバグの検知パフォーマンス検証も手軽に実施可能に回帰テストでカバーできていなかった未発覚バグの検知をカバー

Slide 107

Slide 107 text

107/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテストの種類 3.3 スキル開発で得られた成果スキル開発におけるテスト駆動開発

Slide 108

Slide 108 text

• バトル全体でのバグ報告が約40％減少 108/xx スキル開発で得られた成果 1.6.0 1.7.0 1.8.0 2.0.0 2.1.0 2.2.0 2.3.0 2.4.0 ２か月後１か月後大型アップデート 1.6.0以降から回帰テストツール動作開始

Slide 109

Slide 109 text

Agenda 109/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ

Slide 110

Slide 110 text

• カードの継続的増加により、対策としてテスト駆動開発の導入を考案した • AIの不確定性に対して、AI要件の細分化とプランナーによるテストケース作成を実現し、実装の有効性と正確性を担保 • 回帰テストツールと網羅的自動デバッグ機能を採用することで、 QAコストの削減と堅牢性の強化を実現 • 既存ゲーム機能を流用し、テストツール開発を低コストで実現 110/xx 全体のまとめ

Slide 111

Slide 111 text

Shadowverseは 10年以上続くタイトルを目指しています 111/xx

Slide 112

Slide 112 text

今回の手法で構築した高効率な開発基盤はその礎になります 112/xx

Slide 113

Slide 113 text

113/xx