7
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

CEDEC 2014 - デベロッパーにQAは必要か? 開発スケジュール短縮のための真・QA論

Last updated at Posted at 2015-03-26

CEDEC 2014 開催から半年ほど経過してしまいましたが
せっかくなので当時のレポートを公開しておこうと思います

概要

サイバーコネクトツーが社内に設立したQA(品質保証)チームの事例を基に、
開発スケジュールを短縮し、コスト削減を図るためのノウハウを共有いたします。

・本当にQAチームは必要か?(QAのメリット)
・どれぐらい効率は上がるのか?
・QAチームをアサインすべきベストタイミングとは?
・社内QAとデバッグ外注の使い分け事例など

本講演における言語定義

  • デバッグ

    • バグチェックと同義
    • バグを修正するという意味ではない
  • QA

    • 品質保証
    • デバッグは重要な業務の一つ

今回の講演に置いて事例としての説得力を増すためにガンバリオンも協力とのこと

歴史

これまではβ版作成からマスター作成までのバグチェックの担当を
アルバイトやデバッグ会社に任せることで効率化を図っていた

  • メリット

    • デバッグコスト削減
    • クリエイターの稼働率アップ
  • デメリット

    • 管理負担増
    • ノウハウが蓄積されない
  • なので…

    • 効率を上げるためにデバッグの管理を専任化したい
    • 成立させるための説得力の高い方針を打ち立てる

社内QAチームを立ち上げるにあたって

方針

  • 人員コストを120%消費できるよう仕事を積む努力をする
  • 社内組織だからこそできる事がある

心構え

  • 開発の一員であるという意識
  • 開発の最後の砦であるという意識
  サーバーコネクトツー ガンバリオン
時期 2010年 2013年
社員数 170名 80名
ライン数 2(コンシューマー) 2(コンシューマー)
経緯 デバッグアルバイトから2名契約社員に プランナーの一人を専任化+専任のアルバイト1名

従来のバグチェック手法のデメリット

  • プロジェクトごとに新しいバグチェックの手法が必要になるため、常に新たな教育が必要

  • リードPGが中心にいつつも完全にコントロールできておらず情報が分散してしまう

  • つまり、リードプログラマーが管理すると

    • プロジェクト間でその都度相談して人員を融通し合う
    • バグチェッカーの採用教育コストがかかる
    • 柔軟な人員配置が難しい

デバッグの専任化メリット

  • バグチェッカーの教育コストが低減する

  • QAが独立することで、QAチームにノウハウがたまる

  • プロジェクトに依存しないバグチェッカーを長く確保できるように

  • 窓口をQAチームに集中できる

  • つまり社内QAチームでバグチェッカーを一括管理すると

    • 各プロジェクトのバランスを取りやすい
    • フレキシブルな人員配置が可能
  • まとめると…

    • ノウハウの蓄積が可能
    • バグの傾向の分析が可能
    • 過去事例の蓄積と啓蒙が可能
    • バグの減少、コストの減少が可能

社内QAチームの業務内容

  • 仕事を積む努力・社内のQAチームだからこそできること

バグチェック

  • 省略

ローカライズの窓口

  • クライアント様とのやり取りまで対応
  • 翻訳資料の更新状況確認など
    • ローカライズに関してもQAが専任の窓口になる事でやり取りの質が向上し結果品質アップ

機材管理

  • 開発偉材の管理や設定作業
    • デバッガ用の機材のセットアップ
    • 棚卸しを手伝う事も

宣伝広報への協力

  • PV素材の撮影
  • QAに録画機材を配置する事で全プロジェクトの対応が可能
    • 各種イベントのデータ作成・運営手伝い
    • タイトルのPRに大きく貢献

開発アシスタント業務

  • デモ作成アシスタント3ヶ月間 スクリプトでデモ作成
  • パブ作業アシスタント4ヶ月間 立ち絵のレタッチ作業
  • GDアシスタント3ヶ月間 スマホプロジェクトのパラメータ調整
    • アシスタント業務でのデータ構成の知識などが
    • デバッグや次のプロジェクトの業務に生かされる

他タイトル動画撮影

  • 他社様のタイトルをガイドラインにどう対応しているか撮影し、動画をライブラリ化
    • LANケーブルを抜いたときのメッセージ
    • インストール容量不足のメッセージ
    • プログラマーの手間を削減

バグ撲滅委員会

  • 過去のタイトルからどのような問題が発生したかを共有する事で
  • 未然にバグを防ぎ、開発効率を上げるための資料作成を行う
  • メンバー:プログラマ、サウンドプログラマ、QA、ゲームデザイナー

作っている資料

  • デバッグ依頼ガイドライン
  • 必要なデバッグ機能
  • バグ事例一覧
  • バグ報告と修正確認手順
  • デバッグのコツ
  • 社内ガイドライン

デバッグ依頼ガイドライン

  • デバッグ資料はデバッガーがデバッグをするために必ず必要な資料です
  • デバッグに入る前に、資料を作成・整理する期間をスケジュールに組み込むように心がけてください

実装必須・推奨デバッグ機能

  • イベントメッセージを自動送りにするとか
  • 消費アイテム、重要アイテム、コレクションアイテムを追加するとか
  • イベント戦闘をスキップするとか
  • イベント戦闘開始直後に強制クリアするとか
  • ムービーをスキップするとか

