はじめに
皆様、本年も業務お疲れ様でした。 今年は新規ゲームタイトルのリリース前QAに携わらせていただきました。
今回リリースを迎えるまでに思わぬトラブルや複数の課題にたくさん遭遇しましたので、
本記事では、その経験の中から得られたナレッジを共有をできればと思います。
※あくまで今回のプロジェクトにおける一例です。ご自身の状況に合わせて、適度な距離感で参考にしていただければ幸いです。
事例①：リリース直前まで仕様変更・改修が頻繁に発生
【課題】手戻りの多発と検証期間の圧縮
テスト完了箇所や進行中の箇所にバランス調整が頻繁に入り、手戻り作業が多発しました。結果として、限られた期間で再検証を行わなければならない緊迫した状況が多くありました。当時はメンバー全員が差し込み対応などにより予定通りに業務が進んでおらず、その遅れや新たな差し込みに対しても共有が行き届いておらず、結果連携不足により、QAのテスト期間も逼迫していました。
【工夫】開発・QA合同の「Daily Sync MTG」の導入
状況をリアルタイムで追うため、プランナー(PL)・エンジニア(EN)・デザイナー(DE)・QAを交えた定例MTGを毎日実施し、以下の内容をすり合わせました。
- QAパート
- スケジュールの再確認（追加・変更事項の有無）
- 最適な検証環境の確認（どの環境に反映してもらうかPL/ENと相談）
- 進捗共有（オンスケジュールの確認、不具合検知・修正状況）
- 開発パート
- 検証対象に関する追加情報の共有
- 差し込み検証の依頼や、重点確認箇所の要望出し
【結果】タイムラグの解消
懸念点や追加依頼をその場で密に調整できるようになったことで、課題解決や進行判断のタイムラグが大幅に減少しました。
事例②：リリース時の実装データ数が膨大
【課題】網羅的テストが現実的でない
①課金検証の課題：
- 課金検証では網羅的に検証をおこなうため、全商品を対象とし購入テストをおこなう予定でした。そのため膨大なテスト工数がかかる状態となっており、予算や時間に対して見合ってない状態となっていました。
②ステージクリア等の確認の課題：
- 前提としてテスト対象となるゲームでは、各ステージが存在し、敵を倒すことでステージが進む仕組みとなっており、無数のステージが用意されていました。
- テスト範囲としては当初全ステージを実機で確認し、動作と難易度の確認をおこなう予定でしたが、膨大なステージ数があり、時間も予算も少ない中全てを網羅することが厳しい状態でした。
【工夫】「リスクベース」でのテスト範囲の絞り込み
開発チームと協議し、品質を担保できるラインを見極めてテスト範囲を絞り込みました。
-
実課金検証：
- 商品カテゴリーにつき1点の購入確認で購入フロー自体は担保できると判断し、全数確認から「特定箇所にピックアップして確認する方法」へ変更。
-
ステージクリア等の確認：
- 全数確認は工数的に困難なため、難易度が切り替わる「閾値」や、開発側が懸念しているポイントにフォーカスして検証を実施。
【結果】重要障害ゼロでのリリース
検証負荷を下げつつ、スムーズにQAを進行できました。クリティカルな箇所は開発チームと密にすり合わせたため、リリース時に重要度の高い障害を出すことなく、品質に貢献できました。
【今後の課題】運用フェーズに向けた改善
現在は無事にリリースを迎え運用フェーズに入りましたが、まだ以下の課題が残っています。これらは次なる改善テーマとして取り組んでいく予定です。
- 不具合分析・再発防止のフロー整備
日々の運用で手一杯になり、不具合の分析やテストケース追加などの再発防止策が後手に回りがちです。 今後は「BTSへの自動不具合起票」などを導入して事務作業を効率化し、分析やフロー整備に充てる時間を確保したいと考えています。 - スケジュール策定の精度向上
開発側の繁忙もあり、QAスケジュールの認識合わせが遅れることがありました。 今後は主要メンバーで「スケジュール認識合わせ」に特化したMTGを定期開催し、検証工数のアサイン調整をスムーズに行える体制を目指します。
最後に
振り返りを記事にすることで、私自身も現状の課題再認識や新たな気づきを得ることができました。 今後、新規プロダクトを担当される方や、QA業務に携わる皆様にとって、少しでも運用の参考になれば幸いです。