【ゲームアプリ】クローズドβテスト(CBT)の設計方法(OBTとの違いも比較)

ゲーム開発
スポンサーリンク

【更新版】CBT、OBTより「チューニングテスト」が100倍重要です

こんにちは

マーケティングスペシャリストのトロネコです。

さて今回はスマホゲームに限らずPCオンラインゲームでも避けて通れない必須施策であるCBT(クローズドβテスト)について、その実施目的と役割、設計方法についてお話しします。

そしてCBTとOBT(オープンβテスト)における違いについても解説していきます。

今回、お話しする内容を読めば、CBTのほぼがカバーされているため、明日からCBTマスターになれるかも!?

後半ではCBT、OBTより重要な「チューニングテスト」についても軽く触れます。

CBT(クローズドβテスト)とは何か?

CBTとはスマホゲーム、PCゲームを問わずオンラインゲームのサービス開始前に限られた人数で、実際にプレイしていただきながらテストをすることです。

このテストを行うことで、本番ぶっつけではなく事前に不具合などを察知して、本番サービスでの致命的な問題が発生しないよう未然に防ぐとともに、より良い状態でサービスを提供することができるようになります。

OBT(オープンβテスト)とCBT(クローズドβテスト)の違い比較

一方でOBT(オープンβテスト)というものも存在します。

CBTは選ばれた限られた人数によるβテストである一方、OBTは人数を制限せず、かつユーザーを選別せず実施するため、より実際のサービスに近い状態を再現することができます。

まとめると次のようになります。

CBT(Closed Beta Test) OBT(Open Beta Test)
テスト形態 クローズド オープン
必要人数 少ない(100人程度) 多い(数千人単位)
集客方法 個別でリクルーティング ストアのOBT機能を使ったり、twitterや事前登録ユーザーを対象に集客
実施タイミング タイトル発表前、または配信開始3ヶ月以上前 タイトル発表後、配信予定日から1ヶ月程度前
主な実施目的 離脱ポイントやゲームプレイサイクルにおける課題の収集 配信前提とした完全なる状態での最終チェック。壊れチェック、パラメータチェック

あくまでも一般論ですから、500人でCBTを実施しても構いません。ただし、後ほどお話しますが、実施にあたっての「目的」と「役割」を見失わないようにする必要があります。

CBTとOBTのメリットとデメリット

CBT、OBTともにメリットはサービス開始前に事前テストを実施することで「バグ」「不具合」「未知の問題」「ゲームの面白さ」などを検証することができる点にあります。

一方でデメリットは発売前のゲームゆえに「未完成のゲームを遊ばせることによるネガティブなイメージ」をユーザーに伝えてしまうという点があげられます。

なぜならCBT、OBTに参加してくれるようなユーザーは、そのゲームの熱心なファンであり、実際にゲームが配信開始された後には優良ユーザーになってくれる可能性が高い貴重なユーザーだからです。

そんなユーザーに対して「未完成」のゲームを遊ばせて「がっかり」させてしまうとすれば、そのゲームにとって大きなマイナスになってしまう可能性があります。

一方で熱心な優良ユーザーの声を汲み取り、もっとファンになってもらうこともCBT、OBTの施策設計次第では可能です。このユーザーコミュニケーション次第で

「未完成のゲームでもファンは作れるけど、未完成のゲームでファンを失うこともある」という点を理解した上での実施が必要となります。

まとめると次のようになります。

CBTでも未完成な状況で遊ばせるためネガティブな意見は出ますが、CBTはゲーム会社側が人数を絞って集めたテスターのようなものです。

完全にコントロールできるわけではありませんが、誰でも遊べるような状態で実施するOBTに比べるとネガティブな情報は拡散しにくいとは言えます。

CBT OBT
メリット コストと工数を抑えてざっくりとした課題感の傾向がわかる。 本番サービスにおける配信初動に近い状態でテストができる
デメリット 100人を1箇所で集めて実施が困難でありリモートのテストになるためテストの精度には課題あり 本番サービスの配信初動で遊んでくれる重要顧客が参加する場合が多く、OBTとはいえ不満を与えてしまうと本番サービスに影響が出てくる。OBTの集客方法によってはターゲット外のユーザーが混ざってしまいデータとしての信頼性に欠ける

