NativeGameの障害削減に向けた取り組み

GREE Tech Conference 2020 で発表された資料です。
https://techcon.gree.jp/2020/session/ShortSession-6

Transcript

1. グリー株式会社　WFQAチーム　マネージャー　野本雅俊
 NativeGameの障害削減に
 向けた取り組み
 グリー株式会社　WFQAチーム　　　　　　　　奥泉卓也

2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 氏名と所属
 野本　雅俊
 (のもと　まさとし)
 Customer & Product Satisfaction部 
 WFQAチーム　マネージャー 
 主な業務内容
 NativeゲームのQAマネージャー 
 WFSタイトル全般のQA統括 
 各メンバーのマネジメント 
 略歴
 SIerでエンジニアを経験後、NTTひかり電話関連シ ステムのQA担当を経て、2012年グリーに入社 
 GREE PFのQA担当後、NativeゲームのQAへ異動。 複数タイトルの国内外リリースを成功させ、2018年 からマネージャーとなる。 
 氏名と所属
 奥泉　卓也
 (おくいずみ　たくや) 
 Customer & Product Satisfaction部 
 WFQAチーム
 主な業務内容
 Nativeゲーム（WFSタイトル）のQA担当 
 横断的な障害削減
 略歴
 SIerでインフラエンジニアとしての業務を経て、2018 年グリーに入社。
 当初は移管タイトルのQA立ち上げを担当し、2019年 から自社開発Nativeゲーム 
 （WFSタイトル）のQAを担当。 

3. Copyright © GREE, Inc. All Rights Reserved. 1. 背景
 2. 障害削減の取り組み
 a. 集計方法の統一
 b. 分析軸の策定
 c. 再発防止の実施
 3. 実施効果
 4. まとめ

4. Copyright © GREE, Inc. All Rights Reserved. • NativeGameにおいてリリース後障害が増加傾向にあった
 • 障害集計/分析を開始したがルール統一はしていなかった
 • 再発防止など対策を行っていたが障害数の削減には至らず
 
 
 
 １．背景
 
 先行運用していたQAチームで障害分析による削減事例があり踏襲 し推進することを決定

5. Copyright © GREE, Inc. All Rights Reserved. ２．障害削減の取り組み
 
 
 グリーのNativeゲームQAで進めた障害削減の流れ
 c.再発防止の実施
 a.集計方法の統一
 b.分析軸の策定
 上記の流れに沿って障害削減を推進

6. Copyright © GREE, Inc. All Rights Reserved. a.集計方法の統一
 
 
 
 全件BTS管理
 タイトルA
 スプレッドシート全 件記録
 タイトルB
 社内wiki
 重大なもののみ
 タイトルC
 JIRA
 問い合わせを起票
 タイトルD
 JIRA
 重大なもののみ
 過去の障害集計方法
 改善後の障害集計方法

7. Copyright © GREE, Inc. All Rights Reserved. a.集計方法の統一
 
 • 全タイトル共通の基準として「重大度」を設定
 
 • S：返金のリスクがある不具合、大規模な進行不能/データロスト
 • A：広範囲/イベント報酬関連の不具合、IPを傷つける恐れがある不具合
 • B：条件や範囲が限定的な不具合
 • C：回避手段がある/軽微な不具合
 • D：プレイに影響のない不備・改善余地
 
 ※Cランク以上を削減対象として設定
 今までの記載基準
 改善後の障害集計基準

8. Copyright © GREE, Inc. All Rights Reserved. a.集計方法の統一
 
 記載する情報をルール化
 • 見逃し原因
 • 概要
 • 重大度
 • 補填
 • 対策
 タイトルA
 問い合わせ内容
 影響度
 タイトルB
 概要
 対応
 補填有無
 タイトルC
 概要
 詳細
 今後の対策
 タイトルD
 概要
 対策
 補填有無
 過去の情報記載粒度
 改善後の情報記載粒度

9. Copyright © GREE, Inc. All Rights Reserved. b.分析軸の策定
 
 障害件数 集計
 共通原因
 障害の内容はタイトルごとに様々だが、
 見逃し原因はどのタイトルも同様に分析・対策できる
 内容A
 タイトル1
 タイトル2
 タイトル3
 内容B
 内容C
 見逃し原因を分析の軸として設定
 原因ごとの再発防止策をナレッジとして蓄積
 共通の分析軸を検討

