KLab株式会社様 導入事例

我々の方でメトリクスは設定しているのですが、何が要因でテストが上手く進んでいないのかが瞬時にわかるようになっていたので、やりやすかったですね。あとは、今まではサービスリリース後にバグが発覚してその対応でバタつくことも多かったのですが、このプロジェクトに関してはサービスに影響するようなバグも無く、運営に専念出来ているというのはすごいですね。

今回のプロジェクトは、KLabの品質管理部としても意義のあるプロジェクトになったと思っています。これまで品質管理部はやはり「テストをアウトソースするベンダーさんをコントロールする部署」という社内イメージが強かったのですが、最近では「品質管理部にテストしてほしい」と社内で言われるようになりました。品質状況を数値化して報告することで評価してもらえ、部のプレゼンスも向上したと思います。「品質管理部に頼めば品質の状態が判断しやすい」と、部のブランディングが出来たようです。

いきなり高度なことを実現しようとしても無理なので、まずは何を目安に品質の良し悪しを判定するのか定義しようというところから始めました。今は「バグの残件数」を品質の一つの指標として、開発チームと共通認識が持てるようになっています。はじめはデータが蓄積されておらず上手くいきませんでしたが、ナレッジやデータが蓄積されてくると、次第にチームが学習して上手く回るようになってきました。SHIFTさんにもご協力いただきながら、今はテスト進捗の予定とバグの発見数および残件数などを主な指標として品質管理を行っています。他には、用語の統一も行いましたね。誰でも正しい認識が共有できるような共通の言葉を持つというのは、組織にとって重要だと考えています。

今まで主なテスト観点だった「当たり前品質」だけではなく、やはりゲームはお客様に楽しんでいただけるものでないといけないと思うので、今後は「魅力的品質」についても追求していきたいですね。「魅力的品質」に関わるゲームの企画段階は開発工程の上流にあるので、今より工程を遡って、早い段階で品質管理部が関与することで「当たり前品質」と「魅力的品質」の双方を高めていけたらと思っています。

「魅力的品質」に関しては、今回のプロジェクトから少しづつ取り組み始めています。SHIFTさんで行ったフォーカステストでは良い意味で容赦なく、テスターの方から厳しいコメントをいただいて（笑）。しかしそのコメントが重要でして、操作方法など開発チームで「こうした方がいいかな」と思っていたこととの違いがわかったり、逆に方向性の確認も出来たりと、お願いして良かったなと思いました。

システムテストの手法も改善の余地があると思いますし、今はまだ開発からの要望を受けてテストを実施している部分も多いので、これからテストのより良いやり方、仕組みだったり体制だったりを一緒に作っていただきたいと思います。さらには、例えばスマートフォンが高温になる状態を検出することが出来るテスト手法を導入するなど、「一元的品質」の向上につながる施策にも、取り組んでいただきたいですね。

今回、新規プロジェクトをお願いしたのですが、SHIFTさんのテストチームが経験から学んだことを、大変活かしてくれているなと感じています。以前のプロジェクトでは取り組みたくてもいろいろな理由で実現できなかったことを、今回のプロジェクトでは実行していただいていて、成長するチームを提供してくれたことにとても感謝しています。今後については、品質管理に携わる者の王道のお願いになってしまうと思うのですが、ヒューマンエラーを防止する活動に一緒に取り組んでいただきたいと思っています。サービスを作っているのは人間で、その人間が「どこでエラーを起こしやすいのか」「どういう風に作業を改善すればエラーが防止出来るのか」というところを可視化し、仕組み化することでヒューマンエラーを無くしていく。そんな取り組みを一緒に行っていただけたらと思います。