モバイルゲーム運営のリスクとなる障害対策のすゝめ

# はじめに
モバイルゲーム運営でリリース後の不具合(以降、障害と呼びます)の対策は大きな課題です。
本記事では、さまざまな障害事例とその対策を検討した内容をまとめてみました。
事例自体はSNSやWeb上の情報などをベースにこういうのもありそうだなというものを想像で記載しています。
サービスを提供する組織としてリスクが高いと考えられる障害をピックアップしてみましたので、同じような障害の対策に悩んでいる方の参考になれば幸いです。


# モバイルゲームでリスクとなる障害と対策
モバイルゲームでよく見られる高リスク障害は以下のようなものがあります。

**1. ガチャの誤表記、設定ミス
2. ショップ販売物の設定ミス
3. ランキングイベントの不備**

これらの障害が発生するとお客さまにとって大きな不利益につながりやすく、運営会社も慎重な対応が求められます。
内容によっては、会社の信頼失墜や、大規模な補填、さらにはサービス継続に対して大きな影響を与えることもあります。
## 1.ガチャの誤表記、設定ミス
ゲーム内のお知らせやSNSなどで商品を宣伝されることが多く、お客さまはその情報をもとに購入を検討されます。
主な販売経路としては「ガチャ」「ショップ」などがあります。
有償販売物周りは、お客さまの金銭的な不利益に直結するので何か問題があるとリスクが大きくなります。
まずは「ガチャ」の障害事例を2点説明します。
### 障害事例①ガチャの提供割合表示が実態と異なる

|項目|説明|
|:--|:--|
|詳細|提供割合に記載のないアイテムが排出された|
|対応|対象のガチャを一時停止。期間内にガチャを回したお客さまに使用したガチャ石を返却し、全体にお詫びを配布。|
|対策|[開発に依頼すること] <br> ・提供割合の表記内容を、ガチャの設定値から引用する仕組みの導入 <br> ・ガチャの設定値を元にしたシミュレータの実装 <br> [QAで対応すること] <br> ・表記と仕様の整合チェックを導入 <br> ・シミュレータを規定回数実施し、結果が問題ない範囲におさまっているか確認|

お知らせの画像や文言は、より良い表現を検討したいという気持ちから、場合によっては設定がリリース直前になることもあります。
可能であればミスが入り込まないように、設定された値を元にお知らせ文言の一部を自動生成するツールを導入したり、ミスが入り込んでしまったとしても検知できるよう表記と設定内容が合致しているかを整合チェックできるツールを導入することが望ましいと考えます。
また、実際に端末を操作してガチャを繰り返して確率の挙動をテストするのは工数的に非現実的なので、シミュレータ(※)でのチェックも並行するとテストの信頼度を高めることができます。
※シミュレータ自体のテストは別途必要です。
### 障害事例②提示された商品情報と実際の挙動が一致しない
|項目|説明|
|:--|:--|
|詳細|スキル説明文で効果(大)と記載されていたが、実際は効果(中)だった|
|対応|表記にあわせて効果値を効果(大)に修正。発生中の不利益を加味して、全体にガチャ石を配布。|
|対策|[開発に依頼すること] <br> ・効果を指す文言がどの範囲に設定値を取るかレギュレーションを決める <br> [QAで対応すること] <br> ・文言と設定値の範囲が適切かチェックする仕組みを導入|

スキルの説明文を手書きで設定している場合(※)に起こりうる障害の事例です。
テスト視点だと、説明文と効果値のレギュレーション有無や、実際の端末上でどういった出力になっていればOKと判断できるかを開発チームと合意しておくことでチェック精度を高められると思います。
可能であればスキル説明文を設定値から自動生成する仕組みがあると、より障害リスクを軽減することができます。
※SNSや動画の生配信の説明も要注意

## 2.ショップ販売物の設定ミス
「ガチャ」と同様にリスクが高い機能として「ショップ」があります。
ここでは「ショップ」=ガチャ石との交換や直接購入により、ゲーム内で使えるアイテムを入手できる機能として記載します。
### 障害事例①パック販売に含まれているはずの商品がもらえない

