プレイヤーの意見を参考にする際に意識すべきこと
Your audience is good at recognizing problems and bad at solving them.
（受け手は問題を見つけるのは上手いが解決するのは下手である）
https://mtg-jp.com/reading/mm/0017039/
ゲームをつくるとき、プレイテストは必須の工程です。また、運用型のタイトルはプレイヤーの意見を聞きながら、ゲームを改良していくことが重要です。生まれたばかりのゲームが面白いことは極めて稀で、ゲームを面白くするには外部に晒して洗練させる必要があります。
プレイヤーの声を聞くことは開発・運用どちらにおいても重要ですが、プレイヤーの要求を鵜呑みにしてはいけません。プレイヤーの意見はすべて正しいのですが、それと同時にほぼすべて間違っています。
プレイヤーの意見は、以下の4要素に分類することができます。
1：事実
2：感想
3：推論
4：提案
この4つを区別することは、意見を述べる側・聞く側どちらにとっても意外なほど難しく、訓練を要することがあります。例えば以下の意見を見てみましょう。
「1回も勝てずにつまらなかった。課金装備がなくても勝てるようにしてほしい」
事実：「1回も勝てず」
感想：「つまらなかった」
提案：「課金装備がなくても勝てるようにしてほしい」
つまりこの意見は、
推論1：「敗因は課金装備がなかったためだ」
推論2：「課金装備がないと勝てない」
が省略されています。これはまだ簡単な部類です。ターン制のゲームにありがちな意見を見てみましょう。
「先攻が有利すぎるので、ハンデを付けた方がいいと思う」
「ハンデを付けた方がいい」は提案ですが「先攻が有利すぎる」は事実・感想・推論のどれでしょうか？どのような事実があったかを確認してみましょう。
開発者：「なぜ先攻が有利すぎると思ったのですか？」
プレイヤー：「えーっと、先攻側が5勝2敗でした」
確かに71.4%の勝率は有利すぎるように思えます。しかしこれだけでは「先攻が有利すぎる」ことが事実とは言えません。なぜなら成功確率50%の試行を7回行ったとき、5回以上成功する確率は約22.7%あるからです。この確率はExcelのBINOM.DIST 関数や確率計算サイトで計算することができます。
「先攻が有利すぎる」ことは「先攻側が5勝2敗」という事実から導き出された推論（疑い）に過ぎず、事実ではありません。
しかし、そもそもプレイヤーが「先攻が有利すぎる」と申告した理由は、本当に「5勝2敗」だったからなのでしょうか？別の例を見てみましょう。
プレイヤー：「先攻が有利すぎると思う」
開発者：「先攻側は何勝何敗でしたか？」
プレイヤー：「えーっと、先攻側が4勝4敗でした」
「こんなバカは居ない」と思った方も居るかもしれませんが、これが（筆者も含めた）平均的なプレイヤー像です。どちらかが大きく勝ち越しているわけではないのに、どちらかが有利すぎる・不利すぎるという申告はよく見られます（類似の申告に、格闘ゲームなどの相性における「9:1」などの表現があります。ここまで勝率差が開くことはまずありません）。
ここで記事冒頭の"Your audience is good at recognizing problems and bad at solving them."を思い出していただきたいのですが、プレイヤーは何らかの問題を発見している可能性があります。つまり「先攻が有利すぎる」と認識させる何らかの出来事があり、「すぎる」という表現で申告されていることから、ネガティブな体験だった恐れがあります。
プレイヤーにインタビューすることでプレイヤーが体験したことが本当は何だったのか特定することも可能ですが、アンケートやSNSの意見などでは必ずしもインタビュー・ディスカッションをすることはできません。
開発者が認識すべきは、プレイヤーは必ずしも「事実 → 推論」というプロセスを踏まず、「感想」から「推論」を無意識のうちに行い、それを「事実」として申告するケースがあるということです。
プレイヤーに追加の質問ができないとき開発者は、
推論：「先攻が有利すぎる」
感想：（不快感）
事実：（プレイヤーを不快にさせた何らかの事象）
提案：不快要因の調査・除去
という思考のプロセスを踏む必要があります（もちろん、とりあえずほかのプレイヤーの意見を見てみるのも有力な選択です）。
このように開発者は「プレイヤーの申告する事実」や「推論」から、プレイヤーの「感情」を読み取り、プレイヤーが直面した本来の「事実」を推測する必要があります。プレイヤーの意見を信じこみ提案を鵜呑みにしてはいけませんが、プレイヤーの申告した事実が「偽」であることが分かったからと言って、プレイヤーの申告自体を棄却してもいけません。なぜなら、プレイヤーが「ある事実を『真』と感じたという事実」は「真」だからです（つまり、プレイヤーは正しく、かつ間違っています）。
プレイヤーは事実・感想・推論・提案を区別する責任を負っていませんし、正しい事実を述べる責任も負っていません。4要素を区別し、正しい事実・推論から正しい解決策を導き出すのは開発者の責任です。
別の例を見てみましょう。
プレイヤー：「移動速度を上げるべきだ」
これは「提案」に見えますが、実質的には「移動速度が遅すぎたため、不快だった」という感想、あるいは「移動速度があるべき速度より遅いのではないか？」という推論です。
先ほど「4要素を区別し、正しい事実・推論から正しい解決策を導き出すのは開発者の責任」と述べましたが「正しい解決策を導き出す」ためには4要素のあと、
5：ほかの解決策をリストアップする
6：各案の影響範囲・リスク・コストを比較する
必要があります。「顧客が本当に必要だったもの」というネットミームにもあるように、プレイヤーは正しく自分の欲求を表現・認識しているとは限りません。「移動速度を上げる」のではなく「マップを狭くする」「リスポーン地点を変える」などの案も俎上に載せるためには、やはりプレイヤーの感想や事実まで遡って考える必要があります。
最後に余談になりますが、ごく一部のプロジェクトやジャンルでは、プレイテスト専門のスタッフが雇用されていることがあります（デバッグではなく、ゲーム体験の改善のみを目的としたテストです）。
このとき、4要素の区別のどこまでをゲームデザイナーの責任として、どこまでテストプレイヤーの責任とするかは事前にある程度決めておき、テストプレイヤーの区別が不十分だったときはフィードバックを返す方が望ましい可能性があります（テストプレイヤーがインターンであるケースも多いです）。
しかし、フィードバックには本来テストされる側のゲームデザイナーが、試験官を評価するという歪な構造を生んでしまうという副作用があり、ゲームデザイナーの喜ぶ意見が届くようになる危険があります。
さすがに「あなたのゲームは面白い！天才！」などの意見に偏ることは稀だと思いますが「推論」や「提案」に結びつけられた意見のみが提出され、言語化しにくい感想が申告されにくくなるバイアスは発生し得ます。
このようなことを避けるためには、デザインチームとテストチームのコミュニケーションを密にしたり、テストプレイヤーに対する独立した評価者を設定するなどの対応が考えられるでしょう。