ローカライゼーションを始める最適なタイミングとは？

「プロダクトマーケットフィット後にローカライズを行います。」この一文によって、ソフトウェア企業は開発作業の平均 23 ～ 42% のコストがかかり、世界的な発売が 6 ～ 18 か月遅れます。隠れたコストは翻訳ではありません。それは、現在コードのすべての行に組み込まれている技術的負債です。

残酷な計算: 今すぐ構築するか、後で改修するか

• 5-7x - ローカライゼーションの改造と組み込みのコスト乗数
• 23-42% - ローカライゼーションの遅れによる技術的負債に開発時間が浪費される
• 6-18 か月 - 発売後のローカライズ時の世界市場への参入の平均遅延

マッキンゼーとローカリゼーション業界標準協会の調査によると、組織は技術的負債に対処するために開発努力の 23% ～ 42% を無駄にしています。ローカリゼーションを後回しにすると、この負債は指数関数的に増大します。

これが実際に何を意味するかというと、ハードコーディングされた文字列、レイアウトの前提条件、ロケールに依存しない書式設定を使用して機能を構築するのにチームが 3 か月を費やした場合、グローバル展開を決定するときにそれを解くのに 15 ～ 21 か月かかることになります。これには翻訳時間は含まれていません。コードベースをローカライズ可能にするためのエンジニアリング作業にすぎません。

あなたの運命を決める技術的負債比率

技術的負債比率は、コードベースを修正するコストとコードベースを最初から構築するコストを測定します。業界データによると、TDR が 5% を超えると、緊急の対応が必要であることが示されています。国際化が遅れている企業では、ローカリゼーション固有の TDR が 40% を超えることがよくあります。

実際の例: 50,000 行のコードとハードコードされた英語の文字列を備えた SaaS スタートアップでは、「翻訳の追加」に 2 週間かかると見積もられています。実際の作業では、文字列の外部化、壊れたレイアウトの修正、ロケールを意識した書式設定の実装、およびエッジ ケースの解決に開発者が 6 か月かかりました。コスト: エンジニアリング時間で約 180,000 ドル。初日から国際化を考慮して構築していたら、追加コストは約 25,000 ドルになっていたでしょう。

始めるのに最適な瞬間: 1 行目を書く前

研究は明確です。最初からローカリゼーションを統合する企業は、競合他社がまだコードベースのリファクタリングを行っている間に、より迅速に行動し、支出を削減し、世界市場を獲得します。

国際化 (i18n): あなたの基盤

国際化とは、エンジニアリングの変更を必要とせずに、複数の言語や地域に適応できるようにソフトウェアを設計することです。これはあなたが追加する機能ではなく、アーキテクチャのゼロから採用する考え方です。

Core i18n 原則 (初日からこれらを組み込む):

• ユーザーに表示されるすべてのテキストを外部化します: ソース コード内の文字列をハードコーディングしないでください。コンテンツとロジックを分離するリソース ファイル (JSON、YAML、XLIFF) を使用します。
• どこでも Unicode: ダブルバイト文字、右から左に書く文字 (アラビア語、ヘブライ語)、および複雑な文字 (タイ語、デーバナーガリー文字) をサポートします。
• ロケール対応の書式設定: 日付、時刻、数値、通貨、および単位は、ユーザーのロケールに基づいて動的に適応する必要があります。
• 柔軟な UI レイアウト: ドイツ語のテキストは英語と比較して 30% 拡大されます。日本の契約書。 UI はテキストの拡張/縮小を中断することなく処理する必要があります。
• 連結文字列を避ける: 文法規則が異なる言語では、「" + count + " メッセージがあります」という文法が改行されます。代わりにパラメータ化された文字列を使用してください。
• 双方向性を考慮した設計: レイアウトは、再設計することなく、左から右へのテキスト レンダリングと右から左へのテキスト レンダリングの両方をサポートする必要があります。

// BAD - Hardcoded, will break in other languages
const greeting = "Hello, " + userName + "!";
const message = "You have " + count + " new messages";

