Keywords Studiosによる「シリーズ：現代のゲーム開発をアンロック」を引き続きお届けする。今週はThomas Barth氏によるローカライズのQAについて。

　世の中のほとんどのゲームは，もはやある特定の国や，その言語のみでやっていくのが無理であることは明らかな事実だ。これはグローバルローンチで得られる普遍的かつ重要な経験である。

　よって，複数の言語へ翻訳されたゲームが，（例えば）フランス語やロシア語を母国語とする人でも，英語を母国語とする人と同じゲーム体験ができるように厳密にテストされることが極めて重要となる。

　これがローカライズの言語品質保証（LQA）の役割だ。各言語に翻訳されたゲームタイトルの内容（ダイアログ，テキスト，UI，サポート資料）を検証し，翻訳から生じるバグを発見し，記録し，解決する。

　LQAを成功させることは，世界中のすべてのプレイヤーが楽しめるゲームをリリースすることを意味する。もちろん，プレイヤーが話す言語に関係なく，その地域でのマーケットやゲーム文化をきちんと反映していないがゆえにプレイヤーの没入感を阻害してしまうことなくだ。

　LQAを成功させるためにベストな7つの方法を見ていこう。


1.　開発スタート時点でLQAを統合する
　まず第一に，初期のゲームデザインの段階からLQAプロセスを始めておくと，ゴールに向けて歩みを進むにしたがって発生してくる問題を大幅に減らす。つまり，検証プロセスや，検証テストそのものを減らすことができ，効率を上げるだけでなく，ほかのことにリソースを活用できる。

　例えば，メニューをデザインするときにUIとLQAが同期していれば，ステータスバー，字幕などのHUD要素は，翻訳するとスクリーン上でより多くの文字スペースを要する言語に合わせるために再度設計する必要がない。

　些細なことに思えるかもしれないが，ゲームの全体的なルックスの向上に加えて，プレイヤーが受け取る情報に大きな影響を与える可能性がある。言語とUIの統合によって，読むのに30秒とか3分とかかかるメニューを希望する人はいないだろう。


2.三つの「T」: テストの準備に失敗することは，ゲームの失敗につながる

事前テスト
　多くの開発者は，QAをする前に事前テストを行ったり，検証戦略の策定を検討したりしない。私自身やKeywords Studiosにとって，事前テストはLQAだけでなく，全体のQAにとって不可欠な要素だ。事前テストは一度行っておくとすべてのQAの包括的なバックボーンとなるので，可能な限りやっておいたほうがいい。

　事前テスト・フェーズには一般的に以下のようなものが含まれる。

• テストチームのための適切な進め方を計画する
• QAで利用できるデバッグツールに慣れ，それらを全体的なテスト戦略に組み込む
• ローカライズとQA対応のための疑似ローカライズビルドの検証
• バグ報告とバグ修正に関するコアプロセスの設定と文書化

　事前テストの時間を長く取ると，実際のテストのときにチームがテスト効率のピークに達するまでに要する時間が効果的に短縮される。

回帰/確認テスト
　ゲームは，QAが開始される後の段階を含め，制作のライフサイクル全体を通じて，絶えず開発や変更がなされている。

　そのうえ，さらにLQAのために修正すべきバグがあると，変更のための新しいコードが結果として追加の問題を引き起こす可能性がある。

　したがって，テスト結果が新しいビルドバージョンに反映され，その後も続く開発シナリオでそのバグが正しく対処されていることを確認するには，回帰/バグ確認テストを実行することが大変重要だ。

テストケース
　テストケースは，QAで使われる自己完結したゲームの領域だ。例えば，そのセクション内のすべてのアセット（サウンド，テクスチャなど）を網羅するレベルスライス全体などである。これらはQAアウトソーシング業者または主なデベロッパが作ることができる。

　これらはあらゆるテスターにとって，ツールキットの不可欠な部分であり，合否の基準を使用してエリア全体を承認できる。

