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

2019/09/05 CEDEC 2019

Transcript

1. Shadowverse流開発手法 1/76 ～QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発～ 株式会社Cygames
2. Shadowverseでは膨大なカードの組合せによるQAコストが開発、 運営をしていく中で大きな課題となった。 その課題に対して、プランナー自身がカードの振る舞いをテスト できる環境や、AIの調整、システムの 堅牢性を担保するテストツールなどを駆使することにより 大幅改善を実現した。 本講演では、これらの実践方法と運用方法にShadowverse での実例を交えつつ解説する。 2/xx 本講演の主旨
3. 柴田 有輝 2015年度新卒として株式会社Cygamesに入社。 エンジニアとして、リリース前からShadowverse の開発に携わる。 現在はバトルパートのリーダーを担当、開発と 運用を行いながらバトル開発全体の管理を行って いる。 3/xx 自己紹介
4. 4/xx 自己紹介 鄒 一舟（ソウ イッシュウ） 中国出身。2012年来日し、早稲田大学に修士入学。 2015年新卒として株式会社Cygamesに入社。 Shadowverseリリース前から UI、バトルロジックやAIなどの実装に携わる。 現在はAIの設計と実装を担当している。
5. • ジャンル：デジタルTCG（Trading Card Game） • 2016年6月17日リリース • 運用4年目に突入 • 現在（9/5時点）までに2100万DLを突破 • ４プラットフォーム展開 （GooglePlay、AppStore、DMM、Steam） 5/xx Shadowverseとは
6. 6/xx Shadowverseにおけるリリースサイクル
7. Agenda 7/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ
8. Agenda 8/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ
9. 9/xx Shadowverseの課題 … カードプール増加 バグ増加 テスト工数増加 堅牢性の低下 QAコストの増加 組み合わせ 爆発
10. 直近の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 スキル組み合わせ数 /万
11. 11/xx QAコスト削減と堅牢性強化に我々が必要だったこと 1. 実装から既存機能を守る 2. 手戻りの発生しないことを保証 3. 組み合わせに対して網羅的なデバッグ これらを踏まえテスト駆動開発を提案
12. 12/xx テスト駆動開発導入に当たっての問題点 挙動的に非常に高い不確定性を持っており、機能の正確性と 有効性を両方担保できるテストシナリオは作れない スキルの組み合わせ数が膨大すぎて、 シンプルなテストシナリオでは堅牢性の担保をするには不十分で QAコストが右肩上がりに増えていく ▪AI開発において ▪スキル開発において
13. 13/xx 問題点に対する解決方法 • AIの不確定性に対して、要件の細分化で良し悪しの判断を シンプルにし、テストシナリオを作りやすく。 • 回帰テストと網羅的自動 デバッグを併用し、 膨大なスキル組み合わせの堅牢性の担保とQAコストの削減を実現。 • ツール開発時にゲームの既存機能を流用し、 ツールの開発コストおよび学習コストを抑える
14. Agenda 14/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ
15. AI開発におけるテスト駆動開発 15/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果
16. AI開発におけるテスト駆動開発 16/全ページ 2.1 テスト駆動開発を導入するための必要条件 • AIのテスト駆動開発フロー • 不確定性による影響と導入要件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果
17. 17/xx AIにおけるテスト駆動開発フロー 要件作成 テストケース作成 コーディング 単体テスト 回帰テスト AI調整 デバッグ 効果検証 プランナー主導の仕様段階 エンジニアによる実装段階 プランナーによるバランシング段階
18. 18/xx AIにおけるテスト駆動開発フロー 要件作成 テストケース作成 コーディング 単体テスト 回帰テスト AI調整 デバッグ 効果検証 プランナー主導の仕様段階 エンジニアによる実装段階 プランナーによるバランシング段階 今回はプランナー主導の要件作成/テストケース作 成について話します
19. AI開発におけるテスト駆動開発 19/全ページ 2.1 テスト駆動開発を導入するための必要条件 • AIのテスト駆動開発フロー • 不確定性による影響と導入要件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4得られた成果
20. 20/xx AIの不確定性 ゲームの不確定性 … 実戦では… AIの取るべき行動を 定義しづらい 対戦相手のデッキは不明 カードドローはランダム ランダム性の高いスキル
21. 21/xx AIの不確定性によるテスト駆動開発の難点① プランナーがテストプレイし、 主観で判断する 自動的にテストを実行することはできない ▪AIのプレイング優劣はどうやって判断する？
22. 22/xx AIの不確定性によるテスト駆動開発の難点② ▪開発中によく起きるエンジニアへの手戻り バグが発生した 仕様通り動いたけど、やっぱり使えなかった 20%未満 80%超え エンジニア プランナー
23. 23/xx AIの不確定性によるテスト駆動開発の難点② AIの不確定性により、カードの振る舞いに対して 正確な仕様が作りづらい ▪なぜテストプレイしないと「使えない」ことがわからない？ 仕様の信頼度低下
24. 24/xx テスト駆動開発を導入するための必要条件 AIの不確定性 自動的にテストを実行することはできない 機能要件の有効性を保証 挙動の正確性を機械的に判断 仕様の信頼度低下 テスト駆動開発を導入するための必要条件は…
25. AI開発におけるテスト駆動開発 25/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す • 要件細分化とその実例 • プランナーによるテストケース作成 2.3 テストケース作成ツール 2.4 得られた成果
26. プランナー 26/xx 問題を解決する「鍵」はプランナーにある 人的判断 仕様の信頼性 判断する人は誰？ 仕様を考える人は誰？ 虎の首に鈴を付けた人がその虎から鈴をはずすことができる 原因を作った人こそが、問題の解決に最も適任
27. 27/xx AI開発においてのプランナーの重要性 スケジュール 管理 AI設計思想 とデータ構造 TCGプラン ナーが担当 新規カードの設計と バランス調整を担当する TCGゲームデザインに 特化したプランナー
28. AI開発におけるテスト駆動開発 28/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す • 要件細分化とその実例 • プランナーによるテストケース作成 2.3 テストケース作成ツール 2.4 得られた成果
29. 29/xx 不確定性を回避するための提案 エンジニア では、簡単な要素単位で実装して、その組み合わ せをプランナーで調整できるようにしましょうか。 プランナー 一つ一つの思考要素は簡単だが、実戦では考える 要素が多すぎて… 要件を細分化してロジックをシンプルにする
30. 30/xx 要件細分化により不確定性の影響が収束される 子要件A 子要件B 機能A 機能B 高 度 な 戦 術 … … 複雑な要件 組 み 合 わ せ AIの不確定性に影響されるのは 組み合わせ調整だけ 実装&テスト テストA テストB 任せて^_^ プランナー
31. 31/xx 要件の細分化にはエンジニアリングの考え方が必要 複雑な要件 複雑なシステム 細かい要件A 細かい要件B … コンポーネントA コンポーネントB … プランナーとエンジニアの さらなる連携が求められる エンジニア プランナー ≒
32. デモンストーム お互いのリーダーとフォロワーすべてに３ダメージ。 これはどういう意味なのか 実際のゲーム画面をご覧ください 32/xx 要件細分化の実例：全体ダメージ能力
33. 33/xx 要件細分化の実例：全体ダメージ能力 フォロワー リーダー リーダー 赤い盾：体力
34. 34/xx 要件細分化の実例：全体ダメージ能力
35. 35/xx 全体ダメージの運用要件 相手を倒す 味方フォロワーを生存 させる 相手のフォロワーを 倒す 相手リーダーの体 力を削る 味方を生存 させる 味方リーダーを守る
36. 36/xx 全体ダメージにおいての「相手を倒す」要件の細分化 相手を倒す 相手リーダーの体力を削る 相手のフォロワーを倒す なるべく多くの相手フォロワーにダメージ 倒しきれない場合は自陣フォロワーを使う 返り討ちを食らうかどうかを警戒 … なるべく大打点を出す 自陣フォロワーをリーダーに攻撃 …
37. AI開発におけるテスト駆動開発 37/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す • 要件細分化とその実例 • プランナーによるテストケース作成 2.3 テストケース作成ツール 2.4 得られた成果
38. 38/xx テストシナリオ設計の仕方 プランナー 自陣フォロワーをリーダーに攻撃 この要件はどうのように定 義する？ テストシナリオは要件の元となる 実戦ケースから生まれる
39. 39/xx テストシナリオ①：自陣フォロワーをリーダーに攻撃 相手を倒す 相手リーダーの体力を削る 相手のフォロワーを倒す なるべく多くの相手フォロワーにダメージ 倒しきれない場合は自陣フォロワーを使う 返り討ちを食らうかどうかを警戒 … なるべく大打点を出す 自陣フォロワーをリーダーに攻撃 …
40. 40/xx テストシナリオ①：自陣フォロワーをリーダーに攻撃 相手のフォロワーは 全体ダメージに任せる 自陣フォロワーは 相手リーダーの体力を削る
41. 41/xx テストシナリオ①：自陣フォロワーをリーダーに攻撃
42. 42/xx テストシナリオ②：倒しきれない場合は自陣フォロワーを使う 相手を倒す 相手リーダーの体力を削る 相手のフォロワーを倒す なるべく多くの相手フォロワーにダメージ 倒しきれない場合は自陣フォロワーを使う 返り討ちを食らうかどうかを警戒 … なるべく大打点を出す 自陣フォロワーをリーダーに攻撃 …
43. 43/xx テストシナリオ②：倒しきれない場合は自陣フォロワーを使う 全体ダメージだけで相手フォ ロワーを倒せない場合 自陣フォロワーの攻撃も使う ダメージ:3 体力: 4
44. 44/xx テストシナリオ②：倒しきれない場合は自陣フォロワーを使う
45. 45/xx テストシナリオをエンジニアに共有する手間 図のように盤面を配置 AI場のファイターで敵場の デスドラゴンそれぞれに攻撃 敵場のデスドラゴンが4/2になり AI場のファイターが破壊 デモンストームをプレイ 双方の場のフォロワーが全部破壊 この資料の作成時間は… 30分 ！
46. 46/xx テストシナリオをエンジニアに共有する手間 見づらい 疲れた テストシナリオ遷移図を作成 N
47. 47/xx プランナーにテストケースを作ってもらう エンジニアがテストシナリオを 設計する プランナーにテストケースを 作ってもらう テストケース作成 ツールを実装する テストシナリオ共有の手間をなくす方法 テストシナリオの設計は 要件作成と分離出来ない プログラミングが出来ない
48. AI開発におけるテスト駆動開発 48/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果
49. ▪機能 • テストケース登録 – 手動スタート盤面再現 – 手動行動再現 – スタート盤面と正解結果の保存 • テストケース再生 – スタート盤面再現 – AI思考呼び出し – 正解結果と比較し、差分がある ならNG、一致するならOK 49/xx バトル機能を流用したツール「AITestKun」
50. 50/xx テストケース登録
51. 51/xx テストケース実行
52. 52/xx AIのテストケースの判断において重要なのは「結果」のみ 細かい行動の正解を定義する必要なし ホワイトボックステストも必要なし
53. 53/xx プランナー主導のテスト駆動開発まとめ 要件細分化 テストケース 作成ツール エンジニア プランナー テストケース作成 実装+テスト
54. AI開発におけるテスト駆動開発 54/全ページ 2.1 テスト駆動開発を導入するための必要条件 2.2 テスト駆動開発の主導権をプランナーに渡す 2.3 テストケース作成ツール 2.4 得られた成果
55. • AI開発の作業効率は約2倍に増加しスケジュール遅延の消滅 • AIのバグ報告数が約25%減少し、システム安定化 55/xx 得られた成果 0 10 20 30 40 50 60 70 80 90 2018年7月から年末 2019年初から6月末 バグ報告数
56. 56/xx 得られた成果 プランナーとエンジニア の連携力向上 エンジニアリング思想を 取り入れた要件分析 TCG戦術に合わせた アルゴリズム設計 開発チームの士気と スムーズなコミュニケーション
57. Agenda 57/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ
58. 58/xx スキル開発におけるテスト駆動開発 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト 3.3 スキル開発で得られた成果
59. 59/xx 3.1 スキルはどうやって動いているのか • スキルの仕組み 3.2 スキルの堅牢性を担保するテスト 3.3 スキル開発で得られた成果 スキル開発におけるテスト駆動開発
60. スキルは以下のような構成で、独自のスクリプト言語で制御 60/xx スキルの仕組み Skill=メイン挙動の指定 Timing=発動タイミング Condition=発動条件 Target=発動対象 Option=ダメージ量などの細かい制御
61. 冥府への道 自分のターン終了時、自分の墓場が30枚以上なら、 相手のリーダーと相手のフォロワー すべてに6ダメージ。 これを分解すると 61/xx スキルの仕組み
62. 冥府への道 このように分解される 62/xx スキルの仕組み Skill=ダメージ Timing=自分のターン終了時 Condition=自分の墓場が30枚以上なら Target=相手のリーダーと相手のフォロワー全て Option=6
63. 63/xx 発動時の実際のゲーム画面 相手のリーダー 相手のフォロワー すべてに6ダメージ 墓場×30 ターン 終了時
64. スキル開発はこれら５つの要素に対して 新たな振る舞いを追加することで新規実装を行う 64/xx スキルの仕組み どのような形でスキルの堅牢性を 担保しているのか？
65. 65/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果 スキル開発におけるテスト駆動開発
66. 1. 単体テスト スキル最小要素ごとの単体動作のテストシナリオを使用したテスト 2. 結合テスト スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト 3. 回帰テスト 以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト 4. 自動テスト カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト 66/xx スキル開発におけるテスト
67. 1. 単体テスト スキル最小要素ごとの単体動作のテストシナリオを使用したテスト 2. 結合テスト スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト 3. 回帰テスト 以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト 4. 自動テスト カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト 67/xx 単体テスト
68. 68/xx 単体テスト テストシナリオ作成 エンジニアが主導 テスト テスト テスト テスト テスト Skill=メイン挙動の指定 Timing=発動タイミング Condition=発動条件 Target=発動対象 Option=ダメージ量などの細かい制御
69. 1. 単体テスト スキル最小要素ごとの単体動作のテストシナリオを使用したテスト 2. 結合テスト スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト 3. 回帰テスト 以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト 4. 自動テスト カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト 69/xx 結合テスト
70. 70/xx 結合テスト テスト テストシナリオ作成 エンジニアが主導 Skill=メイン挙動の指定 Timing=発動タイミング Condition=発動条件 Target=発動対象 Option=ダメージ量などの細かい制御
71. 1. 単体テスト スキル最小要素ごとの単体動作のテストシナリオを使用したテスト 2. 結合テスト スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト 3. 回帰テスト 以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト 4. 自動テスト カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト 71/xx 回帰テスト
72. バグ報告の件数 72/xx 回帰テストを行わなければならない理由 結合テスト （カード単体） ＞ 複雑なカード 組み合わせ 複雑なカードの組み合わせ挙動を 厚めにカバーしなければならない
73. 73/xx テストシナリオの作成に関して問題が… プランナー 複雑なカードの組み合わせの算出を正確かつ迅速に できるが、プログラミング知識がない エンジニア 複雑なカードの組み合わせの算出を正確かつ迅速にできない テストシナリオ作成手段と正確性に問題
74. 74/xx テストシナリオ作成、検証にあたっての要件 複雑なカード組み合わせの バグ報告を減らしたい 面倒なテストシナリオの作成 手順は踏みたくない 再開機能の流用を検討
75. 75/xx 再開機能とは 中断 再開 プレイログ バージョンごとに 変動をしない バージョンをまたいでも結果が不変な プレイログを生み出すことが可能
76. 76/xx 再開機能を回帰テストツールに流用する利点 プランナー エンジニア プログラミング知識無しで テストシナリオ作成が可能 車輪の再発明回避 再現性が非常に高い 再開機能をもとに 回帰テストツール開発を決断！
77. 77/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果 スキル開発におけるテスト駆動開発
78. 78/xx 回帰テストツールで保証したいこと プレイログ プレイログ バトル バトル バトル 回帰テスト バトル結果(プレイログ) = 回帰テスト結果 新規実装、ソースコード改修、リファクタリングの結果 以前と挙動（結果）が同じであることを保証する
79. 79/xx 回帰テストツールに必要な追加情報 追加情報をもとに挙動の差分チェック カードの位置情報 カードパラメーター その他 各カードがどの位置にあるかの情報 カードのパラメーターの数値 ターン数、リーダー別の状態等の情報 アクション情報 ユーザー任意のアクション情報(手順情報) 回帰テストツール用の追加情報
80. 80/xx 追加情報の記載、チェックのタイミング スキルの発動A ユーザー任意のアクション スキルの発動B スキルの発動C ・ ・ ・ 各スキルの発動後 情報の記載 or チェック アクション完了後 情報の記載 or チェック アクション開始
81. 81/xx なぜこんなに細かく行う必要があるのか？ テストの過程を無視してテストを行うと 結果の保証が得られなくなってしまう テストA テストB 過程A 過程B 希望通りの結果 過程C 希望通りの結果 ではない 重要度低 重要度高 過程B
82. 82/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果 スキル開発におけるテスト駆動開発
83. 83/xx 回帰テスト用のテストシナリオ作成の流れ テストしたいカードの組み合わせをプレイ プレイログを保存する
84. 84/xx 回帰テスト用のテストシナリオの作成方法
85. チェックタイミングで記録時と差分がない 85/xx テスト実行時の正常パターン 相手の場に体力1のカードが1体存在 ダメージスキルを持っているカードをプレイ 相手の場の体力1のカードに1のダメージを与える 相手の盤面が空になる チェック
86. 86/xx 正常パターンのイメージ
87. 何らかの改修で記録時との差分が発生 87/xx テスト実行時の異常パターン 相手の場に体力1のカードが1体存在 ダメージスキルを持っているカードをプレイ 相手の場の体力1のカードに0のダメージを与える 相手の盤面が空にならない！ チェック
88. 88/xx 異常パターンのイメージ
89. 89/xx 差分が発生！！！
90. 90/xx エラー内容が出力される [スキル(damage)発動後] でエラー発生 記録されていないカードが存在しています :フェアリー (場) 相手の場の体力1のカードに0のダメージを与える 相手の盤面が空にならない チェック
91. チェックタイミングで記録した情報と 差異がなければOK 91/xx 最終的に 相手の場に体力1のフォロワーが1体存在 ダメージスキルを持っているカードをプレイ 相手の場の体力1のカードに1のダメージを与える 相手の盤面が空になる チェック
92. • バージョンごとにフォルダ分けして管理 92/xx 回帰テストのテストシナリオの管理 recovery_single_0001.json
93. 93/xx 回帰テストツールによりできた事と不安な事 発覚済みの組み合わせバグの 再発を防止とQAコストを削減 未発覚バグは依然として人力で 見つけるしかない 人的コストをかけずに 未発覚のバグを検知できないか…？
94. 94/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテスト • 回帰テストツール • テストシナリオ作成からテスト実行までの流れ • 網羅的自動デバッグ機能 3.3 スキル開発で得られた成果 スキル開発におけるテスト駆動開発
95. 1. 単体テスト スキル最小要素ごとの単体動作のテストシナリオを使用したテスト 2. 結合テスト スキル最小要素を組み合わせた動作のテストシナリオを使用したテスト 3. 回帰テスト 以前に問題のあったカード組み合わせのテストシナリオを複数使用したテスト 4. 自動テスト カードを実際にプレイするAI同士が行うデバッグおよび網羅テスト 95/xx 自動テスト
96. 1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 96/xx 網羅的自動デバッグ機能とは
97. 1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 97/xx 網羅的自動デバッグ機能とは
98. 98/xx モンキーテスト シーン遷移やタッチ操作に不具合がないか網羅的に調査する
99. 1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 99/xx 網羅的自動デバッグ機能とは
100. • 自動デッキ編成機能で作成したデッキを使用し、網羅性と偶発性の高いAI により膨大な組み合わせを自動でバトルする機能 ▪規模 • 1バトル当たり5分 • 10:00~19:00まで動作 • 2端末で約108試合/日 • 約25セットで実行 = 約2700試合/日 100/xx 自動バトルデバッグ ①デッキ編成 ②マッチング ③バトル ④レポート 実行サイクル
101. 101/xx 自動バトルデバッグの様子
102. 1. モンキーテスト (無差別、対象指定タップデバッグ) 2. 自動デッキ編成機能 3. AI同士の自動バトルデバッグ機能 4. 社内SNSへの自動レポート送信機能 102/xx 網羅的自動デバッグ機能とは
103. 網羅的自動デバッグ機能の起動中に発生した エラーを社内SNSに 自動投稿する機能 103/xx 社内SNSへの自動レポート送信機能
104. • ユーザー情報(ID等) • バージョン情報 • 接続先情報 • 端末情報(GPU、メモリ等) • カード情報（バトル時） • スタックトレース • スクリーンショット 104/xx 実際に社内SNSに投稿された内容
105. 105/xx 高頻度でバグ報告されるカード バグ報告 NGカード登録 自動デッキ編成 自動バトルで使用不可 バグ報告 無駄な報告が減る
106. 106/xx 網羅的自動デバッグ機能を使用することで チェックリストから漏れたバグの 検知 パフォーマンス検証も 手軽に実施可能に 回帰テストでカバーできていなかった 未発覚バグの検知をカバー
107. 107/xx 3.1 スキルはどうやって動いているのか 3.2 スキルの堅牢性を担保するテストの種類 3.3 スキル開発で得られた成果 スキル開発におけるテスト駆動開発
108. • バトル全体でのバグ報告が約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以降から 回帰テストツール 動作開始
109. Agenda 109/全ページ 1. Shadowverseの課題と解消手段 2. AI開発におけるテスト駆動開発 3. スキル開発におけるテスト駆動開発 4. 全体のまとめ
110. • カードの継続的増加により、対策としてテスト駆動開発の 導入を考案した • AIの不確定性に対して、AI要件の細分化とプランナーによるテス トケース作成を実現し、実装の有効性と正確性を担保 • 回帰テストツールと網羅的自動デバッグ機能を採用することで、 QAコストの削減と堅牢性の強化を実現 • 既存ゲーム機能を流用し、テストツール開発を低コストで実現 110/xx 全体のまとめ
111. Shadowverseは 10年以上続くタイトルを 目指しています 111/xx
112. 今回の手法で構築した 高効率な開発基盤は その礎になります 112/xx
113. 113/xx