ここで気がついた人は鋭いかもです。

CBTとOBTの間はちょっとした距離感を感じるかもしれません。CBTでざっくり課題感を見つけて、その最終確認を後戻りができないOBTで一発勝負をかけるのはリスキーな気がしますよね。

しかも、CBT、OBT共にある程度の人数が必要なので(CBTは少人数とはいっても数百人単位です)とするなら、KPIツールとちょっとしたアンケートでしか情報収集ができないということになります。

でも、それだけで課題に対する解決策が見つかるのでしょうか?

実はCBT、OBT共に

「本当の課題を突き止められずに終わってしまうケースが多いのです」

だからCBT、OBTを実施しても結局アプリ開始時における失敗が後を絶たないのです。

今回の記事の最後に話をしていますが「チューニングテスト」というものが、CBTとOBTの間を埋める役割を果たします。

CBT(クローズドβテスト)の目的と役割は?

そんな「ファンをがっかりさせ、ファンを失うリスクと背中あわせの状態」でありながらCBTを実施するからにはCBTの目的と役割をしっかり押さえておく必要があります。

実は目的と役割次第では、CBTを実施する必要がない、もしくは普通に実施するだけではやる意味がない、というケースもあるので注意が必要です。

主なCBTの実施目的と役割は次に集約されます。

もう、今回あげた内容でほとんどカバーされています。

①サーバー負荷テスト

自前でこのゲームのためにゲームサーバー開発しているような会社の場合は、そのサーバープログラムがどれだけのゲームプレイに耐えられるのかテストが必要です。

一方で様々なゲーム開発を行っているような大手ゲーム会社の場合は「サーバー負荷テスト」のためのCBTは実施しない(実施する必要がなく、サーバー障害が発生する可能性は極めて低い)という場合もあります。

数十人や数百人程度のCBTはサーバー負荷テストにならない場合もありますが、その場合は時間を絞って特定の時間帯にアクセスを集中させるなどの対応をする場合があります。

②未知なるバグを発見するため

本来、CBT、OBTはバグチェックを行うためのテストではありません。バグチェックは自社内で全部洗い出してCBTに挑むのが一般的です。

しかし、中には自社でも見つけられないような深いバグが隠れていることもありますし、本番サービスに近い状態でテストをしないと見つからない場合もありますので、CBTやOBTのような本番サービスに近い状態によるテストは「未知なるバグを見つけるためのテスト」としても活用される場合はあります。

ただし一般的にはレアケースでありCBT本来の目的としては不適切です。なぜなら、これから紹介する項目がもっとCBTにいて重要なことだからです。

③ゲームのプレイサイクルがまわるか確認

実際に設計した「ゲームのプレイサイクル」がちゃんとまわって、ユーザーが楽しんでもらえるのか?チェックすることがCBTの主な目的となります。

例えばバトルと育成パートから構成されるゲームがあるならば、その双方のプレサイクルが設計した通りにまわるかCBTではチェックします。

④ゲームの課金がまわるか確認

ゲームのプレイサイクルがまわっても、結果的に「課金されない」ならゲーム事業としては破綻してしまいます。

よってゲームの課金サイクルが設計通りに回るのか?チェックすることもCBTの主な目的になります。課金がまわらない状態でゲーム配信をすると売上があがらず事業として継続できませんし、想定した以上のスピードで課金がまわってしまうことで「課金コンテンツ不足」が事前にわかる可能性もあります。

ただしCBT、OBTでは実際に「課金」することができないため、実は明確にゲームの課金がまわるのかテストを通して確認することは困難です。

あくまでも「まわるか推測できる程度」の結果しか把握することはできません。なぜなら、自分の身銭を削って実際に課金をしないテストでは、本当の意味での課金サイクルがまわるのかチェックできないからです。

どうしても課金がまわるのか不安ならば日本と近い文化とユーザー属性を持つ「台湾」などで先行配信してしまうのも方法として考える必要があります。むしろ課金テストについては海外での先行配信がおすすめです。

(後ほどお話しするチューニングテストで、課金テストの課題を解決できる方法があります)

⑤ユーザーの離脱ポイントを把握し改修するため

スマホゲーム、PCオンラインゲーム問わずゲームをプレイするとどんどん辞めていきます。

