1.はじめに

ゲームテストを行っていますと、
新規リリース時も大変ですが、運営に入るともっと大変になったご経験はありませんでしょうか？
運営タイトルも運営期間が長くなってくると、
「施策のたび、不具合の数がどんどん増えてきてるな」
「ここ同じような不具合前にもあったよな」
というようなことを思われたこともあるのではないかと思います。
今回、そのような点についてテスト後の振り返りや品質分析がいかに大切であるかを
お話できればと思います。

2.振り返りは何のために行うのか

まずは、「振り返りは何のためにやるんだろう」というところですが、
一般的には
【言動や傾向を客観的に捉えて、次回に向けた改善点の洗い出しを行い、その改善点を実行する】
とされています。

ゲーム開発のプロジェクトの振り返りとしては、
KPIやDAUなどの情報から次回どうしていけばいいのか等を客観的に改善点を洗い出し、
実行に移していくことが行われるかと思います。

では、テストの振り返りはどういうことを行うのかですが、
以下の点などを話し合い、次回に繋げていくことになります。
・テスト中に発生した問題点について
　-問題が発生した際にどのように行動をして対策を打ったか
　-テストにどのような影響が出たか
　-次回以降の対策

例えば、
実装が遅れ、テストスケジュールがひっ迫した
という問題が発生したとします。
事象が発生した際は、臨時対応を行う必要があり、
・増員対応
・スケジュール調整
などの対応が取られる可能性があると思います。
ただ、こちらは発生してしまった後にどう対応するかであって
このようなことが発生しないための対策ではないということです。

この発生しないための対策を話し合うのが振り返りの場として有効なものになります。
問題によっては発生させないということは難しい課題になるかと思います。
その場合は、発生頻度を落とすためにはどうするかというポイントを当てて、
取り組んでいく必要があります。

このような例のもので、
振り返りを行わず、毎回同じような問題が発生するとなると、
工数がひっ迫し、焦りからテストのミスにつながる可能性も出てきます。
また、増員・残業等も発生しますと、余計なコストもかかることになるので、
結果として負の連鎖が生まれてしまうため、
振り返りを行う必要があると考えます。

ただし、問題点のみ話題を上げるのではなく、
どういう点が良かったのかという点も話し合う必要があります。
その良かったことを次回どのように伸ばしていくかなどの話が行えれば、
より良いサイクルを生み出していく可能性があります。

3.品質分析は何のために行い、何に活用できるのか

次に、品質分析についてです。
こちらは、振り返りとイコールになる部分もありますが、
品質分析を用いて、各施策の不具合傾向をつかみ、
テストスコープの見直しやQA側で改善すべき点なのか、開発側で改善すべき点なのかを洗い出します。

品質分析は以下の情報等を用いていきます。
・テスト中に発生した不具合数（ランク別、機能別）
・不具合が発生した原因（不具合種別）

例えば、
不具合が合計100件発生したとします。
ただこの情報のみですと、前回比で不具合数が多い・少ないの判別が付きますが、
今後に活かすための数値としては弱い状態です。

では、不具合ランク別に以下のように数値が出た場合はどうでしょうか？

先程より、重要度の不具合の数が分かるようになりましたが、
どの機能に対して、どういう不具合原因が発生していたのかが分からなため、
情報が足りないように感じるかと思います。

上記情報に加え、以下のように不具合種別の情報も合わせてみるとどうでしょうか？

ランク別にどういう不具合原因があったかと言うのがこれで分かるようになり、
傾向がつかみやすくなったかと思います。

もう1つ、

上記のように機能毎に不具合種別で集計することにより、
どのような不具合原因がどのような機能で多く発生しているのか等が確認できるようになり、
改善に向けての振り返りが行えるようになります。

上記例の件を分析を行っていくと、
・マスタ設定ミスが全体の3割以上を占めている
・マスタ設定ミスの中で、大きな問題に発展する可能性がある課金に関わる
　【ガチャ機能】【ショップ機能】で不具合が多く発生している状態
・不具合ランクとしては【B】となっている可能性があるが、
　課金に絡む部分のため、テストの粒度としては引き続き細かく確認すべき
・同じような不具合傾向が毎回発生している場合、開発の運用フローに問題点が潜んでいる可能性がある
などが大きく挙げられるかと思います。

この内容から、振り返り同様、次回このようなリスクを軽減させるために、どういうことが行えるかなどを検討し、
実際に行動をしていくことで、初期品質の向上を目指せるのではないかと思います。

4.QA担当者内の振り返りのみではなく、担当開発者との振り返りも大切

前項まではQA内での振り返り、品質分析などを用いて、
QA内でどのように次行動を起こして、改善に努めるのかという内容になってきました。
では、それだけで、QA中の問題の洗い出しや改善対策が行えているかというと、【そうではない】と考えます。

QA担当者のみで話し合うと、QA側の視点のみで話が進んでしまう可能性があるため、
客観性がかけてしまう可能性があります。
また、開発担当者がどう思っていて、またどういう問題を抱えていたのかというのが、わからない状態になってしまうため、
QA担当者と開発担当者との振り返りも必要になります。

双方が対応することによって、問題点に対してより改善内容に踏み込んで対応を行うことができ、
同じ問題が発生しないためにも、お互いに協力していく必要があります。

5.最後に

一概に振り返りや品質分析を行うと言いましても、
何のために行うべきなのか目的を明確にして行う必要があると思います。
目的等を定め、何のためにこのような取り組みを行うのかはプロジェクト毎に変わってくるかと思われますが、
その中で、本記事で皆様の中で共感いただけるもの、
また、参考になるものが少しでもありましたら幸いです。