スクエニ バグ

スクエニのAndroidのドラクエ、FFの旧作のリメイクで、
レビューに「ひどいバグがある」などという書き込みがしばらく消えなかったのを何回か見たことがあります。プログラミング的に、Androidのバグを取り切るのはそんなに難しいんでしょうか？難しい理由があれば、高校生でもわかるように教えて下さい。

No.2 ベストアンサー 回答者： cametan_42 回答日時： 2021/02/08 13:37

> プログラミング的に、Androidのバグを取り切るのはそんなに難しいんでしょうか？

Androidかどうか、ってのは関係なく、言っちゃえば、全てのプログラミングではバグを取り切るのは「難しい」のです。
ゲームかどうか、ドラクエだからなのか、スクエニだからなのか、と言うのは全く関係ないですね。
まあ、恐らく、プログラム自体も「凄くデカい」のがまた問題だったんでしょうが。

以下、余談だと思ってくれて良いです。

プログラム初心者に教えるネタで良くあるのは「数学的な課題」なんですけど。
これ、誤解してる人が多いんですが、「プログラミングは数学に密接に関係がある」「プログラミングは理系の範疇」だからじゃありません。
もちろん、プログラミング言語が発展してきた最初は科学技術計算での要請、ってのがあったんですが、今は全く関係ないです。
じゃあ、何で「数学的な課題を扱うのか?」と言うのは、理由が「それがトピックとして一番簡単だから」なんですよ。
言い換えると、「証明済みだから」って事だからです。数学的に証明済みな以上、「それは確実に動く(計算結果が出る)」事が分かっている。そして「証明済みのモノが動かない限り」プログラミングを貴方(プログラミング初心者)がどっか間違えたんだろ、って言えるわけです。
ところが現実的な物事をプログラムするとなると、相手は「数学的に証明されたようなブツ」じゃないので、「上手く動くかどうか」ってのが実は保証されないんです。
これが実は至極厄介なのです。そもそも数学的に証明されていないモノがプログラミングの対象だとすると、じゃあ何をもって「バグ」とするのか?

通常、簡単に「バグ」と言いますが、大きく言うと、パターン的に次のような事があり得ます。

1. プログラマが使用してるプログラミング言語で構文上のミスを犯した。
2. 設計したデータが間違っていた。
3. ユーザーからの入力が想定外だった。
4. ユーザーへの出力が想定外だった。

まぁ、プロのプログラマである以上、1. はまずあり得ないんですが。ただ、これも良くある。人間は「間違える」んで。
問題は構文は正しいのにプログラムが上手く動かないケース。2と3と4はここに含まれる。
この解決策としては、まず一つは数学的に「バグが無い」プログラムを作る事は本当に出来るのか、と理論的に研究する事が挙げられます。
これは大学なんかでの研究対象なんで、興味があるなら大学に進学したあと、学んで下さい。

もう一方は実用的な方面からでのアプローチです。
プログラマは通常、

「こうデータ設計しておいて、入力が来たらこうデータを書き換えて、そのデータの特性に従って、こう処理を振り分けて、それでこう出力して、完成!」

ってやってくんですが、問題はその「ユーザーからの入力」がまずはとんでもなかった場合、です。
例えば入力は整数だ、って想定してたのにアルファベットが入力されてきた、とか。色々そういう「ちょっと待てよ」ってケースが起こりうるのです。
んで、昔はそういう「異常な入力」に対して想定しておき、条件分岐でおかしな入力が来た場合、処理をやり直せ、とか書いてたんですよね。
ところがそれじゃあ大変な事になってきた。

「入力がこれの場合はこうして、入力がそれの場合は、えっと、どこに戻ればイイ?ちと待てよ、入力がアレの場合は・・・・ガーッ!!!!」

条件分岐ってのがメチャクチャ肥大化するような状態になってきたんですよ。
つまりね、

「ユーザーはプログラマが想定出来る範囲の"異常入力"の想定外でかつ斜め上の事を絶対やる」

わけです(笑)。こりゃいくらなんでもダメだろ、と。そして「想定外」が起きる以上、必ずプログラムは異常終了する、と。そうじゃなくって、どんなエラーが起きても、それが起きる前に「巻き戻して」もう一回エラーが起きる前の状態に出来ないか、と考える人が出てきたんです。
んで、まぁこれが最初じゃあないんですが、1996年に発表されたJavaで有名になった機能がある。いわゆる「例外処理」ですね。これでエラーが起きた場合の「取り敢えず暫定的な」対処が可能になった。

ただし、「例外処理」があっても、プログラマの人為的なミスによる「計算の間違い」ってのは起こり得るわけですよ。これは防ぎようがない。
そこで2000年代中盤から「ユニットテスト」とか「テスト駆動開発」って言われる「ソフトの作り方」が推奨されるようになってきた。まず今作ってる部分の「正しく動くんなら結果はこうなる」ってのを列挙します。思いつく限り、ね。
それからその部分のプログラムを書き始める。そのプログラムのテストをする。エラーが起きる。書き直す。テストする。またエラーが起きる。そのバグを潰す・・・ってやってったら「バグがないプログラム」が出来る筈だ、と。まぁ、確かに実用的にはそうだろな、って話です。
でも、良く考えてみると、「全ての"正しい"関係を列挙出来るのか」って問題があるんですよ。それが出来るならそもそも「条件節を書くしか出来ない時代」で列挙出来てた筈なんです。そして一体いくつ「正しい関係」があるのか?
つまり、この方法でも「ある程度の正しさ」は保証出来るんだけど、もし「ある特定の正しさ」が(思いつかなかったり忘れてたりで)漏れていたとしたら、それに対する検証はあり得ません。従って、そこはテスト出来ないので、潜在的にはやはり「バグが残る」のです。
大体、プログラムでさえ書き間違えるのに、テストを書き間違えない、とかあるいは「全部テストを思いつく」って保証があるのか、と。確かに問題は「減ってる」けど「無くなった」ワケでもないんですよね。構造的に。

というわけで、意外とバグって何なのか、とか「バグが無いプログラムって作れるのか?」とか考え出すとこれがなかなか難しいんですよ。
んで、現実的な問題で言うと「どんなプログラムだろうとバグがある」と言われています。「あるんだけど見えないだけだ」と。
つまり、実行させてみてクリティカルになるバグってのは即座修正される可能性はあるんだけど、そうじゃないバグに関しては「潜んでるだけだ」と。だからそもそもそれが「なかなか表面化しない」。
まぁね。ユーザーの立場から言うと、

「バグ起きたプログラムってサイテー」

とか言いたいのは事実なんですけどね(笑)。プログラム組む側から言うとそこまで実は問題は単純じゃない、です。
特にね〜。ゲームはマジで大変ですよ。「やれる事が多くなる」ゲームになればなるほど、指数関数的に潜在するだろうバグは増えていく。
いや、マジでシャレにならん商売だと思いますよ。

この回答へのお礼

皆さんありがとうございます。

お礼日時：2021/02/09 16:36

No.1 回答者： EFA15EL 回答日時： 2021/02/08 12:16

どんなバグかにもよりますが、Androidだから難しいという考え方はあまりしません。

（もちろんAndroid固有の難しさもありますが）

しばらくバグフィックス出来なかったのは、人気タイトルは常に開発が進んでいることもあり、
スケジュールに組み込みづらかったりしたからでしょう。
もちろん緊急性の高いバグ（お金に関わるとか）であれば他の作業を中止してでも改修しますが、
そうでなければ、次回のリリース時にまとめて修正という形を取るのが普通です。