デベロッパ向けにBaaSや分析サービスを提供するChilliConnectの代表取締役Mike Herron氏がソフトローンチに際して把握しておくべき重要なポイントについて概説する。

　潜在的な見返りは大きいのだが，デベロッパやパブリッシャにとってモバイルゲーム分野を攻めることは依然として困難を伴う。飽和状態のアプリストアと高いUA（ユーザー獲得）コストは，ソフトローンチ（徐々に発売枠を広げていく手法）を成功させることがこれまで以上に重要であることを意味する。よく練られたソフトローンチを，次のゲーム開発や投資家への売り込みにマーケティング予算を投じる前に実行すると，そのゲームがちゃんと動くのか，プレイヤーを巻き込むことができるのか，そして最も重要なポイントとして，そもそも商業的に成り立つのかどうかを教えてくれる。これらはモバイルにとくに当てはまると言える。F2Pの無慈悲なエコノミクスでは，ソフトローンチ中に顧客獲得単価がゲームの売上高よりも低いと証明できない場合，その後も，そのゲームは利益を上げないことを意味するのだ。

　これにもかかわらず，デベロッパがタイトルを形にする前に時間も資金も切れて，ソフトローンチがうまく行かないのはもはや周知の事実だ。予定よりも大幅に期間が延びてしまうと，ソフトローンチ期間中に市場が動いてトレンドが変わってしまい，お金をドブに捨てるようなケースもある。

　新しいIPで初めてのソフトローンチを準備している場合でも，または，単に次のゲームのプロセスを改善する機会を探している場合でも，ソフトローンチにあたって避けるように注意すべき三つの大きな落とし穴を挙げてみよう。

間違ったテリトリーを選択している

　次のソフトローンチのために利用するテリトリーは，最初は明らかかもしれない。また，デベロッパが引き寄せられがちな，明文化された選択肢がいくつかある。ただし，引き金を引いてUAへの支出を開始する前に，達成しようとしていることについてまず考えてみよう。

　テリトリーの選択は，主にソフトローンチのフェーズにおける，ある一定の期間にテストしようとしているものに基づいて行われる。大まかに言って，ソフトローンチで検証すべきキーポイントは三つだ。

技術的に機能するか

　ゲームが，ターゲットとしたプラットフォームで成功裏に動作すること，また，オンラインやマルチプレイヤーのゲームでは，そのゲームが必要なだけの同時プレイヤー数を処理できるかを把握する必要がある。これらのタイプのテストで重要なのはプレイヤーのクオリティではなく，数だ。また，なるべくコスト効率よく，大人数のプレイヤーを確保するために，（インストールごとのコストの）CPIが低い地域を探す必要がある。インドネシア，フィリピン，タイはCPIが低い一般的な選択肢で，一般的に1ドル以下だ。

WBとNetherRealmは「Injustice 2」のソフトローンチにフィリピンを選んだ

プレイヤーを引きつけることができるか

　コアループが楽しく，プレイヤーが定期的にゲームに戻っていくようにすることが不可欠だ。通常，この段階での主な関心事はリテンション（維持・保持）とエンゲージメント（引きつけ）になる。プレイヤーがコアなメカニック部分とどのようにインタラクトしているか，人気がある部分，ない部分，プレイヤーがどのくらい滞在するか。売上に関する指標よりもそれらの点にフォーカスすべきだろう。技術テストの場合と同様に，CPIが低い地域における多数かつ低コストのプレイヤーでもってこれらの指標を検証することはできる。

商業的に成り立つか

　ゲームの経済とマネタイゼーションは効果的で収益性が高く，グローバルなローンチで販売されることを正当化できるようなものではなくてはならない。その時点までに，楽しくて，熱中できるゲームであることを証明し，ゲームの収益性，すなわち，どれだけのプレイヤーがお金を払ってくれるプレイヤーになるのか，どのステージでそうなるのか，どれだけ払ってくれるのか，そういったことを計測し，リファインできているはずだ。商用化テストでは，グローバルでのローンチと類似したKPIを収集したいので，最終的にターゲットとなる市場と経済的に似ているテリトリーを選択することが重要だ。例えばオーストラリア，ニュージーランド，カナダは一般的な選択肢と言える。

　多くの場合，一度にさまざまなテストを組み合わせて実行する可能性が高いため，ソフトローンチの進行に合わせてプレイヤーの配分を調整すべきだ。ただし，ゲームが安定してバグがなくなる前にCPIの高い地域を選択すると，初期のビルドではバグが発見されてプレイヤーの解約率やネガティブなストアレビューが増加し，逆にコストが高くつく可能性がある。よって，ソフトローンチのタイミングと場所を注意深く選ぶことが大事なのだ。

十分なデータを収集していない

　すべての開発者はオープンな考え方でソフトローンチに臨むべきだろう。正しいと思うものがエンドプレイヤーに受ける保証はない。どのようなソフトローンチの場合でも，個人的な偏見は取り除き，データだけで機能しているものとそうでないものを判断することが不可欠だ。