// GOOD - Externalized, parameterized, localizable
const greeting = i18n.t('greeting', { name: userName });
const message = i18n.t('message_count', { count: count });

4 つのタイミング トリガー: ローカリゼーションが緊急になったとき

理想的な答えは「最初から」ですが、ローカリゼーションが「あれば便利」から「既存の必要性」に移行する特定の瞬間があります。

トリガー 1: 予期しない国際トラフィック

Google Analytics をチェックすると、トラフィックの 15 ～ 30% がターゲットにしていない市場から来ていることがわかります。これらのユーザーはあなたを見つけていますが、これらの市場でのコンバージョン率は自国の市場より 60 ～ 80% 低くなります。

アクション: これは需要が存在することの検証です。ローカライズを待っていると、それらの市場の競合他社がローカライズされた代替案を構築し、あなたが発見した機会を獲得するでしょう。

トリガー 2: 製品と市場の適合性の達成

最初の市場で製品と市場が適合していることがわかりました。維持率は高く、離脱率は低く、ユーザーはあなたの製品を支持しています。半年後ではなく、今が拡大の瞬間です。

アクション: 継続的なローカリゼーション インフラストラクチャを今すぐ開始してください。 Notion のような企業は、日本と韓国の大規模なユーザー コミュニティに注目するまで待ち、その後急速にローカライズしました。現在、Notion ユーザーの 70% は米国外にいます。

トリガー 3: 資金調達または収益マイルストーン

多額の資金を調達したか、成長の加速が必要な収益マイルストーンに到達しました。投資家は国際的な拡大を期待しています。ローカリゼーションが遅れると、その成長も遅れます。

アクション: 新しい市場への販売とマーケティングを拡大する前に、エンジニアリング リソースの 15 ～ 20% を i18n インフラストラクチャの構築に割り当てます。

トリガー 4: 競争圧力

競合他社が主要市場でローカライズ版を発売し、注目を集めています。彼らのローカライズされた製品は、獲得できたはずのユーザーをコンバートすることです。

アクション: これは最も高価なトリガーです。現在、時間のプレッシャーの下で改造を行っているため、最初から i18n を構築する場合と比べてコストが 8 ～ 10 倍増加します。

アジャイル ローカリゼーション フレームワーク: ウォーターフォールではなくスプリント

すべてを構築してからすべてを翻訳するという従来のアプローチは廃止されました。最新のソフトウェア開発ではアジャイル スプリントが使用されます。ローカリゼーション ワークフローは、このペースに合わせなければなりません。そうしないと、世界的な速度を損なうボトルネックになります。

継続的ローカリゼーション: 実際の意味

継続的なローカリゼーションにより、翻訳ワークフローがアジャイル開発サイクルに統合されるため、ローカライズされたバージョンはソース言語のリリースと同時に出荷されます。翻訳はリリース後の混乱ではなく、すべてのスプリントに組み込まれた並行プロセスです。

実際にどのように機能するか:

1. スプリント計画 (第 0 週): ローカリゼーション要件は事前に特定されます。プロダクト マネージャーとローカリゼーション チームは、どのコンテンツに翻訳が必要か、どの市場が優先されるかについて連携します。
2. 開発 (第 1 ～ 2 週): 開発者は外部化された文字列を使用して機能を構築します。新しいコンテンツがコードベースにコミットされると、自動的に抽出されて翻訳管理システム (TMS) に送信されます。
3. 翻訳 (並列プロセス): 開発者がコーディングを続ける間、翻訳者は新しい文字列の作業を行います。コンテキストは、スクリーンショット、UI の説明、開発者のコメントを通じて提供されます。
4. QA 統合 (第 2 週): 翻訳された文字列はコードベースにマージされます。言語的な QA は機能的な QA と並行して行われます。テスターは、UI の破損、テキストのオーバーフロー、およびコンテキストの正確さをチェックします。
5. 展開 (第 2 週終了): すべての言語バージョンが同時に展開されます。英語、ドイツ語、日本語、スペイン語の各バージョンは、順番にではなく、同時に公開されます。

