汎用型翻訳検証観点表を「実務」導入してみた

■はじめに

皆様はじめまして！師走を満喫している @Sekimendy です。
12月は師すら走るほどの忙しさとは良く言ったもので、イベントの多い12月を表現する粋な異名だなぁと感じている反面、英語だと”December”となりそのコンテクストを含められないところにもどかしさを感じているゲームローカライズ従事者です。(因みに”December”は10を意味するラテン語”decem”が由来らしい。)

ゲームローカライズ従事者と言っても沢山の職掌があるかと思いますので、本題に入る前に軽く私の経歴を紹介をすると、海外PMとして複数ソーシャルゲームタイトルのローカライズの翻訳現場に従事した後、ゲーム翻訳QA(以下、LQA）として別角度から現在はゲームのローカライズに携わっています。
月日の流れは早いもので、私もLQAに従事してまるっと1年が経過しました。

今回は、ゲームLQA現場に汎用的な検証観点表を実務導入してみて得た効果と、同時に見えた課題について共有できればと思います。
ゲームローカライズ現場で少しでも役立てば幸いです。ぜひ参考にしてみてください。

■そもそもLQAとは

前回の記事でも少し触れましたが、まだまだ認知度は高くない職掌かと思いますので改めて紹介です。

LQA(Linguistic Quality Assurance)とは、翻訳QAともよばれ、「言語品質保証」という訳のされ方が世間一般になります。
ゲームにおいては、翻訳テキストの画面上でのテキストの収まり具合や、ゲーム全体における翻訳の一貫性、翻訳先言語の文化や習慣から見て問題ないか、といったことを確認する業務が一般的です。

ゲームQAの対応範囲にある程度の通念があることに対して、ゲームLQAの対応範囲は未だ発展途上であり、各プロダクトやサービスが求める形に適応して変化しているのが多くの現場での現状であると思います。

■翻訳検証観点表とは

次にゲームLQAの現状を踏まえた上で、今回の記事の主役である「翻訳検証観点表」について紹介です。

「翻訳検証観点表」とは、弊社主催の他社合同品質研究会で検討された実験的な「ゲームLQA検証観点表」で、明確な形が定まっていないゲームLQAの検証観点を体系的に示すものとして作成されました。

▼ゲームLQA検証観点表(プロダクト要件に合わせて詳細を記入した例)

今回は、研究会の活動の一貫としてこの「翻訳検証観点表」を実際に新規プロジェクトでの検証観点基準として実務に適用してみた事例をもとに、その効果と課題に感じた部分と合わせて、現時点での改善考察を紹介できればと思います。

■実務への適用と効果

• 観点表をベースにプロダクト¹側へLQA実施内容、品質担保範囲を説明
  実務に適用してまず効果があったことは、LQAの検証範囲と担保する基準をLQAの理解度が浅い相手に対しても効率的に理解してもらうためのツールとなった点が挙げられます。
  
  ゲームLQAとして見る部分、見ない部分、誰がどこを担保するのかなどのプロダクト側への業務内容説明を簡略化できました。それだけでなく、正しく理解してもらえたことで開発チームや翻訳チームからの要望に対するLQA内容のアレンジに関する議論も体系的な表を利用することでスムーズに行うことができたことは導入したメリットだったかと思います。

• 観点表をベースに実際のテストケース(テキスト検証、実機検証)を作成
  今回の実務適用でこの観点表が主に活躍した点はテストケースの作成です。
  LQA経験の浅い社員でも汎用的な観点一覧があったことで、テストケースの作成が効率的に行えました。
  
  作成されたテストケースの妥当性や網羅性についての確認も、観点表があることで視覚的かつ定量的に把握することができたのでヌケモレ防止や重複回避につながっただけでなく、現場以外のメンバーへのレビュー依頼やそのFBの反映も効率的に行えた点は大きな導入のメリットだったかと思います。

■課題

上記のように一定効果があった部分もありましたが、課題に感じる部分もいくつかありました。代表的なものを2つ紹介します。

①「翻訳検証観点表」の観点を実務での検証観点としてそのまま使えない。

• 汎用的な観点表であったからこそのメリットは確かにありましたが、その反面あらゆる場面を想定しているため、特定の実務に落とし込むと必要以上の網羅性が発揮されてしまい、観点表通りにすべてを網羅しようとするとテストケースが膨大になりすぎる課題がありました。

②テスト対象毎の検証観点の整理に時間がかかる。

• 汎用的な観点表をそのまま固有のテストに利用しようとすると、プロジェクト固有の要件やリスクに対応できない場合があったため、観点表の内容をテストする対象や環境に合わせて調整する必要性がありました。またその調整にコミュニケーションコスト含め追加で工数を必要としてしまうケースがありました。

総じて、今回の導入事例の課題の傾向としては使用した観点表の汎用性が故のものが全体的に多かった印象でした。

■改善案の考察

課題はいくつかありつつも、LQA業務の周知や各業務の効率化に効果がでていたという事実もあったため、今後のチームでの汎用的な運用を目指すべく、現在も運用していく中で改善案を模索しているので、その考察内容についても紹介できれば思います。

今回紹介した課題傾向は、汎用的で使用用途を特定していないためのジレンマによるものであったと考察できるため、解決策の方向性としては次の3点をベースに改善案を検討しています。

• ターゲットの明確化:
  　完全な汎用性を目指さず、特定のユーザー層や利用シナリオに焦点を絞る。
• 観点のモジュール化:
  　必要な部分だけを抜き出して利用できるように分割する。
• 利用者フィードバックの反映:
  　LQAテスターだけでなく、プロダクトのニーズや問題点を考慮して都度調整できる状態にする。

▼上記の軸を踏まえての今回の各課題に対する改善案例

• 課題①に対する改善
  膨大なテストケースによる人員や期間のリソース不足をさけるため、今回のプロダクトにおける優先度に応じて取捨選択し、テストの焦点を明確にし観点を絞る。

• 課題②に対する改善
  テスト内容毎にカスタマイズした観点表を別途用意することで都度調整するコストを省く。

現時点でも随時運用に関するアップデートを重ねていますが、重要な点は、「翻訳検証観点表」はあくまでも汎用的な資料であり、これの持つジレンマを理解したうえで、利用する関係者間で密に連携を取ることととコミュニケーションを図ることで、適切なバランスを取ることであると考えてます。

■最後に

昨今のゲームローカライズは、文化的背景リスクの増加など非常にセンシティブで複雑なものになっているトレンドの中にいると思います。

こういった状況を鑑みても、汎用的なローカライズの観点表の運用を業務内で継続的に検討することは、業務の効率化だけでなく、拡大するグローバル市場での競争力と顧客満足度をさらに高めることに繋がると思っています。

今回の観点表の実務導入は試験的な側面が強く課題も多かったですが、一定効果は見られた点もあったので、今後も実務でのより効果的な運用に向けてアップデートを重ねていく予定です。

今回の事例が少しでも皆様のローカライズの現場に役立てば幸いです。
以上、最後までご覧いただきありがとうございました！

1. プロダクト:ゲームタイトルに関わる開発チームのことをここでは指しています。 ↩