　肝要なのは，プレイヤーをゲームに参加させる「前」により良い意思決定を下すための情報を収集することである。ほとんどの分析ツールは，リテンション，MAU，ARPDAUなどの一般的なKPIを提供するが，ほかにも以下のような重要な質問に答えるのに役立つ多くのゲーム固有の指標もある；

FTUE（first-time user experience - 初めてのプレイヤーのエクスペリエンス）の「じょうご」

　あなたの読み通りに，最初に何回のセッションが進行しているか？　プレイヤーはチュートリアルに沿ってプレイしているか？ゲームのコア・メカニクスにピタリと合うのに十分な長さのプレイをしているか？

プレイヤーの進捗

　どのくらいの速さでプレイヤーはゲームを進めているか？　通貨を早く稼ぎすぎたり，レベル完遂が速すぎて退屈したりしているか，あるいは予期せぬ早期の段階で窮地に陥ってイライラした挙句にやめてしまっていないか？

購入のコンテキスト

　プレイヤーは最初に購入した後に具体的にどのような行動をとったか？　コンバートする前にプレイヤーはどのくらいまで進んだか？　コンバージョンまでの平均時間はどのくらいか？

　目標は，貧弱なKPIの潜在的な原因を特定するとともに，実際のKPI自体を測定することだ。例えば，30日のリテンションが悪いことが分かっている場合，その理由を適確に推測するためにプレイヤーの行動に関する情報が十分にあることが重要なのだ。そうすればゲームに適切な変更を加えることができる。

　適切なデータを収集していることを確認するだけでなく，必要な回答をすばやく得るために，データ分析計画も綿密に立てておく必要がある。ただ，異なる分析プラットフォームでは分析方法が異なり，ソフトローンチの準備の一環として開発ビルドのデータを使用し，ライブデータの場合と同じように解析する必要がある。これにより，ゲームローンチされてから突然，重要な情報が不足していることに気づいてしまい，新しいビルドを配布しなければならなくなり，すでにゲームを離れたプレイヤーを引き戻すのに無駄な資金を使ってしまうなどということはなくなる。

迅速に反復できない

　構築，測定，学習のループは，「The Lean Startup」という本で人気を博した製品開発の原則だ。この本は製品開発の主要コンポーネントとして反復のスピードを重視する。構築，測定，学習のループを使用する場合，目標はMVPをできるだけ早く市場にリリースし，パフォーマンスを測定し，その後，プレイヤーデータに基づいてその製品を更新し，ループを必要に応じた頻繁で繰り返すことだ。この原則はゲーム開発に固有のものではないが，デベロッパが新しいタイトルをソフトローンチするときには依るべき考え方と言える。

　多くのチームが一定の予算内または時間内でソフトローンチを行っているものだ。だから，ゲームの更新や変更を迅速に行うほど（つまり，構築，測定，学習のループを1回繰り返すこと），より多くの情報を収集できる。それにより，プレイヤーについてもっと学ぶことができる上，その反復のたびにゲームは改善されていく。多くの場合，具体的にどのような変更がKPIの最大のスイングを引き起こすのかは明らかではないので，できるだけ反復する回数を多く取ることが肝要だ。

　これを迅速に実行できるようにするには，ソフトローンチの前に，新しいビルドを再配布するのではなく，サーバー側の更新を通じてゲームのなるべく多くをリモートで変更できるようにしたほうがいい。サーバーの更新によって変更できるものには次のものがある。

購入価格

　プレイヤーに表示されるアイテム，各アイテムの価格，説明を変更する。

経済的なバランス

　ゲームの通貨価値，ソフト購入価格，ゲーム内報酬，クールダウン・タイマーから始めよう。

一般的なゲーム設定

　ゲームの難度，社会的なプロンプトの位置と頻度，ゲーム広告の頻度，UIプロンプトとメッセージ


　理想的には，アップデートを提供するために使用しているサーバープラットフォームは，同時に複数のプレイヤーのグループで異なるバリエーションの修正・変更を見るA / Bテストの実行もできるようにしておく必要がある。これは，プレイヤーのグループで複数の修正・変更を並行して実行することで，獲得したプレイヤーをより効率的に利用するのに役立つ。例えば，2種類のゲームエコノミーを試してみよう。一つはゲーム内アイテムのコストを2倍にし，もう一つでは半分にし，その変更がどのようにKPIに影響を与えるかを確認してみるということだ。

　もちろん，新しいビルドを再配布してバグを修正し，より大きな機能を追加したり削除したりする必要があるが，リモートで行うことができる変更が多くなればなるほど，ソフトローンチ期間中により速く反復できるようになる。

　Mike Herron氏は，デベロッパとパブリッシャのためのオールインワンの「Live-ops」（プレイヤーデータの分析，コミュニティの育成とそこへの対応，ゲーム内でイベントを行っていくことなど）のプラットフォームであるChilliconnectの共同創設者兼代表取締役だ。ChilliConnectは，ゲームのバックエンドサービス，使いやすい分析ツール，強力な「Live-ops」ツールを一つのSDKに統合し，デベロッパがより早くソフトローンチを開始し，早く反復できるようサポートしている。