そうなんです、オンランゲームはインストールした当日から続々と辞めてしまうゲームなのです。「辞めさせないゲームマーケティング」が重要になります。

CBTではユーザーが辞めてしまうポイントを把握することができます。

・ルールが理解できない

・ゲームが思い

・敵に勝てない

・操作が面倒くさい

やめてしまう理由には様々なものがあります。そんな離脱ポイントをCBTでは把握することができます。配信前に明らかに辞めてしまうような離脱ポイントを把握することで、それを修正し、「辞めさせない状態」でゲーム配信が可能となるのです。

CBT、OBTの目的の大部分はここにあるとトロネコは思っています。

⑥ゲームの面白さが競合タイトルと戦えるかチェックするため

近年、ゲーム市場は完全なるレッドオーシャンです。

既に大人気のゲームが存在しており、新作タイトルを成功させるためには「いま夢中で遊んでいるゲームからユーザーを引き剥がして、我々の新作ゲームをプレイしてもらう」という工程が必要になります。

つまり、ただ新作のゲームが面白いだけでなく

ターゲットユーザーがいま夢中に遊んでいるゲームを辞めてまで、我々の新作ゲームをインストールして遊んでもらう必要があるのです。

そのためにはCBT、OBTを通して「想定している競合タイトル(ベンチマークタイトル)」と真っ向勝負で勝てるだけの「面白さ」があるのか確認する必要があります。

現時点でも十分に面白いゲームであっても、「想定している競合タイトル(ベンチマークタイトル)」に勝てないなら、その新作ゲームの成功は極めて難しくなるからです。

⑦ファンをもっと熱心なファンに育てるため

最後にCBTの目的としてあげられるのは「ファンをもっと熱狂的なファンにするためのプロモーション」としての役割があげられます。

そもそもCBT、OBTをプレイしてくれるようなユーザーはそのゲームに「かなり興味がある状態」といえます。

ですから彼らの声に耳を傾けて、彼らの意見を取り入れて、彼らが満足しながら遊んでもらえるゲームを作り上げ、それを彼らに対してアピールすることは、限られたマーケットボリュームの中で成功を収めるには非常に賢いプロモーションといえます。

このようにプロモーション効果を踏まえた目的としてCBTやOBTを実施するケースも多いのです。

CBTの集客方法によって「ファンをもっと熱狂的なファンにするためのプロモーション」としての役割を見込めるのか変わってきます。CBT参加者はリクルート会社から集めたのか、それとも事前登録の中から選ばれたファン代表なのか?といった違いです。

世の中の9割以上のCBTは価値がなく、間違っているという事実

ここまであげたCBTにおける7つの目的がわかっていれば、無駄なCBTを実施してしまうことはありません。

しかし世の中の9割以上は、CBTの目的を理解しておらず「ただCBTを実施することが目的になっているケース」も多いのです。

「新作ゲームを開発したら配信前にCBT、OBTを実施しなければならない」

という考え方に縛られているケースも多いので注意してください。

CBT、OBTは必ずしも実施しなければならないものではなく、むしろ実施することで「ネガティブな情報がでまわったり」、コストや工数がかかったりする場合もあります。

むしろ「このタイトルではCBTは実施しない」という判断も場合によってはアリなのです。ここを見失わないようにしてください。

CBT(クローズドβテスト)の設計方法

さて、ここからはCBTを実施するための設計方法の流れをご紹介しましょう。ここは設計し始めるとキリがないのでチェックするべき項目だけ今回は説明します。

①CBT実施の目的を決める

②目的を達成するために遊んでもらいたいユーザー属性を決める

③そのユーザーにどの程度(期間と頻度)遊んでもらうことで目的を達成できるのか決める

④目的を達成するために必要なユーザーの集め方を設計する

⑤CBTの結果、どのような対応をするのか事前設計する

たったこれだけです。たったこれだけなのですが、ちゃんと設計できていないケースがほとんどですので注意が必要です。ひとつひとつ説明していきましょう。

①CBT実施の目的を決める

CBTの目的と役割のパートで7つの目的を紹介しましたが、実際のところそれら全部を網羅できるような万能なCBTは設計できません。

よって、この7つの中で多くても2、3つほど選んで頂き、どれを目的にするか決めてください。

