Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
失敗確率を最小化!ユーザーの声からリリース前のネガティブチェックリストを作成
Search
gree_tech
PRO
October 13, 2023
Technology
0
730
失敗確率を最小化!ユーザーの声からリリース前のネガティブチェックリストを作成
GREE Tech Conference 2023で発表された資料です。
https://techcon.gree.jp/2023/session/TrackB-4
gree_tech
PRO
October 13, 2023
Tweet
Share
More Decks by gree_tech
See All by gree_tech
kustomizeをいい感じに使う方法
gree_tech
PRO
5
3.1k
スケーラビリティとコスト管理 Google Cloud Spanner 費用最適化の取り組み
gree_tech
PRO
0
900
「アナザーエデン 時空を超える猫」の5年前のログを引っ越してデータドリブンで事業運用プロセスを改善した話
gree_tech
PRO
0
640
Unity,PHP+Jenkins+GAS 多言語対応を意識させない開発を目指したシステム構築
gree_tech
PRO
0
1.1k
全社総会における「REALITY Spaces」の活用と、Addressableを用いたコンテンツ配信技術について
gree_tech
PRO
0
750
AWSのEKS環境でログ機能を構築/リリースしたお話
gree_tech
PRO
0
580
「ヘブンバーンズレッド」の大規模アップデートにおける国内及び翻訳QAの取り組み
gree_tech
PRO
0
690
アプリ「REALITY」の12言語対応プロセスの仕組みと品質向上の取り組み
gree_tech
PRO
0
1k
REALITYアプリのメンテナンスなしでの機能リリースを実現する、Istio導入とB/Gデプロイ実現の取り組み
gree_tech
PRO
1
810
Other Decks in Technology
See All in Technology
とあるOSSを継続可能にするための取り組みについて / OSS Refactoring Process
bun913
1
190
App Router を実プロダクトで採用して見えてきた勘所をちょっとだけ紹介
marokanatani
1
920
Analytics-Backed App Widget Development - Served with Jetpack Glance
miyabigouji
0
550
「認証認可」という体験をデザインする ~Nekko Cloud認証認可基盤計画
logica0419
2
430
Javaにおける関数型プログラミンへの取り組み
skrb
7
320
事前準備が肝!AI活用のための業務改革
layerx
PRO
1
370
あなたの知らないiOS開発の世界
recruitengineers
PRO
3
170
フルカイテン株式会社 採用資料
fullkaiten
0
32k
Oracle Autonomous Database:サービス概要のご紹介
oracle4engineer
PRO
1
7k
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
130
CRTO/CRTL/OSEPの比較・勉強法とAV/EDRの検知実験
chayakonanaika
1
1.1k
持続可能なソフトウェア開発を支える『GitHub CI/CD実践ガイド』
tmknom
6
1.3k
Featured
See All Featured
RailsConf 2023
tenderlove
28
810
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Building Your Own Lightsaber
phodgson
101
6k
Design by the Numbers
sachag
277
19k
Optimizing for Happiness
mojombo
375
69k
BBQ
matthewcrist
83
9.2k
4 Signs Your Business is Dying
shpigford
179
21k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Building Applications with DynamoDB
mza
90
6k
Why Our Code Smells
bkeepers
PRO
334
56k
Code Review Best Practice
trishagee
62
16k
Infographics Made Easy
chrislema
239
18k
Transcript
リリース時の失敗確率を最小化! ユーザーの声から ネガティブチェックリストを作成 株式会社ExPlay QAエンジニア 山本 幸寛
登壇者紹介 山本 幸寛(やまもと ゆきひろ) 株式会社ExPlay Customer & Product Satisfaction部 WFQAチーム 名と所属 氏名と所
2 氏名と所属 略歴 家庭用ゲームやモバイルゲームの QA業務を経験後、2021年グリー株式会社に入社 入社後はライトフライヤースタジオタイトルの QAを担当するチームに所属し 長期運用タイトルのQA業務を担当 合わせて上流工程からより品質を高めるためユーザーテストに関連する対応も担当
はじめに • グリーでは研究会という形で、複数社合同でQA技術の研究を行っている • 本発表はその研究会で研究したテーマの一つ • 本テーマの研究メンバーは下記4名※敬称略 ◦ 株式会社 ProVision
▪ 出口 健太(でぐち けんた) ◦ グリー株式会社 ▪ 仁禮 景太(にれ けいた) ◦ 株式会社ExPlay ▪ 神谷 勇毅(こうや ゆうき) ▪ 山本 幸寛(やまもと ゆきひろ) 3
本日の流れ • 背景と方針 • ネガティブチェックリストについて • 導入方法想定 • 調査を実施しての所感 •
今後の展開 4
研究の背景 • グリーでは成功確度を高めるため「ユーザー視点で面白さやUI/UXの改善点を フィードバックするユーザーテスト」を実施しているが課題がある 5 『有益性の可視化』と『実行の汎用化』を目指す ◦ 有益性が見えない ▪ 改善結果が売上や継続率に直結しているか判断しづらい
◦ 属人化する ▪ バランス設計などのUX観点でフィードバックを行う際、テスト実行者頼り になってしまう
研究の方針 • 既存のユーザーテストの枠組みを壊し「面白さ」へのアプローチはしない ◦ 有益性の提示が困難 ▪ 参考:サラダマックの大失敗 ▪ ユーザーが「こうした方が良い」と言うものと、実際に面白いと感じるもの は異なる
▪ 面白さに関してヒアリングしてもそのままでは参考に出来なさそう ◦ 汎用性を持たせることが困難 ▪ 「より面白いものにするにはどうすれば良いか?」に対するアプローチは クリエイティブ要素が強い 6
研究の方向性 • ネガティブフィードバックにフォーカスする ◦ 「面白くない・気持ちよくない・使いづらい」というネガティブに感じるポイントは、 タイトル・ユーザー横断で共通していそう ◦ 過去のタイトルから以下をリスト化することで、定量的な根拠を提示できそう ▪ こういった仕様・実装になっていたらイケてない
▪ なぜなら過去同様の仕様・実装でリリースしたら「面白くない・気持ちよくな い・使いづらい」という声がこれだけあったから 7 「どうすれば良くなるのかは分からないが、少なくとも現状が望ましい状態から 乖離しているよ」ということを客観的にフィードバックすることはできそう
ネガティブチェックリストについて 8
チェックリスト作成方法 9 タイトル 選定 • 直近2年以内にリリースされたタイトルを選定 • リリースから3か月のCS問い合わせから、ネガティブフィードバックにあたる意見・要望を抽 出 ◦
問い合わせ総数:4170件 ◦ うち意見・要望と見られるもの: 470件 ユーザーの 意見・ 要望を収集 リスト化 • 抽出した生の定性データを以下 2段階で加工してカテゴライズ ◦ 「端的に言うとどういった内容か?」 ◦ 「本当に求めているものは何か?」 • 該当観点に紐づく意見・要望の数が多い順=優先度としてチェックリストを作成
カテゴライズの例 10 『同じことを言ってるものをまとめる』 【具体(限定)的】 【抽象(汎用)的】 『同じことを求めているものをまとめる』
ポイント • 同じ意見・要望を「本質的に何を求めているか」の観点で抽象化 ◦ 例:「周回するのがしんどい」という意見に対して… ▪ NGフィードバック例 • 意見を鵜呑みにして周回要素の削除 ◦
結果、遊べるコンテンツが無くなりユーザー離れに繋がる 11
ポイント • 同じ意見・要望を「本質的に何を求めているか」の観点で抽象化 ◦ 例:「周回するのがしんどい」という意見に対して… ▪ 「本質的に何を求めているか」の観点で抽象化 • 育成にかかる時間を短縮する手段が欲しい •
育成の過程をもっと面白くしてほしい 12 ▪ 抽象化した意見を元に用意したチェック観点 • 育成にかかる時間を短縮する手段は設けられているか? • 育成の過程は単純作業ではないか? ▪ 上記チェック観点を利用した場合のフィードバック例 • 育成パックのラインナップ拡張/自動周回機能の追加 • 育成コンテンツ・サイクルの見直し
ユーザーが本当に求めているものリスト • 計26個の『ユーザーが本当に求めているもの』観点リストが完成 • 観点毎の重み(該当観点に紐づくユーザー意見・要望の数)に偏りが存在 <観点リスト例> 13
ネガティブチェックリスト • 『ユーザーが本当に求めているもの』観点リストを元にチェックリスト化 • 説得力を持たせるため意見・要望の数に応じた『優先度』を設定 • ネガティブな感情を生む仕様になっていないかを確認するためOK/NG判定に 14
導入方法想定 15
導入方法想定 • 実施タイミングはαとβの合計2回 ◦ αタイミング ▪ テスト対象 • 仕様書 ▪
狙い • 開発初期のタイミングで実施し、実装の手戻りを抑制 ◦ βタイミング ▪ テスト対象 • 実機挙動 ▪ 狙い • αタイミングと比較し、より具体的なフィードバックを実施 16
効果想定 • 1.有益性の可視化 ◦ 過去事例から観点を生成しているためフィードバックの納得感が向上 • 2.実行の汎用化 ◦ 観点に沿ったフィードバックを行う事で実行者によるバラツキの緩和 •
3.ネガティブな反応の減少 ◦ QAからのフィードバックが反映されユーザーのネガティブな反応が減少 • 4.コスト減少 ◦ QA期間中の仕様変更量が減少し、開発&QAコスト減少と不具合数減少 17
効果想定 • 現状の注意点 ◦ CS問い合わせ調査数が1タイトルとサンプル数が少ない ▪ ユーザーが本当に求めている物が「タイトル固有の物」か「どのタイトルに もあてはまる汎用的なものか」の切り分けが出来ていない • こちらは調査対象を広げる事で解消される見込み
18
調査を実施しての所感 19
所感 • 『具体→抽象化』の対応が属人的な対応が必要だった ◦ 対策:一度1か月分のお問い合わせで対応し対応方法を確立 • 作業過程の情報を残し、情報を参照できる体制の構築 ◦ 誰でも一連の調査が可能に •
お問い合わせ以外の情報源としてのX(Twitter)調査が、ポスト数が多く大変 ◦ 対策:今見ているポストをcsv化する『ついすぽ』というツールを使用 • 抽出対応の手間を削減し効率的に情報を収集する事が可能に 大変な部分はあったが一定体系化を進める事が出来、複数タイトル調査を実施出来る 目途が立ったため、より説得力を持ったリストが作成できる見込み 20
今後の展開 21
今後の展開 • X(Twitter)調査を実施し情報のアップデート ◦ お問い合わせ調査と同じ、または別の複数タイトルを調査しリスト拡充 ▪ 狙い • より多い生の声、タイトル事例を収集し、ネガティブに繋がるポイント の更なる可視化
• CSお問い合わせ調査の実施タイトルを増やす ◦ 現状調査タイトル数が少ないため、複数タイトルで調査しリスト拡充 ▪ 狙い • 収集する意見・要望の数が増える事でリストの説得力強化 • 複数事例を収集し共通のネガティブに繋がるポイントの可視化 • ジャンルによる違いがあれば、その可視化 22
ご清聴ありがとうございました 23
24