##概要　
この記事ではゲームQAを行う際、
仕様書の記載内容が抽象的、UIの情報ばかりで機能仕様の情報がほとんどない等の為にテスト項目の作成が進まない、抜け漏れが多数ある、そもそも抜け漏れがあるかも判断が難しい、ある一機能が多数の画面に配置されているためテスト項目が掛け算式に増えていく、不具合(バグ)修正が元で生まれた新たな不具合(バグ)を見落としてしまった。
などといったいくつかの問題に対して、「ゲームの仕組み」を知っておくと情報の少ない仕様書でもテスト観点の抽出を行ったり膨大なテスト項目の削減など、QAとしての考え方にも活用できると考えています。
その活用事例の一部を、実際のQA業務を元にして紹介させていただこうと思います。

※本記事での「ゲームの仕組み」とは、ゲームプログラミングを指しています
プランナーが仕様を考え、デザイナーがUIやキャラを描き～～といった話ではございません。

##テスト項目の抜け漏れや過剰が発生する要因　

テストの抜け漏れや過剰が発生する要因としては多数あるかと思いますがここでは
テスト項目の抜け漏れを「テスト観点の不足」としその要因に着目し、
テスト項目の過剰を「テスト範囲を過剰に見誤った」としその要因に着目したいと思います

テスト観点が不足した要因
仕様書の記載が曖昧で仕様を誤って認識していた
仕様書に記載のあることしかテストしていない
バグ修正時の修正確認をバグが再発しないか？のみのテストしている
テスト範囲を過剰に見誤った要因
マスタ(データ)の変更箇所の数＝テスト項目数になっている
同じ1つのマスタ(データ)を参照している複数の機能全てにまったく同じマスタ反映確認のテスト項目数になっている(データ数×機能)
複数の画面に配置されている同一の機能全てにまったく同じ項目数のテストをしている

上記が原因で発生するテスト観点・範囲の不足または、過剰のいくつかはゲームの仕組みを知ることで、
テスト観点の抽出や適切なテスト範囲の抽出に役立つと考えています。

##テスト観点の抽出
仕様の記載が概要のみ、曖昧、など仕様書を読み込むだけでは拾いきれない個所にはバグが潜んでいる可能性が高いです。
原因としては、記載が曖昧なために仕様書作成者の想定している実装と担当開発者の認識で実装した内容にズレが生じている場合が多く、そこさらに別の開発者が他機能との結合を行うとなるとまたズレが起こりやすくなりその結果バグが生まれやすくなります。
もちろん、そのような場合、開発チーム間ですり合わせを行って補っているケースも多いですが、そのすり合わせ情報がQA（特に外部QA）にまで降りてくるケースはあまりないのではないでしょうか。
その結果、QA側は仕様の認識を誤ったままテストを行い、そのズレが運悪くうまくかみ合ってしまい、意図しない動作にも拘わらずテストOKとなってしまうケースもあります。
そのようなケースに潜む不具合やテスト観点は漏れてしまっても致し方ない　とすることもありますが、
それでも、ゲームの仕組みを知っていると知っていないとでは、漏れやすさに差があると考えます。

例としてあるスマホゲームアプリでゲーム内に現実の時間を表示するという機能があったとして、
仕様書には「時計オブジェには現実の時間を表示します」という記載のみでした。
そのため、テスト項目は

といった1つの項目をテストしました。
しかし、この時間を表示するためにシステムは、利用者のスマートフォンから時刻の情報を参照してるという仕組みであったために、スマートフォンの時刻設定を現実の時間ではない時刻に設定変更すると表示される時刻が実際の現実の時刻とは異なってしまう(設定変更した端末の日時を表示している)という市場バグが発生しました。

こちらのバグは仕様書に「端末の時刻を参照している」といった、「アプリがスマートフォンの情報(設定)を元に動作している」という「情報がない」ためにテスト項目が漏れてしまいました。
このように仕様書に詳細な情報がなく、バグの事例や経験がないケースでも、
このような類の機能はこういった仕組みで実装(動作)している場合がある、またはしている。
といったゲームの仕組みの知識からテスト観点の抽出が行えテストの抜け漏れ(バグの市場流出)を防ぐことにつながります。

他にもバグを修正したことによって新たなバグが生まれるケースは少なくないですが、このようなケースのバグを発見する為の観点の抽出も、仕組みを知っているかどうかで観点の抽出量（バグ検出率）に差が出てくると思います。

此方も実際のところ、開発チームの行ったバグの修正に対して「〇〇の不具合を修正しました」といった旨の連絡があった際「いったいどのような修正を行ったのか？」を知りたいと思うQAの方は多いのではないでしょうか。
そういった方々はゲームの仕組みをある程度理解していて「修正内容によっては他の機能への影響を及ぼす可能性やその範囲が変わってくる」ということを認識しているからだと思います。

不具合修正による新たなバグ発生の事例があるといった経験だけでは、影響を及ぼす可能性や範囲を予測するのは難しいので、やはりゲームの仕組みをある程度理解しているかどうかでこのあたりの観点や範囲の抽出率も変わってくるかと思います。

##テスト範囲の抽出
また、テスト観点を抽出する考え方だけでなくテスト範囲を決定する際の考え方にも生かせます
例として、敵キャラ100体分のステータスマスタ(データ)の値を変更したためその反映確認テストをするといったシチュエーションの場合

　　　　　　　　　　　　　⇩⇩⇩

このマスタが既に一度動作が保証されたテスト済みのマスタであった場合、ゲームとマスタの関係に一定以上知見があれば
変更を行った100体分のデータ全てテストが必要だと考え「100体分のデータ全ての実機確認しテストを行う」のではなく、
いづれか1体分のデータをテストし正常であれば他のデータも変更後のマスタが正常反映されているとみなし「1体分のデータの実機確認で100体分をテスト完了とする」考え方も選択肢の一つとして抽出できます。
実際のテスト項目数はデータの変更内容やアプリとデータの仕組み(関係)により異なってはきますが、同じような考え方でテストを行っているQAチームも少なくないと思います。

