ゲーム業界でSバグといわれるものはいわゆるストップバグ。
ゲームをリリースする目途として、ストップバグが無くなったらリリースしましょうというのが一応の目安かと思います。
この考え方がそろそろ古くなってきたのかもな、というあたりの話をしたいと思います。
■実際Sバグがない状態でリリースされているの？
そんなことはないですね。
実際ほとんどのゲームがばれていないだけでSバグが混在している状態でリリースされています。
何故直さないのでしょうか？
いくつかパターンがあって、
①発生することは何度も確認できているが、どう発生させるのかわからない
②そのバグを修正したことによって別のバグを発生させることがある
などが主な原因ですかね。
■発生することは何度も確認できているが、どう発生させるのかわからない
これが一番よくありますね。
開発中のテストプレイで10件くらい同じ内容で報告される感じのバグです。
10件は多そうなイメージがあるかもしれませんが、何十人で開発して何十日もQAをやって、10件くらいしか出ないバグはかなりのレアケースです。
大概は狙って再発させようとしても再現させることが出来ないことが多いです。
でも10件報告があるということは、まあそういう状態になることがあるということでしょう。
再現しにくい所が重要で、100％再現させることが出来るバグは大概修正できます。
意図的に再現させることが出来ないバグはどこが原因かわかりにくいので、なかなか修正できないのですよ。
締め切り間際まで調査してわからなければ、わかっててリリースすることがあります。
それだけレアケースでしか出ないということは、通常のプレイをしている限りでないことが多いということもあります。
ひょっとしたらここが原因かも？という個所に対策用のプログラムをいれて対処はするのですが、結局それで出なくなるとどこが原因だかわからなくなったりもします。
そうした結果、
・リリース後出たという話を聞かない
・ユーザーが発生条件を早い段階で見つける
というどっちかになることが多いですね。
本気で調査をしていると前者、そこで手を抜いてたなあと思うと後者になることが多いです。
2020年のCEDECでも話題に挙がっていた自動テストなんかをうまく活用しないといけないのでしょう。
■そのバグを修正したことによって別のバグを発生させることがある
このパターンはストップバグに関してはあんまりないかもですね。
それこそストップバグを放置しているほうが別のバグを発生させることが多いですから。
でももうすでにQAを長期間行っていて、その修正を入れることによってQAを全部やり直さないといけない、というような条件だとそのまま修正しないこともあります。
あとはスマホゲームなどだと、特定の機種だけで起こる症状などもこれに入るかと思います。
その機種のためだけに特別な対応を入れると、別の機種で違うバグが起きる可能性が出てきます。
もうこうなったら泣く泣く対応機種から外す感じになりますね。
■Sバグを全廃するのは難しい
コンシューマーゲームであればある程度担保できるんですよね。
状況を確定させることがやりやすい。
でもPCゲームだったり、スマホゲームだったりすると各ユーザーの環境全部を考慮するのは無理です。
コンシューマーでもネットワークゲームなんかは難しいですね。
ネット環境はそれぞれで違いますから。
■私が直面した直せなかったSバグ
いわゆる携帯で遊ぶソーシャルゲームを作成していた時です。
携帯のブラウザで遊ぶことが出来るやつです。
とあるユーザーから「プレイできない」という連絡がありました。
調べてみたのですが問題なさそう。
同じ機種の他のプレイヤーはプレイできている。
ブラウザのバージョンもOSのバージョンも全部調べても問題ない。
ユーザーさんはこちらの聞き取りにも協力的で、いやがらせではないと思います。
でも何度試してもできない。
定期的にまだできないのかという確認がきていたのですが、結局サービス終了までそのユーザーさんがプレイできることはありませんでした。
謎のまま。
普通はあり得ないんですよ、ブラウザでの挙動なんて各携帯で変わるようなことはないので。
通信環境か、携帯に入れていたセキュリティなんかが影響していたのかもしれませんが。
ゲームを製作しているとこういった、摩訶不思議な理由のSバグにも直面します。
■Sバグ根絶は建設的なのか？
この記事を書いたのは下記の記事を読んだからです。
ここで語られている内容に関してエンジニアとしては賛成。
でも「Sバグは許しません！」という条件下だとそうもいっていられない。
オブジェクト指向だったり、C++で組もうとか言う話は「Sバグが許容できない」という所と絡んでくるんですよ。
プログラムのすべてが理解できるような状況になっていないと不慮のバグを根絶するのは難しいのです。
オブジェクト指向はそのあたりを担保しやすくするための技術のように思います。
■Sバグ根絶より必要なのは？
それこそPS2の時代なんかはマルチプラットフォーム対応なんて難しかったじゃないですか
いまだと当たり前にできますよね。
これって便利な反面怖くて、なんでそれが実現できているのかがわかって作成できている技術者なんてごく一部だと思います。
自社マルチプラットフォームエンジンならまだ解析の仕様もありますが、他社作成のゲームエンジンなら何をやっているか調べようがないところもあります。
そういう状態だとSバグ根絶ができるって言いきれないです。
Sバグ根絶を要件にするということは既存のゲームエンジンを使用しないという判断に近いものがあると思います。
もはや現実的でないというか、費用対効果が合わないのですよ。
ゲームエンジンだけでなく、各ゲーム機器のOSだってコントロールもできなければ内部理解だって難しいですよね？
そう考えると「Sバグはすべて悪、全部駆除して当たり前」という考えは一旦捨てたほうがいいかと思います。
一般的なプレイを自動でできるようにしておき、それで発生頻度が何％以下なら修正しない、というような基準をもとに作成していくべきですね。
逆にいうと自動プレイでのバグ調査機能なんかは必須になってくるのでしょう。
■今後どのように考えていくのか
ゲームなんかはまだいいのですが、私は自動車のプログラムを組んでいたことがあるんですよ。
それこそアセンブラレベルで問題がないか確認していました。
だって自動車って制御ミスがそのまま死につながることがあるじゃないですか？
言語仕様の通り組みました、このミスはコンパイラが仕様に沿っていないからです、だからこの事故と私は関係ありません。
と言い切る度胸はなかなか持てないですよね。
それが妥当だと思っているのですが、電気自動車になっていろんな他業種が参入という話が出ているじゃないですか。
参入はいいけどこの辺りは本当に大丈夫？と思います。
レガシーな技術を持つ技術者の確保なんて難しいでしょうし、そもそも開発効率重視でそういう手法は取らないと思うのですよ。
序盤は少なからず問題を起こすように思います。
それでもしょうがないと合理的に考える会社が伸びていく可能性はあると思うんですよね。
そして日本の既存の会社はその手段をとれずに衰退していく可能性もあると思っています。
逆にやっぱり合理的に考えていちゃダメだった、という結論になる可能性もあると思います。
このあたりの判断が日本の製造業の分水嶺になる気がします。