失敗確率を最小化！ユーザーの声からリリース前のネガティブチェックリストを作成

GREE Tech Conference 2023で発表された資料です。
https://techcon.gree.jp/2023/session/TrackB-4

Transcript

1. リリース時の失敗確率を最小化！ ユーザーの声から ネガティブチェックリストを作成 株式会社ExPlay QAエンジニア 山本 幸寛
2. 登壇者紹介 山本 幸寛(やまもと　ゆきひろ) 株式会社ExPlay Customer & Product Satisfaction部　WFQAチーム 名と所属 氏名と所 2 氏名と所属 略歴 家庭用ゲームやモバイルゲームの QA業務を経験後、2021年グリー株式会社に入社 入社後はライトフライヤースタジオタイトルの QAを担当するチームに所属し 長期運用タイトルのQA業務を担当 合わせて上流工程からより品質を高めるためユーザーテストに関連する対応も担当
3. はじめに • グリーでは研究会という形で、複数社合同でQA技術の研究を行っている • 本発表はその研究会で研究したテーマの一つ • 本テーマの研究メンバーは下記4名※敬称略 ◦ 株式会社 ProVision ▪ 出口 健太（でぐち けんた） ◦ グリー株式会社 ▪ 仁禮 景太（にれ けいた） ◦ 株式会社ExPlay ▪ 神谷 勇毅（こうや ゆうき） ▪ 山本 幸寛（やまもと ゆきひろ） 3
4. 本日の流れ • 背景と方針 • ネガティブチェックリストについて • 導入方法想定 • 調査を実施しての所感 • 今後の展開 4
5. 研究の背景 • グリーでは成功確度を高めるため「ユーザー視点で面白さやUI/UXの改善点を フィードバックするユーザーテスト」を実施しているが課題がある 5 『有益性の可視化』と『実行の汎用化』を目指す ◦ 有益性が見えない ▪ 改善結果が売上や継続率に直結しているか判断しづらい ◦ 属人化する ▪ バランス設計などのUX観点でフィードバックを行う際、テスト実行者頼り になってしまう
6. 研究の方針 • 既存のユーザーテストの枠組みを壊し「面白さ」へのアプローチはしない ◦ 有益性の提示が困難 ▪ 参考：サラダマックの大失敗 ▪ ユーザーが「こうした方が良い」と言うものと、実際に面白いと感じるもの は異なる ▪ 面白さに関してヒアリングしてもそのままでは参考に出来なさそう ◦ 汎用性を持たせることが困難 ▪ 「より面白いものにするにはどうすれば良いか？」に対するアプローチは クリエイティブ要素が強い 6
7. 研究の方向性 • ネガティブフィードバックにフォーカスする ◦ 「面白くない・気持ちよくない・使いづらい」というネガティブに感じるポイントは、 タイトル・ユーザー横断で共通していそう ◦ 過去のタイトルから以下をリスト化することで、定量的な根拠を提示できそう ▪ こういった仕様・実装になっていたらイケてない ▪ なぜなら過去同様の仕様・実装でリリースしたら「面白くない・気持ちよくな い・使いづらい」という声がこれだけあったから 7 「どうすれば良くなるのかは分からないが、少なくとも現状が望ましい状態から 乖離しているよ」ということを客観的にフィードバックすることはできそう
8. ネガティブチェックリストについて 8
9. チェックリスト作成方法 9 タイトル 選定 • 直近2年以内にリリースされたタイトルを選定 • リリースから3か月のCS問い合わせから、ネガティブフィードバックにあたる意見・要望を抽 出 ◦ 問い合わせ総数：4170件 ◦ うち意見・要望と見られるもの： 470件 ユーザーの 意見・ 要望を収集 リスト化 • 抽出した生の定性データを以下 2段階で加工してカテゴライズ ◦ 「端的に言うとどういった内容か？」 ◦ 「本当に求めているものは何か？」 • 該当観点に紐づく意見・要望の数が多い順＝優先度としてチェックリストを作成
10. カテゴライズの例 10 『同じことを言ってるものをまとめる』 【具体（限定）的】　　　　　　　　　　　　　　　　　　　　【抽象（汎用）的】 『同じことを求めているものをまとめる』
11. ポイント • 同じ意見・要望を「本質的に何を求めているか」の観点で抽象化 ◦ 例：「周回するのがしんどい」という意見に対して… ▪ NGフィードバック例 • 意見を鵜呑みにして周回要素の削除 ◦ 結果、遊べるコンテンツが無くなりユーザー離れに繋がる 11
12. ポイント • 同じ意見・要望を「本質的に何を求めているか」の観点で抽象化 ◦ 例：「周回するのがしんどい」という意見に対して… ▪ 「本質的に何を求めているか」の観点で抽象化 • 育成にかかる時間を短縮する手段が欲しい • 育成の過程をもっと面白くしてほしい 12 ▪ 抽象化した意見を元に用意したチェック観点 • 育成にかかる時間を短縮する手段は設けられているか？ • 育成の過程は単純作業ではないか？ ▪ 上記チェック観点を利用した場合のフィードバック例 • 育成パックのラインナップ拡張/自動周回機能の追加 • 育成コンテンツ・サイクルの見直し
13. ユーザーが本当に求めているものリスト • 計26個の『ユーザーが本当に求めているもの』観点リストが完成 • 観点毎の重み（該当観点に紐づくユーザー意見・要望の数）に偏りが存在 <観点リスト例> 13
14. ネガティブチェックリスト • 『ユーザーが本当に求めているもの』観点リストを元にチェックリスト化 • 説得力を持たせるため意見・要望の数に応じた『優先度』を設定 • ネガティブな感情を生む仕様になっていないかを確認するためOK/NG判定に 14
15. 導入方法想定 15
16. 導入方法想定 • 実施タイミングはαとβの合計2回 ◦ αタイミング ▪ テスト対象 • 仕様書 ▪ 狙い • 開発初期のタイミングで実施し、実装の手戻りを抑制 ◦ βタイミング ▪ テスト対象 • 実機挙動 ▪ 狙い • αタイミングと比較し、より具体的なフィードバックを実施 16
17. 効果想定 • 1.有益性の可視化 ◦ 過去事例から観点を生成しているためフィードバックの納得感が向上 • 2.実行の汎用化 ◦ 観点に沿ったフィードバックを行う事で実行者によるバラツキの緩和 • 3.ネガティブな反応の減少 ◦ QAからのフィードバックが反映されユーザーのネガティブな反応が減少 • 4.コスト減少 ◦ QA期間中の仕様変更量が減少し、開発＆QAコスト減少と不具合数減少 17
18. 効果想定 • 現状の注意点 ◦ CS問い合わせ調査数が1タイトルとサンプル数が少ない ▪ ユーザーが本当に求めている物が「タイトル固有の物」か「どのタイトルに もあてはまる汎用的なものか」の切り分けが出来ていない • こちらは調査対象を広げる事で解消される見込み 18
19. 調査を実施しての所感 19
20. 所感 • 『具体→抽象化』の対応が属人的な対応が必要だった ◦ 対策：一度1か月分のお問い合わせで対応し対応方法を確立 • 作業過程の情報を残し、情報を参照できる体制の構築 ◦ 誰でも一連の調査が可能に • お問い合わせ以外の情報源としてのX(Twitter)調査が、ポスト数が多く大変 ◦ 対策：今見ているポストをcsv化する『ついすぽ』というツールを使用 • 抽出対応の手間を削減し効率的に情報を収集する事が可能に 大変な部分はあったが一定体系化を進める事が出来、複数タイトル調査を実施出来る 目途が立ったため、より説得力を持ったリストが作成できる見込み 20
21. 今後の展開 21
22. 今後の展開 • X(Twitter)調査を実施し情報のアップデート ◦ お問い合わせ調査と同じ、または別の複数タイトルを調査しリスト拡充 ▪ 狙い • より多い生の声、タイトル事例を収集し、ネガティブに繋がるポイント の更なる可視化 • CSお問い合わせ調査の実施タイトルを増やす ◦ 現状調査タイトル数が少ないため、複数タイトルで調査しリスト拡充 ▪ 狙い • 収集する意見・要望の数が増える事でリストの説得力強化 • 複数事例を収集し共通のネガティブに繋がるポイントの可視化 • ジャンルによる違いがあれば、その可視化 22
23. ご清聴ありがとうございました 23