#はじめに
私はゲーム業界でQAに関する仕事をしています。
中でも主に運用タイトルのQA管理や障害削減、効率化などを行っています。
モバイルゲームの運用に関わったことがある方はご存知かもしれませんが
リリース直前での仕様調整や不具合への対応により
きつきつの開発/検証スケジュールに直面したご経験はないでしょうか？
一時的ならまだしも、運用が続いていく中で
こうした事例が慢性化すると、品質も安定せずにきついスケジュールが常態化する可能性もあります。
この記事では、こうしたリスクを軽減するために気をつけた方が良いと思った点を経験ベースでまとめてみました。
#テスト設計、検証工数の確保について
スケジュールを圧迫する要因で、大きく以下2点について振り返りをおこないました。
- イベント、新規実装の集中
- 全体的な開発遅延
それぞれについて、QAの立場からにはなりますが、問題点とアプローチ案をまとめてみます。
##1. イベント、新規実装の集中
###事例
- 開発状況や、何らかの事情により、特定の日/週にイベントや新規実装が集中し、テスト量が増大することがあった
###問題点
- テスト量が増えることで、急な増員が必要になりテスト精度が落ちる(ナレッジ不足)
- QAだけでなく、開発チーム全体の負荷が高いのでミスしやすくなる
###アプローチ案
- 上記懸念に伴う品質リスクを開発側へ提示し、極力検証工数をならせるように、開発/QAスケジュールを見ながら、検証工数が密集しているところや薄いところを開発担当者と一緒にMTGなどで調整できるとよいと思います
##2. 全体的な開発遅延
ここでは2つの事例をあげてみます。
###事例1
- 企画の確定/QAへの仕様書共有が、QA開始の前々日の夜などに来て、QA開始日の前日1日しかテストケース作成工数が確保されてないことがあった
###問題点
- 開発側のレビュー時間やフィードバックをもらった後のテスト設計者の修正時間が見込まれてないため、レビューの形骸化やテストケースが不十分になる可能性が高い
###アプローチ案
- 無理のないテストケース作成工数と作成期間を明示し、それを確保できなかった場合のリスクについて、開発側と共通認識を持ったうえで、企画スケジュールを相談することが重要と考えます
###事例2
- 実装遅延が定常化し、QA開始日になっても未実装箇所がある
- 機能面の仕様が固まっておらず、正とする挙動が不明(設定値の仕様未確定を除く)
###問題点
- 十分に品質を担保できなくなる
- QA開始が遅延するとQA期間がひっ迫し、検証が荒くなる
- 残業による対応が発生し、検証者に負荷がかかる
- スケジュールを組みづらく、適正工数が不明確になるため、工数管理もしづらくなる
- 一度負荷をかけてなんとかしてしまうと、開発側は何とかなるんだと受け取り、その結果再発しやすく、いずれそれが文化になる可能性がある
###アプローチ案
- 無理のない企画期間/実装期間の確保をQA側から促し、相談することが重要だと思います
- スケジュール策定後に開発側へ依頼しても動かしづらいはずなので、次回スケジュール策定タイミングの前に相談できるとよいと思います
- QA開始までに実装が整わなかった場合、しわ寄せを全面的に請け負うのではなく、ルールを開発稼働前に合意しておくことも大事です
- 例えばQA開始までに実装が整わなかった場合、検証範囲を絞る/開発側に巻取ってもらうなどのルールを決めておけば、ある程度は進捗を想定しやすくなります
#QAのスケジュール管理について
スケジュール圧迫の要因は上述しましたが、スケジュールの管理方法も重要です。
こちらについても事例をまとめました。
##QAのスケジュールと開発スケジュールが、それぞれ別ファイルで管理されており、連動していない
###事例
- QAのスケジュールと開発のスケジュールが連動していない状態でそれぞれ別管理されていた
###課題
- ファイルが二重管理になることで、更新コストが二重でかかる
- 通常開発スケジュールは開発側、QAスケジュールはQA側で管理されることが多いと思うが、開発スケジュール変更時に万が一QAへの共有が漏れると、検知が遅れ、QA期間が十分確保できなくなる可能性もある
###アプローチ案
- 開発スケジュールにQAスケジュールも含めてもらい、1つのファイルやツールに一元管理できるとベストです
- もしくは最低限施策名、企画確定日、実装完了日、リリース日だけは開発/QAスケジュールで連動させておいた方がよいと思います
- そうすれば施策の追加や開発期間が変動しても自動で反映されるため、開発から共有漏れがあっても、検知しやすくなります
#さいごに
上記のような状況に陥らないために、あるいは陥っているときは、極力開発と密にコミュニケーションをとり、QA側の懸念を理解してもらえるまで相談し、開発/QA双方のスケジュールが無理のない形にできると、みんなハッピーになれるのではないでしょうか。