ローカリゼーションのためのスプリント計画: 欠けている部分

ほとんどの開発チームは、最後の瞬間までローカライゼーションを考慮せずにスプリントを計画します。これにより混乱が生じます。成績の高いチームがローカリゼーションをスプリント計画に組み込む方法を次に示します。

1. 「完了の定義」の一部としてローカリゼーションを定義します。

機能は、すべてのターゲット言語でテストされるまで完成しません。これにより、チームはスプリントの見積もりにローカリゼーション時間を考慮する必要があります。

2. ローカリゼーション ユーザー ストーリーを作成する

ローカリゼーションをユーザー ストーリーとして扱います。「ドイツのユーザーとして、製品を母国語で使用できるように、すべての UI 要素を翻訳する必要があります。」ストーリー ポイントを割り当て、速度を追跡します。

3. スプリント計画会議にローカリゼーション チームを参加させる

ローカリゼーション マネージャーはスプリント計画に参加して、翻訳量を特定し、複雑な文字列にフラグを立てて、タイムラインに合わせます。これにより予期せぬ事態を防ぐことができます。

4. コンテンツの抽出と配信を自動化する

Git コミットから新しい文字列を自動的に抽出し、トランスレーターにルーティングする CI/CD 統合を使用します。電子メールやスプレッドシートを介した手動の引き継ぎは、俊敏な速度を損なうボトルネックになります。

5. 翻訳バッファをスプリントに構築する

すべてのスプリントに大規模な翻訳が必要なわけではありません。一部のスプリントは、UI の変更を最小限に抑えたバックエンド作業に重点を置いています。これらのスプリントを使用して、翻訳の負債を取り戻したり、既存の翻訳を改良したりできます。

チーム構成: 実際にローカリゼーションを行うのは誰ですか?

ローカリゼーションは 1 人の仕事ではありません。それには、開発者、プロダクト マネージャー、テクニカル ライター、翻訳者、QA テスター間の部門を超えたコラボレーションが必要です。理想的なチーム構成は次のとおりです。

ローカリゼーション チームの規模に関する質問

実際に何人必要ですか?それは開発速度と市場の野心によって異なります。

• 初期段階 (PMF 前): 0-1 ローカリゼーション スペシャリスト。開発者は i18n アーキテクチャを扱います。翻訳作業には、翻訳者ネットワークが組み込まれた TMS プラットフォームを使用します。
• Post-PMF (2-5 言語): 1 人のローカリゼーション マネージャー + 外部翻訳ベンダー。マネージャーはワークフローを調整し、TMS を管理し、品質を保証します。
• スケール ステージ (5 ～ 15 言語): 1 ～ 2 人のローカライゼーション マネージャー + トップ市場の専任言語学者 + ロングテール言語の外部ベンダー。国内の審査員を雇うことを検討してください。
• エンタープライズ (15 言語以上): 地域マネージャー、社内言語学者、QA スペシャリスト、ローカリゼーション エンジニアからなる完全なローカリゼーション チーム。

テクニカル ライターの役割: ローカリゼーションのための執筆

テクニカル ライターは、効率的なローカリゼーションの縁の下の力持ちです。ソース言語で明確に書かれたコンテンツは、より速く、より正確に、より低コストで翻訳されます。

ローカリゼーションに適した執筆ガイドライン:

