CodeZine(コードジン)

特集ページ一覧

不具合に強い「柔軟性」を持つ設計・実装とは?――ドラゴンクエストXを支える失敗事例【デブサミ2019】

【15-A-1】ドラゴンクエストXを支える失敗事例

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

失敗事例(2)――クローズ基準を厳密化し、「チケット駆動開発」の徹底を

 失敗事例の2つ目は、プレイヤーマッチングにおける不具合だ。ドラゴンクエストXには、8人のプレイヤーが協力して戦うというコンテンツがある。その際に、仲間を自動で探すというオートマッチング機能があるのだが、参加希望者が多数いてもマッチングされないという不具合が出た。コンテンツのリリース当初は問題なく動いていたのだが、6月10日の定例更新以来、一部のエリアのみでこの事象が発生するようになったという。

 条件はプランナー作成のデータで設定されているため、まずはそちらを調査したが、問題となりそうなデータは見つからない。そこでプログラムを詳しく調べると、「6月10日更新分」かつ「特定のエリア」のみを直接条件指定した実装が見つかったという。

特定の更新データとエリアを指定した実装があったことで、時限スイッチのように不具合が発生する事態に
特定の更新データとエリアを指定した実装があったことで、時限スイッチのように不具合が発生する事態に

 なぜこのような実装が行われたか。その理由は、このコンテンツのマッチング条件におけるデータフォーマットを変更した1年前にさかのぼる。その対応を行う際、単純修正では全体影響が発生してしまうことから、影響範囲の局所化を意図し、暫定的に時期とエリアを条件にハードコーディングするという対応がなされた。その後にそれを消し忘れたことから、1年後に不具合が発生したというのが今回の事象の結果である。

 この事例の教訓は、BTSチケットの管理期間の適正化を行うことであると語られた。暫定対応については実施後もクローズせず、本対応完了までをチケット管理することにより再発防止としたという。

2つ目の失敗事例の教訓。各タスクをチケットにより管理する「チケット駆動開発」を行っているため、その管理期間を適正化することで再発防止が可能に
2つ目の失敗事例の教訓。各タスクをチケットにより管理する「チケット駆動開発」を行っているため、その管理期間を適正化することで再発防止が可能に

失敗事例(3)――表面化していない不具合を常に想定し、最終手段は行動ログで

 最後に紹介された失敗事例は、数値判定に関する不具合だ。それはゲーム内で行える「釣り」のミニゲームにおいて、特定の魚を釣った際のサイズ判定が正しく行われないという欠陥であった。魚には個々の大きさがcm単位で設定されており、それに応じてサイズが「キング」「ビッグ」「ノーマル」に分類される。釣った後、特定のキャラクターに話しかけると、サイズに応じた報酬がもらえるのだが、その際に「ビッグ」のはずの魚が「ノーマル」に判定されてしまっていた。

 不具合の詳細は複数の言語を介した際の仕様の差にあった。釣りの実装にはC++とLuaという2つの言語が併用されているのだが、前者ではmm単位の情報をintで扱い、後者ではdoubleで扱うという違いがあった。そこで浮動小数点における誤差を疑い調査すると、不具合が発生した魚におけるサイズ判定基準値では、ちょうどその境界値において1のずれが発生することが発覚したという。なお、浮動小数点における誤差の補正処理は実装されていたものの、その計算式に問題があったことが確認されている。

double型において1023という数値を1000で割り、その次に1000を掛けると、1022.999...という数値になってしまう。不具合が発生した魚での判定基準では、1023mm以上を「ビッグ」、1022mm以下を「ノーマル」としており、ちょうどその部分でずれが発生していた
double型において1023という数値を1000で割り、その次に1000を掛けると、1022.999...という数値になってしまう。不具合が発生した魚での判定基準では、1023mm以上を「ビッグ」、1022mm以下を「ノーマル」としており、ちょうどその部分でずれが発生していた
浮動小数点における誤差を考慮された計算式は実装されており、一見するとその内容も適切であった
浮動小数点における誤差を考慮された計算式は実装されており、一見するとその内容も適切であった
しかし、最後にスケールをそろえる意図により再度1000で割っており、もう一度誤差が発生。さきほどの補正が無意味に
しかし、最後にスケールをそろえる意図により再度1000で割っており、もう一度誤差が発生。さきほどの補正が無意味に

 この不具合については、サイズ分類はもちろん、大きさの数値計算そのものも信用できないデータとなったことが確認された。そこで、行動ログとデータベースの情報から、不具合が発生したユーザーへ個別対応するという手段をとったという。

 ここで得られた教訓とは、表面化していない不具合は、存在する前提で対応すべきということ。また、最終的な対処は行動ログを取得していたからとれた手段であり、ログの重要性も知見として強調された。

行動ログを取得しておくなど、不具合がある前提で構えておくことにより、想定外の不具合にも対処が可能となる
行動ログを取得しておくなど、不具合がある前提で構えておくことにより、想定外の不具合にも対処が可能となる

失敗事例を共有するということ――「経験値」の積み方

 これまでに見た代表的な失敗事例を振り返り、開発ポリシーに追加すべきと考えたこと。それは「リリース後の改修は要注意」であるということだと青山氏はまとめる。リリース後の改修はまず「影響範囲を考察」し、「BTSチケットに登録」、そして「確実にチケットクローズまで対応する」ということが重要であるとした。

 ドラゴンクエストXの開発チームでは、発生した問題に対し、「どうすれば事前に防げたか」という観点で常に検討し、まとめているそうだ。不具合はなくならないが、つど振り返り、教訓としてまとめていけば、その数を減らしていくことはできる。その基となるBTSチケットは(不具合以外のタスクなども含まれるものの)20万件に上るという。その膨大な経験のひとつひとつが、現在のドラゴンクエストXの運営を支えている。青山氏は、それらをノウハウとして共有したこの機会が「皆さんの“経験値”の一部となれば」と思いを伝え、セッションを結んだ。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:【デブサミ2019】セッションレポート

もっと読む

著者プロフィール

  • 西野 大介(SOMPOホールディングス株式会社)(ニシノ ダイスケ)

     SOMPOホールディングス株式会社デジタル戦略部(SOMPO Digital Lab)勤務。損保ジャパン日本興亜グループにおける先進技術の研究開発を担当。過去には基幹システムの開発にも従事し、SoR/SoE双方の開発において幅広い経験を持つ。本業以外では、CodeZineの連載をはじめ、国内/海外...

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5