今回は例として「ユーザーの離脱ポイントを把握し改修するため」を目的としてピックアップすることにしましょう。

②目的を達成するために遊んでもらいたいユーザー属性を決める

「ユーザーの離脱ポイントを把握し改修するため」を目的にした瞬間に遊んで欲しいユーザー属性も決まります。

このゲームを配信直後から遊んでくれるユーザー(超コアファン)と、その後しばらくしてから遊んでくれるユーザー(ミドルファン)にCBTに参加して頂き、コアとミドルにおける離脱ポイントを明確にしてゲーム内容に反映することにしましょう。

こちらの記事でも書いていますがイノベーター理論に沿って、初期インストールユーザーのペルソナ分析まで、この時点で設計されていると「CBTで遊んでもらうべきユーザーの属性(顔)」が明確にわかるでしょう。

③そのユーザーにどの程度(期間と頻度)遊んでもらうことで目的を達成できるのか決める

さて、遊んで欲しいユーザーの属性(顔)が明確になったら、それらユーザーがどのようにゲームを遊んでくれるのか期間と頻度も見えてくるはずです。

こちらの記事で書いていますが、多くのユーザーはインストール初日で半分辞めて、1週間で7割辞めてしまいます。

つまり、インストールから1週間でどれだけ辞めないようにしてもらうのか?

それがこのゲームの未来を決める初動マーケティングといえそうです。

そうするとCBTは1週間程度は最低限期間は必要ですし、1週間は毎日、本番のサービスに近い状態でログインしてプレイしてもらう必要がありそうですね。

ただCBTを実施するのではなく本番サービスの配信1週間に近い状態を再現したテストが必要ということがすぐに理解できると思います。

④目的を達成するために必要なユーザーの集め方を設計する

さて、今回のCBTでは

このゲームを配信直後から遊んでくれるユーザー(超コアファン)と、その後しばらくしてから遊んでくれるユーザー(ミドルファン)の2種類が必要ということになりました。

実際にこれらユーザーを集めてCBTをプレイしてもらう必要があります。

このゲームを配信直後から遊んでくれるユーザー(超コアファン)は、ほぼゲームの事前登録キャンペーンに応募したユーザーや、現時点でTwitterフォローしているようなユーザーと言えるでしょう。

つまりCBTを実施する時点である程度の事前登録数やTwitterフォロワーが存在している必要がありそうですね。ということはCBT単独の設計ではなく、事前登録施策と連携した上でのCBT実施が必要なことが理解できます。

一方でしばらくしてから遊んでくれるユーザー(ミドルファン)は事前登録はしないけど、ゲーム配信されてから情報を知ればインストールしてくれるようなユーザーといえそうです。

このあたりはペルソナ分析がどこまでできているかにかかっていますが、Twitterのターゲッティング広告など「広告を使った集客」は「しばらくしてから遊んでくれるユーザー(ミドルファン)」のCBT誘導には効果があります。

つまり、

事前登録ユーザー(コアファン)×広告による集客(ミドルファン)

という集客方法の使い分けが必要になります。

ここが理解できていないと、ただ無作為に無駄に適当なユーザーを「CBT人数の数合わせ」として集めることになりますのでCBTとしての本来の目的を見失ってしまいます。

⑤CBTの結果、どのような対応をするのか事前設計する

最後に最も重要なのは、CBTの結果、ゲームアプリやプロモーション、マーケティングなどをどのように対応して反映していくのか設計しておく必要があります。

つまり、反映する気がないCBTは最初からやる必要はありません。それってただの自己満足に過ぎませんし、時間の無駄です。

CBTの結果、配信スケジュールを延期してまで反映して万全の状態で配信する覚悟がある人だけがCBTを実施する権利があるのです。

 

CBT、OBT共に下記のような「目的」「目標」「課題」「戦略」をシートにまとめて整理しておくと、実施の役割が明確になるのでおすすめです。

