game-demo-feedback-triage

ゲームデモのフィードバックのトリアージ

このスキルを使って、まとまりのないフィードバック一式を、簡潔で重み付けされたゲームフィードバック概要にまとめます。

目標は、すべての意見を要約することではありません。確度の高い、プレイヤーに影響する最優先の阻害要因を特定し、代表的な兆候とノイズの多い個別の意見を切り分け、次のビルド、プレイテスト、フェス、またはリリースの節目までにチームが作成すべき次の成果物を1つだけ提案することです。

境界事例を分類するときや、ストア／デモ、UX、安定性、パフォーマンスに関する兆候が混在しているときは、references/feedback-buckets.md を読んでください。

このスキルを使う場面

• 社内プレイテストのメモ、アンケート回答、バグ一覧、フィードバック資料の優先順位付けが必要なとき
• Steam Playtest、Next Fest、クリエイター、またはストリーマーによるデモの反応を、優先順位付きの修正概要にまとめる必要があるとき
• 定性的な証拠と技術的な証拠が混在しており、次のビルドまでに何が重要か判断する必要があるとき
• フィードバックがオンボーディング、分かりやすさ、難易度、操作、パフォーマンス、安定性、またはコンバージョンに関わり、部門横断での見解が必要なとき
• 大規模なプロダクトレポートではなく、簡潔な実施可否または最優先の修正に関する提案が必要な小規模スタジオ

このスキルを使わない場面

• 主な問題が、より広範なフィードバック一式を伴わない生のビルド／ログの不具合 → game-build-log-triage を推奨します
• 主な問題が明らかにパフォーマンス計測とボトルネックの診断 → game-performance-profiler を推奨します
• プレイヤーのフィードバックがまだない段階で、ストアページやローンチページの監査が必要 → steam-store-launch-ops を推奨します
• ユーザーがゲーム固有のフィードバックの証拠を伴わない一般的なスプリント計画を求めている → task-planning または bmad-gds を推奨します

手順

ステップ 1：フィードバック一式にラベルを付ける

優先順位を決める前に、最低限の情報を記録します。

以下を記録します。

• 情報源の構成：社内プレイテスト | Steam Playtest | クリエイター／ストリーマー | QA パス | アンケート／フォーム | Discord／コミュニティ | 混合
• ビルド段階：プロトタイプ | バーティカルスライス | デモ | 配信予定 | フェス向けデモ | リリース候補 | リリース後
• 対象ユーザーとの適合度：ターゲットプレイヤー | 好意的なテスター | 幅広いユーザー | 不明
• 証拠の種類：引用、課題リスト、動画／クリップ、アンケート集計、ウィッシュリスト／状況に関するメモ、パフォーマンス／ログの分析結果
• 目標の制約：次回のプレイテスト | Next Fest | クリエイター向けの節目 | リリース日 | 不明
• 既知の重大度を示す兆候：重大な阻害要因、離脱／直帰、混乱、低いコンバージョン、クラッシュ、引っかかり、否定的な感情

フィードバック一式が乏しい場合や、個別の意見に大きく偏っている場合は、確度を低く保ち、その旨を明記してください。

ステップ 2：フィードバックを主要な分類群にまとめる

以下の分類を使い、リストを簡潔に保ちます。

主要な分類

• onboarding-comprehension
• core-loop-fun-clarity
• difficulty-balance-progression
• controls-ui-readability
• stability-performance
• content-polish-scope
• store-demo-conversion-message
• unknown-needs-better-evidence

一般的な対応例

