世界同時リリースの段取り — シムシップで得るものと払う代償
リリース計画を詰めていくと、どこかで「全部の言語を初日に出すのか」という話になります。直感的には出したくなります。ローンチは一度きり、話題も一度きり、すべての市場を同じタイミングで招待できるからです。この計画には業界用語があり、シムシップ(simultaneous shipment、同時出荷)と呼ばれます。支えられる体制があるなら、実際に強い戦略です。
同時に、これは最も高くつくリリースの組み方でもあります。しかも支払うのは主に費用ではなく、柔軟性です。シムシップは処理能力を増やして成立するのではなく、締切を前倒しにして成立します。初日に出すと決めた言語の数だけ、テキストの凍結は数か月前へ動き、発売日はその中で最も遅い言語に人質を取られます。
この記事では、その取引を意識して行うための材料を扱います。シムシップで何が手に入り、何を請求されるのか。そして、発売日を動かさずに途中で方針を変える方法についても書きます。
何を買っているのか
シムシップを支持する理屈は、注目が時間に対して均等に配られないという事実です。ローンチはそれを一点に集めます。メディアの記事、配信者、ストアの目立つ場所、レコメンドの動き、同時に始めたプレイヤー同士の口コミ。半年遅れて参加した市場が手にするのは、その勢いが周囲に何もない状態のゲームで、二度目のローンチが一度目を再現することはめったにありません。
あまり語られない二つ目の利点として、全員が同じ内容を同じ時期に遊んでいるほうがコミュニティを一つに保ちやすい、というのがあります。議論も攻略も動画も二次創作も言語をまたいで広がるので、自分の言語版がまだ存在しないという理由で参加できないプレイヤーは、そのまま離れていきがちです。対戦要素や交流要素が強いゲームでは、記事に載ること以上にここが効きます。
守りの理由もあります。求められている言語に対応していない市場では、その空白を誰かが埋めることがあります。有志の翻訳が出てくる程度で済めばまだしも、無断で改変されたビルドが出回ることもあります。完全に防ぐことはできませんが、自分でその言語を出しておけば、そこにある需要そのものがなくなります。
代償はテキスト凍結が大幅に早まること
ほかのすべてを決めているのは、この仕組みです。テキストが安定するまで翻訳は始められず、翻訳が終わるまでレビューは始められず、訳文がビルドに入るまで実機での確認は始められません。この三段階は順番に起き、それぞれにカレンダー上の時間がかかります。全部を発売前に終わらせる必要があるなら、発売日からこの連鎖の長さを引いた日が、テキストの凍結日です。そしてその日付は、多くのチームが思っているよりずっと手前にあります。
言語の数はこの連鎖の長さをほとんど変えません。言語同士は並行して進むからです。増えるのは、連鎖が壊れうる経路の数と、遅い時期の修正一つあたりの費用です。一言語のリリースなら、セリフの言い回しを変えるのは五分の判断です。シムシップでは同じ一行が変更依頼になり、全言語の翻訳者に届き、戻ってきて、レビューされ、文脈の中で再確認される必要があります。動かない日付までに、言語の数だけ。
正直に言い換えると、シムシップは終盤にもっと頑張ることを求めているのではありません。文章をずっと早く書き終えて、そのあと本当に触らないでいることを求めています。後半の約束をしないままシムシップに同意したチームは、利点だけ取り逃して費用だけ払うことになります。
動き続けるゲームに対して翻訳を走らせる
現実には、発売の数か月前にゲームが変化を止めることはありません。ですからシムシップとは、変更をなくす方法ではなく、変更を管理する規律です。実務的な形はバッチ化です。最後に一度の巨大な受け渡しをするのではなく、仕上がった区画から順に凍結して送り出します。バッチごとに凍結日があり、その周囲のゲームは動き続けてかまいません。
そのためには例外処理の手順が要ります。例外は必ず出るからです。凍結済みテキストの変更を承認できるのは誰か、変更に何の情報を添えるか、それがどう全言語へ届くかを、事前に決めておいてください。ある翻訳者にだけ個別メッセージで伝わり、ほかに届かなかった変更こそが、五つの言語では新しい表現、六つ目だけ古い表現、という状態でゲームが出荷される原因です。
進捗は全体の一つの割合ではなく、バッチ×言語で管理してください。「ローカライズは80%完了」という言い方は、ある言語は終わっていて別の言語は未着手、という状況を覆い隠します。そしてそれこそが、発売日に間に合うかどうかを決めている状況です。
バッチ | 凍結日 | ja | fr | de | zh-Hans ----------|---------|-------|-------|-------|-------- prologue | 03-14 | 確認済 | 確認済 | 確認済 | レビュー chapter-1 | 03-28 | 確認済 | レビュー| 翻訳中 | 翻訳中 chapter-2 | 04-11 | レビュー| 翻訳中 | 翻訳中 | 未着手 ui-final | 04-18 | 翻訳中 | 未着手 | 未着手 | 未着手
日付・物量・言語 — どれを譲るかを先に決める
リリース計画には動かせるものが三つあります。発売日、コンテンツの量、そして言語のリストです。終盤には、たいてい二つしか守れません。最悪なのは選ばないことで、その場合は三つとも静かに劣化します。日付は少しずれ、コンテンツは慌てて削られ、言語は残った時間で出せる品質になります。
早い段階で決めておく価値があるのは「何を犠牲にするか」で、被害が最も小さい答えはしばしば言語です。発売の数週間前に、初日の対応言語から一つ外すのは、きれいに実行できる判断です。ストアの表記から外し、告知せず、あとで独立したアップデートとして出す。そのとき小さいながら二度目の注目も得られます。約束されていなかった言語に落胆する人はいません。
対して、ほかより二週間短いレビューしか受けていない言語を出すほうは、別の意味で悪い結果になります。その市場のプレイヤーは、それを日程上の妥協としては体験しません。自分の言語における「このゲームはこういうものだ」として体験し、そう書きます。そのレビューは、あなたが直した後もページに残り続けます。
だからこそ、対応言語の告知には実際の重みがあります。初日に出ると伝えられた市場からそれを取り下げると、買い戻せない信用を失います。自信のある言語だけを告知し、残りは嬉しい追加として扱ってください。
時期をずらしたほうがよい場合
シムシップが常により野心的な選択、というわけではありません。単により高い選択であることもあります。主要言語を先に出し、ほかは準備できた順に出す段階リリースのほうが本当に優れている状況は、いくつもあります。
- ゲームがまだ最終形を探しており、早期アクセスや初期の大型更新を通じてテキストが変わり続ける
- 訳文を文脈の中で確認する手段がまだ整っておらず、規模を広げても未検証の面が増えるだけになる
- 追加言語が需要の裏付けではなく期待に基づいており、規模を絞ればデータのある言語に予算を集中できる
- チームが小さく、ローンチ週そのものに全員が必要で、多言語ローンチはまさにその瞬間のサポートとコミュニティ対応を倍増させる
- テキスト主導の内容で、日程の圧力がそのまま翻訳品質に着地する構造になっている
段階リリースにも計画は要る
段階リリースの弱い版は「言語はあとで足します」で、これはたいてい永遠に来ません。発売後は誰も担当していないからです。強い版は、言語の追加を一つひとつ小さなリリースとして扱います。日付があり、告知があり、確認の工程がある。結果として、注目される機会が一度ではなく二度、三度と手に入ります。
二つのことが、二言語目以降を一言語目よりずっと安くします。テキストを書き出せる状態に保ち、キーを安定させておくこと。そうすれば新しい言語は新しいプロジェクトではなく新しい列になります。もう一つは、最初の翻訳者から来た質問を記録しておくことです。次の翻訳者も、その大半を同じように尋ねます。一言語目をきちんとやっていれば、五言語目はほとんど日程の問題になります。
どちらの道を選ぶにせよ、判断とその理由を書き残してください。半年後に誰かが「なぜこの言語は後回しだったのか」と聞いたとき、答えは記録された取引であるべきで、時間が足りなかった気がするという記憶であるべきではありません。