Deanne CurtisはPTW Montrealの品質保証マネージャーであり、数多くのゲームの発売を支援してきました。キャリアの中で彼女は、これまでに出会った数多くのパートナーが実行しているワークフローに、ある共通点があることに気付きます。QAの扱いが、開発プロセス全体に関わる重要な要素ではなく、開発の最終段階と見なされている点です。以下の内容は、2022年10月19日にカナダのモントリオールで開催されたMEGAMIGSでのDeanneによるプレゼンテーションから抜粋されたものです。

QAは製作パイプラインの企画段階からは外されることが多く、認証取得のための必要悪とみなされがちです。管理者はQAの必要性を理解してはいますが、QAが行われるのは通常、リリース前の最終段階となってしまいます。しかし、Deanneによれば、計画段階からQAを積極的に取り入れることで、結果的に開発サイクルが効率化され、リリース時のゲーム品質向上に繋がります。

Deanneの検証の結果、QAのこのような扱いはQAスタッフに対する認識に起因するそうです。QAスタッフはプロジェクトのあらゆる側面に触れるゼネラリストであり、エキスパートではないというイメージが定着していると言います。誰にでもできる仕事と思われているため、新人が多く配属され、真の専門性を身につけるまで長くは続かないのです。さらに、QAは開発の業務を批判することしかせずクリエイティブではないと見られがちなため、様々なケースで見過ごされてしまいます。

企画の初期段階でQAが外されてしまうのには、このようなネガティブな認識が原因となっています。ですが、適切な準備をすれば、QAはエラーを早期発見・修正できる継続的なガイド役となります。長期的には時間の節約になり、発売予定日の直前に納期を逃すことも避けられるでしょう。

大半のゲームデベロッパーやパブリッシャーにとって、認証の取得は目指すべきゴールです。認証なしにゲームは発売できないため、これは当然といえます。認証とは、対象プラットフォームのベストプラクティスに準拠することです。そのためには、要件のチェックリストをクリアしなければなりません。しかし適切に計画を立てなければ、開発終了間際に大慌てでチェックリストの確認に奔走することになってしまいます。そのため、手順がずさんになりチームへの重圧が増すばかりか、完成品のゲームの品質低下を招いてしまいます。

認証を後回しにしたことで不要なリスクを背負い、安定性に欠けてしまうと、QAチームをフルに活用できず（すなわち時間とコストが無駄になります）、部門間の知識共有度が低下し、ゲーム全体を熟知するQAチームがLiveOpsチームに参加できない結果となります。そうなれば、プレイヤーサポート業務も厳しいものとなるでしょう。

Deanneの主張では、QAが早期かつ積極的に関与することで、認証をスムーズに取得できるといいます。真のQA活用には、以下に示す様々な利点があります。

では、QAを巻き込んだ開発を実施するにはどうしたらよいのでしょうか？まずは、企画の初期段階からQAをコアチームの一員とすることから始まります。QAにはプロセス全体を見通せるようにしなければなりません。小さな問題が大きな問題になる前に特定し、より先のボトルネックになる可能性を予見することができるからです。

そのためには、QAチームの体制を理解することが肝心です。プロジェクトが始まると、Deanneはクライアントとミーティングし、戦略を立てます。ニーズに合わせて最適なQAチームモデルを提案し、専門性がクライアントに最も適したテスターを選定しています。

チーム体制には基本的に2種類あります。一枚岩タイプのチームでは、多数のテスター人員でチームを組みますが、この際テスターの専門性は考慮されません。このような場合、たいていプロジェクトは「ウォーターフォール」モデル（プロジェクト全体を直線的に進め、QAを最終ステップとする）で実行されます。このようなチーム構成では、テスターの質よりも量が優先されるため、必ずしも望ましいとは言えません。

一方、例えばソフトウェアQAや開発QAといった専門性を持つ少数精鋭のテスターを、個々のプロジェクトのニーズに応じて配置する方式もあります。この場合のプロジェクトは、テスターがクライアント側チームに完全に組み込まれる「アジャイル」方式で運営されるので、最良の結果をもたらし、熟練の個々のチームメンバーの力を最大限に引き出すことができます。このフレームワークにより、PTWとクライアントの全体が効率的なコラボレーションとコミュニケーションを行うことができるのです。

多くの場合PTWの専門テスターは、クライアントの開発チームに完全に組み込まれ、プロダクションチーム、開発者、社内のQAチームやリードと直接かかわって業務に取り組むことになります。テスターは若手から中堅まで幅広く、様々なコーディング言語に精通している場合は、実際に開発者としての業務に当たるスタッフもいます。

PTW Montrealのチームは、現在4つのQAチームが組み込み式となっています。このモデルは、あるクライアントが試しに組み込み式を行ったことから始まり、その結果が満足のいくものだったため、さらなるチームにも展開され、現在では他のクライアントにもご利用いただいています。

チーム体制が一度決定すると、今後のプロジェクトでもその形が維持されます。継続的に制度的知識を得ることができるので、その恩恵を常に受けられるのです。過去の開発プロジェクトで得た知見を活用し、関係者全員がプロセスの効率化を進めることができます。

時には外部のサポートベンダーに依頼し、柔軟で専門的かつ信頼性を高めることが最適な場合もあります。開発の一部を外部に任せることで、他のチームは得意分野に注力する時間を確保するのです。パートナーを選ぶ際には、適切な質問をすることが必要です。例えば、プロジェクトの具体的なニーズは何か、チーム内に必要な専門的知識を持つ人がいるかどうか、スペシャリストが特別に必要か、リリース時に必要なLive Opsのサポートは可能か、というようなことです。

パートナーにはそれぞれ特徴があるので、この要素を分析・評価し、最適なサービスベンダーの選定を行う必要があります。採用後は、外部チームを自社のプロセスに組み込むことを考慮しましょう。交流の窓口を明確にすることで、適切なチャンネルでコミュニケーションが行われるようになります。ガイダンス文書には完全にアクセス可能にし、プロジェクトの範囲を当初から定義してください。プロジェクトマネージャーは、動向に合わせて、方向性を変更することができます。

最後に、プロジェクト全体にとって重要なのは、QAがチーム内に馴染めるようにすることです。QAが部外者ではなく、プロセス全体の貴重な構成要素であることをチームリーダーが明言し、QAをカルチャーフィットさせましょう。プロジェクトの構造自体が、QAの参加を歓迎するものであるべきです。

このような体制の変更は、これまでに実績のあるプロセスからは大きく方向転換をしなければならないと感じる方もいるでしょう。しかし、一度正しく実施すれば、QAを早期に導入することの価値は、最終製品の品質で証明されるはずです。さらに、開発パイプライン全体にQAが関与することで、非効率な部分を明らかにして合理化を促進できます。必要な時には対応できる余裕を持たせた、首尾一貫し上手に管理されたプロセス形成に繋がるのです。