• 「プレイヤーが何をすればよいか分からない」→ onboarding-comprehension
• 「操作方法は理解しているが、10 分もすると興味を失う」→ core-loop-fun-clarity
• 「デモが理不尽に感じる／テンポが悪い／リソース経済が崩れているように感じる」→ difficulty-balance-progression
• 「メニュー、HUD、チュートリアルのプロンプト、またはコントローラーの操作感にストレスを感じる」→ controls-ui-readability
• 「クラッシュ、引っかかり、Steam Deck の問題、またはカクつきについて言及されている」→ stability-performance
• 「ビルドはおおむね問題ないが、粗い部分や演出の不足が印象を弱めている」→ content-polish-scope
• 「プレイヤー／視聴者がゲームの魅力や、デモ／ストアでの訴求に納得していない」→ store-demo-conversion-message

すべての課題を「バグ」や「フィードバック」にひとまとめにしないでください。プレイヤーの理解、楽しさ、仕上がり、安定性、コンバージョンを区別してください。

Step 3: ランキングの前にシグナルの重み付けを行う

各バケットについて、次の4つの観点から証拠を評価します。

1. 頻度 — テスターや情報源の間で、どのくらい頻繁に挙がりましたか？
2. 深刻度 — 理解、継続、リリースへの信頼を妨げますか？
3. 代表性 — 対象プレイヤーからの意見ですか、それとも偏った層からの意見ですか？
4. タイミングリスク — 対応を見送ると、次のイベント、デモの見せ場、リリースに悪影響がありますか？

次に、各項目を以下のいずれかに分類します。

• fix-before-next-build
• watch-next-test
• do-not-overreact-yet

一つの大きな声のコメントが、自動的に最優先事項になるわけではありません。

Step 4: フィードバックブリーフを作成する

次の正確な構成で簡潔なレポートを返します。

# Game Demo Feedback Brief

## Scope
- Source mix: ...
- Build stage: ...
- Audience fit: ...
- Target constraint: ...
- Confidence: high | medium | low

## Highest-confidence signals
- 2-4 bullets on what the evidence most strongly suggests

## Priority buckets
| Bucket | Why it matters now | Evidence weight | Action |
|--------|---------------------|-----------------|--------|
| ... | ... | high / medium / low | fix-before-next-build / watch-next-test / do-not-overreact-yet |

## Top 3 fixes before the next beat
1. ...
2. ...
3. ...

## Issues to watch, not overreact to
- ...
- ...

## Evidence gaps
- ...
- ...

## Recommended next artifact
- Choose one: onboarding fix brief | demo polish checklist | creator-feedback summary | store/demo message update | performance follow-up brief | bug bash list | next playtest plan

## What not to do yet
- 1-3 bullets that prevent noisy backlog churn or premature redesigns

Step 5: リクエストの種類に合わせてブリーフを調整する

内部プレイテストの場合：

• 長期的な磨き込みより、理解しやすさ、楽しさ、進行を優先します
• チームが把握している問題と、新規プレイヤーが実際に戸惑った点を分けます

Steam Playtest／Next Fest／一般公開デモのフィードバックの場合：

• 評判へのリスクをより重視します
• デモの品質を損なう阻害要因と、ストアページやトラフィックの問題を区別します
• 次に取るべき最善策が、デモの修正、メッセージの修正、タイミングの判断のどれかを明示します

クリエイター／ストリーマーからのフィードバックの場合：

• 初回プレイ時の分かりやすさ、読みやすさ、見せ場、プレイが視聴や共有に適さなくなる箇所に注目します
• 視聴者向けメッセージの問題と、システムの深い部分に関するバランスの不満を分けます

バグ＋パフォーマンス＋UXが混在するフィードバックの場合：

• stability-performance はバケットとして使い、結論全体をそれだけにしないでください
• 詳細なプロファイリングが必要な場合は、次の成果物として game-performance-profiler を推奨し、その結果をブリーフに反映します

Step 6: 必要に応じて、不足している最小限の証拠を求める

確信度が低い場合は、トリアージの精度を実質的に高められる最小限の追加情報を求めます。

