LoginSignup
9
2

More than 5 years have passed since last update.

開発側と連携して、実装品質を改善した話

Last updated at Posted at 2018-12-13

この記事の目的

私は現在3つのタイトルのQA管理を行っております。直近開発側と連携して、QA前の実装品質を上げる取り組みを行った結果、QA/開発双方で対応工数が減り、さらに市場不具合を削減することができました。

この取り組みを通じて、QAチームと開発チームが連携して改善を進めることの重要性を強く感じたので、特に開発の方へ向けて、その内容をまとめます。

QA前の実装品質向上に目を向けた背景

事の発端は、私の担当しているタイトルでQAコストがかかりすぎていたため、効率化を進めたいと思ったことから始まりました。まず、QA中の不具合数に着目してみると、他タイトルと比較しても、不具合数がかなり多かったため、QA中の不具合数を削減することで、テスト実行コストを減らすことにしました。

取り組み内容

開発によるQA前の簡易チェック導入

QA中の不具合数を削減するとなると、QA前の実装品質を高める必要があります。今回の対象タイトルでは、QA開始時にそもそも実装が整っていないことや、毎回発生するような不具合も一定数発生していたため、QA前に開発側で簡易的にチェックするフローを導入してもらうことにしました。

まずQA内でベースとなるチェックリストを作成し、それを基に開発側でアップデートしてもらう形にしました。施策によって、チェックポイントは変わるので、大まかにガチャ/レイドイベント/ショップなど数種類作成しました。
5635796-31a8f946c510b12b4d23030abcdc2fabf1c77f17.png

導入結果

上記により、QA中の不具合数は導入から半年で60%以上減少し、当初課題に挙がっていたQA費用だけでなく、市場不具合数も大幅に削減することができ、期待以上の効果が得られました。
5635797-17f53b8895dec147d99aa6db3fa583cbea1e3a43.png

対象 削減率(月)
QA費用 -35%
市場不具合数 -40%

また、この取り組みは他にも2つのタイトルで導入を開始し、今まで継続して取り組まれています。開発側へメリットを聞くと、やはり不具合対応コストが減り、品質も向上するという部分が大きいようです。

工夫したこと

  • チェック項目のベースはQAチームで作成
    • 開発側でチェックする文化がない場合、開発担当者でのチェック項目の洗い出しはそれだけでかなりの労力になると思います
    • 不具合の傾向なども把握しているQA側で作成した方がスピード感もあると思うので、QA側に依頼することをお勧めします
  • 初めからチェック項目数を多くしすぎない
    • 初めから100%のチェック項目を作ろうとすると、対応工数が大きくなってしまい、導入自体難しくなってしまいます
    • 最初はこれならすぐ終わりそうというくらいの項目数にしておいて、導入後少しずつアップデートしていく形がスムーズかと思います
  • 初めから継続運用前提で進めない
    • 確かにこの取り組みは開始1ヵ月程度で成果が出るものではないので、実際にチェックする担当者もまずやってみないと工数感などもわからないと思うので、最初はトライアルとして実施して、振り返りを行って、よければ次の対象を決めていくという前提でスタートしました

ただ、緩くしすぎてもスピード感が損なわれるため、導入が成功したら、状況管理を徹底し、小まめにアラートを投げられる体制に変えていく必要があります。

  • 開発側にQA窓口の方を立てる
    • QAチームからアラートを各開発担当者それぞれへ上げるのは、かなりの労力が必要になるため、開発側で窓口になる方を立てていただき、その方にQA側と課題感をすり合わせて、開発チーム内に落としてもらえると、QAは分析に集中でき、精度の高い改善提案が行えるようになります
  • 向こう3ヵ月~半年の目標削減件数を合意しておく
    • 導入が成功したら、直近の件数推移を基に、無理のない範囲で各施策担当者と目標件数を合意できると、その後目標からの上振れをトリガーとして、アラートが投げやすくなります
    • また設定した目標に対して、実績を振り返るというのも非常に重要です。今回は、各施策担当者へ1つのスプレッドシートに実績と振り返りをQA後に記載してもらいました。この運用はそれなりに工数はかかりますが、状況が可視化されるので、改善がスピードアップしました 5635799-2f551d0506079cae0e8b8d04b62c9bce87bcb952.png
  • 件数推移や原因別の内訳を可視化して、週次定例で振り返り
    • やはり最初は一部チェック項目がチェックされていなかったり、チェックはついているが、正しいチェックがされていないことが多く発生するので、最初はQAチームと週次など頻度高めに振り返りをすることで、早期にフローの課題を解消したり、チェックリストの拡充を加速させることができます
    • また、実際にチェック精度が高く、改善している開発担当者がいれば、QA側から共有してもらうようにして、全体の定例などでしっかり賞賛することも非常に重要です

以上が工夫してよかったと感じたポイントでした。

さいごに

QAコストの効率化や品質改善は、QA部門で何とかするものだというイメージが強いと思いますが、開発工程で品質改善できると、QAだけでがんばるよりも圧倒的に早く、大きな効果を埋めると思います。ぜひQAと積極的に連携していただき、品質改善につなげていただけますと幸いです。

9
2
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
9
2