社内モニター会

  • マイルストーンごとにモニター会を実施
  • QAがモニターの日程調整などを行う
  • ディレクターの手間を削減

挑戦

ガイドライン違反ゼロへの挑戦

  • マスター直前に違反が見つかる状況を改善したい
  • そもそもガイドライン違反の発生件数を減らせないか?
    • 本開発開始前にQAのチェックリストを開発者に渡す
    • 違反しない実装をしてもらう
    • その後も各マイルストーンごとに継続的に告知する

チェック漏れゼロへの挑戦

  • デバッグ後半にデバッグ経験者の能力に頼らざるを得ない状況を改善したい
  • 個人スキルに左右されないチェック体制を作れないか
    • 仕様書だけではなく、実装担当のPG、GDから直接話を聞きながら精度の高いチェックリストを作成
    • 経験が無くても漏れの無いチェックができるようにする

ユーザーの不満を限りなくゼロに近づける

  • マスターアップには影響しないが、不便と感じる部分を減らしたい
  • 例:アイテムの一括売却が無いままリリース、結果、不便との声が上がる
    • β版後の実装変更は難しい
    • α版前のチーム無いチェック段階でQAも参加し不便になりそうな部分を指摘して改善してもらう

ソーシャルプロジェクト事例紹介

QAチームの役割

  • 関係各社と直接連絡を取りつつデバッグやメンテナンス・ユーザーサポートを行う
  • チャットツールを使う
  • 内容に応じて各担当者にRedmineで割り振りを行う
  • 多い日は20件以上のエスカレーションに対応
    • サポートのノウハウが蓄積
    • 不具合が起きやすい端末がわかるようになる

デバッグ関連

  • 最新ver.のビルドの確認

メンテナンス関連

  • 本番環境チェック、新イベントチェック、アプリ内のWebチェック etc
    • 本番環境のDB操作
    • トラブル時は補填内容の提案
      情報収集、ユーザー問い合わせ・某掲示板・Lobi・Twitter 等
    • Webチェックは特に重要、表示内容が間違っていると補填の対象になってしまう
    • また、イベントの内容が固まったあとに作成するのでチェック期間が短い

その他

  • 毎日スマホプロジェクト売り上げ確認

開発フェーズと運営フェーズ

スマホとコンシューマーのデバッグ方法の違い

デバッグ前半

  • デバッグ内容はコンシューマーとほぼ変わらない
  • 端末ごとの挙動チェックが違う

デバッグ後半

  • 通信がつながってから短期集中(3から6週間)で通信込みの全般駅なチェックを行う

失敗談

  • 通信が入ると挙動が別物になり、チェックをすべてやり直した

運営開始後の体制

イベントチェックは社内

  • スピード重視
  • イベントの実装が配信前日18:00以降になってもチェック可能
  • メンテナンス当日のイベント変更対応なども担当者に直接確認できる
  • 軽度な作業でレスポンスが大切な作業を振りやすい

バージョンアップチェックは外部

  • バグが無い事を重視
  • 人数の増減が可能なため、バージョンアップの時期に集中チェックを行いやすい

端末について

端末購入数について

  • 開発、デバッグに必要な数は購入した(一人一台)
  • SIMは2端末のみ契約→課金チェックで重宝

端末の選別の仕方

  • 基本はシェア率
  • 不具合を起こしやすい端末を購入
  • CPU、GPUの異なる機種を選択

端末の管理

  • 社内の端末はQAが一元管理
  • 社内で約80端末所持(開発用込み)

プロジェクトから購入希望を提出

  • QAが社内にある端末を確認して適正を判断

データベースで一元管理

リリース前の対応端末チェック

  • デベロッパーで前端末購入する事は非効率
  • 外部のデバッグ会社に依頼 120〜140端末ほど依頼
  • QAがとりまとめて外部デバッグ会社に依頼

ゲームデザイナーの視点を持った人材の育成

  • 課金をしてもらえるバランスになっているかのチェック
  • KPIを見ながら難易度が高くないかのチェック
  • Webの見せ方が適切かのチェック
  • 勉強会を行う事でQAが根拠を持った運営の案を提示できるようになる

まとめ

  • 効率を上げるためにデバッグの管理を専任化したい
  • 開発の一部であるという意識で社内組織だからで切る仕事を積み上げていった
  • その結果でバッグ管理の効率化に加えタイトルに関わるさまざまなメリットを生み出す事に成功

今後も品質を守る最後の砦という意識を持ち開発に食らいついていきます

質疑応答

  • 自動テストは行っているか

    • ビルドのフローに自動テストを組み込んでいる、エイジング、モンキーテスト
    • 自動でバグチェック
    • 各画面を自動で遷移させたりとか
    • 各キャラ自動で組み合わせているとか
  • 例えば特別なツールで計測している?

    • ログはとっているが特殊なツールを使っている訳ではない
  • 具体的に、体感的にどのくらいのコストが削減できたか

    • 外部デバッグ会社に依頼する場合は社内で依頼する場合で3分の2のコストですむ
    • 半分ほどの費用でアルバイターを雇う事ができる
  • パブリッシャーにもQAが、デベロッパーにもQAが存在する?
    外部デバッグとは異なるやり方をどのようにしているか

    • クライアント様とのQAのやり方はクライアント様によって変わるのでクライアントにあわせる
    • キックオフMTGでどこの会社がどの部分を担当するのかを決めている
7
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?