• シンプルで直接的な言葉を使用します: 慣用句、文化的参照、複雑な文構造を避けてください。 「ボタンをクリックして」は、「ボタンを押してプロセスを開始する」よりも適切に翻訳されます。
• 用語に一貫性を持たせる: 同じ概念には同じ用語を使用します。 「削除」、「削除」、「ゴミ箱」を交互に使用しないでください。 1 つ選んでください。
• 文章は短くしてください: 1 文につき 1 つのアイデア。複数の文節を含む長い複合文は翻訳の悪夢です。
• ユーモアや言葉遊びを避ける: ダジャレ、ジョーク、気の利いた言葉遊びが翻訳されることはほとんどありません。これらは翻訳者に、文字通りの翻訳 (ジョークが失われる) か、創造的な翻案 (リスクが生じる) のどちらかを選択することを強います。
• 翻訳者向けの文書コンテキスト: 文字列が出現する場所、その機能、制約 (文字数制限、トーン要件) を説明するコメントを追加します。
• 用語集の作成と管理: 重要な用語を 1 回定義します。翻訳者が製品固有の用語に対して一貫した翻訳を使用していることを確認します。

実際の成功事例: タイミングをうまく捉えた企業

概念: 早期にローカライズされ、グローバルに捕捉される Growth

Notion は、これまでターゲットにしていなかった市場である日本と韓国で予想外の注目を集めていることに気づきました。彼らは待つのではなく、製品と市場の適合後に迅速にローカライズしました。すでにコンテンツ管理用の Contentful を導入していたので、Smartling との統合にはわずか 1 週間かかりました。

現在、Notion は 19 の言語と方言をサポートしており、ユーザーの約 70% が米国外にいます。初期のローカリゼーションへの投資により、拡張を目指す米国製品ではなく、最初からグローバル製品として位置づけられました。

Airbnb: 競争戦略としてのローカリゼーション

Airbnb は、現地（土家、小竹）の熾烈な競争と厳しい規制障壁に直面していることを承知して中国にアプローチしました。彼らのローカリゼーション戦略は翻訳を超えたものでした。

• 「Aibiying」（愛情彼迎）に改名： 「愛を持ってお互いを歓迎する」という意味で、音声的に似ているだけでなく、文化的に共鳴します。
• WeChat と Alipay の統合: 中国のユーザーはオンライン支払いにクレジット カードを使用しません。 Airbnb は決済インフラを地域の行動に適応させました。
• 中国語の好みに合わせて UI を再設計: 文化的な期待に合わせて、用語を「ホスト」と「ゲスト」から「ホーム パートナー」と「短期賃貸人」に調整しました。
• ローカライズされたリスティングの説明: 「高級アメニティ」から、中国人旅行者が実際に探している「居心地の良い滞在」と「本物の現地体験」に移行しました。

結果: ローカライズ後 1 年で中国の顧客ベースは 700% 増加しました。

Spotify: 単なる翻訳ではなく、文化的なローカリゼーション

Spotify のインドでの発売は、ローカリゼーションには言語翻訳だけでなく製品の適応も含まれることを示しています。

• 多言語サポート: ヒンディー語、タミル語、パンジャブ語、その他の言語を、単一の「インド」バージョンとしてではなく、個別にローカライズされたエクスペリエンスとしてアプリに直接統合しました。
• ローカライズされたプレイリスト: 地元のアーティスト、ジャンル、視聴習慣を理解した地域固有の音楽発見アルゴリズムを構築しました。
• 価格設定の適応: USDをINRに換算するだけでなく、現地の購買力に合わせた手頃なプランを導入しました。

Spotify は、ローカライズを正当化するのに「十分な」インド ユーザーが集まるまで待ちませんでした。彼らは最初にそれらのユーザーを獲得するためにローカライズを行いました。

コストの内訳: 実際にかかる費用

実数について話しましょう。ローカリゼーションを最初から行う場合と、後で改造する場合では、実際にどのくらいの費用がかかりますか?

結論: 100,000 行のコードと 10,000 の翻訳可能な文字列を含む一般的な SaaS 製品の場合、初日から i18n を構築するには、追加のエンジニアリング時間として約 30,000 ～ 50,000 ドルの費用がかかります。同じ製品を発売後に改修するには、エンジニアリング、翻訳、QA、および遅延した収益機会に 20 万～50 万ドルの費用がかかります。

よくある反論 (そしてそれが間違っている理由)

「私たちの製品が国内市場で成功するかどうかさえわかりません。」