　LQAの場合，この利点により，ゲーム全体をテストし，途中でエラーを修正し，もう一度最初から最後までLQAをやって変更した部分が他に影響を及ぼしていないか確かめなくても，後で行うチェックでセクション全体を削除できる。

　要するに，テストケースは効果的な進捗とカバレッジの追跡を可能にし，また回帰テストの必要性を減らす。首尾一貫したLQA戦略を確実にするために，テストケースは事前テストと一緒に計画され，作成されるべきである。


3．デバッグツールを利用する
　デバッグツール，すなわち「チート」を使用することはLQAテスターの隠れた武器だ。十分に装備されたさまざまなツールは，テスト中のプレイ時間を大幅に短縮することを可能にする。それは，ゴッドモードを許可したり，「クリッピングなし」で壁を通り抜けたりすることができるようになり，より頻度高くテストし，良い結果を出せる。

　ツールセットを共有し，ワークフローをさらに統合できるように，QAパートナーと協力してよう。

「LQAに複数の言語が必要な場合，それを一つのサプライヤに割り当てると，作業が楽になる」

4.用語集を使う
　ゲームデザインの中では，ローカライズチームが武器の名前，知識，架空の言語など重要な言葉の用語集を作成するのが一般的だ。LQA（ローカライズ後にゲームが実際に動作するのを最初に見た人）にとっては，用語集が不可欠だ。それは決定的な知識ベースと名前の付け方の一貫性を確実にし，翻訳エラーと矛盾がプレイヤーの没入感を阻害したり混乱させたりすることを防ぐ。

5.多言語チーム
　LQAに複数の言語が必要な場合，それを一つのサプライヤに割り当てると，作業が楽になる。一つのチームにさまざまなネイティブスピーカーを配置することで，バグ数と作業負荷を減らすことができる。例えば，エラーが英語（つまり原文の言語）の場合，5つの異なるアウトソーシング業者/言語からの5つの報告が来るのではなく，ネイティブスピーカーたちから一つの問題として報告されるだろう。
　多言語チーム内のコラボレーションは，チームの多様な性質が，均質的なチームでは見つけられないエラーを発見する機会を生み出し，一貫したクオリティの確立を可能にする。


6.コラボレーション：ゲーム開発は協力の産物
　上記のように，統合とコラボレーションはより速く，より良い結果を意味する。LQAとローカライズチームを統合することは，例えば，サービスとしてのゲームではとくに重要だ。なぜなら，継続的なアップデートでコンテンツが追加されていくときに，以前のケースをベースに何を事前にテストできるか知っておく必要があるからだ。

　この共同作業の知識を持つことで，次のコンテンツの一連をはるかに早くテストすることができ，小規模なアップデートで素早く対応することができる。

　多言語チームの中でも，チームの多様な性質が単一言語チームには見られないような複合エラーを発見する機会を増やすので，コラボレーションは品質を向上させる。


7.テスターに権限を与える
　これは，コラボレーションおよびLQAチームに複数の言語のネイティブスピーカーを配置することを意味する。ネイティブスピーカーであれば，基本的な言語バグ（例えば，綴り，文法，句読点の問題）を正式なタグとして挙げる必要はなく，直接問題を解決することができる。

　ネイティブスピーカーが自分たちのイニシアチブで働けるようにし，テキストを修正できる権限を与えよう。それによりバグデータベースの中の重要度の低い問題の量を減らし，翻訳チームの作業負荷を減らせる。

　Thomas Barth氏は，Keywords StudiosのローカライズQAディレクターである。QAとLQAで10年以上の経験を持ち，業界のあらゆる分野（デベロッパ，パブリッシャ，ハードウェアメーカー）の無数のクライアントと協力して，世界中のオーディエンスに等しく没入感のある経験を提供してきた。Keywords Studiosの詳細については。ここをクリック。