本記事は『ゲームをテストする バグのないゲームを支える知識と手法』の「第4章 ゲームデバッグはもう古い!?」から一部を抜粋し、編集したものです。
ゲームデバッグはもう古い!?
ゲームデバッグとは文字どおり「ゲーム」を「デバッグ」することですが、実はここでいう「デバッグ」という言葉は、本来の意味とは少し異なる使われ方をしています。
デバッグという言葉は本来、「バグを探してそのバグを修正する活動」を指します。しかしゲームデバッグの「デバッグ」はバグを探し出す活動のみを指しており、そこにはバグを修正する活動は含まれません。
なぜこういう使われ方をしているのか、確かなことははっきりしませんが、本来の意味でのデバッグの中でも重要な活動のバグ探しを指して、「バグ探し=ゲームデバッグ」と呼ばれるようになったのではないかと思います。
なお、ゲーム業界以外のテストの現場では、「デバッグ=バグ探し」とは認知されておらず、「デバッグ=バグを探してそのバグを修正する活動」という正しい意味で認知されている点には注意が必要です。
ゲーム業界では昔からこのゲームデバッグが行われてきましたが、コンシューマーゲームが主流であった時代からスマホゲームが主流の時代に変化し、ゲームの開発方法やゲームビジネスも変化してきました。ゲームデバッグという昔ながらのやり方だけでは品質を担保するのが難しくなってきているのが現実です。
豊富な経験に依存した究極のアドリブ
ゲームデバッグとは、バグ出しに特化した活動です。ゲームの仕様が適切であるかの確認はあまり含まれておらず、とにかくゲームを動かしてデバッガーが異常と感じる現象が発生しないかの確認を行います。
ゲームデバッグのやり方は、いわゆるフリーデバッグと呼ばれる「デバッガーが自由にゲームをプレイして、デバッガーのセンスや経験からバグを探していく」やり方が主流です。「デバッガーのセンスって何？」と思うかもしれませんが、以下のような要素がセンスの有無につながります。
- 想像力や発想力がある
- 視野が広い
- 観察力がある
- 好奇心がある
バグは予期しない操作から予想も付かない動きをすることが多く、デバッガーはゲームをプレイしながら「こういうことをしたらどうなるか？」を常に考えなくてはなりません。そのため、幅広い自由な発想力を持っていることで、デバッグ経験が少なくてもバグを見つけられる優秀なデバッガーになれる可能性があります。
こうしたセンスのあるデバッガーがデバッグ経験を積んでいくと、ある程度狙ってバグを出せるようになっていくのですが、第1章でも述べたようにそういったデバッガーは少ないのが実際です。
多くの人は見た目でわかる表示系のバグ出しや、聞けばわかるサウンド系のバグ、あとはボタンの同時押しやボタン連打系でのバグ出しが中心になります。経験を積んだりさまざまな情報を蓄積したりしていくことで、よりテクニカルなバグを見つけられるようになっていきますが、経験のうち最も重要なのはどれだけ多種多様なバグを見聞きしてきたかだといえます。
多くの人にとって、未知のことがらはなかなか想像がつきませんが、既知のことがらはイメージすることができます。つまり、どこで何をしたらバグが出たのかという情報を蓄積していくことで、似たような状況に直面したときにバグが出た操作をイメージすることができるようになるのです。
ただし、これにはたくさんの経験値が必要であり、すぐにできるようになるものではありません。また、個人のデバッグ経験に依存し、そのバグが発生する原理の理解まではできていないため、なぜバグの出る操作を行ったのかを聞かれると「過去の経験から」といった答えしか返ってきません。経験を積む以外の方法を誰かに教えてもらおうとしても論理的な説明ができず、人から教えてもらうことが難しくなります。
こうしたバグ情報を蓄積するには、自分でバグを見つける以外にも他のデバッガーが見つけたバグのバグレポートを見るのが非常に有効です。
現代的な手法「ソフトウェアテスト」
ゲーム業界の関係者であれば、「ゲームデバッグ」「デバッグ」という言葉を実際に使ったり聞いたりしたことがあることでしょう。しかし、「ソフトウェアテスト」という言葉にはなじみが薄い方も多いはずです。
ソフトウェアテストは、その名前のとおりソフトウェアをテストするための考え方であり、現代のゲームテストにも欠かせないものとなっています。
ソフトウェアとは何か？
ソフトウェアテストについて述べる前に、ソフトウェアとは何かについて述べておきましょう。ソフトウェアとは、「コンピューターやスマホ、その他電子機器に搭載されたプログラム」のことを指します。ソフトウェアには、以下のようにさまざまなものがあります。
- OS
- ブラウザ
- スマホアプリ/ゲーム
- 鉄道などの券売機システム
- 銀行ATM システム
コンシューマーゲームやスマホゲームも、当然ソフトウェアの1つですが、ソフトウェアテストの考え方はこれらすべてに対して共通して活用できるものなのです。
ソフトウェアテストの歴史
ソフトウェアテストが日本で広まってきたのは2000年以降です。特に、ソフトウェアテストに関する国際的な資格であるISTQB（International Software Testing Qualifications Board）の加盟組織として認定されたJSTQB（Japan Software Testing Qualifications Board）が、2006年から日本でソフトウェアテストの資格試験を開催するようになったことも、日本で広まる大きな要因だったのではないかと思います。
コミュニティ活動やイベント活動も活発になり、JaSST（Japan Symposium on Software Testing）というソフトウェアテストシンポジウムが開催されたのもこの頃（第1回は2003年）です。コミュニティ活動が活発になり、ソフトウェアテストが浸透していきました。
ゲーム業界とソフトウェアテスト
一方、ゲーム業界では昔ながらのゲームデバッグという文化が強く根付いており、ソフトウェアテストの考え方はなかなか浸透しませんでした。
ゲームはプロトタイプ、α版、β版と開発を進めていく中で、まず間違いなく仕様変更が入ります。机上で考えていたものを現実化した際に、思っていたより面白くないと感じることが往々にしてあるからです。
これはゲームというソフトウェア特有の性質です。ゲームはユーザーの感性に訴えかけるソフトウェアであるため、机上のものだけでは面白さを測れず、実際にプレイできるようになって初めて「面白い／面白くない」を感じられるのです。そうして仮にα版で面白くないと判断されれば、企画や要件の変更が必要となります。すると、プロジェクト全体の予算や工期にも影響が出てくる可能性があるのです。
テスト工程は、ゲームなどのソフトウェア開発の工程の中では最後に位置するため、こういったしわ寄せの影響をもろに受けます。度重なる仕様変更の中で仕様書などの資料が更新されていなかったり、テスト中であっても仕様変更が入る可能性が高かったり、しわ寄せの影響でテスト期間が予定よりも短くなってしまったりすることもあります。そういったことが多かったため、ゲーム業界ではバグ出しに特化したゲームデバッグ文化が根付いていくことになったのです。
しかし、スマホゲームの登場以降、ゲーム業界でもソフトウェアテストが注目され始めました。
コンシューマーゲーム開発は大ボリュームで自由度が高く、ゲームが発売されればそこからイベントが開催されたり機能が追加されたりするようなことはあまり多くありませんでした。そのため、マンパワーや物量による人海戦術でも何とかなっていました。しかし、現在はスマホゲームが主流になっています。スマホゲームはコンシューマーゲームとは違い、ゲームがリリースされたあとも開発や運営が継続していきます。
また、基本無料で遊べることも、スマホゲームの大きな特徴です。コンシューマーゲームはゲーム1本に値段が付いており、お金を払ってそのゲームを購入するまでそのゲームを遊ぶことができず、そのゲームが何本売れたのかがそのまま収益になります。しかし、スマホゲームは、基本無料で遊ぶことができ、ゲーム内で課金してもらうことで収益を作っていきます。さらにスマホゲームは、リリース後も継続的にイベントを開催したり、機能の改善や追加実装などを行ったりしてユーザー数や継続プレイ率を維持・向上する必要もあります。
もしもスマホゲーム開発でゲームデバッグをやっていたら
もし、スマホゲーム開発でコンシューマーゲームと同じように人海戦術によるバグ出し（ゲームデバッグ）をやっていたら、以下のような問題が生じます。
- リリースしたあとの運営フェーズでのテストで、リリース時のテストウェア（テストの成果物）の再利用ができない
- 属人的な活動になり、テスト要員の交代（引き継ぎ）に時間がかかってしまう
- テスト状況が可視化されておらず、品質状況もわからない
- ゲームのバージョンアップやイベントは毎月のように行われるが、行き当たりばったりな活動ではバグの市場流出が止まらない
スマホゲームでは一定の間隔でバージョンアップをしていく必要があるため、より効率的・効果的なテストが求められるのですが、その実現にはソフトウェアテストが適しているのです。
ソフトウェアテストの7原則
それでは、ソフトウェアテストについてもう少し掘り下げて見ていくことにしましょう。
ソフトウェアテストには、「テストの7原則」という、共通するテストの考え方があります。言葉自体は知らなくても、これらの中には少なからずテストに携わったことのある方にとってピンとくるものがあるかもしれません。
原則①：テストは欠陥（バグ）があることは示せるが、欠陥がないことは示せない
テストをして欠陥を発見した場合、その欠陥を見せることで欠陥があることを示すことができます。しかし、テストをしても欠陥が発見できなかった場合、本当に欠陥がなかったのかもしれませんし、本当は欠陥が潜んでいてその欠陥が表出する条件やタイミングによってテストができていなかった可能性もあります。
つまり、「欠陥がないこと」は証明することができず、「欠陥があること」しか示すことができないのです。
原則②：全数テストは不可能
「全数」とは、その言葉どおり「全部」という意味です。例として、ゲーム内でアバターを作成できる機能を考えます。アバター作成では、頭部のパーツだけでも髪型、髪色、目の形、目の色などと複数のパーツがありますが、この4つのパーツがそれぞれ10種類ずつあったとすると、10×10×10×10=10000通りの組み合わせが考えられま す。
実際には頭部のパーツはもっと数があるでしょうし、胴部、腕部、脚部などにも複数のパーツがあることでしょう。これらも含めると、組み合わせは数万、数十万にもなる可能性があります。
条件、組み合わせ、パターンなどのすべてを網羅したテストを行うには膨大な作業工数と期間が必要になります。ごく単純なソフトウェア以外では全網羅したテスト（全数テスト）は現実的には難しいため、リスクの分析やテストの優先度などを検討する活動が必要になってきます。
原則③：早期テストで時間とコストを節約
テスト工程に入ってからテスト活動をするのではなく、開発プロセス全体のなるべく早い段階からテスト活動を行うことで、バグ修正にかかる時間やコストの低減につながるという考え方です。
1：10：100の法則
よく知られる言葉に「1：10：100の法則」というものがあります。これは要件定義や設計段階で発覚した問題の解決にかかるコストを1とした場合、開発段階の単体テストでは10倍に、リリース後では100倍ものコストがかかってしまうという意味です。
この考え方はコスト面だけではなく、品質面においても効果があります。早期からテスト活動を始めることで、要件の考慮漏れの指摘につながったり、テスト設計までに仕様を深く理解できたりと、品質に対してもプラスに働きます。
原則④：欠陥（バグ）の偏在
これは、特定の機能にバグが集中するという考え方です。コードボリュームが多い、複雑な処理を実装している、他の機能との結合が多いなどの理由から、特定の機能にバグが偏る傾向があるのです。
原則⑤：殺虫剤のパラドックスにご用心
ある部分に対してあるテストをした際に、最初はバグが発見できたとしても、そのバグが修正されたあとも同じテストを続けていては新しいバグを見つけることはできません。新しい発見を得るためには、操作のタイミングをずらしたりゲーム内の状態を変えたりして、常に新しいテストをしていかなければ新しいバグは見つけられません。
原則⑥：テストは状況次第
テスト対象やテスト実施時の状況によって、テストの目的やテスト方法が変わってきます。
例えば、ECサイトではユーザーの個人情報を大量に取り扱うので、個人情報を流出させないためにセキュリティに関するテストが重要になってきます。ゲームでもセキュリティは重要ではありますが、それ以上にユーザビリティテストやユーザーテストなど「ユーザーが遊びやすいか」「面白いか」などを重視している傾向があります。
原則⑦：「バグゼロ」の落とし穴
徹底的に機能のテストをしてバグを取り除いてバグが出なくなったとしても、ゲーム内での画面遷移に毎回数分かかったり、UI上のアイコンが小さくて見づらくタップしづらかったりといったゲームができあがることがあります。しかし、これらはユーザーの不満につながる要素であり、バグではないとはいえ、こういった要素が残されている状態は品質がよいとはいえません。
「バグゼロ」は必ずしも「高品質」ではありません。バグ以外の部分にも気をつけましょう。
