（株）Aimingの社内勉強会で使われたスライドです。開発中のタイトルの画像は削除してあります。ご了承ください。

1. オンラインゲームと
社内テスト
水島 克 2013.9.11
Aiming Inc.

2. 社内テスト好きですか
Aimingの社内テスト
社内で配布して指定の時間にフリープレイ
東京スタジオでは月に２∼３回の頻度
参加は自由
参加率が高くオープンな良い文化

3. 良い点
デバック会社に頼むより短期で柔軟に開催
社内のプロジェクトについて共有できる
経験ある開発者からも意見がもらえる
後で個別にヒアリングしやすい

4. 悪い点
自由参加なので、何人参加するかわからない
業務の支障になる場合がある
気安さからか進行がグダグダになりがち
説明が不足で結局なんのテストだったのか…

5. 特に、
開発チームと運営担当の情報共有が不十分で
「なんとなくやってるテスト」がある…
改善したい！

6. ゲーム開発のテストとは
旧来のコンソールゲームにおけるテスト
テスト≒デバッグ
テストは主にゲームの完成間近に行われる
もの、という意味合いが強かった

7. ゲーム開発が大規模化／多様化
QA（品質管理）のセクションが独立化
テスト自体をゲーム開発に組み込む傾向
開発のためのテスト

8. オンラインゲームでは
コミュニティがゲームの在り方を規定
少数の人間の評価だけでは把握できない
ためテストが重要

9. テストの重要な側面
ゲームに隠れているの問題点や
未来の可能性を「定量化」
「能力」や「センス」に頼っていた部分を
数値や言葉に置き換え

10. 本日のおはなし
最初はオンラインゲーム開発における
様々なテストについてのはなし
残りは現在開発中のプロジェクトの事例
効果的な社内テストの方法について考える

11. 様々なテストのかたち
社内テスト事例
なぜ社内テストをやるか
本日のメニュー
Chapter 1
Chapter 2
Chapter 3
テストの障害と対策Chapter 4
テスト前のチェックシートChapter 5

12. 様々な
テストのかたち
Chapter 1

13. 開発行程とテスト
Prototype Alpha Beta CBT ver. OBT ver.
フォーカステスト
負荷テスト
自動テスト
実装確認
自動テスト
データロギング
デバッグのためのテスト
互換性 互換性
レベルバランスのテスト
負荷テスト

14. フォーカステスト1
開発中のタイトルに対する目的を絞ったテスト
ゲームのコンセプトや開発中の特定パートが
どのような印象を与えるのかを調査
１ プレイ中の動向を観察
２ プレイ後にインタビューする
３ アンケートを取る

15. フォーカステスト
✓ テスト目的：ゲームの特定のパートが狙いどおりに実
装できているか確認
✓ プレイヤー：一般ユーザー、社内の別チームの人など
✓ テスト方法：１部屋で数人のプレイヤーに遊んでもら
い観察（撮影）する
✓ 必要な結果：プレイヤーが示す反応、受けた印象、コ
メントなど

16. レベルバランスのテスト2
レベルデザインのプロセスの一部
想定する状態（装備／成長レベル／パーティー
人数等）でプレイしてバランスを確認
デザインドキュメントを見る
短期間に修正とフィードバックを繰り返す

17. レベルバランスのテスト
✓ テスト目的：特定のレベルの難易度が想定どおりかど
うか／前回の問題点が反映されているか
✓ プレイヤー：社内のテスター、レベルデザイナー
✓ テスト方法：デザイン側のスコープに合った環境を作
り、テスターにプレイしてもらい観察する
✓ 必要な結果：想定した難易度に収まっているか。想定
した動線や遊び方でプレイされるか。逆に想定外の不
適切なプレイをされないかどうか。

18. データロギングのテスト3
プレイヤーの行動ログを記録。
難易度や動線などを計測
何千回ものプレイの動線を地図やグラフに展開
移動、死亡、戦闘、アイテム使用 etc...
FPS/TPSのAAAタイトルで多く見られる

19. データロギングのテスト
✓ テスト目的：プレイヤーの行動ログを記録しそこから
統計的な偏りを探る
✓ プレイヤー：社内のテスター
✓ テスト方法：ログの記録を行いながらフリープレイ
✓ 必要な結果：できるだけ多数のプレイヤーの行動の傾
向、統計的なデータ