仮に上記のようなシチュエーションで全データのテストを行うとなった場合でも、開発チーム(または外部の開発会社) は
「テストのことは良くわからないから、QAチーム(または外部QA)に任せる」「信頼しているテストのプロにまかせる」などといった
良い意味の理由で、たとえ開発チームとテスト計画やテストケース(項目)のレビューを行い、そこで開発チーム側は「全データ見なくてもよいのでは？」と感じていたとしても、このような話しは議題に上がらない、提案されない場合が多く、結果レビューは指摘無しとなりQAチームはそのまま変更を行った全データに対してテストを行い、テスト項目が膨大になってしまうといったことになりえます。

ゲームの機能的な面で例をあげると、所持アイテムの一覧をソート及びフィルターできる機能のテスト項目数が200項目程あるとします。
そして、その機能を持つ所持アイテムの一覧を表示する画面がインベントリ画面、ショップの所持、アイテムを売る画面、倉庫へアイテムを入れるときの画面などなど複数の機能(画面)にわたって存在している際、すべての機能(画面)で200項目のソートフィルターのテストを行うと項目数が非常に増加してしまいます。
ですが、このソートフィルター機能は全ての機能(画面)で同一のプログラムを呼び出し参照しているとした場合、1つの機能(画面)で200項目をテストしてソートフィルター機能の動作を保証し、残りの画面では必要最低限の項目数に削減する。といった考え方でテスト範囲を絞り、効果的でないテスト項目の過剰化を防ぐことができます。

そのため、QA側からも「〇〇機能が〇〇〇といった仕組みの場合、網羅するテスト対象を〇〇に絞り他は簡略化することでテスト項目を〇〇件ほど削減が見込めます」などといった工数削減案の提案も必要があると感じています。
※結局のところゲームの作り(仕組み)次第なので、開発チームとすり合わせは必須です！！

##「ゲームの仕組み」を知るためにはどうすればよいのか？
個人的には「自分でゲームを作ってみる」ことをおすすめしています。
独学となるとハードルが高いように感じる方も多いかもしれませんが、最近は開発ツールが無料で利用できたり、ツールの提供元がゲーム作成のチュートリアルを用意していたり、独学でゲームプログラミングを学んだ方々が方法やコツなどのネット記事を書いていたりと、独学かつ、プログラミングの知識ゼロからでも始めても、実際はそこまでハードルは高くないと思っています。
その際、学習に使用するゲーム開発ツール(フレームワーク)はメジャーなものがお勧めです。
逆にあまりメジャーでないツールだと、公式のガイドやチュートリアルが英語のみ、調べても情報があまり出てこない(あっても英語のみ)など学習する上での不都合が多いためです。
その点、メジャーなものは上記の理由の他、利用者も多いので独創的な仕様の機能の実装方法、バグ発生時や詰まった時の解決法など踏み込んだ情報の展開量が多い為です。
環境の用意が難しい、時間があまりとれない方やそこまでするのはちょっと、、、と抵抗を感じる方は、
お手軽カジュアルに取り組む方法として、任天堂より発売されている「ナビつき! つくってわかるはじめてゲームプログラミング」というNintendo Switch用ゲームソフトも非常におすすめです！
ちなみに、私が初めてプログラミングを独学で学ぶ際に使用したものはゲーム開発で知名度の高い「Unity」を利用しました。（今でも利用しています！）

##実際に自分でゲームを作ってみる際の流れ
始めは、公式のチュートリアルを利用してツールの使い方と初歩的なプログラミングを学び。
その後は、自身でネット記事や実装したい機能の実装方法など調べながらゲームを作っていくといった流れになると思います。
また、その際に実装する機能はあまり独創的なものではなく一般的なものを中心に実装するほうが幅広いゲームQAに役立つ知識が得られるのでそちらをお勧めします。
一般的な機能の例でいえば、プレゼントBOX機能やショップ機能などといったどのようなゲームでも実装されていて、かつ想定される動作もほぼ同じようなものが良いと思います。
そうして、初めのうちはシンプルな仕様で実装を行い、慣れてきたらパラメータなどのデータをソースコード（ハードコーディング等と呼ばれるもの）ではなくデータベース(いわゆるマスタデータ)で管理するようにしたり、自分で仕様を考え実装するのではなく、何かしらのゲームを参考にしそのゲームを再現するように実装を行い、その仕様を実装しようとしたことにより起こりうるバグなどテスト観点につながる出来事が体感できるかと思います。

##まとめ
テスト項目の作成や実行を行わずにテスト観点に活用できる知識や考えを深められ、それだけではなく開発チームへの質問やレビュー、ミーティング時等にプログラミングに関する会話が行われてもある程度理解ができるようになるなど、テスト実行だけでなくQAを行う上で利点となることが他にも多く学べると思います。
学習は手すきの時間やプライベート時間でも少しづつ取り入れることができますし、「Github」などのソースコード管理サービスを活用すれば、複数のPC(環境)でも同一の作業が可能なので職場や自宅など場所を問わずに学習を進められます。
また、昨今は中学校でもプログラミングの授業が取り入れられてきている時代ですし、もう少し先のQA業界は、例え一QAであってもプログラミングの知識が求められてくるようになるのではないかと感じています。
ゲームの品質を高めるため、ゲーム開発に興味があるが手を出せてない人はもちろん、ゲーム開発に興味もなく、ゲームプログラミングをしたことが無いとった方も、これを機にゲームプログラミングを学んでみることを是非お勧めします！