LQAは内製か外注か — ローカライズQAの体制をどう決めるか
翻訳が納品されました。次は、誰かが各言語でゲームを実際に遊び、テキストが間違っている場所、切れている場所、抜けている場所、別の文言が出ている場所を見つける必要があります。その「誰か」を自社の人間にするのか外部チームにするのかは、翻訳を誰に頼むかとは別の判断です。そして多くの会社で、この判断は意図してではなく成り行きで決まっています。
LQA(ローカライズQA)は、QAの中でも扱いにくい性質を三つ持っています。必要な技能が言語固有で代替できないこと — テスト経験をいくら積んでも、韓国語を読めない人が韓国語のテキストを判断することはできません。作業量が波打ち、マイルストーン直前に集中すること。そして実ビルド上でしか実施できず、その時期はプロジェクト全体で最も日程が混み合う区間だということ。この三つが重なるので、体制の判断が難しくなります。
この記事では体制の選択肢を比較し、判断のためのフレームを示します。LQAが何を見る工程なのか、表計算ソフト上で訳文を読むのとどう違うのかは、すでにご存じの前提で進めます。
この仕事に実際に必要なもの
体制を比べる前に、何のために人を確保するのかをはっきりさせておく価値があります。外から見ると分かりにくく、しかも一つ条件が増えるたびに、担当できる人が確実に減っていくからです。
- 対象言語をネイティブ水準で読み、正確さだけでなく語調やレジスター(場面に合った言葉遣い)まで判断できる人
- コンテンツに到達できるだけのゲームの腕。ボスを倒せない人は、その先のテキストを一行も確認できません
- 不具合報告の作法。再現手順・スクリーンショット・文字列キーが揃った報告は対応できますが、「スペイン語がなんか変」は対応できません
- 対象プラットフォームで動くビルドへのアクセス。しかもテキストが十分に確定し、報告が無駄にならない段階であること
- テスト用アカウント、各エリア付近に置かれたセーブデータ、そして一行を見るために12時間遊び直さずに済むデバッグ機能
- テキスト確定後、提出前という日程上の枠。プロジェクトで最も奪い合いになる区間です
性質の違う二つの仕事が混ざっている
最初のLQAパスで報告される内容のかなりの割合は、言語の判断とは関係がありません。未翻訳・空欄、壊れたプレースホルダー、枠からあふれたテキスト、文字化け、対応の取れていないタグ、文字数上限を超えた行。これらは機械的な問題で、訳文の出来とは無関係に真偽が決まり、その言語を読めなくても検出できます。
この区別が体制の話に効いてくるのは、二つの半分でコストの伸び方が正反対だからです。機械的な問題はビルドが存在する前、ファイルの段階で見つけられ、量が増えてもコストがほとんど増えません。言語としての判断は、資格のある人が実際にゲームを遊ぶ必要があり、コンテンツ量・プラットフォーム数・言語数の掛け算で増えていきます。
どの体制を選ぶにせよ、機械的な層を先に通してください。40行が未翻訳のまま残っていることを、ネイティブ話者にビルドの中で発見してもらうのは、最も希少な資源を最も安い発見に使う行為です。しかも本来拾ってほしい言語的な指摘が、そのノイズに埋もれます。内製か外注かという問いは、実質的には後半の仕事についての問いです。
必要量は波打ち、しかも各社の山は重なる
LQAの需要は平坦ではありません。年に2回リリースするプロジェクトなら、数か月はほぼゼロで、各リリース直前に言語ごとに数週間のフルタイム相当が発生します。どの体制も、結局はこの形とどう付き合うかの方法です。
内製は、谷を自社で抱えることを意味します。年に2回しか出さない言語の専任テスターは、継続的に費用が発生して使うのは一瞬、という状態になります。間の期間に意味のある仕事を渡せるなら別ですが、それはたいてい「純粋なLQA専任ではない」という設計であり、それは妥協ではなく妥当な設計です。
外注は、山で競合することを意味します。ベンダーは自社全体の需要に対して人を張っており、リリース時期は年に数回の山に固まります。混み合う四半期に遅れて枠を取ろうとすると、待つか、特急料金を払うか、こちらのゲームを知っている人ではなくその時空いている人を受け入れるか、という選択になります。
どちらを選んでも結論は同じです。希少なのは日程上の枠であり、必要になる前に押さえておく必要があります。「ビルドができたらLQAを始める」と決めるのは、実際にはそれより遅く始めると決めることです。人が確保されていないからです。
内製が効く条件と、外注が効く条件
内製が固定費に見合うのは、作業が継続的で、言語数が絞られている場合です。定期的に更新する運営タイトルは安定した仕事量を生みますし、母国市場+主要1言語程度なら人員も説明が付きます。本当の利点は時間単価ではなく、ループの速さです。社内のテスターなら、曖昧な箇所をライターと数分で解消できます。翌日のメール往復にはなりません。さらに、過去の判断、過去の修正、用語をめぐる議論といった組織の記憶が蓄積します。入れ替わる外部チームには決して溜まらない部分です。未公開コンテンツが社外に出ないことも、秘匿性の高いプロジェクトではすべてを単純にします。
外注が効くのは形が逆のときです。同時ローンチで一度に多言語を見る必要がある場合や、リリースが稀で谷のほうが山より長い場合。ベンダーは、自社で買って維持しなければならないもの — 実機、開発機材、OSのバージョン違い、端末群 — を抱えていますし、現地採用が現実的でない言語もカバーします。他タイトルで提出まで回してきたチームは、プラットフォームの審査で落ちやすい箇所を経験として知っています。これは資料を読んで得られる知識ではありません。
どちらが品質的に上、という話ではありません。4回のリリースを通してこちらのゲームを見てきた外部の翻訳者は、先月LQAに配置換えになった社内の担当者より確実に良い仕事をしますし、その逆も同じくらい成り立ちます。体制が実際に決めているのは、継続性、応答の速さ、そして日程上のリスクのうちどれだけを自分たちの手元に置くか、です。
多くのチームが行き着くハイブリッド
実務では、多言語で出しているチームはたいてい同じ形に落ち着きます。「内製で持ち、外部で量を賄う」という形です。プロセスは自社が持ち、山が来たときの各言語のネイティブパスをベンダーが供給します。
社内側が持つのは、チームに拡散した責任ではなく名前のあるプロセス責任者、不具合のトリアージ、修正の再確認ループ、ビルド間の回帰確認、そして毎ビルド自動で回る機械的検査です。社外に出すのは、範囲とブリーフを定めた言語ごとのネイティブパスで、混み合う数週間に集中させます。
ハイブリッドを機能させるものは地味です。ベンダーごとの表計算ではなく一つの不具合トラッカー。共通の重大度定義 — 外部テスターの「Critical」と社内の「Critical」が同じ意味であること。一つのビルド配布手順。パスごとの書面のブリーフ(今回何を見るか、既知の問題は何か、範囲外は何か)。そして、ベンダーの就業時間中に連絡が取れる社内の担当者。質問が返ってこないまま止まったテスターは、有償の稼働を一日単位で燃やします。
壊れ方も同じくらい予測可能です。ブリーフなしでビルドだけ渡して有用な報告を期待すること。ベンダーの報告をトリアージせずそのまま確定として扱うこと。そして修正の再確認を省くこと。最後の一つが最も多く、最も高くつきます。直したが後のビルドで確認していない不具合は、直っていません。それは希望であり、社内の誰も読めない言語でプレイヤーに届く事故の、典型的な出どころです。
言語ごとに決める、そして計画から抜け落ちるコスト
判断はプロジェクト単位ではなく言語単位で行います。1言語だけ内製で、残り8言語はベンダー、という構成は優柔不断ではありません。作業量の形が組織図に現れているだけです。
どちらを選んでも、最初の計画から確実に漏れる費目がいくつかあり、LQAのサイクルが超過するのはたいていそこです。立ち上がりのコストは毎回発生します。外部チームは、同じ人を名指しで指定し、かつその人が空いていない限り、毎回こちらのゲームを学び直します。だから継続性は「そうなればいい」ではなく契約に書いておく価値があります。ビルドの配布、NDAの書類、アカウントの発行も、各サイクルの冒頭で実日数を消費します。社内のトリアージも一つの仕事です。誰かが届いた報告を全部読み、重複をまとめ、不具合なのか好みの違いなのかを判断します。そしてその人はたいてい、日程上いちばん余裕のない人です。
そして二回目のパスがあります。修正の再確認は最初のパスの脚注ではなく、もう一度のビルド、もう一度の日程調整であり、ベンダー案件ではもう一度のミニマムチャージになることも多いものです。LQAを1パスで予算化しているチームは、実際に走らせる量の半分を予算化しています。
最後に、時差は両刃です。12時間の差は、こちらの終業時にビルドを渡し、翌朝に報告を読むという一晩の折り返しをくれます。同時に、返答のない質問一つが有償テストの丸一日を溶かす原因にもなります。どちらになるかを決めるのは地理ではなく、こちら側に連絡の取れる人がいるかどうかです。
これらのコストを机に載せたうえで、判断そのものは短い問いの列に落ちます。出荷する言語ごとに、それぞれ答えてください。
プロジェクト全体で一度ではなく、言語ごとに答える: 1. 頻度 : この言語のLQAパスは年に何回あるか 2. 分量 : 1パスあたりの工数(コンテンツ量 x プラットフォーム x 設定) 3. 重要度 : ローンチ市場か、後から足した言語か 4. 採用可能性: この言語の人材を、そもそも自社で採用できるか 5. 実機 : テストに必要なハードとアカウントを自社で持っているか 6. 折り返し : ビルドを渡してから修正確認までどれだけ速く回す必要があるか 7. 秘匿性 : 未公開ビルドをNDA下で社外に出せるか 高頻度 + 少言語 -> 内製をコアに 低頻度 + 多言語 -> ベンダー その中間 -> 社内に責任者、量はベンダー