20. 負荷テスト4
オンラインゲームで、サーバ／クライアントプ
ログラムの性能を見るためのテスト
同時接続し、ゲームの進行が円滑か確認
機能別の各サーバに負荷をかける
小規模→大規模に段階的に行う場合が多い

21. 負荷テスト
✓ テスト目的：サーバ／クライアントプログラムの性能
を確認、ボトルネックを探す
✓ プレイヤー：社内・デバッグ会社のテスター、全社員
✓ テスト方法：多くのテスターが同時接続し、同時に同
じ行動をして発生する負荷を検証
✓ 必要な結果：同時接続時のサーバログ、CPU負荷、ク
ライアントのフレームレートなど

22. BOTによる自動テスト5
特にMMOGなどで、簡単なBOTのプレイヤー
キャラクターにプレイさせログを取る
通常プレイでは膨大な時間がかかるゲームの
平均プレイ時間や難易度などを計測

23. BOTによる自動テスト
✓ テスト目的：通常プレイでは時間のかかるプレイを自
動化しログを取り、バランスの参考にする
✓ プレイヤー：BOTプログラム
✓ テスト方法：BOT操作によるプレイヤーキャラを生成
し、24時間無休で自動プレイさせる
✓ 必要な結果：BOTキャラクターのプレイ難易度、プレ
イ時間など

24. 実装確認6
実装完了となったシステムやゲームのデータ、
アートのアセットなどをチェック
仕様書やリソースのリストを参照
「すべてのスキルの組み合わせをすべてのキャ
ラで」といった、総当たり式のテストも

25. 実装確認
✓ テスト目的：プログラムやデータが正しく実装されて
いるか確認
✓ プレイヤー：社内・デバッグ会社のテスター
✓ テスト方法：仕様書やテーブル、アセットのリストな
どに基づいて正常に機能するか確認
✓ 必要な結果：チェック項目のリストと各項目に対する
テスト結果

26. デバッグのためのテスト7
純粋な不具合を発見し、開発チームに修正依頼
するためのテスト
フリープレイ＆怪しい箇所は重点的にプレイ
チケットを発行し、開発チームに報告
再現性の高い報告（不具合が出る条件を特定し
たもの）が望ましい

27. デバッグのためのテスト
✓ テスト目的：ゲームの不具合を発見て修正を依頼し、
ゲームの商品としての完成度を高める
✓ プレイヤー：社内・デバッグ会社のテスター
✓ テスト方法：ゲームをフリープレイ、怪しい部分を重
点的にプレイ
✓ 必要な結果：不具合の再現条件や原因を報告するチケ
ット

28. 機種互換のテスト8
様々な端末でプログラムが「プレイ可能な水
準」を満たしているか確認
スマートフォンの場合、最低スペックと標準ス
ペックの方針（OS・RAMサイズなど）が必要
アクション性のあるゲームの場合、平均で
15fpsを切るようだと厳しい

29. 機種互換のテスト
✓ テスト目的：保証スペックを満たす端末で正常にプレ
イできるかどうかを確認
✓ プレイヤー：社内＆デバッグ会社のテスター
✓ テスト方法：できるだけ多くの端末（特に人気端末）
にインストールしプレイする
✓ 必要な結果：各端末毎の動作確認結果のリスト

30. 開発行程とテスト
Prototype Alpha Beta CBT ver. OBT ver.
フォーカステスト
負荷テスト
自動テスト
実装確認
自動テスト
データロギング
デバッグのためのテスト
互換性 互換性
レベルバランスのテスト
負荷テスト

31. ゲームに隠れているの問題点や
未来の可能性を「定量化」
テスト目的に合わない結果・レポートは
意味をなさない場合が多い

32. 適切なタイミングで
必要なテストを
行うことが肝要

33. プロジェクトＮの
社内テスト事例
Chapter 2

34. プロジェクトＮ 概要
３０中盤∼後半のオッサン中心のチーム
５∼１０人の小規模チーム
スマホのフル３Ｄオンラインゲーム
サーバ・クライアント共に内製
ちょっと新規性あり

35. プロジェクトＮ 概要
これまでに６回のマイルストーン（1.5∼2.5ヶ
月単位）
計５回の社内フォーカステストを実施
そのうち４回はアンケートも実施
ゲームはまだ未発表…

36. Nのマイルストーン
Prototype Prototype2 Alpha Beta1 Beta2
テスト１
テスト２
テスト３
テスト４
テスト５
アンケート１
アンケート２
アンケート３
アンケート４
Alpha2

