ローカライズPMの仕事は実際には何をしているのか

小規模・中規模のスタジオでは「ローカライズPM」という肩書きの人がいることはほとんどない。それでも仕事自体はなくならないので、誰かに吸収される — プロデューサーだったり、リードエンジニアだったり、最後に翻訳者にメールを送った人だったりする。それでたいてい回るのだが、ある日突然破綻する。二人とも「相手が日本語ファイルを取り込んだはず」と思っている日や、翻訳が完成して受信箱に二週間眠っている日が来る。

肩書きがなくても、この仕事が実際に何から成るかを言葉にしておくと助けになる。「誰かがローカライズを見ている」という漠然とした感覚より、タスクの一覧の方が、割り振ったり、任せたり、抜けに気づいたりしやすい。

ファイルの準備

テキストを翻訳者に渡す前に、今回のバッチに何を含めるかを決め、翻訳者が扱いやすいクリーンな形式に書き出し、進行中の別バッチと範囲が重複したり矛盾したりしないか確認する必要がある。機械的に聞こえるが、スコープの肥大や重複作業はここから静かに始まる — 二人が同じファイルの重なる範囲をそれぞれ書き出したり、出荷するつもりのなかった仮のテキストが混じったままバッチが出て行ったりする。

翻訳者へのブリーフィングと質問対応

文脈のないファイルは推測を生む。誰かがブリーフを書く必要がある — 何が対象範囲か、どのトーンを使うか、何を変えてはいけないか — そして曖昧な点があったときに翻訳者が実際に連絡を取れる相手である必要がある。放置された質問は、そのバッチ全体を止めるか、当てずっぽうで解決されて後になって見つかるバグに変わる。

テキストフリーズを見据えたスケジューリング

翻訳には実際の日数がかかる。だからスケジュールはリリース日から逆算して組む必要があり、「テキストがたまたま完成した日」から順算してはいけない。つまり、テキストの変更を止める日(テキストフリーズ)がいつかを把握し、その日が存在することを上流のチームにも周知し、フリーズ後にテキストが変わってしまった場合の対処方針を用意しておく — 実際、それはよく起こる。

レビューの調整と結果の取り込み

翻訳が戻ってきたら、誰かがそれを実際に判断できるレビュアー — チーム内のネイティブスピーカーや、翻訳者自身による二度目のチェックなど — に回し、修正を集約し、最終的なテキストをゲームが実際に読み込む形式に戻す必要がある。この段階でこそ、往復によるフォーマット破損(壊れたプレースホルダー、文字コードの誤り、失われた改行)を見つけられるか、そのまま出荷してしまうかが決まる。

ビルドでの確認

ファイル上では正しく見えるテキストでも、画面上では欠けていたり、重なっていたり、取り込み処理が静かに失敗して単に表示されていなかったりする。誰かが実際に各言語のビルドを開いて確認する必要がある。パイプラインが動いたはずだと信じるだけでは足りない。

誰も担当していないときに失敗する引き継ぎ

上記のすべての工程は引き継ぎであり、引き継ぎはデフォルトで静かに失敗する。ファイルが放置されていてもエラーは出ないし、質問が未読のままでも通知は来ないし、フリーズ日を知らされていなかったチームがそれを過ぎても誰も気づかない。ローカライズ作業が全員の「片手間の担当」であり、誰の正式な仕事でもないときに現れる具体的な穴は次のようなものだ:

• 翻訳済みファイルが完成した状態で誰かの受信箱に眠っている。届いたことを誰も見ていなかったから
• 同じバッチを二人が別々に取り込む、あるいは誰も取り込まない
• フリーズ日が一人の頭の中にしかなく、それを過ぎてもコンテンツが気づかれず出荷される
• 翻訳者の質問が長く放置され、当てずっぽうで進められ、それが実際のバグになる
• 誰もリリース前にローカライズ済みビルドを開いておらず、崩れた行はプレイヤーからの報告で初めて発覚する

肩書きがなくても、仕事には名前を付ける

これを解決するのに専任のローカライズPMを雇う必要はない。役立つのは、タスク一覧を明示的にし、それぞれを特定の誰かに割り振ることだ。その人が他に三つの仕事を兼任していても構わない。リリースごとの短いチェックリスト — ファイル準備完了、ブリーフ送付済み、フリーズ日を周知済み、レビュー担当者アサイン済み、ビルド確認済み — があれば、見えなかった責任がチームの目に見える形になり、互いにカバーし合えるようになる。