はじめに
皆様、はじめまして。
今回、海外リリースで必要となる日本語テキストの翻訳の正常性確認（翻訳QA：Linguistic Quality Assurance）を1年間実施した結果、実際に発生した障害傾向、および対策についてお話出来ればと思います。
翻訳QAは言葉に関する品質管理作業になります。ローカライズされたテキストがその言語のネイティブプレイヤーがプレイして、意図した翻訳になっているかどうかの確認を行います。
翻訳QAについて
翻訳QAは「翻訳された仕向け地別の各言語（テキスト）」の品質管理業務となります。各言語に翻訳されたテキストをネイティブプレイヤーがプレイして、「誤訳が無いか」、「違和感が無いか」、「誤認されないか」の観点で翻訳されているかの確認が主になります。
直近1年間で散見された翻訳関連の障害の傾向について少し記載します。
＜散見された翻訳問題＞
➀ 翻訳関連
・スキル、パラメータ内容の意味合い翻訳ミス（返金リスク：高）
・日本語原文に対する誤訳（返金リスク：高）
＜発生原因＞
・翻訳者（ネイティブスピーカー）の日本語原文の理解度不足
➁ 日付、タイムゾーン関連
・日付、時刻の記述ミス（返金リスク：中）
＜発生原因＞
・翻訳者（ネイティブスピーカー）の人為的ミス
➂ 表示関連
・文字崩れ、改行ミス（返金リスク：低）
・画像崩れ、画像見切れ（返金リスク：低）
＜発生原因＞
・固有端末の画面サイス起因
・固有名詞などの文字数制限
➃ 実装関連
・海外版での日本語表示（返金リスク：低）
・他海外言語の画像表示（返金リスク：低）
・お知らせ等で他海外の価格単価表示
＜発生原因＞
・翻訳箇所の共有漏れ
・設定ミス
・デプロイ時のマージミス
翻訳関連の障害は翻訳者の日本語原文の内容誤認による翻訳ミスが発生しやすい箇所になります。また誤訳による「優良誤認」の可能性が発生する箇所でもあり、返金リスクの可能性がもっとも高く、翻訳QAで最も時間をかけて確認する項目です。
日付関連は比較的少ない障害です。
主にタイムゾーン未表記により、ユーザーからは日本時間か現地時間かの判断が出来なくなり、結果「イベント参加に遅れた」、「アイテムを取得できなかった」等の不利益が発生しやすい箇所となります。
表示関連は最も多く障害が発生しやすい箇所です。
改行ミス、見切れなど軽微な障害も発生しやすいですが、その他、表記ゆれが最も多く発生する可能性がある項目です。
アイテム名、ガチャ名、イベント名など、過去のリリース済みの表現、記述ルールと沿っていないなど、「表記ゆれ」の定義は多岐に渡りますが、返金リスクに繋がる事はほぼ無く、翻訳QAとしても検証時間を短くする傾向にあります。
実装関連の障害の発生件数は少ないですが、海外ユーザーへの影響範囲の高い箇所になります。
発生理由の大半は「エンジニア側のビルド作成時のデプロイミス（設定ミス）」になりますが、翻訳QAは実装後の正常性確認を担保していない事が多く、実装ミスを発見する事が難しい箇所になります。
また実装ミスの原因として以下も発生事由の一因になる可能性があります。
＜リリース直前の変更による原因＞
バランス調整による仕様変更、スキル、パラメータ変更
リリース期間変更
翻訳QAチームとしての改善アクション
LQAチームとしての上記問題点の解決は以下となります。
ツールによる未翻訳箇所の検知
‐翻訳QA検証者のヒューマンエラーによる検知漏れを削減することが目的
‐新フォントの対応確認ツールの導入
‐ファイル容量削減などにより過去使用していたフォントを、
「別の新フォント（全角→半角への変更）」に変更しても、該当箇所を
検知出来るツールを導入。
開発チーム、翻訳チームとの連携強化
‐仕様変更発生時のLQA再確認時間の確保が目的
‐プロダクトによる変更発生の早期キャッチアップ実施、翻訳チームとの
翻訳問題の共有化を行い、次施策の翻訳向上、LQAチェックの
再スケジュール化が可能。
他部署（プロダクト側、翻訳チーム）との定期ミーティングを強化し、問題点の共有化を重視する事で過去発生の翻訳ミス等の「12％」削減を実施し、結果、翻訳確認に要する翻訳QA確認時間も「15％」削減が可能となりました。
今後のLQA確認方法について
現在、翻訳QAの喫緊の問題として以下の内容があり、改善を実施中です。
翻訳QAの合格範囲の統一化
プロダクトによって翻訳精度の許容範囲が異なり、翻訳チェック側のスタッフが困惑する事があります。この許容範囲の統一化を行う事で無駄なフィードバック、修正依頼を削減する事が出来、さらに翻訳QA側、翻訳者側でのコストを削減出来るメリットがあります。
※プロダクトへ継続的に確認粒度の統一化を打診し、問題点の改善を要求する。
2 LQA側での確認を「目視確認」→「自動化チェック」へ
翻訳精度を自動化チェックする事で製品精度の向上を見込めるほか、検証時の問題点である「俗人化」の解決（誰が検証を実施しても同じ精度でチェックが出来る）も可能になると思います。
デメリットとしては自動化用の用語集、仕様書などの資料作成が必須であり、プロダクト側のコスト増加の問題があります。
3 本番ビルドでの実装の正常性確認
ビルド作成後の本番ビルドで各海外言語が正しく表示されているか（実装されているか）の最終確認の必要性が高いと考えていますが、「リリースまで時間が無く、確認時間が無い」、「コスト増加」、「そもそもどの部署が実装担保するのか」などの問題の解決が必須となる事案であり、実施には大きな壁があります。この問題の根本には「日本語原文のFIX遅延」、「開発遅延」などプロダクト側に起因する原因が多く、まずは「開発スケジュールの前倒し」を関係各所との協議、コミット、検証フロー化をしていくことで改善出来ると思います。
最後に
今後も翻訳QAによる「障害（バグ）」を世に出ないよう駆除する為、一層効率的な方法を見つけて実施する事を目標として尽力しようと思います。