37. テストの目的
Prototype Alpha Beta CBT ver. OBT ver.
フォーカステスト
負荷テスト
自動テスト
実装確認
自動テスト
データロギング
デバッグのためのテスト
互換性 互換性
レベルバランスのテスト
負荷テスト
互換性

38. プロトタイプ版1
基本的な操作性／画面イ
メージ／ヒット感／戦術
を試すもの
最初のサンプル版
オフラインのみ

39. プロトタイプ版
✓ 個別に１人ずつ呼んでテスト
✓ ゲームデザイナ（水島１人）がプレイをじっと見る
✓ テスターは全部で１０人くらい（企画の人中心）
✓ プレイ後、各テスターにインタビュー
✓ アンケートは無し
テスト方法 フォーカステスト

40. プロトタイプ２版2
プリプロ版をマルチプレ
イで遊べるもの
複数人で遊んだ時のプレ
イ感を検証

41. プロトタイプ２版
✓ 個別に３人ずつ呼んでソロ＆マルチテスト
✓ ゲームデザイナがじっと見る
（東京20人＋大阪21人）
✓ テスターは運営のスタッフを中心に選出して依頼
✓ 各テスターにインタビュー＆アンケートもらう
テスト方法 フォーカステスト

42. アンケート形式
google docsの
アンケート機能
訊きたい項目別に
５段階で評価
項目に対する
コメント欄

43. プロトタイプ２版
スコア
項目 とてもよい よい ふつう いまひとつ よくない
第一印象 14% 62% 19% 5% 0%
ゲームデザイン 5% 38% 40% 14% 0%
ビジュアル／演
出／世界観
12% 38% 33% 17% 0%
操作性／UI 5% 29% 29% 38% 0%
レベルデザイン 7% 21% 57% 12% 2%
コンセプト／新
規性／将来性
17% 43% 33% 7% 0%
※４１人が回答

44. アルファ版3
複数のマップが遊べる
スキルシステムを追加
遊びの基礎を補強
ソロ∼マルチへの序盤の
流れを作る

45. アルファ版
✓ 個別に３人ずつ呼んでソロ＆マルチテスト
✓ ゲームデザイナがじっと見る（１７人）
✓ テスターを選出して依頼
✓ 各テスターにインタビュー＆アンケートもらう
✓ アンケート項目を最小限に絞り固定化
テスト方法 フォーカステスト

46. アルファ版
スコア
項目 とてもよい よい ふつう いまひとつ よくない
スキル 0% 65% 18% 12% 6%
UI／操作性 0%(5%) 29%(29%) 29%(29%) 41%(38%) 0%(0%)
レベルデザ
イン
18%(7%) 0%(21%) 47%(57%) 24%(12%) 12%(2%)
コンセプト
／将来性
6%(17%) 65%(43%) 18%(33%) 12%(7%) 0%(0%)
※１７人が回答。 ()内は前回の結果

47. ベータ１版4
チュートリアルを入れ
序盤の流れを構成
プレイ評価システム
基礎的なコミュニティの
機能

48. ベータ１版
✓ 個別に１０人ずつ呼んでソロ＆マルチテスト
✓ ゲームデザイナ（３人）がじっと見る
✓ 各テスターは東京スタジオで公募（35人くらい）
✓ アンケートもらう（東京スタジオ27人）
✓ アンケートに端末機種と不具合報告を追加
テスト方法 フォーカステスト
互換性

49. ベータ１版
スコア
項目 とてもよい よい ふつう いまひとつ よくない
スキル 4% (0%) 74% (65%) 15% (18%) 7% (12%) 0% (6%)
UI／操作性 7% (0%) 22% (29%) 33% (29%) 26% (41%) 11% (0%)
レベルデザ
イン
4% (18%) 30% (0%) 52% (47%) 15% (24%) 0% (12%)
コンセプト
／将来性
37% (6%) 41% (65%) 15% (18%) 7% (12%) 0% (0%)
※２７人が回答。()内は前回の結果

50. ベータ２版5
ステージ選択画面など
UI周りの強化
１時間程度のプレイボリ
ューム
アイテムを入手しプレイ
ヤーが成長する流れ

51. ベータ２版
✓ はじめての全社テスト
✓ 参加希望者が同じタイミングで一斉にテスト
（東京＋大阪で全部で６０人くらい）
✓ 同時プレイの負荷テスト
✓ 不具合端末などの報告を受付
✓ 各テスターからアンケートもらう
テスト方法 フォーカステスト
互換性 負荷テスト

