翻訳の見積書の読み方 — ワード単価・ミニマムチャージ・マッチ率割引
見積書が届きます。ワード単価があり、予想していなかった項目がいくつか並び、ワード数の帯ごとにパーセンテージが振られ、最後に総額があります。単価だけ見ればもう一社と大差ないのに、総額は大きく開いていて、その理由はどちらの書面にも書かれていません。
二社の見積もりの差は、多くの場合「単価」ではありません。その単価が何に掛かっているか、単価の中にどの作業が含まれているか、そして何が静かに外されているかです。構造を読めるようになると、見積もりの比較は勘ではなく計算になります。
この記事で扱うのは、受け取った見積書の読み方です。誰かに相談する前に自分で費用を組み立てる作業は、出発点の違う別の作業になります。
何を、どの単位で数えているのか
ワード単価は一見すると業界標準のようですが、「どのワードか」を聞くと前提が分かれます。原文ワード基準は、こちらが渡すテキストを数えます。訳文ワード基準は、返ってくるテキストを数えます。訳した結果が長くなる言語ペアでは、同じ仕事でも数字が変わるので、同じ単価でも同じ金額にはなりません。原文基準には実務上の利点もあります。着手前に数字を検証できて、作業中に総額が動きません。
日本語や中国語は、単語の間に空白を置かない書き方をするため、ワードではなく文字数で数えるのが一般的です。日本語から英語への見積もりは、原文の文字数で建てることも、出来上がった英語のワード数で建てることもあり、この二つは単価どうしを並べても比較になりません。どちらの基準かを確認し、金額だけでなくベンダーが使った実際のカウントを出してもらいます。
そのうえで、何がカウントに入っているかを確認します。キー列、文脈・コメント列、翻訳対象外の行、マークアップのタグ、重複するシステム文言は、ファイルの解析方法によって数に入ったり入らなかったりします。「10万ワード」とだけ書かれ、どの10万ワードなのかが分からない見積書は、まだ検証できる見積書ではありません。
翻訳以外の行を分解する
翻訳そのものは一行です。それ以外はすべて工程であり、同じ文字数の見積もりが割れるのはこの工程部分です。単価に含めてしまう会社もあれば、行を分ける会社もあります。どちらが正しいというものではありませんが、含んだ単価と含まない単価は、両方を開かないと比較できません。
- 第二の翻訳者によるレビュー・校閲(バイリンガルレビュー)。任意項目の中では最も金額が大きくなりがちです
- 動作するビルド上でのLQA。ワード単価ではなく時間単位・日単位が一般的です
- ファイルエンジニアリング。こちらの形式の読み込み、タグやプレースホルダーの保護、再取り込み、非標準な部分の処理
- 画像内テキストや、翻訳後のレイアウト調整(いわゆるDTP)の作業
- プロジェクトマネジメント費。小計に対する率で載ることも、単価に溶けていることもあります
- ミニマムチャージ。言語ごと・案件ごと・納品ごとのいずれかで最低額が発生します
- 特急料金。ある納期を下回ると加算されます
- ボイス収録・ディレクション。行ではなく、別枠の予算と考えたほうが実態に合います
比較の前に、全社を同じ表に載せ替える: 言語ペア : 日本語 -> 英語 数え方 : 原文文字数 / 訳文ワード数 (ベンダー提示カウント: ______) 翻訳 : 単価 x 割引後の正味カウント 第二翻訳者レビュー: 含む / 別行 / 提供なし ビルド上のLQA : 時間単価、想定 ___ 時間 / 提供なし エンジニアリング: 納品ごと固定 / 含む / 時間単価 PM費 : 小計の___% / 含む ミニマムチャージ: 言語ごと / 納品ごと / なし 特急料金 : 営業日___日を下回る場合に適用 発売後のバッチ : 単価 + バッチごとのミニマム、納期___日
マッチ率割引が前提にしていること
ベンダーが翻訳メモリ(過去の訳文を蓄積して再利用する仕組み)を使う場合、見積書のワード数が帯に分かれていることがあります。ファイル内での繰り返し、既存メモリとの完全一致、パーセンテージで区切られたファジーマッチ、そして純粋な新規。帯ごとに単価が段階的に下がり、再利用の多いプロジェクトでは総額を大きく動かします。
考え方自体は妥当です。すでに翻訳・承認済みの文と同一のセグメントは、訳す作業ではなく確認する作業なので、同じ額を払う理由はありません。ただし、この割引表にはいくつかの前提が埋め込まれていて、受け入れる前に表に出しておく価値があります。
一つ目は所有権です。そのメモリが自社の過去プロジェクトから作られたものなら、割引は「すでに支払ったテキストの分が戻ってきている」だけで、あるべき姿です。一方、メモリがベンダー側の資産としてベンダーと一緒に移動するものなら、発注先を変えた日にその蓄積は消え、次の見積もりには割引の帯がそもそも存在しません。これは価格の問題ではなく調達の問題です。
二つ目は検証可能性です。帯を算出した解析結果(いわゆる解析レポート)を、合計値だけでなくファイルとして出してもらいます。ベンダーが使うツールの標準的な出力なので、出せない・出さないという場合は、見積もりの中で最も大きい変数を信用だけで受け入れてほしいと言われていることになります。
三つ目は、一致したセグメントが実際にどう扱われるかです。100%一致でも、置かれる場所が変われば誤りになり得ます。同じ短い英単語がボタン名としては成立してもステータス名としては成立しない、同じ台詞でも話者が変われば口調が合わない、といったことが起きます。一致分をほぼゼロ円で請求し、誰も開かないまま通す運用は、静かな誤りが溜まる典型的な場所です。高い一致率の行も文脈上で目を通してほしいと要求するのは妥当ですし、その分の費用がかかるのも当然です。
見積書に書かれていないこと
どの見積書も、いくつかの問いについては沈黙しています。そしてそのどれもが、比べていた単価より実際の総額を大きく動かします。いずれもメールで一日あれば答えが得られる内容です。
- 実際に誰が翻訳するのか。社員か、常時の契約者か、その週に空いている人か。そして更新時も同じ人が続くのか
- どこかの工程が機械翻訳・AI出力+人手編集になっていないか。なっている場合、それはポストエディットとして値付けされているか、通常翻訳として値付けされているか
- 修正は何回まで含まれ、どこから追加請求になるのか
- 着手後に原文を変更した場合どうなるのか。ゲーム開発では仮定の話ではありません
- 終了時点で翻訳メモリと用語集は誰のものか。どの形式で受け取れるのか
- こちらのファイル形式の処理が含まれているのか、整形済みの表を渡す前提になっているのか
- 通貨、税の扱い、支払い条件、海外送金の手数料をどちらが負担するか
二つの見積もりを一つの比較に直す
まず、両方を同じ範囲に載せ直します。自分たちが本当に必要な範囲(レビューやLQA、ストアテキストを含むのか含まないのか)を決め、それをそのまま各社に提示して、外していた項目を足した金額を出し直してもらいます。これは価格への異議ではなく通常の手順で、ベンダー側も想定しています。
比較は単価ではなく言語ごとの総額で行います。単価は構成要素にすぎず、実際に払うのは言語ごとの総額です。ミニマム、帯別の割引、単価に含まれた工程は、この粒度で初めて表に出てきます。
そのうえで、比較の期間を発売時点から一年に伸ばします。新規・変更テキストの月あたりの見込み量を出し、各社の更新時の価格とバッチごとのミニマムを当てはめ、12か月分を積みます。運営が続くタイトルでは、これで順位がひっくり返ることが珍しくありません。単価はやや高くてもバッチごとのミニマムがなく、二日で返してくれる会社のほうが、発売時の見積もりで勝った会社より一年では安く付く、という結果はよく起きます。
最後に、あとから買い直せないものを確認します。翻訳メモリの帰属、用語集の引き渡し、担当翻訳者の継続は、契約時なら安く確保でき、あとからでは高いか、そもそも不可能です。それらが含まれていないから安い見積もりは、実際には安くありません。
聞いてよいこと、動かせるところ
内訳を求めるのは失礼ではなく普通のことです。総額を分解して見せない会社は、その後の関係がどうなるかを先に教えてくれているようなもので、それを調達段階で知れるのはむしろ幸運です。
交渉の余地は、たいてい単価ではなく構造にあります。細かい更新を都度送るのをやめて定期的なバッチにまとめれば、繰り返し発生していたミニマムチャージが消えます。量や期間をコミットすれば、その分の余地が生まれます。納期に余裕を持たせれば特急料金がなくなります。ベンダーが得意な形式に合わせれば、エンジニアリング費が下がります。いずれも相手のコストを下げることで自分のコストを下げる方法で、実作業に入っても崩れない唯一の値引きです。
一方、単価そのものを押し込むのは、ある一線を越えると逆効果になります。その線を下回ると、ベンダーは同じ翻訳者をこのプロジェクトに置いておけません。担当者の入れ替わりは最も高くつく値引きです。交代した人はこちらの用語も、キャラクターも、初回納品時に決めた判断も知らないので、その不整合は請求書ではなくゲームの中に現れます。
総額がどうしても予算を超えるなら、同じ範囲を安くしてもらうのではなく、範囲を明示的に削ります。発売時の言語数を減らす、まずストアページとUIだけ対応してシナリオは次の波にする、吹き替えではなく字幕にする。これらは説明できて、あとから戻せる判断です。黙って薄くなった工程は、どちらでもありません。