ローカライズ担当の採用: 最初の1人に何を任せるか
ローカライズ担当を置こう、という判断は、たいてい何かが壊れてから出てきます。ある言語だけ前のバージョンのテキストのまま出荷してしまった週や、プロデューサーがマイルストーン期間の3日を、進行管理ではなく請求書とファイルの受け渡しの追いかけに使っていたと気づいた週です。
それまで、この仕事は誰かの手が空いている部分に吸収されています。制作の誰かが翻訳会社にメールを出し、エンジニアの誰かがファイルを取り込み、たまたまその言語がわかる社員がリリース前に数行読んで「大丈夫そうです」と言う。この形は、だいたい1タイトル・1〜2言語までは持ちます。それを超えると、ローカライズは「厚意の集まり」ではなく「機能」になり、担当が決まっていない機能は、発売後にしか表面化しない壊れ方をします。
この記事で扱うのは採用の判断そのものです。ローカライズという言葉に束ねられた複数の仕事のうち、実際にどれを採るのか。社外のパートナーとの線をどこに引くのか。そして候補者が目の前に来たときに何を見るのかです。
「ローカライズ担当」に含まれる4つの仕事
組織図の上では一つの枠でも、実際には同じテキストに触れるだけの別々の仕事が4つ入っています。必要な技能が違うので、どれか1つが得意な人が他は不得意でも、それは本人の欠点ではありません。
- 進行管理 — 発注範囲の切り出し、翻訳者への説明、テキスト凍結を軸にしたスケジューリング、質問への回答、納品の追跡
- 言語品質 — 訳文そのものを作る、または良し悪しを判断する。タイトルとその更新をまたいで口調と用語を一貫させる
- ローカライズQA — 翻訳済みビルドを実際に遊び、画面上で何が壊れているかを報告する。ファイル上の間違いとは別物
- ローカライズエンジニアリング — 書き出しと取り込みの仕組み、ファイル形式、文字コード、フォント、レイアウトの挙動、そしてそれらの自動チェック
進行管理が欠けているとき、日々の見た目には何も壊れていません。単に作業が遅れ、重複し、誰も答えていない質問を抱えたまま納品されます。そのコストは「不具合」としてではなく「リリースから落ちた言語」として現れます。
言語品質の担当がいない場合、各社・各翻訳者の自己申告をそのまま信じるほかなく、言語をまたいで比べる手段がありません。社内で読める1言語なら何とかなりますが、読めない言語では危うい状態です。
LQAが欠けていると、表計算上は完璧な訳文が、見切れた状態や別の画面に紐づいた状態で出荷されます。エンジニアリングの担当が決まっていないと、毎回のリリースに「1人だけが手順を知っている手作業の変換」が挟まります。その1人が審査提出の週に不在になるまでは、問題なく回ります。
最初の1人は、たいてい翻訳者ではない
最初の採用として真っ先に思い浮かぶのは翻訳者です。必要な言語を作れる人だからです。しかしこれは、技能の問題ではなく供給の問題として、たいてい最初の1人には向きません。翻訳の供給力は買えます。必要になりそうな言語のフリーランスも会社も存在し、リリース計画に合わせて増減できます。一方で進行管理の力は同じようには買えません。自社のゲーム、ビルド手順、カレンダーを知っていることが前提だからです。
翻訳者1人をローカライズ部門そのものとして採ると、1言語だけがきれいに面倒を見られ、残りの仕事は翻訳作業の合間に押し込まれます。その人はスケジュール調整、催促、ファイルの取り込みをやることになります。採用時に期待されていたのはそこではなく、本人も望んでいないことが多い作業です。そして本来お金を払った技能は、その人が話せない言語では遊んでいます。
例外はあります。継続更新のあるライブ運営タイトルで、主要な対象言語が1つに絞られていて、守る価値のある文体があるなら、毎日ゲームの中に住んでいる社内翻訳者は外部のどんな体制より強くなります。その場合、進行管理の負荷は制作側で吸収できる規模に収まっていることも多いはずです。ただしこれは一般則ではなく、条件のそろった個別ケースとして扱ってください。
求人票を書く前に、社外との線引きを決める
この役割の形は、何を社外に残すかで完全に決まります。先に決めるべきはそちらで、求人票はその結果です。次の5つでほとんどが決まります。
- 誰が訳すのか — 直接契約のフリーランスか、全言語を1社にまとめるか、言語ごとに使い分けるか
- 訳文の良し悪しを誰が判断するのか。そもそも社内に判断できる人はいるのか
- LQAを誰がやるのか。どのビルドで — 自社か、テスト会社か、プラットフォーム提出の一部としてか
- 書き出し・取り込みの仕組みとチェックを誰が持つのか。この新しい役割か、既存のエンジニアリングチームか
- ある言語が遅れたとき、責任を負うのは誰か — 発注先か、新しい担当者か、制作か
この答え次第で、まったく違う2種類の職種になります。翻訳もレビューも社外、パイプラインは自社エンジニアという構成なら、採るのは判断力・コミュニケーション・カレンダー管理で価値を出すコーディネーターです。レビューやパイプラインまで社内に持ち込むつもりなら、プロデューサーとエンジニアの中間に近い人材で、候補者の母数は小さく、単価も上がります。
どちらが正しいということはありません。間違いなのは、前者として採用しておいて、後者を暗黙に期待することです。初めてのローカライズ採用が失敗する経路として、これが最も多いものです。
求人票に何を書くか
ローカライズの求人票は、職種として異様に抽象的なものが多く、抽象的な求人票は「1年で退屈する業界ベテラン」か「翻訳しかやったことがない人」を集めます。具体性がそのままフィルターになります。次のような骨格で書くと機能します。
職種: ローカライズコーディネーター(ローカライズ職の第1号) 前提 - 運営中2タイトル、開発中1タイトル。PC・コンソール - 現在6言語、来年2言語追加予定 - テキストはエンジンの文字列テーブル。外注へはCSVで書き出し - 毎週パッチ。凍結後のテキスト変更が2回に1回程度発生 担当範囲(この役割が持つ) - 発注範囲、スケジュール、翻訳者への説明、質問対応 - 凍結日と、凍結後変更の例外手続き - 提出前の翻訳済みビルド確認 関与するが決定権は持たない - 次にどの言語を追加するか - 単価と外注契約 最初の半年で実際にやること - 書き出し・取り込みの往復を文書化し安定させる - 全外注先で共通の用語集と質問ログを1本に統一する - 既発売タイトルに対して最初の体系的なLQAを実施する
この骨格の中で、他より効いているのは2か所です。「持つ範囲」と「関与するだけの範囲」を分けておくと、初期に最も起きやすい失敗 — 防ぐ権限がなかった遅延の責任だけを負わされる — を避けられます。もう1つは、最初の半年を正直に書くことです。ローカライズ職の1人目の半年は、たいてい華やかではありません。パイプラインの発掘作業、用語集の整備、そして「この言語は誰も確認していなかった」という発見の連続です。
語学要件の書き方には注意してください。3言語の流暢さを要求すると、優秀なコーディネーターが弾かれ、翻訳者が集まります。それは2つ前の節で採らないと決めたはずの人材です。実際に必要なのは、社内と外注先の共通言語での実務レベルの運用力と、少なくとも1つの対象言語について「悪いファイルを見たときに気づける」程度の土地勘です。
面接で見るところ
最も情報量が多い質問は、実際のプロジェクトで自分が回した翻訳の往復を、最初から最後まで説明してもらうことです。途中で誘導しないでください。次の要素が、こちらから聞かなくても出てくるかどうかを聞いています。
- 文脈 — 文字列以外に翻訳者へ何を渡したか。スクリーンショット、キャラクター設定、用語集、その行がどこに出るかの説明
- 質問 — 翻訳者から質問が来ていたか。その回答をその後どう扱ったか
- 凍結 — テキストがどこかで変更停止したか。その後に来た変更をどう処理したか
- 確認 — 出荷前に、誰かが各言語でビルドを開いたか
- 失敗 — うまくいかなかったことと、再発しないように何を変えたか
ファイルの受け渡しだけを語る候補者 — 送って、返ってきて、取り込んだ — は、この仕事の機械的な部分だけを経験していて、残りの部分の存在を知らない可能性があります。若手の採用ならそれ自体は不合格材料ではありませんが、その分の仕事は当面こちらが持ち続けることになる、という見積もりにはなります。
もう1つ有効なのは、短い成果物レビューです。翻訳済み文字列20行程度の表を渡し、意図的に問題を仕込んでおきます。原文と訳文で形が変わってしまった変数、口頭で伝えたUI幅にどう見ても入らない行、2通りに訳し分けられてしまった用語、訳文が原文と同一の行。それぞれについて、何をどの順でやるかを聞きます。見つけられるかどうかより、優先順位の付け方のほうが多くを語ります。
最後に、「納期は完璧に守られたが、訳文が良くなかったらどうするか」を聞いてください。この答えで、スケジュールを管理する人と品質を管理する人が分かれます。良い答えには根拠があり、漠然とした不満ではなく具体的な指摘があり、発注先との対話があります。黙って受け入れることでも、同じ問題を抱えたまま発注先だけ替えることでもありません。
採用した人が静かに潰れないために
ローカライズ職の1人目は、決まった形で失敗します。自分では動かせない結果に責任を負わされ、1年間火消しに追われ、引き継いだときと同じパイプラインを残して辞めていきます。次の4つで、その大半は防げます。
- 日程に対する権限。テキスト凍結を「お願いする」ことしかできないなら、その凍結は存在していません。
- アクセス権。ビルド、バージョン管理下の文字列ファイル、ストアの管理画面、外注先との関係 — 初週から全部渡します。
- 制作側へのレポートライン。マーケティングの下だけに置くと、ストアページはよく面倒を見られ、ゲーム内テキストは後回しになりがちです。
- 予算が見えること。翻訳に実際いくらかかっているか見えない人に、範囲の取捨選択はできません。
最初の90日は、成果物ではなく棚卸しに使ってください。どのテキストが、どの言語で、どの品質で存在し、誰が作り、どう確認されたのか。多くの会社が、誰も一度も確認していない言語を最低1つと、何年も欠損のある変換を通り続けているファイルを1つ見つけます。
2人目の採用は、その棚卸しの結果から決まります。問題が画面上に集中しているなら — 見切れ、違う言語の表示、まるごと未翻訳の画面 — 次はLQAです。問題がパイプラインに集中しているなら — 文字化け、キーのずれ、手作業の取り込み — 次はエンジニアです。どちらか分からないまま抽象的に増員すると、目に見えて忙しいのに同じ不具合を出し続けるチームができあがります。