これは最も一般的な反対意見であり、i18n は高価なオーバーヘッドであり、グローバルに展開する場合にのみ利益が得られるという誤った前提に基づいています。

現実: 初日から i18n を使用して構築すると、10 ～ 15% の余分な開発時間がかかります。これは、2 週間のスプリントごとにおよそ 1 日追加されることになります。文字列を外部化し、ロケールを意識した書式設定を使用し、柔軟なレイアウトを設計するという規律は、ローカライズを行わなくても実際にコードの品質を向上させます。ハードコーディングされた前提を回避し、よりモジュール化されたアーキテクチャを構築し、保守可能なコードを作成します。

本当の問題は「グローバルに進出するのか？」ではない。それは、「製品全体を再構築する余裕があるかどうか」です。

「ローカリゼーションは、それらの市場で有料の顧客を獲得するまで待つことができます。」

これは鶏が先か卵が先かの問題を引き起こします。製品がローカライズされていない場合、国際市場の顧客はコンバージョンに至る可能性が低くなります。これらの市場でのコンバージョン率は自国の市場より 60 ～ 80% 低くなり、「十分な需要が存在しない」と判断できます。

しかし、その需要の低さはローカライゼーションが不十分なために生じたものであり、実際の市場の無関心ではありません。適切にローカライズすると、これらの「需要の低い」市場は、多くの場合、当初の想定を上回るパフォーマンスを発揮します。

CSA Research によると、オンライン消費者の 76% は、母国語で情報が記載された製品を購入することを好みます。製品がローカライズされていない場合、実際の需要を測定することはできません。英語のみの製品に対する許容度を測定していることになります。

「Google 翻訳を使用して、後でクリーンアップします。」

機械翻訳は劇的に改善されましたが、適切なローカリゼーション戦略に代わるものではありません。その理由は次のとおりです。

• 文脈に関する事項: 「銀行」とは、金融機関または川岸を意味する場合があります。 MT はトレーニングがなければコンテキストを理解できません。
• 文化適応は翻訳ではありません: 支払い方法のローカライズ、配色の調整、UI フローの適応は MT が扱うものではありません。
• ブランドの声が失われる: MTは、ブランドの個性を維持する説得力のあるコピーではなく、機能的なテキストを作成します。
• 法的および規制に関するコンテンツには人間によるレビューが必要です: 利用規約、プライバシー ポリシー、およびコンプライアンス文書は法的に正確である必要があります。 MT の間違いは責任を生み出します。

とはいえ、MT は最初のドラフト、ユーザー作成のコンテンツの翻訳、および優先度の低いコンテンツには価値があります。ただし、これは専門的なローカリゼーションに代わるものではなく、人によるレビューを含むワークフローの一部である必要があります。

ローカリゼーション準備チェックリスト

このチェックリストを使用して、ローカリゼーションを開始する準備ができているかどうか (または、最初に i18n インフラストラクチャを構築する必要があるかどうか) を判断します。

インフラストラクチャの準備:

• ユーザー向けの文字列はすべてリソース ファイルに外部化されます (ハードコーディングされていません)。
• コードは Unicode をサポートし、マルチバイト文字を正しく処理します
• 日付、時刻、数値、通貨の書式設定ではロケール対応ライブラリを使用します
• UI レイアウトはテキストの拡大/縮小を処理します (ドイツ語と日本語でテスト済み)
• 右から左へ記述する言語サポートが実装されている (または設計されている)
• 文字列の連結は回避されます (代わりにパラメータ化された文字列を使用します)
• 翻訳管理システム (TMS) が選択されているか評価中です

チームの準備:

• 開発者は i18n の原則を理解し、ベスト プラクティスについてのトレーニングを受けています
• ローカリゼーションマネージャーまたはポイント担当者が割り当てられます
• ターゲット市場に合わせて翻訳ベンダーまたは社内言語学者を特定する
• テクニカル ライターはローカリゼーションに適したコンテンツを作成しています
• QA プロセスには、ローカライズされたバージョンでの UI の破損のテストが含まれます
• スプリント計画には、「完了の定義」の一部としてローカリゼーションが含まれます

