※本エントリーでは、リリース後に発生した不具合を「障害」と定義します
インフラエンジニア出身の私は、障害が大嫌いです！！！
夜中にデータセンターに行くのも、お客さんに謝りに行くのも、
社内で詰められながらなぜなぜ分析させられるのも全部大嫌いでした！！
ゲーム会社のQAチームに来てから、起きた障害を分析する機会は多いのですが、
パッと見プロダクト側起因でも、QA側で何とかできないのか！と厳しい目で見てしまいがちです。
さて本記事では、そんな視点で分析した障害の中から、
これを検知するのは厳しい…！と感じた例をいくつか紹介したいと思います。
（すべてフィクションを織り交ぜています）
仲間外れ
ゲームをされる方はピンとくると思うのですが、キャラクターのパラメータとしてスキルが設定されてたりします。
最近のゲームはキャラが非常に多いので、キャラクター固有のものだけだと大変なので、汎用的なものも用いられます。
以下の画像は適当に作った例です、数値とかスキル名とかは全部適当です。
この画像だと、キャラAとキャラBに設定された汎用スキル「防御強化」は同じ内容で同じ名前になっています。
例えば、諸般の事情でキャラAを上方修正することとなった場合、「防御強化」のスキルを強化したとすると、
同じ「防御強化」を持つキャラBも強化されるのが普通の流れだと思います。
この画像ではキャラAとキャラBの2種類だけですが、汎用スキルなので他にも100種類くらい同じスキル持ったキャラクターがいると仮定します。
その仮定の上で、「防御強化」の上方修正を行った際、100種類のキャラを個別に検証するでしょうか？しませんね。
大体は上の画像のように、重要なキャラクターをピックアップして検証することで、
同種のスキルを持ったキャラクターについても品質が担保されると判断するはずです。
普通はこのような検証観点で問題はないのですが、まれに次のようなケースがあります。
このように、見かけ上同じだと思っていたものが実は仲間外れになっているケースは非常に性質が悪く、QAでの検知も難しいですし、
再発防止策として、レコードの全件検査を行うといったような多大な工数を必要とする場合もあります。
IP系
これは既存のIP（アニメとか漫画とか…）を基にしたゲームにありがちなのですが、元ネタの設定と、ゲームに実装された設定が食い違っている！
という障害が起きることがあります。
例えば例が適当で申し訳ないのですが、戦国時代を元ネタにしたアニメがあり、それとコラボしたとします。
で、そこに出てくる信長のカードをこんな感じで実装したとします。
SSR【本能寺】織田信長
ホトトギスも添えてあり、信長だということもわかりやすくてバッチリなカードに見えますね。
しかし、原作のアニメの方で、ホトトギスは本能寺の変の時には既に死んでいるという設定があったとしましょう。
すると、キャラ名に【本能寺】と入っているのにホトトギスが居るのはおかしい！ということで、障害となってしまいます。
このようなIP周りの障害は、テスターさんがそのIPを知っているかという点に依存してしまい、防ぐことが難しいのですが、
原作のファンの方を刺激しやすく、熱量の高い問い合わせにつながりがちです。
コミュニケーションエラー
開発チームとQAチームのコミュニケーションエラーも、障害を呼び寄せる一因です。
例えば、A、B、C3種の新機能を追加したが、C種の機能についてはQA依頼をするのを忘れていて、そこに不具合が潜んでいた～、といったような例はわかりやすいと思います。
しかし、次のようなケースだと、テストを実施していて問題ないと判断していても、障害につながってしまう場合があります。
新イベントに合わせて、次のようなキャラをリリースするとします。
検証時には実際にこのキャラをイベントで使ってみて、与えるダメージが同じ攻撃力の特効なしキャラの1,000倍
（レベル最大時に10,000倍）になっていることが確認できれば、テスト結果はOKとなるでしょう。
さらに、同じタイミングで既存のカードに上方修正を加えるとします。
次の画像のように、よくある進化でパワーアップみたいな感じの上方修正をしてあげます。
こちらも進化したキャラを適当なイベントで使ってみて、与えるダメージが同じ攻撃力の特効なしキャラの20,000倍になっていることが確認できればOKとなるでしょう！
しかしここで、以下のようなQA未共有情報が眠っていたとすると、状況は一変します。
公式twitterにて、新キャラクターAのイベント特効スキルは過去最強！と訴求していた
こうなると、新キャラクターのイベント特効倍率は仕様と一致してはいますが、
上方修正を受けた既存キャラクターのスキルは新イベントに限定しないボスへのダメージ倍率が20,000倍と、新キャラクターAのダメージ倍率を超えてしまっています。
これだとtwitterでの訴求内容に反してしまうので、障害となってしまいます。
本例は不当表示につながるため、インパクトの大きい障害ですが、事前にtwitterでの訴求内容がQAに伝わっていれば、防げたかもしれません。
最後に
ここまでQAで検知しにくい障害の事例を紹介してきました。
どれもいきなりQAで防ぐのは偶然以外では難しいと思います。
が、かといって「仕方なかったね」で終わらせていいということにはなりません。
QAで検知するのが難しい障害が起きたら、次はどうすれば防げるか考えるのがQAの仕事だと思います。
例えば既存スクリプトの不具合であれば、QA稼働の少ない時期に過去データの洗い出しを提案したり、
IP周りの不具合であれば、IPについての勉強会を企画したり、
コミュニケーションエラーであれば、コミュニケーションのフローを整備したり、色々QA側から働きかけることはできると思います！
まだまだ障害分析には着手したばかりですが、主体的に動き、品質のいいゲームを世に出すことを心掛けたいと思います！