1.はじめに
みなさま、こんにちは。
昨年は以下の記事で、開発チームの作業遅延や連携漏れを改善するために、QAとして私が行った立ち回りについてご紹介しました。
今回も開発チームの課題解決についてご紹介しますが、前回はリリース後の運用タイトルだったのに対して、今回はリリース前の新規開発中タイトルでの開発課題を取り上げたいと思います。特にプロダクトメンバーの巻き込み方の工夫を事例をもとにご紹介します。
- 担当タイトルの課題が上流工程にあって、QAだけでは改善できなそう
- 現状分析→課題特定→対策検討まではできるが、対策を実行する際にどうやってプロダクトのメンバーを巻き込んでいけば良いかわからない
といった方の参考になれば幸いです。
2.リリース前タイトルでの課題例
過去私が実際に担当したタイトルでは以下のような状況に陥っていました。
- プロダクトの人員が足りず、実装が終わらない状態が続き、テストが進行できない
- 品質を担保してリリースするには、プロダクト体制強化 / リリース日延期を行う必要がある
このような状況の中で、QAとして私が実際に行ったことを簡単にご紹介します。
3.QAからのアクションと効果
「開発ボリュームに対してプロジェクトマネージャー・ゲームプランナー・ゲームエンジニアのリソースが足りていない」という課題に対して、以下の3つの情報を私の方で可視化＆資料化し、QA責任者（QAチームのマネージャー）からプロダクト責任者（事業部部長）へ開発状況をエスカレーションしていただきました。
- 現状のペースのままだとリリース予定日時点で障害（市場不具合）が重大度別に何件出るか
- 現状のペースのままだと不具合の収束にいつまでかかるのか
- リリース予定日までにQA完了させるためには実装・不具合解決ペースをどれだけ上げる必要があるか
加えて、デイリーで上記の見込みを更新し、私（QA担当者）からプロダクト責任者（事業部部長）へ報告しました。
その結果
- QA情報を可視化、共有したことで適切な品質状況の判断が可能になった
- 適切な開発期間の確保
- 開発体制の強化
に繋がりました。
4.QAから提示した情報のサンプル
プロダクト責任者へエスカレーションを行う際に、特に以下2点の可視化を行いました。
4-1.残テストケース数の推移と、着手済みテストケースのうち不具合によりテスト実行できない割合
テストケースの消化状況を可視化し、テストが進行していない状況と、その要因がプロダクトマター（不具合対応や実装待ち）であることを伝えました。
4-2.不具合チケットのOPEN vs CLOSE推移予測
現状の実績値から、現状のペースのままだとリリース予定日時点でどれだけ不具合が残存する形になるのか、不具合の収束にいつまでかかるのかを伝えました。
合わせて、その予測を実現するための「実装完了時期」「初期品質（1項目あたりの不具合遭遇率）」「1日あたりの不具合チケット解決数」という条件もセットで提示しました。
各予測値の具体的な算出方法は以下となります。
- 【予測残存不具合数（グラフの黄色）】＝【予測不具合起票総数（グラフの青色）】ー【予測不具合総解決数（グラフの赤色）】
- 【予測不具合総起票数（グラフの青色）】＝【その日に消化されるであろう項目数（予測値）】×【1項目あたりの不具合遭遇率（直近の実績平均）】＋【項目消化総数（実績値）】
- 【その日に消化されるであろう項目数（予測値）】＝【テスター1人日あたりの項目消化数（直近の実績平均）】×【アサイン予定しているテスター稼働人数】
- 【予測不具合解決数（グラフの赤色）】＝【その日に解決されるであろう不具合数（直近の実績平均）】＋【不具合解決総数（実績値）】
5.QA主導でプロダクトを巻き込むためのポイント
上記のアクションを実行して実際にプロダクトに動いてもらった結果を振り返ると、QAから提案する際に大きく2つポイントがあったと考えてます。
1つ目は「提案先と順番」です。
プロダクトに動いてもらうには、現場メンバーよりもプロダクトの責任者を先に巻き込むことが重要です。そのために、まずはQA責任者と対策内容を握り、QA責任者主催のMTGでプロダクト責任者へ提案を行う形を取ったことが有効でした。
2つ目は「提示する情報」です。
プロダクト責任者へ提案を行う際には、プロダクト責任者が気にする情報を伝えることが重要です。現状の課題を伝えるだけでなく「このままだと今後どうなってしまうのか」というリスクを定量的に提示したことが効果的でした。合わせて、「これからどうして欲しいのか」という具体的な改善要望もセットで伝えられるとより改善がスムーズに進むと思います。
少しでも、同じような課題に直面されている方の参考になりましたら幸いです。