戦略の準備:

• トラフィックデータ、市場規模、競争に基づいてターゲット市場の優先順位を決定
• 予算は翻訳、ツール、潜在的な雇用に割り当てられます
• 成功指標が定義されています (市場ごとのコンバージョン率、アクティベーション、リテンション)
• 法的要件とコンプライアンス要件をターゲット市場に合わせて調査します
• 製品と市場の適合性が少なくとも 1 つの市場で検証されている

タイミングのパラドックス

ローカリゼーションを始めるのに最適な時期は、コードの最初の行を書いたときです。次に最適なタイミングは今、次のコード行を書く前です。

i18n インフラストラクチャの構築が遅れると、毎日技術的負債が蓄積されていきます。ハードコードされたすべての文字列は、もつれを解く必要がある別の文字列です。英語のテキストの長さを想定しているレイアウトはすべて、再設計する必要があるレイアウトです。

世界市場で勝利を収めている企業は、最高の翻訳予算を持っている企業ではありません。彼らは初日からローカリゼーションを DNA に組み込んでいるので、東京、サンパウロ、ベルリンで機会が訪れたときは、現地の言語で答える準備ができています。

行動計画: 今週何をするか

これを読んでローカリゼーションが遅れていることに気付いた場合は、すぐに次のことを行う必要があります。

開発を開始していない場合:

1. 初日から i18n 用に設計する: i18n サポートが組み込まれたフレームワーク (React Intl、i18next など) を選択します。
2. 最初のコミットの前に TMS をセットアップします: Lokalise、Crowdin、または Phrase などのプラットフォームは GitHub と直接統合されます。
3. すべての文字列を直ちに外部化します: すべての UI 文字列、エラー メッセージ、およびツールヒントは、ソース コードではなくリソース ファイルに入れられます。
4. ローカリゼーション戦略を文書化します: 1 つの市場でのみリリースする場合でも、他の市場にどのように拡大するかを文書化します。

開発途中の場合:

1. コードベースを監査します: ハードコードされた文字列をすべて特定します。ユーザー向けの機能では文字列の外部化を優先します。
2. リファクタリング ロードマップを作成します: 今後 3 ～ 6 か月間でスプリント速度の 20% を i18n インフラストラクチャに割り当てます。
3. 新機能から始めます: すべての新機能は i18n 準拠である必要があります。これにより、既存の借金を返済しながら追加の借金を防ぐことができます。
4. 擬似ローカリゼーションによるテスト: 実際の翻訳前に文字拡張を伴う偽の翻訳を生成し、UI の破損を見つけます。

すでに起動している場合:

1. 技術的負債を定量化します: コードベースをローカライズ可能にするために必要な労力を見積もります。費用については正直に言ってください。
2. 既存のトラフィックに基づいて市場の優先順位を付ける: ローカライズされていないにもかかわらずオーガニック トラフィックを獲得している市場については、Google Analytics を確認してください。
3. 1 つの市場でパイロットを実行します: 潜在性の高い市場を選択し、完全なローカリゼーション パイロットを実行します。これにより、隠れた課題がすべて明らかになります。
4. 現実的なタイムラインを関係者に伝える: ローカリゼーションの改修には 2 週間ではなく、6 ～ 18 か月かかります。期待値を早めに設定します。

結論: あなたの世界的な未来を決定する決断

ローカリゼーションを遅らせることによる実際のコストがわかりました。問題はローカライズするかどうかではありません。最初からすぐに構築するか、それとも 5 ～ 7 倍のお金を払って後から改修するかです。

i18n インフラストラクチャなしで出荷されるすべての機能は、再構築する必要がある機能です。参入を遅らせると、競合他社が市場を占領してしまうことになります。

最も賢明な創業者は、ローカリゼーションを成長に対する税金とは考えていません。彼らはそれが世界的な成長を可能にする基盤であると考えています。