プレイテストの極意：Dead CellsとHadesが教える「プレイヤーの声」の聴き方

皆さんこんにちは、ゲームデザインポッドキャストへようこそ。今日は、ゲーム開発で避けて通れない「プレイテスト」について深掘りしていきます。

実は、そこが今日のポイントなんです。友人や家族にプレイしてもらうだけでは、本当に必要なフィードバックは得られないんですよ。

今日は、Dead Cells、Hades、Hollow Knightといった大成功したインディーゲームが実践したプレイテスト手法を7つ紹介します。これを知れば、皆さんのゲームも大きく改善できるはずです。

最初に紹介するのは「Silent Observation」、日本語で言うと「無言観察法」です。これがプレイテストの基本中の基本なんですよ。

その通りです。プレイヤーがゲームをプレイしている間、一切の介入、説明、弁解をしない。ただ黙って観察するんです。

まさにそこなんです。開発者は「説明すれば理解できる」と思いがちですが、リリース後にはプレイヤーに説明できないんですよ。Silent Observationでの失敗は、致命的な設計欠陥を示しているんです。

ポイントは「ゲームをテストしている、あなたをテストしているのではない」とプレイヤーに伝えることです。心理的安全性を確保した上で、30秒以上の停滞、ため息、舌打ち、逆に身を乗り出す瞬間などを記録します。

実は、Portalの開発チームは数百時間のプレイテストビデオを分析して、「説明なしで理解される」まで反復改善したんです。その結果、パズルゲーム史上最高のオンボーディングが生まれました。

次は「Think-Aloud Protocol」、思考発話法です。これはプレイヤーに「今考えていること」を声に出しながらプレイしてもらう手法です。

似ていますが、もっと内面に焦点を当てます。「このアイテムは回復だと思った」「ここにドアがあると思った」といった、プレイヤーの期待値や誤解が可視化されるんです。

驚くべきことに、この手法でモデレート付きセッションを5から8人に実施するだけで、主要なユーザビリティ問題の80から90パーセントを発見できるんです。

はい。ただし注意点があって、声に出しながらプレイすると認知負荷が増えるので、フロー状態の評価には向かないんです。チュートリアルやパズルの検証に特に効果的ですね。

ここが面白いんですが、プレイヤーの「言葉」と「行動」は必ずしも一致しないんです。だから、メトリクス駆動分析が重要になります。

まず「ファネル分析」です。チュートリアル完了率が70パーセント以下なら深刻な問題があります。各ステージでの離脱率に急激なスパイクがあれば、そこに難易度問題がある証拠です。

あと「Rage Click」という指標も面白いです。反応しない要素への連打のことで、これはUI問題を示しています。プレイヤーが「ここクリックできると思ったのに」という無意識の期待ズレですね。

ただし、定量データは「何が起きたか」を示すけど「なぜ起きたか」は示さないんです。だから、必ず定性データと組み合わせる必要があります。

意外なことに、プレイテストは本質的にバイアスまみれなんです。これを知らないと、せっかくのテストが無駄になります。

まず「観察者効果」。開発者が見ていると、プレイヤーは「良いプレイヤー」を演じてしまうんです。本当の反応が見えなくなる。

そして最も厄介なのが「社会的望ましさバイアス」です。プレイヤーは開発者を傷つけたくないから、好意的な回答をしがちなんです。だから友人や家族のフィードバックは信用できない。

対策としては、友人家族の比率を50パーセント以下に抑える、匿名アンケートを使う、そして言葉より行動データを優先する。これが鉄則です。

その通りです。「楽しかった？」ではなく「どこが楽しかった？」「どこで詰まった？」と具体的な体験を問う質問に変えるべきです。誘導しない質問設計が重要なんです。

さて、ここからは実際の成功事例を見ていきましょう。まずはDead Cells。このゲームはEarly Accessのマスタークラスと呼ばれています。

驚くべきことに、30から40パーセントの完成度でSteam Early Accessを開始したんです。コアメカニクス、つまりタイトな操作感と戦闘だけを極限まで磨いた「Core Vertical Slice」を先行公開しました。

ここが重要なポイントです。開発者は「Listen to Problems, Not Solutions」という方針を持っていました。プレイヤーが「問題」を指摘したら真剣に対応する。でも「解決策」の提案は参考程度にする。

プレイヤーは問題発見の天才だけど、解決策提案の素人だからです。彼らは「ここが不満」とは的確に言える。でも「こう直せば良い」は開発者の仕事なんです。

最終製品の40から50パーセントの機能がEarly Accessフィードバック由来でした。18ヶ月の運営後、2023年時点で1000万本超え。インディーRogueliteで最大級の成功を収めたんです。

次はHadesです。このゲームが特別なのは、メカニクスだけでなくナラティブもEarly Accessでテストしたことです。

まさにそこがSupergiant Gamesの挑戦だったんです。彼らは「Sweet Spot」と呼ぶタイミングを重視しました。プレイ可能で楽しめるけど、まだ拡張余地がある状態での公開です。

ここが面白いんですが、Hades 2ではプレイヤーの反応を受けて、エンディングを全面的に書き換えたんです。ナラティブすら「固定」ではなく「反復改善」の対象にしたんですよ。

その結果、Supergiant史上最大・最多機能のゲームになり、Game of the Yearを複数受賞しました。ネタバレ懸念よりも改善効果が上回ったんです。

最後にHollow Knight。このゲームの開発者は、プレイテストを通じて重大な決断を下しました。

コアゲームの難易度を「下げる」決断です。Kickstarter支援者向けのベータテストで、大量の重要フィードバックを収集した結果、開発者の想定より難しすぎることがわかったんです。

その通りです。開発者は自分のゲームを「難しく」感じられない。何百時間もプレイして習熟しすぎているからです。プレイテストなしの難易度調整は不可能と言っても過言ではありません。

1500万本販売、2Dメトロイドヴァニア史上最大級の成功を収めました。少数の熱心なファンからの深いフィードバックが、方向性を定めたんです。

ここで、プレイテストでやりがちな5つの失敗パターンを紹介しましょう。これを知っておくだけで大きな差が出ます。

1つ目は「説明してしまう症候群」。プレイヤーが詰まると「ああ、それはね」と説明したくなる。でもリリース後は説明できない。この衝動を抑えるのが最初の壁です。

手を後ろに組む、別室でモニター観察、録画のみのリモートテスト。物理的に介入できない環境を作るのが効果的です。

2つ目は「友人家族依存症」、3つ目は「浅い質問症候群」。4つ目は「データ無視症候群」で、3人以上が同じ問題を報告したら即座に設計を見直すべきです。

最も危険なのが「遅すぎるテスト症候群」です。リリース直前にプレイテストして致命的問題を発見しても、修正する時間がない。初回体験の失敗はリカバリー不可能なんです。

さて、今日のポイントをまとめましょう。プレイテストは単に「感想を聞く」ことではありません。Silent Observationで説明なしで観察し、Think-Aloudで思考を可視化し、メトリクスで行動を追跡する。

その通りです。そしてDead Cellsが教えてくれた「Listen to Problems, Not Solutions」。プレイヤーは問題発見の天才ですが、解決策は開発者の仕事です。

はい。リリース直前では遅すぎる。Core Vertical Sliceが固まった時点でのEarly Accessも選択肢です。Hades、Dead Cells、Hollow Knightの成功がそれを証明しています。

それでは、また次回のエピソードでお会いしましょう。さようなら。