CBT OBT
目的 離脱ポイントやゲームプレイサイクルにおける課題の収集 配信前提とした完全なる状態での最終チェック、壊れチェック、パラメータチェック
目標 全体的な課題感の把握 本番サービスの模擬試験として初動継続率の最終チェック
課題 ひとりひとりの声に対して踏み込んで聞きにくいため情報が散漫になる KPIツール上でのデータ推移でしか把握できない。個人に踏み込んで分析はできない。またこのタイミングで大きなゲーム改修は困難。1週間実施してもプレイモチベーションが実サービスと同じように担保できないので1日目、2日目程度のKPI数値しか参考にならない
戦略 実際のターゲットユーザーに近いユーザーを課金、非課金、ライト、ミドルなど複数のセグメントでリクルートして実施する 事前登録キャンペーンを並行実施し、アプリ初動でインストールしてくれる特に重要なユーザーによって実施する。ターゲット外のユーザーを無駄に集めない

 

CBTやOBTよりも重要なのはチューニンググテスト

どうしてもCBTやOBTばかりが注目行きがちですが、実はCBTやOBTよりも重要で、かつ効果が見込めるのが「チューニングテスト」です。

チューニングテストというと「パラメーター」や「ゲームバランス調整」のイメージを持たれるかもしれませんが、ここでの「チューニングテスト」は結構違ったことを指しています。

CBTでざっくりとした課題を発見して、チューニングテストで課題の深掘りをして

結果的に開発ビルドに反映して、最終チェックでOBTを行う

といったプロセスを踏むとアプリ配信初動の失敗を高確率で回避することができます。

詳しくは下記の記事で書いていますので、こちらもご覧ください。今回の話以上にこちらの記事の方が価値があると思います。

むしろCBT、OBTをやらないなくても、チューニングテストだけはやるべきです。

 

CBT、OBTをやらずチューニングテストを複数実施するのもあり

最後に「そもそも」的な話をします。

ズバリ、CBT、OBTをやらないという判断もアリです。

配信日から逆算して3ヶ月前にCBT、1ヶ月前にOBTを実施するケースが多いわけですが、ここで何かしら課題が見つかっても

多くの場合は配信日を変更せずに、改修できる範囲の改修しかせずに、配信してしまいます。

配信日を変更するということは会社にとってもビジネス的な影響がありますので、ビジネスが優先される事が多いというわけですね。

中にはCBT、OBTをやった結果、課題が見つかっても、ほぼ改修せずに配信してしまうゲームもあります。

もし、改修せずに配信するなら

CBT、OBTなんてやらなくていいよね。

という話です。

本気でゲームを改善して、良いものを作るなら、もっと以前の段階でCBTを複数回実施して、ゲーム開発に反映することだってできます。

でもCBTって、それ自体が「ネガティブな情報を拡散してしまうリスクあり」という話を冒頭でしました。

 

となると・・・・・

CBT、OBTという発想を全部捨てて、チューニングテストを何回も内部で完全クローズドな形で実施した方が良いという判断もあります。

ちなみにトロネコなら、チューニングテストを内部で何度も実施して、最後の「最終確認としての最終チェック」としてOBTを実施します。

それまでやってきたチューニングテストの最終確認をOBTでやる感じです。

あとはOBTという名前も使いません。

社内的にはそれがOBTとしての役割だとしても、対ユーザー的にはそれは「配信直前の体験版」みたいな見せ方で遊んでもらう感じです。

この辺りはそのタイトルの「マーケティング戦略」にも依存するので、戦略を決めた上で、OBTの役割も決める、といった感じになります。

繰り返しますが

 

CBT、OBTなんてやらなくてもいいんですよ

やる前提で議論している状態は本当にヤバいと思ってください。

なぜなら、そういう現場って、OBT、CBTの結果とか成果が目的ではなくて、

何となくやらなければならない雰囲気の中で、仕事をしているからです。

そんな目的もはっきりしない環境で、流されて仕事をしている状態で、良いゲームなんて作れません。断言します!

まとめ

今回、CBT、OBTについて結構深い話をしてみました。

実際のところもっと深い話なのですが、そこはキリがないので割愛します。

でも今回あげた項目を理解しておけば「大きく間違った価値がないCBT、OBT」を実施するリスクは大きく軽減できます。

最後に今回、ご紹介した内容についてご相談したいことがあればLINEチャットで無料相談できる「トロネコのカベウチ」をお気軽にご利用ください。トロネコがチャットでご相談に乗ります。

もちろんメールでご連絡いただいても結構です。

Contact_US@gamemarketinglab.com

みなさまのお役に立てればトロネコは幸せです。