ローカライズ相見積もりのチェックリスト — 各社に渡す資料と価格以外の比較軸
ゲームがあり、発売時期があり、複数の翻訳会社から見積もりを取るよう言われている。数週間後、手元には総額が倍近く開いた見積書が並び、安い会社が効率的なのか高い会社が丁寧なのかを判断する材料は、どの書面にも書かれていない。相見積もりでは珍しくない光景です。
これはたいていベンダー側の問題ではなく、依頼の仕方の問題です。ベンダーは、こちらが伝えた条件にしか値段を付けられません。第二の翻訳者によるレビュー工程を含めるかどうかを書かなければ、含める会社と含めない会社が出ます。どんな形式のファイルを渡すかを書かなければ、各社がそれぞれ違う前提でエンジニアリングの手間を見積もります。比較可能性は、返ってきた見積書の中から発見するものではなく、依頼の時点で作り込むものです。
この記事は、ローカライズ調達プロセスのチェックリストです。RFP(提案依頼書 — 発注側が条件をまとめて各社に配る文書)に何を入れるか、何を質問するか、返答をどう比べるか、そしてこの段階の応対から何が読み取れるかを扱います。
なぜ相見積もりは比較できなくなるのか
誠実な見積もりどうしでも金額が大きく開くのは、そもそも別の仕事に値段を付けているからです。よくあるズレは、範囲(ゲーム内テキストだけか、ストアページや宣伝文も含むか)、工程(翻訳のみか、翻訳+バイリンガルレビューか、さらにビルド上でのLQAまで含むか)、数える単位(原文ワードか訳文ワードか文字数か)、ファイル処理を誰が負担するか、そして発売後に発生するテキストの扱いです。
さらに、不正直さとは無関係に、安く出すほうへ引っ張られる構造があります。依頼書が範囲を曖昧にしていると、最も狭く読んだ見積もりが比較で勝ち、抜けていた作業はあとから追加費用として戻ってきます。全体像を織り込んだ会社は「高い」と判断されて落ちるので、市場全体が狭い見積もりを出す方向に学習していきます。
対策は値切ることではありません。前提が分かれる余地をなくし、各社が返す数字が同じ仕事を指すようにすることです。
全社にまったく同じ資料を渡す
資料は一式にまとめ、同じ日に、同じ回答期限で全社に送ります。途中で一社から質問が来て追加情報を出したなら、その回答も全社に配ります。そうしないと、また違うブリーフから書かれた見積書を比べることになります。
- 言語ペアごとの分量。どうやって数えたか、何を含み何を除いたかも添える
- 内容の内訳(UI、システム文言、シナリオ、アイテム・チュートリアル、ストアページ、宣伝文、規約類)。構成比によって単価も担当者の割り当ても変わる
- 実ファイルのサンプル。整形せず、ベンダーが実際に受け取る形のまま数百行、キー列も含めて渡す
- ファイル形式と往復の流れ。何を書き出し、何を返してもらい、間に何かツールが入るのか
- 対象言語とロケールを正確に。地域バリアントは別の判断であり別のコストです
- テキストが背負っている制約。項目ごとの文字数・表示幅の上限、プレースホルダーの記法、リッチテキストのタグ、翻訳してはいけない用語
- スケジュール。テキスト確定日、納品マイルストーン、発売日、そして発売後に月あたりどれくらい新規テキストが出る見込みか
- 個別に金額を出してほしい工程。翻訳、バイリンガルレビュー、ビルド上のLQA、エンジニアリング、画像内テキスト、ボイス
- 現時点で存在する参考資料。用語集、スタイルガイド、過去の翻訳、プレイ可能ビルドまたは動画
- 秘密保持とプラットフォーム上の義務。NDA、未公開コンテンツの扱い、再委託の可否
同じ質問票を、同じ順番で投げる
自由形式の提案書は横に並べて読めません。各社が自分の得意なところを軸に構成してくるからです。番号を振った質問票を渡し、その順番で答えてもらいます。相手の手間はほとんど増えず、こちらの比較は表になります。
多くの質問は、答えの内容そのものより「言い淀まずに答えられるか」を見るためのものです。この工程を何度も回している会社は、自社の手順を具体的に説明できます。
1. 数え方 - 単価は原文ワード・訳文ワード・文字数のどれに掛かりますか - 日本語や中国語が原文の場合、どの数え方になりますか - 言語ごと・ファイルごと・納品ごとのミニマムチャージはありますか 2. 工程 - 誰が翻訳し、第二の翻訳者によるレビューは提示額に含まれますか - 機械翻訳やAIをどこかの工程で使いますか。使う場合、どの工程で、どう開示されますか 3. 体制 - 言語ごとに何名が担当し、更新時も同じ担当者が継続できますか - その担当者は、この言語でどのようなタイトルを手がけましたか 4. 資産 - 本件で発生した翻訳メモリと用語集の所有権はどちらにありますか - どの形式で、どの時点で受け取れますか 5. 更新 - 発売後の追加バッチはどう価格設定・日程調整されますか - 少量・急ぎのバッチの最短納期はどれくらいですか 6. 品質 - 納品後にこちらが不具合を報告した場合、どう対応し、期限はいつまでですか - こちらのビルド上でのLQAは可能ですか。どういう体制になりますか
価格以外に何を比べるか
価格はれっきとした判断基準で、そこを隠す必要はありません。ただし比べるべき数字は発売時点の金額ではなく、最初の一年の合計です。以下の観点は、単価よりもその合計を大きく動かします。
- ゲームの実績。エンタメ全般ではなく、テキストの性質と分量が近いゲームの実績があるか
- 見積もり前に質問してきたか。その質問が、予算ではなくこちらの制約についてのものだったか
- LQAの可否。動作するビルド上で、こちらの対象プラットフォームで確認できるのか、ファイルを読むだけなのか
- 翻訳メモリと用語集の帰属、受け渡し形式、いつ受け取れるか
- 更新時に同じ担当者が続けられるか。ゲームの寿命全体で見ると、トーンの一貫性を最も左右する要素です
- 少量バッチの納期とミニマムチャージ。運営中の更新にいくらかかるかは、ここでほぼ決まります
- AI・機械翻訳の使用について、どこまで具体的に説明できるか。ポストエディットがその工程として値付けされているか
- やり取りの言語、時差の重なり、遅延時のエスカレーション先
RFPの段階で見えてしまうベンダーの質
返答そのものが作業サンプルです。受注前の対応は、受注後の対応の最も良い版だと考えて構いません。
見積もりを出す前にプレースホルダーの記法、文字数上限、参考資料の有無を尋ねてくる会社は、自社の工程を見せてくれています。一時間で質問ゼロのまま金額だけ返してくる会社は、テンプレートに数字を入れているので、そのテンプレートが置いた前提が、あとで揉める箇所になります。実際に誰が作業するのか(社員か、常時の契約者か、その週に空いている人か)が曖昧なときは、丁寧に、しかしはっきり確認したほうがよいところです。
都合が良すぎるスケジュールも同様に疑ってかまいません。翻訳者が質問する時間が確保されていない日程は、「分からないところは推測します」という宣言に近く、推測された行が後日プレイヤーからの指摘として戻ってきます。
金額が大きいなら、有償のトライアルを挟む価値があります。候補各社に、同じ量・同じ内容の、実際に代表的なテキストを、同じ条件で発注します。そして対象言語を読める人に、どれがどの社の訳か伏せたまま評価してもらいます。トライアルの費用は、間違った選定を本番の納品で知る費用よりはるかに小さく済みます。
進め方と、決め方
評価基準とその重みは、回答が届く前に文章にしておきます。価格を見てから何が重要かを決めると、最も安い提案を正当化する作業になりがちですし、あとから社内で説明することもできなくなります。
判断のための時間も日程に確保します。テキスト確定の二日前に決まった発注先は、選定の結果ではなく「すぐ着手できた会社」でしかありません。納品日から逆算し、レビュー、LQA、ビルドへの組み込みを差し引いて、RFPの回答期限を置きます。
配った資料と受け取った回答は必ず残します。次回のRFPは今回の差分で作れますし、今回その場しのぎで答えた質問は、次回は最初から資料に入れるべき項目です。制作用のローカライズキット(翻訳者に渡す資料一式)をすでに整備しているなら、RFP資料はその一部に商流上の質問を足したものになります。整備していないなら、いま作ったこの資料がその第一稿です。
最後に、選ばなかった会社にも短く連絡します。他社の金額を伝える必要はありません。この業界は狭く、今回落ちた会社が来年こちらが困っているときに空いている会社かもしれません。きちんとした進め方をするという評判は、一回の価格交渉より長く効きます。