10. Copyright © GREE, Inc. All Rights Reserved. c.再発防止の実施
 QA責障害
 QA起因の障害
 
 テスト実施漏れ
 テスト設計漏れ
 開発責障害
 開発起因の障害
 QA未依頼
 QA後修正
 テスト範囲外
 グレー障害
 開発、QA双方で考 慮が難しい不具合
 テスト
 範囲外
 （暗黙的）
 外部要因障害
 テストでの検知が 難しい障害
 端末依存
 環境依存
 原因別に効果的なアプローチを検討する
 各障害見逃し原因の概要

11. Copyright © GREE, Inc. All Rights Reserved. ヒューマンエラーであるという点に着目
 …システム的に再発を防ぐ方法を検討
 
 • 特に効果的なのが「データ上の不具合」
 ◦ 開発への事前の入力値チェックの提案
 ◦ マスタデータの可読化
 ◦ マスタと仕様の自動比較(データ検証)
 
 c.再発防止の実施
 目視チェック
 テスターの技量やコンディ ションによって見落としの可 能性が生じる
 データ検証
 テスターの技量やコンディ ションに左右されづらく、見落 としリスクが低い
 テスト実施漏れ

12. Copyright © GREE, Inc. All Rights Reserved. c.再発防止の実施
 ナレッジの蓄積で再発防止を図る
 
 タイトル内で
 振り返り
 他タイトルで
 ナレッジ活用
 設計観点の追加
 横断レビュー
 横断的な
 設計観点の追加
 例：
 • ランイベ用キャラ
 ◦ 実戦に近い状態での実機 テストを実施
 • 特殊スキル
 ◦ 比例・反比例による性能 変化等の境界値分析テス トを実施
 • 既存の取り組み
 テスト設計漏れ

13. Copyright © GREE, Inc. All Rights Reserved. • 取り組みを行い、障害削減に成功
 　
 　 QA責障害
 　 半期で35%削減
 
 • 全体の障害件数も13%削減
 • 今後も取り組みを発展させて継続
 ３．実施効果

14. Copyright © GREE, Inc. All Rights Reserved. • BTS化や指標の共通化を行うことは工数面でもメリットがあった
 • 共通指標を使うことでタイトルごと横並びで分析できるようになった
 • QA責障害の可視化によりナレッジ蓄積が行え、再発防止を強化できた
 • 結果としてQA責の障害数を35%削減することに成功
 
 
 ４．まとめ
 導入は面倒だし効果に疑問もあるかと思いますが、
 障害が減らないことに悩んでいるチームはぜひやってみてください！
 
 

16. Copyright © GREE, Inc. All Rights Reserved. b.分析軸の策定
 タイトル名
 S
 A
 B
 C
 Aプロジェクト
 1
 2
 8
 11
 Bプロジェクト
 0
 2
 4
 6
 ・・・
 
 
 
 
 タイトル名
 テスト実施漏れ
 テスト設計漏れ
 テスト範囲外
 ・・・
 Aプロジェクト
 0
 1
 6
 
 Bプロジェクト
 1
 0
 8
 
 ・・・
 
 
 
 
 集計した情報をもとに現状把握
 • 週次で状況共有を実施
 • 発生状況や見逃し原因、作りこみ 原因、重大度を確認
 
 分析を効率化できる軸を検討
 現状の把握…タイトル横並びで情報を集計
 
 

17. Copyright © GREE, Inc. All Rights Reserved. c.再発防止の実施
 テスト範囲外
 （暗黙的）
 ピンポイントでの対策にしない
 …単体の事象をもとに、アプリの構造を深堀していく
 例：武器に新レアリティ追加の結果、特定クエストが進行不能
 • 特定クエストでキャラが装備している武器のレアリティを参照するロジック 
 • 該当クエスト側に新レアリティに対応する実装がないのが原因 
 • 武器追加時に今回障害が発生したクエストを進行して問題がないことを見る 
 ピンポイントの対策
 • 他に関連付けが難しいテーブルを参照しているクエストがないか精査し、観点追加 
 望ましい対策
 見逃し原因ごとの傾向を探る：グレー