|項目|説明|
|:--|:--|
|詳細|パック商品Aのアイコン画像に含まれるスタミナ回復薬が実際に購入したときにもらえない|
|対応|パック商品Aの購入者にアイコン画像に含まれていたスタミナ回復薬を補填(※)。パック商品Aにスタミナ回復薬を追加。 <br> ※ゲームの仕様によっては補填対応が難しいアイテムもあるので注意|
|対策|[開発に依頼すること] <br> ・可能な範囲でアイコンを汎用性の高い画像に差し替える運用に変更 <br> [QAで対応すること] <br> ・テスト内容にアイコン画像とパック内容の整合確認観点を追加|

商品の内容を伝わりやすくするために画像で紹介することもありますが、パックの中身が変動する際には注意が必要です。
あらかじめテスト内容に含めておくか、アイコン画像自体を統一して誤認リスクを減らすことも対策の一つです。
また、類似するケースとして商品内容の説明文言の記入ミスもあげられます。
ガチャお知らせの対策同様に、設定された値から説明文を自動生成できるとリスク軽減につながります。
### 障害事例②個数限定販売と記載されているが、実際には何度でも購入できてしまう

|項目|説明|
|:--|:--|
|詳細|1回限定で購入できるパック商品が複数回購入できる|
|対応|限定回数を超えた分を回収し、購入につかったガチャ石を返却。|
|対策|[開発に依頼すること] <br> ・設定された購入可能回数から、購入可能数表示を出すようにプログラムを修正 <br> [QAで対応すること] <br> ・購入可能回数に制限がある場合に実動作確認結果の動画をテストエビデンスとして提出する運用に変更|

ショップ販売は一度販売内容を決めて運用を開始したら、販売内容の更新をすることは多いですが、プログラム上の変更自体はそこまで多くないと思います。
そのため、最初に決めたテスト内容がそのままになっており、変更点の共有漏れでテストされずにリリースされることも起こりうるので開発チームとの仕様共有も重要です。

## 3.ランキングイベントの不備
ランキングイベントはお客さま間の競争要素で、上位ほど報酬も高く設定されていることから不具合が発生するとリスクが大きくなります。
### 障害事例①ポイント計上の上限設定ミス

|項目|説明|
|:--|:--|
|詳細|ランキングイベントで特定のポイント以上獲得するとスコア表示がおかしくなる|
|対応|スコア上限のプログラムを修正し、本来獲得できていたポイントを補填。発生中の不利益を加味して、全体にガチャ石を配布。|
|対策|[開発に依頼すること] <br> ・イベントのスコア情報を記録し、推移を追いながら適宜上限値を確認するフローを導入 <br> [QAで対応すること] <br> ・必要に応じてデータ上限の動作確認を実施|

獲得したポイントを競い合うイベントで運営が想定していた以上に遊んでいただけることもあります。
特に運営が長期化してくるとプレイの幅も広がり、獲得ポイントも大きくなってきます。
初期実装時には問題なかったプログラムでも、遊び方の広がりで不具合につながることもあるので注意が必要です。
### 障害事例②ランキング報酬の設定ミス

|項目|説明|
|:--|:--|
|詳細|イベントTOPページに表示された報酬キャラの説明内容に誤りがあった|
|対応|イベントTOPに記載された内容にあわせて報酬キャラの性能を情報修正。お詫びとして全体に回復アイテムを配布。|
|対策|[開発に依頼すること] <br> ・イベントTOPの報酬キャラ説明で手書き入力になっている箇所を抽出 <br> [QAで対応すること] <br> ・該当箇所の確認をテストに追加|

事前に説明のあった報酬と実際に獲得できたものが異なる場合、お客さまの期待値との乖離が大きいほど問題になりやすいです。
特にランキング上位報酬のミスは影響が大きくなりやすいので、どの画面でどういった説明が入るかは確認しておきましょう。

# 最後に
障害を未然に防ぎ切ることは困難ですが、過去の事例やノウハウを駆使することでリスクを軽減することはできます。
今回挙げたリスクとなる障害はいずれもヒューマンエラーに起因するものです。サービスを提供する組織として、開発チームと結束して説明文の自動生成等の対策などを取り入れて最大限リスク軽減に努めていきたいと思います。
他にもこういう事例とか対応あるよ、という方がおられましたらぜひコメントいただけますと幸いです。

これからもお客さまに最大限ゲームを楽しんでいただくために、開発チームと連携して障害対策を推進したいと思います。