1. 代表的なフィードバックの引用または問題点を5～10件
2. テスターが対象プレイヤーか、協力的な関係者／社内テスターか
3. 現在のビルド段階と次の外部マイルストーン
4. クラッシュ／パフォーマンスの傾向や、特定のデバイスに関する苦情
5. プレイヤーが離脱した箇所、戸惑った箇所、興味を失った箇所についての短い要約

長大な事後分析は求めないでください。

出力形式

長いデザイン論ではなく、常に短いトリアージブリーフを返します。

必須要件：

• プレイヤーに最も大きく影響する阻害要因を、最初に優先して示します
• 代表的な傾向と、逸話的な例外を分けます
• ユーザーから追加を求められない限り、レポートはおおむね350～550語未満に収めます
• 並行する作業を10件提案するのではなく、次の成果物を1つ推奨します
• 一般公開に関わる場面では、リリース／フェスティバルのタイミングリスクを明示します

例

例1：Next Festデモでの混乱

入力

Next Festデモで小規模なプレイテストを実施しました。大半の人は操作感に問題はないと言っていましたが、多くのテスターが最初の10分で迷い、ストリーマーの中にはゲームの本当の魅力が分からないと言う人もいました。Steam Deckでカクつくという声も少しありました。

出力の概要

• 主なバケット：onboarding-comprehension
• 副次的なバケット：store-demo-conversion-message と stability-performance
• 上位3件の修正では、序盤の分かりやすさ、初回プレイ時の道案内、全面的な作り直しではなくSteam Deckに絞った追加調査を優先します
• 推奨する次の成果物：onboarding fix brief

例2：クリエイターへのアプローチ前にまとめた社内メモ

入力

デモをクリエイターに送る前に、このプレイテストのメモを優先順位付けしてください。バグ一覧は長いですが、実際の傾向としては、プレイヤーは戦闘を気に入る一方で、メニューで離脱しているようです。

出力の概要

• 最も確度の高いシグナル：コアループは好評ですが、メニュー／操作／視認性の問題がプレイ継続を妨げています
• 優先アクション：発生頻度の低いバグを磨き込む前に、操作上の負担が大きいメニュー／HUDの視認性の問題を修正します
• 推奨する次の成果物：demo polish checklist または creator-feedback summary

例 3：ストアとデモの混乱を伴う厳しいフィードバック

入力

Steam Playtestの登録数はまずまずですが、プレイヤーはチュートリアル後に離脱するか、ページやトレーラーから想像していたゲームとは違ったと言います。まず何を修正すべきでしょうか？

出力の概要

• 分類：onboarding-comprehension と store-demo-conversion-message
• ブリーフでは、期待値の設定とゲームプレイのオンボーディングを区別します
• 次に作成する成果物の推奨：store/demo message update または onboarding fix brief
• まだ行わないこと：問題を大まかなスコープ拡大の中に埋もれさせないでください

ベストプラクティス

1. フィードバックは投票ではなく証拠として扱う — 声の大きい逸話より、代表的な阻害要因を優先します。
2. 理解度、楽しさ、安定性を切り分ける — それぞれ異なる次の成果物につながります。
3. 次の対外的な節目を見える状態にしておく — Next Fest、クリエイターへの働きかけ、ローンチ時期によって優先度が変わります。
4. 短い優先事項ブリーフを1つ使う — あらゆる問題を一度にチームへ大量に提示するのは避けます。
5. 必要に応じて技術的な詳細調査を別の担当へ回す — 詳細なプロファイリングや生ログのトリアージは、専門スキルの領域です。
6. バックログを頻繁な変更から守る — すぐに修正するのではなく、次回テストで確認する問題として印を付けます。

参考資料

• Steam Playtest
• Steam Next Fest - ヒント
• ストアページの作成と編集
• ベストプラクティス：より良いプレイテストのための5つのヒント
• インディー開発者向け、プレイテストプロセスを成功させる6つのステップ
• フィードバックテストでゲームの意思決定を改善する
• 効率的なゲームテストの方法