青山Pが振り返る「ドラゴンクエストX」3つの失敗――消すつもりのコードが本番環境に：累計20万チケットを生んだオンラインゲーム開発プロジェクトの裏側（3/3 ページ）

[石川俊明，＠IT]

f_Result = math.floor((f_FishScale + 0.0004）* 1000) / 1000

実装していた数式

　変数のf_FishScaleには、魚の大きさをミリメートルからメートルに変換した「1.022999……」のような小数が与えられる。

　そこに、0.0004を加えて三捨四入したものに1000を掛ける。その結果「1.022999……」は、「1.023399……」となる。

　これをfloat型からint型に変換することで「1023」になり、正しい魚の大きさが求められる。

　しかし、最後に1000で割った結果、「1.022999……」になった。誤差を補正しているようで、補正していない数式になってしまっていた。

　ゲーム内で魚を生成する際は、ビッグサイズやノーマルサイズなどサイズ分類をしてから魚の大きさを乱数で決定していた。しかし、この数式によって「1.023999」のように誤差補正をしないまま保存したため、「ビッグサイズの1022mm」という魚データがゲームDBに保存されていた。その後、別の不具合でサイズ分類に不整合があり、釣り老師に話し掛けたタイミングで魚の大きさからサイズ分類を行うようにした結果、今まで保存されていた「ビッグサイズの1022mm」が、「ノーマルサイズの1022mm」に正しく直されたのが不具合として扱われていた、ということだった。

　「サイズ分類処理も、魚の大きさ処理もバグを含んでいたことが分かったため、ログとゲームDBの情報から不具合が発生したユーザーに個別対応した。行動ログを基に全て対応できたので、よかった。この不具合からは、バグがある前提で不具合に対応していくべきだという教訓を得た」

---

　青山氏は3つの不具合と原因、改修方法を振り返り、サービス運用時の注意点について考察して講演を締めくくった。

　「今回紹介した失敗を含め、担当者が『こんな修正、影響ないだろう』と思って修正したものがサービスに影響を及ぼして起きた不具合が最も多いと感じている。リリース後の改修は要注意だ。もし、リリース後にサービスを改修するなら、改修の影響範囲を考察し、BTSに不具合内容と改修の影響範囲を記録する必要があるだろう。もちろん、影響がなかったケースもあるにはあるが、全ケースをBTSに登録するようなスタンスが求められると考えている。この教訓は、ドラゴンクエストX開発陣の結論なので、この失敗事例を知って『自分たちのサービス運用ではどうするか』を考えるきっかけになれば幸いだ」