52. ベータ２版
スコア
項目 とてもよい よい ふつう いまひとつ よくない
スキル 6% (4%) 33% (74%) 21% (15%) 30% (7%) 9% (0%)
UI／操作性 0% (7%) 9% (22%) 27% (33%) 48% (26%) 15% (11%)
レベルデザ
イン
9% (4%) 15% (30%) 42% (52%) 24% (15%) 9% (0%)
コンセプト
／将来性
15% (37%) 36% (41%) 27% (15%) 18% (7%) 3% (0%)
※３３人が回答。()内は前回の結果

53. Ｎのテストのポイント
開発の初期段階から何度も見せる
テストの規模は開発段階に応じて大きくする
テスト結果をオープンに（チームwikiに貼る）
アンケートを集計しコメントは細かく読む
「将来性あるか？」をストレートに聞く

54. なぜ社内テストを
やるのか
Chapter 3

55. この章はプロジェクトＮで
社内テストを何度かやっての個人的な感想
基本スタンス
ゲーム開発は主観的で属人的な行為
多数決ゲームが作りたいわけではない
テスト結果をどう使うか？

56. 問題点を特定する
開発中のゲームの潜在的な問題を知る
アンケートで書かれた意見から問題を推察
例）「カメラを動かしたい！」
本当の問題は必要な要素が画面内
に収まっていないこと？

57. プレイヤーの動向を知る
プレイヤーの視点でゲームを再確認できる
ゲームのどこに注目し、どこに注目しないか
例）大きな文字のメッセージを読まない
例）驚くほど簡単な場所でつまづく
全体を把握しない視点が重要

58. 作業優先度の参考に
やりたいことは山のようにあるが、予算や
開発期間の都合でできることは一部だけ
開発の順番・優先度の参考にする
意見を参考に主観的に判断

59. 会社との共通認識
CxOな人々（社長など）が安心できる
このゲームが「もういけそう」なのか
「まだいまいち」なのかざっくり共有
ゲームの「強い点」と「弱い点」を明確
化し、会社と目標を共有

60. 開発チームの本音
「完璧にできてから人に見せたい」
「不当に評価されるのが怖い」
いつかは評価される。テストは
早いほうが行動の選択肢が増える
テスト結果はあくまで参考に

61. テストの
障害と対策
Chapter 4

62. 4.1
開発チーム側の
問題

63. 情報の共有不足
文化的な問題：オープンになれない
「評価されるのが怖い」心理
サービス直前に社内テストをして
問題が出てもすぐには直せない
テストでハッキリ評価を受けたほうがいい

64. 開発の目標設定
マイルストーンの目標設定が分かりにくい
→どんなテスト結果が要るのか分からない
目的設定をイメージしやすいものに
× 移動、エンカウント、スキル、敵を殺せる、および戦闘のUI
○ 戦闘のプレイ感覚と操作感、特に「爽快感」を具現

65. 遊べるバージョンが無い
日常的に遊べるバージョンが無いと起こる問題
例）運営「触らせてもらえません？」
開発「いま遊べないんだよねー（ずっと）」
例）社内テストの前日の深夜にリリース → 運営担当者が触ら
ないままテスト開始
不十分なバージョンでも日常的に
見せたほうがいい

66. 4.2
開発∼運営の
距離感

67. 企画／運営の切り分け
ソーシャル／スマホネイティブの傾向
イベント中心のゲームが主流
開発と運営とプロモーションは一体
「開発チームが作ったものを運営に渡してサー
ビスしてもらう」みたいな発想は捨てる

68. 担当者間の対話不足
運営担当者が開発の後半に合流することが多い
テストの目的が共有されていない
× 作るだけ作って「あとはヨロシク」の企画担当者
× 仕事を「やらされて」いて無関心な運営担当者
メンバー全員が積極的に関われる環境づくり

69. 社内テスト前の
チェック項目
Chapter 5

70. チェックリスト
✓ ゲームの最終形はどういう形？
✓ 今回のマイルストーンは何が目標？
✓ どんな目的のテスト？（複数）
✓ どういう規模で誰を対象に行う？

71. アンケートを作ろう
開発チーム内で評価ポイントをヒアリング
プログラム、アート、企画でポイントが
異なる
そのバージョンで最もフォーカスするべき部分
をピックアップ

72. まとめ

73. 社内テストは会社の良い文化。
適切なフィードバックをすることで
ゲームがより早期により良くなる
社内テストをうまく
活用しましょう！