対象読者

趣味のゲームクリエイター（非エンジニア）
ゲーム開発に興味がある方

エンジニアの定義が難しいけど、ゲームクリエイター（アマチュア）向けに、ゲームテスター（QA）で参画していた時の話を公開できる範囲で提案と注意喚起をしたい。

話さないこと

ベストプラクティス
- 筆者も未だ模索中…
- 主事業ではないため、類似案件を今後受けるとは限らないため更新予定がない

ゲーム環境

ジャンル: RPG
プラットフォーム: PC(ブラウザ）、モバイルも動くけど動作確認対象外
エンジン: オープンソース

最初から炎上

ゲーム開発者は非エンジニア（ソースコード改変できるレベル）、ゲームテスターがエンジニア経験者、という、まぁすごい環境での参画となった。
ややこしいが、ゲーム開発者とはエンジニアリング的な開発者ではなく、ただのゲームクリエイターと意訳して欲しい。

当初の筆者の業務内容はデバッグ作業だった。
ついでにいちユーザーとしてレビュー（改善希望を含む提案）を上げる事を期待されていたが、実際に参画してみると、まずデバッガー陣（外注メンバー）がチームとして組織されていなかったのでテストチームマネジメントと、バグシートの運用管理の促進などサブマネジャー的位置付けで開発者が細々と持っていた雑務を一手に受けてのハブ役を担う事にした。
そうしないとゲーム開発者の手が取られて開発に時間が割けず、テストチームに待ちが発生する可能性が高かったからだ。
開発のリソースが足りず、テスター余りの状態が発生するというのはゲーム開発あるある（？）かもしれない。
開発の手が足りずに仕様で片付けないようにしたい、という思いが強かったので、連絡の交通管理（トップダウンのシステムツールとボトムアップのシステムツールの運用徹底）と、契約内容外だが個人的に応援したいという気持ちもあり、開発支援ツールを提供させていただいた。
開発者もゲームに対する思いは強く、毎日（土日も含んで）頑張っていたものの状況はなかなか改善しない。ゲームのクオリティを上げるためのデバッグ作業とはいえ、根本的な部分に課題があったので非常に慎重なレベルデザインを求められた。
筆者もやや設定にこだわりが強いので、自身がゲーム開発をするなら？（していた時の経験）という観点で数値や難度調整と、ゲームのこだわりポイント、いわゆる実績があり、ある程度の縛りプレイを試してみるなど「開発者目線」でも試してみることで、ゲームの二週目・三週目を促す仕組みを検討した。
（本来、周回プレイを想定する場合は多少のシナリオ追加や変動はあった方が良いのだが）

とはいえ、目下炎上中で周回プレイの話を作り込むのは危ないので、優先順位づけと作業分担の割り振り、次回作への課題（挑戦）として上げるようにした。

最終的には、テスト後半に全体設計部分にかなり影響のある修正があったりしたため、契約期間中に吸収しきれない課題があったため、ある程度の対応と引き継ぎをして終了という形になった。
その後、無事発売となったが、それまでの開発陣の奮闘たるや。

お願い（本題）

本案件はかなり特殊な環境にある、が大体どのゲーム開発現場もそれぞれのコミュニティとか現場の色が強く出る（と筆者は感じている）ので、特殊ではない現場の方が少ないのかもしれない。

仕様書

今回入った現場は仕様書が全くなかったため、仕様整理から始まった。
が、仕様整理ばかりしていると作業が全く進まないため、仕様についてはクリティカルな部分だけ取り上げて、違和感のない部分はいったん対象外という形にしたため、テストステップを大量に省略する事にした。
具体的には、後述の記事でいえば起動直後の画面におけるレイアウトやタイトルロゴ、ボタンジャンプなどの遷移先についてはゲームエンジンの仕様による部分が大きいので、テスター側がエンジンの仕様把握に努める事として（後でわかった事だが、テスターはほぼ全員が別作品での同一エンジンでの開発者または開発経験者だった）オリジナル部分に注目しての仕様を書き出していく。
実際はどのレベル感での仕様が必要になるかというと、以下記事がとても詳しく取り扱っているので引用したい。

関係者ご各位

本案件のご担当者の方が本稿を見ているかわからないが、関係者だけに向けて言及したい。

上記記事のレベルで書き出すと、たとえば主人公のクラスデータやスキル、アイテムなどの効果も仕様に書き出す必要がある。
また、ダメージ（特に属性相性系）やレベルアップの計算式もあると、最適な行動をするユーザー（ゲーム巧者）と変な行動をしたユーザー（RPGが苦手な方）との差を取りやすくなる。
特にレベルアップの計算式はデフォルトを採用するケースが多いように思うが、きちんと理論があるので、興味があれば参考にされたい。

計算式の内容を把握するのは大変なので、とりあえずは具体例の部分だけで良い。

ゲームテスターのスキルと、テスト自体のスキルを理解いただく

本稿では便宜上、テスターという表現を採用したが、世の中にはQA＝品質保証という職種が存在している。
なお、ソフトウェア業界ではあまり出てこないが、QCというのも存在しており、どちらも製品の品質に関わる大切な役割を担っている。
いわゆるテスターとは何が違うのか、というのは専門家の記事が詳しい。

発注いただく際は「誤字脱字の確認だけしてもらえばいいです」というクライアントもいるし「ゲームの問題点を洗い出してください」という全体的にふんわりした発注をされるクライアントもいるので、ご予算に応じて作業範囲を相談の上決定するようにしているが、更に予算が積めれば問題点の解決やより精度の高い提案をさせていただくことも可能である。
ここで言及したいのは、とりあえず募集してとりあえず集まった方々に対して、きちんとスキルチェックをした方がいいよ、という事である。
たとえば、一言でゲームテスターと言ってもクライアントによって求めるスキルはバラバラだし、テスターもテストをするという観点で慣れているジャンルはそれぞれに異なるだろうし、一概に「テスター経験あります」という言葉を鵜呑みにしてしまってはいけないということだ。

本来であれば、業界全体としてゲームテスターのスキルを定義して資格化するべきだが、残念ながら現状はそうなっていない。
一応、JSTQB認定テスト技術者試験というものはあるが、あくまでソフトウェアテスト全般が対象なので汎化したものに過ぎない。
が、一般に無資格OKで募集するよりは高い知見を持っている事は確かである。

もちろん、彼らは歴とした「ソフトウェアテストのプロ」なので予算面で決して安くはない。

ナレッジの全体化する効果

これはテスターあるあるかもしれないが、何回も同じ場所を走っていると「こうすればうまくいく（失敗を再現しやすい）といった手順のようなものが確立されてくる。
これを全体に共有する事で生じるメリデメが表裏一体であることを認識してほしい。

ナレッジを共有化する（タスクチケットで管理し、テスターに公開する）ことでテスター全員が同じ手順で再現確認をする傾向が出るため全体として見ると作業負荷軽減になる
再現手順を画一化してしまうことで、他の手順による再現確認の機会を失ってしまう可能性がある

ゲームの品質を上げたいなら、開発者とテスター個別とのやりとりをする形式で進めるべきだが、テスター全体で共有すべき事項についてはこの限りではない。
また、テスター間でのコミュニケーションについて許可するかどうかも上記で判断したい。

ツールの取り扱い

非エンジニアに使ってもらってこそ、というのは私個人の哲学としてあるので、開発支援を目的に自分用のツールを提供するようにした。
本当はテスターの方にも提供したいが、ここでは技術分野についてはNDA（基本契約書などの内容も含む）を締結しなかったため、横展開は残念ながらできなかった。
おそらく開発サイドもツールの提供があることを想定していなかっただろうと思うのでやむなしだが、特にエンジニアはツールの提供時はメンテナンスコストがかかる事も想定しておきたい。
また、ツールを作成・使用したことで著作権その他について揉める事になるので、クライアントが信頼できる方でない限りは個人使用にとどめた方が懸命だ。

今回は最初から開発のご厚意でテスターがかなり優位な形でご対応・ご高配をいただいていたので、返せるものは返したいという意図があったので、他テスターへの横展開以外は許容している。

本稿で言いたい事

様々なツール・ゲームエンジンの簡易化により普及してきたが、本来のゲーム開発は高度な知識が求められる。
企画力やストーリー構成、イラストやサウンドといった面に目を向けがちだが、RPGだと特にレベルデザインや演出面（エフェクトを含む）だったり、場合によってはプラグインなどゲームエンジン固有の拡張機能が必要だったりする事もある。
作る以外だとマネジメント面（特に納期を指すが、本稿ではテスターが主題）や、テスターのスキル管理と把握も必要になる事がある。
全部をやるのは当然幅広い知見が必要になるので、いっそのこと専属契約で囲い込んでしまったり、コンサルを置く方法もある。
無論、予算の都合もあるだろうと思うので無理はできないが、今まで目を向けてこなかった分野にも専門スキルがある事を認識されたい。